Subject: Re: CUA capabilities

From: Doug Royer <[email-masked]>
Date: Wed, 7 Apr 1999 14:05:42 -0700 (PDT)

> Date: Wed, 07 Apr 1999 14:29:01 +0000
> From: John Stracke <[email-masked]>
> 
> 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.

okay - but it was a nice talk :-)

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

Thats what 'fanout' is all about. Pat had an error in her meeting
notes (from Minneapolis or the pre-Minneapolis meeting I forget which).

I think that fanout is 'in'. And that means that a CAP message
can be forwarded via iMAP.

CAP is proposing to rev the VERSION to 2.1. That does not break iTIP.

Pat Egen - was the consensus that it was fanout IN or OUT ?

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

That is one of the points brought up in Minneapolis. Frank presented
the details of why that is a problem and needed to be fixed.

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

I strongly agree that the problems you address need to be solved.

If we solve this incorrectly we have a mess. Ask anyone that has done 
the code that implements the telnet options. I have been
told that the telnet I-HAVE and I-WANT from each side can get very messy.
I think that each side sending CAPABILITY might get into the
same problems.

I don't know the best way - I just don't want to step in the
same land mine.

-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: Fri, 09 Apr 1999 16:09:02 +0000

Doug Royer wrote:

> [...]

(I assume you mean iMIP.) "Can", yes, but that doesn't mean that iTIP is the only
mechanism the CS can use.

> I think that each side sending CAPABILITY might get into the

Perhaps--but at least it's an escape hatch.  If we find that CAPABILITIES works
only for a limited class of extensions, and come up with a better way eventually,
then CUAs and CSes can use CAPABILITIES to announce that they support the better
way.

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