Subject: Re: Heirarchical error codes

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

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: [email-masked]
> 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

---

From: Rob Earhart <[email-masked]>
Date: Fri, 19 Mar 1999 22:00:40 -0500 (EST)

> If I issue an ABORT and get back a 2.0.99 - what does that mean

  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.

  I agree with you, though.  Actually, I think this is a great reason to
punt on hierarchical error codes entirely.

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

(line breaks added for clarity; imagine that all as one line...).

  (ICON-NUMBER would be a really stupid extension, but that logic's never
stopped people before, and it makes for a nice example.)

  )Rob