CAP-12-e: CAP-VERSION Property
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OF95866467.04DCDDF3-ON85256DD3.006E9561-85256DD3.006F5AE8@notesdev.ibm.com> |
In looking at Tims proposal I noticed that CAP-VERSION is not properly
described/defined. 12-e says:
Description: This specifies the version of CAP that the endpoint
supports. The list is a comma separated list of RFC numbers
supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE
REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT).
Formal Definition: The property is defined by the following notation:
cap-version = "CAP-VERSION" other-params ":" text CRLF
Example: The following are examples of this property:
CAP-VERSION:XXXX
1: Is there a reason CAP-VERSION is not defined like VERSION is in
iCalendar? That is, why it is not a numeric value or formatted like a
numeric value? It used to be last I checked on it back in CAP-09:
CAP-VERSION 1 Version of CAP. It MUST include at least
"1.0"
for this version of CAP. Like the "VERSION"
property, it may have a range. Uses the
exact
same syntax as the "VERSION" property value.
The default is "1.0".
2: When did we say CAP-VERSION was to be the RFC number? Is there any
real use for that over using the numeric scheme like we did in iCalendar?
If we do opt to stay with "text" then the last line there needs to have
the same "(NOTE 'XXXX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS
DOCUMENT)." added to it to ensure the change is uniform.
3: In later examples we use numeric values ala VERSION. For example, page
112 has:
L: CAP-VERSION:1.0
If we are avoiding using numeric values and go with RFC numbers then this
example needs to be changed and flagged too for update on RFC number
assignment.
Bruce
===========================================================================
Bruce Kahn INet:
[email protected]
Messaging & Collaboration Phone: 978.399.6496
IBM Software Group FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.