Re: Status of the CALSCH working group (Versioning)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug replied on 11/07/2003 04:14:11 PM:
> > Versioning: The CAP-VERSION property as currently defined is
simply 
> > not adequate to allow us the possibility of gracefully introducing
> > incompatible changes in future versions. As I contemplate an
> > involvement in such future refinements, I can't imagine a more
> > "showstopping" problem than this one. FWIW, I speak
from bitter 
> > experience: for those of you who don't realize it, "MIME-Version"
has 
> > an inadequate definition that almost certainly precludes *any*
future 
> > values other than 1.0. I would like to see CAP avoid the same
mistake, 
> > as I think the cost would be much greater for CAP than it was
for MIME.
> 
> Currently the iCAL 'VERSION' property of iCAL has the same problem
as 
> MIME-Version.

I dont recall seeing any previous WG
postings regarding problems with iCalendars versioning design.  In
any case the topic is CAPs CAP-VERSION and its current design.

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

CAP defines CAP-VERSION as:

   Purpose: This property specifies the
version of CAP supported.

and iCalendar defined VERSION as:

   Purpose: This property specifies the
identifier corresponding to the
   highest version number or the minimum and maximum range of the
   iCalendar specification that is required in order to interpret
the
   iCalendar object.

Unfortunately CAP does not say much
more on the topic of using versions which means there is no clearly defined
behaviour or expectations for CAP 1.0 implementations to follow in a consistant
manner.

Currently it is not a list of supported
versions of CAP, it is a single valued property with no clearly defined
behaviour for going forward.  The issue of the "1.0" (pre-July
2003) vs "XXXX" RFC number (~July 2003) value change is secondary
to the funcational questions of it.

> So I do not think it has the same problem as
the MIME-Version and iCAL 
> VERSION properties.

The problem is compound:

1: The property is currently single
valued, not multivalued.
2: The property has no clear definition
of dealing with multiple values (ie: what is the expected or recommended
behaviour if multiple values are found).
3: Is there any priority assumed by
the ordering of multiple values.
4: If there is a disjoin between each
sides supported version, what then?

I think I had one other but thats enough
to get some discussion going (I hope).

iCalendars VERSION does not share these
problems nor is it relevant to this CAP discussion.

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

You misread/misunderstood the 1st question
on that topic that I asked even after I rephrased it.  Please go reread
it and see if its clearer...  (The point about "numeric"
formatting was due to the previous CAP versions using "1.0" vs
the apparently undiscussed recent change to "XXXX", NOT a proposal
of any kind.)

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...