Subject: Hirerachical error codes: English Language: A proposal

From: [email-masked]
Date: Mon, 22 Mar 1999 12:01:22 -0500

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

---

From: [email-masked]
Date: Tue, 30 Mar 1999 05:28:57 GMT

Andre made a nice proposal of sorts while John and others went down a BIG
rat hole.  I think this has been a great waste of group bandwidth as some
folks just dont seem to read all emails (or they just ignore postings from
me :^b).  In order to get us back on track (and out of this rat hole) Ill
repost part of my reply on this thread from 3/18:

[Snippet]
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]

So, to make it plain US-ASCII for some folks: We _already_ have what John
was originally asking for _and_ there is a clear description of what a CUA
should do when it finds something like 3.2.1.2.3.6.3.2.2.1.2 and it only
understands codes down to 3.2.1.2.3.6; it can treat them as near
equivalents and behave acordingly.  Thats the entire purpose of the
hierarchical coding scheme and using classes of error codes and why we took
that decision in iCalendar!!!

Enough said on this topic; we have lots more important stuff than just
rehashing violent agreements and reinventing the iCalendar RFC content!!

Bruce