CAP-VERSION (was Re: Status of the CALSCH working group)

On Friday, November 7, 2003, at 04:14  PM, Doug Royer wrote:

> Currently the iCAL 'VERSION' property of iCAL has the same problem as 
> MIME-Version.
>
> However the  CAP-VERSION is more ~like~ the telnet capability in that 
> you can list the specific
> CAP-ish things. It is not a VERSION as much as a list of docs the CS 
> (or CUA) supports.
>
> So I do not think it has the same problem as the MIME-Version and iCAL 
> VERSION properties.
> If we were to change it to be like the iCAL VERSION property (as some 
> have recently
> almost proposed) - then it would have the same problem as the 
> MIME-Version issue.

I remain confused as to the purpose of CAP-VERSION, and will take the 
liberty of asking a dumb question or two.

First, as far as I can tell, the only example of its use is in a CUA's 
response to a GET-CAPABILITY command issued by a CS.  Is there any 
other scenario where it is used?  If so, what is it?  If not, how does 
a CUA find out what CAP-VERSION is supported by the CS?  How do the 
values for CAP-Version relate to the ical Version?  Moreover, what does 
it mean for a CUA to say that it supports multiple CAP-VERSION values?  
  For example, if in the fullness of time we have defined cap-versions 
"1.0" and "2.0", is it reasonable to imagine that a CUA returns

CAP-VERSION:  1.0; 2.0 (alpha); 2.0 (beta)

In this case, first please pardon my semicolon -- although Doug 
referred to CAP-VERSION as multivalued, I couldn't find any indication 
of what the separator should be so I made that up.  Second, does this 
mean that the CUA is prepared to take data in a form labelled simply 
"2.0" or not?   What if 1.0 and 2.0 actually have incompatible 
semantics for identical syntax -- how is the CUA supposed to know what 
it is seeing?   Finally, why are we using version numbers like 1.0 -- 
is there an intended implication about how an implementation should 
handle unrecognized version numbers, such as "ignore minor version 
differences but insist on major version compatibility"?  If so, we 
should spell it out, and if not, we should dispense with the frivolity 
of using "1.0" when "1" would carry no less information.

I'm sure some of these are stupid questions, but I suspect at least 
some of them are meaningful.

I know that it would be nice if I now made a proposal for how things 
*should* work, but I'm reluctant to do so before I understand the 
purpose of CAP-VERSION.  Here are several possible purposes:

-- Allowing the CUA to find out what version of the CAP protocol the CS 
supports.
-- Allowing the CS to find out what version of the CAP protocol the CUA 
supports.
-- Allowing the CUA to find out what iCal "Version" fields the CS 
supports.
-- Allowing the CS to find out what iCal "Version" fields the CUA 
supports.

Even if I did understand the purpose of CAP-VERSION, I'd still want to 
be sure that there's a way to tell which of the supported CAP-VERSIONs 
is actually being used.  If I tell you I support 1.0 and 2.0, and you 
come back at me with a verb that has different meanings in the two 
versions, how do I know which you're using?

This is the kind of stuff I most want to see us fix before we declare 
the document finished, because getting this wrong will make it much 
harder to fix anything else later.  One of the reasons that 
MIME-Version didn't turn out to be a major problem is that document 
formats are relatively stable and rarely require negotiation.  
Information exchange protocols, however, often involve version 
negotiation, so the costs of screwing this up could be significant.  -- 
Nathaniel