Subject: [Ietf-calsify] The ical version number must be bumped

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Feb 10 08:29:23 2005

In October, Doug wrote:

> The difficult part is to ensure that we can distinguish old and new 
> objects
> and interoperate as much as possible.

which Tom Ramsdell simplified to:

> Default has to be current behavior to accomodate existing iCalendar 
> generators.

It seems to me that, given the number and nature of the problems with 
the old spec, we have no real choice but to bump the ical version 
number to 3.0.  Tom's concern about backwards compatibility is a real 
one, but my feeling is that, for as long as there are enough ical 2.0 
implementations out there to care abut, a 3.0-complaint implementation 
can *send* both 2.0 and 3.0 data, wrapped in a multipart/alternative.  
It's ugly, but it's the only hope I see for getting to a cleaner, 
simpler design in the long run.

With regard to how we'll actually specify version numbers, Tim Hare 
wrote:

> VERSION; LEVEL=STANDARD: 2.0    Complies with RFC 2445/6/7 as written 
> today
> VERSION: 2.0                            Same as above, under 2.0 
> default would be LEVEL=STANDARD to grandfather existing stuff
> VERSION: 3.0                            Same as the first one, under 
> 3.0 default would be LEVEL=BASIC
> VERSION; LEVEL=EXTENDED: 3.0    Standard plus extensions, look for the 
> EXTENSIONS property
> EXTENSIONS: RFC9901, RFC9902, RFC9903

I think that this and similar proposals to embed capability information 
with the version number are plausible but perilous, for reasons 
described in my other post, "Receiver Capability Description Considered 
Harmful".  That is, they're useful, but I think it would be a mistake 
to use version numbers received in the past to make choices about the 
format of a message to be sent.

Finally, a minor syntactic comment is that if we go down the path of 
extensions, I don't see why we need the syntactic change of "LEVEL=" -- 
it seems to me that syntactically you can do just as well with

	VERSION:  3.0; EXTENSIONS="EXT1, EXT2, etc."

I also claim that it's safer to give these things symbolic names (EXT1) 
rather than RFC numbers, so that it will be possible to produce a new 
RFC that clarifies but does not change the meaning of an extension.

Version numbers are very tricky.  I will be embarassed about our 
underspecification of "MIME-Version: 1.0" to my dying day.  Let's try 
to get this one right.  -- Nathaniel