Subject: Re: Correct handling of Recurrence-id

From: [email-masked]
Date: Tue, 27 May 2003 16:22:30 -0400

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: Tue, 27 May 2003 15:31:21 -0600

Bruce - I can not find in my mail box or the IMC archives the e-mail
that you are responding to.

I can not find ANY email from "Arnaud Quillaud". Could you please
post a  link to the IMC site for this?

Thanks!

[email-masked] wrote:
> 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
> "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.
> 
> 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.
> 
> Bruce Kahn                                INet: [email-masked]

-- 

  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: Doug Royer <[email-masked]>
Date: Tue, 27 May 2003 15:41:15 -0600

>  > DTSTART: tuesday the 9th at 10am

What would be the point of the above object?
As it is a REQUEST, why not just create an object SEQUENCE:<next>
that is what you want? What is the point of this?

Would it not be better to:

    BEGIN:VCALENDAR
    METHOD:REQUEST
    ...
    BEGIN:VEVENT
    UID:that
    SEQUENCE:1

--

---

From: [email-masked]
Date: Wed, 28 May 2003 10:58:10 -0400

> post a  link to the IMC site for this?

The person is Arnaud Quillaud <[email-masked]> and he has 
been posting some comments to the me and CCing the list (or visa versa). I 
just assumed they were also getting to the list.  In checking the IMC 
archives I see this is not the case.

Im guessing that Arnaud is NOT a WG member so postings to the list do not 
get thru the IMC list manager.  Ive sent him a note asking about this.  In 
the mean time, here is the posting he sent that I was replying to (Im 
editing out the text/html body part for brevity though):

Received: from e6.ny.us.ibm.com ([9.14.6.106])
          by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
          with ESMTP id 2003052320153916-21133 
          for <[email-masked]> ;
          Fri, 23 May 2003 20:15:39 -0400 
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com 
[205.159.212.202])
                 by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id 
h4O0Fb82170396
                 for <[email-masked]>; Fri, 23 May 2003 
20:15:38 -0400
Received: from brmea-mail-3.sun.com ([192.18.98.34])
          by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
          with ESMTP id 2003052320142983-24223 
          for <[email-masked]> ;
          Fri, 23 May 2003 20:14:29 -0400 
Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45])
                 by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id 
h4O0F5ep011439;
                 Fri, 23 May 2003 18:15:06 -0600 (MDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM 
[129.146.18.131])
                 by engmail1mpk.Eng.Sun.COM 
(8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4O0F5Kw022242;
                 Fri, 23 May 2003 17:15:05 -0700 (PDT)
Date: Fri, 23 May 2003 17:15:12 -0700
From: Arnaud Quillaud <[email-masked]>
Subject: Re: Correct handling of Recurrence-id
To: [email-masked]
Cc: [email-masked]
 
<[email-masked]>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 08:14:30 PM,
                 Serialize by Router on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 08:14:31 PM,
                 Serialize complete at 05/23/2003 08:14:31 PM,
                 Itemize by SMTP Server on Ace/Iris(Build 
V602_05122003NP|May 12, 2003) at
 05/23/2003 08:15:39 PM,
                 Serialize by Notes Client on Bruce 
Kahn/Westford/IBM(Build V70_04022003NP|April
 02, 2003) at 05/28/2003 10:53:40 AM,
                 Serialize complete at 05/28/2003 10:53:40 AM
Content-type: multipart/alternative;
 boundary="Boundary_(ID_83e9+ab581aIPJMEfd9TIw)"

--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

[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]
>   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

Bruce changes the second instance to tuesday, so he sends a new iTIP 
REQUEST to bob:

BEGIN:VEVENT
UID:that
SEQUENCE:1

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 ?

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

--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]
--Boundary_(ID_83e9+ab581aIPJMEfd9TIw)--

Bruce

---

From: [email-masked]
Date: Wed, 28 May 2003 11:02:32 -0400

> post a  link to the IMC site for this?

And here is the 2nd posting he sent in reply to my reply to his first 
posting (the 2nd one I sent but #1 in the ordering), again sans HTML:

Received: from e31.co.us.ibm.com ([9.14.4.129])
          by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
          with ESMTP id 2003052319595385-21118 
          for <[email-masked]> ;
          Fri, 23 May 2003 19:59:53 -0400 
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com 
[205.159.212.202])
                 by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id 
h4NNxru9253464
                 for <[email-masked]>; Fri, 23 May 2003 
19:59:53 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43])
          by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
          with ESMTP id 2003052319584589-24208 
          for <[email-masked]> ;
          Fri, 23 May 2003 19:58:45 -0400 
Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19])
                 by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id 
h4NNxMYU017219;
                 Fri, 23 May 2003 17:59:22 -0600 (MDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM 
[129.146.18.131])
                 by engmail2sun.Eng.Sun.COM 
(8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NNxLuc027717;
                 Fri, 23 May 2003 16:59:21 -0700 (PDT)
Date: Fri, 23 May 2003 16:59:28 -0700
From: Arnaud Quillaud <[email-masked]>
Subject: Re: Correct handling of Recurrence-id
To: [email-masked]
Cc: [email-masked]
 
<[email-masked]>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 07:58:46 PM,
                 Serialize by Router on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 07:58:46 PM,
                 Serialize complete at 05/23/2003 07:58:46 PM,
                 Itemize by SMTP Server on Ace/Iris(Build 
V602_05122003NP|May 12, 2003) at
 05/23/2003 07:59:54 PM,
                 Serialize by Notes Client on Bruce 
Kahn/Westford/IBM(Build V70_04022003NP|April
 02, 2003) at 05/28/2003 10:59:13 AM,
                 Serialize complete at 05/28/2003 10:59:13 AM
Content-type: multipart/alternative;
 boundary="Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)"

--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

[email-masked] wrote:

>
> Arnaud Quillaud wrote on 05/23/2003 02:49:21 PM:
> > But what is the advantage of the opposite interpretation of the spec
> > (changing RECURRENCE-ID over time) ? Or what are the disadvantages
> > of fixed RECURRENCE-ID ?
>
> I thought I covered them already earlier today but Ill try to 
> resummarize the probelms with the 'delta' model: 

...
Sorry, I was probably not clear enough. My question was not aimed at you.
Let me try to rephrase it:
First, I think we all agree that the current RFCs are not crystal clear 
in that area, otherwise, we wouldn't have this interesting discussion.
Then, I don't really like to use names, as this discussion is not just 
about 2 people arguing, but to be more clear, let's say we have the 
Bruce model on one hand and the Doug model on the other hand.
You (Bruce) have been quite clear about why you think your model makes 
everybody's life easier, is the only one that truely works, etc...
I would like to to hear now, from Doug or from others, why they think 
their model is simpler/better. There is probably some good reasons why 
they think we should go that way. It would help the debate if they could 
expose those reasons, just like you've exposed yours.

Arnaud

--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]

--Boundary_(ID_AaJntEE6BeSgWe5jsMypqw)--

Bruce

---

From: [email-masked]
Date: Wed, 28 May 2003 11:00:02 -0400

> post a  link to the IMC site for this?

Here is the initial posting he sent last Friday too (again sans the HTML 
body part):

Received: from e31.co.us.ibm.com ([9.14.4.129])
          by ace.notesdev.ibm.com (Lotus Domino Build V602_05122003NP)
          with ESMTP id 2003052314494871-20712 
          for <[email-masked]> ;
          Fri, 23 May 2003 14:49:48 -0400 
Received: from capricorn.iris.com (capricorn.notesdev.ibm.com 
[205.159.212.202])
                 by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id 
h4NInou9253416
                 for <[email-masked]>; Fri, 23 May 2003 
14:49:50 -0400
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
          by capricorn.iris.com (Lotus Domino Build V602_03262003NP)
          with ESMTP id 2003052314484437-23842 
          for <[email-masked]> ;
          Fri, 23 May 2003 14:48:44 -0400 
Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45])
                 by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id 
h4NInELv008141;
                 Fri, 23 May 2003 11:49:14 -0700 (PDT)
Received: from phys-mpkmaila (phys-mpkmaila.SFBay.Sun.COM 
[129.146.18.131])
                 by engmail1mpk.Eng.Sun.COM 
(8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NInEL0019362;
                 Fri, 23 May 2003 11:49:14 -0700 (PDT)
Date: Fri, 23 May 2003 11:49:21 -0700
From: Arnaud Quillaud <[email-masked]>
Subject: Re: Correct handling of Recurrence-id
To: [email-masked]
Cc: [email-masked]
 
<[email-masked]>
X-MIMETrack: Itemize by SMTP Server on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 02:48:44 PM,
                 Serialize by Router on Capricorn/Iris(Build 
V602_03262003NP|March 26, 2003) at
 05/23/2003 02:48:45 PM,
                 Serialize complete at 05/23/2003 02:48:45 PM,
                 Itemize by SMTP Server on Ace/Iris(Build 
V602_05122003NP|May 12, 2003) at
 05/23/2003 02:49:48 PM,
                 Serialize by Notes Client on Bruce 
Kahn/Westford/IBM(Build V70_04022003NP|April
 02, 2003) at 05/28/2003 10:56:52 AM,
                 Serialize complete at 05/28/2003 10:56:52 AM
Content-type: multipart/alternative;
 boundary="Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)"

--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed

Hello,

The proponents of the fixed RECURRENCE-ID have explained in quite some 
details already why this seems like the right approach.
But what is the advantage of the opposite interpretation of the spec 
(changing RECURRENCE-ID over time) ? Or what are the disadvantages of 
fixed RECURRENCE-ID ? I think we now all understand the proposed model. 
It would be great to now see _why _it might be the best approach.

We have two  interpretation of the RECURRENCE-ID:

version 1: The RECURRENCE-ID is equal to the DTSTART of the instance as 
defined in the initial recurring component (that is, it is included in 
the recurrence set (RRULE + RDATE - EXRULE -EXDATE) in the SEQUENCE 0 
recurring component). Or as Bruce puts it: "The RECURRENCE-ID is fixed 
and unchanging from the initial assigment of it and is used to uniquely 
identify the repeating entry no matter where it has been rescheduled to."

version 2: The RECURRENCE-ID is equal to the DTSTART of the instance at 
a given time. When sending an iTIP REQUEST that  corresponds to a change 
of DTSTART for a particular instance, the RECURRENCE-ID is equal to the 
previous value of the DTSTART. In any subsequent REQUEST, the 
RECURRENCE-ID is equal to the new DTSTART (that is, until the DTSTART is 
changed again). Hence, the RECURRENCE-ID identifying an instance might 
change over time.

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.
Here is an example:

initial REQUEST:

BEGIN:VEVENT
SEQUENCE:0

changing the second instance to tuesday

BEGIN:VEVENT
SEQUENCE:1

Now, john joins the party. The organizer will send him a request 
containing the "master" event + the exception.
What recurrence set (RRULE + RDATE + EXDATE + EXRULE) should the 
organizer send him ? Is it:

or should he send the initial recurrence set which was just:

?
If it is the former, then, with option 1, we will have a RECURRENCE-ID 
that doesn't correspond to the recurrence set.
If it is the later, then the recurrence set doesn't reflect the full 
list of instances.

That said, this might just be a problem of definition of what the 
RECURRENCE-ID is. We might say that, as the recurrence set evolves, a 
particular RECURRENCE-ID might end up being part of the EXDATE.

Anyway, this doesn't seem like a major problem.

Arnaud

--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)
Content-transfer-encoding: 7BIT
Content-type: text/html; charset=us-ascii

[Snip, snip]

--Boundary_(ID_Je36pJ2Dp28r/Mbz+wcR8g)--

Bruce

---

From: [email-masked]
Date: Wed, 28 May 2003 11:13:35 -0400

> that is what you want? What is the point of this?

The point is that the REQUEST contains a full snapshot of the repeating 
entry set from my calendar in such a way that the invitee (Arnaud) can 
properly create it in his calendar and use the same 
UID/RECURRENCE-ID/SEQUENCE key values that I would so we can easily do 
workflow.   Since we share the same keys we can match up instances 
correctly and not worry about phantom or incorrect bookings, etc.

Using a higher SEQUENCE is not what I want.  See below for why not.

>     RDATE: tuesday the 9th at 10am

Not unless you want to entirely invalidate all other REPLYs to all other 
instances that are NOT being rescheduled.  PLUS you would have to now 
renegotiate SEQUENCE:1 responses from all other invitees (ok, only Bob in 
this case but so what). 
Only the 2nd instance changed so only it needs to be rev'd to SEQUENCE:1. 
The rest are still unchanged and as such should not be rev'd.

Now, _could_ I rev to SEQUENCE:1 for all instances?  Sure.  But then why 
would I want to since it means I now have to repeat the entire process of 
negotation/workflow w/all the other invitees.  Their REPLYs at SEQUENCE:0 
would be 'old' and thus invalid.  If you repeat this "just rev it and 
forget it" approach for multiple instances it makes workflow tedious at 
best and a deterance to using it at worst.  Not a good idea if you want 
folks to actually use this is it?  After all the 4th Monday has not 
changed yet Ive had to reREQUEST everyone 14 times because the 2nd and 3rd 
instances got rescheduled 5 times each (not including the rescheduling 
that they cause each other to have to do).  Yuck!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 May 2003 15:47:33 -0600

> invite a totally new attendee to the whole serie, not just a particular

That can be done without any RECURRENCE-ID updates. Simply send a REQUEST
to the new ATTENDEE. There is NO requirement all all ATTENDEEs be notified
so you do not incremnet the SEQUENCE number. You just send a copy of
the existing object with the new ATTENDEEs added, to the new ATTENEES only.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 May 2003 15:59:27 -0600

> What will this request look like in your model ?

Simply send the new REQUEST object that represents the current
ORGANIZER view of the object with the new ATTENDEE added to
the new ATTENDEEs only.

It can be done with EXDATE/EXRULE or additional RRULE or RDATE
properties. The METHOD:ADD can be used in a separate VCALENDAR
object when details about the meetings (or whatever) can not
be described in one object.

Also, there is no requrement that all ATTENDEEs see the exact same object. 
That is you could send each ATTENDEE an object that only contains them
in the ATTENDEE list. You could also send them an object that only
contains the instances that they will be attendending or are invited
to attend. It can be done with RRULE, RDATE, EXRULE and EXDATE. Only
the ORGANIZER CUA would need to know when different objects are sent
to various ATTENDEEs.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 May 2003 16:08:04 -0600

> expose those reasons, just like you've exposed yours.

At any point in time when a CUA gets an existing UID with a SEQUENCE
number '1' more than it has, then it just processes the object.

At any point in time when a CUA gets an existing UID with a SEQUENCE
number '2' or more than it has, then it MUST do a REFRESH as there
is no way what so ever to known what a specific RECURRENCE-ID
means if you do not have the current SEQUENCE. For all the ATTENDEE/CUA
knows all of the original instances were canceled in the missing SEQUENCE
object. You MUST do a REFRESH 100% of the time when your SEQUENCE number
is more than '1' out of sync.

No tracking of history required at all by the ATTENDEE.
The ORGANIZERs CUA must keep track of who send REPLY objects
for each SEQUENCE in both models.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 28 May 2003 17:02:43 -0600

[email-masked] wrote:
> renegotiate SEQUENCE:1 responses from all other invitees (ok, only Bob 
> in this case but so what).  
> Only the 2nd instance changed so only it needs to be rev'd to 
> SEQUENCE:1.  The rest are still unchanged and as such should not be rev'd.
 >
> would I want to since it means I now have to repeat the entire process 
> of negotation/workflow w/all the other invitees.

Forcing all CUA to remember SEQUENCE:0 and all updated objects (new
SEQUENCES) is less desirable and not the current RFC model.

If you only alter/add/cancel 1 instance, then you are required to increment
the SEQUENCE number. (iCAL 4.8.7.4 Sequence Number). It is NOT
optional!

The fact that it forces all ATTENDEEs to do another REPLY
was discussed on this list and was accepted.

So unless you are talking about some hypothetical next revision
and not yet proposed iCal - that is just not the way the spec
reads.

> Their REPLYs at 
> SEQUENCE:0 would be 'old' and thus invalid.  If you repeat this "just 
> rev it and forget it" approach for multiple instances it makes workflow 
> tedious at best and a deterance to using it at worst.

Yes - A SEQUENCE:1 RECURRENCE-ID:x when is all you have is SEQUENCE:0
is invalid. Do a REFRESH and get SEQUENCE:1

 >   Not a good idea
> if you want folks to actually use this is it?  After all the 4th Monday 
> has not changed yet Ive had to reREQUEST everyone 14 times because the 
> 2nd and 3rd instances got rescheduled 5 times each (not including the 
> rescheduling that they cause each other to have to do).  Yuck!

We did discuss this problem on the list (pre-2445) and the consensus was
you can create a smart CUA that notices what the differences and
automate much of the work. But - yes. You must increment the SEQUENCE
number and then the ATTENDEEs must then REPLY to the new REQUEST/SEQUENCE
(automated or not).

If ONE instance changes then the existing ATTTENDEEs MUST REPLY
to that change. If not, how would they know to COUNTER if
they wished. I could imagine an optimized CUA that could only
send what effected each ATTENDEE to limit the amount of REQUESTs
and REPLYs, however the spec says if the instances change,
the SEQUENCE must be updated.

--

---

From: [email-masked]
Date: Thu, 29 May 2003 18:11:19 -0400

> be described in one object.

Sorry to rain on your parade again but an ADD is NOT called for when 
inviting a new ATTENDEE.  The ADD method is defined as:

                 The "ADD" method allows the "Organizer" to add new
   instances to an existing event using a single ITIP message without
   redefining the entire recurring pattern.

In the case of adding a totally new ATTENDEE, they do not have the 
"existing event" so ADD would be the WRONG method to use.  In fact iTIP 
clearly rules that out:

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT". 

(I think the 'must' in line 1 should have been 'MUST' but thats just 
me...)

> Also, there is no requrement that all ATTENDEEs see the exact same 
object. 

They do however need to see the same instance information such as DTSTART, 
DTEND, RDATE, RRULE, etc.  Otherwise they are all using different 
repeating set definitions and thats BAD!  They do not need to share the 
same ATTENDEE, COMMENT, etc properties though.

> in the ATTENDEE list. 

Yep.  (Who says Doug and I never agree??...)

>                       You could also send them an object that only
> to attend. 

Absolutely.  There is NEVER a case in iTIP when we defined a case where 
REQUEST is used to inform an ATTENDEE about an event they are NOT invited 
to (party crashing aside). 

But Arnaud was asking about what iTIP object(s) would be sent to him to 
invite him to the entire set... 

>             It can be done with RRULE, RDATE, EXRULE and EXDATE. Only

The Organzier CUA doesn't have to know anything about what was sent; just 
what to generate.  It does not need to track the different iTIP objects 
that get sent out as they are supposed to be representative of the current 
view of the instance(s) involved.  Once sent, the CUA has no need to keep 
track of the actual messages contents as it can easily rebuild it and 
resend it as necessary...

If a CUA keeps copies of all iTIP messages sent to all ATTENDEEs in a 
repeating event then Id be more than a bit concerned about the bloating 
that would occur as rescheduling happens.

I have yet to see any answers to my previous questions about what exact 
iTIP properties get sent to do resyncing in the model Doug advocates.  Did 
I miss them?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 May 2003 16:52:55 -0600

>   redefining the entire recurring pattern.

True and the original example also did that:

   "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 ? "

Yes - you can send them a REQUEST + ADD.

--

---

From: [email-masked]
Date: Thu, 29 May 2003 18:52:33 -0400

> number '1' more than it has, then it just processes the object.

This must be your interpretation of iTIP.  However I see NOTHING in iTIP 
that expressly says "1 more than it has" (even paraphrased)...

> means if you do not have the current SEQUENCE.

Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID.  At 
least thats how I take" to know what a sepcific RECURRENCE-ID means if you 
dont have the current SEQUENCE" because you are predicating the 
RECURRENCE-ID on a particular SEQUENCE value.

Unfortunately this is contrary to iTIP which says:

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

That is, for any given UID/RECURRENCE-ID key the CUA then uses SEQUENCE to 
determine if the message is old or not. 

This does not say use UID to find an set of instances, then the SEQUENCE 
to see if I can use the RECURRENCE-ID and then RECURRENCE-ID to find the 
exact instance.  This UID -> SEQUENCE -> RECURRENCE-ID behaviour also 
assumes that ALL instances share the same SEQUENCE value.  That really 
sucks!!  That means if I reschedule just 1 instance (thus reving SEQUENCE 
one higher) I MUST ignore all REPLYs (& COUNTERs) I get for _all other 
instances_ because the SEQUENCE value changed even though the instances in 
question did NOT change!  Ugh!!!  Talk about workflow 
thrashing/nightmares!

>                                                    For all the 
ATTENDEE/CUA
> is more than '1' out of sync.

ONLY IF YOU SUBSCRIBE TO THE "DELTA" MODEL!   Yet even doing a REFRESH 
100% of the time does NOT SOLVE the problem.  Here's why:

1: I invite Doug, George, Tom and Ki to SEQUENCE:0 to 3 Mondays in a row.
2: I then reschedule to 3 Wednesdays in a row and send a SEQUENCE:1 
REQUEST to them.
3: I reschedule again to 3 Thursdays in a row and send a SEQUENCE:2 
REQUEST to them.
4: I reschedule again to 3 Fridays in a row and send a SEQUENCE:3 REQUEST 
to them.

There are at least 2 problems with this situation which are unrecoverable:

A: If the REQUEST from Step 4 arrives before the REQUESTs from Steps 2&3 
then Doug is going to have to send a REFRESH to me.  I get it and send a 
new REQUEST at SEQUENCE:3.  However if he gets this before the others 
arrive (or after only 1 other arrives) then what can he do with it? 
Nothing!  He MUST send another REFRESH request.  This will in turn cause 
another unusable (by Doug) REQUEST to be resent and the pattern keeps 
looping.

B: If any single entry in the chain of reschedules NEVER arrives then 
there is NO way to recover it using a REFRESH.  The REFRESH will cause my 
CUA to send a REQUEST that reflects the current view of the entry, NOT one 
that reflects any missing REQUEST.  As such, NO MATTER HOW MANY REFRESHes 
get sent by Doug in response to missing SEQUENCE:2 (or 1), there is NO way 
to send the information Dougs CUA would need to rebuild the missing 
SEQUENCE (and thus missed RECURRENCE-ID) entry.

iTIP clearly says how a REFRESH works:

                               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.

[Emphasis mine]  So if Doug missed SEQUENCE:2 (or 1) then he would send a 
REFRESH using the UID and RECURRENCE-ID from the SEQUENCE:3 REQUEST.  I 
would in turn send back a REQUEST with the exact same 
UID/RECURRENCE-ID/SEQUENCE values (since I didnt reschedule it yet again). 
 So, Doug now has 2 REQUESTs.  However NEITHER are usable because there is 
missing SEQUENCE:2 (or 1) information.

This is precisely why we decided that each iTIP object would be a full 
snapshot of the instance in question and why the key values of UID & 
RECURRENCE-ID MUST NOT change.  There is no known way to recover! 
REFRESHes will NOT do it... 

This is also why we put the text in bullet #2 in 2.1.5 about higher 
SEQUENCE values for the same UID / RECURRENCE-ID pair "obsoletes all other 
revisions of the component with lower values.".  So what if you missed 3 
interim messages?  The SEQUENCE:5 data for a given UID / RECURRENCE-ID is 
more recent than any of the prior SEQUENCE values! 

Since UID never changes for an entry or a repeat set and RECURRENCE-ID 
never changes for an instance in a set you can ALWAYS just discard ANY 
prior SEQUENCE entries and be happy!  ALWAYS!

> No tracking of history required at all by the ATTENDEE.

For a delta model it absolutely is!  Otherwise you yave no chance to 
rewrite the RECURRENCE-IDs as the SEQUENCE value changes so you can 
properly identify the instance in question.

Also, what good is a REFRESH if its the 'latest' and you missed 2 or more 
REQUESTs?? (Your claim at top, not my misquoting of you...)

> for each SEQUENCE in both models.

And what good is that??  You were just saying that a REFRESH object was 
required when > 1 is missing. Reread that bit from REFRESH I highlighted 
above.  Factor in that a REFRESH has NO SEQUENCE property in it and as 
such the Organzier would have no way to even know what SEQUENCE caused the 
Invitee to need a REFRESH!  Now please explain to me what good it does my 
CUA to keep track of that info in this model.

So the Organzier for some unclear reason keeps track of responses at each 
SEQUENCE level but I fail to see what use that is to know that Ki said hed 
come to SEQUENCE:0 and SEQUENCE:2.  Im at SEQUENCE:3 now so whop-de-doo! 
ANY workflow from SEQUENCE values under 3 are stale and should be ignored! 
 Your CUA could keep them around not every one finds bloating that useful. 
 I may want to know that Ki did respond but to an older version but 
responses per old SEQUENCE??  Whatever floats your boat.

Still, that had nothing to do with the workflow recovers in the model you 
espouse.  Can you please show me how a REFRESH magically solves the case 
of a missed (or purposely deleted by the CU) entry in the chain?  Perhaps 
George can chime back in and rephrse what Doug's said so that its clear. 
Or if someone else out there can show how everything gets resync'd 
properly when RECURRENCE-IDs change per SEQUENCE Im all eyes!  Anyone??!!

Bruce

---

From: [email-masked]
Date: Thu, 29 May 2003 19:20:14 -0400

> SEQUENCES) is less desirable and not the current RFC model.

What does NOT reving SEQUENCE on all non-rescheduled entrys have to do 
with forcing CUAs to remember SEQUENCE:0?  The entires have not been 
rescheduled so they are by definition at SEQUENCE:0.

> the SEQUENCE number. (iCAL 4.8.7.4 Sequence Number). It is NOT

I agree.  However you seem to think that SEQUENCE is shared among all 
instances!  It is NOT! 

The reason it isnt is simple: Because if it were then rescheduling any 1 
instance of a repeating set would invalidate the REPLYs (COUNTERs, etc) to 
ALL other instances!

Why should all the REPLYs to Arnauds 1st Monday be invalidated because the 
2nd Monday moved around?!?!?  It should not be.  Each instance has its own 
distinct set of properties.  The only thing that they MUST all share is 
UID.  Beyond that, each instance can have different SUMMARYs, 
DESCRIPTIONs, ATTENDEE lists, (certainly) DTSTART & DTEND, etc.  Workflow 
on a single instance of a repeating set should have NO impact on any other 
instances in that set. 

If I cancel the 6th Monday, should I invalidate all REPLYs to the other 
Mondays?  Since a CANCEL rev's SEQUENCE it certainly sounds like Doug 
thinks it should.

> was discussed on this list and was accepted.

Not sure which discussion you are referring to Doug given the 6+ year 
history of the list...  Which one did we say that SEQUENCE is shared among 
all instances?

> and not yet proposed iCal - that is just not the way the spec

The spec conflicts as it is written now, not in some hypothetical or 
mytical versions.  Recall:

   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.The "RANGE" parameter is used to specify
   the effective range of recurrence instances from the instance
   specified by the "RECURRENCE-ID" property value. The default value
   for the range parameter is the single recurrence instance only. The
   value can also be "THISANDPRIOR" to indicate a range defined by the
   given recurrence instance and all prior instances or the value can be
   "THISANDFUTURE" to indicate a range defined by the given recurrence
   instance and all subsequent instances.

Both paragraphs from 2445.  The former describes a fixed RECURRENCE-ID. 
The latter describes a changing RECURRENCE-ID.  Im claiming that the 
latter is residual from the early delta model we had in iCalendar and is 
wrong.  Ive shown how but I have yet to see any proof to the contrary that 
it is correct and it works.

> is invalid. Do a REFRESH and get SEQUENCE:1

REFRESHes wont solve the problems of a delta model.  For the 'delta' model 
you wont get the missing instance(s) data so you cannot rebuild the chain 
of reschedules.  For the non-delta model you have no need to REFRESH; the 
UID/RECURRENCE-ID match and since by iTIP 2.1.5 rules SEQUENCE:1 obsoletes 
SEQUENCE:0 the receiver can just act on it.

> number and then the ATTENDEEs must then REPLY to the new 
REQUEST/SEQUENCE

This is totally, 100% unnecessary to do if the RECURRENCE-ID stays fixed 
(like the UID does!).  You must be looking at a discussion we had when we 
did have a delta model in the workflow.  However as iTIP Section 2.1.5 
shows thats NOT the case any more: the highest SEQUENCE for any given 
UID/RECURRENCE-ID wins, the rest are obsolete and thus 
ignorable/deletable.

Also, this does not address the issue of a missed SEQUENCE where the 
RECURRENCE-ID gets rewritten.  As Ive noted ad naseum already today, a new 
REQUEST will have the same UID/RECURRENCE-ID/SEQUENCE values on it (and 
just a newer DTSTAMP) and so by iTIP rules on message sequencing it would 
"overrides all others."  There is no mention of filling in some missing 
SEQUENCE so that a new RECURRENCE-ID could be calculated to keep the 
invitees and the Organizer in sync. 

> the SEQUENCE must be updated.

The SEQUENCE for the instance, NOT the entire set!... 

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 May 2003 17:38:37 -0600

> that expressly says "1 more than it has" (even paraphrased)...

True - that text is not in iTIP. Are you suggesting that SEQUENCE never
changes?

> Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID.

You do.

Otherwise there would be NO way to ever determin the intended start
time for an instance you do no have.

> At 
> least thats how I take" to know what a sepcific RECURRENCE-ID means if 
> you dont have the current SEQUENCE" because you are predicating the 

No keep reading.

>       property value.  For components where the "UID" is the same, the
> That is, for any given UID/RECURRENCE-ID key the CUA then uses SEQUENCE 
> to determine if the message is old or not.  

And if it is old, what good is RECURRENCE-ID in a CANCEL for an object
where SEQUENCE:0 -never- contained the start time with that value
you wish to CANCEL?

--