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

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

> Date: Mon, 05 Apr 1999 20:05:15 +0000
> From: John Stracke <[email-masked]>
> 
> 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.

For a VEVENT for example? If yes - there is no such iCAL object
that can represent multiple languages. This has to be true or
it would mean that the CUA could not forward the message via iMIP.
Which one would it send?

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

Not if they are all marked text/calendar. Then iMIP + iTIP + iCAL says
that if they have the same UID - they are the same object and that I can
assume that the newest one received is the latest update.

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

Language and charset are NOT the same thing.

I could make a VEVENT DESCRIPTION in Spanish, French, or English in
the UTF-8 charset.

I could make the same VEVENT DESCRIPTION in Spanish, French, or English
in the iso-8859-1 (and many other) charset.

Any ~new~ component can have a LANG of anything the 'CUA' allows and the
CS would only store the LANG tag, it otherwise does not care.

Charset however MUST be anything the CUA and BOTH CS support. If
not the CS could not even determine the end of line in some charsets.
Some charsets have embedded ZERO bytes in them, ... Example:

--
	content-type ....;charset=klingon
	
	BEGIN:VEVENT
	DESCRIPTION;LANG=empire-starfleet:klsdf^cvs62340\0\01dfkg
	...
	UID:1
	END:VEVENT
 --
 
	content-type ...;charset=iso-8859-1

	END:VEVENT
	DESCRIPTION;LANG=EN-US:Meet me at the water fountain.
	...
	UID:2
	END:VEVENT

--

-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: Wed, 07 Apr 1999 14:29:01 +0000

First, a step back to recover context (I think we're talking at cross purposes,
possibly because I keep getting behind in my email and resuming threads that
people have forgotten about): the original question I tried to answer was "why
would a CUA need to send capabilities?".  My off-the-cuff answer was that it might
need to say what subset of Unicode it could handle; but please forget that, it was
clumsy.  I'm now trying to argue that a CUA might need to be able to specify what
languages its user understands, so that a CS can pick out an appropriate
translation of the iCalendar object.

> it would mean that the CUA could not forward the message via iMIP.

But CAP and iTIP are orthogonal.  A CS that uses CAP to talk to CUAs might use an
extended protocol (iTIP with proprietary extensions, or future standard
extensions) to talk to other CSes.  It would be a Good Thing if CAP1 clients could
get the benefit (or, at least, not be shut out by an incompatible transition to
CAP2).

(For that matter, the alternative renditions of the iCal object might not be sent
from CS to CS at all; a CS might incorporate babelfish technology and translate
the text.  Translation technology is pretty rough today, but it's often
usable--the translated text is more understandable than a language the user
doesn't know, at least--and it'll probably improve in the future.)

> assume that the newest one received is the latest update.

As I said, that's fine.  If your MIME stack doesn't support multipart/alternative
(which it should; it's not a mandatory part of MIME, but it's extremely easy) then
your iTIP implementation will get all the iCal objects in sequence, and the last
one it gets will be the most faithful rendition (as per the m/a spec; see
RFC-2046, section 5.1.4), which probably means the one in the sender's native
language, which is the one you would have gotten without this extension anyway, so
you're no worse off.

In any case, even if this example is found to be difficult or invalid, I maintain
it is still the case that CAP must include bidirectional capability exchange.
Without that, we don't get extensibility, and nonextensible protocols die off very
quickly--probably without even getting an RFC out.

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

---

From: David Madeo <[email-masked]>
Date: Fri, 09 Apr 1999 03:01:17 -0400

John Stracke wrote:

> I'm now trying to argue that a CUA might need to be able to specify what

Maybe I'm missing something here.  If I type "meeting with George" or"rencontrant
George" or "George treffen" or even "ÆüËÜ¸ì George", then that's what I'd expect to be
stored on the CS and that I'd get back in the CUA.  The CS shouldn't be translating
behind the scenes.  At most, the client could translate when specifically asked to by
the user. But I think we're off the topic of the CAP protocols at this point.

dmadeo

---

From: John Stracke <[email-masked]>
Date: Fri, 09 Apr 1999 16:03:30 +0000

David Madeo wrote:

> stored on the CS and that I'd get back in the CUA.

OK, so what do you do if you've got an event announcement (say, a soccer match) where
you'll have people attending who speak many different languages? You want each user to
see the announcement in their own language, which means the CS needs to be able to
present multiple versions and  CUA and the CS need to do content negotiation.  The CS
doesn't need to do the translation itself (though that may be an option eventually); it
would suffice for there to exist some (possibly proprietary) mechanism whereby the
alternative renditions can be provided for it to store.

> But I think we're off the topic of the CAP protocols at this point.

No, because, to do the above content negotiation, CAP needs to be able to express the
user's preferred language.