Subject: RE: error codes

From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
Date: Thu, 8 Apr 1999 14:02:22 -0700

There seems to be an assumption that whenever there is human-readable text
included, that the server must be able to translate that into the
appropriate language for the user.  Why is that?  Antoine's example of a
specific dialect is a good example why we can't expect that to happen.
Instead, Antoine's "ca-valencia-FR" client, which is carefully designed to
use proper dialect and (if it's a GUI) well-formatted dialog boxes of some
kind, will know all the standard errors and have a table mapping them to
appropriate catalan strings.  The client might even have additional
information it can tack on.  An english client might even receive the error
code "4.5.8  BADLY FORMATTED DATA"  and instead display it to the user as
"An error was received from the server which indicated that data was
improperly formatted".  Or the client might choose to do something
completely different than to display a text error.  Summary:  the client
will choose what to display anyway, so text error messages shouldn't be
translated/formatted for the client.

Instead, I've always understood text-based error messages in protocols to be
a convenience for protocol and implementation designers, testers, coders,
debuggers, system administrators, etc.  This makes it possible to use
strings which are brief but informative to techies, like "BADLY FORMATTED
VCAR".

Lisa

-----Original Message-----
From: Antoine Leca [mailto:[email-masked]]
Sent: Wednesday, April 07, 1999 3:10 AM
To: Doug Royer
Cc: [email-masked]
Subject: Re: error codes

Doug Royer wrote:
> 
> 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:

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.

> 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

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!)

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

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

Agreed.

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

Right, but...

>     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

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

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

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

Antoine

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Apr 1999 06:48:41 -0400 (Eastern Daylight Time)

On Fri, 09 Apr 1999 02:38:23 -0400 David Madeo <[email-masked]> 
wrote:

> I agree with most of what Lisa (and the others) are saying on this.  However,
> the dissenting view convinced me.  To reiterate: 1) Adding text of any
> nationality makes the parsing more difficult, especially since it might include
> data as well as a return code (referrals).   2) People working with older
> protocols had found that developers had hard coded parsing based on the
> "friendly" text and were now locked into that format going forward.  Does anyone
> disagree with these two points?

I think the latter is a misreading of the experience.  There
have been two separate problems: 

(i) The original code set is inadequate, so people make up their
own.  This is rarely a "fix in version 2" problem: if
implementers discover that they _need_ something that isn't
there, they will make it up and use it, and, by "version 2", it
will be too late to get interoperability, at least without great
pain.  I suggest that the correct lesson is that, if one can't
be absolutely, 100%, positive that the set of codes provided is
sufficient and unambiguous, then the doc should specify exactly
what should be done when one of the exceptions is found (and
what conditions might constitute an exception, rather than an
excuse for overloading).

(ii) People start parsing, and interpreting, the text part
(whether to translate into a different natural language, or to
translate from geek-speak into "people", or for other purposes,
makes no difference.  This has been cited as a good reason for
banning such text entirely, but it is very handy for tracking
down problems of many varieties.  A flat ban on the practice of
parsing/ interpreting such strings is probably a good idea, but
the ban will stick iff the error code set is sufficient or
readily extensible in an orderly way.  And, of course, if there
have to be significant bits of text in those strings, it better
be *real* easy to find them and pull them out, language and
character-set independent.  

But trying to standardize the text strings and prohibit
everything else is probably a bad idea, if for no other reason
than that such requirements are almost always ignored in
practice. 

    john

---

From: David Madeo <[email-masked]>
Date: Fri, 09 Apr 1999 02:38:23 -0400

I agree with most of what Lisa (and the others) are saying on this.  However,
the dissenting view convinced me.  To reiterate: 1) Adding text of any
nationality makes the parsing more difficult, especially since it might include
data as well as a return code (referrals).   2) People working with older
protocols had found that developers had hard coded parsing based on the
"friendly" text and were now locked into that format going forward.  Does anyone
disagree with these two points?  Unless they can be refuted, my opinion is that
I'd like to keep the parsing as easy to do as possible.  That outweighs the
slight gain in ease of use for an administrator.

I'd suggest that the RFC define each return code and the accompanying English
text to explain it.  A CS MUST reply with only the return code.  It MAY (if it
would like to make it's users happy) log the accompanying text (or it's
translated equivalent) or even Lisa's example text.  An especially industrious
implementor would include a wrapper for snoop or tcpdump or your favorite packet
sniffer which would provide a similar service.  As a customer/administrator,
that would be good enough for me.

I'm deliberately avoiding the topic of whether error messages should be
extensible.  Andre's example of "Bad Data"->"Bad Vcar"->"Bad CalID" is a
reasonable one.  But of course, you'd still need to go through the process of
registering the extensions, otherwise there's the potential for conflict.  Your
bad CalID is my password incorrect.

One question that keeps coming up is "what about errors we didn't envision
during this process".  Isn't that why so many people are vetting this?
Alternatively, that's what version 2 is for.   Antoine uses the example of disk
full.  Isn't there a big difference between protocol errors and what the CS is
logging behind the scenes?

Hopefully, we can come to agreement on this part of the discussion so that we
can start coming up with more CAP examples and focus on the difficult issues of
hierarchy, users vs calendars, and access control.

Thanks,

dmadeo

---

From: John Stracke <[email-masked]>
Date: Fri, 09 Apr 1999 15:56:11 +0000

David Madeo wrote:

> sniffer which would provide a similar service.

Bleah.  I don't like solutions which require the user to employ packet sniffing.
What if they're on a multiuser machine; do you want them to see other people's
sessions? (More likely, of course, they just won't be allowed to sniff anything.)
What if the calendar admin is not the superuser on the calendar server? What if the
user's on an OS which simply cannot support sniffers? (E.g., a cellphone of 2004
might well contain an IP stack, and a bare-bones CUA would be an obvious app to
include; but it probably won't be running an OS where the user can run third-party
software.)

I like Doug's suggestion, where a status report can consist of three parts:

   * A standard error code which the CUA can understand (MUST).
   * Descriptive text for debugging purposes (SHOULD).  Not necessarily in English,
     of course; it can be in the implementor's own language, or an implementor can
     make it localizable.
   * User-visible text which must be localizable.  (SHOULD, whenever the server has
     useful details that can't be conveyed in a standard error code.) How a server
     localizes text sent to a client is an interesting problem, of course.

> during this process".  Isn't that why so many people are vetting this?

Yes, but we're rushed; we have to get this done by July, and it's not so improbable
that we'll miss some stuff.

> Alternatively, that's what version 2 is for.

Big-bang version changes in protocols are a Bad Thing.  Good protocols are smoothly
extensible.

--
/=============================================================\
|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 |
\=============================================================/