Subject: Focus attempt: Do new properties force a change in VERSION?

From: Bob Mahoney <[email-masked]>
Date: Thu, 13 Jun 2002 20:19:00 -0400

I asked Doug Royer to craft a concrete example that could explain his 
understanding of the competing viewpoints around the question of the 
need to change the VERSION property.  His example follows.

Thoughtful and dispassionate discussion is preferred...  :-)  If you 
have an alternate understanding, please include your version of this 
example object, so that we can compare apples and apples.

Thanks

-Bob

--
Question:  Does adding new properties force a change in the VERSION
  property value? (currently 2445 is version "2.0")

  My reasoning that it does not change:

	It would be like bumping the MIME-Version number
	in e-mail from the current 1.0 each time someone
	added a new header or mime body type. How many
	mime types have been added since MIME 1.0 was
	released? And MIME is still at 1.0 because the
	format of the MIME object has not changed.

	The implication of updating the VERSION number
	would be that ALL implementation of VERSION X.Y
	would have to implement ALL features in A.B through
	X.Y, when in fact they can be parallel an not
	interacting with each other.

	Example: If we were to add properties that allowed
	Hertz to track cars and called that version 2.3 .
	Then later added properties that allowed conference
	room tracking and called it 2.4 . Now all conference
	room implementation would have to implement car
	tracking to be compliant. When in fact the two can
	coexist and not interact with each other.

  How this effects the CAP design:

	Some folks on the list are saying that because
	we have to bump the version number (and we don't),
	then we MUST have a new iCalendar wrapper object
	EACH time we add a property. Not only that, but
	they are saying that in addition to making the
	wrapper object, we ALSO have to bump the version
	number of the object.

	Here is a silly example of how far that can go:

		BEGIN:VCALENDAR
		VERSION:X.Y
		BEGIN:WRAPPER-3
		favorite-hand:right	# implied version x.x
		BEGIN:WRAPPER-2
		car-license-plate:123456 # implied version x.w
		BEGIN:WRAPPER-1
		cap-command:just store it. # implied version x.v
		BEGIN:VEVENT		# implied version 2.0
		2445 - properties
		END:VEVENT
		END:WRAPPER-1
		END:WRAPPER-2
		END:WRAPPER-3
		END:VCALENDAR

		When it could just be:

		BEGIN:VCALENDAR
		VERSION:2.0
		favorite-hand:right
		car-license-plate:123456
		cap-command:just store it.
		BEGIN:VEVENT
		2445 - properties
		END:VEVENT
		END:VCALENDAR

	It is up to the WG to decide if the new properties
	effect existing objects. It is not automatic.

	Adding 'favorite-hand' does NOT effect anything.

	Adding 'bumb-all-dates-by-one-day' would effect
	other properties and and it would be blocked by
	the WG anyway.

---

From: "John Stracke" <[email-masked]>
Date: Fri, 14 Jun 2002 10:30:21 -0400

>                interacting with each other.

Some features might be parallel. For example, many of the SkiCal 
properties seem to be mutually independent.  However, other useful 
features are not parallel.  For example, many of the base iCalendar 
properties interact--consider DTEND and DURATION.  It is clearly necessary 
that, any time we add the property which interacts with an existing 
property, we increment the version number.  What is unclear is how much 
interaction is necessary. 

But this argument is beside the point.  The fact is that the text of 2445 
requires a change to the version number whenever  any new property is 
defined:

4.7.4 Version

   Property Name: VERSION

   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.

"Interpret the iCalendar object" does not simply mean being able to parse it.  It means been able to understand 
every property and every parameter. 

Now, if we had a requirement  in 2445 that unknown properties be ignored, 
as in HTTP, then it would be valid to assume that would be safe to add 
properties which did not interact.  Such a requirement would be a promise 
to spec extensions that complaint implementations would be able to cope 
with such new properties.  But, as things stand, the spec makes the 
opposite promise: it promises implementors that any object labeled version 
2.0 can be understood by implementing 2445 and nothing else. 

One more point: Doug has repeatedly asserted that VERSION refers only to 
the version of the format.  However, this assertion cannot be correct, 
because 2445 does not define a format independent of the properties; it 
defines them all in the same ABNF grammar.

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|If at first you don't succeed, don't go skydiving.      |
\========================================================/

---

From: [email-masked]
Date: Fri, 14 Jun 2002 14:47:12 -0400

>    format of the MIME object has not changed.

Thats an apples/oranges comparison.  From RFC 2045, the description of the 
intent of MIME-Version:

    (1)   A MIME-Version header field, which uses a version
          number to declare a message to be conformant with MIME
          and allows mail processing agents to distinguish
          between such messages and those generated by older or
          non-conformant software, which are presumed to lack
          such a field.

From RFC 2445, the description of the intent of VERSION:

4.7.4 Version

   Property Name: VERSION

In the former case, its an issue with conformance to the (MIME) standard. 
In the latter case its an issue of data interpretation.  MIME is a 
framework for encapsulating mail (and other data too).  iCalendar is a 
data format for conveying information.

Had we defined VERSION to be "the highest version number or the minimum 
and maximum range of the iCalendar specification that is required in order 
to parse the iCalendar object." then the comparison would be a valid one.

We have always intended that the format of iCalendar would be A) "self 
contained" and B) adhere to a basic "name *(";" param ) ":" value CRLF" 
format (See Section 4.1 Content Lines) so we in effect have an implicitly 
fixed format (thus we didnt need a MIME-Version to determine how to parse 
the data).  If we change the underlying data format then we would need to 
add a new property that is more equivalent to the MIME-Version (See 
Section 4. MIME-Version Header Field of RFC 2045 for more info there).

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "John Stracke" <[email-masked]>
Date: Mon, 17 Jun 2002 13:56:13 -0400

>As in we can't
>do anything with VERSION other than know it is iCalendar 'format'.

But iCalendar "format" is not defined anywhere.  Only iCalendar is 
defined.  (This is actually one of my major gripes with 2445: it is 
intuitively clear that there is a format, but its definition is 
intermingled with the property definitions.)

/===========================================================\
|John Stracke                    |Principal Engineer        |
[email-masked]   |Incentive Systems, Inc.   |
|http://www.incentivesystems.com |My opinions are my own.   |
|===========================================================|
|Sleep is for wimps--healthy, well-adjusted wimps, but wimps|
|nonetheless.                                               |
\===========================================================/