Subject: RE: PROPOSAL: CAP Error codes definition and handling

From: "Lisa Lippert (Dusseault) (Platinum)" <[email-masked]>
Date: Fri, 18 Jun 1999 13:59:59 -0700

Will there ever be a need for parameters on an error message?

E.g. if an attendee tries to change a bunch of properties of a VEVENT
and they are not allowed to change some of them, the error message might
need to specify what property:

	4.15;"organizer";"Write access forbidden to a property"

Lisa

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 14, 1999 8:56 AM
> To: [email-masked]
> Subject: PROPOSAL: CAP Error codes definition and handling
> 
> 
> 
> Within CAP, there is a fundamental need for well defined
> return code handling. Every operation sent from the CUA
> to the CS needs to have a returned status code indicating 
> the result of the operation. 
> 
> As a representative of the group at interim meeting in Atlanta,
> I am proposing the following:
> 
> That to each transaction from the CUA to the server, the
> satus be reported as follows:
> 
> <statuscode>;<text>
> 
> Where:
> 
> statuscode is the error code defined in the status code table
> in the draft.
> 
> text is a USASCII text string, for diagnostics purposes, that
> is not to be displayed by the CUA.
> 
> For example
> 
> 3.5.4; Can't write: disk full.
> 
> I also propose that whatever this group chooses to do,
> that we make that error code format identical between
> iCal's and CAP.
> 
> I'm looking forward to see the group's feedback.
> 
> Andre Courtemanche
> CS&T
>

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jun 1999 14:58:31 -0700 (PDT)

> Date: Tue, 22 Jun 1999 21:38:04 +0000
> From: John Stracke <[email-masked]>
> 
> Doug Royer wrote:
> 
> >         3) Use text in some language. CUA's probably will
> >            not be able to format the data in a pretty looking form.
> >
> >            (Breaks interoperability
> 
> I don't want to drag everybody through the arguments for why #3 is The Right
> Thing again, but I want to object to this one point.  It doesn't break
> interoperability, because it isn't part of the protocol; it's just a comment.
> The only part that needs to be standardized for interop is the error code.

Then that's (1) not (3).

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL