Subject: RE: error codes

From: Doug Royer <[email-masked]>
Date: Tue, 6 Apr 1999 15:57:09 -0700 (PDT)

> From: "Larry Osterman (Exchange)" <[email-masked]>
> Date: Tue, 6 Apr 1999 15:14:53 -0700 
> 
> The issue is not what the CHARACTER SET is, but what the LANGUAGE is.  A
> character set defines a set of glyphs only, the LANGUAGE defines the
> characters to be sent using that character set.
>
> In addition, there is the client LOCALE, which defines what collation order
> to use when sorting or searching.  If there is to be any sort of search
> functionality in CAP, it MUST contain the ability to specify the locale for
> searching/sorting, otherwise it won't fly as an international standard.
> There are already too many us-only internet protocols....

In iCalendar there is LANG in the iCalendar object and CHARSET in the
MIME header for us to work with.  The default charset for iCalender is
UTF-8 per the existing RFC's.  And in those RFCs a default LANG is not
defined for any 'value'.

The 'iCalendar'-LANG parameter is what many people call LOCALE (as in
'en-us' vs 'en-uk' vs 'fr-ch' vs ...).  And the (ISO?)  ~standard~ for
LOCALE is from the subset of LC_MONETARY, LC_TIME, LC_MESSAGES,
LC_CTYPE, LC_COLLATE, LC_NUMERIC.  Example:

	LC_MONETARY=en-us	What symbol to use for money
	LC_TIME=en-us		Format to display time and time zone to user.
	LC_MESSAGES=en-us	What message catalog to use
	LC_CTYPE=en-us		7bit, 8bit, multibyte, ...
	LC_COLLATE=en-us	How to sort strings
	LC_NUMERIC=en-us	How to display numeric values
	
	(There are probably more ...)

So - back to Hierarchical error codes:

After hearing the debate it would have been nice if the RFCs had not
used hierarchical numbers - but the RFCs do use hierarchical numbers
and that is now the way to do them for iCalendar objects.

As to error messages that are intended to be human readable:

    In order for there to be an error code to include a human readable
    error message, the CS MUST have 2 things:

		1) The iCalendar-LANG (or LOCALE) of the CUA

		2) The charset of the CUA.
	
 -  With human readable error messages and IF the MUST implement for
    CAP is UTF-8, then;  The CS still needs to have a message catalog
    for all of the possible LANGs (LOCALEs) that a CUA might use.

    I think this makes it much harder to interoperate. As in
    no guaranteed interpretability.

 -  If there is no default CHARSET, then the CS and CUA
    MUST agree on the CHARSET, or you can not interoperate at all.

    In other words, no interpretability guaranteed by CAP.
    
-   If however there are NO messages from the CS that are intended
    to be human readable:

    There is now less of a reason to support a large number
    of CHARSETs in the CS. And there may be NO reason to
    support multiple LANGs (LOCALEs) in the CS over CAP.
    
    If the error messages are some kind of string (numeric or not), and
    the data presented in a formatted way (Just an example):

	1.2.3 cap://www.foo.com/abc x-y-z

    The CUA and the CS could both know in any language and locale
    this means something specific. For example:
    
    	If 1.2.3 meant: permission denied
    	And x-y-z meant: CS performing backup - try later
    	
    Any CUA could now construct any human readable message
    and interoperability would be enhanced as everyone knows
    both the meaning to the CS and CUA and next state for both
    the CS and the CUA.

    The CUA could for example know that a retry is might
    work later.

-  If CAP is going to allow other than non-UTF-8 charsets, then
   it is a MUST that the CUA and the CS MUST be able to default
   back to UTF-8. Or there is no guaranteed interpretability.
   
> -----Original Message-----
> From: Doug Royer [mailto:[email-masked]]
> 
> > Date: Sun, 04 Apr 1999 14:52:35 +0000
> > From: John Stracke <[email-masked]>
> > 
> > Doug Royer wrote:
> > 
> > > > Date: Mon, 29 Mar 1999 19:44:43 +0000
> > > > From: John Stracke <[email-masked]>
> > > >
> > > > Frank Dawson wrote:
> > > >
> > > > > What scenario did you have in mind that necessitated the CUA to also
> 
> specify
> > > > > it's capabilities?
> > > >
> > > > "I cannot render non-Latin1 text"?
> > >
> > > As there were not any Latin1 text messages defined,
> > > I am not sure what your need is.
> > 
> > There's human-composed, user-visible text in the message, which means that
> > the CUA needs to consider whether the user is going to be able to read the
> > incoming message.  An advanced CS might be capable of storing multiple
> > versions of the text, and picking out the one to send to the CUA--but only
> > if it can find out what languages the user can read, and what character
> > sets the CUA can display.
> 
> The iCalendar object default charset is UTF-8. 
> 
> I would hope that a CS should be able to charset convert to UTF-8 on
> the way in or out of the CS. I would also hope that all CUAs MUST be
> able to handle UTF-8.
> 
> As for languages, there is no way to store multiple LANG 'DESCRIPTION'
> or 'SUMMARY'.
> 
> I think the best that can occur is if all CUAs MUST be able to handle
> UTF-8, and they must ask for anything other than UTF-8. A user might
> not be able to understand the text as sent to the CS, but the CUA MUST
> be able to understand the UTF-8 text.

---

From: Antoine Leca <[email-masked]>
Date: Wed, 07 Apr 1999 12:10:08 +0200

> LC_CTYPE, LC_COLLATE, LC_NUMERIC.  Example:

They are from the C language Standard (ISO/IEC 9899, aka ANSI C), except
LC_MESSAGES which is from ISO/IEC 9915 aka POSIX.

>         (There are probably more ...)

Not that I know of.

>                 1) The iCalendar-LANG (or LOCALE) of the CUA

Agreed.

>                 2) The charset of the CUA.

Disagree.  What it needs is the charset used in the interchange.  Then
the CUA should be responsible to present it in the proper way to the user,
and this is completely outside the scope of the job on the server side
(think about GUI CUAs where the effective charset is really arrays of pixels!)

>     for all of the possible LANGs (LOCALEs) that a CUA might use.

I believe this is too large as a requirement: suppose I write a ca-valencia-FR
CUA (Valencian version of Catalan as used in France): should all CS all over
the world have to catter with my very specific LOCALE?  I even do not expect
more than a pinch of CS to have messages in anything except English...

So we need negociation and fallbacks here.  With them, we then can have
a minimum (read: English) functionality.  Far from perfect, but better
than nothing.

>     MUST agree on the CHARSET, or you can not interoperate at all.

Agreed.

>     support multiple LANGs (LOCALEs) in the CS over CAP.

Right, but...

>         And x-y-z meant: CS performing backup - try later

This one is clear enough (although I doubt we have to be that precise).

But how can a CS express something that was not envisionned in the specs.
Examples might be "disk full", "disagree on TZ settings", "too much users
connected", "please obtain a cookie from www.cake.com before continuing",
"you are blacklisted", "only GTIML supported", "your driver is not compliant,
upgrade to version 2.x.y", etc. (some may be already covered, some are not).

>    back to UTF-8.

Certainly.  In fact, I do not believe non-UTF8 charsets are to be allowed
(what can be the benefits?)

Antoine