Subject: Re: Heirarchical error codes

From: Doug Royer <[email-masked]>
Date: Fri, 19 Mar 1999 19:25:13 -0800 (PST)

> Date: Fri, 19 Mar 1999 22:00:40 -0500 (EST)
> From: Rob Earhart <[email-masked]>
>
> 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
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Rob Earhart <[email-masked]>
Date: Sat, 20 Mar 1999 13:37:22 -0500 (EST)

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

> of the futrue CAP will be between CS's and CUA's, not people looking

  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? 

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

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

>    I think we MUST keep human readable messages out of the protocol.

  I think we MUST have them.

> 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