[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PROPOSAL: CAP Error codes definition and handling



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

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: andrec@cst.ca [mailto:andrec@cst.ca]
> Sent: Friday, May 14, 1999 8:56 AM
> To: ietf-calendar@imc.org
> 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
>