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

From: [email-masked]
Date: Fri, 14 Jun 2002 14:54:48 -0400

Bob forwarded:
>   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.

Not true. From RFC 2445:

 Section 4.7.4 Version
[Snip]
   Format Definition: The property is defined by the following notation:

     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

Thus if we ever defined an X.Y that was not 'compliant' with A.B then the 
data would look like:

VERSION:X.Y;X.Y

to convey that X.Y was the minimum iCalendar version needed to grok the 
entity.  Unless A.B is between X.Y and X.Y (or Q.R) then there is no 
justification for the claim.  This is exactly why we did a min/max model 
for VERSION!

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: Doug Royer <[email-masked]>
Date: Fri, 14 Jun 2002 13:35:59 -0600

[email-masked] wrote:

> ...to convey that X.Y was the minimum iCalendar version needed to grok
> the entity.  Unless A.B is between X.Y and X.Y (or Q.R) then there is
> no justification for the claim.  This is exactly why we did a
> min/max model for VERSION! 

No, the same problem exists.

If I use:

	VERSION:1.0;2.3

That would imply that I can process All of "1.x", "2.0, and "2.2"
as well as "2.3". That is what VERSION says.

The proposal that I am arguing against is that when we ADD a property
we bump the protocol version. That would mean that if Ski-Cal
implemented "2.1", that everyone that wanted "2.3" properties would have
to implement Ski-Cal.

Is that what you are saying? Or are you saying that each new
property gets it own version number and we have to enumerate
exactly which properties each and every object is compatible with?
As in:

	VERSION:1.0;2.3;just-kidding-I-can't-do-2.1-ski-cal-version
	 ;but-i-can-to-std-foo-property-version ?

If so, lets eliminate CAPABILITY and move the functionallaty
to VERSION by allowing one flag for each property that the
CUA and CS supports.

---

From: [email-masked]
Date: Fri, 14 Jun 2002 17:32:07 -0400

> as well as "2.3". That is what VERSION says.

You misgrok the use of VERSION.  If your CUA groks VERSION 2.2 then it 
would be able to parse and process the entity its parsing.  It says 
nothing about what you as the recipient of the iCalendar can do, its what 
VERSION you need to grok in order to properly (or reasonably) deal with 
the entity you just got.  We never said that just because your CUA groks 
2.2 that a 1.0;2.3 message MUST have the 2.2 properties in it; it must 
have the 2.3 properties in it and any 1.0 or later CUA should be able to 
parse and process it (albeit w/some possible loss of fidelity; see 
REQUEST-STATUS)

So, my new beefy CUA can generate a VERSION:2.0;3.3 METHOD:REQUEST and 
your yet-to-be-upgraded VERSION:2.0 CUA can grok it just as well as Bobs 
VERSION:3.1 CUA.  You just wont be able to avail yourself of the 3.x 
additions to the REQUEST message.  For example, we may have added some 
"Portrait" or "Pronunciation" or "Directions" properties to enhance the 
original REQUEST; your CUA does not need them in order to properly deal 
w/the new REQUEST.

> implemented "2.1", that everyone that wanted "2.3" properties would have

Im with you against reving VERSION unless there is a clear and compelling 
need to (and it cannot be satisified by another means that avoids reving 
VERSION).  However I think that putting it in a different way may help 
ease some of the miscommunications. 

By the arguments Ive heard so far we must either make every new VERSION a 
superset of the prior collection of VERSIONs (at the expense of adding 
cruft) or we must change VERSION so that its a list of versions that the 
client can support (ie: VERSION:3.3,3.1,3.0,2.0 thus excluding the car 
rental cruft in 3.2 that I dont want). What I havent seen is any 
justification for these that make sense (although Ive only been able to 
skim the postings of late due to Real Work(TM) demands).  See my example 
at top and iTIP, Section 3.6 Status Replies (ie: REQUEST-STATUS:3.9 or 
similar)...

Back to the example (with tweaks): Hertz creates some car tracking stuff 
and proposes VERSION:2.3 and Ticketmaster creates some concert venue stuff 
and proposes VERSION:2.4.

While there can be some 'crossover' between a car tracking system and the 
concert venue management system I would tend to view it as highly unlikely 
for the most part.  (Anything is possible in C&S but I involk the 90/10 
rule for how far we should contort before saying "Reality check time!"). 
Still better yet can someone tell me why they think that the VERSION:2.4 
METHOD:REQUEST _must_ have VERSION:2.3 properties in it if it does not 
make sense??

We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but I 
my maxver is 2.3 so Ill expect/assume/require that all my 2.3 properties 
MUST be there."  Thats just bad design!!  No way to spec around poor CUA 
design folks... 

Alternately, if someone needs to change an existing METHOD such that they 
absolutely make backwards interop impossible then they can always set the 
minver to be just that version and then older clients that did the right 
thing should be able to deal w/that (if not, they need to reread iTIP, 
Section 5.1 Partial Implementation and take the right approach by 
returning "Not Support" as the REQUEST-STATUS).

> exactly which properties each and every object is compatible with?

Still have that question??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 14 Jun 2002 16:56:31 -0600

[email-masked] wrote:
> nothing about what you as the recipient of the iCalendar can do, its
> what VERSION you need to grok in order to properly (or reasonably)
> deal with the entity you just got. We never said that just because
> your CUA groks 2.2 that a 1.0;2.3 message MUST have the 2.2 properties
> in it; it must have the 2.3 properties in it and any 1.0 or later CUA
> should be able to parse and process it (albeit w/some possible loss of
> fidelity; see REQUEST-STATUS)

Sure you did, how can I grok SKi-Cal:value if I don't know what
it is? Is this not the same argument that is being used to
bump the version (assuming you agree with that)?
As in -> If we add something, bump the version so that the CUA
knows what it is?

If we tie the properties supported to the version number (add a
property == bump the version), then the version will have no
meaning other than a count of the number or properties (or
property sets) that have been added.

This is the TELNET have/want bug all over again. You can't
tie features supported in an implementation to object version.

The argument seem to be saying that as long as we don't change the
format then we don't have to worry about VERSION because it is not
relevant as the CUA must be able to grok it anyway. As in we can't
do anything with VERSION other than know it is iCalendar 'format'.
Which is why I say it does not need to change. And people can add
all of the properties that they want and I can still grok the object
and never care what the VERSION is as long as I know it is a supported
format (but wait; I can't tell because you are saying that VERSION
does not mean format VERSION) even when I don't know what the
properties mean.

> your yet-to-be-upgraded VERSION:2.0 CUA can grok it just as well as
> Bobs VERSION:3.1 CUA. 

So what would "3.1" mean? Nothing!  It would only mean that
some unknown number of properties have been added to the 
standard. It would have no other meaning.

It would mean that no matter what the VERSION is, I must ignore
it and parse the object. It would mean that I can not tell if I
can parse the object until I try an maybe choke. If you have not
changed the format then 3.1 would only mean it might contain some
stuff, it might not, and it has nothing to do with if I know what
you send me is usable by me. So what is it the version of? Not the
contents, above you say I can't tell what is supported by looking
at the version (And I agree). So what is it the version of? Is it not
then just a counter of the number of properties that have been
registered? What good is that?

> You just wont be able to avail yourself of the
> 3.x additions to the REQUEST message.  For example, we may have added
> some "Portrait" or "Pronunciation" or "Directions" properties to
> enhance the original REQUEST; your CUA does not need them in order to
> properly deal w/the new REQUEST.

I agree, so what does 3.1 tell my parser?

> > The proposal that I am arguing against is that when we ADD a
> > property we bump the protocol version. That would mean that
> > if Ski-Cal implemented "2.1", that everyone that wanted "2.3"
> > properties would have to implement Ski-Cal.
> 
> Im with you against reving VERSION unless there is a clear and
> compelling need to (and it cannot be satisified by another means that
> avoids reving VERSION).  However I think that putting it in a
> different way may help ease some of the miscommunications.

Thanks, I don't see that we have changed iTIP in an incompatible
way. (METHOD is again only iTIP) And that is the ONLY thing that
will be effected by CAP changes. There is NO production CAP-CUA now,
so nothing between any CS and any CAP-CUA will break. The ONLY thing
that is going to be added (as Bernard pointed out) is that TARGET
will be added in the protocol between the CUA and the CS, that in
no way effects iMIP. And if I sent you an iMIP message with TARGET
in it, will it break your CUA - I'll bet not.

> By the arguments Ive heard so far we must either make every new 
> VERSION a superset of the prior collection of VERSIONs ...
> .. or we must change VERSION so that its a list of versions that
> the client can support ...
> 
> Back to the example (with tweaks): Hertz creates some car tracking
> stuff and proposes VERSION:2.3 and Ticketmaster creates some concert
> venue stuff and proposes VERSION:2.4.
> 
> While there can be some 'crossover' between a car tracking system and
> the concert venue management system I would tend to view it as highly
> unlikely for the most part. ...
> 
> We should _NOT_ be making CUAs that go "Hmm, I see VERSION:2.0,2.4 but
> I my maxver is 2.3 so Ill expect/assume/require that all my 2.3
> properties MUST be there."  Thats just bad design!!  No way to spec
> around poor CUA design folks...

I agree.

> Alternately, if someone needs to change an existing METHOD such that
> they absolutely make backwards interop impossible then they can always
> set the minver to be just that version and then older clients that did
> the right thing should be able to deal w/that (if not, they need to
> reread iTIP, Section 5.1 Partial Implementation and take the right
> approach by returning "Not Support" as the REQUEST-STATUS).

I agree.

> Still have that question??

I think we agree. There is no reason to bump the version as
nothing between the CUA and a CS will effect iMIP. And only
iMIP implementations will be effected if we (as in your example)
change METHOD (which we will not).

-Doug

---

From: [email-masked]
Date: Mon, 17 Jun 2002 14:27:21 -0400

Doug wrote on 06/14/2002 06:56:31 PM:
> it is? 

No we didnt.  Where in the RFC did we state that?

You can _parse_ it as it must follow the format rules (see Section 4.1 
again).  _Interpreting_ its full meaning is something that only a VERSION 
2.1 (or whatever) client can do.  That does NOT meant that an older client 
cannot necessarily grok it. 

A METHOD:REQUEST has straighforward semantic.  You may not grok the 
meaning of the newer 2.1 properties but you can still make a reasonable 
response to the REQUEST AND you can convey back to the Organizer that you 
may not have grok'd it w/the same fidelity as a newer CUA. 

Section 5 Application Protocol Fallbacks of iTIP discusses dealing with 
new METHODs and similar logic should also apply to VERSION (although we 
never expresslly put it into any RFC text, we glanced over it when we 
defined minver and maxver in iCalendar).

>        Is this not the same argument that is being used to

Maybe its me but I dont see that this is necessarily a problem as long as 
the additions do no cause a problem for older clients.  Thats part of why 
we put in maxver and minver in the first place!  If the changes are such 
that they are not backwards compatable then the minver gets set 
accordingly (OR a new METHOD is created!).  Either way the receiving CUA 
should be able to deal w/it if it was coded properly.

It is the job of the WG to make sure that any changes/additions in the 
future do not cause problems and that the changes/additions are done "the 
right way" and that harmony is maintained.

> property sets) that have been added.

Just what do you think the use/intent of minver and maxver is?  They 
delimit the set of CUAs that can properly (or reasonbly) grok the 
iCalendar stream.  If some addition/change in the future decided to mangle 
a previously defined METHOD requires that a minver of something other than 
"2.0" be sent then Id have to question its change instead of defining a 
new METHOD value instead.  Still it could happen (ie: in order to fix a 
serious problem that was overlooked before)...

> do anything with VERSION other than know it is iCalendar 'format'.

No, no, no.  Perhaps its the term 'format' that makes me hop up an down so 
Ill try to restate this as clearly as I can:

VERSION does not specify the parsing format of the data, it specifies the 
(minimum and) maximum versions of a CUA that are required to _understand_ 
the parsed content. 

The parsing/content 'format' is defined in Section 4.1 and if that changes 
then we need to define a different way to detect and deal with it since it 
would be potentially impossible for an older CUA to even parse the new 
format to discover that it did not know how to even parse it (let alone 
understand it).  In this case a new MIME type/subtype would probably be in 
order.

If we change the semantics of a METHOD thats already defined in such a way 
that only newer CUAs can grok it (grok != parse; grok == understand) then 
that is when a VERSION with a minval higher than the current 2.0 would be 
necessary.  Adding new 'features' does not (NOR should it!!) change the 
semantics of an already defined METHOD. 

>       (but wait; I can't tell because you are saying that VERSION

VERSION does not and never has meant "format" VERSION.  Dont know where 
that concept came from.

From 2445:

   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.

(Emphasis mine).  That seems pretty clear to me.  Where does it mislead 
one to think its a format issue?

> standard. It would have no other meaning.

They are not "unknown"; they would have to be codified in some RFC. 

Just because your already written/shipping CUA does not know what they are 
does not mean that VERSION has no meaning.  It tells your CUA that there 
are properties in the iCalendar that it may not know how to interpret but 
the minver indicates that you can still properly interpret the METHOD 
(albeit w/o benefit of the newer properties).   My VERSION 2.0;2.0 CUA may 
not understand the VEHICLE;TYPE=CAR:MID-SIZE in the new Hertz VERSION:2.2 
REQUEST but its not necessary for me to in order to accept the REQUEST or 
COUNTER it.  It may even be smart enough to put in a REQUEST-STATUS value 
to indicate that some fallback was taken for the entry.

If your CUA got a VERSION:3.0;3.5 REQUEST and its just VERSION:2.0 then it 
should do the correct thing and send back a REPLY with 
"REQUEST-STATUS:3.9;Unsupported version.;I only understand a minver 2.0 
REQUEST" (See 3.6 Status Replies of iTIP). 

> can parse the object until I try an maybe choke. 

Again, VERSION does not and never has meant "format" VERSION.    See 
above.

Also, since VERSION and METHOD appear in the stream before the other 
container subcomponents (ie: VEVENT) then  you only have to parse some of 
the stream to know that you wont be able to understand the METHOD (or the 
VERSION).  You will still have to find some way to scan over or parse over 
the entries since more than 1 iCalendar stream may exist in the data 
stream body as we defined it (See Section 4.4 iCalendar Object).  However 
parsing is NOT the concern as long as the rules in Section 4.1 are adhered 
to; its only interpretation of whats parsed.

>                                                  If you have not
> you send me is usable by me. 

NOT a _format_ change, an interpretation change.  Ill keep pointing this 
out as long as it takes...

> I agree, so what does 3.1 tell my parser?

Nothing.  It tells your processing engine something though!

> > around poor CUA design folks...

We usually do.  We just have to overcome our initial communication issues.

Bruce

---

From: David Nusbaum <[email-masked]>
Date: Mon, 17 Jun 2002 21:04:21 -0500

I have been working on a CUA and found the meaning of VERSION to be 
confusing despite the description of the property contained in RFC2445. 
My confusion stems from the fact that the general property parameter, 
property, and component definitions all include support for "some other 
IANA registered  (parameter, property, or component)". My assumption, 
perhaps incorrect, is that I would have to be able to parse any 
iCalendar content following that format defined in RFC2445 and that I 
MUST be able to interpret any of the objects defined within the RFC. 
This seemed to make sense because some components and properties are 
core to calendaring and scheduling, such as time zone related elements, 
while others elements may be specific to one specific vertical such as 
the car reservation system.

Regardless of what the VERSION description says today, why do we support 
other IANA registered names if they would need to be added to the RFC 
and the version number incremented? I also think it practical to allow 
for vertical extensions of the CORE object specification without 
updating the version number and that incrementing the version be 
reserved for changes to the CORE specification (horizontal).

This is my first update to the mailing list, so don't hit me too hard. I 
just wanted to offer the opinion of somebody who has been writing to the 
specification and how it had been interpreted along the way.

On Monday, June 17, 2002, at 01:27 PM, [email-masked] wrote:

> again).  _Interpreting_ its full meaning is something that only a 
> VERSION 2.1 (or whatever) client can do.  That does NOT meant that an 
> older client cannot necessarily grok it.  
>
> response to the REQUEST AND you can convey back to the Organizer that 
> you may not have grok'd it w/the same fidelity as a newer CUA.  
>
> Maybe its me but I dont see that this is necessarily a problem as long 
> as the additions do no cause a problem for older clients.  Thats part 
> of why we put in maxver and minver in the first place!  If the changes 
> are such that they are not backwards compatable then the minver gets 
> set accordingly (OR a new METHOD is created!).  Either way the 
> receiving CUA should be able to deal w/it if it was coded properly.
>
> future do not cause problems and that the changes/additions are done 
> "the right way" and that harmony is maintained.
>
> iCalendar stream.  If some addition/change in the future decided to 
> mangle a previously defined METHOD requires that a minver of something 
> other than "2.0" be sent then Id have to question its change instead of 
> defining a new METHOD value instead.  Still it could happen (ie: in 
> order to fix a serious problem that was overlooked before)...
>
> No, no, no.  Perhaps its the term 'format' that makes me hop up an down 
> so Ill try to restate this as clearly as I can:
>
> VERSION does not specify the parsing format of the data, it specifies 
> the (minimum and) maximum versions of a CUA that are required to 
> _understand_ the parsed content.  
>
> The parsing/content 'format' is defined in Section 4.1 and if that 
> changes then we need to define a different way to detect and deal with 
> it since it would be potentially impossible for an older CUA to even 
> parse the new format to discover that it did not know how to even parse 
> it (let alone understand it).  In this case a new MIME type/subtype 
> would probably be in order.
>
> If we change the semantics of a METHOD thats already defined in such a 
> way that only newer CUAs can grok it (grok != parse; grok == 
> understand) then that is when a VERSION with a minval higher than the 
> current 2.0 would be necessary.  Adding new 'features' does not (NOR 
> should it!!) change the semantics of an already defined METHOD.  
>
> Just because your already written/shipping CUA does not know what they 
> are does not mean that VERSION has no meaning.  It tells your CUA that 
> there are properties in the iCalendar that it may not know how to 
> interpret but the minver indicates that you can still properly 
> interpret the METHOD (albeit w/o benefit of the newer properties).   My 
> VERSION 2.0;2.0 CUA may not understand the VEHICLE;TYPE=CAR:MID-SIZE in 
> the new Hertz VERSION:2.2 REQUEST but its not necessary for me to in 
> order to accept the REQUEST or COUNTER it.  It may even be smart enough 
> to put in a REQUEST-STATUS value to indicate that some fallback was 
> taken for the entry.
>
> If your CUA got a VERSION:3.0;3.5 REQUEST and its just VERSION:2.0 then 
> it should do the correct thing and send back a REPLY with 
> container subcomponents (ie: VEVENT) then  you only have to parse some 
> of the stream to know that you wont be able to understand the METHOD 
> (or the VERSION).  You will still have to find some way to scan over or 
> parse over the entries since more than 1 iCalendar stream may exist in 
> the data stream body as we defined it (See Section 4.4 iCalendar 
> Object).  However parsing is NOT the concern as long as the rules in 
> Section 4.1 are adhered to; its only interpretation of whats parsed.
>
> >                                                  If you have not
> NOT a _format_ change, an interpretation change.  Ill keep pointing 
> this out as long as it takes...
>

---

From: [email-masked]
Date: Thu, 20 Jun 2002 16:57:56 -0400

David replied on 06/17/2002 10:04:21 PM:

>                                                      My assumption, 

Fairly accurate.  You should be able to parse ANYTHING that conforms to 
RFC 2445 but you may not be able to interpret it for some reason (probably 
architectural in nature but not always). 

For example, Outlook can parse an iTIP REQUESTs that has RDATEs in it and 
it wont complain but they drop RDATEs on the floor and the invitation is 
not flagged as being repeating.  The reason being that they internal 
design is more pattern centric and list centric.  Or your application may 
not have the concept of a Journal it for whatever reason so you probably 
wont write any code to actually process the VJOURNAL that you can easily 
parse.

> and the version number incremented? 

This is NOT accurate.  Its possible for anyone (ie: SKiCAL) to draft up 
some new properties to add to the current standard without needing to 
revise/increment VERSION.  That however does not preclude reving of 
VERSION if some properties are added if there is a sufficient or 
compelling need to do so.

From the fragments Ive caught so far I havent seen any such need for doing 
that just yet but perhaps its there.  So far Doug and I have gone back and 
forth (while being on the same side of the fence I suspect) but no 
clarification from the "Pro revising" camp yet...

> This is my first update to the mailing list, so don't hit me too hard. 

We stopped flaying former lurkers a while ago... ;^)

Bruce