Subject: CAP-12-e: CAP-VERSION Property

From: [email-masked]
Date: Mon, 3 Nov 2003 15:19:36 -0500

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-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Mon, 03 Nov 2003 14:42:26 -0700

[email-masked] wrote:

> iCalendar? 

It is a multivalued field unlike VERSION. So you could say you are RFC 
X, and Z compatible
skipping Y if needed.

>  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:
>
>                              property, it may have a range. Uses the exact
> 2: When did we say CAP-VERSION was to be the RFC number? 

As you pointed out about it must have been -10

-- 

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

               We Do Standards - You Need Standards

---

From: [email-masked]
Date: Tue, 4 Nov 2003 10:18:35 -0500

> It is a multivalued field unlike VERSION. So you could say you are RFC 

My appologies for not be more precise in the question.  I was referring to 
using a numeric values like VERSION (which actually is biparted):

     version    = "VERSION" verparam ":" vervalue CRLF

     verparam   = *(";" xparam)

     vervalue   = "2.0"         ;This memo
                / maxver
                / (minver ";" maxver)

     minver     = <A IANA registered iCalendar version identifier>
     ;Minimum iCalendar version needed to parse the iCalendar object

     maxver     = <A IANA registered iCalendar version identifier>
     ;Maximum iCalendar version needed to parse the iCalendar object

So to rephrase a bit: Is there a reason that CAP-VERSION is not defined 
using something like:

   cap-version   = "CAP-VERSION" capverparams ":" capvervalue *("," 
capvervalue) CRLF

  capverparams   = *(
                ; the following are optional,
                ; and MAY occur more than once

                (";" iana-params) /
                (";" xparam) 
                )

   capvervalue   = "1.0"         ;This memo
                / iana-capver

   iana-capver   = <A IANA registered CAP version identifier>
     ;Any other IANA registered CAP version that the sender supports

This is how we defined recurrence and exception dates (multivalued) and 
VERSION ("1.0" instead of the RFC number) in iCalendar.

> As you pointed out about it must have been -10

Did we actually discuss exchanging "1.0" for the RFC number at some point? 
 I dont recall any WG discussion on it nor can I find any in the archives. 

A check of the archives for "CAP-VERSION" shows we talked about the 
GET-CAPABILITY command being mandated for all implementations back 
~Oct/Nov 2002 and back then we used CAP-VERSION:1.0. 

On 15-Apr-2003 in the thread "Diffs - ftp://royer.com/pub/CALSCH/cap.txt" 
we were using "1.0" still.

The next time I find a reference is Dougs "CAP ABNF" posting dated 
06/14/2003 05:38:19 PM CST that had:

   254   cap-version   = "CAP-VERSION" other-params ":" text CRLF

but nothing inbetween nor anything that discussed the change on the list. 
Hence my question: _When_ did we say CAP-VERSION was to be the RFC number? 

Bruce
Standard disclaimers apply, even where prohibited by law...

---

From: Mark Smith <[email-masked]>
Date: Tue, 04 Nov 2003 11:47:53 -0700

> Did we actually discuss exchanging "1.0" for the RFC number at some

Look closer. As usual - you miss what you disagree with.

---

From: Doug Royer <[email-masked]>
Date: Tue, 04 Nov 2003 12:16:01 -0700

[email-masked] wrote:

> My appologies for not be more precise in the question.  I was 
> referring to using a numeric values like VERSION (which actually is 
> biparted):

Do you have a proposal? It does not look like it to me.

--

---

From: [email-masked]
Date: Wed, 5 Nov 2003 09:40:07 -0500

> Look closer. As usual - you miss what you disagree with.

I already said I did a full text search on "CAP-VERSION" which should be 
in any posting where it was to be discussed and found no WG postings 
between April where it was "1.0" and June where Doug posted it as the RFC 
number.  If you wont provide at least a thread reference then please dont 
waste our cycles.

Bruce

---

From: [email-masked]
Date: Wed, 5 Nov 2003 10:11:58 -0500

> Do you have a proposal? It does not look like it to me.

I clearly indicated that it was a question, not something that required a 
proposal to resolve. 

By your constant avoidance to the question Ill have to assume that you 
made the change arbitrarily without WG discussion or concensus by virtue 
of being the sole current editor.  If Im wrong then fine but I can find no 
WG discussion on the changes that Im asking about or the questionable ABNF 
I find.  As recent as April 2003 it was described one way and all of a 
sudden in June 2003 it was different.

Since you have said (in part but not out of context):

It is a multivalued field...

I think its fair to question the non-multivalued ABNF that is currently 
there.  In case you were not aware, the current ABNF does NOT indicate 
that CAP-VERSION is multivalued.  It is just:

which means CAP-VERSION is single valued; a single 'text' value.  If you 
want to see an example of a multivalued ABNF then check out my provided 
ABNF or the one in Section 8.22 MULTIPART Property

   name = "MULTIPART" other-params ":" text *( "," text) CRLF

Bruce