Subject: Re: Fw: Correct handling of Recurrence-id

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 13 Jun 2003 16:26:56 -0700

Robert Ransdell/Westford/IBM wrote:

>
> You can only change individual dates or ADD to the repeat dates.  You 
> can not re-roll the repeat rule.
>
> If you re-roll the repeat rule.  This is a new meeting.. UNID changes

That would probably be a good simplification of the protocol but where 
does that come from ?
I don't see anywhere in iCAL/iTIP that the organizer can't change the 
RRULE. Or did I miss something ?

Arnaud

>
>
>
> _____________________
> Note: new email address
>
> [email-masked]
>
>
> *Arnaud Quillaud <[email-masked]>*
> Sent by: [email-masked]
>
> 06/13/2003 01:47 PM
>
> To
> "[email-masked]" <[email-masked]>
> cc
>
> Subject
> Re: Fw: Correct handling of Recurrence-id
>
>
>
>
>
>
>
>
> Doug Royer wrote:
>
> >
> >
> > Arnaud Quillaud wrote:
> >
> >>  >
> >>  > > Unless Doug or George can demonstate how to resync, etc
> >>  > using a delta
> >>  > > model I suggest we make a strong WG note to remove the
> >>  > misleading text
> >>  > > from the next revision of 2445 and move on.
> >>  >
> >>  > You do not have to SYNC - simply do a REFRESH and get the
> >>  > latest object
> >>  > version.
> >>  >
> >> But in Bruce model, you do *not* have to do a REFRESH. That sounds
> >> like a much simpler mechanism.
> >> So, what is the advantage of the changing recurrence-id model ?
> >> Arnaud
> >
> >
> > You are totally hosed if you were not part of SEQUENCE:0
>
> I've asked Bruce about a new attendee being added to the VEVENT (I've
> included both my question and his response). In his view, the recurrence
> set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee
> would be the original one so there wouldn't be any ambiguity.
>
> >
> > or somehow loose your data.
>
> If you loose your data, you're hosed, whatever the model. All you can do
> is to do a REFRESH, that is, if you still have the ORGANIZER and UID.
> The REFRESH would work (see above).
>
> >
> >
> > And when 100% of the original instances change and you
> > somehow missed an important change. The new instances
> > will not map to the SEQUENCE:0 instances and you
> > might apply them incorrectly.
>
>
> You mean, if the organizer change the recurrence set (e.g. change the
> event from weekly to bi-weekly) ?
> I guess, Bruce rules needs to be refined to say that the list of
> recurrence-id  refers to the latest recurrence set
> (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer.
> Bruce ?
>
>
>
> BTW, is there a section in iTIP that talks about handling of exceptions
> on the attendee side, when receiving a REQUEST with a new recurrence set ?
> For example:
> 1st REQUEST
> RRULE: weekly on mondays for ever
>
> 2nd REQUEST
> RECURRENCE-ID=second monday
> DTSTART=second tuesday
>
> 3rd REQUEST
> RRULE: weekly on wednesday
>
> Does the 3rd REQUEST implicitly means cancel of the second tuesday's
> instance ? Or should the attendee consider it still valid unless it
> receives a CANCEL ?
>
> Thanks,
>
> Arnaud
>
>
>
> ----- Message from Arnaud Quillaud <[email-masked]> on 
> Fri, 23 May 2003 17:15:12 -0700 -----
> *To:*
> [email-masked]
> *cc:*
> [email-masked]
> *Subject:*
> Re: Correct handling of Recurrence-id
>
>
>
> [email-masked] <mailto:[email-masked]>wrote:
>
> > The only disadvantage of version 1 that I can think of is about
> > someone joining the party while some rescheduling has already
> > occured. Since the newcommer won't have the SEQUENCE: 0 of the
> > recurrence set, he might interpret the set of RECURRENCE-ID
> > differently. But maybe this is just because I don't understand what
> > the right iTIP workflow is.
>
> Its not a problem for the non-delta model.  The Organizer simply sends 
> a new invitee a REQUEST that contains the information they will need 
> to correctly identify the instance and put it on the right date/time. 
>  So, continuing the example I used earlier to add Arnaud to Friday 
> 13-Jun-03 I would simply send the following REQUEST:
>
>   BEGIN:VCALENDAR
>  PRODID:-//ACME/DesktopCalendar//EN
>  METHOD:REQUEST
>  VERSION:2.0
>  BEGIN:VEVENT
>  ORGANIZER:_Mailto:[email-masked]
>  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:_Mailto:[email-masked]
>  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug:_Mailto:[email-masked]
>  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George:_Mailto:[email-masked]
>  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom:_Mailto:[email-masked]
>  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki:_Mailto:[email-masked]
>  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud:_Mailto:[email-masked]
>  DTSTART:20030613T140000Z
>  DTEND:20030613T150000Z
>  SUMMARY:Head bashing
>  _UID:[email-masked] 
> <mailto:UID:[email-masked]>
>  SEQUENCE:3
>   RECURRENCE-ID:20030609T140000Z
>  DTSTAMP:20030523T225900Z
>  END:VEVENT
>  END:VCALENDAR
>
> In my example, I was talking about the case where the Organizer wants 
> to invite a totally new attendee to the whole serie, not just a 
> particular instance.
>
> initial REQUEST. Bruce invites bob and only bob:
>
> BEGIN:VEVENT
> UID:that
> SEQUENCE:0
> DTSTART: monday the 1st at 10am
> RRULE: every monday forever
> ATTENDEE: bob
> END:VEVENT
>
> Bruce changes the second instance to tuesday, so he sends a new iTIP 
> REQUEST to bob:
>
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> END:VEVENT
>
> Now, Bruce wants to invite arnaud to _all _instances of the recurring 
> event. Arnaud has no information about this event in his CUA. So I'm 
> assuming Bruce will send him one iTIP request containing the "master" 
> event + the exception, right ?
>
> What will this request look like in your model ?
>
> Will it be:
>
> BEGIN:VCALENDAR
> METHOD:REQUEST
> ...
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am*
> RRULE: every monday forever*
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR
>
> or will it be:
>
> BEGIN:VCALENDAR
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am*
> RRULE: every monday forever
> RDATE: tuesday the 9th at 10am
> EXDATE: monday the 8th at 10am*
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR
>
> Or did I totally missed the logic of iTIP and does he send something 
> else ?
>
> Thanks,
>
> Arnaud
>
>
> ----- Message from [email-masked] on Tue, 27 May 2003 
> 16:22:30 -0400 -----
> *To:*
> [email-masked]
> *Subject:*
> Re: Correct handling of Recurrence-id
>
>
>
>
> Arnaud Quillaud wrote on 05/23/2003 08:15:12 PM:
> > Now, Bruce wants to invite arnaud to all instances of the recurring
> > event. Arnaud has no information about this event in his CUA. So I'm
> > assuming Bruce will send him one iTIP request containing the
> > "master" event + the exception, right ?
>
> Yes.  From iTIP, Section 3.2.2 REQUEST:
>
>   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.
>
> So the iCalendar stream would contain the "base" definition followed 
> by any instance specific data that "override the base" definition.
>
> > What will this request look like in your model ?
> >
> > Will it be:
> >
> > BEGIN:VCALENDAR
> > METHOD:REQUEST
> > ...
> > BEGIN:VEVENT
> > UID:that
> > SEQUENCE:1
> > DTSTART: monday the 1st at 10am
> > RRULE: every monday forever
> > ATTENDEE: bob
> > ATTENDEE:arnaud
> > END:VEVENT
> > BEGIN:VEVENT
> > UID:that
> > SEQUENCE:1
> > RECURRENCE-ID: monday the 8th at 10am
> > DTSTART: tuesday the 9th at 10am
> > ATTENDEE:bob
> > ATTENDEE:arnaud
> > END:VEVENT
> > END:VCALENDAR
>
> For the most part yes.  The SEQUENCE property in the base would be 0, 
> not 1 but close enough... (Since only the 2nd instance got rescheduled 
> only its SEQUENCE value has changed.)
>
> > or will it be:
> >
> > BEGIN:VCALENDAR
> > BEGIN:VEVENT
> > UID:that
> > SEQUENCE:1
> > DTSTART: monday the 1st at 10am
> > RRULE: every monday forever
> > RDATE: tuesday the 9th at 10am
> > EXDATE: monday the 8th at 10am
> > ATTENDEE: bob
> > ATTENDEE:arnaud
> > END:VEVENT
> > BEGIN:VEVENT
> > UID:that
> > SEQUENCE:1
> > RECURRENCE-ID: monday the 8th at 10am
> > DTSTART: tuesday the 9th at 10am
> > ATTENDEE:bob
> > ATTENDEE:arnaud
> > END:VEVENT
> > END:VCALENDAR
>
> Not this because the "base" definition does NOT define the entire 
> repeat set that was originally defined.  It defines a set of [ "Every 
> Monday Forever" + "Tuesday the 9th" - "Monday the 8th" ].  The 
> "update" that follows now specifies an instance that was not part of 
> the "base" (the RECURRENCE-ID is not reachable from the "base" because 
> it was EXDATEed out).
>
> The other problem I see is that the 1st object defines a Tuesday the 
> 9th instance initially thus making the RECURRENCE-ID for that instance 
> of "Tuesday the 9th" and not "Monday the 8th" which later got 
> rescheduled to the 9th (in the second object).  This could mean that 
> when a CUA rolls out both of these VEVENTs they 'dedup' the 2 "Tuesday 
> the 9th" entries (per iCalendar) and may not be able to properly 
> reschedule the Tuesday entry to a new date/time.
>
> > Or did I totally missed the logic of iTIP and does he send something 
> else ?
>
> No, I think that was pretty much on track.  The RFCs could use some 
> prose in some areas and no doubt if you spend some cycles on repeating 
> entries more gaps/mistakes will appear.
>
> Does this jive with your expectations?
>
> Bruce
> ===========================================================================
> Bruce Kahn                                INet: 
> [email-masked]
> Messaging & Collaboration                 Phone: 978.399.6496
> IBM Software Group                         FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 19:39:35 -0600

> RRULE. Or did I miss something ?

It is not in iCAL/iTIP - your right. There is no such restriction or rule.
If they want to do that they would have to re-issue all of the REQUESTs
so that the CUA's inserted all of the new entries. That method could get
tricky if the users do not allow scheduling conflicts. So the ORGANIZER
would have to CANCEL them in one pass then re-issues them with the new UID in
a second pass.

There would be no way to have the CUA automatically issue REPLYs because
the CUA would have no way of knowing they were the same object with
the UID renamed. You would have hope that they did not re-use the now free
time for another meeting between the CANCEL and REQUEST.

Any vendor specific data that the CUA stored in the objects
that is not populated back to the world that was saved with the
object would get tossed out as there would not be a way to re-attach
it to the seemingly unrelated UID. And in the CAP world that
means that ALL user-local VALARMs and VCARS would be tossed and the CU
would have to manually re-insert them back into the new objects.

I do not think that is a simplification.

-- 

  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: Mon, 16 Jun 2003 18:11:12 -0400

Since there would  be no mapping of existing repeat dates to the new dates 
generated by the new rule, this is equivalent to a NEW meeting.  Thus you 
must assign a new UNID.
_____________________
Note: new email address

Arnaud Quillaud <[email-masked]> 
Sent by: [email-masked]
06/13/2003 07:26 PM

To
Robert Ransdell/Westford/IBM <[email-masked]>, 
[email-masked]
cc

Subject

Arnaud

---

From: Doug Royer <[email-masked]>
Date: Mon, 16 Jun 2003 17:23:51 -0600

[email-masked] wrote:
> 
> Since there would  be no mapping of existing repeat dates to the new 
> dates generated by the new rule, this is equivalent to a NEW meeting. 
>  Thus you must assign a new UNID.

I think this proposal will fix the incompatibilities and fix the
problem of mid-object-existance joining by attendees from organizers
CUAs which fix the recurrence-id to sequence zero.

For organizer CUAs that can only generate sequence zero recurrence-ids
and a recurrence rule change occurs.

  If sent to an attendee CUA that only assumes a sequence zero recurrence-id,
  there will be no problem as the organizer CUA will CANCEL and re-REQUEST
  on recurrence rule changes. Any CU specific data in the CS for that UID
  will be lost at the attendee end.

  If sent to an attendee CUA that assumes recurrence-id is tied to
  the sequence number, there will be no problem as the organizer CUA will
  CANCEL and re-REQUEST on recurrence rule changes. Any CU specific data
  in the CS for that UID will be lost at the attendee end.

For organizer CUAs that tie the recurrence-id to the sequence number
and a recurrence rule change occurs:

  If sent to an attendee CUA that only assumes sequence zero recurrence-id,
  there will be no problem as the attendee CUA will be unable to map the
  recurrence-id to the sequence zero object on recurrence rule changes,
  AND the attendee CUA will be able to tell that the new object has recurrence
  rule change, and then it must do a REFRESH. They should throw away their
  version of the object and use the new object returned from the organizer
  pretending it is sequence zero. No CU specific data in the CS for
  that UID need be lost.

  If sent to a an attendee CUA that assumes recurrence-id is tied to
  the sequence number, there will be no problem. No CU specific data
  in the CS for that UID will be lost.

When implementing a CUA if you are going to assume that the recurrence-id
is always tied to sequence zero, then simply doing a REFRESH should
solve the problem if you pretend that whatever sequence you get back
from the REFRESH is sequence zero. This will also allow mid-existince
objects to be joined by CUA/attendees that assume that recurrence-id
is tied to sequence zero. Without this assumption, there is no way
to ever have an ATTENDEE join mid object existence as they would never
be able to process recurrence-ids.

I think this solves the problem for everyone. Comments?

--

---

From: [email-masked]
Date: Wed, 18 Jun 2003 13:07:38 -0400

I don't really consider this a fix since A RESCHEDULE without anyway to 
map, is not really a reschedule.
Also this does not fix the  BUG of changing recurrence-id's on a 
reschedule.  You have never given a valid counter example for changeable 
recurrence-id's to Bruce Kahn's valid example of how fixed recurrence-id 
work.  This issue can not be closed until unless it is proven that 
changeable  recurrence-id's work.
_____________________
Note: new email address

Doug Royer <[email-masked]> 
Sent by: [email-masked]
06/16/2003 07:23 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

  If sent to an attendee CUA that only assumes a sequence zero 
recurrence-id,
  there will be no problem as the organizer CUA will CANCEL and re-REQUEST
  on recurrence rule changes. Any CU specific data in the CS for that UID
  will be lost at the attendee end.

  If sent to an attendee CUA that only assumes sequence zero 
recurrence-id,
  there will be no problem as the attendee CUA will be unable to map the
  recurrence-id to the sequence zero object on recurrence rule changes,
  AND the attendee CUA will be able to tell that the new object has 
recurrence
  rule change, and then it must do a REFRESH. They should throw away their
  version of the object and use the new object returned from the organizer
  pretending it is sequence zero. No CU specific data in the CS for
  that UID need be lost.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Jun 2003 13:54:17 -0600

> map, is not really a reschedule.

There is a way to re-map, tie the sequence number to the recurrence-id.
OR when they do not map, do a REFRESH. Any CUA needs to be able
to do a REFRESH anyway if things get out of sync for any reason
including recurrence-id issues.

> reschedule.

I know of no bug except in implementations that do not do a REFRESH
when they get out of sync for what ever reason. The recurrence rules
being out of sync is just one of the many reasons to do a REFRESH.

> You have never given a valid counter example for changeable 

I do not work for you or Bruce. I do not *have* to give you anything.
I have participated in various internet and IETF calendaring
working groups since 1978. And did participate in the discussions
on this topic and others and I will continue to participate in the
discussions.

Bruces example showed why is it broken to tie recurrence-id to
sequence zero. And he stated in his emails that attendees can
not join later if they can not figure out the sequence zero recurrence-id's.
Bruces examples did not show that tying the recurrence-id to the
sequence number failed, he stated that that is not they way he
does it and in his views that is the way it should be. And he
did not dispute that doing a REFRESH to get the latest copy breaks
users that do not already have the original sequence zero object.
He also does not dispute that there is no way to ever get the
sequence zero object if that is not the current sequence. And
you seem to agree that doing a REFRESH and starting with that
copy works, but you do not like it.

Recurrence-id's work when you tie them to the sequence number. You simply
refuse to acknowledge that it works for others and you simply refuse to
and have declared on this list that your product will never change.
That's your choice. Demanding that iCal and iTIP change because you do
not want to change is not going to convince anyone. Or declaring that
it is a bug because  some number of vendors do it one way or another
way also does not solve the problem.

The resolution to this problem that I sent works. Use it or not. However
for those that tie the recurrence-id to the sequence number, they CAN and DO
allow recurrence rule changes for the same UID. For those that
do tie it to sequence zero only, it can be made to work ny doing a REFRESH.
I tested it. Do or do not do it, but do not expect me or others to reduce
the features in our code simply because you declare it is a bug.

--

---

From: [email-masked]
Date: Wed, 18 Jun 2003 17:01:29 -0400

There was nothing broken about Bruce's example.  I'm assuming since you do 
not want to defend your use of recurrence-id's and since all existing 
iCalendar products on the market that I know of, use fixed recurrence-id, 
that the correct usage is fixed recurrence-id's.  Any other use is 
incompatible.
_____________________
Note: new email address

06/18/2003 03:54 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

not join later if they can not figure out the sequence zero 
recurrence-id's.

The resolution to this problem that I sent works. Use it or not. However
for those that tie the recurrence-id to the sequence number, they CAN and 
DO
allow recurrence rule changes for the same UID. For those that
do tie it to sequence zero only, it can be made to work ny doing a 
REFRESH.
I tested it. Do or do not do it, but do not expect me or others to reduce
the features in our code simply because you declare it is a bug.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Jun 2003 15:58:15 -0600

[email-masked] wrote:
> 
> There was nothing broken about Bruce's example. 

Perhaps you missed Bruces posts where he declared
that there is no way for an attendee to join
if they do not have sequence zero when tying
the recurrence-id only to sequence zero?

--

---

From: Arnaud Quillaud <[email-masked]>
Date: Thu, 19 Jun 2003 10:51:14 -0700

Your proposal might solves the problem of changing the recurrence rule.
But it doesn't solve the more severe interoperability problem of 
mismatching interpretations of the recurrence-id:
If the dtstart of one instance is changed once and the 
organizer/attendee UAs have different interpretations of what the 
recurrence-id should be, *even if all the requests arrive in the right 
order without any lost*, the workflow is broken from now on.

Of course a REFRESH from the attendee could probably straighten the 
situation, but then it seems that REFRESH is the magic solution to all 
the ambiguities of the iCAL/iTIP spec. If the attendee UI needs to do a 
REFRESH, even when nothing goes wrong, why should the organizer UI 
bother with sending individual REQUESTs when an instance changes ? Why 
not send the whole object all the time ?

Instead of trying to get the 2 to coexist, I think we really should 
settle one way or the other.

My experience with iCAL/iTIP is that there are other areas where 
interoperability is made difficult by the openness of the current specs 
(e.g. the flexibility of the rrule grammar). Is there any effort going 
on to amend or add an "interoperability recommendations" document to the 
protocol ?

With CAP coming into the picture soon, I think it is quite important to 
have its foundations (iCAL/iTIP/iMIP) straightened up. For example, to 
go back to our beloved RECURRENCE-ID, CAP makes several references to it 
in some critical sections of the spec. If we leave the RECURRENCE-ID as 
defined today (i.e. undefined), it means that the CAP interoperability 
is doomed from the beginning.

Thanks,

Arnaud

---

From: Doug Royer <[email-masked]>
Date: Thu, 19 Jun 2003 13:38:03 -0600

Arnaud Quillaud wrote:
> bother with sending individual REQUESTs when an instance changes ?

When any of RRULE, EXRULE, RDATE, or EXDATE changes, you must bump
the SEQUENCE number anyway. Then your going to have to send new REQUESTS
to all ATTENDEEs anyway. ...

 > Why not send the whole object all the time ?

...So yes. I have spent much time reviewing the years of archives over the
last week or so, I can not find (until the recent proposals), any
conversations that said you must re-issue a UID on recurrence rule
changes. I believe it was the intent of this WG to be able to
evolve the recurrence rules with UIDs over time. And it works
as long as you tie recurrence-id to the sequence number.

There also have not been any posts that I can find (except the
recent proposals) that said you can CANCEL or update the
recurrence rules without bumping the sequence number. I think
they are a red herring as this WG did already solve that problem.

> settle one way or the other.

I agree that would be best. Fixating the recurrence-id to sequence zero
prevents the recurrence rules from ever changing and will make CAP
VCARs, NOTIFICATIONS, local CU VALARMs break in CAP. So I just do
not see how that will work. So we would have two choices, invent
a new iTIP method that says UID-old == UID-new. But that is not
necessary, just use the sequence, that is one reason it was invented.

In fact iCAL says:
    ...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. ...

Note that 'SEQUENCE' *is* in the text. The argument that was given
is 'I do not want to force CUA's to have to do REPLYs' is also
bogus for two reasons. (1) The ORGANIZER-CUA is NOT required
to send REQUESTs for SEQUENCE number updates unless it feels
it needs to and (2) the ATTENDEE CUA can be written to detect
what changes and act automatically to some changes.

A CUA should be able to detect that any recurrence rule changed
and do a REFRESH whenever it gets lost. I just do not see that as
difficult. Forcing the world to never be able to update recurrence
rules seems like the choice not to make.

> on to amend or add an "interoperability recommendations" document to the 

Not in any formal way.

> is doomed from the beginning.

I dispute that it is undefined :-)
I think the dispute is how it is defined.

That does bring up another point. CUAs that fix their recurrence-id to
sequence zero will never be able to fetch objects by date/time range with
EXPAND=TRUE or FALSE. *Unless* they just happen to have sequence zero
laying around in their CS.

Changing any recurrence rule requires the SEQUENCE number to be bumped
and at that point the CUAs could just (as you state above) send the
entire new object. We could specify that as a SHOULD. Then this
specific problem goes away (I think).

--

---

From: [email-masked]
Date: Thu, 19 Jun 2003 17:22:05 -0400

> including recurrence-id issues.

SHOW ME HOW A REFRESH IN A DELTA MODEL WORKS!  If you miss 1 reschedule 
you cannot ever recover no matter what voodoo you _THINK_ or _CLAIM_ 
happens.  Show us otherwise!  Ive already demonstrated how it fails but 
perhaps your Kung Fu is stronger.  Show us...

> when they get out of sync for what ever reason. 

Not sure what you're claiming to be true here but a REFRESH is an iTIP 
message that an invitee sends to the Organizer.  Its only mandated use in 
iTIP is for the case where the ADD method from the Organizer is NOT 
supported.  There is nothing claming or implying that an invitee need do a 
REFRESH back to the Organizer in any other case.  Since a REQUEST message 
is fully self contained and thus not reliant on any other message and 
since iTIP Section 2.1.5 clearly says that "the highest numeric value for 
the "SEQUENCE" property obsoletes all other revisions of the component 
with lower values." I have to question your assertion here. 

If the higher SEQUENCE obsoletes the lower ones then WHY would the invitee 
need/want to do a REFRESH in response to, say, a SEQUENCE difference of 
2??  The higher one they have obsoletes the one they currently have PLUS 
the missed one.  So what use is the REFRESH from the invitee??  It only 
results in a duplicate of the higher SEQUENCE REFRESH being sent. 

You can keep repeating "Just do a REFRESH" but unlike a Nike commercial 
that does not solve anything nor make me buy into it.  Show us how it 
does.  Please!!

> I do not work for you or Bruce. I do not *have* to give you anything.

You do have to be able to back up your claims at least if you want anyone 
to take them seriously.  Repeating them ad naseum w/o any examples though 
does will not make it true.

> on this topic and others and I will continue to participate in the

Then why wont you show us the iTIP on how a REFRESH will recover from a 
missed SEQUENCE in your 'delta' view of things?!  Could it be because you 
cannot because it doesn't??

> sequence zero. 

Huh??  My examples have why the absolute models works and why a delta 
model wont work.  Thats all. 

> sequence number failed

My examples showed how keeping a fixed RECURRENCE-ID works and trying to 
rewrite the RECURRENCE-ID will not.  If you missed that Ill be glad to 
show you again. 

In the mean time Id really appreciate it if you could stick to the issues 
and not duck them when you cannot show how it works.  I think Ive been 
more than patient and I certainly wont let the issue just drop since its a 
key interoperability issue.

>                                                            And he

What are you smoking out there Doug?!?!  If the RECURRNECE-ID NEVER EVER 
EVER changes (a claim Ive made all along) then it does NOT require an 
invitee to know the SEQUENCE:0 RECURRENCE-ID for a particular instance in 
order to process the latest REQUEST at, say, SEQUENCE:10. 

The RECURRENCE-ID never changes so its the same at SEQUENCE:0 as it is at 
SEQUENCE:10 as is at SEQUENCE:100523.  As such, the invitee has NO problem 
keeping in sync w/the Organizer.

In _YOUR_ (and Georges too) view of things though the RECURRNECE-ID 
changes with each reschedule (paraphrased a bit but I can get you the 
exact quote if you really need it).  As such the invitee ABSOLUTELY, 
POSITIVELY MUST have ALL (repeat _ALL_) of the reschedule REQUESTS from 0 
thru 100523 in order to properly stay in sync w/the Organizer!  Otherwise 
they cannot recalculate the RECURRENCE-ID each time!  Nothing you wish for 
or claim (but cannot demonstrate here) will change that.  Sorry...

> sequence zero object if that is not the current sequence.

The absolute model does NOT require that.  Why do you think it does? Since 
RECURRENCE-ID does not change why does the invitee need to have the 
SEQUENCE:0 version of it when the current one is SEQUENCE:5??  I dont get 
it?  Actually I do; you're the one who doesnt...

> Recurrence-id's work when you tie them to the sequence number. 

Go read iTIP Section 2.1.5 again (or for the first time?).  You dont tie 
them together.  UID/RECURRENCE-ID is the primary key to find the 
particular instance.  THEN you use SEQUENCE to see if you know that 
'version' of the instance.  Not the other way around...  Is this not 
clear??

>                                                               You simply

We cannot acknoledge that it works because it doesn't.  You can easily 
send a message saying it does but you have yet to show the actual iTIP 
that demonstrates it using your view of the way things should work.

How about showing actual iTIP fragments of how your model can recover from 
a missed REQUEST and then perhaps there would be something for us to 
actually acknowledge...

>                                                  Or declaring that

Hahaha.  I didnt realize you were a part time comic!  I really needed that 
to lighten my end of day.  Thanks.

> The resolution to this problem that I sent works. 

What did you send?  I havent seen anything that remotely approaches iTIP 
fragments on how it works.  Did I miss 'em??

> However
> for those that tie the recurrence-id to the sequence number, 

Are going to be in a world of hirt when they try to interoperate with 
other vendors that do adhere to the actual RFCs since they clearly did not 
read and understand Section 2.1.5 of iTIP on how to do sequencing of 
messages, etc.

> I tested it. 

Great, you tested it with yourself and that proves what? 

Did you try testing with other products that support iCal like Notes, 
Organzier, Outlook, Exchange or Evolution? 

Or better yet could you cut/paste the iTIP into a WG message so the rest 
of us can evaluate it?  Id love to see how your homogenous system handles 
missed REQUESTS.  Please show us!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 19 Jun 2003 16:16:49 -0600

> perhaps your Kung Fu is stronger.  Show us...

So Bruce, what do YOU expect to get back from a REFRESH?
An unrelated object? A another UID object? Or a voodoo doll :-)
Or the entire object you asked for?

I really do not understand why you think that a REFRESH will
not get you the object you ask be sent.

You have not shown any examples of how a REFRESH returns bogus data.
You have not shown any examples of how the results of a REFRESH
are anything un-usable.

If you do a REFRESH on UID:1, you get back the UID:1 object
in its latest and most up to date state.

---

From: [email-masked]
Date: Fri, 20 Jun 2003 19:21:25 -0400

> So Bruce, what do YOU expect to get back from a REFRESH?

I expect to get a REQUEST with the matching UID/RECURRNECE-ID at the 
latest SEQUENCE value.  If you are not clear on the use of REFRESH then go 
reread iTIP, Section 3.2.6 REFRESH.  It says:

3.2.6 REFRESH

   The "REFRESH" method in a "VEVENT" calendar component is used by
   "Attendees" of an existing event to request an updated description
   from the event "Organizer". The "REFRESH" method must specify the
   "UID" property of the event to update. A recurrence instance of an
   event may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated event. The "Organizer" responds with
   the latest description and version of the event.

It pretty clearly descibes it use I think.  Its not vague on what the 
Organzier is to send back either: "the latest description and version of 
the event". 

So, if Im invited to an instance of a repeating entry and I send you a 
REFRESH I expect you to send me the REQUEST for that UID/RECURRENCE-ID at 
the current SEQUENCE.  So if the instance is currently at SEQUENCE:10 then 
I expect your CUA to send me SEQUENCE:10.  Not SEQUENCE:0.  Not 
SEQUENCE:5.  Just for SEQUENCE:10.

If I were to use a delta model where the RECURRENCE-ID value changed every 
time the SEQUENCE did (to match the new DTSTART as you claim) and I was 
currently at SEQUENCE:5 then just how would your CUA sending me the 
SEQUENCE:10 REQUEST help me to get back in sync?? 

In order to match the RECURRENCE-ID I MUST have the SEQUENCE:6 DTSTART, 
the SEQUENCE:7 DTSTART, the SEQUENCE:8 DTSTART and the SEQUENCE:9 DTSTART 
(and apply them in order) before I could use the SEQUENCE:10 REQUEST to 
find the right instance.  Thats 5 REQUESTs at different SEQUENCEs, NOT 1.

> Or the entire object you asked for?

And how do I match the SEQUENCE:10 RECURRENCE-ID in the REQUEST you send 
back to the SEQUENCE:5 RECURRENCE-ID that I currently have???  HOW!?!?  It 
is physically NOT possible.

> not get you the object you ask be sent.

Still do not see it??

Besides I think you keep forgetting / ignoring the fact that iTIP says in 
3.2.2 REQUEST:

   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.

(The text under 3.4.2 REQUEST for VTODOs properly includes "SEQUENCE" too 
but thats an already known omission in 3.2.2.)  For the case of repeating 
entrys you should replace "UID" with "UID"/"RECURRENCE-ID" in the text 
above to be consistant with "To reference an instance of a recurring 
component, the primary key is composed of the "UID" and the 
"RECURRENCE-ID" properties" from Section 2.1.5

So, if I have UID:12345, RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 and I 
opt to ask you to REFRESH it and you send me UID:12345, 
RECURRENCE-ID:20030625T173000Z, SEQUENCE:10 I will find that I do not know 
the UID/RECURRENCE-ID primary key (Section 2.1.5) and thus I take the 
former action described above and treat it like a new request (same UID, 
different instance!).  Now I have 2 instances of UID:12345 on my calendar 
but only 1 is actually supposed to be there.

No matter what I send to you regarding UID:12345, 
RECURRENCE-ID:20030619T150000Z, SEQUENCE:5 instance, Ill never be able to 
do anything more with it (except let it block my busytime on my calendar) 
since by your description its got a stale RECURRENCE-ID and I have no way 
to get to the current RECURRNECE-ID that I can see.

> You have not shown any examples of how a REFRESH returns bogus data.

Its not bogus data on a REFRESH; its that the REQUEST that the REFRESH 
triggers provides the REFRESH sender with any means of resycing!

> You have not shown any examples of how the results of a REFRESH

Twice I have.  You have yet to even once show any iTIP fragments of how I 
can resync if I miss one intermediate rescheduling REQUEST.  3 weeks and 
counting (or is it 4 now)...

> in its latest and most up to date state.

If Im only invited to an instance (or subset of instances) then would you 
send me the entire set now in response to my REFRESH?  Gee, that means Im 
now invited to all instances and not just 1 or a subset!  What a wonderful 
way to party crash.  Ill keep that in mind when we do the next 
CalConnect... 

Please show me how an invitee to a single instance or subset of instances 
will be able to resync to UID:1 if they are at SEQUENCE:1 and you are 
currently at SEQUENCE:5?

Also, you seem to have a problem w/the concept of primary and secondary 
keys as described in iTIP Section 2.1.5.  For repeating instances the 
primary key used to see if you already have that instance is the 
UID/RECURRNECE-ID pair.  As such, in order for the CUA to determine if 
they have the REQUEST or not (per the cited 3.2.2 REQUEST text above) the 
CUA uses the UID/RECURRENCE-ID pair to look for the instance.  If its 
found then its an existing instance and we can proceed to step 2 under 
2.1.5 and use SEQUENCE.  If its not found then its a new REQUEST and we do 
not need to worry about the rest of Section 2.1.5 since this is the first 
copy of that instance we've seen.

If the UID/RECURRENCE-ID pair is found then the CUA applys step 2 and 
checks the SEQUENCE of the found instnace w/that of the REQUEST.  If the 
REQUESTs is higher, its newer and thus obsoletes the one we have and so it 
should be presented to the CU.  If the REQUESTs is lower, its older and 
thus obsoleted by the copy we already have and so it can be safely ignored 
and disposed of.  If the SEQUENCEs are the same then we proceed to step 3 
and check the DTSTAMP values.

You seem to think that A) SEQUENCE should be used to determine the 
validity of RECURRENCE-ID (since you've said RECURRENCE-ID changes each 
SEQUENCE), B) that the SEQUENCE for every instance is shared (ala UID) or 
C) both A) and B). 

A can be clearly shown incorrect by (re) reading iTIP Section 2.1.5 on 
primary and secondary keys.  (Common sense: If you change the keys on your 
house door, will the old keys work to let you in?  If you change the key 
on your hash will you get to the same bucket every time? Of course not...)

B is not something thats written anywhere in any of the RFCs and was never 
in any draft!  If you did this then rescheduling any 1 instance of a 
repeat set would mean the instant invalidation of _all_ other instances 
and having to renegotation their status all over again!  I would hope that 
that would be clear but perhaps not.

Im heading out now but I hope to see some iTIP fragments on Monday showing 
us how resycing a single instance after a missed SEQUENCE change or two is 
possible...  Given Dougs insistance on this being possible I would tink 
that it would be a piece of cake to show besides just a simple UID:1.

Bruce

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 20 Jun 2003 17:34:28 -0700

[email-masked] wrote:

> latest SEQUENCE value.  If you are not clear on the use of REFRESH 
> then go reread iTIP, Section 3.2.6 REFRESH.  It says:

...
Maybe there is some misunderstanding here.  My guess is that Doug means 
"Do a REFRESH with just the UID" when you seem to think "REFRESH with 
UID/RECURRENCE-ID".
Doug ?

Of course then, what does a REFRESH with just the UID mean ?

Do we all agree that, in the case of a recurring event, it means: "Send 
me back the whole object: master object with any existing exceptions" ?

Arnaud

---

From: Doug Royer <[email-masked]>
Date: Fri, 20 Jun 2003 18:36:47 -0600

[email-masked] wrote:
> latest SEQUENCE value. ...
 > ...
> 
> If I were to use a delta model where the RECURRENCE-ID value changed 
> every time the SEQUENCE did (to match the new DTSTART as you claim) and 
> I was currently at SEQUENCE:5 then just how would your CUA sending me 
> the SEQUENCE:10 REQUEST help me to get back in sync??  

Simple, at that point the ATTENDEE CUA can throw all of the same UID
data away and use the sequence:10 data it just got. Nothing to 'sync'.
Problem solved as the ORGANIZERs copy *is the valid copy* of the data.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 20 Jun 2003 19:44:16 -0600

Arnaud Quillaud wrote:
> "Do a REFRESH with just the UID" ...
> Doug ?

Yes.

> Of course then, what does a REFRESH with just the UID mean ?

It gets you the entire UID recurrence rules and all.

> me back the whole object: master object with any existing exceptions" ?

Yes. When you get out of sync for any reason do a REFRESH/UID
and no recurence-id. Correct.

--

---

From: [email-masked]
Date: Mon, 23 Jun 2003 11:15:45 -0400

> "Do a REFRESH with just the UID" when you seem to think "REFRESH with 

My examples have been how do I resync a particular UID/RECURRENCE-ID all 
along.  Thats what "If Im only invited to an instance (or subset of 
instances) then would you send me the entire set now in response to my 
REFRESH?" means. 

As I noted in my last posting, if Doug sends me a REQUEST for the entire 
sequence then all of a sudden Im invited to all instances and not just 1. 
Thats NOT the proper action to take clearly is it??

Sending a REFRESH that describes the entire UID does not work for someone 
whose only coming to a particular instance or a subset of the entire set. 
Cant no matter how ya slice it. 

> Of course then, what does a REFRESH with just the UID mean ?

2446 is not vague on this at least to me.  It says:

   corresponding to the associated event.

It means a refresh to either a non-repeating entry or the entire set 
defined by the UID.  This should not be ambiguous.  Ive already responded 
how it works in the absolute model (that was ~3 weeks ago) but it seems 
that Doug thinks that a REFRESH w/o any RECURRECE-ID info it in response 
to my UID/RECURRENCE-ID REFRESH requst will solve the problem.  It cant 
for those not invited to the entire set; unless you want to now include 
them on all the instances... %^|

> me back the whole object: master object with any existing exceptions" ?

2446 says:

                                       The "Organizer" responds with
   the latest description and version of the event.

The discrepancy is what the "master object" is or perhaps its unclear to 
some that if the REFRESH is for a particular UID/RECURRENCE-ID then the 
REQUEST that is expected back should be for that RECURRENCE-ID.  This also 
does not cover the orphaning of the earlier RECURRENCE-ID either if it 
changes for each reschedule per Dougs suggestion. 

This has gone on for way too long and I think Doug and others are 
forgetting several important points so Ill try to get us refocused:

1: We _had_ this kind of disucssion back in ~July 1999 and we all agreed 
then that RECURRENCE-ID does NOT change!  Go check the archives and look 
for Dan Hickmans thread.

2: Dougs/Georges entire design philosphy is based on _1_ paragraph in 2445 
that contradicts _several_ others in 2445 and 2446.  The paragraph that 
they seem to be fixated on for justifying changing RECURRENCE-IDs is one 
that was left in from the initial model where we did have a delta model. 
After we (the WG) took a hard look at how workflow was effected and 
impacted by trying to recover from missed messages we found we COULD NOT 
use a delta model.  Go ask the original authors of 2445/2446 if you dont 
believe me!

3: The 3rd paragraph under the 4.8.4.4 Recurrence ID Description on p. 108 
contradicts the 4th (which I claim is residual to the delta model) in that 
it says that RECURRENCE-ID does not change.  However it is in total 
agreement with 2446's Section 2.1.5 Message Sequencing where it describes 
using UID/RECURRENCE-ID as the primary key to find the instance in 
question (so you can THEN use SEQUENCE to determine if the message is 
older or newer).  It is also in total agreement with the text under 2446's 
Section 3.2.2 REQUEST where it describes how to determine if this is a new 
invitation or an update (2nd paragraph after the bulleted list).  So are 
all these _other_ paragraphs WRONG too?  Its just common sense that if the 
primary key changes (ie: RECURRENCE-ID) then you are NOT referring to the 
same instance.  Doug keeps talking about using SEQUENCE to check the 
RECURRENCE-ID value but no matter what he wants thats BACKWARDS from the 
clear and unambiguious steps defined in 2.1.5 for message sequencing.

4: The authors of the original RFCs have already implemented and interop 
tested their products (several products really) along with anyone else who 
has done an engine so far.  Did we all get the model wrong or is someone 
new just trying to change it now based on a bit of residual prose?  The 
standards are ~255 pages combined so its not unlikely that 1 paragraph 
could get overlooked in the change from delta to absolute that we did. 
Other mistakes happened and this is just one more.

5: It can easily be demonstrated that its not possible to resync a single 
instance or subset of instances if the RECURRENCE-ID changes and a single 
reschedule was missed.  No delta model solution exists to cover this and 
thats just one reason why we long ago changed the underlying model from 
delta to absolute.

This entire discussion has merely pointed out that we need to remove the 
4th paragraph under the Detailed Description of RECURRENCE-ID in 2445 so 
that its totally unambiguous that RECURRENCE-ID never changes. 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 23 Jun 2003 10:23:08 -0600

> instances) then would you send me the entire set now in response to my 

It is not needed, do a full (not recurrence-id) REFRESH and you are
back in sync. No code needs to be written that you would not have
already needed to write.

--

---

From: "Chris Olds" <[email-masked]>
Date: Mon, 23 Jun 2003 10:37:58 -0700

On Mon, 23 Jun 2003 11:15:45 -0400, Bruce_Kahn wrote
> My examples have been how do I resync a particular UID/RECURRENCE-ID 
> all along.  Thats what "If Im only invited to an instance (or subset 
> of instances) then would you send me the entire set now in response 
> to my REFRESH?" means. 

None of the CUAs I have expose the ability to do this, but I would expect that
any CUA capable of inviting someone to a subset of a set of meetings
(recurring or otherwise) would be able to keep track of this.  As a result,
the organizer's CUA would be able to send the current state of the subset I
had been invited to (in reality, for privacy reasons, I would expect that it
would completely conceal from me that I was only invited to a subset).

> As I noted in my last posting, if Doug sends me a REQUEST for the 
> entire sequence then all of a sudden Im invited to all instances and 
> not just 1. Thats NOT the proper action to take clearly is it??
> 
> Sending a REFRESH that describes the entire UID does not work for 
> someone whose only coming to a particular instance or a subset of 
> the entire set. Cant no matter how ya slice it. 

The (modest) additional complexity of making this work must be implemented in
the organizer's CUA, but it works just fine.  Pegging the RECURRANCE-ID to the
values of SEQ=0 is the more brittle mode - how can I add instances to a set
w/o issuing a new UID in that case?  This is clearly an anticipated action,
but it breaks SEQ=0 semantics by adding an instance that cannot be addressed
by RECURRENCE-ID if those values are fixed at SEQ=0.  Forcing a new UID to be
allocated is contrary to the described workflows, and would reqire cancelling
the sequence and issuing a new REQUEST with the new UID in order to work at all.

Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta model.
Since the current state of the REQUEST can always be obtained via REFRESH, any
attendee CUA that finds itself out of synch can recover with one pair of messages.

Pinning RECURRENCE-ID values to SEQUENCE 0 requires attendee CUAs to do
complex tracking of the mapping of RECURRENCE-IDs to instances as the event
evolves, and what I think of when I hear the term 'delta model'.  It is easy
to find series of updates that make RECURRENCE_IDs ambiguous, and easy to have
instances with no valid (according to this model) RECURRENCE-ID.

While this view appears to agree with Doug, it is based on my own reading of
iTIP.  It wouldn't surprise me if many other people held this view, but arent'
saying anything because of the tenor of many of Bruce's messages.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: [email-masked]
Date: Mon, 23 Jun 2003 13:54:04 -0400

Doug persisted on 06/23/2003 12:23:08 PM:
> back in sync. 

My example was for someone who is NOT invited to the entire set.  Examples 
are: guest speakers for monthly team meetings, one-time presenters for 
regular meetings (ie: design review boards), Proxys / Delegates, etc. 

Do you expect to just invite them to all instances if they do a REFRESH 
for the UID/RECURRENCE-ID you invited them to?  After all you previously 
sent a REQUEST for a particular UID/RECURRENCE-ID and they for some reason 
decided to REFRESH (per your suggestion).  Now they get a REQUEST for all 
instances??  They are _not_ invited to all so why send a new REQUEST for 
the entire set now rather than the instance they just got invited to?

PLUS this entire suggestion is predicated on using SEQUENCE to find the 
RECURRENCE-ID/UID pair when sequencing the REQUESTs the invitee receives. 
HOWEVER that is BACKWARDS from 2446's description in Section 2.1.5 Message 
Sequencing.  This section of iTIP is not ambiguous so I dont know why some 
keep trying to use SEQUENCE to determine the validity of RECURRENCE-ID; 
thats clearly contrary to Section 2.1.5.  I dont know why Doug thinks that 
a new REQUEST will solve the problem because it has a higher SEQUENCE when 
SEQUENCE is used as the secondary key to matching the REQUEST to the 
instance that currently exists.  SEQUENCE is the secondary key to 
determine if for the instance found using a particular UID/RECURRENCE-ID 
pair (primary key) can be safely ignored or not.  By changing the 
RECURRENCE-ID part of the primary key you can never consistantly find the 
same instance!  Never!

This also means that rescheduling a particular instance alone is not 
doable since you seem to think that sending the entire set is the answer 
and it is not.  By reving RECURRENCE-ID and SEQUENCE for a particular 
instance as you reschedule it you cannot recover from a missed REQUEST! 
Nothing said so far has shown otherwise.

Also, the "just do a REFRESH" is predicated on some unknown trigger action 
on the users part.  iTIP only mandates/defines the use of REFRESH for the 
case of ADD not being supported.  iTIP also clearly says that for a given 
UID[/RECURRENCE-ID] the SEQUENCE value is used to determine if a message 
is obsolete or not since the message is supposed to be totally self 
contained.  This is iTIPO section 2.1.5, not some unknown or wishful 
thinking. 

It also does not factor in the behaviour described about distinguishing a 
reschedule from a new request.  Since iTIP also clearly says in Section 
3.2.2 REQUEST:

and the restriction table says:

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

So, if a user gets 2 REQUESTS with the same UID but different 
RECURRENCE-IDs then they treat them as 2 separate invitations to 2 
separate instances.  If the Organzer wants to reschedule a particular 
instance they would use the same RECURRENCE-ID (not disputed by anyone) 
with a higher SEQUENCE value (per Section 2.1.5). 

However its NOT possible to miss 1 REQUEST for a particular RECURRENCE-ID 
and properly match find the correct instance if the RECURRENCE-ID changes 
per Dougs suggestion.  This means that message sequencing MUST be done by 
SEQUENCE then UID/RECURRENCE-ID in order to even try and do the request vs 
reschedule distinction.  This though is contrary to Sections 2.1.5 and the 
text above.

If RECURRENCE-ID never changes then there is no danger of misidentifying 
an instance because the behaviour from Sections 2.1.5 and 3.2.2 works 
perfectly.  The proper instance is found and it does not matter if 1 (or 
100) reschedule were missed.  It doesn't because the newer SEQUENCE 
"obsoletes all other revisions of the component with lower values" and 
because the UID/RECURRENCE-ID is found and matched (per Section 3.2.2 
above) the CUA can properly tell to ignore the old REQUEST.  NO need for 
any REFRESH.  No need to try and resync; the newest SEQUENCE _does_ that 
by the virtue that its the most recent copy.

Per the text from iTIP 3.2.2 REQUEST above each reschedule with a new 
RECURRENCE-ID and SEQUENCE (BUT for the same instance as Doug suggests) 
would be treated as a NEW invitation and NOT a reschedule.  As such the 
CUA will now think there are 2 instances Im invited to when infact I just 
missed just 1 REQUEST that rescheduled the instance.  Since I shouldn't 
ever have to do a REFRESH when I get a new REQUEST, I would never think 
that Im invited to just 1 instance rather than to 2 (or more).  Each 
missed reschedule would result in more 'orphans' being added to my 
calendar and unless I though that a REFRESH was in order (cause still TBD 
as to why I think that) Id never be able to recover properly even if I got 
a full REQUEST again (as was suggested). 

All of Dougs & Georges logic is based on 1 paragraph in 2445 and it 
ignores the conflicting paragraph before it PLUS all of the conflicts it 
has with 2446.   If Doug wants to build something to this model then I 
wont stop him.  Ive already tried to correct the problem but since I dont 
work with or for Doug thats the best I can do.  I hope others take the 
analytical approach to this (and read my previous msg on this) before 
jumping off the cliff too.  Doug's been around since nearly the beginning 
so I dont know why he didnt speak up back in 1999 when we first discussed 
if RECURRENCE-ID changes or not...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 23 Jun 2003 13:59:11 -0600

[email-masked] wrote:
> My example was for someone who is NOT invited to the entire set. 
>  Examples are: guest speakers for monthly team meetings, one-time 
> presenters for regular meetings (ie: design review boards), Proxys / 
> Delegates, etc.  
 > ....

That has NOTHING to do with the problem. If ATTENDEE X asks for a REFRESH,
send him what *he* is expected to see. We discussed this prior to iTIP
being released. All ATTENDEEs do *not* have to have the same copy of
a UID. Just send them what *they* need to see as the ORGANIZER would
need to understand that anyway.

--

---

From: [email-masked]
Date: Mon, 23 Jun 2003 16:05:01 -0400

Chris wrote on 06/23/2003 01:37:58 PM:
> (recurring or otherwise) would be able to keep track of this. 

Not sure what you mean by "expose the ability to do this".  Do you mean 
invite only to a subset?  Lotus Organizer and Lotus Notes do this and have 
done it for years (since R4.5 actually).  Im pretty sure that Microsoft 
Outlook and Microsoft Exchange have that ability too since we tested with 
them.

>                                                               As a 
result,
> would completely conceal from me that I was only invited to a subset).

The concealing bits are orthogonal to the problem that arises from Dougs 
example.  The simple fact is that if I send a REFRESH for a 
UID/RECURRENCE-ID then Id expect a REQUEST for that UID/RECURRENCE-ID.  If 
the Organizer turns around and sends me a REQUEST for the entire set then 
all of a sudden Ive been 'promted' from a single instance (or subset of 
instances) to all instances.  Is this the proper behaviour?  I think not.

> the organizer's CUA, but it works just fine. 

Please show me how if RECURRENCE-ID changes as SEQUENCE changes that you 
can properly identify a missed reschedule REQUEST from a new invitation to 
another instance.

As I noted before, if Im at UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 and 
I send a REFRESH to the Organzier who is at SEQUENCE:10 then what should 
be sent back to me?  If the RECURRENCE-ID changed every SEQUENCE then the 
Organzier _should_ send me a REQUEST for UID:12345, RECURRENCE-ID:YYYY, 
SEQUENCE:10.  This however, per iTIP Section 3.2.2 will look like a new 
invitation to a new instance to me since I do not already know that 
UID/RECURRENCE-ID.  As such I now have 2 instances on my calendar, not 1. 

How can I ever hope to resync my UID:12345, RECURRENCE-ID:XXXX, SEQUENCE:1 
to the UID:12345, RECURRENCE-ID:YYYY, SEQUENCE:10 if a REQUEST the 
Organizer sends in response to the REFRESH will always be the "latest 
description and version of the event."?   It sounds as if Dougs (and 
Chriss) answer is that the Organzier would send a REQUEST for the entire 
set but thats not viable unless you are adding a user to all instances... 
Clearly thats not was the invitee expects nor what the Organizer wants.

>                                              Pegging the RECURRANCE-ID 
to the
> w/o issuing a new UID in that case? 

We have not dealt w/the ADD case, just the simple missed REQUEST case. 
Lets resolve the simple case before trying to digress to others shall we?

>                                                       Forcing a new UID 
to be
> the sequence and issuing a new REQUEST with the new UID in order to 

Huh??  You must be talking about something someone else said.  Ive never 
talked about reassigning UIDs.

> Making RECURRENCE-ID depend on the UID and SEQUENCE is not a delta 
model.

Sorry but if the RECURRENCE-ID changes ever SEQUENCE then in order for you 
to properly tell what the RECURRENCE-ID for SEQUENCE:1003 is, you MUST 
have all prior SEQUENCE values to properly change the RECURRENCE-ID to 
DTSTART @ SEQUENCE:1, DTSTART @ SEQUENCE:2, ..., DTSTART @ SEQUENCE:1002 
before you can try to match the RECURRENCE-ID for SEQUENCE:1003.  How is 
this not a delta model?

Also, if the RECURRENCE-ID changes every SEQUENCE then iTIP Section 2.1.5 
is wrong since it clearly uses UID & RECURRENCE-ID to find the instance 
before it uses SEQUENCE. 

> attendee CUA that finds itself out of synch can recover with one 

Ok, just just what would cause a CU think they are "out of sync"? 

A new REQUEST for a new UID/RECURRENCE-ID?  Why should that matter; its 
just a new invitation (per iTIP Section 3.2.2 REQUEST). 

A REQUEST with a SEQUENCE that is more than 1 off?  Why should that 
matter; its just an update to an existing entry and since by iTIP Section 
2.1.5 the newer/higher SEQUENCE "obsoletes all other revisions of the 
component with lower values."  Thus any missed SEQUENCE is inconsequential 
because that missed SEQUENCE is ALSO obsoleted.

This is not true for the case where RECURRENCE-IDs change per SEQUENCE. 
PLUS rekeying RECURRENCE-IDs every SEQUENCE is contrary to the entire 
design philosphy of iTIP Section 2.1.5 since it makes RECURRECE-ID 
dependent on SEQUENCE and not the other way around.

> evolves, and what I think of when I hear the term 'delta model'.

Why? 

The Organzier can gave the attendees the RECURRENCE-IDs in _any_ REQUEST, 
not just SEQUENCE:0.  As such by simply applying the sequencing rules 
under Section 2.1.5 and the logic described in 3.2.2 its never an issue 
since the RECURRENCE-ID never changes.  No matter where the instance goes 
in time and the number of reschedules it gets or the number of missed 
reschedules on any invitees part its trivial to simply look at the 
REQUEST, grab the UID/RECURRENCE-ID from it, find the instance if it 
already exists and then compare the SEQUENCE the attendee has with the one 
on the REQUEST.  From there its easy to if the

The term delta model was applied because the RECURRENCE-ID changes 
SEQUENCE thus in order to match the RECURRENCE-ID at SEQUENCE:10 you MUST 
be able to follow the changes with each SEQUENCE value before 10 by 
adopting the DTSTART at each SEQUENCE.  This was much like the original 
early drafts we had in iCalendar / iTIP until we found we had resync 
issues for missed cases.

>                                                                    It is 
easy
> instances with no valid (according to this model) RECURRENCE-ID.

No matter where you move the instance to, if the RECURRENCE-ID never 
changes then its trival to unambiguously find it at any point in the 
workflow process (at any SEQUENCE value).  Ths same cannot be said for 
when RECURRENCE-ID changes per SEQUENCE since by iTIP only the latest 
version would ever be sent.  Thus no amount of REFRESH/REQUEST thrashing 
will result in properly resyncing an instance or subset of instances since 
you cannot accurately indentify the instances in question.

>         It wouldn't surprise me if many other people held this view, but 
arent'
> saying anything because of the tenor of many of Bruce's messages.

You should be happy that Franks no longer active here.  Im tame compared 
to him...

My agressive tenor is due to several factors including that this was 
something the WG already covered ~4 years ago and we long ago agreed that 
'delta was bad' because of insurmountable problems like resycing instances 
or subsets of repeat sets.  Hey, are you suggesting I try decaf??!

Bruce

---

From: [email-masked]
Date: Mon, 23 Jun 2003 16:22:16 -0400

Since you are not sending the entire Rule since that person was only 
invited to a single instance, you must reference it with the recurrence-id
.  That recurrence-id must the fixed recurrence-id of when rule was 
created or this invitee will have no way to map it to what is currently on 
his/her calendar.
_____________________
Note: new email address

06/23/2003 03:59 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 23 Jun 2003 14:51:38 -0600

[email-masked] wrote:
> UID/RECURRENCE-ID then Id expect a REQUEST for that UID/RECURRENCE-ID. 
>  If the Organizer turns around and sends me a REQUEST for the entire set 
> then all of a sudden Ive been 'promted' from a single instance (or 
> subset of instances) to all instances.  Is this the proper behaviour?  I 
> think not.

At what point did I or anyone say that if you ask for just one
recurrence-id that the organizer would send you everything?
I can find NO instance of that statement for which you are replying.

If you ask for RECURRENCE-ID:x and what you get back is a
valid object with a SEQUENCE:<larger-than-you-have>, then you will
AT ALL TIMES NO MATTER IF YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE,
you MUST do a REFRESH for the ENTIRE object (REFRESH with out RECURRENCE-ID). 
Else you would not have a CLUE what the object is supposed to look like.

If the SEQUENCE number is the same as you have, then RECURRENCE-ID
MUST MATCH as each time a recurrence rule changes, you
MUST update the SEQUENCE number, so if they are the same then
one thing you know is that NONE of the recurrence rules changed
and the RECURRENCE-ID is valid. If the SEQUENCE number is LARGER
than you have, one of the reasons MAY be because someone changed
a recurrence rule and per iCAL/iTIP the sequence number gets bumped.

> can properly identify a missed reschedule REQUEST from a new invitation 
> to another instance.

Its NOT relevant, if WHATEVER you get back has a larger SEQUENCE number
than you have, you are going to have to do a FULL REFRESH anyway. Then
the ORGANIZER will send you *your* latest object.

And if the SEQUENCE number IS the same, then by definition in iCAL/iTIP,
the recurrence rules MUST NOT have changed.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 23 Jun 2003 14:58:16 -0600

[email-masked] wrote:
> invited to a single instance, you must reference it with the 
> recurrence-id.  That recurrence-id must the fixed recurrence-id of when 
> rule was created or this invitee will have no way to map it to what is 
> currently on his/her calendar.

No, per iCAL/iTIP the SEQUENCE number in what the ATTENDEE gets
must match, if what you get is a SEQUENCE number larger than what
you have then you MUST do a REFRESH as one of the reasons the
ORGANIZER MUST bump the SEQUENCE number is a change in any
recurrence rule.

If the SEQUENCE number is the same then by definition, none
of the recurrence rules could have changed.

It has nothing what so ever to do with how many people
are invited to which instances. There is NO requirement that
the ORGANIZER send the same object to each ATTENDEE, so it has
NO impact on RECURRENCE-ID other than if the SEQUENCE number
is larger or not.

 > That recurrence-id must the fixed recurrence-id of when
 > rule was created or this invitee will have no way to map it to what is
 > currently on his/her calendar.

iCAL specificly says that if a recurrence rule changes you MUST
bump the SEQUENCE number, so that is simply not true.

    ... The "RECURRENCE-ID" property is used in conjunction with the "UID"

It does NOT say that it is fixed at the SEQUENCE zero value.

--

---

From: [email-masked]
Date: Mon, 23 Jun 2003 17:45:47 -0400

> I can find NO instance of that statement for which you are replying.

That exact word for word statement was not made by anyone.  You have been 
saying (and you did not disagree w/Arnaud) that in response to a REFRESH a 
REQUEST with just UID would be sent.

Ive been asking you to please show me how a REQUEST in response to my 
REFRESH for UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 would work if the 
instance is now at SEQUENCE:10 in the Organziers calendar.  Since the 
RECURRENCE-ID changes with ever SEQUENCE change (you've said that 
continuously this entire thread) then exactly what will be in the new 
REQUEST that gets sent? 

However Id like to be clear on this before I go further: Do you think that 
the REQUEST that gets sent in response to the REFRESH (UID:12345, 
RECURRENCE-ID:XXXXX, SEQUENCE:5) should have a RECURRENCE-ID value in it 
or not?

> you MUST do a REFRESH for the ENTIRE object (REFRESH with out 
RECURRENCE-ID). 

Says who?!?  There is NOTHING in any of the RFCs to indicate this!  iTIP 
is quite clear on how to distinguish a new invite from a reschedule:

For repeating instances you need to treat "UID" above as 
"UID/RECURRENCE-ID" just as described in Section 2.1.5 of iTIP.  As such 
the above clearly says that if the UID/RECURRENCE-ID does not exist in my 
calendar then the REQUEST is a new invitation.  Otherwise its an update. 
There is didly about "If the SEQUENCE value is not 'off by one' then all 
bets are off and the Attendee MUST issue a REFRESH to get back in sync." 
(NOT EVEN REMOTELY paraphrased!). 

As bullet 2 of Section 2.1.5 plainly says:

   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.

Since SEQUENCE:1000 obsoletes ALL SEQUENCE values below it what gives you 
the impression that if "you get back is a valid object with a 
SEQUENCE:<larger-than-you-have>, then you will AT ALL TIMES NO MATTER IF 
YOU TIE RECURRENCE-ID to ZERO or THE SEQUENCE, you MUST do a REFRESH for 
the ENTIRE object"??

> Else you would not have a CLUE what the object is supposed to look like.

Sure you do.  The SEQUENCE:1000 REQUEST is fully intact and obsoletes ALL 
prior SEQUENCE REQUESTSs so I can use it as it appears in the stream.  Why 
coudln't I??  Is the object faulty?  Is it incomplete?  Is it inaccurate? 
No.  The bullet clearly says "obsoletes all other revisions of the 
component with lower values."  As such I dont see why you think 
otherwise...

> If the SEQUENCE number is the same as you have, then RECURRENCE-ID

STOP!  You are not reading Section 2.1.5 correctly!  SEQUENCE is NOT a 
precursor to RECURRENCE-ID.  Secondary keys do not have precedence over 
primary keys! 

> than you have, you are going to have to do a FULL REFRESH anyway. 

What do you mean by "FULL REFRESH"??  Isn't that a REQUEST with just the 
UID and NO RECURRENCE-ID in it?  Nah, cant be since you just said you've 
never said that.  So please tell me what iTIP properties are in a "FULL 
REFRESH" when I send a REFRESH on UID:12345, RECURRENCE-ID:XXXXX, 
SEQUENCE:5?  Will it have a RECURRENCE-ID in it or not?

> Then

Again, if Im invited to single instance of the set or a subset of the 
entire set then WHAT EXACTLY is in that new REQUEST that gets sent??  If 
it has a RECURRENCE-ID in it then how do I match it to my existing 
RECURRENCE-ID:XXXXX, SEQUENCE:5 if the actual instance is now at 
SEQUENCE:10 since by your logic the RECURRENCE-ID would be different?? 
How???

The only way to get rid of that UID:12345, RECURRENCE-ID:XXXXX, SEQUENCE:5 
REQUEST is to provide some means to remove it and Ive seen nothing so far 
in any of your responses describing exactly how.  The Organizer is going 
to send a new REQUEST so far Ive seen NO exact example of what gets sent. 

It sounds to me as if Doug and others think that SEQUENCE is across all 
instances of the repeat set.  Please say its not true... 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 23 Jun 2003 16:52:51 -0600

[email-masked] wrote:
> That exact word for word statement was not made by anyone.  You have 
> been saying (and you did not disagree w/Arnaud) that in response to a 
> REFRESH a REQUEST with just UID would be sent.

> continuously this entire thread) then exactly what will be in the new 

I have answerd that three times. Unless there is some new technical
point. I consder this a user error and this point closed as it works
as documented.

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 24 Jun 2003 15:15:32 -0600

> is quite clear on how to distinguish a new invite from a reschedule:

Perhaps your version of iTIP is missing the sections below:
 From iTIP:

4.7.2 Bad RECURRENCE-ID

    Component instances are identified by the combination of "UID",
    "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
    to an "Attendee", there are three cases in which an instance cannot
    be found.  They are:

    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.

    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.

    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.

    In case (3), the limitations of the "Attendee's" CUA makes it
    impossible to match an instance other than the single instance
   scheduled. In this case, the "Attendee" need not send a "REFRESH" to
    the "Organizer".

    The example below shows a sequence in which an "Attendee" sends a
    "REFRESH" to the "Organizer".

    ...

--