Hirerachical error codes: English Language: A proposal

[andrec@xxxxxx]

Natural Language Error codes: A proposal

We could resolve the situation by the following proposal:

The protocol, as defined is a "English natural language" protocol: it has 
commands like CAPABILITY, CREATE, BEGIN,END. It makes sense to 
have English language Error codes as a "MUST". Then, for commonly used 
commands and keywords, there could be a mapping to numeric values that 
are non-ambiguous. In particular, for error codes we could have the
following: 

>From the following table:

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

Instead of  4.5.8.1, it could be expressed as the following:

BADCOMMAND.COMMANDPARAMETER.BADLYFORMATED.VCAR

Benefits:

1-	A one to one mapping from English natural language to numeric codes 
	can be establish.

2-	When needed, protocol can be easily debugged and, end customers like

	Morgan-Stanley can snoop on the line to see what happening if they
want to.

3-	Not only error codes could have both a numeric and "English" version
but 
	the same could be done for all other tokens, through a standard IETF
proposal
	outside of this one. This would allow for a much more compress
protocol. 
	NOTE: the topic for numeric value based for all tokens in the
protocol is 
	for another time !

4-	For suppliers that want to deliver a hi-performance server, like the
CS&T 
	calendar server, then there is a standard way to do it, not only for
error codes 
	but throughout the protocol. 

5-	Numerical error codes don't have to be done now. A mapping from
English 
	language to numeric values can be a proposal by itself and we can
move forward.

6-	Provides for standard way to extend the error code space as per my 
previous proposal.

Andre Courtemanche
CS&T