RE: Heirarchical error codes: A proposal

["Lisa Lippert (Dusseault) (Exchange)" <lisal@xxxxxxxxxxxxxxxxxxxxxx>]

With this proposal, are you intending that the strings in the table below be
sent along with the numbers?  I'd go for that -- yes it's lengthy, but it
makes design/debugging easier.

Lisa

-----Original Message-----
From: andrec@cst.ca [mailto:andrec@cst.ca]
Sent: Monday, March 22, 1999 8:31 AM
To: ietf-calendar@imc.org
Subject: Re: Heirarchical error codes: A proposal




Here's a proposal to solve the "Hierarchical error code issue", allowing us
to 
move forward

If we accept that error codes can be hierarchical, that is a series of
numbers
Separated by "."  (i.e. 4.5.5) and that we accept that there is a known
table
of error for a particular version of the protocol as could be illustrated by
the
example below:

		4.5.8	"BADLY FORMATED DATA"
4.5.8.1	"BADLY FORMATED VCAR"
4.5.8.2	"BADLY FORMATED iCAL DATA"
4.5.8.2.1	"BADLY FORMATED OWNNER PROPERTY
4.5.8.2.2	"BADLY FORMATED DTSTART
4.5.8.2.3	"BADLY FORMATED  DTEND"
4.5.8.3	"BADLY FORMATED PRINCIPAL


Then, given a new server that has more error codes, for instance 4.5.8.1.4,

with meaning "BADLY FORMATED CARID". Note that it is not in the table.

An older CUA can still function. It doesn't know exactly what the error
means but it known it's a badly formatted VCAR.

This way of doing has 2 benefits:

1-	Interoperability of servers supporting error codes that are more
specific. The example above illustrates it.
2-	Allows new set of error codes to be published for the protocol in a
standard way. The group, or individuals could certainly propose very well
defined extension, through the IETF process.

Andre Courtemanche
CS&T