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

Nathaniel Borenstein wrote:

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

Correct, that is the only time 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?

They do not relate to the iCal VERSION directly. It just happens that 
CAP uses iCal
file format '2.0' (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,

iCAL VERSION 2.0 separates multivalued property text items with a COMMA.
See RFC 2445.

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


Per cap the value(s) is(are) the RFC number of the CAP protocol that the 
endpoint
that sent the reply supports. If CS advertised incompatible versions of 
something then
it would be hosing itself.

> -- Allowing the CUA to find out what version of the CAP protocol the 
> CS supports. 

Look at the values the CS sends to the CUA in the CAP-VERSION property
in the GET-CAPABILITY reply.

> -- Allowing the CS to find out what version of the CAP protocol the 
> CUA supports. 

Look at the values the CUA sends to the CS in the CAP-VERSION property
in the GET-CAPABILITY reply.

Each end sends a GET-CAPABILITY to the other endpoint and
gets back a set of properties (with values).

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

So far only iCAL version 2.0 exists and RFC's 2446, 2447, and CAP specify
iCAL as in 2445 (which means 2.0).

If CAP-other-version were to come out, it would need to specify the iCAL 
version.
Plus the iCal objects themselves are tagged with the iCAL VERSION.

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

Given:
   
    CAP-VERSION:1234,5678

Then it means the sending endpoint supports CAP as defined in RFC-1234 
and RFC-5678

> 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


-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards