Re: Heirarchical error codes

[Rob Earhart <rob@xxxxxxxxxxxxxx>]

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.

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

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

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

  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:

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

  I think I understand your motivation: reusing REQUEST-STATUS property
values somehow would be a good thing.  I just don't think they're the
general solution for CAP. 



  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.

  )Rob