Subject: Re: RECURRENCE-ID discussion

From: [email-masked]
Date: Mon, 4 Aug 2003 11:36:48 -0400

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: Doug Royer <[email-masked]>
Date: Mon, 04 Aug 2003 12:50:27 -0600

> takes place the RECURRENCE-ID value "is still set to the original" 

Of the one being changed! Not of SEQUENCE:0 - orever.

Other wish to blindly ignore ALL of the text and examples that
clearly show that the paragraph you cite is for CHANGING and instance
where the RECURRENCE-ID sent is the OLD one (for the set you are
changing from).

On this topic you have almost demanded that I answer your questions
while you ignore all of mine. Not an open debate.

The model in iCalendar that maps the RECURRENCE-ID to the the UID
and SEQUENCE as documented works for BOTH models. Fixing the
RECURRENCE-ID to be forever at the SEQUENCE:0 value and ignoring
the 'set' only works for Bruce's model.

In Bruces model he can not change a 2nd unrelated instance back to
an original time of a separate 1st instance, so there code issues a
new UID (As I understand it) then cancels the original UID (or the other way
arround). Not a problem for those that tie the RECURRENCE-ID to
the UID and SEQUENCE set as it will work for those.

I'll stick to the method that works with both models.

My testing shows that it DOES work with the major vendors.
So far I have seen no evidence of any problem. Simply tie the
RECURRENCE-ID to the SEQUENCE and UID as shown in multiple places
in 2445 and 2446 and all works.

-- 

  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 14:57:22 -0400

> Of the one being changed! Not of SEQUENCE:0 - orever.

The text cited clearly says that RECURRENCE-ID does not change on a 
reschedule contrary to what Doug has claimed.  As such the RECURRENCE-ID 
on each subsequent would stay the same as the one it had originally at 
SEQUENCE:0 when it was originally created.  This is a fixed model of 
RECURRENCE-ID, NOT one where it changes on each reschedule as Doug has 
claimed.

Still Im not clear on what he means by "Not of SEQUENCE:0 - orever.".  The 
RECURRENCE-ID at SEQUENCE:1 will be the same RECURRENCE-ID as it had at 
SEQUENCE:0 since it does not change on the reschedule and will be the the 
same at SEQUENCE:1000 (excluding addition/deletions to the repeat set).

> where the RECURRENCE-ID sent is the OLD one (for the set you are

Doug, has NOT shown any that says RECURRENCE-ID changes on each 
reschedule!  He has only cited Section 4.7.2 Bad RECURRENCE-ID in iTIP and 
he apparently misread whats there at that.  Examples are NOT definitive 
sources in the RFCs and he knows that.  The ABNF and prose supercede in 
authority any example and they always have.

Plus he still ignores the fact that "iTIP complements the iCalendar object 
specification by adding semantics" to iCalendar data.  It does NOT 
redefine iCalendar properties; that is the function of the iCalendar RFC 
("provides for the definition of iCalendar object methods").

No matter how you try to spin it, iCalendar flat out says that the 
RECURRENCE-ID is "fixed" and does not change on the reschedule:

Also, if you check out iTIP Section 4.4.2 Modify A Recurring Instance it 
says NOTHING about RECURRENCE-ID changing on a reschedule.  It shows the 
RECURRENCE-ID value of July 1 for rescheduling the July 1 instance to July 
3.  I see nothing that says that RECURRENCE-ID is "the currently booked 
instance and not the SEQUENCE:1 (original)" as Doug has repeatedly 
claimed.

In fact I checked all the examples in iTIP and NONE of them have ANY prose 
even remotely saying that the RECURRENCE-ID used on each reschedule is 
"the currently booked instance and not the SEQUENCE:1 (original)"  (By the 
way, the original value for an instance would be the SEQUENCE:0 one for 
all the scenarios we've used so far; we have not done any adding or 
removing of instances to get from SEQUENCE:0 to SEQUENCE:1.)

> while you ignore all of mine. Not an open debate.

In order for us to debate a highly contentions claim like "The RFCs says 
RECURRENCE-ID changes on each reschedule" you need to be able to cite the 
bits that support this.  So far the ONLY reference you have provided was 
to eventually refer to an example section of iTIP (Section 4.7.2).  If you 
actually read the section though it actually describes a case where a 
fixed RECURRENCE-ID is used.

First I tried to address Dougs claim using examples.  I asked for 3+ weeks 
when the original thread started for simple iTIP examples to show how you 
could recover from a missed reschedule REQUEST for a single instance since 
I claimed its not possible.  I provided iTIP fragments to support my 
claims and examples but he never did (and still have not to date).  When 
Arnaud and others asked for them Doug still did not provided them; he 
merely coined a new term that caused confusion (Thanks again Arnaud for 
helping clarify this). 

In the end he tacitly agreed that resyncing the missed instance is NOT 
possible; his solution was to resync them ALL (even unaffected instances).

I have provided plenty of iTIP fragments on how a fixed RECURRENCE-ID 
model works and how fault tolerant it is when doing message sequencing.  I 
have provide explicit iCalendar and iTIP references that all support this. 
 I have even done an analysis of why the delta/changing RECURRENCE-ID was 
abandoned by the WG long ago by describing the flaws inherent in it. Along 
the way Ive had questions about Dougs assumptions that to date have never 
been answered. 

I have attempted to stay focused on the central claim and not be digressed 
by unrelated scenarios or questions so I have not answered each and every 
one of Dougs questions.  I dont think it necessary since they are 
unrelated to debunking the claim of a changing RECURRENCE-ID model in the 
RFCs.

> the 'set' only works for Bruce's model.

Fist off, its not my model; its iCalendars:

is straight from the RFC, Section 4.8.4.4, Page 108. 

Secondly the RECURRENCE-ID value is described as "The date/time value is 
set to the time when the original recurrence instance would occur".  I see 
no text in iCalendar "that maps the RECURRENCE-ID to the the UID and 
SEQUENCE" since the value is a date/time (or date) and not some amalgam of 
UID/SEQUENCE.  Perhaps Doug thinks "used in conjunction with the "UID" and 
"SEQUENCE"" means that RECURRENCE-ID values are 'mapped'.  Perhaps he is 
still fixated on Case 2 from iTIP Section 4.7.2 and is neglecting the 
message sequencing rules that apply to all iTIP messages where it clearly 
says that UID and RECURRENCE-ID are used before SEQUENCE is.  This also 
agrees with Case 1 from the same section.  (Refer to my full analysis from 
yesterday for more details on this if need be.)

In addition since we have not been talking about changing the recurrence 
sets defintion, merely rescheduling instances around, the RECURRENCE-ID 
will be fixed for all SEQUENCE values.  The only time that iCalendar says 
RECURRENCE-ID "might also change" is "When the definition of the 
recurrence set for a calendar component changes" (and thats also 
iCalendars text, not just me guessing). 

> the UID and SEQUENCE set as it will work for those.

Im not discussing the way any particular engine handles some CUs action; 
Im trying to stick to an analysis of the text in iCalendar and iTIP. 
However perhaps a more concrete example will help so let try one.

If my UID and RECURRENCE-ID  stay fixed then I can _always_ uniquely and 
correctly identify the instance in question and perform any workflow on it 
I need to.  If I miss a message (SEQUENCE of 2+ differnece) I can quickly 
and simply recover.  This is 100% NOT possible w/the delta RECURRENCE-ID 
model.  This is one of the factors why we long ago decided on a fixed 
RECURRENCE-ID model (and the RFCs bear this out).  The only way to recover 
in the changing RECURRENCE-ID model is to blast away ALL instances and 
have the invitee recreate them ALL!!  Not very efficient for 1 missed or 
missequenced message is it?

Doug incorrectly states that with fixed RECURRENCE-ID you "can not change 
a 2nd unrelated instance back to an original time of a separate 1st 
instance".  With a fixed RECURRENCE-ID model I can easily reschedule 2 
separate instances in the set to swap with each other and easily keep all 
REPLYs in sync with my versions.  With a changing RECURRENCE-ID model it 
can be shown that in 5 simple steps I can toally confuse the Organizer 
when trying to match REPLYs to the right instances.   With the fixed 
RECURRENCE-ID model its perfectly normal and workable to have:

BEGIN:VEVENT
UID:[email-masked]
SEQUENCE:3
ORGANIZER:Mailto:[email-masked]
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
ATTENDEE:Mailto:[email-masked]
DTSTART:20030805T210000Z
DTEND:20030805T220000Z
RECURRENCE-ID:20030804T210000Z
STATUS:TENTATIVE
END:VEVENT

BEGIN:VEVENT
UID:[email-masked]
SEQUENCE:8
ORGANIZER:Mailto:[email-masked]
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
ATTENDEE:Mailto:[email-masked]
DTSTART:20030804T210000Z
DTEND:20030804T220000Z
RECURRENCE-ID:20030805T210000Z
STATUS:CONFIRMED
END:VEVENT

and I can quickly and easily match the right REPLY from Pat to the correct 
instance because the UID and RECURRENCE-ID are the primary keys and never 
change.  If I get SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z I 
know that Pat is referring to an old copy of the instance that originally 
occurred on 05-Aug-2003 @ 21:00Z but she is responding to an obsolete 
version of it so I simply resend her a REQUEST with the current version 
and Im done.

If we use a changing RECURRENCE-ID model then I have NO 100% accurate way 
to match a SEQUENCE:5 REPLY for RECURRENCE-ID:20030805T210000Z to the 
correct instance she was responding to.  The ONLY solution is therefore to 
resend ALL current instance definitions and let _her_ sort 'em out.  Of 
course Id have to craft a REQUEST that sent not only some 'base' defintion 
but also the individual differences (different SEQUENCE, SUBJECTs, 
DESCRIPTIONs, etc).  She would then have the fun job of removing and 
recreating it all on her end.  All because I have no way to match her 
REPLY to my instances OR because 2 messages got missequenced en-route.

iCalendar says that RECURRENCE-ID is "is used in conjunction with the 
"UID" and "SEQUENCE" property to identify a specific instance of a 
recurring...calendar component.".  iTIP agrees with this.  However none of 
this says that RECURRENCE-ID changes on a reschedule.  In fact iCalendar 
says that it does NOT (and iTIP for the most part concurs).

> I'll stick to the method that works with both models.

If you change the RECURRENCE-ID on each reschedule you do then you are in 
direct vioaltion of iCalendar.  Im trying to keep you (and others) from 
making that mistake.

> My testing shows that it DOES work with the major vendors.

If you tested with Microsoft or IBM products then you should have seen 
that all use a fixed RECURRENCE-ID.  Thats because thats what the WG 
decided on, whats in iCalendar and what is more efficient and fault 
tolerant. 

> in 2445 and 2446 and all works.

I have provided at least 2 explicit examples where it breaks down or 
causes massive C&S workflow thrashing thats easily avoided. 

I have provided an analysis of why the WG went with a fixed RECURRENCE-ID 
over a changing one and how the RFCs support this. 

Ive also shown that the iCalendar RFC clearly defines a fixed 
RECURRENCE-ID for the simple reschedule case. 

If you chose NOT to adhere to the RFCs then thats your decision.  However 
your decision is NON-conformant to the RFCs and no matter how long you 
claim "it works" or that the RFCs say the model is NOT a fixed 
RECURRENCE-ID (contrary to actual RFC text) you are still in violation of 
the RFC.  I would hope that you would conform to the RFCs instead of 
clinging to 1 poorly described case in an example section of iTIP but 
thats your choice Doug.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Aug 2003 14:16:47 -0600

[email-masked] wrote:
> The text cited clearly says ...

And Bruce still does not answer any of the questions or debate
any posted soultions...

--

---

From: [email-masked]
Date: Tue, 5 Aug 2003 17:27:22 -0400

> And Bruce still does not answer any of the questions or debate

Clearly you are just playing spoiler attempting to waste cycles.  I asked 
for clarification of your "Of the one being changed! Not of SEQUENCE:0 - 
orever." but dont see it.

Plus its not my job to prove your bogus assertions about a changing 
RECURRENCE-ID model.  iCalendar defines a "fixed" (go to 
http://www.m-w.com/ if you dont understand that word either) RECURRENCE-ID 
model and iTIP supports that.  As previously noted the WG alrady covered 
the 2 lines of iTIP that try to redefine RECURRENCE-ID and there was no 
disagreement (not even by you!) to "we decided to leave the RECURRENCE-ID 
the same."

We collectively did agree (by the lack of disagreement over that statement 
or by vocally agreement) so this is old news.  In fact the only real 
conflicting line in iTIP is the last one that Satay (not you) referenced 
when it says:

               Note that after the change has occurred, the
   "RECURRENCE-ID" has changed to the new "DTSTART" value.

The other (preceeding) line actually agrees w/iCalendar:

                                  If the "Organizer" wishes to
   change the "DTSTART", the original "DTSTART" value is used for
   "RECURRENCE-ID" property [Snip]

but that would assume that you understand what the word "original" means. 
So I must ammend my 2 lines vs 250+ pages comparison to be 1 line vs 250+ 
pages to the contrary.  Yep, that sounds real compelling...

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Aug 2003 17:12:12 -0600

[email-masked] wrote:
> Clearly you are just playing spoiler attempting to waste cycles. 

No Bruce. I answered all of your questions and you ignored all of mine.

I proposed solutions to all of your quandaries, you ignored all of them.

--

---

From: Tim Hare <[email-masked]>
Date: Wed, 06 Aug 2003 23:39:15 -0400

I'm not going to quote all of the discussion about RECURRENCE-ID, but I am 
going to try to offer a semi-"user" perspective, and perhaps through my 
ignorance of all the issues,  try to obtain some clarity for myself 
(others' mileage may vary of course).

To me, the problem is not necessarily with the RFC, but with the terms used 
to describe an item on the calendar. Each item has a unique UID, _unless_ 
it's part of a recurrence set, then they all have the same UID but 
different RECURRENCE-IDs, as I understand it, so it appears to the 
uninformed that we have two different uniqueness values for calendar items. 
This to me as a "user" and sometime-programmer, makes the semantics (if I'm 
using that term correctly here) confusing at best. What if each and every 
item on a calendar had a unique identifier, which I am going to call 'X-ID' 
for this argument to avoid confusion with the others, and items had an 
optional property called X-RID, which was a recurrence _set_  identifier, 
but not a uniqueness value for the items.

1. Updating/deleting any one part of a recurrence set would be accomplished 
using X-ID as the key of that item, which does not change because it 
uniquely identifies the item (I'm thinking of the calendar store as a 
"database" and X-ID as the "key" of items in the database).
2. Applying changes to one whole recurrence set would be accomplished by 
using commands which did not specify an X-ID, but did specify a "filter" 
consisting of the X-RID.  The protocol would require the CS to apply the 
update to all matching items (UPDATE Fields from CS WHERE X-RID = "some 
value").  Removing an entire recurrence set would work much the same way. 
You could even change the recurrence set on all the identifiers matching a 
certain value, since it would not be a  "key" to the calendar store.

Now, that makes perfect sense to me from a "layman's" perspective so I'm 
sure there's something I'm overlooking - but I think part of the problem 
with the discussion has been trying to make UID and RECURRENCE-ID do the 
same job - provide the unique identifer for one item in the CS.  If we 
_must_ use these terms, then the uniqueness identifer for an item in a 
calendar store is really the concatenation of both values, perhaps using 
NULL as the recurrence identifier for non-recurring items. Then an item is 
uniquely identified by

UID.NULL or UID.RECURRENCE-ID

The _combination_ of these values, which is the "key" for the item, 
shouldn't change (in my opinion) so that the same ID always means the same 
item.

As I said - feel free to point out my errors, I'm relatively new to this... 
but does this help at all?

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 6 Aug 2003 22:00:22 -0700

[This seemed to have gotten lost in transit so I'm
 reposting.  I apologize if any of you receive it twice.]

At the risk of furthering Doug's rather discredited pulpit,
but to ensure that I understand what Doug is trying to say,
I agree with Bruce that Doug's comment in response to one
of Bruce's examples didn't seem to make sense but almost
sounded reasonable.  So I really thouroughly tried to go
through and pick up the context from the mindset of a
changing RECURRENCE-ID model.  I think I understood what
he was trying to say, but when I tried to actually go
through and see what messages in a changing RECURRENCE-ID
model would like it, I found that using either Doug's or
Bruce's interpretation of "original", that the net result
was the SEQUENCE: 0 RECURRENCE-ID was always the one to
be used.  I encourage Doug to please look this over and
point any flaws in my logic or understanding of the prose.

The argument basically boils down to the fact that in
order to end up at a changing RECURRENCE-ID model, the
CS or CUA has to take a proactive leap that the prose
doesn't tell it to take.

Below is what I did that had me arrive at this conclusion.

I believe the context for the confusion was the following:
<iCal definition text>
"

[Snip]

"
</end definition text>

To which Bruce declared (slightly modified for clarity):
> Some folks seem to blindly ignore the 2nd paragraph above,
> (which is the 3rd paragraph in the actual RFC text)
> which clearly and unequivocally says that when a reschedule

To which Doug responded:

Now I think this means that Doug is trying to say that
the RECURRENCE-ID is set to the original value of the instance
being modified which with a changing RECURRENCE-ID could be
different.  But I find it impossible for Doug to support
this claim because as far as I can see there is no where in
the text that allows one to set a before and after RECURRENCE-ID.
So the only way to get a differing RECURRENCE-ID is for CS/CUA
to proactively change it on its own accord which the message
never specifies to do.

If we followed the logic as either Bruce or Doug put it forth
we find it impossible to get a changing RECURRENCE-ID:

I first create an event:

UID: 1
SEQUENCE: 0
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030805T180000Z

Now to update this I have to reference it, no one here
disagrees that the RECURRENCE-ID used in the SEQUENCE: 1
message will be identical to the SEQUENCE: 0 message.

UID: 1
SEQUENCE: 1
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030806T150000Z

[For readability sake I'm going to drop the date part of
the IDs becuase only times are significant.]

So now we go to update it again.  If we look at the objects
themselves.  I specified that SEQUENCE: 1 of UID: 1,
RECURRENCE-ID: ...T180000Z would DTSTART at ...T150000Z.
Note that no where in this object did I ever say, "oh and
by the way here's a new RECURRENCE-ID".  So now we go
to move it again.  Here's where the disagreement is.

In a fixed RECURRENCE-ID model the answer is ...T180000Z.
In a changing RECURRENCE-ID model the answer is purported to
be ...T150000Z but as we will see in a second it is
impossible to arrive at that answer without proactive and
rather magical intervention on the part of the CS/CUA.

We know what Bruce's interpretation says, so for sanity's
sake to put this to rest, let's use Doug's.
Doug's interpretation says that we use the original
RECURRENCE-ID of the instance we are trying to modify.

Looking at the instance I'm trying to modify, which
is the SEQUENCE: 1 version of the object, I see that the
original value of RECURRENCE-ID is ...T180000Z.
I didn't tell the CS/CUA to change the RECURRENCE-ID, so unless
the CS/CUA did that on its own it will be the value I set it to.
Further, unless we redefine the word "original" to mean "CS/CUA
modified" (which I don't think any of us could accept) the
RECURRENCE-ID of that instance remains ...T180000Z which is
also the same as SEQ: 0 by virtue of propogation through SEQ: 1.
So the object to update the SEQUENCE: 1 version of the instance
must be:

UID: 1
SEQUENCE: 2
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030806T210000Z

So now I want to change it a third time.  We go through
the logic again and we see that the original value for
RECURRENCE-ID in the SEQUENCE: 2 version of the object
is: ...T180000Z
Which also happens to be the same as the SEQUENCE: 1
version, which also happens to be the same as the
SEQUENCE: 0 version.

Which of course leads us to the obvious that, barring some
proactive action on the part of the CS/CUA to change the
RECURRENCE-ID away from what the object specified, it is
impossible to escape using the SEQUENCE: 0 value since that
value will be propogated using either Bruce's or Doug's
interpretation of paragraph 2 in the definition.

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 11:33:53 -0600

> DTSTART: 20030805T180000Z

You can't create that VEVENT. You do not create a VEVENT
with a RECURRENCE-ID. Now assuming that you meant that
you created a VEVENT with that DTSTART, then later
you wanted to refer to that instance of that VEVENT,
then that would be the RECURRENCE-ID you would use
to refer to that instance.

The RECURRENCE-ID is use to refer to an existing instance.

> to move it again.  Here's where the disagreement is.

You do not need to say 'oh and by the way here's a new RECURRENCE-ID'
because iCAL says:

    Purpose: This property is used in conjunction with the "UID" and
    "SEQUENCE" property to identify a specific instance of a recurring
    "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
    value is the effective value of the "DTSTART" property of the
    recurrence instance.

So once the SEQUENCE:1 object is booked, then the RECURRENCE-ID
for that single instance object SEQUENCE:1 is the effective value
of the "DTSTART" property - ...T150000Z and not ..T180000Z.

So after that point if you do an update to RECURRENEC-ID ..T180000Z,
there would be no object with that effective DTSTART date and
thus no RECURRENCE-ID to match.

In Bruces model you can NEVER add someone to the series
of recurring VEVENT after any change that effects the
effective  DTSTART value of any instance as they could never
be able to resolve the RECURRENCE-ID because they never
had SEQUENCE:0.

For a single VEVENT REQUEST with three instance (COUNT=3
in a RRULE). It has three RECURRENCE-ID's none of which
were ever explicitly created.

So if the original REQUEST looks like this:

	METHOD:REQUEST
	SEQUENCE:0
	DTSTART:20030805T180000Z
	RRULE:FREQ=HOURLY;COUNT=3
	LOCATION:A

Would have 3 RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

So now the ORGANIZER wants to change the 2nd instance to ..T193000Z.
So per iTIP they could send a new REQUEST SEQUENCE:1 :

	METHOD:REQUEST
	SEQUENCE:1
	DTSTART:..T193000Z
	RECURRNCE-ID:..T190000Z

So once the CUA accepts the new SEQUENCE:1 object, the object
still has three RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T193000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

As the RECURRENCE-ID is the effective DTSTART value
of the instance.

Now change the 3rd instance of the SEQUENCE:1 object to ...T190000Z
and move its LOCATION to 'B'.

	METHOD:REQUEST
	SEQUENCE:2
	DTSTART:..T200000Z
	RECURRNCE-ID:..T190000Z
	LOCATION:B

So once the CUA accepts the new SEQUENCE:2 object, the object
still has three RECURRENCE-ID's (new effective DTSTART times):

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
                      (used to be the 3rd instance)
	...T193000Z  3rd instance (effective DTSTART)
		     (used to be the 2nd instance)

Now change the SEQUENCE:2 2nd instance to ...T200000Z:

	METHOD:REQUEST
	SEQUENCE:3
	DTSTART:..T190000Z
	RECURRNCE-ID:..T200000Z

Now in Bruce's model, your broken because you just moved
the SEQUENCE:0, LOCATION:A meeting to ...T200000Z to LOCATION:A.
When in fact the move was to move the LOCAION:B meeting.

Bruce's reply is to throw the object away and start over
because its impossible to resolve.

 > to proactively change it on its own accord which the message

You do not change RECURRENCE-ID's directly. You update the object
in ways that alter the effective DTSTART value for an instance.
And as its effective DTSTART value is changed, thus its RECRRENCE-ID
changes to match its effective DTSTART value. And:

    (iTIP)
    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. 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.

You do not 'set' the 'before' and 'after' RECURRENCE-ID, you
alter the effective DTSTART directly by updating one or more
instances and the RECURRENCE-ID is defined to match the
new effective DSTART.

Another way to change the RECURRENCE-ID's is to alter the times
an existing VEVENT. So if the SEQUENCE:0 object were:

	METHOD:REQUEST
	SEQUENCE:0
	DTSTART:20030805T180000Z
	RRULE:FREQ=HOURLY;COUNT=3
	LOCATION:A

Would have 3 RECURRENCE-ID's:

	...T180000Z  1st instance (effective DTSTART)
	...T190000Z  2nd instance (effective DTSTART)
	...T200000Z  3rd instance (effective DTSTART)

If the ORGANIZER sent a SEQUENCE:1 :

	METHOD:REQUEST
	SEQUENCE:1
	DTSTART:20030805T180000Z (same as the SEQUENCE:0 value)
	RRULE:FREQ=HOURLY;COUNT=3;INTERVAL=2
	LOCATION:A

The SEQUENCE:1 object would 3 RECURRENCE-ID's 2 of which
are different than the SEQUENEC:0 object:

	...T180000Z  1st instance (effective DTSTART)
	...T200000Z  2nd instance (effective DTSTART)
	...T220000Z  3rd instance (effective DTSTART)

The ORGANIZER moved two instances and their effective
DTSTART values (RECURRENCE-ID).

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 15:26:06 -0400

[Snip]
> The RECURRENCE-ID is use to refer to an existing instance.

Umm, we never said that in 2445.  In fact, if you create the instances at 
SEQUENCE:0 then by definition you are gonna be creating the RECURRENCE-IDs 
at that time too...  You dont create the instance in the set w/o assigning 
RECURRENCE-IDs otherwise you wont be able to match REPLYs to particular 
instances until you reschedule them (to SEQUENCE:1).

Also, that was a perfectly valid iTIP fragment for a SEQUENCE:0 REQUEST 
for a particular instance.  After all its referring to a particular 
instance and iTIP has the restriction table of:

and since its referring to an instnace of a recurring component, it MUST 
be there...

Bruce

---

From: [email-masked]
Date: Thu, 7 Aug 2003 15:42:52 -0400

> of the "DTSTART" property - ...T150000Z and not ..T180000Z.

Show us where iCalendar says that the RECURRENCE-ID values are assigned at 
SEQUENCE:1.  If you create the set at SEQUENCE:0 then the id would have to 
be assigned at that time, not after a rescheduling of that instance.

> effective DTSTART value

Huh??  You are really not getting the fixed model I think.  If the 
RECURRENCE-IDs used never change then adding someone is no big deal.  Take 
a look...

If for some reason I wanted to add you to an instance of:

UID: 1
SEQUENCE: 10
RECURRENCE-ID: 20030805T180000Z
DTSTART: 20030816T150000Z

then I send you just that.  Your REPLY would use the same UID / 
RECURRENCE-ID / SEQUENCE value that someone who is aready invited would 
and we would all be on the same page.  Where is it broken??

>                   of any instance as they could never

So??  The value is the same at SEQUENCE:10 as it is as SEQUENCE:0.  If you 
correctly apply the iTIP Section 3.2.2 REQUEST rules:

   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.

then you would treat it as a new invitation (which it is) to UID:1 / 
RECURRENCE-ID:20030805T180000Z / SEQUENCE:10 and that info comes back in 
your REPLY reflecting your response. 

It does not matter that you never saw the SEQUENCE 0 thru 9 versions, the 
SEQUENCE:10 version obsoletes them anyway.  If I had invited you at 
SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can correctly 
apply the iTIP message sequencing rules to detect that the message is 
obsolete and thus you ignore it (and the missequenced 9 too).

Now, if the RECURRENCE-ID value changed on each reschedule (along with 
SEQUENCE) then when you get UID:1 / RECURRENCE-ID:20030815T190000Z / 
SEQUENCE:8 you have no way to accurate match this REQUEST to the instance 
you already have since the UID / RECURRENCE-ID primary key matches nothing 
you have.  As such, you would mistakenly treat this stale REQUEST as a new 
invitation to a different instance.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 13:55:32 -0600

[email-masked] wrote:

 > ... then by definition you are gonna be creating the
> RECURRENCE-IDs at that time too...

We agree, you can not create a VEVENT with a RECURRENCE-ID property in it.

> instance and iTIP has the restriction table of:

He actually said:

	"I first create an event:
	 UID: 1
	 SEQUENCE: 0
	 RECURRENCE-ID: 20030805T180000Z
	 DTSTART: 20030805T180000Z   ..."

And you can not create a VEVENT with a RECURRENCE-ID property in it.

> and since its referring to an instnace of a recurring component, it MUST 

For REPLY, Single instance update, moving an instance, canceling and
instance, but not creating a recurrence set even when the recurrence
set has only one instance.

This was covered by Frank/Steve on this list as part of the pre-iTIP
debates.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 14:09:34 -0600

[email-masked] wrote:
> Show us where iCalendar says that the RECURRENCE-ID values are assigned 
> at SEQUENCE:1.  If you create the set at SEQUENCE:0 then the id would 
> have to be assigned at that time, not after a rescheduling of that 
> instance.

Show me anywhere where in any RFC it says you can ignore:

   (iCAL)
    ...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. ...

If you change just the LOCATION for example the RECURRENCE-ID does
not CHANGE even when the SEQUENCE changes. If you change the
effective DTSTART value for a given recurrence instance (THE
RECURRENCE-ID for that instance), then the RECURRECE-ID changes.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 14:10:54 -0600

[email-masked] wrote:

> RECURRENCE-IDs used never change then adding someone is no big deal. 
>  Take a look...
> 

That example of mine was NOT to a single instance - what's your point?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 14:12:31 -0600

[email-masked] wrote:
> So??  The value is the same at SEQUENCE:10 as it is as SEQUENCE:0.  If 
> you correctly apply the iTIP Section 3.2.2 REQUEST rules:

Not in the example provied if you read the entire email.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 14:35:09 -0600

[email-masked] wrote:

> It does not matter that you never saw the SEQUENCE 0 thru 9 versions, 
> the SEQUENCE:10 version obsoletes them anyway.  If I had invited you at 
> SEQUENCE:8 and you got it after the SEQUENCE:10 instance you can 
> correctly apply the iTIP message sequencing rules to detect that the 
> message is obsolete and thus you ignore it (and the missequenced 9 too).

So if SEQUNCE:10 is the following REQUEST VEVENT and is the FIRST
one to which I am invited:

	SEQUENCE:10
	RDATE: Jan-1
	RDATE: Jan-2
	RDATE: Jan-3

Now I get a request to change the RECURRENCE-ID:Jan-4 to Jan-5
because the original (SEQUENCE:0) RECURRENCE-ID for one of the
above instances was Jan-4. It is useless trash to the CUA at that point.

If updates and cancels do not apply to the current object (latest
REPLY'd UID/SEQUENCE/RECURRENE-ID set) and if a RECURRENCE-ID has changed
from the original (SEQUENCE:0) object, you can never send me updates
to instances as I do not have the original (SEQUENEC:0) object in
order to process the update or cancel. Is all that can be known is that one
might match the same effective DTSATRT value of SEQUENCE:10, but in the
examples you keep cutting out in your replies to my email - you can
break/fake the CUA into changing an incorrect instance LOCATION if
you fixate on SEQUENCE:0 instance times.

The RECURRENCE-ID changes as the booked UID/RECURRENCE-ID/SEQUENCE
changes. Else you can not add new ATTENDEEs if there has been
or will be a change to an effective DTSTART instance *if* your
model is correct.

---

From: [email-masked]
Date: Thu, 7 Aug 2003 16:42:54 -0400

> We agree, you can not create a VEVENT with a RECURRENCE-ID property in 
it.

Umm, I dont think you got my meaning.  If you create the VEVENT recurrence 
instances at SEQUENCE:0 then by defintion you've assigned each instance 
its RECURRENCE-ID then.  You had said that it didnt happen until 
SEQUENCE:1.

When I actually create the instances in my calendar Im going to create 
them w/the UID and RECURRENCE-ID values to identify the recurrence set and 
the particular instance.  As such they get created in the Organziers 
calendar at SEQUENCE:0.  They also get created and assigned in each 
invitees calendar when they create the instance set in their calendars 
when they get my SEQUENCE:0 REQUEST.  Right?

> And you can not create a VEVENT with a RECURRENCE-ID property in it.

You certainly can Doug.  If I want to invite you to a particular instance 
of a repeat set I would exactly send that iTIP fragment. 

You dont get the instances you are not invited to; you'd have no way to 
know you were not being invited to them!

> set has only one instance.

Err, that restriction table snippet came from iTIP Section 3.2.2 REQUEST 
and clearly matches the iTIP note:

     .  Reschedule an existing event;

Just because we didnt espressly write "Reschedule an existing event [or a 
particular instance or range of instances of a repeating event]" every 
time does not mean it does not work refer to just a particular instance 
only.  If we had done this then iTIP would have been 4 times larger.  It 
should be understood that whever we referred to "an event" we meant "an 
event or an instance of a repeating event or the entire set of instances 
in a repeating event" with the releveant gramatical changes.  As such when 
the text says:

                                    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.

it implicitly should read:

                                    If the "UID" and "RECURRENCE-ID" 
   property values in the "REQUEST" are not found on the recipient's 
   calendar, then the "REQUEST" is for a new instance of a repeating
   "VEVENT" calendar component.

when you are talking about an instance of a repeating set.  You can add 
the omitted verbage when dealing with RANGEes if you like...  In any case, 
a RECURRENCE-ID on a REQUEST  is valid and expected when referring to a 
particular instance.

Oh I think I see now.  Noone said it was a 1 instance set, at least that 
not what I got from a quick reading of the original posting.

Yes, I  do agree that a non-repeating component has NO RECURRENCE-ID value 
if thats what you meant.  iCalendar addresses this with:

   Conformance: This property can be specified in an iCalendar object
   containing a recurring calendar component.

If its non-recurring, then the property does not belong (although its kina 
loose phrasing with "can be" instead of "can only be" but we cant catch 
'em all).  There is no simple way to specify this in the ABNF so we opt'd 
for conformance prose here.

However I took his example to be referring to a single instance of some 
arbitrary repeating instance.   In any case, what I said before and above 
holds true for any REQUEST when dealing with a particular instance of a 
recurrence set.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:06:16 -0600

[email-masked] wrote:
> Umm, I dont think you got my meaning.  If you create the VEVENT 
> recurrence instances at SEQUENCE:0 then by defintion you've assigned 
> each instance its RECURRENCE-ID then.  You had said that it didnt happen 
> until SEQUENCE:1.

I said no such thing.

I said:

I made no mention of the SEQUENCE:0 RECURRENCE-ID which is
known to the ATTENDEE CUA after (or when) then REPLY to the SEQUENCE:0
object is made.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:08:56 -0600

[email-masked] wrote:
> You certainly can Doug.  If I want to invite you to a particular 
> instance of a repeat set I would exactly send that iTIP fragment.  
> 

And it does not contain a RECURRENCE-ID, else it is not a new invitation,
its a iTIP modify to an existing VEVENT. So, no you can not.
If it contains a RECURRENCE-ID and a DTSTART and METHOD:REQUEST,
then it is a modification to an existing VEVENT, not a new
invitation.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:12:38 -0600

[email-masked] wrote:
> Just because we didnt espressly write "Reschedule an existing event [or 
> a particular instance or range of instances of a repeating event]" every 
> only.  

Yes you can also use RANGE if that is what you meant to say.

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 17:10:04 -0400

> Not in the example provied if you read the entire email.

All SEQUENCE values examples above 8 were my own.  That should have been 
clear from reading the entire posting.  I can repost if need be with 
proper cavat...

Bruce

---

From: [email-masked]
Date: Thu, 7 Aug 2003 17:08:04 -0400

>     instance might also change. ...

Whats to ignore?  Nothing even remotely comes close to your SEQUENCE:1 
claim.  I still see NOTHING in your citation that says RECURRENCE-ID 
values are assigned at SEQUENCE:1 and not at SEQUENCE:0 no matter how hard 
I try to ignore it.. 

If I create the repeating set at SEQUENCE:0 then Im also assigning the 
RECURRENCE-IDs then.  Otherwise I cannot add any new ATTENDEEs unless I 
change SEQUENCE to 1 by your logic.  Plus, Im creating the instances now, 
NOT changing them (or more accurately changing the "defintion of the 
recurrece _set_".  Besides, rescheduling an instance is not redefining the 
set, its moving the instance around.

After all, if the instances are created at SEQUENCE:0 then they each have 
their own original DTSTART values for everyone invited to use when adding 
to their calendars.  Otherwise how could I reschedule just 1 instance the 
original ATTTENDEEs know about if my now SEQUENCE:1 instance has a 
RECURRENCE-ID that I only just assigned?

Assigning the RECURRENCE-ID at SEQUENCE:0 also allows ATTENDEEs to REPLY 
to particular instances too.  For example, I know I cant make the 4th 
instance so I can immediately send a REPLY with PARTSTAT=DECLINE for that 
particular RECURRENCE-ID.  If you had not created the RECURRENCE-ID values 
when you created the instances at SEQUENCE:0 then you have no way to match 
up my 100% valid REPLY (at SEQUENCE:0) to the correct instance.  You'd 
have to rev SEQUENCE to 1 and resend the REQUEST to me so I can once again 
decline...

> not CHANGE even when the SEQUENCE changes. 

Not true.  I wont quote all of 2445 on this (Section 4.8.7.4 Sequence 
Number, p 131) but I will point out that SEQUENCE is required to change on 
certain conditions but it is NOT LIMITED to those cases only.  The 
relevant bit you may have overlooked is:

   In addition, changes made by the "Organizer" to other properties can
   also force the sequence number to be incremented. The "Organizer" CUA
   MUST increment the sequence number when ever it makes changes to
   properties in the calendar component that the "Organizer" deems will
   jeopardize the validity of the participation status of the
   "Attendees".

The Organizer may decide that changing LOCATION:Boston to LOCATION:Miami 
may is a reason to jeopardize participation and thus MUST rev SEQUENCE. 
This decision is not just limited to LOCATION though, it could be nearly 
any other factor (or set of factors).  We _never_ said SEQUENCE can or 
should _only_ be revd for the explicit set of changes you are thinking of; 
we just mandated it MUST for them but allowed it to be reved in other 
cases too.

>                                             If you change the

I guess you are ignoring:

or perhaps you just didnt see it before... 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:17:43 -0600

[email-masked] wrote:
> Yes, I  do agree that a non-repeating component has NO RECURRENCE-ID 
> value if thats what you meant.  iCalendar addresses this with:

And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID.
And if it does contain a RECURRENCE-ID, then it is a object modify
as defined  by iTIP and not an new invitation.

> arbitrary repeating instance.   In any case, what I said before and 
> above holds true for any REQUEST when dealing with a particular instance 
> of a recurrence set.

Do you disagree that iTIP says that if it has a RECURRENCE-ID and
METHOD:REQUEST that it is a modify and not a new invitation?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:32:25 -0600

> clear from reading the entire posting.  I can repost if need be with 

Except you were replying to my email - not yours.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 15:33:53 -0600

[email-masked] wrote:
> Whats to ignore? 

Your ignoring the fact it changes.

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 17:19:58 -0400

> That example of mine was NOT to a single instance - what's your point?

The point I was making is that its 100% easy and straight forward adding 
ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) model. 
I just moved SEQUENCE ahead to 10 to reuse the fragments already in play 
but I see that easily confused some folks.  Sorry about that.

Lets see if I can rephrase the point for you: Adding new ATTENDEEs at ANY 
TIME is no problem with a fixed RECURRENCE-ID model; your claim of "you 
can NEVER add someone to the series...after any change" is just flat out 
wrong.  Yep, that about rephrases it just right.

Above was an example of how easy it is to add someone to a single 
instance, I simply send them a REQUEST using the current definition and 
thats it.  Adding them to the set is just as easy.  I showed how easy it 
was last month when Arnaud asked for examples.  To save time and effort 
Ill let you go check the archives for 'em if you are still unsure how it 
can be done. 

Bruce

---

From: [email-masked]
Date: Thu, 7 Aug 2003 17:52:42 -0400

This blatantly FALSE.

The request method makes no such distinction.
If you receive a request and it is not on your calendar, you must treat it 
as an invitation.
The presence of a repeat-id makes it an invitation to an instance of a 
repeat set.
_____________________
Note: new email address

[email-masked]

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/07/2003 05:17 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: RECURRENCE-ID discussion

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 16:05:40 -0600

[email-masked] wrote:

> ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars) 
> model.  I just moved SEQUENCE ahead to 10 to reuse the fragments already 
> in play but I see that easily confused some folks.  Sorry about that.
> 
> Lets see if I can rephrase the point for you: Adding new ATTENDEEs at 
> ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim of 
> "you can NEVER add someone to the series...after any change" is just 
> flat out wrong.  Yep, that about rephrases it just right.

And what about the example I sent to this list that shows how
your model broken in that area? You know the one that showed
that new attendess in your model can not process instance
changes unless they just happen to be the same as the SEQUENCE:0 instances?

> Ill let you go check the archives for 'em if you are still unsure how it 

Except all of your examples were how to modify an existing VEVENT
and you called it inviting a new attendee. There is no problem
to solve, just send them a VEVENT with NO RECURRENCE-ID as all
of the examples in iCAL and iTIP show and every thing works.
There is no need to invent a new way to invite an ATTENDEE.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 16:15:53 -0600

[email-masked] wrote:
> If you receive a request and it is not on your calendar, you must treat 
> it as an invitation.

Nope - iTIP - Modify A Recurring Instance, look for:

	...Note the use of "RECURRENCE-ID" property and "SEQUENCE"
	property in the second request.

And i iTIP - Working With Recurrence Instances, at and near:

    ...If the "Organizer" wishes to

If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.

> The presence of a repeat-id makes it an invitation to an instance of a 

Can you cite any text? Or is that just another take my word for
it assertion?

---

From: [email-masked]
Date: Thu, 7 Aug 2003 18:38:33 -0400

>changes unless they just happen to be the same as the SEQUENCE:0 
instances?

Of course nothing works if you send your changing recurrence ids.   This 
is not the iCalendar RFC 2445 model.

   If the value of the "DTSTART" property is a DATE type value, then the
   value MUST be the calendar date for the recurrence instance.

RECURRENCE-ID ARE SUPPOSE TO BE THE     "ORIGINAL"    dates of the 
"ORIGINAL"  repeat set.
If you send your changing  values as recurrence ids to a properly coded 
iCalendar, of course you will not work correctly.
_____________________
Note: new email address

08/07/2003 06:05 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

And what about the example I sent to this list that shows how
your model broken in that area? You know the one that showed
that new attendess in your model can not process instance
changes unless they just happen to be the same as the SEQUENCE:0 
instances?

--

---

From: [email-masked]
Date: Thu, 7 Aug 2003 18:17:46 -0400

> one to which I am invited:

My example was for a particular instance at SEQUENCE:10 and your response 
was for the entire set I assume.  This is mixing apples and kiwis.  We've 
been discussing how instances are affected so lets try to stay focused 
shall we.

However, since Doug suggested the example I think it important to analyze 
it for those who may not grasp the subtler problems or issues inherent in 
it.  This example is for a world where the RECURRENCE-ID changes on each 
reschedule because the Organizer is asking the recipient to create the 
entire set w/the given RDATEs as RECURRENCE-IDs.  Implicit in this are 
several assumptions like:

1: All instances share the exact same information and have no variations. 
In the real world I rarely hear of any repeating meetings that always 
exactly the same.  At least the DESCRIPTION or something is usually 
different but perhaps I live in a bubble...

2: Updating or inviting to a particular instance is error prone because of 
message sequencing issues.  Thus you have to take this kind of "carpet 
bombing" approach to flush out any potential instances the invitee already 
has.  All because there is no way to match RECURRENCE-IDs at different 
SEQUENCE values when they in fact are the same instance.

3: If this fragment is to add a new ATTENDEE to all the instances (or a 
set of instances) then its assuming that all instances share the same 
SEQUENCE value.  (Do they Doug???)  Since each instance can have its own 
workflow independent of its peers and thus have different SEQUENCE values, 
doing this kind of setting SEQUENCE to 1 instances value means _all_ 
responses (REPLYs, COUNTERs, etc)  from _all_ current ATTENDEEs at 
previously valid SEQUENCE values are NO LONGER VALID AND MUST BE 
renegotiated. 

#3 is quite significant so lets focus on it for a minute shall we. 

Lets say that RECURRENCE-ID:Jan-1 is at SEQUENCE:6, RECURRENCE-ID:Jan-2 is 
at SEQUENCE:10 and RECURRENCE-ID:Jan-3 is currently at SEQUENCE:4  since 
each can be has was negotiated separately.  In order for the Dougs 
fragment to be usable by an invitee it means therefore then that the 
Organizer must rev the SEQUENCE values of all instances below SEQUENCE:10 
up to 10.  This means that any REPLYs (sic) current invitees send back 
that ordinarily would be valid (and thus accepted by the Organizer) are 
now 'obsolete' because they contain SEQUENCE:6 (for Jan-1) or SEQUENCE:4 
(for Jan-3) which are now deemed "obsolete" by iTIP.  As such they MUST be 
ignored (per iTIP) and a new REQUEST must be sent to the existing invitees 
too.. 

All this even though the ONLY thing that happened was that a new invitee 
got added.  No reschedules happened, the Organizer just needed a fast way 
to get the recurrence set onto the new invitees calendar.  Sounds like a 
great reason to invalidate all other REPLYs that would otherwise be 
acceptable. 

> above instances was Jan-4. It is useless trash to the CUA at that point.

Yep, its an example for the delta RECURRENCE-ID world.  What he says is 
not legit in the fixed RECURRENCE-ID world and the fragment at top is 
equally malformed for the fixed model.  Go see last months explcit 
examples if you want to see the details on how easy and non-destructive 
adding new invitees to an existing set is.

> REPLY'd UID/SEQUENCE/RECURRENE-ID set) 

You get the ordering wrong.  iTIP says use UID / RECURRENCE-ID as primary 
keys and then you use SEQUENCE as the secondary key.  This from Section 
2.1.5 in case you need to check it out (or ignore it).

You use UID / RECURRENCE-ID to find the specific instance.  If you do not 
find a match then if you correctly apply iTIP 3.2.2 REQUEST you'd say that 
the UID / RECURRENCE-ID was not found and treat this as an initial 
invitation for the particular instance.  If you find a match THEN you use 
SEQUENCE to see if your copy is obsolete or not.  If your copy is obsolete 
(or you had to further use DTSTAMP to detect this) then you apply iTIP 
3.2.2.1 Rescheduling an Event and treat it as the reschedule that it is.

>                                        and if a RECURRENCE-ID has 
changed
> order to process the update or cancel.

I guess you did not see iTIP Section 3.2.2 REQUEST when it says:

Since this is referring to a recurrance instance you should use "UID" / 
"RECURRENCE-ID" in place of "UID" in the text above (by Section 2.1.5 
Message Sequencing bullet 1).  If you do not find the UID / RECURRENCE-ID 
then its an invitation to the instance in question.  No stuggling, no 
mess, no fuss, no ambiguity.

>                                        Is all that can be known is that 
one
> you fixate on SEQUENCE:0 instance times.

It sounded like there was going to be a quesiton there but I only see a 
comment. 

If Im not redefining the recurrence set, merely rescheduling instances or 
adding ATTENDEEs then the RECURRENCE-ID will be the same at SEQUENCE:10 as 
it is for SEQUENCE:0.  In additon adding a new ATTENDEE to any / all 
instances is SIMPLE and EASY without causing thrashing with the existing 
ATTENDEEs.  The same cannot be said for the changing RECURRENCE-ID model. 
(See above for why.)

> or will be a change to an effective DTSTART instance *if* your

I gave full examples last month of exactly how a new ATTENDEE gets added 
after the fact to one or all instances so clearly you do not understand 
the examples or the explainations so far.  The same examples can be used 
for the 'some' instances case too so dont try to claim that either.

What I think some folks fail to realize is the behaviour implications of 
your model so I strongly urge everyone to be sure the points at the top 
are well understood, they should give you plenty of concern over using a 
'delta' RECURRENCE-ID model.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 17:24:00 -0600

> is not the iCalendar RFC 2445 model.

How about responding to the email that showed why your model
is broken?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 07 Aug 2003 17:31:49 -0600

[email-masked] wrote:
> My example was for a particular instance at SEQUENCE:10 and your 
> response was for the entire set I assume.  This is mixing apples and 
> kiwis.  We've been discussing how instances are affected so lets try to 
> stay focused shall we.

No, I am showing why your model does not work. Please respond
to the text submitted. Why will you not respont to the problem
that I submitted? Why? Your model is broken Bruce. You can
not update that VEVENT can you Bruce?

--

---

From: Tim Hare <[email-masked]>
Date: Thu, 07 Aug 2003 23:16:48 -0400

OK - after some more of this back-and-forth on the RECURRENCE-ID 
discussion, and from some other reading and side e-mail pointing out to me 
that all occurrences of a recurrence set are not necessarily instantiated 
in the CS (for example infinitely recurring events),  I now feel a little 
differently about some of this.  Someone posted an example where you change 
the time for one of the "parts" of a recurrence set.  To me that showed 
that the RECURRENCE-ID _does_ change, IF its identifier is defined as in 
the spec - basically the DTSTART of the instance.  It _has_ to change, 
under that definition, if the time of the instance changes.  This to me 
makes it easier for the CUA to determine the RECURRENCE-ID of an event 
(merely pick the starting timestamp) when making requests; this also 
explains to me that UID is the one and only "key" to my hypothetical CS 
"database".  I think it _may_ cause some synchronization issues when a 
CUA  and CS/CUA are looking at the same recurrence set but with different 
recurrence IDs  [if A thinks the set consists of (x,y,z) and B thinks the 
set consists of (x,y,q)] but I _think_ the use of SEQUENCE resolves who 
wins in a "debate" situation.

Now - whose model did I just say was OK and whose did I say was broken? 
I've been getting lost on that count. Have we been discussing the protocol, 
or potential implementations?

Tim Hare
Senior Systems Programmer
Florida Department of Transportation

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 8 Aug 2003 00:15:03 -0700

Not that clarification helps at this point but here
goes anyway.

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> The RECURRENCE-ID is use to refer to an existing instance.

The snippet was used in the context of establishing the
instance I was going to be manipulating.  I could have
just as well said "First lets establish the instance we
are going to play with".  However, the mindset I had when
writing that snippet was inviting a new ATTENDEE (the reader)
to that particular instance of an existing recurring event.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 7 Aug 2003 23:53:34 -0700

> I've been getting lost on that count. Have we been discussing the
protocol, > or potential implementations?

At the moment you're in the delta RECURRENCE-ID camp otherwise
known as Doug's camp on this thread.

We've been discussing update semantics for recurring event
instances.  Most(All?) the major existing (not potential)
implementations use the fixed REUCRRENCE-ID model.  This
is really the only tenable implementation and in addition
is also very elegant (simple and efficient).

Bruce's first email of 8/4/2003 does an extremely good
job at pointing out the numerous flaws in the model
where the RECURRENCE-ID changes.  I should note here
that I actually switched camps as a result of his email
and ever since the world has gotten a lot clearer. ;)

The RECURRENCE-ID doesn't have to change if an instance
gets updated.  There is one section of iTip that actually
blatantly says that it does change, but when taken in the
context of the rest of the protocols and actually having
to implement it becomes very clear that this text is an
error and needs to be updated.

As Bruce has so eloquently pointed out if the RECURRENCE-ID
changes, then a whole lot of things start to go wrong very
easily, thrashing (lots of feedback loops trying to get
resynchronized) abounds, and the whole system becomes very
fragile overall in the presence of missed/lost messages.
iTip very explicitly in multiple places all over the place
goes through great pains to describe an implementation that
is very tolerant of missed/lost messages and using a
changing RECURRENCE-ID blatantly violates that principal.

The lines in iTip, which those in the fixed RECURRENCE-ID
camp have declared as an error and are invalid and MUST
be ignored are:

    The property value is

This should read something to the effect of:
    The property value is
    equal to the date/time of the orginal SEQUENCE: 0 instance.
    If the "Organizer" wishes to change the "DTSTART", the
    original "DTSTART" value is used for the "RECURRENCE-ID" property
    and the new "DTSTART" and "DTEND" values reflect the change.
    Note that after the change has occurred, the "RECURRENCE-ID"
    is still at its original SEQUENCE: 0 value.

While I would never advocate such a thing be done without
serious deliberation, Bruce's first email of 8/4/2003 does
such a good job of explaining how iCal is designed to function
as a fixed RECURRENCE-ID (both technically and lexically) that
the only conclusion I am left with is that those lines that
are referrenced by the delta RECURRENCE-ID camp are really
the only support for such a model and is incosistent with
the intent of the protocol.

Doug has currently asserted that certain things are impossible
to do with a fixed RECURRENCE-ID model, but so far I have found
all of his claims to be in error.  The list is still busy
responding to his claims but it is taking a while to sort it out.

He has one particular example where he says:

  In Bruce's model you can NEVER add someone to the series
  of recurring VEVENT after any change that effects the
  effective  DTSTART value of any instance as they could never
  be able to resolve the RECURRENCE-ID because they never
  had SEQUENCE:0.

His claim seems to be based on at least two very false
assumptions.  The first mentioned above that an end user
needs the SEQUENCE: 0 version in order to locate the
instance in question, and from one of his other posts
that a RECURRENCE-ID cannot exist in the creation of a
VEVENT because its presence means an update to an instance
that already exists when it actually doesn't exist.

I'm not going to quote text just yet, but in following the
reponses to these assertions by both Bruce, and Robert it
was very clear to me that it is never required that a
CUA have the SEQUENCE: 0 version in order to participate
in a VEVENT series and/or instance thereof.

To add an Attendee to an entire series you simply add the
attendee to the latest SEQUENCE version of the UID with no
RECURRENCE-ID and then send along with it all recurrences
instances that have been updated and have SEQUENCE > 0
with the Attendee added.  To invite an Attendee to a single
recurrence instance you simply send them a copy of the
latest UID/RECURRENCE-ID/SEQUENCE version with the attendee
added and be done with it.

Using a fixed RECURRENCE-ID model each instance has a fixed,
unique, and permanent RECURRENCE-ID that is always the
same regardless of which SEQUENCE version of the instance
you happen to receive.  The RECURRENCE-ID is listed in every
instance object and that ID can accurately, permanently, and
unambiguously identify each and every instance within the
set regardless of missed messages, out of order processing,
or other communication failure.  If a VEVENT should show up
that the existing calander isn't aware of then per the iTip
rules that Bruce has referenced the CUA just poofs it into
existence and starts working with it.  It is treated as the
initial invite and goes from there.

As a result of the fixed RECURRENCE-ID model, any future
or past messages the CUA might get that refer to that
particular instance are easily, quickly, and unambiguously
identified and processed.  Using a delta RECURRENCE-ID model
this kind of interaction (out of order processing)
becomes very ugly very quickly.  The single most blatant
counter to any thought of using a delta RECURRENCE-ID is
that it is completely intolerant of missing any message
that modifies the start time of an instance.  Contrary to
the fixed RECURRENCE-ID model where these messages are
processed with nothing but a passing notice that they
were out of order.  See Bruce's first 8/4/2003 email
for details.  Making the fixed model a technically more
elegant model, you combine this with the numerous
references that iTip must operate in the face of failed
communication and a changing RECURRENCE-ID model quickly
because an unworkable solution.

There is an exception to the permanently fixed part above.
If you should change the set, most likely because you
changed the RULES that create the set, then the
RECURRENCE-IDs may change (for instance, the VEVENT
object said every Friday, and you changed it to every
Monday - as a result of this, the new fixed RECURRENCE-ID
for each instance will now reflect Mondays, and not
Fridays as it was previously).  However, this conversation
is not dealing with changing the set description of the
master VEVENT, it's dealing with updating instances that
occur when that set description is instantiated.  So in
that limited context, the RECURRENCE-IDs are permanent.

His second assertion, that the presence of a RECURRENCE-ID
means an update to an existing instance, is also false as
he puts it forth.  iTip is very clear about what to do if
the UID/RECURRENCE-ID pair exist in the calander store.
You treat it as an update to this existing event.  However,
you have to fall back to other rules if the pair do not
exist.  Doug seems to have fallen into the belief that
if you receive a message that has a UID/RECURRENCE-ID and
you do not have an existing UID/RECURRENCE-ID to match
that message that it is an iTip error.  This is simply
not true.

The technical issues of both that there are absolutely
cases where a RECURRENCE-ID MUST exist in the creation
of a VEVENT and the technical requirement of being able
to process out of order and lost messages aside, there
are no sections in iTip that support his claims.

He claims:
"
The only times that RECURRENCE-ID can exist in a VEVENT is:

    When REPLYing to an existing instance and if present indicates
    that the sender is only replying to that named instance.

    Updating an existing instance in an existing recurrence set.

    CANCELing an instance in an existing recurrence set.
"

He's probably not wrong about this, however he's using to
narrow a vision of when a CUA might receive these messages
and doesn't seem to realize that there are other portions
of the text that tell a CUA how to handle unexpected messages.

For instance the second item about updating.  He's right in
that I would be sending out an update to an existing instance
of a recurring set, however he's wrong in that you the recipient
would already know about it.

An instance of a recurring event is a VEVENT in its own right.

There is nothing that I have found in the text to make me
believe otherwise and both technical implementation and
comments by others smarter than I about this concur.

Doug seems to believe that an instance of a recurring event
only exists if the CUA happens to know about the master template.
And indeed, everything he claims to be impossible seems to
follow from this belief.

If I send you a message that contains:
UID: 1
SEQUENCE: 3
RECURRENCE-ID: 20031231T180000Z

I am telling you about instance 20030101T120000Z of UID 1.
Whether or not you previously knew about EVENT UID 1 or
even SEQUENCE versions 0,1, and 2 is completely
inconsequential.  The rules of iTip as Bruce has referenced
many times make this so.  In fact, as per the "add an Attendee"
subthread, this instance may be the only instance of UID 1
that you ever see.  I might be kind enough to tell you about
a second instance:

UID: 1
SEQUENCE: 3
RECURRENCE-ID: 20041231T180000Z

In which case you'd just add this VEVENT to your calander too.
Again, not knowing about UID: 1, or SEQUENCE versions 0,
1, or 2 is harmless in a fixed RECURRENCE-ID model.

If I should tell you about UID: 1 then you can interact
with it and do more than just mess with the two individual
instances I told you about, and if you receive info on
SEQUENCE versions 0,1, and 2 you will dutifully ignore them.

-- Michael --

"Tim Hare" <[email-masked]> wrote in message
news:[email-masked]...

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 8 Aug 2003 03:51:56 -0700

> thus no RECURRENCE-ID to match.

Indeed, I grant you that the use of the term "effective" does
tend to call for the use of a changing RECURRENCE-ID.  But it
doesn't, and I'll show you why a little later.

So further down in the IMAP definition, we find this text:

   For a given pair of "UID" and "SEQUENCE" property values,
   the "RECURRENCE-ID" value for a recurrence instance is fixed.

So here's how I read this:
There is a UID which describes a recurrence set.  That UID has
a SEQUNCE value which identifies the set it describes.  This
reading is supported by the part that describes how the SEQUNCE
changing reflects a set description change which in turn could
modify the RECURRENCE-ID of the set instances.

So for examples sake, let's again use UID: 1
and say that SEQUENCE: 0 describes every Friday this year.

So for UID 1/SEQUENCE 0 the RECURRENCE-ID for each instance
is "fixed" at the Fridays of this year.  If I move one of
those instances (say June, Friday the 13th) to Thursday.
Then I update that particular instance's SEQUENCE to 1.
This is only an update to the SEQUENCE for that specific
instance's calendar component not for the parent UID 1
set descriptor.  The UID/SEQUENCE pair has not been updated.
The (UID-RECURRENCE-ID)/SEQUENCE pair (or triplet depending
on how you want to describe it) has been updated and has
no relevance to whethere or not the RECURRENCE-ID is fixed.

This view is supported by order of precedence for locating
an instance, first the UID, then the RECURRENCE-ID are primary
lookup keys, the RECURRENCE-ID can be NULL which means
different things in different contexts, and then the SEQUENCE
is used as a secondary lookup.

In other words, by moving an instance to Thursday I have
not modified the description of the recurrence set specified
by UID 1/SEQUENCE 0 and therefore the RECURRENCE-ID remains
fixed.  Consequently, for the pair UID 1/SEQUENCE 0, the
RECURRENCE-ID for June, Friday the 13th remains fixed
regardless of what I do that particular instance of UID 1
in the context of SEQUNCE 0.  In essence, I've simply said
that June, Friday the 13th's instance actually occurs on
Thursday now.

So let's go back to that other quote that seemed to
imply a changing RECURRENCE-ID.

>     The property value is the effective value of the
>     "DTSTART" property of the recurrence instance.

The "effective value" here is referencing the UID/SEQUENCE
pair, not the effective value of an instance that's been
updated.  This must be the case because
"for a given UID/SEQUENCE pair the RECURRENCE-ID value
for a recurrence instance is fixed".

However, if you update the recurrence set description,
and consequently update SEQUENCE for that UID, then
you must recalculate all the instances in the set and
they may have a new DTSTART.  To account for the
ability for the RECURRENCE-ID to change in this way
you must use "the effective value of the DTSTART
propoerty of the recurrence instance".

The only model under which all the paragraphs make
sense is the one where the RECURRENCE-ID is fixed
within a given set description of an event.  The
simplest way to express this in terms programmers
can easily adhere to is that for a given UID/SEQUENCE
pair (meaning a particular recurring set description)
the RECURRENCE-ID value for a recurrence instance
is fixed.

Once UID 1/SEQUENCE 0 hits UID 1/SEQUENCE 1 (which would
mean something significant about the set of instances
has changed) all bets are off in regards to RECURRENCE-ID
values that previously existed.

> be able to resolve the RECURRENCE-ID because they never

This is just plain false.  Given my "every Friday for this
year" example above, with the June 13th modification to
June 12th, to invite someone to the entire series I would
send them a
VEVENT REQUEST containing:
UID: 1
SEQUENCE: 0
describing every Friday this year
with them as an ATTENDEE

and simoultaneously also send them a
VEVENT REQUEST containing:
UID: 1
RECURRENCE-ID: Friday, June 13th
SEQUENCE: 1
describing Thrusday, June 12th
with them as an ATTENDEE

In "Bruce's model" I could even send those two objects
out of order and you'd still be able to accurately process it
which debunks your claim that they couldn't resolve the
RECURRENCE-ID because they never had SEQUENCE: 0.

I don't mean to be trolling here, but isn't it in fact
the changing RECURRENCE-ID model that has the problem
with dealing effectively with lost / missing messages?

> ...T200000Z  3rd instance (effective DTSTART)

So good so far.

> So per iTIP they could send a new REQUEST SEQUENCE:1 :

Also so good so far.

> As the RECURRENCE-ID is the effective DTSTART value

Oooops just violated:

   For a given pair of "UID" and "SEQUENCE" property values,
   the "RECURRENCE-ID" value for a recurrence instance is fixed.

Since you didn't provide a UID in your examples (how strange)
let's go ahead and use UID: 1

First you defined UID 1 with three events, then you updated
one of those instances.  This was fine, but when you listed
the new RECURRENCE-ID's you seemed to miss that you haven't
redefined the recurrence set of UID 1, just updated the DTSTART
of an instance whose effective DTSTART is still defined by
UID 1/SEQUENCE 0.

UID 1 and UID 1/RECURRENCE-ID ...T190000Z are two totally
separate calendar components which each track there own
SEQUENCE values.

> and move its LOCATION to 'B'.

Woaaahhh you have two problems here.

First the 3rd instance is actually RECURRENCE-ID: ...T200000Z
which you were trying to DTSTART to ...T190000Z and move to
location B so you're example message wrong, but I can work
with what you intended.

The second problem is that you just jumped two SEQUENCE values
when you've only made one change to this object.  You haven't
touched the 3rd instance prior to this point, and the update
above to the second instance did not update UID: 1, it updated
UID: 1/RECURRENCE-ID: ...T190000Z so this is actually a
SEQUENCE: 1 move for UID: 1/RECURRENCE-ID: ...T200000Z.

Remember that:
UID: 1 and
UID: 1/RECURRENCE-ID: ...T180000Z and
UID: 1/RECURRENCE-ID: ...T190000Z and
UID: 1/RECURRENCE-ID: ...T200000Z

are totally separate objects which persist their own SEQUENCE.

>      (used to be the 2nd instance)

This is actually totally screwed up at this point with
exception of the first instance.

There are four components involved in this event at this
point and they are described as follows:

UID: 1 - describes three instances starting an hour apart
     at Location: A
UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched
     at Location: A
UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T193000Z
     at Location: A
UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z
     at Location: B

This is important to note for you to see the flaw in your
later assertion that "in Bruce's model, you're broken".

> Now change the SEQUENCE:2 2nd instance to ...T200000Z:

This actually needs to read:
"Now change the SEQUENCE:1 version of the 2nd instance
 to ...T200000Z"

This will actually be a SEQUENCE: 2 update for the 2nd instance.

> RECURRNCE-ID:..T200000Z

First off you totally screwed the pooch on mixing up the
RECURRENCE-ID and DTSTART again.  Secondly you're just being
sloppy or you're getting models confused because up to now
you seem to have been using a changing RECURRENCE-ID model
which would make the ID for the 2nd instance ...T193000Z.

> because its impossible to resolve.

Again, this is a totally bogus assertion.
The above message should actually read:

METHOD:REQUEST
SEQUENCE:2
DTSTART:..T200000Z
RECURRNCE-ID:..T190000Z

I don't quite understand what you are asserting is broken.
If you first create three events at Location: A, you then
move the time on the second, and then the time and the
location on the third, and then just the time again on
the second.  You end up with the first two events at
location A, one starting at 1800Z, the other at 2000Z,
and the thrid event at location B starting at 1900Z.
What's broken about that?

This would leave us with the following four objects:
[Note:  The first instance may or may not actually
be represented in the calendar store since it was
never actually modified from its original description]

UID: 1 - describes three instances starting an hour apart
     at Location: A - SEQUENCE: 0

UID: 1/RECURRENCE-ID: ...T180000Z - hasn't been touched
     at Location: A - SEQUENCE: 0

UID: 1/RECURRENCE-ID: ...T190000Z - DTSTART: ...T200000Z
     at Location: A - SEQUENCE: 2

UID: 1/RECURRENCE-ID: ...T200000Z - DTSTART: ...T190000Z
     at Location: B - SEQUENCE: 1

> in ways that alter the effective DTSTART value for an instance.

The "effective DTSTART" is per the UID / SEQUENCE set description
pair, not the UID/RECURRENCE-ID / SEQUENCE pair.  Otherwise you
conflict with:

   For a given pair of "UID" and "SEQUENCE" property values,
   the "RECURRENCE-ID" value for a recurrence instance is fixed.

> instances and the RECURRENCE-ID is defined to match the

I hold that the "Note" mentioned above which is a main crux for
the changing RECURRENCE-ID understanding is an actual RFC error
and was not the intent of the authors.  That text appears in one
place, however in numerous places throughout the RFC iTip goes
to great pains on several occasions to talk about how iTip must
be tolerant of missed/lost messages.  In the changing RECURRENCE-ID
model this idiom is severely violated since it is not tolerant
at all to missequenced messages and especially volatile in the
presence of lost messages.

Further, the "effective DTSTART", is the DTSTART of the instance
as described by the recurrence set in the event object and not
the current DTSTART for any given instance.

Ok, now this next part we all totally agree on!!!!

> DTSTART values (RECURRENCE-ID).

Absosmurfly! Without question! and with violent agreement, Yes!

Updating to SEQUENCE: 1 on the base event object, by for
instance doing a recurrence set description update like
the above, in every way, shape, and form throws all
RECURRENCE-IDs from the SEQUENCE: 0 version into doubt.

I am in total agreement, as is Bruce from what I've read,
that this kind of change, one in which no RECURRENCE-ID
is referenced to limit the scope to a single instance
but instead operates on the whole set of instances, totally
presents the possibility that the RECURRENCE-ID of the
instances will change.  In fact, the new RECURRENCE-ID
will be the bewly updated "effective DTSTART" value.

This new set of RECURRENCE-IDs will remain "fixed" for
as long as the event set descriptor maintains its same
SEQUENCE value.  Should another change update the set
descriptor object to SEQUENCE: 2, the entire set of
RECURRENCE-ID MUST be recalculated to their new effective
DTSTART values.

It seems to me that main crux to the differences here is
a different understanding in the handling of the SEQUENCE
values in relationship to the several calendar components
that exist to serve a single recurring event.

I'm too tired to look it up now, but the section on what
objects must persist under what circumstances should
clear up that issue.  So at the moment, given lack of
text to back me up, I can only contend that the RFCs
specify that for each recurring event there are two types
of calendar components.  One type is the event descriptor
itself (UID with no RECURRENCE-ID) and the other type is
a recurrence instance within that set (UID and RECURRENCE-ID)
and that every one of these objects tracks its own
independent SEQUENCE value.

-- Michael --

---

From: [email-masked]
Date: Fri, 8 Aug 2003 11:55:22 -0400

> known to the ATTENDEE CUA after (or when) then REPLY to the SEQUENCE:0

The implication I got was that there was no RECURRENCE-ID assigned until 
the SEQUENCE:1 version was booked since you made no mention of all about 
the RECURRECE-ID for the SEQUENCE:0 versions REQUEST.  I didnt intend to 
misquote you. 

In any case, the RECURRENCE-ID from the SEQUENCE:0 REQUEST is assigned 
when the instances are created; thats the original DTSTART value of each 
instance.  As such it exists and is (or can be) used before the SEQUENCE:1 
REQUEST arrives.

Its perfectly legal for an invitee to send back a REPLY at SEQUENCE:0 for 
a particular RECURRENCE-ID and not have to wait for SEQUENCE:1.  After all 
its perfectly valid to accept/decline/counter/delegate a particular 
SEQUENCE:0 instance and as such the RECURRENCE-ID in that REPLY must 
match.

Bruce

---

From: [email-masked]
Date: Fri, 8 Aug 2003 12:14:21 -0400

> then it is a modification to an existing VEVENT, not a new

Its becoming clear to me that you are not quite clear on the concepts of 
message sequencing or missequencing or message loss.

There is NOTHING in iTIP that says "An invitation has no RECURRENCE-IDs" 
or "You cannot/MUST NOT use RECURRENCE-IDs in an invitation" or "The 
REQUEST at some magic SEQUENCE value is an invitation, all others are 
reschedules.", etc. 

Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a UID 
and RECURRENCE-ID if you are only inviting someone to a particular 
instance of the set.  A simple example of this is I schedule a repeating 
meeting with Bob and Pat and they both accept all instances.  Pat also 
sends back a COMMENT:Shouldnt Doug come to Fridays Social?  I agree so I 
select the Friday instance and add you which results in a SEQUENCE:0, 
RECURRENCE-ID:<Friday> REQUEST being sent to you.  You should apply iTIP 
Section 2.1.5 Message Sequencing rules and the text from 3.2.2 (below) to 
treat it as an invitation.  No need for me to rev SEQUENCE to 1 just 
because I add you.  Doing so would just invalidate the participation 
status of Bob and Pat so Id have to reREQUEST them...

Because of message sequencing concerns what the Organzier sends as a 
reschedule may be the only REQUEST received by the invitee and thus they 
rightly view it as an invitation.   We have no defined settings or 
property combinations that differentiate invite from reschedule from 
non-reschedule update from anything else.  The distinction is inferred by 
the recipient based on the properties in it.  This is described in iTIP 
with text like:

from 3.2.2 REQUEST or from 3.2.2.1 Rescheduling an Event:

   The "REQUEST" method may be used to reschedule an event. A
   rescheduled event involves a change to the existing event in terms of
   its time or recurrence intervals and possibly the location or
   description. If the recipient CUA of a "REQUEST" method finds that
   the "UID" property value already exists on the calendar, but that the
   "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
   greater than the value for the existing event, then the "REQUEST"
   method describes a rescheduling of the event.

Because iTIP messages are not guaranteed to arrive in any particular order 
(or can even be lost), we created the guidelines in Section 2.1.5 Message 
Sequencing to be applied to all iTIP methods and thats exactly why each 
methods data is totally self contained and NEVER relys on any data from 
previous messages. 

However, if you build a delta RECURRENCE-ID model then you have just built 
an implicit reliance on each and every iTIP REQUEST being deliverable and 
in order at that.  This is a poor design because this reliance is not 
always possible and thus fault prone and hard to recover from.

Perhaps I need to put out an example w/iTIP fragments to demonstrate this 
but in the mean time I would suggest that you go reread iTIP regarding 
message sequencing and how the recipient is supposed to treat/decode the 
REQUEST, etc.

Bruce

---

From: [email-masked]
Date: Fri, 8 Aug 2003 12:23:31 -0400

> Yes you can also use RANGE if that is what you meant to say.

RANGEs are a whole other ball of wax that are not germane to this thread. 
My point is that you did NOT list RECURRENCE-ID as being valid on a 
REQUEST as an invitation too which I pointed out it was.

Also, what you said about creating a recurrence set of 1 instance is NOT 
something that iCalendar/iTIP consider repeating.  If there are no repeat 
instances then its non-repeating and has no RECURRNECE-ID.  Being invited 
to a single instance is NOT the same as saying there is only 1 instance in 
the repeat set.  The invitee only knows about the instances they are 
involved with, the Organzier who owns it knows of them all!  (You did say 
"set even when the recurrence set has only one instance." right??.. so Im 
not misquoting you). 

Do not assume that each ATTENDEE knows about each and every instance; that 
is not required by the RFCs nor it is logical from a workflow point of 
view.  There is no way to distinguish those instances you were actually 
invited to from those you are just told about so you can ignore or so you 
can roll out some RECURRENCE-IDs from,  As such, REQUESTs only refer to 
instance(s) involved in invitations, reschedules, etc and do not refer to 
instances that are not relevant to the Organziers intent.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 10:52:17 -0600

> no relevance to whethere or not the RECURRENCE-ID is fixed.

I am confused reading your above paragraph. Are you saying
that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes
that is my point.

> describing Thrusday, June 12th

Bruce clamed that you did not have to remember SEQUENCE:10.
Your claiming you do. Are you sure you and Bruce are
talking the same model?

You are claming that the ORGANIZER must figure out and
send the ATTENDEE a correct set of all sequences starting
at SEQUENCE:0 up to the current sequence, and process a reply
for each sequence (because that is how it is done). Why go
through all of that? Why not just send ONE REQUEST/VEVENT
with the latest state? No RECURRENCE-ID needed no need
to force the ATTENDEE CUA to REPLY to X number of REQUESTS
only to immediately throw X-1 away and end up with with
what could have just been ONE REQUEST/REPLY ? That is not
a simplification.

Assuming that what you are saying is true, think of
a public calendar where hundreds of people may be
added and removed to a series of public events. Do you
really want to process (SEQUENCE*new-ATTENDEE) objects and
REQUEST/REPLYs? When it could just be (1*new-ATTENDEE)
REQUEST/REPLY packets?

The assertion (by someone) that this is  simpler is an attempt
to declare that a new way of doing things is iCAL/iTIP. No it
is not.

Your example covers a case that works, what about the one I described
that did not work?

> with dealing effectively with lost / missing messages?

No, because the they map to the UID/SEQUENCE and DTSTAMP.
So if you get SEQUENCE:10 and did not get SEQUENCE:9, follow
the rules of iTIP and you will now you do not care about
SEQUENCE:9 as you have the SEQUENCE:10. If it is a modification
to an instance to SEQUENCE:10 (because it has a RECURRENCE-ID),
then follow the rules in iTIP - wait abd then to a REFRESH if
it does not arrive

It works in any order and with missing objects.

>    the "RECURRENCE-ID" value for a recurrence instance is fixed.

Oooops that means per set - and nope, I updated the set.

--

---

From: [email-masked]
Date: Fri, 8 Aug 2003 13:01:52 -0400

Sorry Doug your wrong.

iTip 3.2.2 REQUEST

_____________________
Note: new email address

08/07/2003 06:15 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

                 ...Note the use of "RECURRENCE-ID" property and 
"SEQUENCE"
                 property in the second request.

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 12:53:38 -0600

> message sequencing or missequencing or message loss.

Its becoming clear to me that you did not understand iTIP when you
wrote your project and you did not know that these new proposals
of yours were already covered in iTIP and we do not need new ways
to do things that are already documented.

> REQUEST at some magic SEQUENCE value is an invitation, all others are 

Exactly - you are proposing a new way to invite ATTENDEEs. And it is not
needed.

> Its perfectly legal and valid to have a REQUEST for SEQUENCE:0 with a 
> UID and RECURRENCE-ID.

How do you disambiguate that from an update to a missed object?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 12:54:59 -0600

[email-masked] wrote:
> RANGEs are a whole other ball of wax that are not germane to this 
> thread.  My point is that you did NOT list RECURRENCE-ID as being valid 
> on a REQUEST as an invitation too which I pointed out it was.

So - HOW DO YOU DISAMBIGUATE IT FROM AN UPDATE TO A MISSED OBJECT
      AS IT LOOKS EXACTLY THE SAME ?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 12:57:26 -0600

> Sorry Doug your wrong.

So rather than discuss the text in iTIP I sent, you want to
just declare your beliefs. Thanks for sharing, but it
does not make an update to a instance go away.

So - how  do you disambiguate it from an update to a missed object?

--

---

From: [email-masked]
Date: Fri, 8 Aug 2003 14:43:30 -0400

Tim wrote on 08/07/2003 11:16:48 PM:
>                              Someone posted an example where you change 

> under that definition, if the time of the instance changes.

Interesting analysis but lets take a look a couple bits from the RFCs and 
see if that still holds true.  The issues of how a CS manages internal 
storage is not germane to the data format (iCalendar) or the messaging 
protocol (iTIP); its strictly an internal issue.  Not every C&S product 
supports the exact same featuresl ike infinite recurrence and thats 
factored into iTIP (ie: under iTIP 3.6 Status Replies).  The concerns 
should be how well the model can represent C&S functionality and how well 
workflow performs.

First off, iCalendar defines the use of RECURRENCE-ID as:

                                                  The "RECURRENCE-ID"

and it later adds:

   instance would occur;

So it should be clear that the RECURRENCE-ID value is supposed to be the 
initial DTSTART value for the instance in question.  However even if its 
not it is necessarily so due to the message sequencing problems that can 
affect iTIP. 

If your iTIP REQUESTs get missequenced and your model relys on each 
previous SEQUENCE values RECURRENCE-ID value to calculate the next one 
then you cannot recover workflow for just that instance; you can only 
recover by recreating ALL instances (the infamous 'full REFRESH').  There 
is no way to guarantee that each and every REQUEST gets there and in the 
correct order; some may never arrive or they may be delayed out of 
sequence.

So the only thing the user can do is toss out ALL instances and wait for 
the Organizer to resend 'em all in a new REQUEST.  This brings workflow to 
a grinding halt for that invitee.

However, if your RECURRENCE-ID is fixed then you can quickly and easily 
recover from any missequenced REQUESTs.  Since the recipient can uniquely 
and unambiguously identify the instance in question based on the UID / 
RECURRENCE-ID pair in a fixed model, they can easily find the correct 
instance in question and then use SEQUENCE (and DTSTAMP) to resolve 
missequencing.

For example, using a fixed RECURRENCE-ID, I send you a SEQUENCE:0 
invitation (MsgA), a SEQUENCE:1 reschedule (MsgB) and then a SEQUENCE:2 
reschedule (MsgC) for a particular instance.  If they arrive in reverse 
order (MsgC, MsgB, MsgA) or even missing/missequenced (MsgC, MsgA, no 
MsgB) then no problems exist and recovery is trivial.  Lets see why.

MsgC arrives.  You check for the UID / RECURRENCE-ID value and do not find 
it.  So by 3.2.2 REQUEST you treat it like an invitation to the instance 
and put it on your calendar.  You send back a UID / RECURRENCE-ID / 
SEQUENCE:2 REPLY that I can easily match to my instances and everyone is 
happy.  Recovery was essentially nothing since nothing was wrong from your 
view.

MsgB arrives.  You check for the UID / RECURRENCE-ID  value and find it. 
You next check your SEQUENCE value and find it higher than the one in MsgB 
so you know that this REQUEST is obsolete and you safely ignore it.  No 
recovery needed.

MsgA arrives.  You perform the same steps as for MsgB and again no 
recovery is necessary.

Even if MsgB or MsgA never arrived, recovery was essentially not an issue 
or necessary.

If you move the arrival order around you will see that by properly 
applying iTIP 2.1.5 Message Sequencing rules its easy to recover from any 
problems.

Now, if we used a changing RECURRENCE-ID model and I send the same 
messages there are lots of problems to be concerned with.  Besides the 
issue of recovery there is also the issue of how to remove 'orphaned' bad 
entries in the invitees calendar.  Lets see this:

MsgC arrives.  You check the UID / RECURRENCE-ID and do not find it.  As 
such you treat it like a new instance invitation (which it is per iTIP 
3.2.2 REQUEST) and add it to your calendar.  You send back a UID / 
RECURRENCE-ID / SEQUENCE:3 REPLY that I can match to my instances and 
everyone is happy.  So far, no problems are noticed but they will soon 
start.  Recovery was essentially nothing since nothing was wrong from your 
view (or mine).

MsgB arrives.  You check the UID / RECURRENCE-ID and do not find it.  As 
such you incorrectly treat it like a new instance invitation (per 3.2.2 
REQUEST). and add it to your calendar.  Now you have RECURRENCE-ID:C and 
RECURRENCE-ID:B at different SEQUENCE values on your calendar instead of 
just RECURRENCE-ID:C.  You send back a UID / RECURRENCE-ID / SEQUENCE:2 
REPLY that I _cannot_ match to any current instance in my calendar.  As 
such I treat it like a mistake OR an attack on my calendar. 

If I decide to treat it like a mistake I toss the REPLY away and send you 
a new REQUEST with the latest UID / RECURRENCE-ID:C / SEQUENCE:3 info (per 
iTIP; MsgD).  Lets say that MsgD arrives before MsgA (just to keep the 
process moving along here).  You check the UID / RECURRENCE-ID value and 
find it.  You check the SEQUENCE value and find it matches what you have 
so you then check DTSTAMP against your existing one.  You detect that 
MsgD's DTSTAMP is newer than yours so the new REQUEST obsoletes the 
instance RECURRENCE-ID:C you already have so you replace that copy with 
the exact same data that you had already from MsgC.

At this point you would still have RECURRENCE-ID:B and RECURRENCE-ID:C on 
your calendar when you should only have 1 instance.  If MsgA now arrives 
you'd take the exact same actions that you did for MsgB and you wind up 
with 3 instances on your calendar instead of just the 1 you should have.

By applying the sequencing rules from 2.1.5 and the differentiation 
guidelines from 3.2.2 as described then you can wind up with many 
'orphaned' instances that do not belong.  Now the only way to get rid of 
these orphans is to do a REQUEST with NO RECURRENCE-ID value but a 
matching UID value; this has the effect of referring to the entire set of 
instances and thus I would have to remove all existing instances and then 
replace them with the new instances defined in the UID only REQUEST. 

However this approach is more than a little heavy handed when dealing with 
multiple separate instances because you essentially have to hose ALL 
unrelated instances as well as the orphans and the specific instance in 
question; just because you missed 1 REQUEST to 1 particular instance.

When we revised our model from a delta model to a fixed model this was one 
of the factors we considered.  There was no benefit in having a delta 
RECURRENCE-ID model because of the thrashing and extraneous iTIP messaging 
necessary and since each iTIP REQUEST was fully self contained, there was 
NOTHING we needed from any previous iTIP REQUEST so we had an additional 
benefit from the change.  The protocol became much more fault tolerant and 
efficient plus we minimized CUA confusion when referencing instances.

>                                                              This to me 
> (merely pick the starting timestamp) when making requests; 

Is it easier if you are referring to an instance whose date/time has 
changed but you NEVER got the rescheduling REQUEST and thus may not longer 
existing in my calendar? Just how would I match your delayed REPLY to an 
instance that no longer exists in my calendar?  The only way would be to 
keep a list of "previously known RECURRENCE-ID" values for each instance 
that you were invited to but even that can be defeated in 5 simple steps 
(see previous postings for 'em if you missed 'em).

If you were only invited to a single instance I could assume thats the one 
in question but then again not really viable or as reliable.

>                                                            this also 
> "database". 

The UID is only the primary key if the entry is non-repeating.  Otherwise 
the primary key is clearly defined to be UID / RECURRENCE-ID.  I dont 
think thats in dispute here (or are you disputing it?).  If RECURRENCE-ID 
is not part of your primary key then you cannot perform workflow on the 
instances indepently of each other unless you rewrite iTIP.

>             I think it _may_ cause some synchronization issues when a 
> recurrence IDs 

There are sequencing issues like the ones described above.  Thats why a 
fixed RECURRENCE-ID model is what we went for.  Recovery is trivail and 
fast and there is NEVER any ambiguity as to which instance the 
RECURRENCE-ID is referring to.  

> Now - whose model did I just say was OK and whose did I say was broken? 

You said that Dougs delta RECURRENCE-ID model was ok and that the 
iCalendar "fixed" RECURRENCE-ID model was broken. 

However, now that Ive shown you some of the problems inherent in dealing 
with message sequencing do you still think the same?

> I've been getting lost on that count. Have we been discussing the 
protocol, 
> or potential implementations?

It started as a discussion of whats in the published RFCs but Doug 
recently said its under the guise of discussing changes to iCalendar so Im 
not sure...  Ill keep treating it like an interpreation of the existing 
RFCs since we have no demonstrated need to literally invert the data model 
and destroy interoperability with existing implementations.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 08 Aug 2003 13:37:26 -0600

[email-masked] wrote:
> Interesting analysis but lets take a look a couple bits from the RFCs 
> and see if that still holds true.  The issues of how a CS manages 
> internal storage is not germane to the data format (iCalendar) or the 
> messaging protocol (iTIP); its strictly an internal issue.  Not every 
> C&S product supports the exact same featuresl ike infinite recurrence 
> and thats factored into iTIP (ie: under iTIP 3.6 Status Replies).  The 
> concerns should be how well the model can represent C&S functionality 
> and how well workflow performs.

I do not follow how or why you think his point has anything to do with storage
format. Are you saying because your storage format does not allow for
it to change that you want other vendors to change?

> then you cannot recover workflow for just that instance;

Not true and if you read iTIP from page one to last you will see
that there is an entire section devoted to that problem - with
a solution.

> ... you can only 
> recover by recreating ALL instances (the infamous 'full REFRESH'). 

Your new proposal holds a worse problem. Not only do you have to invent
new ways to invite attendees, you have to somehow remember what SEQUENCE:0
object would have sent them and do (current-SEQUENCE * VEVENT) object
to update them - MUCH more data than a REFRESH (which is documented), then
they have to REPLY to all of that. How is that better than a REFRESH?
How is sending much more data as SEQUENCE gets large better than
sending one REFRESH/REQUEST set?

>  There is no way to guarantee that each and every REQUEST gets there and 
> in the correct order; some may never arrive or they may be delayed out 
> of sequence.

Which is true of all models. A red herring as iTIP has an entire section
devoted to that solution.

> the Organizer to resend 'em all in a new REQUEST.  This brings workflow 
> to a grinding halt for that invitee.

As opposed to sending SEQUENCE*EVENTS if they are ever to get an update?

> recover from any missequenced REQUESTs.  Since the recipient can 
> uniquely and unambiguously identify the instance in question based on 
> the UID / RECURRENCE-ID pair in a fixed model, they can easily find the 
> correct instance in question and then use SEQUENCE (and DTSTAMP) to 
> resolve missequencing.

Fixed to a SEQUENCE they might not have? Your again ignoring all busted
examples sent to this list for your proposed model.

> MsgB) then no problems exist and recovery is trivial.  Lets see why.

Better yet - why not just point to iTIP and say - yes it is documented
in iTIP?
> issue of recovery there is also the issue of how to remove 'orphaned' 
> bad entries in the invitees calendar.  Lets see this:

So please clarify - you are indeed proposing a model that is not
compliant it iTIP? iTIP already has solved this problem. Trying
to get the world to do it your way because you do not like the
way iTIP does it is fine - but please do not pretend that iITIP
is busted, its not.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sat, 9 Aug 2003 02:33:41 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> property in the second request.

What does this have to do with making a new REQUEST?

Of course this example uses a RECURRENCE-ID and it is
an update because the recipient already has their calendar.

A new REQUEST _by definition_ is one for which the CUA
has never seen the UID before.  This example is totally
out of a context.  A REQUEST is sent to do lots of things.

Some of which are to request a new VEVENT, update an existing
event, reconfirm an existing event, reschedule an existing
event, and as a response to a REFRESH.

How the local CUA treats the REQUEST is clearly laid out
in Section 3.2.2 of iTIP where it explicitly states that
if it has never seen the UID before it's a request for a
new VEVENT calendar component.

I can't find anything in the text that says:
If it has a RECURRENCE-ID and METHOD REQUEST then it is
an update, but in every single example case the recipient
CUA already has a copy of the UID.
It is not a new appearance.

Even the example that triggers the REFRESH request only
does so because it has received a message for which the
UID/SEQUENCE it already has versus the one in the message
is a 2+ difference so it figured it missed some updates
and wants the latest updated copy.

Again, not a new instance of a UID which it has never
seen before.

> If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.

This is simply saying that if you want to modify a VEVENT
you include the RECURRENCE-ID to identify it.  Your local
calendar has seen the UID before, and all preexisting ATTENDEES
have also seen the UID before so therefore it's a RESCHEDULE
because the UID already exists and the SEQUENCE is larger than
what all of them have seen.  This is clearly defined in
section 3.2.2.2.

If the recipient CUA has never seen the UID before it is treated
as a new request as defined in 3.2.2

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Sat, 9 Aug 2003 03:58:47 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes

I am saying that there are two component types.
UID - describes a recurring set
UID/RECURRENCE-ID - describes an individual instance of
                    the above UID.

I am further saying that there is a seperate and distinct
SEQUENCE on each type that are completely unrelated to
each other.

So UID: 1/SEQUENCE: 0 is a totally different component
than UID: 1/RECURRENCE-ID: today/SEQUENCE: 5
and that the RECURRENCE-ID is "fixed" in respect to the
UID: 1/SEQUENCE: 0 pair.

> Your claiming you do. Are you sure you and Bruce are

That whole SEQUENCE: 10 thing was about inviting an ATTENDEE
to the SEQUENCE: 10 of a particular recurrence instance.

You asked how to invite someone to the entire series after
some per instance rescheduling had been done.  So that's
what I showed you.  If you like I can move the June 13th
instance around 9 more times and invite a new ATTENDEE to
the entire series.  At that point the SEQUENCE for the
June 13th instance will be 10, but the UID: 1 SEQUENCE
will still be at 0.

Inviting a new someone to an entire series after some
rescheduling has been done is the equivalent to a REFRESH
request by that ATTENEDEE so of course it has to include
all per instance data.  This is the same in either model.

What I am coming to realize is that in your world, redefining
the recurrence set, and rescheduling an instance are one and
the same action.

You can't say "The Friday the 13th instance occurs on
Thrusday the 12th".  You can only say, the set has been
redefined, Friday the 13th is now excluded and Thursday
the 12th is a new addition.

Here's the same request back at you.  We've shown you ours,
now you show me yours.

Create an event for every Friday of this year say 180000Z,
reschedule June, 13th's instance to the 12th, and then
invite a new ATTENDEE and show us the iTIP messages.

> for each sequence (because that is how it is done).

No I'm not.  You're stuck in thinking that all references
to UID: 1 are the same component.  They aren't.

UID: 1 / SEQUENCE: 0 describes a recurrence set.  It is
one calendar component.

UID: 1 / RECURREINCE-ID: Friday June 13th is a separate
component.  It has it's own SEQUENCE value that is
incremented independently of the UID: 1 component.

As I said (after shifting the event around 9 times) I could
have just as easily sent this to that new attendee:

and simoultaneously also send them a
VEVENT REQUEST containing:
UID: 1
RECURRENCE-ID: Friday, June 13th
SEQUENCE: 10
describing Saturday, June 14th
with them as an ATTENDEE

Once it has processed these _two_, not _eleven_,
messages the recipient's CUA will be totally up
to date with all the latest information including
the per instance information with reschedules.
Because it uses a fixed recurrence id for each
instance in UID: 1/SEQUENCE: 0 it can unambiguously
know that the instance that would have occureed on
Friday the 13th now occurs on Saturday the 14th
and never needs to concern itself with any SEQUENCE
version of UID: 1/RECURRENCE-ID: June 13th prior to 10.

> Why go

Because it would also be impossible for me to convey any
per instance changes (like venue changes or comments)
in just one VEVENT object.

Also if I adopted  a model where I just sent them one
VEVENT with the latest state it would totally invalidate
all the "partstat" values for that VEVENT every time a
change that caused a SEQUENCE increment to any instance
ever happened.  With the existing model updating the
SEQUENCE  for any particular instance only invalidates
the "partstat" value for that single instance and for
no other instances because none of those other instances
have had a significant change to them.

> REQUEST/REPLYs? When it could just be (1*new-ATTENDEE)

Actually it would never be SEQUENCE*new-ATTENDEE.

The absolute worst case scenario in the fixed RECURRENCE-ID
world is (1+NUM_INSTANCES)*new-ATTENDEE.  And that would
only happen if every single instance had per instance data
above and beyond what was defined in the base component.
For instance partstat values that were different from the
base component response, descriptions and comments,
ATTENDEES that aren't involved in the base component
are all examples of properties that would force a specific
description in the iTIP message.

Essentially, the cost of inviting a new ATTENDEE is the
same cost as a REFRESH which in a fixed RECURRENCE-ID
model is at worst 1+NUM_INSTANCES VEVENTs big and at
best 1 VEVENT big.

> Your example covers a case that works, what about the one I described

I have a searched this thread up and down and the only example
of you claiming that something didn't work was the example you
deleted from this post where I message by message pointed at
A) Your sloppy construction of the message, B) How you would
construct the proper messages given a fixed RECURRENCE model,
C) the state of the calendar after each said message, and
D) why "Bruce's model" did not fall down as you asserted it did.

Unless there is another example I can't find aside from:

Create three instances, move the time of the second,
move the time of the third to the original time of the
second and change its venue, and then move the time
of of the second to the original time of the third.

Which I very clearly proved was not a problem for a
fixed RECURRENCE-ID model (as had Bruce before me),
please post the example/challenge again because I
don't see one.

If you don't think I proved how the fixed RECURRENCE-ID
model succeeds given that example then look at my
message of 8/8 3:51am and look for the part about
"and lastly to cover that great example you offered"
(the one you deleted from this post) and show me how
a fixed recurrence model "breaks".

All of the messages are there, the state descriptions
are there, it very clearly and plainly shows what state
every component is in at each phase of the game, and
it even compensates for your errors to do what you meant.

> It works in any order and with missing objects.

Ok this works becuase you consider the rescheduling of
any instance a rescheduling of the entire set.  Thus
you update the master UID to reflect a set that includes
the newly rescheduled instance and if you were using an
RRULE to define the set you'd have to also include an
EXDATE property and a new RDATE property to exclude and
reinclude (respectively) the item that you just moved.

So how do you get around the fact that you've now forced
all the ATTENDEES to every occurence to REPLY with their
partstat for every instance again (assuming they had mixed
responses)...  Further how do you add just one ATTENDEE
to a single instance without fragmenting your calendar
and tracking a separate UID version for just that person.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Sat, 09 Aug 2003 10:02:53 -0600

> and that the RECURRENCE-ID is "fixed" in respect to the

Well the UID:1/SEQUENCE:0 paris is fixed.
And the UID:1/SEQUENCE:1 pairs are fixed.

Is that what you mean?

> invite a new ATTENDEE and show us the iTIP messages.

Original send to ATTENDEE:one

	UID:1
	SEQUENCE:0
	DTSTAMP:...time-1...
	DTSTART:Friday...180000Z
	RRULE:every...friday...
	ATTENDEE:one

Updates per iTIP can be done in one of two ways:

  (1) Update entire object and send to ATTENDEE:one

	UID:1
	SEQUENCE:1
	DTSTAMP:...time-2...
	DTSTART:Thursday...180000Z
	RRULE:every...friday...
	EXDATE:...june-13...
         RDATE:...june-12...
	ATTENDEE:one

  OR

  (2) Update an instance and send to ATTENDEE:one
      (4.4.2 Modify A Recurring Instance)

         UID:1
	SEQUENCE:1
	DTSTAMP:...time-2...
	DTSTART:...june-12...
	RECURRENCE-ID:...june-13...
	ATTENDEE:A

Adding a new ATTENDEE - sent to ATTENDEE:two and ATTENDEE:one
   (And you do not have to send it to ATTENDEE:one again
    unless you want ATTENDEE:one to know that ATTENDEE:two
    was added).

	UID:1
	SEQUENCE:1
	DTSTAMP:...time-3...
	DTSTART:Thursday...180000Z
	RRULE:every...friday...
	EXDATE:...june-13...
         RDATE:...june-12...
	ATTENDEE:two
	ATTENDEE:one

> describing Saturday, June 14th

That is a RESCHEDULE - not an ATTENDEE add.

--

---

From: Doug Royer <[email-masked]>
Date: Sat, 09 Aug 2003 10:08:50 -0600

> to UID: 1 are the same component.  They aren't.

When you say 'component' do you mean booked object?
Or do you mean 'over the wire component'?

--

---

From: Doug Royer <[email-masked]>
Date: Sat, 09 Aug 2003 09:41:36 -0600

> What does this have to do with making a new REQUEST?

It has to do with the fact that your email was EXACTLY
how to modify an existing instance. Not how to add
an ATTENDEE.

Your example would be indistinguishable from a modification
to an existing instance. An iTIP compliant CUA would have no
choice but to assume it missed the original.

--

---

From: Doug Royer <[email-masked]>
Date: Sat, 09 Aug 2003 10:34:04 -0600

> version of UID: 1/RECURRENCE-ID: June 13th prior to 10.

Nothing you sent shows how a new ATTENDEE would know
how to use instances that overlapped from the original
SEQUENCE:0 instances. The only thing you are showing
is that as long as in the history of the event no
two instances happen to have had the same time, then
it works.

> in just one VEVENT object.

For that use the "4.4.2 Modify A Recurring Instance"
procedure and add COMMENT.

> have had a significant change to them.

First adding an ATTENDEE does NOT require the SEQUENCE
be updated. For that update the DTSTAMP and resend.
No PARTSTATs are effected.

Second, adding an ATTENDEE does NOT require that all
ATTENDEEs be updated with the latest DTSTAMP versions.
I can add attendees, and as long as I do not update
the properties defined in iCAL/iTIP that mandate
the SEQUENCE number be updated, then I do not have
to tell ALL ATTENDEES. There may be times when an
implementation needs or wants to inform ALL ATTENDEEs
of each ATTENDEE (or other) addition/deletion, but that
in itself does not require that the SEQUENCE be incremented
so no PARTSTAT is effected.

Third, if you are rescheduling an event, then YES
you effect the PARTSTAT of ATTENDEES going to those
instances.

Fourth, if ATTENDEE 'A' is NOT attending instance 'I',
then you do NOT have to send 'A' an instance update.
The SEQUENCE number of the booked object would be
incremented because you altered the booked object.
And the effected ATTENDEEs would be sent the update
or new object with the new SEQUENCE. But if it does
not effect ATTENDEE 'A' then you can just keep
the ATTENDEE 'A' PARTSTAT value the same because
they have no decision to make as it did not effect them.

> world is (1+NUM_INSTANCES)*new-ATTENDEE. 

If you bump the SEQUENCE, then you are going to tell
ALL attendees in that model - correct? Then is is
(*ATTENDE [new and old]) not just new-ATTENDEE - correct?

> model is at worst 1+NUM_INSTANCES VEVENTs big and at

A refresh is only when you get out if sync. Like
getting an update when you do not have the update/sequenec-1
object.

> D) why "Bruce's model" did not fall down as you asserted it did.

I can not follow your sloppy paragraph, could you cite
a date time or link?

> please post the example/challenge again because I

You did not prove it, you changed the example to one
in which did not apply to the problem.

--

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 10 Aug 2003 00:08:05 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> Or do you mean 'over the wire component'?

I'll respond to the other posts as well, but this is the
most relevant difference it seems.

Each instance, plus the parent UID, are each their own
'booked object', an actual component of the calendar.

So when I create:
UID: 1/SEQUENCE: 0
describing every Friday this year that is one physical object
that the CUA can manipulate -- and then every instance of
UID: 1 has a RECURRENCE-ID set to something generated by the
set described by UID: 1 are separate physical objects.

So assuming that there are 52 Fridays in the year, there would
be 53 separate and unique objects on the calendar to support
the recurring event.

To further provide a concrete example of this, each time a
particular range of the calendar gets viewed by the CU, the
CUA generates the subset of instances that would occur in
the range viewed.

So if the CU was looking at the month of June, for
UID: 1 the CUA would generate the RECURRENCE-IDs of
June 6th, June 13th, June 20th, and June 27th.

It would then lookup in its store each of those event
instance components and display them.

Meaning it would display the following objects:
UID: 1/RECURRENCE-ID: June 6th
UID: 1/RECURRENCE-ID: June 13th
UID: 1/RECURRENCE-ID: June 20th
UID: 1/RECURRENCE-ID: June 27th

However, since we updated UID: 1/RECURRENCE-ID: June 13th
to actually DTSTART on the 12th, that object would draw
itself on Thursday 12th and not on Friday 13th as originally
described by the RRULE of UID: 1.

Assuming we made no other substantive changes, UID: 1 would
be at SEQUENCE: 0, as would all UID: 1/RECURRENCE-ID: *****
with the exception of UID: 1/RECURRENCE-ID: June 13th which
would be at SEQUENCE: 1.

UID: 1/RECURRENCE-ID: June 13th would be at SEQUENCE: 1
because it had a substantive change that jeopardized the
validity of the partstat status that was attached to the
SEQUENCE: 0 version of the instance.  In other words, that
instance was reshceduled and so therefore the partstat of
all ATTENDEES must be renegotiated.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 10 Aug 2003 00:32:11 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> how to modify an existing instance. Not how to add

My email was "inviting" an ATTENDEE to a single instance by
sending them a REQUEST with the latest SEQUENCE of the instance
with them listed as an ATTENDEE.

Besides, that was irrelevant at that point, the quote being
responded to from you was not in the context of my examples
which you were claiming to be flawed by virtue of having a
RECURRENCE-ID in them.

You were asserting that if a message EVER contains a RECURRENCE-ID
and is a METHOD: REQUEST - then it must be a modify.
That is blatantly false (to quote Robert).
To his response you pointed to some examples, to which I
responded that the examples you pointed to are meaningless.

The examples you pointed to are considered updates because the
recipient already has an existing version to be updated.

If the recipient has never seen that UID before, then the
METHOD: REQUEST I send, with the VEVENT object that also
contains a RECURRENCE-ID would be treated like an invite
to that particular instance because it has never seen that
VEVENT before.  It could never be treated as an update to an
event that it doesn't have, couldn't have, and hasn't ever
had because that's what iTIP specifies.

Again, you were claiming that all iTIP messages that are
METHOD: REUQEST and contain RECURRENCE-ID must be an update
of some kind.

Again, that claim is blatantly false and it's easy to prove
via sections 3.2.2.1 and 3.2.2.2 since those are the only
sections that describe how to determine what a METHOD: REQUEST
is in regards to any kind of updates.  Since neither of those
sections tell the CUA what to do if it has never seen that
UID before, those sections do not apply when the CUA has never
seen that UID before.

Further, there is another section, 3.2.2 which exactly tells
the CUA what to do if it has never seen that UID before.
It tells the CUA to treat the message as a REQUEST for a
new VEVENT calendar component.  Which if the recipient was
also listed as an ATTENDEE (which they were) amounts to an
invitation to that VEVENT calendar component (aka that
recurring event instance).

> choice but to assume it missed the original.

It could only consider it an update to an existing instance
if it had ever seen that UID, or UID/RECURRENCE-ID before.
And if it had seen that VEVENT before, then it _would_ be
a modification to an existing instance, but also wouldn't
be newly inviting them, lest somehow they were told about
it, but weren't actually invited (like they were a delegate)
but that's getting to far away from the intent of our
discussion which is just about inviting a new ATTENDEE to
a recurring instance of an event for which they are only
invited to that one instance and have never seen any
version of it before.  Therefore, by virtue of having
never seen the UID before, the CUA must treat it as a
REQUEST for a new VEVENT calendar component.

And yes, assuming that SEQUENCE was not 0, any iTIP
compliant CUA would have to assume that it missed the
original, but it couldn't care less.  It has just
received an invite to the most recent version what
does it care about the original, now invalid, version?

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Sun, 10 Aug 2003 10:42:06 -0600

Michael Fair wrote:
> most relevant difference it seems. ...

Thank you for clarifying, however that is not the iCalendar
model that has been discussed on this WG list over the
last few years.

And your example that I am cutting out again still does
not address the problem.

--

---

From: [email-masked]
Date: Mon, 11 Aug 2003 11:15:33 -0400

> And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID.

Says who?  Its nowhere in any text or table in iTIP.  Its perfectly valid 
to send:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1com
   RECURRENCE-ID:19970701T210000Z
   SEQUENCE:0
   ORGANIZER:Mailto:[email-masked]
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
   ATTENDEE:Mailto:[email-masked]
   ATTENDEE:Mailto:[email-masked]
   ATTENDEE:Mailto:[email-masked]
   DESCRIPTION:IETF-C&S Conference Call
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:20030814T210000Z
   DTEND:20030814T220000Z
   LOCATION:Conference Call to resolve RECURRENCE-ID
   DTSTAMP:20030811T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

NOWHERE in iCalendar or iTIP do we ever say this is NOT allowed.  Sorry 
but you are creating new semantics for REQUEST that simply do not exist in 
iTIP.  iTIP 3.2.2 REQUEST says that REQUEST is used for multiple actions:

     .  Invite "Attendees" to an event;
     .  Reschedule an existing event;
     .  Response to a REFRESH request;
     .  Update the details of an existing event, without rescheduling it;
     .  Update the status of "Attendees" of an existing event, without
        rescheduling it;
     .  Reconfirm an existing event, without rescheduling it;
     .  Forward a "VEVENT" to another uninvited CU.
     .  For an existing "VEVENT" calendar component, delegate the role of
        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component, changing the role of
        "Organizer" to another CU.

and it later says how to differentiate between these different cases with 
the text:

and:

3.2.2.1 Rescheduling an Event

3.2.2.2 Updating or Reconfirmation of an Event

   The "REQUEST" method may be used to update or reconfirm an event. An
   update to an existing event does not involve changes to the time or
   recurrence intervals, and might not involve a change to the location
   or description for the event. If the recipient CUA of a "REQUEST"
   method finds that the "UID" property value already exists on the
   calendar and that the "SEQUENCE" property value in the "REQUEST" is
   the same as the value for the existing event, then the "REQUEST"
   method describes an update of the event details, but no rescheduling
   of the event.

So, if the UID / RECURRENCE-ID are not found for a repeating instance then 
"then the "REQUEST" is for a new "VEVENT" calendar component." (aka an 
invitation). 

If the UID / RECURRENCE-ID are found for the repeating instance and the 
SEQUENCE value is "greater" (not just 1+) "then the "REQUEST" method 
describes a rescheduling of the event." (aka a reschedule in case the 
section header wasnt clue enough). 

If the UID / RECURRENCE-ID are found for the repeating instance and the 
SEQUENCE value is the same (factoring in DTSTAMP too) "then the "REQUEST" 
method describes an update of the event details, but no rescheduling of 
the event." (aka an update in case the section header wasnt clue enough 
here too). 

The CUA does NOT construct semantics based on just the properties in the 
message; it bases it on them and those it has (or does not have) locally! 
Any other behaviour is contrary to iTIP and a misapplication of it.

> as defined  by iTIP and not an new invitation.

You seem to be ignoring the application of Section 2.1.5 Message 
Sequencing rules when you read the Section 3 messages.  Because the 
workflow process needs to be able to deal with different kinds of messages 
that may arrive in different order than they were sent, we created Section 
2.1.5 as a common place for explaining how to sequence them all.  This 
also had the benefit of not making us having to expressly say "If you find 
the "UID" (or the "UID" / "RECURRENCE-ID" pair in the case of a repeating 
instance) ..." in every place in the Section 3 texts.  It made for a 
smaller draft and made editing easier. 

I say this because you keep saying that there is no RECURRENCE-ID on an 
invitation and Im guessing that you think this because the text from 3.2.2 
does not expressly say "RECURRENCE-ID" in it somewhere.  However neither 
do the 3.2.2.1 or 3.2.2.2 texts so perhaps you think that you cannot have 
RECURRENCE-IDs on reschedules or updates too then??...

> METHOD:REQUEST that it is a modify and not a new invitation?

Yes. If you understand the function of Section 2.1.5 and correctly apply 
it to all the Section 3 texts you should see that iTIP NEVER says that a 
METHOD:REQUEST without a RECURRENCE-ID is an invitation, otherwise its a 
reschedule.  iTIP NEVER draws that distinction.

If one correctly reads the text in 3.2.2 (and 3.2.2.1 and 3.2.2.2) then 
you should see that the recipients interpretation of the message is 
dependent on what they _already_ know about the instance in question and 
not just the senders intent! 

So, if you never got the SEQUENCE:0 thru SEQUENCE:5 REQUESTS (they got 
lost in a disk crash enroute or your Admin was messing with you or some 
coworker was getting even or...) and you do receive the SEQUENCE:6 REQUEST 
then you should treat it like an invitation even though from the 
Organizers point of view it was the 6th reschedule of the instance (to 
which you may have only recently been added or were an 'original' 
ATTENDEE). 

It does not matter to you really in that you can correctly join the 
workflow for that instance by simply sending back a REPLY with the UID / 
RECURRENCE-ID / SEQUENCE values you just got.  If you recieve one or some 
of the previous SEQUENCE valued REQUESTS later then you simply can treat 
them as obsoleted REQUESTs for an instance you already have more current 
info and ignore them.  That of course assumes a fixed RECURRENCE-ID model 
so that you can do the correct obsolete determination. 

Otherwise you have to go thru all the extra gyrations and thrashing I 
described in my analysis for Tim last week.

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 11:24:29 -0400

> Except you were replying to my email - not yours.

Evade and distract all you like, the points and analysis still stand and 
nothing you've NOT said about 'em should confirm them.

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 11:22:48 -0400

> Your ignoring the fact it changes.

Im not the one ignoring:

and Im not the one who treats a reschedule of a recurrence _instance_ as a 
change to the "recurrence _set_".

Ive also pointed out that we dealt with the 1 line in iTIP back in 1999 
(if not before then given the way Dan phrased his posting). 

If one takes a serious look at the workflow process and how a changing 
RECURRENCE-ID model is very fault intolerant compared to the fixed model 
it should be clear that the intent is to use fixed RECURRENCE-IDs. 

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 12:01:53 -0400

Doug wrote on 08/07/2003 06:05:40 PM:
> your model broken in that area? 

You put no iTIP fragment into your postings that I saw.  You merely put in 
text that said:

Thats just an unsubstantiated claim that Ive demonstrated to be false and 
misleading with both iTIP fragments and iTIP citations.

>                                  You know the one that showed
instances?

I dont know what example you are referring to since there was none in your 
08/07/2003 01:33:53 PM reply. 

In any case, I see that there is a greater problem with your 
misunderstanding of iTIP and the REQUEST method.  I covered much of it 
already in an earlier reply to a different posting but essentially you are 
trying to imply Organziers semantics on the recipients side when you 
cannot.

iTIP says that the recipient determines the semantics of the REQUEST based 
on the information it has about that UID / RECURRENCE-ID / SEQUENCE / 
DTSTAMP.  If you understand the role of Section 2.1.5 and how it applys to 
all Section 3 iTIP methods this should be relatively easy to see.

To be clear to those that may not see that other message, iTIP says that 
if the UID / RECURRENCE-ID are not found in the recipients store then the 
REQUEST is an invitation (Section 3.2.2).  If the values are found then 
SEQUENCE (and DTSTAMP too) are used to differentiate between a reschedule 
(SEQUENCE values do not match, Section 3.2.2.1) and an update (SEQUENCE 
values match, Section 3.2.2.2) with DTSTAMP being used to determine 
obsolesce.  The senders semantics are not always those determined by the 
recipient; it depends on what they already know about the event / instance 
in question!

> and you called it inviting a new attendee. 

Where did you pull that from?!?  I simply sent:

UID: 1
SEQUENCE: 10

to someone who does not have it yet since I just added them.  By iTIP 
Section 3.2.2 REQUEST:

so they treat it for exactly what it is, an invitation.  Just how could it 
be an update or a reschedule if they dont have it yet?? 

>                                                There is no problem

Sending just:

UID: 1
SEQUENCE: 10

is WRONG since they are being added to a particular instance and NOT the 
entire set (or to a non-repeating entry).  Perhaps you missed:

in the REQUEST restriction table. Since the invitation is for an instance 
then it MUST be there.  If there is no RECURRENCE-ID then the invitee 
would send back a REPLY w/o one and this is defined in 3.2.3 REPLY as:

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

so the Organizer would think they are referring to all instances in the 
set when in fact they are referring to just one. 

In addtion, in order to add them to another instance using Dougs model you 
will have to send a new REQUEST that has NO RECURRENCE-ID on it but has 
RDATE info so that the recipient will toast their view of that UID and 
recreate it.   That means that the invitee has to either renegotate that 
1st instance all over again  or at a minimum remove and recreate the exact 
same instance. 

This waste of bandwidth and cycles is necessary because in Dougs model the 
RECURRENCE-IDs change on each reschedule and the invitees have NO way to 
differentiate between a missed reschedule OR an invitation to a new 
instance they never knew about before.  So far Ive shown this twice by 
example yet some would prefer to ignore it for whatever reasons they have. 
 (This REQUEST with RDATEs is Dougs "full REFRESH" for those still 
reading)

No matter the distractions or claims to the contrary, it was easyly shown 
how fault _intolerant_ and error prone a changing RECURRENCE-ID model is. 
If you missed it when I posted it on Friday Ill be glad to repost it along 
w/the exact same comparison for the fixed RECURRENCE-ID model so you can 
see for yourself.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 10:14:33 -0600

[email-masked] wrote:
> Says who?  Its nowhere in any text or table in iTIP.  Its perfectly 
> valid to send:

Because it is then indistinguishable from an instance modification.
The ATTENDEE being unable to tell the differanec will have to
do a REFRESH.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 10:15:35 -0600

> nothing you've NOT said about 'em should confirm them.

That you replied to my email?

--

---

From: [email-masked]
Date: Mon, 11 Aug 2003 12:23:35 -0400

> Nope - iTIP - Modify A Recurring Instance, look for:

Lets not get distracted from the details shall we:

1: Your example is a misuse of an iTIP example (Section 4.4.2 Modify A 
Recurring Instance) which clearly is for "a recurring meeting" NOT for a 
single instance of that repeating set.

2: You are relying on an example thats not the same scenario we have been 
discussing (the invitation to a single instance of a repeating set)

3: iTIP Section 3.2.2 REQUEST clearly defines how the recipient is to 
determine invitation from reschedule from update.  If you properly use 
Sections 2.1.5 and 3.2.2 (or any Section 3 message) you will know how to 
distinguish between all the cases.

>     "RECURRENCE-ID" has changed to the new "DTSTART" value.

You recycle old references that the WG covered at least 4 years ago.  The 
1st line you cite agrees w/iCalendar in its reference to 'original' (no 
matter your defition), the last line is the only conflict w/the rest of 
iCalendar or the iTIP.  1 line vs all the rest of the agreeing text is 
hardly a forceful case to redefine the model that iCalendar defines.

> If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.

DIFFERENT CASE!  Stop trying to mix the examples so you can twist the 
discussion.  We have been discussing the workflow of a single instance of 
a repeating set; not changing the recurrence set by expanding it. 

If you want to go and change the repeating set by ADDing an instance then 
iCalendar is clear when it says that the RECURRENCE-ID "might also 
change".  However that is NOT the example we have been discussing.

> Can you cite any text? Or is that just another take my word for

Its in the REQUEST restriction table:

There is also the text from 2.1.5 that some folks seem to neglect:

Because of potential sequencing problems enroute the Organziers 
"reschedule" may be treated by the invitee as an "invitation" since it 
gets there first. 

It is trivial to show that an instance of a repeating set may never go 
beyond SEQUENCE:0 (all invitees agree to the date/time w/o COUNTERing or 
the Organizer never reschedules it because of any number of reasons) and 
as such adding someone to that instance alone clearly means they will get 
an invitation at SEQUENCE:0.  Under Dougs model its not clear that I would 
not have to rev SEQUENCE when I add a new invitee given his postings so 
far.  As such, it sounds as if I would have to rev SEQUENCE to a higher 
value every time a I add someone just because I have to craft some 
specialized REQUEST to them.  Ugh!

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 12:33:05 -0400

> How about responding to the email that showed why your model

You have not shown anything; you have merely written a few lines claiming 
the model is broken.

I have posted detailed examples and analyses of how workflow performs 
using both your changing RECURRENCE-ID model and the iCalendar fixed 
RECURRENCE-ID model. 

I have provided iTIP fragments all along that support the model and are 
supported by the RFC texts.

I have shown that in 5 simple steps its easy for the Organizer to fail to 
match the REPLY to the proper instance.

I have shown that error recovery for missequenced or lost iTIP messages is 
trival for the fixed RECURRENCE-ID case.  All it takes is 1 simple REPLY 
and workflow is restored.

I have shown that for a changing RECURRENCE-ID model, because you cannot 
uniquely identify the correct instance in question because its id changes, 
its easy to trash about trying to recover from 1 single missequenced or 
lost message.  Recovery at the instance level is NOT possible as Doug has 
tacitly agreed, the only way to recover is to nuke all instances and 
recreate them all from scratch.  This of course assumes you can correctly 
sequence that REQUEST w/the rest and its not missequenced too!

At this point Im coming to the conclusion that Doug is either unfamiliar 
with iTIP Section 2.1.5 or is unsure how to correctly apply it to all the 
iTIP methods.  Thats the only explaination I can come up with for how hes 
is misinterpreting iTIP (invitation vs reschedules) and iCalendar but if 
someone else can see it please chime in.

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 14:02:23 -0400

Doug wrote on 08/07/2003 07:31:49 PM:
> >  > > message is obsolete and thus you ignore it (and the missequenced 
9 
> > too).
> to the text submitted.

Gladly and I hope you will respond to the analyses Ive done on why the 
changing RECURRENCE-ID model is the wrong one.  Ill go first...

You have not shown any such failure; merely claimed it and posted 1 
incomplete iTIP fragment (above). 

Neither have you disputed my analysis of the weaknesses in the changing 
RECURRENCE-ID model as they relate to message sequencing but more on that 
later. 

Lets take a look at your purported failure example shall we.  First off 
its makes some assumptions that could be invalid:

1: ALL instances share the same SEQUENCE value.  Each instance can be 
negotiated separately so they are not always likely to have the same 
SEQUENCE values but they could.

2: Using that fragment every instance would share the same data (except 
the derived DTSTART/DTEND values).  In the real world I do not often find 
this to be the case for ALL repeating calendar entries; in fact I find it 
to be quite contrary to the norm where Organizers update the DESCRIPTION 
or ATTACHments or vary ATTENDEE lists, etc based on the needs/requirements 
of each instance.

3: This implicly assumes that this REQUEST will get to the invitee and not 
be lost or missequenced.  If your later REQUESTs assume that this one 
arrived and was properly processed then you are gonna be in a world of 
hirt as you misread iTIP.  iTIP messages are NOT guaranteed to be 
delivered in the same order they were sent; this should be obvious to most 
email users who get replys to postings they have yet to see.  In fact, 
iTIP message delivery is NOT guaranteed at all and thats why each iTIP 
message is self contained; they have NO dependencies on any previous iTIP 
message contents.  The exception to this seems to be Dougs model where the 
RECURRENCE-ID changes on each reschedule.

4: iTIP REQUEST allows for the Organzier to send multiple body parts for 
the same UID in the same iTIP message:

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.

and this is necessary when you want to sent data about multiple instances 
all at once as in a new invitation to a repeating set. 

There are 2 ways that a new invitee can be added to a _set_ of instances 
and Ive already given those iTIP fragments in response to Arnaud over a 
month ago.  Go check the archives for my posting.  It should be noted that 
Doug never responded to the request how  it would work in his model and 
still has not after 6+ weeks.  I can only guess why not.  However this is 
a digression from the case of adding a single invitee to a single instance 
of the repeating set but I have indulged the digression in an attempt to 
show how the claim of failure is patently false and incorrect.

If you understand iTIP Section 2.1.5 and how it applys to all Section 3 
text you should see that adding a new invitee to an existing instance is 
trivial:  simply send a REQUEST with the UID / RECURRENCE-ID / SEQUENCE 
that the instance currently has.  The invitee should apply iTIP 3.2.2 text 
to detect that the UID / RECURRENCE-ID are not in the calendar and thus 
the REQUEST is an invitation.  For invitations to multiple instances, the 
iTIP REQUEST contains the data for those instances (using the behaviour 
cited under #4 above)

> Why will you not respont to the problem
> that I submitted? Why? 

I have responed (this is the 2nd time) and so far Ive seen nothing that 
supports your assertion of a bad model or that something breaks.

I now expect that you will respond to my analysis of the workflow model 
and how fault _intolerant_ and error prone it is when a changing 
RECURRENCE-ID is used.

>                                                   You can

Where do you pull these assertions from Doug?!  You  must not be reading 
my side by side analysis of each model and how message sequencing works 
(the iCalendar model) or fails (your model).

However in case some missed it Ill repost part of it here to show exactly 
whose model is broken.

First off, a fixed RECURRENCE-ID model:

An update to an existing entry is defined in iTIP 3.2.2.2 Updating or 
Reconfirmation of an Event and a reschedule is defined in iTIP 3.2.2.1 
Rescheduling an Event.  Both are quite similar so Ill just discuss the 
reschedule case and leave it to the reader to apply the same understanding 
to the update case.  3.2.2.2 says:

                  If the recipient CUA of a "REQUEST" method finds that

So to determine that this is a reschedule from a new invitation (iTIP 
3.2.2 REQUEST) the UID and RECURRENCE-ID values must exist in the invitees 
calendar.  The text says that SEQUENCE is "greater than the value for the 
existing event" without any distinction of being 1 or 2 or 5 or 1000 
greater.  This should imply that the RECURRENCE-ID value does not change 
but Ill continue.  If the invitee is able to find the instance by UID / 
RECURRENCE-ID and then properly detect that their SEQUENCE value is, say, 
3 lower than the SEQUENCE on the REQUEST they can tell 3 things:

1: This is indeed a rescschedule of the given UID / RECURRENCE-ID 
2 The version they have is obsolete compared to the one in the REQUEST 
(this comes from iTIP Section 2.1.5 bullet 2 AND the text above!)
3: They can safely act on the REQUEST and apply it to the correct instance 
in their calendar.

The invitee can now craft the proper REPLY and send it back to the 
Organzier and update their copy of the event with the newer info.  No 
problems.

Now, suppose that the reschedule for the same UID / RECURRENCE-ID came in 
but with a lower SEQUENCE value (one of the missing 2).  If the CUA 
correctly implements Sections 2.1.5 and 3.2.2 they would see that they 
have the UID / RECURRENCE-ID values (so its NOT an invitation) but that 
the SEQUENCE is "lower" than the value they currently have so the REQUEST 
is obsolete and is safely ignored.  No failures here.  Nothing to worry 
about!

Now for the changing RECURRENCE-ID model:

The CUA looks at the UID / RECURRENCE-ID and does not find it in the 
calendar.  As such it should follow iTIP 2.1.5 Message Sequencing and 
3.2.2 REQUEST:

(since its a repeating instance) and _incorrectly_ treat the REQUEST as a 
new invitation to the instanced referred to by UID / RECURRENCE-ID at the 
given SEQUENCE.  It now adds a new instance of UID to the users calendar 
and they have 2 instances of the UID at different date/times rather than 
1. 

The invitee now crafts up a REPLY with the given UID / RECURRENCE-ID / 
SEQUENCE and send it back to the Organzier.  The problems that we have at 
this point are:

1: There are now 2 versions of what is really the same instance on the 
users calendar.  The user does not know something was wrong NOR do they 
have a way to simply remove the stale duplicates.
2: The REPLY to the Organzier has a RECURRENCE-ID matches one the 
Organizer has so they think the invitee is coming to 1 instance.

Now, suppose that the reschedule for the same instance (same UID / another 
different RECURRENCE-ID) came in but with a lower SEQUENCE value (one of 
the missing 2).  If the CUA correctly implements Sections 2.1.5 and 3.2.2 
they would see that they do not have the UID / RECURRENCE-ID values and 
again incorrectly treat it as an invitation.  They would repeat the same 
process of adding a 3rd duplicate instance and sending a REPLY back to the 
Organizer.

Assuming the Organizer gets the REPLY for the older UID / RECURRENCE-ID / 
SEQUENCE they have NO way to 100% accurately match it to the correct 
instance in question.  The CUA could try to guess but any attempt is 
easily defeated in 5 steps (see previous 2 descriptions of this if 
interested).  As such the Organizer does not know for sure which instance 
in question the REPLY was for so they would send out a new REQUEST with 
the latest UID / RECURRENCE-ID / SEQUENCE (per iTIP).   However its not 
clear what data would be in it since its not always possible to tell 
exactly which instance is in question.

The only solution to this dilema is to destroy and recreate ALL instances 
by sending a REQUEST with a UID and a higher SEQUENCE value but no 
RECURRENCE-ID (but with RDATEs instead).  This is much like Dougs example 
at the top with the same assumptions and related bagage.  The answer is 
therefore that the Organizer must send an iTIP REQUEST that will cause the 
invitee to toast all instances it thinks it knows about and recreate them 
all; even those UNRELATED to the instance in question.  And even this is 
not a totally viable solution as it does fails to fix the problem if the 
'nuke' REQUEST never gets delivered.

Since iTIP messages may get lost in transit for any number of causes, its 
not safe to rely on the assumption that the 'nuke ' REQUEST will actually 
get to the user (this is why REQUESTs are full snapshots, yes!?).  If it 
gets lost then the orphaned duplicates will still exist on the invitees 
calendar.  Any future REQUESTs will get treated as new invitations instead 
of reschedules and although the REPLYs look like the invitee knows the 
current state of things in fact they have a totally poluted calendar with 
duplicate instances that the Organzier has know way to knowing about or 
way to get rid of.  Yep, this sounds like the model I want to have for my 
calendar system!

Even if you have an unusual definition for the word 'original', take an 
analytical look at iTIP messging, message sequencing and its impact on C&S 
workflow.

How can anyone who takes an analytical look at the workflow and how it 
fails with missequenced or lost messages when the RECURRENCE-ID changes 
actually think that model works when compared to the very fault tolerant 
fixed RECURRENCE-ID model?? 

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 14:12:23 -0400

Michael replied on 08/08/2003 06:51:56 AM:
> tend to call for the use of a changing RECURRENCE-ID. 

'effective' is likely due to the fact that the DTSTART date/time values 
for the instance cannot be blindly copied from the 1st instance to all 
others. 

This is due to things like timezone shifts where the starting time is, 
say, 9:00 AM EST half the year and and 10:00 AM EDT the other half. 
Another example is the effect of unrolling the RRULE which may have BYxxx 
components that effect the final DTSTART value of the instance.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 12:49:18 -0600

> SEQUENCE values but they could.

I think we agree - the instance can change.

> the derived DTSTART/DTEND values).  In the real world I do not often 
> find this to be the case for ALL repeating calendar entries; in fact I 
> find it to be quite contrary to the norm where Organizers update the 
> DESCRIPTION or ATTACHments or vary ATTENDEE lists, etc based on the 
> needs/requirements of each instance.

Frequency of occurrence is not relevant. I think we agree that
the exceptions are what break most models.

> 3: This implicly assumes that this REQUEST will get to the invitee and 
> not be lost or missequenced. 

Are you saying that is your opinion? Or that you think that is
my opinion?

Which is opposed to the iTIP 'Abstract':

    The document outlines a model for calendar exchange that defines both
    static and dynamic event, to-do, journal and free/busy objects.
    Static objects are used to transmit information from one entity to
    another without the expectation of continuity or referential
    integrity with the original item. Dynamic objects are a superset of
    static objects and will gracefully degrade to their static
    counterparts for clients that only support static objects.

> If your later REQUESTs assume that this 
> one arrived and was properly processed then you are gonna be in a world 
> of hirt as you misread iTIP.  iTIP messages are NOT guaranteed to be 
> delivered in the same order they were sent; this should be obvious to 
> most email users who get replys to postings they have yet to see.  In 
> fact, iTIP message delivery is NOT guaranteed at all and thats why each 
> iTIP message is self contained; they have NO dependencies on any 
> previous iTIP message contents.  The exception to this seems to be Dougs 
> model where the RECURRENCE-ID changes on each reschedule.

Stating a truism is not relevant to the point. It is also
true that I am sending email. How many times do I need to say
that?

I have nor have I seen anyone on this list claim that the above
truism you state is false.

>   components are needed to express the entire series.

Yes, and we both fought for that - another turism.

> and this is necessary when you want to sent data about multiple 
> instances all at once as in a new invitation to a repeating set.  
> 
> month ago.  Go check the archives for my posting.  It should be noted 
> that Doug never responded to the request how  it would work in his model 
> and still has not after 6+ weeks.  I can only guess why not.

I did respond - check your email or the imc archives.

> However 
> this is a digression from the case of adding a single invitee to a 
> single instance of the repeating set but I have indulged the digression 
> in an attempt to show how the claim of failure is patently false and 
> incorrect.

Your intentional ignoreing my questions does not make it proved.

> that the instance currently has.  The invitee should apply iTIP 3.2.2 
> text to detect that the UID / RECURRENCE-ID are not in the calendar and 
> thus the REQUEST is an invitation.  For invitations to multiple 
> instances, the iTIP REQUEST contains the data for those instances (using 
> the behaviour cited under #4 above)

And what about my repeated questions that show when that does not work?

I am deleteing the rest of your reply becuase so far you still keep
giving your opinion, do not address the facts, or just quote text
that does not address the questions that you reportataly above
declared to address...

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 12:52:32 -0600

[email-masked] wrote:
>  Another example is the effect of unrolling the RRULE which may have 
> BYxxx components that effect the final DTSTART value of the instance.

Yet in sections that have noting to do with timezones, such as
RECURRECE-ID and RANGE it also talks about the effective start
date of an instance. Sounds like selective reading to me.

--

---

From: [email-masked]
Date: Mon, 11 Aug 2003 15:30:40 -0400

> that the RECURRENCE-ID is tied to the UID/SEQUENCE? Yes

You are basing your design on an example (Section 4.7.2 Bad RECURRENCE-ID, 
bullet 2) and NOT on the normalative prose of iTIP that are relevant like 
Section 2.1.5 Message Sequencing and many parts (or subparts) of Section 
3.  This is folly, coding to an example and not the prose its intended to 
demonstrate but it would not be the first time someone did that.

In case you want something to ignore, Ill provide you with the key 
sequencing bits:

   To maximize interoperability and to handle messages that arrive in an
   unexpected order, use the following rules:

Even bullet 1 of Dougs prescious Section 4.7.2 clearly descibes a case 
where UID / RECURRENCE-ID are fixed and used to find the instance in 
question before checking SEQUENCE (otherwise how could you find the UID / 
RECURRENCE-ID but have a SEQUENCE that is greater or lesser??).  Of course 
thats contrary to Dougs UID / SEQUENCE / RECURRNECE-ID model so he'd just 
like you to forget it.

Lets take some common sense approach to this discussion and see if that 
helps.  If you want to unambiguously refer to an instance of something you 
need to assign it an identifier that you can use consistantly and that 
will always allow you to find the instance in question or be sure you and 
the other party are referring to the same item/instance.   Otherwise you 
risk having 2 separate converstations and never noticing a problem.

One way that we do this now is to assign serial numbers to things like 
your PC or a VIN to your car.  If I want to have any correspondence with 
someone about the item I can always use that serial number for doing 
things like tracking it inventory and tracking current ownership.  I do 
not say "Where is your Dell laptop?" when I talk w/someone who may have > 
1 laptop if Im interested in a particular laptop.  I must say "Where is 
your Dell laptop, serial #123456?"  That way I know that both the other 
person and I are referring to the same laptop and not different ones. 
Otherwise I may think the person still has laptop #123456 but in fact it 
no loner exists.

For people (here in the US), your name can change but your Social Security 
Number (SSN) does not.  So a person can change their name but the 
government still has a way to uniquely refer to them no matter the change. 
 If the government had to rely on a value that could change at any time 
then they would have NO way to accurately know which "Doug Royer" or 
"Bruce Kahn" was which.  Thats why SSNs are fixed (ok, they are reused on 
your death after 20 years but thats not relevant).

Your cell phone has a unique identifier it uses to access the phone 
networks so that the carriers can confirm your phones identity and apply 
the charges to the proper account.  If the identifier it used on each call 
was different then the charges could not be accurately apply to your 
account.  Gee, maybe I could like Dougs model for some things...

iTIP is designed to be fault tolerant because not all bindings of it are 
going to be able ensure 100% message delivery and ordering and handling 
(NOT EVEN CAP can guarantee that!).  The ONLY way to correctly identify 
the instance the sender was referring to on the receiving side is if the 
identifier (RECURRENCE-ID) is fixed.   If the design required that all 
previous messages be recived and in the order sent then it would not be 
very fault tolerant at all and very error prone.

Bruce

---

From: [email-masked]
Date: Mon, 11 Aug 2003 15:45:55 -0400

>       AS IT LOOKS EXACTLY THE SAME ?

iTIP tells you exactly how.  Lets start with Section 2.1.5 Message 
Sequencing since this is a sequencing problem:

This helps you detect ordering problems if you apply it correctly for all 
Section 3 methods.  Section 3.2.2 REQUEST has:

As such if you NEVER EVER saw any previous UID / RECURRENCE-ID REQUESTs 
you treat it for what it is, an invitation.  SO WHAT if its actually the 
reschedule REQUEST that you got out of order; its new to you so its an 
invitation.  You as a recipient have NO way to know if this is the 1st or 
10th or 1006th REQUEST that the Organzier sent to you; to you its new so 
its an invitation.  If the other REQUESTs come out of order too (ie: in 
reverse order) then so what?!!  They are obsolete compared to the version 
you treated as an invitation so they do not matter any  more!  Toss em 
away and get on with your life.  Of course you cant do that if your 
primary keys value changes though can you?...

Section 3.2.2.1 Rescheduling an Event covers how to distingush a 
reschedule from the invitation and Section 3.2.2.2 Updating or 
Reconfirmation of an Event covers how to distinguish non-rescheduling 
updates from the other possible meanings of the REQUEST.

You seem to think that the ordering of iTIP messages implys some kind of 
semantic interpreation on the receiving end.  This is NOT true.  The 
senders exactly meaning for the REQUEST is NOT conveyed in the iTIP 
message, at least where REQUEST is concerned.  iTIP says that the meaning 
is derived based on the values of UID / [RECURRENCE-ID when repeating 
instances are involved] / SEQUENCE "are used to distinguish the various 
uses of the "REQUEST" method.".  If you simply take the prose of UID / 
SEQUENCE alone then you are totally ignoring iTIP Section 2.1.5 when 
constructing your keys for searching and indentification. 

Ive said it before and Ill say it again, the reason that each and every 
instance of "UID" does not say "UID" (or "UID" and "RECURRENCE-ID" when 
referencing an instance of a repeating set)" was that we use that term in 
many places and putting in such quialifications into every Section 3 text 
would have resulted in lots of bloat compared to putting it into the 
guidelines under 2.1.5 that apply to all messages (since all messages need 
to be sequence conscious). 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 14:28:08 -0600

> Sequencing since this is a sequencing problem:

The section you quoted does NOT show how to tell if you missed the first
object. Without the new method you propose for adding an attendee,
it is possible to use the text you site to differentiate. With your
proposal then ANY object with a RECURRENCE-ID could be considered
an update to a missed object, or a new object.

What is the justification for creating a new way to add an ATTENDEE?

--

---

From: [email-masked]
Date: Mon, 11 Aug 2003 17:06:07 -0400

> to do things that are already documented.

I have not proposed anything new.  I have merely done an analytical 
analysis of the way a changing RECURRENCE-ID model would function (or 
misfunction) and how a fixed RECURRENCE-ID model woudl function under the 
rules currently in iTIP. 

You seem to ignore the concepts that dont fit your ideas and try to twist 
the rest to fit.  Anyone can go and compare my analysis of BOTH models 
against the RFCs and confirm the results.  So far you have not so Ill take 
that as tacit agreement that its correct.

> How do you disambiguate that from an update to a missed object?

By the presence of the instance in your calendar.  iTIP says it in Section 
3.2.2 REQUEST in case you missed it the last 4+ times:

In the case of a repeating instance the values used would be UID / 
RECURRENCE-ID and not UID alone assuming you understand iTIP Section 2.1.5 
Message Sequencing when it says:

If you find the UID / RECURRENCE-ID then you can decide if its a 
reschedule or an non-rescheduling update by the text in Sections 3.2.2.1 
Rescheduling an Event and 3.2.2.2 Updating or Reconfirmation of an Event 
respectively. 

This is what we did in our 3 separate implementations and what Microsoft 
did in Outlook and Exchange so either the original authors all 
misinterpreted their own text and the design OR you did...  I wonder which 
is more likely??...

Bruce

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 15:45:37 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> an update to a missed object, or a new object.

Actually that's not true.
This is only true in the case where the original recurrence
description object (the one without the RECURRENCE-ID) has
not ever been seen.

If I've ever seen that object, then it will tell me what
all the possibly valid RECURRENCE-IDs are.  For instance,
SEQ:0 of the object describes every Friday.  If I've received
that message then I know that the recurring event instances
will all have RECURRENCE-IDs on Friday.  So if I ever receive
an object that has that UID, but doesn't have a RECURRENCE-ID
on Friday I know something went wrong.  Assuming no one is just
trying to be mean and inserting bad data, it means that my
copy of the orginal UID object is out of date, and needs to
be refreshed.

This post does bring up a good point though.

There might be a situation where the model as I've
presented it has the same problems that the
'current-value' model constantly suffers from.

However, it also might just be my misinterpretation
of when and how a RECURRENCE-ID might change.

To cause the problem it requires both an invitation to
a single instance, and a complete rescheduling of the
entire set of instances.

However, anyone who has more knowledge of how this is
handled and can tell me how I'm misintrepreting what
goes on here is encouraged to please chime in.

Here's the situation:

Assuming a simple every Friday meeting of which no
instances have been touched.
We're at SEQ:0 and all RID's are Friday.

I invite someone to a single instance using:
UID:1
RID:Some Friday
SEQ:0

They've never seen the parent UID:1 and thereofore
have no way to know what is a valid RID and not.
They do the Refresh thing and get back just the
single instance they've been invited to.

I then reschedule the entire series from Friday to
Thursday which updates SEQUENCE for the UID and
moves all the RIDs to Thursdays.

I then try and send the ATTENDEE the update.
According to my original methodology I wouldn't
be able to send them the "move to Thursdays"
update because they weren't invited.

I would send them the new updated invite with a
Thursday RID with which the CUA wouldn't be able
to locate an instance on its calendar.  This would
be treated as a new invite to a separate instance
and not a rescheduling of the first.  Noticing
the SEQUENCE jump for this instance it should send
a refresh.  The ORGANIZER will respond with a
description of only one VEVENT that references
the new Thrusday instance and says nothing about
the old Friday instance and the CUA will be stuck
having two instances on its calendar.

The 'current-value' camp relies on violating the
global uniqueness requirement of the event UID to
get around this problem.  It would have sent a
version of the event without a RECURRENCE-ID that
described only the instance that the CU was
invited to.

If the fixed-id camp wanted to, it could violate the
global uniqueness requirement too and in exact same
way and get the same level of clarity that the
'current-value' model has to resolve the issue.
The CUA would get an event that had the parent UID
and it would describe the Thursday in question but
not the Friday in question and the CUA could drop
the Friday occurence.  But this violates the global
uniqueness property of the UID used and cause all
kinds of other madness I outlined above....

I'm leaving it unresolved for now until someone
with more wisdom than I can paint a consistent
model where this can be done.

-- Michael --

---

From: [email-masked]
Date: Mon, 11 Aug 2003 18:24:43 -0400

> it to change that you want other vendors to change?

Tim cited the example of infinite recurrence as a factor in his decision 
for how he interpreted the RFCs.  I was responding to this by pointing out 
that the internal storage format of any CUA or CS is NOT covered by 
iCalendar or iTIP.  iCalendar is an interoperability format for on the 
wire and iTIP is the semantics for understanding the data it represents. 

Are you now saying that all iTIP implementations MUST use a storage format 
thats basically native iCalendar?  That would ruin your cherished SQL 
backend for CAP wouldn't it?  Besides, you seem to want to digress us into 
non-related stuff than discuss the analysis.  Ignoring it wont make it go 
away or disprove it.

> that there is an entire section devoted to that problem - with

You have consistanly claimed that the CUA first matches the RECURRENCE-ID 
in the RECURRENCE-ID in the REQUESt and then the RECURRENCE-ID value gets 
changed to the DTSTART value when the instance gets added to my calendar 
on a reschedule.  This clearly means that the RECURRENCE-ID value is 
reliant on those from previous iTIP REQUESTS.  Otherwise you could not 
match it to the one you incorrectly saved.

You are correct in that iTIP has Section 2.1.5 Message Sequencing to deal 
with missequencing of iTIP messages.  However your model does not follow 
this text.  Instead it relys in the some of the example text under Section 
4.7.2 Bad RECURRENCE-ID.  You have coded something against an example 
rather than against the prose it was intended to describe and you should 
have known better.  Coding to examples rather than the prose or ABNF is 
poor practice that no amount of RFC text can resolve.

> they have to REPLY to all of that. How is that better than a REFRESH?

I wonder where you pulled this from since it does not apply at all to the 
model described in iTIP.  You should note that there is NO need to do any 
"full REFRESH" as you so like to say since under the fixed RECURRENCE-ID 
model in the RFCs: The REQUEST for the given UID / RECURRENCE-ID is either 
found or its not in the recipients calendar.   If its found it identifies 
the correct instance in question and so a Reschedule / Update check can 
easily be applied (iTIP Sections 3.2.2.1 or 3.2.2.2 respectively).  If its 
not found then by iTIP 3.2.2 its an invitation to a new instance.  I can 
simply put it on my calendar and send back the REPLY since the invitation 
contains the current version of all data for that instance. 

There is NO need to do a REFRESH, its a new invitation that simply gets 
put on the calendar.

When you use a changing RECURRENCE-ID model then the problem of 
identifying the correct instance in question is raised.  As you so deftly 
noted, its not possible to match to the existing set and since you cannot 
distinguish between a new invitation and a missequenced reschedule the 
ONLY solution is to DESTROY THEM ALL AND RECREATE THEM (aka a "full 
REFRESH").  This is a very drastic thing to do if you the REQUEST was 
simply missequenced Id say! 

Imagine, one reschedule for just 1 instance of any repeating instance is 
lost or delayed and the ONLY solution is to destroy ALL instances in the 
users calendar and ask for them all again!  That works out great don't you 
think?

Oh yeah, adding an invitee to another instance of a repeating entry they 
already know about requires that you send another 'nuke' REQUEST to 
recreate the entire subset of instances the user is invited to.  Even if 
the other instance has not changed!  Yep, thats an efficient workflow 
protocol. 

You MUST do this for Dougs model because thats the ONLY way for the 
invitee to distinguish between a missed reschedule and a new instance 
invitation when you use changing RECURRENCE-IDs.   If the RECURRENCE-ID 
were fixed you can quickly, consistanly and unambiguously tell how to deal 
with the REQUEST.

> sending one REFRESH/REQUEST set?

This incorrectly follows from your misunderstandng above.  There is no 
need to have to resend all the data for all relevant instances if you can 
consistanly identify the instance in question despite missed or 
missequenced iTIP messages.

> devoted to that solution.

Its not a red hering; its germane to the analysis of why we did specifed a 
fixed RECURRENCE-ID (except in the 1 erroneous line in iTIP).

Recovery and handling of the problem is different in each model and its 
also key in understanding why the fixed RECURRENCE-ID works much better 
than the changing RECURRENCE-ID.  No matter how you try or wish, you 
cannot say the behaviours are the same in both models or that the delta 
model functions better.  The analysis of each still stand.

> As opposed to sending SEQUENCE*EVENTS if they are ever to get an update?

Huh!?!  Where do you come up with this stuff I wonder. 

In case its not clear by now Doug, you do NOT need to do any kind of 
REFRESH because no matter the misordering its quick and simple to recover 
the workflow for a particular instance (and ignore the obsoleted 
missequenced REQUESTS if they ever do arrive).  Since a fixed 
RECURRENCE-ID allows me to do the correct instance identification no 
matter the missequcing or message loss I can correctly find the instance 
in question, do the correct invitation / reschedule / update determination 
and apply it and send a REPLY.  Any obsolete iTIP messages are ignored and 
have as such late arrivals are detected as being obsolete (Section 2.1.5 
again!) and thus ignored.

This correct instance identification is 100% impossible when there is a 
missequenced or lost message involved.  Thus the only possible solution is 
to do a "full REFRESH" and wait for the Organziers 'nuke' REQUEST.  Of 
course, since that REQUEST too could be lost you are left with the 
invitees in an indeterminate state and with lots of duplicate orphans that 
will never get cleaned up. 

Just think, a later reschedule REQUEST at a higher SEQUENCE could match 
the UID / RECURRENCE-ID for _some_ particular instance (not necessarily 
the one the Organizer was thinking of) the invitee already has and viola, 
they update the wrong instance.  The REPLY would have data to match the 
Organizers so the Organizer has NO way to tell that the invitee mismatched 
the UID / RECURRENCE-ID and is thinking of the wrong instance.  As such 
they have no reason to send a 'nuke' REFRESH to get the invitee resyncd 
w/them; they think everyone is resynced when in fact one 'orphan' was 
simply rescheduled and the others are still there.

Yep, that sounds like a real good solution to me...

> examples sent to this list for your proposed model.

No, NOT fixed to a particular SEQUENCE value.  The RECURRENCE-ID value is 
fixed when the instance is created and persists indefinitely unless the 
set gets changed (ie: you do an ADD which I have NOT done).  For this case 
iCalendar says that RECURRENCE-ID "might also change" NOT "will change" or 
"should change", etc.  A reschedule on the instance changes the instance, 
not the "set".   If you want to discuss this then perhaps you can show me 
your dictionary where you got "original" means "current" or "latest" from 
and then we can rehash iCalendar again.

You claim busted examples but nothing backs up your assertion.  Im not the 
one trying to infer invitation vs reschedule vs update based on 
RECURRENCE-ID.  NO TEXT OR RESTRICTION TABLE says thats how you decode the 
intent of the REQUEST so I dont know where you get this from.   If you do 
not understand how Section 2.1.5 Message Sequencing applys to all iTIP 
methods under Section 3 then I cant help you there.  Perhaps we need Frank 
or someone else here to transcode it and explaint it a different way.

I do however stand by the analysis I did based on the use of the fixed and 
changing RECURRENCE-ID values. 

> Better yet - why not just point to iTIP and say - yes it is documented

Because I can demonstrate how flawed the delta RECURRENCE-ID model is when 
it comes to missequenced or lost messages.  I can also demonstrate how 
flexible and robust the fixed RECURRENCE-ID model is when it comes to 
these problems.  This should help those who eschew a changing 
RECURRENCE-ID model of its weakness and inflexibility when compared to the 
fixed RECURRENCE-ID model.

I still stand by the analysis I did and am curious if it makes Tim or 
Chris think twice...

> compliant it iTIP? 

I have proposed NOTHING Doug.  I have done an analysis of how each model 
deals with faults introduced into the workflow process.

>                     iTIP already has solved this problem. Trying

You amaze me Doug.  You claim to have years and years of experience doing 
stuff like this and you seem to fail to recognize (or at least 
acknowledge) flaws inherent in the design interpretation you have of 
iCalendar and iTIP.  You are unwilling or unable to distinguish an 
analysis of 2 models from a proposal; I have strived to prevent 
misinterpreations of the RFCs (or to at least prevent others from being 
mislead) and not propose any RFC changes.

You consistanly fail to understand the text in iTIP Sections 2.1.5, 3.2.2, 
3.2.2.1 and 3.2.2.2 which tells a CUA how to handle messge sequencing and 
distinguish between invite/reschedule/update.  You have invented some 
mechanism for differentation DIFFERENT from that in iTIP Sections 3.2.2, 
3.2.2.1 and 3.2.2.2 (based some how on either SEQUENCE and/or 
RECURRENCE-ID in the REQUEST) yet you claim that Im proposing something 
new.

You seem to have latched onto one bulleted case in an example section for 
your understanding of the iCalendar/iTIP design and you have ignored all 
the normalative text in iCalendar/iTIP to the contrary.  You have also 
claimed that both models work just fine when infact it can be shown that 
this is not the case. 

I have attempted to show that iCalendar defines a fixed RECURRENCE-ID 
model and that iTIP supports this.  I have done both an analysis of text 
in iCalendar and iTIP regarding RECURRENCE-ID and Ive done a workflow 
analysis utilizing both a fixed and a changing RECURRENCE-ID model.  So 
far, nothing Ive read indicates that you disagree w/the weakness inherent 
in the delta RECURRENCE-ID model.

It does appear to me that you still do not follow the fixed RECURRENCE-ID 
model examples all that well since as I noted there is NO need to do the 
things you claim because with a fixed RECURRENCE-ID you can easily recover 
from the problems of message loss or missequecing. 

BTW: You have never answered my question: Does each instance have its own 
SEQUENCE or not?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 17:10:18 -0600

[email-masked] wrote:
> I have not proposed anything new.

Your propiosing that to add and attendee, you send a instance update.

That *IS* new.

Here are some snips of how iTIP says to uinvite an ATTENDEE:

  3.2.2 REQUEST

    The "REQUEST" method in a "VEVENT" component provides the following
    scheduling functions:

      ....

    ...
    The "Organizer" originates the "REQUEST". The recipients of the
    "REQUEST" method are the CUs invited to the event, the "Attendees".
    "Attendees" use the "REPLY" method to convey attendance status to the
    "Organizer".
    ...

3.2.2.6 Forwarding to An Uninvited CU

    An "Attendee" invited to an event may invite another uninvited CU to
    the event. The invited "Attendee" accomplishes this by forwarding the
    original "REQUEST" method to the uninvited CU. The "Organizer"
    decides whether or not the uninvited CU is added to the attendee
    ....

Which *IS* distinctly different than:

4.4.2 Modify A Recurring Instance

    In this example the "Organizer" issues a recurring meeting. Later the
    "Organizer" changes an instance of the event by changing the
    "DTSTART" property. Note the use of "RECURRENCE-ID" property and
    "SEQUENCE" property in the second request.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 17:30:20 -0600

[email-masked] wrote:
> for how he interpreted the RFCs.  I was responding to this by pointing 
> out that the internal storage format of any CUA or CS is NOT covered by 
> Are you now saying that all iTIP implementations MUST use a storage 
> format thats basically native iCalendar?

No.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 17:39:07 -0600

Michael Fair wrote:
> all the possibly valid RECURRENCE-IDs are.

Which is NOT the problem. No one is disputing that SEQUENCE:x
where X != 0 is an issue. it is when you may have missed the ORIGINAL
object (maybe you missed the SEQUENCE:0 object). Prior to
this new invention - it was determinable.

> a single instance, and a complete rescheduling of the

To cause the problem it requires that you somehow missed the
SEQUENCE:0 object. Yet it looks *exactly* like a modification.
How can I tell which it is when the 1st UID:x I see is
SEQUENCE:1 ?

What if I was first invited to SEQUENCE:Z yet
I missed Z, so I only see the modification:Z+1.
Now how do It tell if I missed SEQUENCE:Z ?
I no longer can - don't do it that way.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 17:12:26 -0700

Umm....
Ok...
Let's follow this train wreck....

Again, show me code.

Update an instance of a recurring event.
(For arguments sake move Friday, June 13th to the 12th)

Now invite an uninvited CU to the new 12th meeting.

Remember, as per 3.2.2.6 which talks about forwarding:

   When forwarding a "REQUEST" to another CU, the
   forwarding "Attendee" MUST NOT make changes to
   the VEVENT property set.

by VEVENT property set they mean the entire set of
properties on the VEVENT.  In other words, the VEVENT
must be sent wholesale, exactly as is.  There is an
implied exception in which the forwarder MAY add the
new recipient as an ATTENDEE but isn't encouraged to.

After you do this, show me how you didn't change the
property set, and why the recipient CUA isn't confused
by this.

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 17:34:36 -0700

> How can I tell which it is when the 1st UID:x I see is

Ok, in an attempt to finish this train of thought since
nothing we have said about this topic in what feels like
umpteen posts I will try to say it a different way (again).

You don't care what it actually it is, it's an invite
to you.  You treat it like an invite, your REPLY to it
like an invite, and the world is a happy place.

> I missed Z, so I only see the modification:Z+1.

In a fixed-id model Z+1 _is_ the most recent version
of the event so you couldn't care less about whether or
not you saw Z.  You don't need Z.  Z and <Z is old news,
history, obsolete, deep sixed, laid to rest, forever
more to be ignored, and if it ever shows up it will be
forwarded to /dev/null, dropped without further
consideration, thrown out, tossed away, have its bits
recycled, or anything else you'd like to use to mean
not even looked at or processed.

> I no longer can - don't do it that way.

If you are saying that "Z" was a recurring description,
and that "Z+1" is an instance modification that's a
bit different.

If the CUA thinks there's something fishy about the
SEQUENCE numbers it can send a REFRESH if it likes.
In fact, if Z+1 is the very first instance in the
entire set of events refrenced by the recurring series,
and it only describes an instance of a recurring event,
it SHOULD request a REFRESH and use it to single that
it might have missed a message.  Right after it puts
it on the calendar and REPLYs to it as a new invite.

This behavior should be exactly the same in both models.

Are you saying that in the 'current-value' if Z described
a recurring event, and Z+1 described an instance update,
and the CUA saw Z+1 (the update) before it saw Z that the
CUA should ignore or refrain from processing the message
at all until it sees Z?

Tsk, Tsk Doug that's not good.

But to give you the benefit of the doubt.

Doug, in the 'current-value' model what should a CUA
do if it received Z+1 (the update to an instance) before
it saw Z (which described the recurring event)?

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 19:17:00 -0600

> like an invite, and the world is a happy place.

Except your CUA is out of sync with the ORGANIZER
if it was an update and you missed the original.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 18:16:27 -0700

While not in direct reply to this response, at the
end of at least two messages, Bruce has asked a
specific and direct question of you Doug.

Does each instance of a recurring event have its own
SEQEUNCE or is there one SEQUENCE value for the entire
recurring series which they all share?

In case the question isn't clear:
If I have a new recurring event and the only
I change I make is to update one instance in
which I use SEQUENCE:1, and then I go to
update a totally different instance, is the
SEQUENCE value for the second instance 1 or 2?

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 19:24:33 -0600

> SEQUENCE numbers it can send a REFRESH if it likes.

And how would it know? You just made an update look
like a new object. Its out of sync and can't even
know that it is out of sync.

> it on the calendar and REPLYs to it as a new invite.

How would it know that? You sent a modification (or
was it a new event?).

> Tsk, Tsk Doug that's not good.

But it can happen over iMIP. Objects can get out of
order. Just check the Received-by lines compared
to the 'Date' lines of email on this WG list.
They are not all in order by 'Date' or 'Received-by'.
They are just mostly ordered by one or the other.

> it saw Z (which described the recurring event)?

As you would NOT invite someone with an object that
also looked like a modification, it could tell that
it was a modification and do a REFRESH. But because
you want that exact same object it to also look like
an invitation it can no longer tell in anyone's model.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 19:54:45 -0600

> SEQUENCE value for the second instance 1 or 2?

If you update any date or recurrence rule (and other things), then
you have to update the SEQUENCE, but you do not necessarily have
to send it to all attendees. So the booked object is at '2'.
The rules are in iCal/iTIP, so I am not sure of your question.

There is an example in iTIP that covers that case exactly.

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 19:27:53 -0700

I don't know what this hangup on modification
versus new object is about?

It's been explained several times and since you
continue to persist, it will continue to be repeated
until you say something that is actually consistent
and responsive to what's been written.

An instance of an event is an object in its own right.
An update to an instance of an event is targeted
specificly at that separate independent object.

If I send a REQUEST and it contains UID:1/RID:1
then it is a reference to the object UID:1/RID:1.
UID:1 part is only the first half of the primary key.

It doesn't, in anyway shape or form, have any bearing
on the totally separate object UID:1.  The CUA doesn't
need the object UID:1.  The CUA might hope to someday
see UID:1 but it can be perfectly functional without it.

It has seen UID:1/RID:1.
It has processed UID:1/RID:1.
UID:1/RID:1 is a uniquely identifiable singleton.

The CUA treats UID:1/RID:1 as a singleton.
It sends a REPLY to UID:1/RID:1 is a singleton.
It can get invited to UID:1/RID:1 in the same way
it could get invited to any other singleton.

UID:1/RID:1 has its own independent versioning
just like any other singleton.

Do you understand this yet?

With that in mind read my responses to your questions.

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> know that it is out of sync.

It would know because it received a message for the
singleton UID:1/RID:1 which because the RID value is
not null, it knows should be part of a recurring set.
However, it has no records for a UID:1/RID:NULL
recurring event description object on its calendar.

Speaking on behalf of the CUA:

"Hmm, I just received an invite to the singleton
UID:1/RID:1 however I have no record of a UID:1
object that tells me which RIDs are actually valid.
Something is fishhy.  Well I'll just assume that
this object I received is valid, process it like
the singleton that it is and request a REFRESH
for the UID:1/RID:NULL object.  I probably just
missed a message somewhere."

That's how it knows.

> How would it know that? You sent a modification (or

Doesn't matter what I sent, it gets processed as a new
singleton UID:1/RID:1.

The absence of UID:1/RID:NULL from my calendar indicates
I might have missed something.

> They are just mostly ordered by one or the other.

I totally know it can happen, I never said it couldn't.
I never said I didn't even want it to.  The fact that
it can happen is the entire reason a fixed-id model is
totally required.  If the 'current-value' can't hack it
in that environment it should get out of the kitchen.

It's been repeatedly shown how the 'current-value' model
falls flat on its face when faced with trying to deal
with missequenced messages.  You have not provided any
discussion to the contrary yet.  Since you seem to have
nothing to say about our demonstrations of the
'current-value' falling flat on its face in this regard,
I can only assume that you agree that 'current-value'
model falls flat on its face.  But rather than conceed
to the flaws and discuss workable solutions, you choose
to ignore what we say so you can continue to try to harp
on a flaw in the fixed-id model that just isn't there.

The fixed-id as has been continuously demonstrated
to perform exceedingly well in this exact situation.

> an invitation it can no longer tell in anyone's model.

I don't get it.  You didn't answer the question.

What does the CUA do with the message it receives?
Does it put on the calendar or not?
Does it ask the participant if they want to go or not?
Does it send a REPLY or not?

Whatever logic you are you using for the 'current-value'
model to detect that it should a REFRESH request can
also be used in the 'fixed-id' model I assure you.

Are you assuming that a REQUEST for a new object can't
trigger a REFRESH while the CUA processes it?

If it helps you understand this better I can call it
an update to a missed object without losing any ground
or changing any semantics.  It doesn't track iTIP, but
you don't seem to care about that on this point anyway.

Ok fine, let's pursue this pedantic exercise.

Here goes:
Doug, in the fixed-id model a message which to you
looks like an update (note this is not a reschedule!
No incrementing of the SEQUENCE from the ORGANIZER's
copy is done) is used to invite a new CU to an instance
of a recurring event.

The CUA will process it as an update to an object that
doesn't exist (wtf?).  The CUA will put it on its calendar,
it will send a REPLY with the partstat set according to
the CU's preference, and processing it will trigger a
REFRESH request.

Does that make you happier?

The net result is the exact same.  A REFRESH got sent
and the user got invited to singleton they were supposed
to be invited to.  You just chose to process it in a way
that doesn't follow the terminology of sections 2.1.5
or 3.2.2.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 19:44:51 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

> The rules are in iCal/iTIP, so I am not sure of your question.

Ok let me try again and I'll make it even easier.

I schedule UID:1 to recur every Friday this year.
Here I use SEQUENCE: 0

step one: Reschedule Friday, June 13th to Thursday, June 12th.
Here I use SEQUENCE:1

step two:  Reschedule Thrusday, Jan 3rd to Thursday, Jan 2nd
Here I use SEQUENCE:___ <-- Fill in that blank.

The fixed-id model says that it's 1.
This is consistent with section 3.7.1 which says:
   ... the protocol is designed so that each recurring
       instance may be both referenced and versioned ...

Your model says that it is...?

> There is an example in iTIP that covers that case exactly.

No there isn't.  Prove it.

4.4.2 Only covers how to do the first "step one", it doesn't
      even touch doing the second step.

4.4.7 Introduces an "Add" which changes the entire event set
      and effectively updates the SEQUENCE number for all
      instances to 2.  Again this only a step one example.

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 20:53:29 -0600

> versus new object is about?

That idea does not work for all cases.

Your CUA will be out of SYNC with the organizer view
if iMIP objects that are sent as updates are interpreted
as new objects - when received out of order via iMIP.

You can pretend that out of order objects will not
happen via iMIP all you want. It is not true.
Servers queue up outgoing email all of the time
and for reasons of system load can send them out in an
order that is random. Your CUA will call it a new
item then ignore the SEQUENCE:x-1 object because
it thinks it is older.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 21:15:27 -0600

> Ok let me try again and I'll make it even easier.

Your example is the same as the one I replied to. Re-read
my post.

> No there isn't.  Prove it.

Do you want me to send you a copy of iTIP?

--

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 11 Aug 2003 20:55:03 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> Your example is the same as the one I replied to. Re-read

You said "If you update any date or recurrence rule
(and other things), then you have to update the SEQUENCE"
... " the booked object is at '2'."

That means - despite your unwillingness to give a clear
answer to what the SEQUENCE number should be, or whether
or not all instances of the same recurring event have the
same SEQUENCE - you believe that all instances of a
recurring event share the same SEQUENCE.  Right?

As in when I reschedule one instance of a recurring event,
the SEQUENCE number for all instances increments.

This is distinctly different from the iTIP where each
instance is both referenced and versioned.

Rescheduling an instance of a recurring event is _not_
an update to "any date or recurrence rule (and other things)."

> Do you want me to send you a copy of iTIP?

That would be useless I have already read iTIP and have
seen that it is not there, reposting iTIP will just waste
hard drive space and bandwidth.

I want you to prove that iTIP has an example that covers
that case because I say it isn't there and therefore one
of us is in error.  If you say it is there point me to it.

It's pretty easy actually.

Either paste the section number along with the relevant
example(s) text or just give a section number and I can
read it for myself.

Just in case you misunderstood them, sections 4.4.2
and 4.4.7 do not cover that case.  They cover different
cases which I explicitly described.  Is there somewhere
else in iTIP that has examples covering the modification
of recurrence instances that I am missing?  You say that
I am, I say that I am not, you can shut me up completely
by just citing the example you claim to be there.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 16:02:18 -0700

> That idea does not work for all cases.

Assuming that we are still talking about Z-1 being
a recurring event and Z is an instance modify then
it does work.  It works very well.

I am so far the only one on this list who has potentially
shown a sequence of messages that _might_ cause an
inconsistency using the fixed-id model because there is
one circumstance under which the RECURRENCE-ID _might_ change.

And in fact, it happens to be the same sequence of messages
that causes the 'current-value' model to fall apart.

> as new objects - when received out of order via iMIP.

Why would it be out of sync?

The Z message is totally and completely a self contained
update with all information from the <Z message in regards
to that instance.

> happen via iMIP all you want. It is not true.

It's good that we can agree on this.  Forever more neither
one of us has to prove that messages can arrive out of order,
it can just be accepted that they might.

Further, all of us will have to defend what our respective
models do when it receives messages out of order.

> item then ignore the SEQUENCE:x-1 object because

The fixed-id model doesn't ever need to see the SEQ:x-1
object to know that it has the latest version of the instance.

I think you believe that if X was recurrence instance modify,
and X-1 was a recurring event definition, that we would ignore
X-1 and that would be bad.

And if the fixed-id model did ignore it, you would be right,
it would be bad.

But it doesn't ignore it so you just misunderstand the model.

If we receive an instance update with UID:1/RID:1/SEQ:1 we
will put it on the caledar as a recurring event instance
with the primary key UID:1/RID:1.

If afterward we recieve a full blown recurring event
UID:1/SEQ:0 we will not ignore it because we haven't
seen a message for event UID:1/RID:NULL before.

We will process this new event message and add every instance
that we have not already seen (i.e. we will skip UID:1/RID:1
because we already have that object at a SEQ > 0).

The easiest way for you to think about this is using SQL.
An event in the iTIP model has a primary key of:
UID:  NOT NULL UNIQUE
RECURRENCE-ID: DEFAULT VALUE NULL
events primary key (UID, RECURRENCE-ID);

Note that in this definition RECURRENCE-ID could be NULL
and is NULL unless otherwise specified.

So in the iTIP model all events that do not have a
RECURRENCE-ID in them effectively have a RECURRENCE-ID
of NULL.

So when we recieve the first for message UID:1/RID:1 we look
in our calendar and don't find one.  We process it as a
new event and put that instance on the calendar using the
primary key UID:1/RID:1.

Then when we later receive a message for UID:1/RID:NULL
we look in our table and again don't find one.  We process
it as a new event and now put the entire series on our
calendar.  When we process the UID:1/RID:null series,
we don't clobber the UID:1/RID:1 we have as that would
be stupid.  UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL
is at SEQ:0.  As such, our SEQ:1 version of UID:1/RID:1
trumps UID:1/RID:NULL's implied SEQ:0 version of the
same event.  Same goes for DTSTAMP in case the SEQUENCE
values happen to match.

This is all very clear from reading 2.1.5.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 17:36:17 -0600

> it does work.  It works very well.

Thank you for acknowledging that you did see the email.

The example did NOT include the sequence of events that your
email replied to, and it does not address the issue.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 18:47:01 -0700

> Thank you for acknowledging that you did see the email.

I've been trying to figure out what email you've been talking
about and you haven't been very helpful.

I've been trying to figure out what example you've been
talking about and you haven't been very helpful.

> email replied to, and it does not address the issue.

Ok since you have still decided to be very unhelpful in
calrifying which sequence of the 5 or 6 we have floating
around this chain is, I'm going to try guessing. Again.

I'm going to assume that it at least has something to do
with the email where you made a reference to Z and Z+1.
Since that's the one you are grateful that I acknowledged.

One of the examples we have floating around that we haven't
yet quoted back to you is:

"

Despite the fact that we have shown several times why this
isn't a problem I'll go through it trying to specically
use this quote.

Since you didn't specify which type of message Z or Z+1 is
in terms of whether or not it was an instance or the whole
recurring series.  I'm going to give two cases.

Case 1) A CU being invited just to that particular instance.
Case 2) A CU being invited to a whole series but gets just
        the instance update first.

------------------------------------------------------------------
Case 1) Z+1 = Instance / Z = Instance

First the CUA sees:

UID:1
RID:1
SEQ:Z+1
DTSTART:newStart
ATTENDEE;partstat=NEEDS-ACTION:A

The CUA  finds neither UID:1/RID:1 nor UID:1/RID:NULL on
its calendar which would have been a prior version so it
declares it a new event.
It finds out from the CU if they would like to attend to
formulate a REPLY.
It adds UID:1/RID:1/SEQ:Z+1 to the calendar as a new
singleton event and sends a REPLY with UID:1/RID:1/SEQ:Z+1.

The absence of UID:1/RID:NULL and a SEQUENCE jump > 1
signifies a potential missed message for UID:1/RID:NULL.
It sends a REFRESH for UID:1/RID:NULL because that's what
it SHOULD do, but it muses that it didn't have to and things
would still be compliant and its calendar would still
be consistent.

Then it sees:

UID:1
RID:1
SEQ:Z
DTSTART:oldStart
ATTENDEE;partstat=NEEDS-ACTION:A

It throws this away because it already has a more recent version
of UID:1/RID:1.

The CUA ends up with a single instance on its calendar at newStart
as intended by the ORGANIZER.

------------------------------------------------------------------
------------------------------------------------------------------
Case 2) Z+1 = instance / Z = whole series

First the CUA sees:

UID:1
RID:1
SEQ:Z+1
DTSTART:newStart
ATTENDEE;partstat=NEEDS-ACTION:A

It adds UID:1/RID:1 to the calendar at SEQ:1 as a new event.
It finds out from the CU if they would like to attend
this instance and sends a REPLY with UID:1/RID:1/SEQ:Z+1.

As above it uses the absence of UID:1/RID:NULL and SEQUENCE
jump >1 to signify a potentially missed message so it sends
for a REFRESH of UID:1/RID:NULL.

Then it sees:

UID:1
SEQ:Z
DTSTART:oldStart
ATTENDEE;partstat=NEEDS-ACTION:A
RDATE/RRULE:someStuff that describes a set with RID:1

It doesn't throw this one away because it's never seen
UID:1/RID:NULL before.  The CUA finds out from the CU if
they want to attend the whole series except for RID:1
because it already knows the answer to that.
The CUA adds UID:1/RID:NULL/SEQ:Z to the calendar and
sends a REPLY with UID:1/SEQ:Z.
It does not update UID:1/RID:1/SEQ:Z+1 at all because
Z+1 is more recent that Z and contains the most recent
information as per the ORGANIZER's calendar.

The CUA ends up with many instances of the event each
matching the ORGANIZER's calendar.  Most at Z, one at Z+1.
------------------------------------------------------------------

So Doug, how'd I do?  Did I guess the elusive example you
claim we are ignoring yet?

Do you see any internal inconsistencies or iTIP/iCal
violations?  Are you ready to put the 'current-value'
model through the same sequences as from above yet?
I'll even let you show us the code lest you feel that
we might get the behavior wrong.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 20:25:40 -0600

Michael Fair wrote:

> UID:1/RID:NULL before.

That is not iTIP:

(1) It gets tossed as it is obsolete.

(2) Your CUA would not have a clue that z-1 was ever sent if
     it gets lost in transit. And the CU would have then acknowledged
     SEQUENCE:Z telling the ORGANIZER they you agree to the meetings
     that the CUA has never seen (in z-1). Because newer SEQUENCE
     REPLYs obsolete older ones. The ATTENDEE-CU and ATTENDEE-CUA
     having *never* seen (z-1), would NEVER do a REFRESH and never know
     they had an incomplete list of instances. That's why you can not
     invite an ATTENDEE by sending an object that looks like an
     instance modification.

     Prior to Bruces proposal to add ATTENDEEs in that way, the ATTENDEE-CUA
     would have known it was an update. Now it thinks it is a new original
     and complete object. With Bruces model the error checking is busted.

     In addition, if Z were acknowledged then the ATTENDEE could get on
     an airplane, they would not see z-1 until they got back (if ever)
     from a meeting that was canceled in z-1.

     If that object only looks like a modification, then the ATTENDEE-CUA
     would know to do a REFRESH and the ATTENDEE would know that they
     do not have all of the information to make the decision.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 01:54:23 -0700

Yay, some actual constructive and debatable text.
Thank you very much for adding this to the discussion.

> (1) It gets tossed as it is obsolete.

But it is iTIP and it doesn't get tossed away as the
CUA hasn't seen it yet.

From the same section (2.1.5):

I'm fairly certain that we can all agree that (1) precedes (2)
in the iTIP text and therefore (1) must be applied before
moving on to (2).

A message with addressing of:
UID:1
RID:1
SEQ:<doesn't matter>

Is trying to talk about RECURRENCE-ID: 1 of UID: 1.
Why do we know that?
The presence of a RECURRENCE-ID tells us so as per (1).

The second sentence of (1) is very clear the "primary key"
for "an instance of a recurring component" is UID/RID.

Further, from the REQUEST restriction table we have:

                        it MUST NOT be present.

Therefore the presence of the RECURRENCE-ID property says that
we MUST be referring to an instance of, and not the recurring event.

I'll say it again, if a message EVER contains RECURRENCE-ID it
MUST be referencing an instance of a recurring event.  Looking
back at (1) we see the primary key for an instance is BOTH
the UID AND the RECURRENCE-ID.

And by extension therefore a message that does not contain a
RECURRENCE-ID CANNOT be referring to an instance of a recurring
event and consequently MUST be describing the parent event.

Therefore when a message later shows up that references the
recurring component itself with no RID, we know we haven't
seen it before.  We've only seen a message talking about
one of this event's instances, but not this event itself.

Ironic that this is actually a problem in Doug's single SEQUENCE
model.  If I schedule UID:1/SEQ:0 and then update RID:1 at SEQ:1
and then update RID:2 at SEQ:2 and then update RID:3 at SEQ:3
as Doug would have you do.

Then if his model sees and accepts 3 first, his model then can't
process 0,1, or 2 because his application of 2.1.5 ignores
section 3.7.1 where each instance is independently versioned.
The fixed-id / multisequence model that iTIP/iCal describes
does not have this problem.

Doug would have you believe that receiving a message for
UID:1/RID:1 could a screw up in receiving a message for
UID:1/RID:NULL because the SEQUENCE for UID:1/RID:1 was
greater than that of UID:1/RID:NULL which it would not.

If Doug is right, than iTIP is totally intolerant of receiving
an update to an instance before the definition itself.  I have
asked him in another subthread what his model would do with the
first message in the very plausible world where a CUA receives
the instance update before the recurrence definition.  I believe
the answer was throw it out or hold it until it saw the definition.
In other words, his model can't process an instance update message
unless it has a copy of the set definition.  I find this to be
rather inconsistent with iTIP's vehemence that it be tolerant of
missing any message.

An instance of a recurring component is a singleton.
It has a special relationship to its parent UID component, but
it is its own independently referenced and versioned component.

This is evidenced in section 3.7.1:
   ... meeting instances still need to be referenced ...
   ... the protocol is designed so that each recurring instance
   may be both referenced and versioned ...

As another consistency problem with Doug's model, if I was going
to add/update a comment, or a description, or an X-PROPERTY, or
a summary, or the STATUS, or an attatchment, or a RELATED-TO, or
a URL to an instance of a recurring event I would use an iTIP
message that referenced UID:1/RID:1.
Why is an ATTENDEE property any different from other properties?

In fact if I was going to change the DTSTART, or the ORGANIZER
for that instance, I would again reference UID:1/RID:1.  Why is
it that Doug believes that the string ATTENDEE need be treated
any differently from any of the other properties?

As even further evidence, when an ATTENDEE responds to update
the status of their attendence for a particular instance, they
respond with a message referencing UID:1/RID:1.  So if I send
a message to a recipient that updates an instance to a recurring
event, and this is the first time they've seen that component,
and due to the presence of an RID know that it must be referencing
a recurring event instance, and they are listed as an ATTENDEE
why shouldn't the CUA just accept the message as the latest
version of an instance to a recurring event that it currently
has no set description for?

If it had the set description that's the message it would send.
Why should it be any different just because it doesn't have the
set description?

If it turns out to be the only instance in that series they
are ever informed about why does the CUA care about the parent?
It would be no different than having the "RELATED-TO" set in
some other singleton but not having the events that the event
says it is related to.

For those of you still reading these long posts,

>      and complete object. With Bruces model the error checking is busted.

It's not busted, it thinks it is a new, original, and complete instance
of a recurring event.  It also happens that what it treats it as, is
what it actually is, a complete description of a recurrence instance.

>      from a meeting that was canceled in z-1.

This is either impossible, plain stupid human error by the ORGANIZER,
the actual intended result of the ORGANIZER.  I don't think Doug is
thinking his assertion through.  If someone cancelled the recurring
series at Z-1 - and then they go an update a cancelled instance
of a recurring event at Z - they either meant to reschedule it in
which case it's a good thing our friend didn't cancel their flight,
or the ORGANIZER is just being mean, trying to help our friend
accumulate frequent flyer miles, or just plain in error in which
case no model can really help them.

If the recurring event was actually canceled at Z-1 there'd be no Z.
It wouldn't exist, it'd have never been created and therefore could
never have been misdelivered.

Of course if history is an indicator Doug is just going to
delete this whole cancellation example from his next post
rather than admit he was in error or try and address it.

>      do not have all of the information to make the decision.

By virtue of receiving an event with both a UID and RID for which
neither a UID/RID component nor a UID/RID:NULL component can be
found it knows that it might have missed something.

The SEQUENCE numbers for each component are tracked separately.

UID:1/RID:NULL is at Z
UID:1/RID:1 is at Z + N where N=number of instance modifications.
UID:1/RID:2 is at Z + J where J=number of instance modifications.

I can receive a message for UID:1/RID:1/SEQ:Z+N and then a message
for UID:1/RID:2/SEQ:Z+J and then a message for UID:1/SEQ:Z
and still keep track that the recurring series was defined at
Z, RID:1 is at Z+N, and RID:2 is at Z+J and not get confused.

If I ever receive a message for UID:1/SEQ:Z+I where I>N and I>J
then I know that the entire series for UID:1 has been rescheduled.

If I ever receive a message for UID:1/SEQ:Z+I where I<N and I>J
then I know that the entire series for UID:1 has been rescheduled
inclusive of RID:2, but that my current copy of RID:1 is more recent.

If I ever receive a message for UID:1/SEQ:Z+I where I<N and I<J
then I know that the entire series for UID:1 has been rescheduled
and that both my copies of RID:1 and RID:2 are more recent.

By detecting the instances being more recent, I can then shield
them from being redefined by the reschedule to the series.

I can receive these messages in order you can concoct and the
resulting calendar will be identical to the ORGANIZER's.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 10:13:34 -0600

> But it is iTIP and it doesn't get tossed away as the

It is obsolete - it gets tossed. If an ATTENDEE gets a SEQUENCE:10000
object, how long should it wait be able to process the first 9,999
missing objects with confidence. That is simply ridiculous.

All CUA's would then be forced to do a REFRESH just to be sure.
I'll go with 1 set of packets and not 5 sets of packets to get the
same thing done.

Even if that could work reliability - why bother with that
complexity? Just send an invite as documented in iTIP. No
history needed, no attempting to guess if a packet is an
update or an invitation, no manual REFRESH just to be sure?
Why break iTIP?

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 11:34:03 -0700

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> missing objects with confidence. That is simply ridiculous.

If an ATTENDEE's CUA receives a SEQUENCE:10000 object it simply
processes it with confidence that is the most recent and up to
date version of that object.  I've said it before, and I'll say
it again.  UID:1 and UID:1/RID:1 are not the same obejcts.
So a SEQUENCE:10000 object for UID:1/RID:1 is meaningless and has
no bearing on what came before it.

Let's look at what might have come before it, a prior version of a
UID:1/RID:1 object or a UID:1 object.  In either case, SEQ:10000 is
a more recent version of UID:1/RID:1.

The only potential danger, as you suggest, is if the recipient CUA
would throw away the UID:1 object at SEQ:<10000, but since it's
never seen it before (becuase UID:1 and UID:1/RID:1 are separate
objects) it won't.

> update or an invitation, no manual REFRESH just to be sure?

We are sending an invite as it is documented in iTIP, I've
sent several messages directly quoting iTIP and lots of other
sections as consistent support for why iTIP says what it says.

It's obvious we don't agree on what iTIP says, it's obvious
that both of us claim the other's model breaks iTIP.  I'm
the only one in this thread who is showing any kind of iTIP
evidence (save that last quote you sent) that their model
is the right one.  I'm also the only on this thread using
iTIP to debunk the validity of the other's model.  I can't
remember the last time in this whole series of message you
showed one scrap of iTIP messaging (even after directly asked
for it) that can support your claim.

I'll do it it again here now to save you the effort of having
to hunt for it because I'm generous about helping you clarify
what it is I'm referring to and am interested in a constructive
conversation here.

In your model, if I wanted to invite user's A and B to a single
instance of a recurring event RID:1 and RID:2 respectively,
assuming that there had been no reschedules so everything is
at SEQUENCE:0 I would send them the following:

For ATTENDEE A:
UID:1
SEQ:0
DTSTAMP:timeOfInviteToA
DTSTART:startOfRID:1

For ATTENDEE B:
UID:1
SEQ:0
DTSTAMP:timeOfInviteToB
DTSTART:startOfRID:2

Right?
I mean you wouldn't send A:
UID:1
SEQ:0
DTSTAMP:timeOfInviteToA
RDATE:dateOfRID:1
DTSTART:startOfRID:1

and then send B:
UID:1
SEQ:0
DTSTAMP:timeOfInviteToB
RDATE:dateOfRID:2
DTSTART:startOfRID:2

Right?  I mean we are talking about singleton's in your
model and not a recurring event of one instance?

So now B decides to forward the invite to A.

B forwards the REQUEST exactly as is:
UID:1
SEQ:0
DTSTAMP:timeOfInviteToB
DTSTART:startOfRID:2

A's CUA looks on its calendar and finds UID:1/SEQ:0
already exists and so it falls to DTSTAMP.  If A was
invited first, it will interpret this as being invited
to a more recent version of the same event, it will
remove its current copy and use the updated one from
B.  If however, B was invited first, the DTSTAMP will
be older and it will throw the message out.

In either case, A now believes it is invited to only
one event.  In the case where the invite to A was
older and it replaced its own with B's it now erroniously
believes that it is invited to the wrong instance.
It in the case where the invite to B was older it will
never receive the invite intended.

This is not a problem in the model I described as the CUA's
will differentiate each invite based on the RID included and
figure out that A and B are talking about two separate instances
of the same recurring event - and just live with the fact that
they have never seen a description of parent event.

I find it hard to exactly track how this particular thread
of "what iTIP to send" to invite a CU to a particular instance
has much of anything to do with 'fixed-id' versus 'current-value'

The iTIP inclusive of an RID:1 to specify an invite to a
particular instance is just as valid in either model and
totally consistent with all other iTIP text.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 14:37:10 -0600

Michael Fair wrote:
> date version of that object. 

You can type it as many times as you want, but why not just
send it as documented in iTIP? Whey that extra overhead?

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 14:59:40 -0700

First off, thank you for acknowledging that this method
actually works.  This is progress.  At least now we are
arguing about whether or not it's what iTIP says to do
and whether or not it actually includes extraneous overhead.

> send it as documented in iTIP? Whey that extra overhead?

Where is it documented in iTIP that you should fragment
the UID to invite someone to a particular instance of a
recurring event?

Where is it documented in iTIP that to change the set of
ATTENDEE properties for a particular instance you should
do it in a way other than the method used to change all
other properties for that same instance?

Why did you ignore the very real implementation problem
with your recommendation which I included in the
previous post?

Why have you not explained to us why fragmenting the UID
as you suggest, to keep various branches of the UID floating
around for the different sets of instances that particular
ATTENDEEs are invited to, is not in violation of the
uniqueness requirement for the primary key of an event?

I don't see how this method actually uses any extra
overhead except for maybe a little fatter message
used on the transport wire (but the same or fewer
amount of resources to process it) in two cases:

1) The recipient was invited to the subset of instances
   at the same moment in time by the ORGANIZER and
   not piecemeal.
or
2) If the recipient is invited to a set of instances but
   not the whole series AND they request a REFRESH AND the
   instances haven't ever been renegotiated by the ORGANIZER.

Other than those two very specific cases which are hardly
worth the effort in optimizing for, the two models use
identical resource overhead.  If you need me to, I can
go through the effort of proving it, but since you thus
far have not seemed to care to read/respond to the effort
put into explaining it to you I'm going to save my time
and energy lest you, or someone else on this list, request
the demonstration of why either of these "invite" models use
the same overhead in all but those two instances.

I'd also like to make you aware that we are totally off the
subject of this thread at the moment.  We are now debating
two different models of inviting a CU to an instance and
not the merits/disadvantages of fixed-id/current-value
recurrence-id property values.  The two discussions are
hardly related to each other.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 20:50:04 -0600

Michael Fair wrote:
> actually works. 

I said no such thing.

--