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

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jun 1999 13:52:15 -0700 (PDT)

> From: [email-masked]
> Date: Tue, 22 Jun 1999 15:51:30 -0400
> 
> Lisa asked:
> >Will there ever be a need for parameters on an error message? 
> 
> Perhaps.  It could be useful (or necessary) in the future to have that 
> info.
> 
> Despite all the noise on this thread so far I have not heard any reason 
> why the current RFC 2445 format for Response-Status cannot be used.

There are two kinds of errors:

	CAP protocol errors - yet to be defined.
	
	iCalendar (RFC 2445) errors - already defined.

An iCalender object is a MIME object. And the charset can
determined by looking at the MIME header. The language
can be determined by looking into the iCalendar object (but
only after you know the charset).

However CAP protocol errors are NOT MIME objects.
So what charset / language will the text part of any
CAP protocol error be in? I think we want the CAP
protocol to be in the UTF-8 charset. 

So the debate (as I understand it) was on three basic paths.
(Plus my feelings on these).

	1) Text optional. Use English in UTF-8 as the text is NOT
	   to be used by a CUA. Text part optional and for
	   debug use only.
	   
	   (My 2nd choice.)
	   
	2) If they are intended to be used by a CUA, then
	   then they need to be localizable and in a
	   predetermined format. Something like:
	   
	   	4.5.6;<username>;DENIED

	   (My 1st choice PLUS need a set LANG CAP command
	    something like the (proposed?) FTP LANG command.)
	   
	3) Use text in some language. CUA's probably will
	   not be able to format the data in a pretty looking form.

	   (Breaks interoperability as you can't depend on
	    the string from the CS to be useable by the CUA,
	    and users will get confused across the internet
	    when different vendor CS's produce different strings
	    for the same error.)
	
If (2) there needs to be a way for the CUA to set the
preferred language in UTF-8.

I do not like (3) because that is what IMAP does, and GUI MUA's
ignore the messages as they don't often mean anything to the user.

Also if there is text in the error message, what format?
If a CUA is to use it in a GUI, it will need to be well
formatted or it will not be used and again users may
not see anything useful.

>  Since 
> we already have one "error code" format I do not see any useful reason to 
> invent another.  I still propose that we reuse the format from Section 
> 4.8.8.2 of the iCalendar RFC for this purpose.  If anyone can give reasons 
> why we should not then Id like to hear them.  Otherwise, KISS and lets not 
> reinvent the wheel here (There are more important issues to handle!)...
> 
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: [email-masked]
> Iris Associates                          Phone: 978.392.5335
> Westford, MA, USA 01886                    FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...
-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

---

From: John Stracke <[email-masked]>
Date: Tue, 22 Jun 1999 21:38:04 +0000

Doug Royer wrote:

>            (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.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/