Re: Heirarchical error codes

[Rob Earhart <rob@xxxxxxxxxxxxxx>]

On Fri, 19 Mar 1999, Doug Royer wrote:
> > > 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.

  It would have to be in v1, so that the first thing a client does is
issue the command "go to v1 mode".  In any event, I think the whole
capability negotation's been covered in a seperate thread... 

> 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 argument holds for all protocol elements, actually.  Why have a
textual protocol at all, instead of going straight binary?

  I don't really mind binary protocols.  I think textual protocols are
much easier to debug and understand, in addition to being more flexible,
but I can see the case for binary; the more compact encoding makes some
sense if nothing but machines will ever read it. 

  I don't know of any argument to justify a part text, part binary
protocol, though; pick one or the other.  Currently, it's a textual
protocol; the best arguments in favor of this are ease of debugging and
flexibility.  Why throw that away just to make the error codes numerical? 

> >     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)

  (Incidentally, where could I get a copy of the current CAP proposal?)

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

  True.  And the other side should know, from one's announced
capabilities, which response messages one understands.

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

  I disagree; I've personally written the code to do it, and aside from
the effort in translating, it was trivial.  (Admittedly, things do get
interesting if you want to use an external message catalog.)

>    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.

  I think we MUST have them.

> A well defined and well thought out protocol should be able
> to define all CS and CUA states and response codes.

  This turns out to be nigh-impossible.

  There are simply too many special cases to create a response code for
each of them; ask Ned Freed sometime about X.400 error codes, and the
lengths they went to attempting to encode every possible circumstance in
an error code (my personal favorite was the one for "Recipient has died"). 
It turns out to be very useful to allow servers to directly say what they
want; specify response codes for the things which the client might care
about and be able to deal with, and send the rest as a human-readable
string.  Attempting to have clients localize server-generated messages is
an interoperability and specification nightmare.

  Incidentally, one of the arguments that I was trying to make which you
didn't address was that response codes shouldn't be strictly hierarchical;
there's a need for orthogonality.  Did this make sense?  (I just want to
check; I think it's pretty important.)

  )Rob