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

[John Stracke <francis@xxxxxxxx>]

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.

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.

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

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

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

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  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/