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

From: Doug Royer <[email-masked]>
Date: Tue, 18 May 1999 15:45:35 -0700 (PDT)

> From: "lisal" <[email-masked]>
> Date: Tue, 18 May 1999 15:25:11 -0700
> 
> The DAV RFC explains better than I have been able to how you can have
> English text in error messages (for ease of design, debugging, coding
> and testing), without worrying about localization.  
> 
> "For error reporting, we follow the convention of HTTP/1.1 status
>    codes, including with each status code a short, English description
>    of the code (e.g., 423 (Locked)).  While the possibility exists that
>    a poorly crafted user agent would display this message to a user,
>    internationalized applications will ignore this message, and display
>    an appropriate message in the user's language and character set.
> 
>    Since interoperation of clients and servers does not require locale
>    information, this specification does not specify any mechanism for
>    transmission of this information."
> 
> -- Lisa

I think we are agreeing.  The text is optional and for
diagnostic use only. From RFC-2068, the ABNF for 'status code'
section 6.1.1:

          extension-code = 3DIGIT

          Reason-Phrase  = *<TEXT, excluding CR, LF>

Where '*' denotes optional.

> > -----Original Message-----
> > From: Doug Royer [mailto:[email-masked]]
> > Sent: Tuesday, May 18, 1999 2:13 PM
> > To: [email-masked]
> > Subject: RE: PROPOSAL: CAP Error codes definition and handling
> > 
> > 
> > 
> > > From: [email-masked]
> > > Date: Tue, 18 May 1999 13:31:34 GMT
> > > 
> > > ...
> > >
> > > >Furthuremore, statdesc is of a type that can be localized,
> > > >with a language tag, bla, bla bla.
> > > ...
> > >
> > > If the LANG= issue is the only real problem for Andre Id 
> > ask the WG to give
> > > a thumbs up/down on leaving in the LANG= or not (and if 
> > not, defaulting it
> > > to USASCII).  If there are any other issues then lets 
> > resolve 'em but I
> > > still think we should reuse this format (just like we 
> > reused the iCalendar
> > > hierarchical response code format and classes).
> > 
> > If the LANG is going to be there in the CAP protocol, then there
> > needs to be a way for the CUA to specify its preferred LANG to
> > be used in the CAP protocol replies. Otherwise there is no way
> > to know not to send some LANG content that is incompatible with
> > the CUA.
> > 
> > The REQUEST-STATUS iCalendar object contains application data
> > reply information.
> > 
> > The CAP protocol reply contains information independent of the
> > iCalendar application data.
> > 
> > I agree with Andre's proposal. 
> > 
> > 	<statuscode>;<text>
> > 
> > Where <text> is optional, US-ASCII, and for diagnostics purposes only.
> > I am in favor of:
> > 
> > 	<statuscode>[;<text>]
> > 
> > Where  the 'text' value is optional at all times.
> > 
> > -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
> > 

-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: Dave Crocker <[email-masked]>
Date: Mon, 24 May 1999 11:20:57 -0700

>diagnostic use only. From RFC-2068, the ABNF for 'status code'

Exactly  correct.

And to the extent that anyone wishes to have responders generate the 
'correct' language for users, let's remember that a successful protocol 
works toward fewer choices, not more.

Supporting many languages, as an essential part of the core protocol, makes 
implementation a nightmare.  (This is distinct from permitting simple 
carriage of different languages.)

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>