Re: Heirarchical error codes

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Sun, 21 Mar 1999 22:10:44 -0500 (EST)
> From: Rob Earhart <rob@andrew.cmu.edu>
>
> On Sat, 20 Mar 1999, Doug Royer wrote:
> > In general I could agree. In CALSCH, the RFC's already define status
> > codes RFC2445, 2445, and perhaps 2446.
> 
>   Just to outline my problems with them:
> 
>   ) They're unwieldy and difficult to read in a protocol trace.

Too late - they are RFC's and there are implementation already
using them. Wished you would have submitted your suggestions last year.
:-(

>   ) They're pretty specific to processing of iCalendar objects -- which
> is important in CAP, but not all of CAP.

True - however part of CAP is returning iCalendar objects - with
those status replies. Two forms of reply codes for the same thing?

>   ) They impose a strict hierarchy on the response code space, which
> limits extensibility.

No not at all. Example, look at the documented extensions that CAP
and iRIP have proposed to them.

>   ) The protocols are fundamentally different.  CAP will be processed by a
> different parser, which can translate as needed.  The operations, while
> similar, need not--and probably will not--be identical. 

CUA's would be forced to deal with both kinds. One from CAP, the
other in the iCalendar object.

>   On the other hand, they may be useful for a CUA when performing
> iTIP-like manipulations.  Maybe a server could encapsulate them in some
> responses? So when attempting to schedule a meeting, a client might
> recieve the following:

Why? When there are already defined ones that do the same thing?
Again, if this had been done 1 year ago when iCalendar was a draft.
At this time its just going to add confusion and double the
code to parse reply codes, one for each format.

> 	S: Bad iCal (3.5) "Invalid iCal object"
> 
> (I've left the human-readable text deliberately vague here; in a real
> server, I'd clarify exactly what was invalid.  So how many people know,
> off the tops of their heads, what 3.5 is defined to be by section 3.6 in
> rfc2446?) 

Yet above you talk about a parser. The protocol is for the parser.

>   Re: human-readable messages.  I agree with your points (although I don't
> think UTF-8 is unreasonable for PDAs).  I still think that adding a
> human-readable message doesn't hurt users who can't read it, it's a nice
> addition for users who can, and is definitely a good thing from a system
> administration standpoint, assuming that the server's halfway intelligent
> about how it composes those messages.
> 
> > Have you seen some of the so called human viewable messages
> > that come back in IMAP servers? What does "internal error" mean?
> 
>   I think that's a quality of implementation issue...
> 
> > I could see a debug option that turned them on. Then they
> > would be OPTIONAL and the server would not have to translate
> > the message for every locale. And if they were OPTIONAL for
> > the server to implement and advertised as a capability, then
> > I could go for them.
> 
>   Why not just always send them?  They're not that much overhead, and
> clients never have to show them to users... I'd much rather require
> servers to implement them.

How long are they? What is the format of the line that I can ignore?

Optional at runtime - yes.
MUST implement - I could go with yes if they are optional at run time.
If required - a waste of bandwidth.

-Doug