Re: Heirarchical error codes

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Fri, 19 Mar 1999 22:00:40 -0500 (EST)
> From: Rob Earhart <rob@andrew.cmu.edu>
>
> On Fri, 19 Mar 1999, Doug Royer wrote:
> > I really think we need to be strictly define status codes. And only
> > by revving CAP could they be added. Think interoperability.
> >
> > If I issue an ABORT and get back a 2.0.99 - what does that mean
> > to the CUA?
> 
>   Even if v2 of CAP were to define that code, v1 clients wouldn't be able
> to grok it; they'd just have to deal.

Yes but in Minneapolis we talked about requireing a V2 server to
have a command like "go to v1 mode". Then its a non-issue.

>   I agree with you, though.  Actually, I think this is a great reason to
> punt on hierarchical error codes entirely.

I would prefer if error codes were assigned in sequence. (1, 2, ...)
and have NO relational value. I think the argument of human readable
result codes is silly. As 99.999% or more of all of the calendring trafic
of the futrue CAP will be between CS's and CUA's, not people looking
at them.

>   The same orthogonality issues that come up in setting CAP version
> numbers vs. capability lists come up in error/status codes.  It's more
> extensible to send a not-necessarily-hierarchical stream of stuff that
> clients can deal with or punt on, as needed.  One might envision some
> client ten years down the road getting a response like
> 
>     S: a1 NO PERMISSION ("cal://foo.bar/some_object") TEMPFAIL
>        MICROSOFT-ICON-NUMBER (16) "You don't have permission to do that
>        right now."

1) I think that the current CAP proposal is that tags be NUMERIC only.
   (I know that's not your point - just FYI in case some missed that)

2) 'Punt'ing on a response directly opposes interoperability.

3) Human readable messages in server / client protocols makes
   implementing multi-simultaneous-locale servers difficult.

   (One CUA in French, another CUA in Japanese, and a third CUA 
    in Arabic all talking to the same server at the same time).

   Yes its doable, the Sun-CS does this.

   Even if the the WG decides to go with string type of status messages;
   I think we MUST keep human readable messages out of the protocol.

A well defined and well thought out protocol should be able
to define all CS and CUA states and response codes. If any were
missed, that would be a good argument for a new RFC with updates,
and an argument against vendors just adding them.

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL