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,
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?
-- 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).
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
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature