Subject: RE: RECURRENCE-ID discussion

From: Satya Vempati <[email-masked]>
Date: Mon, 04 Aug 2003 12:19:09 -0700

Unfortunately the RFCs are not consistent. You can quote one part of the
RFC which agrees with your position, and others can quote the other parts
that seem to buttress theirs.
-----------------
For example, (RFC 2446, Section 3.7.1)
 
If the "Organizer" wishes to
change the "DTSTART", the original "DTSTART" value is used for
"RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
reflect the change. Note that after the change has occurred, the
"RECURRENCE-ID" has changed to the new "DTSTART" value.
-------------------
 
Additionally, portions of the document are not very clear and open to
multiple interpretations:
 
"When the definition of the recurrence set for a calendar component
changes...the "RECURRENCE-ID" for a given recurrence instance might also
change" 
 
What is meant by the "definition of a recurrece set?" One can also argue
that the recurrence set changes whenever something is added to or deleted
from it.
 
Because of such inconsistencies, if we clearly understand the intent of
the original authors and agree on it, the minor textual inconsistencies
could be resolved amicably.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 04, 2003 8:37 AM
To: [email-masked]
Subject: Re: RECURRENCE-ID discussion

Satya asked on 07/31/2003 06:43:38 PM:
> Is there an update on when the iCal authors will post their thinking on
> the subject?

I had hoped that reading the RFCs and searching the archives would have
put this to rest once and for all but perhaps not for some.  So let me
take some time to review both the RFC text and to technically analyze why
the iCalendar specified a fixed RECURRENCE-ID.  This is going to be a
somewhat long posting in order to cover both iCalendar, iTIP and the
claims that purportedly define a changing RECURRENCE-ID model. 

First, lets start with a review of the RFCs.  The 2 RFCs in question are
2445 (iCalendar) and 2446 (iTIP).  iCalendars role is to define the
various properties and property parameters as well as specify their
behaviour / intent.  iTIPs role is to give the iCalendar properties
semantic meaning that all implementations can follow to interop.  So lets
start with reviewing the actual definition of RECURRENCE-ID (Section
4.8.4.4 Recurrence ID). 

   Description: The full range of calendar components specified by a
  recurrence set is referenced by referring to just the "UID" property
  value corresponding to the calendar component. The "RECURRENCE-ID"
  property allows the reference to an individual instance within the
  recurrence set.

[Snip]

  The date/time value is set to the time when the original recurrence
  instance would occur; meaning that if the intent is to change a
  Friday meeting to Thursday, the date/time is still set to the
  original Friday meeting.

  The "RECURRENCE-ID" property is used in conjunction with the "UID"
  and "SEQUENCE" property to identify a particular instance of a
  recurring event, to-do or journal. For a given pair of "UID" and
  "SEQUENCE" property values, the "RECURRENCE-ID" value for a
  recurrence instance is fixed. When the definition of the recurrence
  set for a calendar component changes, and hence the "SEQUENCE"
  property value changes, the "RECURRENCE-ID" for a given recurrence
  instance might also change. [Snip]

Some folks seem to blindly ignore the 2nd (above, 3rd in the actual RFC)
paragraph which clearly and unequivocally says that when a reschedule
takes place the RECURRENCE-ID value "is still set to the original" value! 
This of course flat out defeats the claim that "RECURRENCE-ID changes on
each reschedule" as some have claimed so its easy to see why overlooking
it happens. 

In looking at the oft cited last paragraph you will find that the key
phrase is "When the definition of the recurrence set for a calendar
component changes...the "RECURRENCE-ID" for a given recurrence instance
might also change".  The important bit that seems to be misread is
"definition of the recurrence set"; it does not say "definition of the
recurrence _instance_".   So its likely that this is partly to blame for
some misinterpreting the description to mean "Whenever the instance is
rescheduled, the recurrence instance also changes"  This does make a
couple minor but not insignficant changes to the phrasing such as changing
"might also change" into "always changes" but these changes are best
ignored if you want to change the model. 

Of course these changes would conflict with the entire paragraph before it
so some would just ignore it in favor of their reinterpreatation of the
prose.  However it must be noted that iCalendar clearly proscribes a
"fixed" RECURRENCE-ID in at least 2 places.   

In addition Doug has claimed that "'original' means currently booked
version" but thats nowhere near the meaning of the word original.  Instead
of arguing a common sense meaning Ill instead defer to Merriam-Webster who
define it as: 

Main Entry: 2original
Function: adjective
Date: 14th century
1 : of, relating to, or constituting an origin or beginning : INITIAL <the
original part of the house>
2 a : not secondary, derivative, or imitative b : being the first instance
or source from which a copy, reproduction, or translation is or can be
made 

So "original" means the the same as the "initial" value, NOT the "latest"
or "most recent".  This definition matches the paragraph in describing how
RECURRENCE-ID stayed at the Friday date/time.  The reason that a fixed
RECURRENCE-ID was specified over a varying one will become evident as we
move into analyzing iTIP so lets do that now. 

iTIP defines its role in relation to iCalendar as: 

  iTIP complements the iCalendar object specification by adding
  semantics for group scheduling methods commonly available in current
  calendar systems. 

so its role is NOT to impart (or modify) any defintion to the iCalendar
properties or property parameters, thats the function of iCalendar.  The
semantics for "group scheduling methods" are done in the various iTIP
methods or messages.  iTIP messages can be sent over any kind of media or
using assorted methods so the protocol had to first define some guidelines
to apply to all messages to properly deal with missequencing  on the
receiving end.  That is done in Section 2.1.5 Message Sequencing, before
any direct discussion of individual messages was done.  In Section  2.1.5
Message Sequencing we see: 

   1.  The primary key for referencing a particular iCalendar component
      is the "UID" property value. To reference an instance of a
      recurring component, the primary key is composed of the "UID" and
      the "RECURRENCE-ID" properties.

  2.  The secondary key for referencing a component is the "SEQUENCE"
      property value.  For components where the "UID" is the same, the
      component with the highest numeric value for the "SEQUENCE"
      property obsoletes all other revisions of the component with
      lower values. 

Thus for repeating instances the primary key value used to find the
instance the message refers to is the UID / RECURRENCE-ID pair.  Once this
pair is used to find the instance in question the SEQUENCE property can be
used to determine if the message is newer or older than the one the
recipient has.  Or in iTIP terms, tell if the message has already been
obsoleted or if it should obsolete the recipients copy.  Nothing here
claims that RECURRENCE-ID changes on each reschedule and in order to be
fault tolerant and easily recoverable RECURRENCE-ID should not change
(iCalendar prose not withstanding).  This can be seen in the prose found
in other sections in iTIP such as Sections 3.2.2 REQUEST, 3.2.2.1
Rescheduling an Event, 3.2.2.2 Updating or Reconfirmation of an Event, or
even the often misquoted Section 4.7.2 Bad RECURRENCE-ID. 

Section 3 of iTIP is where the actual protocol definitions happen.  Its
where iTIP defines what a meeting request or response look like, etc. 
Section 4 of iTIP is where the authors provided assorted examples of
actual iTIP messages from Section 3.  As such its merely the demonstrative
part of the iTIP RFC and does not carry the same weight.  The authors were
always grumbling about the inclusion of examples ("If we put in an example
of X then everyone will code to that and not to the text" as they so often
lamented in meetings, emails and here on the list) and now this has come
back to haunt us based on a misreading of iCalendar and a line or two in
the examples section of iTIP (not even in the defintion section of iTIP).
In any case, lets continue the analysis promised. 

iTIP Section 3.2.2 REQUEST in part reads: 

   The "UID" and "SEQUENCE" properties are used to distinguish the
  various uses of the "REQUEST" method. If the "UID" property value in
  the "REQUEST" is not found on the recipient's calendar, then the
  "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
  property value is found on the recipient's calendar, then the
  "REQUEST" is for a rescheduling, an update, or a reconfirm of the
  "VEVENT" calendar component. 

and if you apply the rules from Section 2.1.5 to this you should get that
if the UID/RECURRENCE-ID are not found in the recipients calendar then its
a new REQUEST, otherwise its an update.  Implicitly this concurs with
iCalendar and Section 2.1.5 because if the RECURRENCE-ID changed and one
or more iTIP REQUESTs were missed (or delayed!) then the recipient has NO
way to properly perform this match and thus they would treat the REQUEST
as a new invitation rather than a reschedule. 

In case that was not clear enough for some Ill try to make it as clear as
I can: If I send you a REQUEST for a particular UID and RECURRENCE-ID that
you do not have then you are to treat it as a new invitation by the
definition of REQUEST.  So you want the UID / RECURRENCE-ID values to
never change from that point on or else you will think you got _another_
new invitation rather than a rescheduling of the one you already have! 

If RECURRENCE-ID did change on each reschedule (iCalendar prohibitions
aside) then you have NO way to distinguish between a new invitation and
the case where you missed one or more reschedules.  This means that for
the model where RECURRENCE-ID changes on each reschedule, any single
delayed or missequenced REQUEST can _only_ be recovered by rescying up
_all_instances_ of the repeat set!  In addition if the messages were just
missequenced this results in _tons_ of extra wasted workflow thrashing.   

Lets compare the iCalendar defined fixed RECURRENCE-ID model to the
changing RECURRENCE-ID model of some and see how they deal with
missequenced messages.  The scenario is I invite you to an instance of a
repeating meeting.  After the initial invitation I reschedule it two times
to accomodate other invitees.  So for simplicity in references Ill refer
to the initial invitation as SEQUENCE:0 and the two reschedules as
SEQUENCE:1 and SEQUENCE:2 respectively.  Because of network/server issues
you recieve them in the order of SEQUENCE:0 then SEQUENCE:2 and then
SEQUENCE:1; a not uncommon case when using email (aka iMIP). 

First the fixed RECURRENCE-ID model analysis: 

When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and
3.2.2 and determine that this is a new meeting invitation which you take
some action on to get it onto your calendar.   

You then receive SEQUENCE:2 and you can match the UID / RECURRENCE-ID
values and determine that the message is newer and that it obsoletes your
current copy.  You may notice that its SEQUENCE value is more than 1
different but since the higher valued SEQUENCE "obsoletes all other
revisions of the component withlower values" it is not an issue that you
did not see SEQUENCE:1 (yet).  You can simply take action on it and send
back a REPLY with the correct UID / RECURRENCE-ID / SEQUENCE:3 info on it
and we are in sync.   

You later receive the SEQUENCE:1 REQUEST.  You apply Section 2.1.5 and
determine that your version is newer and as such this REQUEST is obsoleted
and should be ignored.  No further action is required by you since you are
already in sync with me. 

Now for the changing RECURRENCE-ID model analysis: 

When you receive the SEQUENCE:0 invitation you apply Section 2.1.5 and
3.2.2 and determine that this is a new meeting invitation which you take
some action on to get it onto your calendar. 

You then receive SEQUENCE:2 and you can NOT match the UID / RECURRENCE-ID
values in your calendar so you determine that "something has gone wrong"
(to borrow from the misquoted Section 4.7.2).  You MUST therefore take NO
action on the REQUEST since you cannot match the instance to one you
currently have.  You can ONLY send a REFRESH message back to me with just
the UID and NO RECURRENCE-ID.  This will cause me to generate another
REQUEST to you "with the latest description and version of the event" (per
iTIP Section 3.2.6 REFRESH).  So I send you another REQUEST with the
latest RECURRENCE-ID at SEQUENCE:2 which happens to _exactly_ match the
REQUEST you just tossed out.  If you receive this new REQUEST _before_ you
get the missequenced SEQUENCE:1 REQUEST then you can _only_ repeat this
loop indefinitely without recovery! 

In the interim the SEQUENCE:1 REQUEST arrives and you are able to apply
Section 2.1.5 rules and find the correct UID / RECURRENCE-ID instance and
determine that the REQUEST obsoletes the SEQUENCE:0 one you have.  Now you
can apply the currently obsolete SEQUENCE:1 change to your SEQUENCE:0
instance and send back a REPLY to me.  I would of course detect that the
UID / RECURRENCE-ID / SEQUENCE:1 REPLY is for an old copy (by applying
2.1.5) and thus I would have to ignore it and send you yet another REQUEST
at SEQUENCE:2.  Now that you are at SEQUENCE:1 you can safely match the
UID / RECURRENCE-ID values and re-respond at SEQUENCE:3. 

This model has lots of drawbacks (hence why we long ago opt'd for a
"fixed" RECURRENCE-ID model).  They include: 

1: Any missequencing of iTIP messages cannot be recovered on a single
instance case.  You MUST resync up ALL instances in the set, not just the
instance in question.  This means potentially LOTS of extra wasted
workflow messaging.  All just because of _1_ missquenced REQUEST (or REPLY
if you invert the picture for my side as Organizer). 

2: If the problem is NOT a missequencing of REQUESTs but rather recovery
from a lost REQUEST (ie: an interim copy got lost in a server crash, disk
failure, admin purge, etc) then it is not possible to recover when just
one or some instances are involved since RECURRENCE-IDs are always
involved in the REQUEST/REPLY(/COUNTER/...) messages when you correctly
apply the restriction tables from iTIP.  REQUEST clearly says: 

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                           recurring calendar component.  Otherwise it
                           MUST NOT be present.

so any initial or subsequent REQUESTs MUST have a RECURRENCE-ID on them
when referring to a particular instance.  Had you not received the
SEQUENCE:1 REQUEST at some point you would be infinitely stuck in the
REFRESH/REQUEST loop above. 

3: Since each instance can be reschedule independently of its siblings, it
can be shown that if the RECURRENCE-ID changes it takes just 5 steps to
misidentify the correct instance in question in a REPLY (on the Organizers
side).  For the steps, go check the archives for the 2 times its been
pointed out. 

The same kind of fault _intolerant_ behaviour can be seen for other cases
in iTIP if you lay out the scenarios (and ignore iCalendar too).   

Now lets visit that misquoted iTIP Examples Section 4.7.2 Bad
RECURRENCE-ID lest some claim we are ignoring their citations for
justifying a changing RECURRENCE-ID model.  iTIP Section 4.7.2 Bad
RECURRENCE-ID is intended as an example section on how to deal with
problems matching UID / RECURRENCE-ID / SEQUENCE.  It says "there are
three cases in which an instance cannot be found." and describes them as: 

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
      been found but the "SEQUENCE" number in the calendar store does
      not match that of the ITIP message.

  2.  The component with the referenced "UID" has been found, the
      "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
      found.

  3.  The "UID" and "SEQUENCE" numbers are found but the CUA does not
      support recurrences. 

Case 3 is not germane and will be ignored for this analysis. 

Case 1 is dealt with in: 

   In case (1), two things can happen. If the "SEQUENCE" number of the
  "Attendee's" instance is larger than that in the "Organizer's"
  message then the "Attendee" is receiving an out-of-sequence message
  and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
  instance is smaller, then the "Organizer" is sending out a newer
  version of the component and the "Attendee's" version needs to be
  updated. Since one or more updates have been missed, the "Attendee"
  SHOULD send a "REFRESH" message to the "Organizer" to get an updated
  version of the event. 

Here SEQUENCE is described as "smaller" and "larger" rather than "highest"
and "lower" found in Section 2.1.5 but the implicit behaviour still
matches.  In order to match a UID / RECURRENCE-ID / SEQUENCE combo where
the UID and RECURRENCE-ID  values are "found" but the SEQUENCE value is
"smaller" or "larger" then it should be intuitive that UID and
RECURRENCE-ID do not change.  Otherwise they could not be found to
mismatch SEQUENCE!  So this description matches the behaviour under
Section 2.1.5. 

The last ine about "one or more updates have been missed" has been misused
as justification for the recipient (ie: you in the above examples) having
to send a REFRESH to the Organizer (ie: me...).  However 2 things need to
be noted here: 

A: The case is described as the one where UID / RECURRENCE-ID matched but
SEQUENCE did NOT and 
B: The text says that the recipient "SHOULD" send a REFRESH, not "MUST". 

Now if you apply normal logic to the analysis you should see that bullet A
above cannot be done in a changing RECURRENCE-ID model since the
RECURRENCE-ID value changed!   However this is incongruence needs to be
overlooked to use Section 4.7.2 as justifying a changing RECURRENCE-ID
model.   

Also, bullet B does not say "MUST" because it is NOT necessary! The
larger/higher SEQUENCE version obsoletes all smaller/lower SEQUENCE
versions and as such a REFRESH is not really necessary (except in a
changing RECURRENCE-ID model). 

Case 2 is dealt with in: 

   In case (2), something has gone wrong.  Both the "Organizer" and the
  "Attendee" should have the same instances, but the "Attendee" does
  not have the referenced instance.  In this case the "Attendee" SHOULD
  send a "REFRESH" to the "Organizer" to get an updated version of the
  event. 

Aha, we now have problem with the fixed RECURRENCE-ID model or do we? 
Actually we do not.  If you receive a REQUEST for an unknown UID /
RECURRENCE-ID pair then if you apply the text from Section 3.2.2 REQUEST
correctly you simply view the REQUEST as a new invitation.  In this case
to a new instance you did not know about before.  No problem here.  Simply
treat it as what it is, a REQUEST to another instance and workflow
functions as before. 

Ah, we do have a problem though if we used a changing RECURRENCE-ID model.
 The "something has gone wrong" is that the message was missequenced. 
Gee, something as simple as that means there is a problem??  Thats the
sign of a poor model (and one of the reasons the WG opt'd for the fixed
RECURRENCE-ID model) because to recover means lots of extraneous iTIP
messages in both directions. 

In addition it should be noted that not all Attendees are invited to all
instances so the 2nd line is a bit misleading.  If I want to add you to an
instance (or subset of instances) of a repeating meeting Im organzing then
obviously you wont have the "the same instances".  I suspect that this is
an artifact of editing because we do not expect / require that all
attendees be invited to all instances. 

Also, this example also uses "SHOULD" instead of "MUST".  Had the
RECURRENCE-ID model been one of a changing RECURRENCE-ID value then the it
would have to say "MUST" in order to attempt to resync the invitee with
the Organzier.  Some folks have seized on this Case as justification for a
changing RECURRENCE-ID model.  However they have modified it in the
process by changing the "SHOULD" into a "MUST" and ignoring all of the
other sections of iTIP that contradict them. 

Ok by now it should be clear that iCalendar and iTIP specify and use a
fixed RECURRENCE-ID model.  So the next thing to consider is the Working
Group history on this subject and looking at how its been implemented by
folks. 

As previously noted in recent discussions the question of a fixed or
changing RECURRENCE-ID model was raised at least as far back as July 1999.
 The concensus then was that RECURRENCE-ID was fixed (essentially for the
reasons demonstrated above).  I invite anyone who still thinks that
RECURRENCE-ID should changing on a reschedule to go reread the archives
and search for yourself. 

Finally, lets take a look at how at least the RFC authors have implemented
RECURRENCE-ID in their various products.  Surely they would have
implemented it the way the RFC intended it, yes?!   

If you take a look at Microsofts Outlook 98 (and higher) and Exchange you
will find that all implementations (done by different development teams)
all implement a fixed RECURRENCE-ID.  You need to be configured for
Internet Mode to get iCalendar support (or you can use the Exchange server
if you configure it for iCalendar).  In any case they have a fixed
RECURRENCE-ID model. 

If you take a look at Lotus Organizer, Lotus Notes and the eSeries
offerings you will find that all of them (also done by different
development teams) implement a fixed RECURRENCE-ID. 

I do not have current access to Evolution or to Netscapes offerings but in
looking over my notes from CalConnects I see that we did not have any
interoperability issues with anyone participating so they must have also
implemented fixed RECURRENCE-IDs. 

Ok, to recap this (assuming you are still with me to here): 

1: iCalendar clearly and unequivocally says that on a reschedule
RECURRENCE-ID does not change; it keeps the "original" value. 
RECURRENCE-ID "might also change" only in the case "When the definition of
the recurrence _set_ for a calendar component changes" and not "When the
definition of the recurrence _instance_ for a calendar component changes" 
2: iTIP prose specifying Message Sequencing and messages themselves do not
disagree with iCalendar. 
3: iCalendar defines the RECURRENCE-ID property; iTIP defines its
semantics.  As such iTIP cannot redefine RECURRENCE-ID, that is not its
job/function. 
4: The changing or delta RECURRENCE-ID model has been demonstrated as
being fault intolerant and flawed in dealing with sequencing and recovery
of lost messages. 
5: The WG already discussed this long ago and confirmed that RECURRENCE-ID
did not change on a reschedule. 
6: ALL the implementations from all the authors use a fixed RECURRENCE-ID.
 So either they ALL misunderstood their own model or they properly
implemented it based on iCalendar and iTIP. 

RECURRENCE-ID is akin to "the UID for a particular instance" and as such
it needs to have the similar behavior as the UID property.  Otherwise iTIP
workflow gets lots more complicated and verbose and so does a CUAs design.

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: [email-masked]
Date: Tue, 5 Aug 2003 12:14:11 -0400

> that seem to buttress theirs.

2 things that are being forgotten so Ill repeat 'em again:

1: This exact citation was the one Dan Hickman asked about back in July 
1999 and the WG discussed.  We agreed that it was in error.  Given that of 
250+ pages of RFCs and you find 2 sentences that contradict the rest is 
not an overwhelming contradiction.  We had 5+ authors working on different 
parts of 3 RFCs so 2 lines out of 250+ is not that significant.  There are 
no other conflicting citations that Ive seen so far and ALL the others 
citations support each other.

2: The lines you cite is part of iTIP.  iTIP provides the semantics for 
the iCalendar defined properties.  iTIP cannot change the iCalendar 
defintion of the property or its behaviour; thats NOT its function.

> that the recurrence set changes whenever something is added to or 
deleted

A: What about the paragraph you forgot to cite?  The one that expressly 
says on a reschedule of an instance the RECURRNECE-ID stays at its 
original value?  Is that unclear or open to multiple interpretations?

B: We have _always_ been discussing the case of rescheduling instances, at 
least thats always been the scenario Ive used and focused on (and Ive 
always tried to keep others from mixing the scenarios).  Changing the 
definition of the recurrence set by doing an adding or removing instances 
is exactly what that sentence was about.  However rescheduling an instance 
is doing NEITHER!  And as you seem to agree, adding or removing/deleting 
instances clearly says that the RECURRENCE-ID value "might also change". 
For example, if I add a new non-conflicting instance to the existing set 
then there is no need for my RECURRENCE-ID to change obviously. 

Do NOT fall into Dougs misinterpreation that rescheduling an instance is 
the same as changing the repeat instance set defintion, its not.

> Because of such inconsistencies

1 already WG discussed and declared bad iTIP bit from at least 1999 is not 
anything new or a major inconsistancy in the RFCs.  The other phrase you 
mention is not an inconsistancy in my reading; the only problem is how 
some can misread "the definition of the recurrence set" as being "the 
definition of the recurrence instance" but thats not the RFCs fault nor is 
it an inconsistancy. 

It sounds like you only need a short note from the authors to this effect 
and you'd then accept the fixed RECURRENCE-ID model.  Would that be 
accurate?

>                                  , if we clearly understand the intent 
of
> could be resolved amicably.

I always try to be as polite but sometimes frustration seeps in.  I have 
showed:

1: Multiple supporting citations in both iCalendar and iTIP that describe 
and support a fixed RECURRENCE-ID model
2: Why the fixed RECURRENCE-ID model works well and is quite fault 
tolerant. 
3: That the RFCs overwhelmingly describe and implicitly use a fixed 
RECURRENCE-ID model. 
4: Several of the major flaws inherent in a changing RECURRENCE-ID model. 

Yet some folks still persist in saying that 1-2 lines in iTIP justify that 
iCalendar/iTIP uses a delta RECURRENCE-ID model.  Wouldnt you get a littel 
frustrated too after several weeks of this?

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: Tue, 05 Aug 2003 11:40:43 -0600

[email-masked] wrote:
> 1999 and the WG discussed.  We agreed that it was in error.

No, some think it is in error, including you. That does not make
2445 incorrect. It makes it a point to debate.

>  Given that 
> of 250+ pages of RFCs and you find 2 sentences that contradict the rest 
> is not an overwhelming contradiction.  We had 5+ authors working on 
> different parts of 3 RFCs so 2 lines out of 250+ is not that 
> significant.  There are no other conflicting citations that Ive seen so 
> far and ALL the others citations support each other.

Except the ones you delete from posts and never reply to? Below
in your post you declare that there is contention, here you claim
that you have not seen any? Please explain.

> defintion of the property or its behaviour; thats NOT its function.

Yes it can, that is part of the IETF process. That is *this* debate
and we *are* discussing iCAL changes not only on this topic but in non
controversial ways discussing iCAL-rev-next.

Some including me say that they are all consistent as original
means the original one you are changing from, not sequence:0.

> original value?  Is that unclear or open to multiple interpretations?

No, and you have never addressed those, you just declare that one
paragraph overrides all others rather than admit that it means
the original one being changed from and not the original sequence:0
instance.

> B: We have _always_ been discussing the case of rescheduling instances, 
> at least thats always been the scenario Ive used and focused on (and Ive 
> definition of the recurrence set by doing an adding or removing 
> instances is exactly what that sentence was about.  However rescheduling 
> an instance is doing NEITHER!  And as you seem to agree, adding or 
> removing/deleting  instances clearly says that the RECURRENCE-ID value 
> "might also change". For example, if I add a new non-conflicting
> instance to the existing set then there is no need for my RECURRENCE-ID 
> to change obviously.  
> 

You have never replied to those citations or questions. You just keep
asserting that you know that one paragraph overrides all others
and that your repeated assertion that 'original == sequence:0'. Even
when no such text exists. It means the original 'set' before the change
and not sequence:0. Then all text is consistent.

> 1 already WG discussed and declared bad iTIP bit from at least 1999 is 
> not anything new or a major inconsistancy in the RFCs.  The other phrase 
> you mention is not an inconsistancy in my reading; the only problem is 
> how some can misread "the definition of the recurrence set" as being 
> "the definition of the recurrence instance" but thats not the RFCs fault 
> nor is it an inconsistancy.  
 >
> It sounds like you only need a short note from the authors to this 
> effect and you'd then accept the fixed RECURRENCE-ID model.  Would that 
> be accurate?

It's not the EDITORS opinion that counts, its the WG's. As much hard
work as they put into the RFCs, it is a WG document.

>  >                                  , if we clearly understand the intent of
> 1: Multiple supporting citations in both iCalendar and iTIP that 
> describe and support a fixed RECURRENCE-ID model

There are multiple citations that disagree with you. Could you
please explain rather than ignore those?

> 2: Why the fixed RECURRENCE-ID model works well and is quite fault 

Would you please reply to my posting about how your model is broken?

> 3: That the RFCs overwhelmingly describe and implicitly use a fixed 

Yet the citations you refuse to debate disagree with you. Including
iTIP which you admit above disagrees with you.

> 4: Several of the major flaws inherent in a changing RECURRENCE-ID model.  

All of which have been addressed and you have ignored all such posts.

> Yet some folks still persist in saying that 1-2 lines in iTIP justify 
> that iCalendar/iTIP uses a delta RECURRENCE-ID model.  Wouldnt you get a 
> littel frustrated too after several weeks of this?

Yet you refuse to acknowledge that even in your email here that I am
responding to - iTIP disagrees with you.

Yet you refuse to acknowledge the other text here that has been
cited that disagrees with you.

Is it possible that you are misreading that one paragraph?

-- 

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

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Tue, 5 Aug 2003 16:45:50 -0400

> 2445 incorrect. It makes it a point to debate.

iTIP provides semantics to iCalendar and as such it cannot be redefining 
iCalendar to suite its needs.  Those 2 lines conflict w/all the rest of 
the RFCs but they do not mean that ALL the other prose is wrong.  Thats 
like the flea wagging the dog.

I do not agree that RECURRENCE-ID changes on a reschedule and I did not 
back in 1999.  I agree with Dan Hickman that RECURRENCE-ID was supposed to 
be fixed and nowhere during that 1999 discussion did I disagree.  To be 
accurate, at no point during that thread did anyone disagree with Dans 
comment "I thought we decided to leave the RECURRENCE-ID the same." 
including you. 

Originally a changing RECURRENCE-ID was the design that the WG had and at 
one point I _may_ have thought it was ok but I took an analytical approach 
to it and to the protocol and saw its many flaws and realized that if part 
of my primary key for sequencing changes every time there was too much 
room for failure and inconsistancy.  This is why a fixed RECURRENCE-ID was 
the model we finally put into iCalendar.

Ignore all the parts in all the RFCs that say this if you like but that 
wont change the published RFCs that definitely use a "fixed" RECURRENCE-ID 
model (when doing normal rescheduling, etc).

You can also ignore my lengthy analysis if you like but I dont hear you 
saying that it was wrong. 

You can disagree w/the fixed RECURRENCE-ID model all you like but thats 
whats in the RFCs.

> Except the ones you delete from posts and never reply to? 

Oh a question.  Better remember to answer 'em all lest Doug think Im 
ignoring him or dont want to debate just the issues... 

Umm, Im not the one who deletes conflicting lines of citations when 
responding.  In fact Doug has yet to even acknowledge that iCalendar says 
that RECURRENCE-ID stays at the original (aka 1st) value and does not 
change on a reschedule. 

Every time you've used a citation Ive tried to make sure it was entirely 
in perspective.  Im not the one ignoring the iTIP prose on Message 
Sequencing or describing the separate methods.  Im not the one ignoring:

Does that say that the RECURRENCE-ID changes to the new Thursday value or 
does it say that it "is still set to the origianl" value?

Im also the one who noted that iCalendar says RECURRENCE-ID "might also 
change" "When the definition of the recurrence set for a calendar 
component changes" so Im cant be accused of ignoring that possiblitiy. 
(Actually accusuing is easy, demonstrating is not...)  Perhaps because 
that line about when RECURRENCE-ID may change also has "and hence the 
"SEQUENCE" property value changes" some folks are of the notion that 
_every_ time SEQUENCE changes RECURRENCE-ID MUST also change.  That does 
not logically follow since SEQUENCE can also be changed if the changes "to 
other properties can also force the sequence number to be incremented." 
and a CUA can ref SEQUENCE anytime it wants (even for fixing a typo, sic). 
 By extension then a simple typo change could cause RECURRENCE-ID to 
change because SEQUENCE changed.  Yech!

>                                                           Below

I didnt use the phrase contention so Im not sure where you think I saw 
some. 

I noted that we already covered that exact iTIP citation from Satya back 
in 1999 (noone disagreed then that we had alrady agreed by July 1999 that 
RECURRENCE-ID was fixed) and that its the only line in iTIP that 
contradicts iCalendar and the rest of iTIP. 

> controversial ways discussing iCAL-rev-next.

1: iTIP does NOT define/redefine iCalendar properties or their actions! 
That is not its role.  iCalendar is the "definition of a common format" 
and iTIP "complements the iCalendar object specification by adding 
semantics".  You dont change the defintions when you provide semantics; 
you update the actual defintions.  Thats why we separated iCalendar from 
iTIP in the first place.

2: We are _NOT_ and have never been discussing _changes_ to iCalendar!  I 
am contesting your still unproven claim that iCalendar/iTIP _currently_ 
define a delta RECURRENCE-ID model!  I have used both RFC citation AND 
model analysis to disprove this but you just dont want to accept it.

If you want to propose changes to iCalendar and disguise it as a necessary 
CAP need then thats a different discussion.  As a vendor (and Method 
Reviewer for the existing RFCs) Ill object to a total reversal of the 
iCalendar model especially given there is no demonstrable need for it and 
that the current model has been implemented by many and works. 

If you built some prototype based on some misreading of the existing RFCs 
and want to change the model just because its easier for you than 
redesigning/recoding then thats not my problem. 

> means the original one you are changing from, not sequence:0.

Thats not the ways its defined in English nor the way its used in 
iCalendar.  Your misuse of original is really "the latest" or "the most 
recent" or "the current" no matter how you try to spin it.

> the original one being changed from and not the original sequence:0

Doug, get real.

Go to http://www.m-w.com/ and look up the work "original" then we can 
talk. 

When legal documents refer to the "original owner" they do not mean "the 
latest owner" or "the current owner".  (Gee that would be great for some 
property disputes yes!!?)
When advertising touts "The Original Widget" they are not talking about 
the latest clone widget product. 
When someone asks you where you are originally from they aren't asking 
where you just came from.
When people say "Originally I went studied Chemistry but I changed my 
major to Computer" they dont mean they first studied Computers and then 
Chemistry.

> You have never replied to those citations or questions. 

Ive answered your questions so far.  How about the same?

You just keep ignoring the fact that iCalendar says RECURRENCE-ID is 
"fixed" by now trying to weasle around the meaning of the word "original". 
 Even if you want to play weasel on that meaning the rest of the example 
paragraph demonstrates it:

Just in case you dont understand "original" the highlighed part should 
clue you in; the value DID NOT CHANGE to the new Thursday one!

>                                           You just keep

For the case where I create a repeating meeting set and then proceed to do 
workflow (the one Ive always used and referred to) then the original 
RECURRENCE-ID value will be the one from SEQUENCE:0.  This was always the 
case under discussion despite you attempts to muddy the discussion with 
different scenarios.

Your 6+ week refusal to acknowledge the text above and now this attempt to 
say "original" means "the latest version" (paraphrased for actual intent) 
is just ludicrous.  Now are you going to tell me that the highlighted bits 
above dont really mean the SEQUENCE:0 RECURRENCE-ID value (Friday) is 
preserved at SEQUENCE:1 (Thursday) because it doesnt put explicit SEQUENCE 
values in the text?

Prior to now you have merely said "its in the RFCs" (slightly paraphrased) 
or referred just to iTIP Section 4.7.2, an example section in ITIP at that 
and you never ever pointed to iCalendar as justification for your claim of 
a changing RECURRENCE-ID on a simple reschedule.  If you had actually 
thought that "original" meant what it did you would have immediately used 
that as a justification but you cant so you didnt.

> work as they put into the RFCs, it is a WG document.

And the WG passes the drafts that the Editors put out.  As such they 
provide both input to the Editors and they review the outputs before they 
move on.  As such its NOT just the Editors who agree with the fixed 
RECURRENCE-ID model, it was the entire WG!

> please explain rather than ignore those?

There is ONLY 1 citation so far thats been provided and that was Satays. 
Ive already pointed out that we dealt with it in 1999.  I repeatedly 
covered your single citation of Section 4.7.2 Bad RECURRENCE-ID and even 
shown how it agrees with a fixed RECURRENCE-ID.  What other citations have 
I missed? 

> Would you please reply to my posting about how your model is broken?

Its not my model, its the one from RFC 2445 and I did reply to it. 

I notice you have NOT responded to my comparison/analysis of the changing 
vs fixed RECURRENCE-ID.  Instead you try to wiggle around the meaning of 
"original"...  Ill take it then that you agree w/my analysis of the 
flaws/weaknesses in the changing RECURRENCE-ID model (above and beyond the 
fact that iCalendar says that its "fixed").

> iTIP which you admit above disagrees with you.

The 2 lines from the bottom of iTIP Section 3.7.1 Working With Recurrence 
Instances are old news and I did cover them again.  Umm I get it; 2 lines 
= 2 citations...  Ok must be Dougs defintion of citations but thats ok. He 
even double includes them at the end.

Those 2 lines have been hashed over before and still do not have the same 
weight as the actual defition from iCalendar no matter how much you wish 
for it.

> All of which have been addressed and you have ignored all such posts.

Ignored all such posts? Hahaha, I just have to laugh now.

Im the one who described the weaknesses inherent in the changing 
RECURRENCE-ID model.  I showed how the fixed RECURRENCE-ID has no such 
weakness.  Im the one who showed how easy it is to thrash or stuck in a 
changing RECURRENCE-ID model and that the same problems do not happen in a 
fixed RECURRENCE-ID model.

What did I ignore?

> responding to - iTIP disagrees with you.

What have I refused to acknowledge? 

Ive already noted that there are 2 lines in iTIP that we already discussed 
in 1999 and that they alone do not justify your claims.  2 lines vs 250+ 
pages and iCalendar defintions to the contrary; yep that sounds like a 
ringing justification of your claims.

Im NOT the one who has misunderstood the meaning of "definition of the 
recurrence set" nor the defintion of the word "fixed" nor the meaning of 
the word "original" in:

Nor have I now tried to reframe the assertion in the guise of iCalendar 
changes for CAPs benefit/need. 

> Is it possible that you are misreading that one paragraph?

Lets reread that paragraph (plus a bit more) again shall we:

[Snip, snip]
                               When the definition of the recurrence
   set for a calendar component changes, and hence the "SEQUENCE"
   property value changes, the "RECURRENCE-ID" for a given recurrence
   instance might also change.

Umm, no I dont think so.  Im rescheduling an instance in the set so the 
RECURRENCE-ID value "is still set to the original" value.  Even if I look 
at iTIP and Section 4.4.2 Modify A Recurring Instance I see no mention or 
example that shows RECURRENCE-ID changing. 

So, if you want to claim that iCalendar / iTIP _currently_ have a changing 
RECURRENCE-ID model then show it.  If you want to redefine the model under 
the guise of "discussing iCAL changes" relevant to CAP then say so (and 
dont forget to justify why a model change is necessary).

Bruce
PS: Fourth time asking: Doug, do you think that 1 SEQUENCE property/value 
is shared among all instances of the repeat set or does each instance have 
its own SEQUENCE value?
===========================================================================
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...