Subject: Re: CUA capabilities (was Re: Heirarchical error codes)

From: Doug Royer <[email-masked]>
Date: Mon, 5 Apr 1999 11:14:57 -0700 (PDT)

> Date: Mon, 05 Apr 1999 16:10:11 +0000
> From: John Stracke <[email-masked]>
> 
> (Clarification: when I referred to Latin1 text, I didn't mean the encoding, I
> meant the characters themselves, regardless of how they're encoded.)
> 
> Doug Royer wrote:
> 
> > As for languages, there is no way to store multiple LANG 'DESCRIPTION'
> > or 'SUMMARY'.
> 
> (a) Sure there is--the protocol may not specify a way to transport them, but
> you can store whatever you want.

True - but that vendor specific extension is not part of a CAP.

> (b) I suspect that iMIP might be able to express it with multipart/alternative
> (you wouldn't necessarily want to send it to someone unless you know they can
> handle it, since m/a isn't a mandatory part of MIME; but it can be done).

They better not have the same UID, or I might keep replacing the
last one found as the newest one.

> > 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.
> 
> Not going to happen--the CUA can handle it internally, sure, but most of the
> computers in the world simply do not have the fonts to render every single
> character in Unicode.

True - but there is no other better choice? And RFC-2445, 2446, and
2447 were written with UTF-8 in mind. A not yet written soon to be 'CAP'
CUA would have to deal with this anyway.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
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: Mon, 05 Apr 1999 20:05:15 +0000

> True - but that vendor specific extension is not part of a CAP.

Storage is not a vendor-specific extension; it's an implementation detail,
orthogonal to the protocol.  The only extension being discussed is the capability
negotiation that would enable the CS to figure out which language variant to
present.

> last one found as the newest one.

If you don't understand the extension, then that's more or less fine; they're all
equivalent.

> True - but there is no other better choice?

No, there isn't--everything in the world needs to handle Unicode; every iCal-based
solution needs to handle UTF-8--but we should attempt to provide some form of
content negotiation so that users can see languages they understand.

In fact, in some countries, it's probably going to be a requirement.  Consider a CS
that contains a public calendar of music events at Ontario Place.  That information
needs to be available in English and French, and it would be a pain if people had
to configure their CAP client to know which calendar to use to pick the right
language.

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