Re: CUA capabilities

[John Stracke <francis@xxxxxxxx>]

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.

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?

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

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

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