Re: Heirarchical error codes

[Doug Royer <Doug.Royer@xxxxxxx>]

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?

Did it work or not? Or is it the undocumented nonstandard vendor specific
reply to a SENDDATA? Or does it mean - No I don't support that even
if that means I am non-compliant?

I think we will have a MESS of we do not tightly control the status codes.

-Doug

> From: Bruce_Kahn@iris.com
> Date: Thu, 18 Mar 1999 14:50:09 GMT
> 
> (Attempt to re-reply...)
> 
> John wrote:
> >Yes, of course.  The goal is to minimize the problems.  Defining classes
> of
> >error codes enables the client to say, for example, "OK, I don't know
> exactly
> >what this error means, but I do know that it indicates some kind of access
> >control problem".
> 
> but I dont want us to reinvent the preverbial wheel here so Ill refer you
> all to the iCalendar RFC:
> 
> 4.8.8.2 Request Status
> ...
> The short return status is a PERIOD character (US-ASCII decimal 46)
> separated 3-tuple of integers. For example, "3.1.1". The successive levels
> of integers provide for a successive level of status code granularity.
> 
> The following are initial classes for the return status code. Individual
> iCalendar object methods will define specific return status codes for these
> classes. In addition, other classes for the return status code may be
> defined using the registration process defined later in this memo.
> [/Snippet]
> 
> Ill leave it as an exercise to the reader to find the actual text that
> tells CUA implementers to do what John is asking for when dealing w/'newer'
> reply codes...
> 
> Bruce