Subject: RE: Correct handling of Recurrence-id

From: kiwong <[email-masked]>
Date: Wed, 21 May 2003 15:03:41 -0700

I just want to make sure we understand the problem of RECURRENCE-ID if we
*DO NOT* use the original dtstart (the dtstart the recurring set is
created at the time by the organizer).

Let’s say I send out an weekly invitation to you, which is 5/1, 5/8, 5/15,
5/22, ...
 
You got your invitation and see the recurring event in your calendar 

Now if I change the 5/8 to 5/9 and send out an update. Then I change it
again from 5/9 to 5/10 and send another update. 

The problem arises in the following cases: 

1)If the 5/8- > 5/9 event got lost in email, but 5/9- >5/10 succeeds, then
you cannot apply the 5/9- >5/10 because 5/9 is not in your recurring set. 

2)If both emails 5/8- >5/9 and 5/9- >5/10 are in your Inbox, and you open
the latest one first, which is 5/9- >5/10, then it will generate an error
as well.  You must open the 5/8- >5/9 before you can open 5/9- >5/10 

If RECURRENCE-ID is the original dtstart, then *out of sequence* iMIPs
will not be a problem. Otherwise, how do CUA/CS resolve this kind of
problems?

ki

> -----Original Message-----
> From: George Babics [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2003 2:20 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Correct handling of Recurrence-id
> 
> 
> 
> According to RFC 2445 an event's current DTSTART is
> its recurrence id. Section 4.8.4.4:
> 
>     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.
> 
> And in RFC 2446, section 3.7.1:
> 
>     An instance of a recurring event is assigned a unique identification,
>     "RECURRENCE-ID" property, when that instance is renegotiated.
>     Negotiation may be necessary when a substantive change to the event
>     or to-do has be made (such as changing the start time, end time, due
>     date or location). The "Organizer" can identify a specific recurrence
>     instance using the "RECURRENCE-ID" property. The property value is
>     equal to the date/time of the instance. If the "Organizer" wishes to
>     change the "DTSTART", the original "DTSTART" value is used for
>     "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
>     reflect the change.  Note that after the change has occurred, the
>     "RECURRENCE-ID" has changed to the new "DTSTART" value.
> 
> George
> 
> [email-masked] wrote:
> >
> > Don't even reference DTSTART.
> > The values for RECURRANCE-ID in any future reschedule/update or counter
> > must be the dates rolled from the chairs Original meeting invitation
> > RRULE/RDATE/EXRULE/EXDATE.
> > _____________________
> > Note: new email address
> >
> > [email-masked]
> >
> >
> > *Doug Royer <[email-masked]>*
> > Sent by: [email-masked]
> >
> > 05/21/2003 02:00 PM
> > Please respond to
> > "[email-masked]" <[email-masked]>
> >
> >
> > To
> > "[email-masked]" <[email-masked]>
> > cc
> > Subject
> > Re: Correct handling of Recurrence-id
> >
> >
> >
> >
> >
> >
> >
> > I think the terms 'the same' and 'original' are the cause of the
> > confusion. Two different question were asked.
> >
> >
> > kiwong wrote:
> >  >
> >  >
> >  > I agree with Bob. I don?t see how recurrence-id will work for ?out
of
> >  > band? iTIP messages if it doesn?t have the original date.
> >
> > The RECURRANCE-ID value is the same as the DTSTART value for that
specific
> > instance in the booked object. It is not always equal to the DTSTART
> > value of the original object:
> >
> >   A 1 hour meeting starts on monday at 1pm for 5 days:
> >
> >     DTSTART: ...monday
> >
> >   To specify a specific instance the RECURRANCE-ID value
> >   may be set to a value of ...tuesday.
> >
> >   So they are NOT the same as the original instance except when
> >   the instance in the iTIP object refers to the 1st booked instance.
> >
> > And the DTSTART and RECURRANCE-ID values are not always the same in a
> > specific iTIP object. It depends on the METHOD value. If you are
> > METHOD:CANCEL-ing an  instance - yes they must be the same in the
> > iTIP object.
> >
> > If you are updating the DTSTART value of an existing (booked) object.
> > And you are altering the DTSTART value of a specific instance of that
> > booked object. And you are NOT updating the 1st instance of that
> > booked object:
> >
> >    Then the RECURRANCE-ID in an update iTIP object would have
> >    different values for the RECURRANCE-ID and its DTSTART value.
> >    The DTSTART value has the NEW instance value.
> >    The RECURRANCE-ID value has the OLD instance value.
> >
> > So it IS always the same as the 'booked' object instance.
> > It is NOT always the same as the DTSTART value in the 'booked' object.
> > It is NOT always the same in a specific iTIP object.
> >
> >  >
> >  > I tested out the Outlook/Exchange and they use the original date as
the
> >  > RECURRENCE-ID.
> >
> > Using what 'METHOD:' value?
> >
> >  > I assume Notes is using it the same way. For iTIP
> >  > interoperability, is it more beneficial to have RECURRENCE-ID as the
> >  > original date?
> >
> > Only when referring to the 1st instance of a booked object or
> > using specifc METHOD values.
> >
> > --
> >
> >  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: Thu, 22 May 2003 08:50:26 -0600

kiwong wrote:
> I just want to make sure we understand the problem of RECURRENCE-ID if 
> we *DO NOT* use the original dtstart (the dtstart the recurring set is 
> Let?s say I send out an weekly invitation to you, which is 5/1, 5/8, 
> 5/15, 5/22, ...

> 1)If the 5/8- > 5/9 event got lost in email, but 5/9- >5/10 succeeds, 
> then you cannot apply the 5/9- >5/10 because 5/9 is not in your 
> recurring set.

Yes.

> 2)If both emails 5/8- >5/9 and 5/9- >5/10 are in your Inbox, and you 
> open the latest one first, which is 5/9- >5/10, then it will generate an 
> error as well.

When you say 'Inbox' I think of an MUA. Although iTIP can be sent through
e-mail, iCalendar objects are not processed by an MUA. The are processed by
a CUA. So your CUA should be smarter.

> You must open the 5/8- >5/9 before you can open 5/9- >5/10

Your CUA must 'process' them in the correct order.

The 5/9 -> 5/10 iTIP object would have a SEQUENCE number in it that
does not match your current copy of the object. So your CUA would know
to do a REFRESH and get a new copy before applying the update.
This is described in RFC-2446.

--

---

From: John Stracke <[email-masked]>
Date: Thu, 22 May 2003 11:38:39 -0400

Doug Royer wrote:

> Although iTIP can be sent through

Except that, in the most common case, your CUA receives your incoming 
iTIP messages only when you open them in your MUA.  I suppose it could 
say, "This message is out of sequence; I'll hold it until I get the 
missing message(s)".

-- 
/=================================================================\
|John Stracke      [email-masked]                          |
|Principal Engineer|http://www.centive.com                        |
|Centive           |My opinions are my own.                       |
|=================================================================|
|McDonald's, which does not wait on your table, does not cook your|
|food to order, and does not clear your table, came up with the   |
|slogan "We Do It All For You." -- Dave Barry                     |
\=================================================================/

---

From: [email-masked]
Date: Fri, 23 May 2003 12:15:57 -0400

> say, "This message is out of sequence; I'll hold it until I get the 

Any by what magic would a MUA/CUA know that there are other pending or 
incoming REQUESTs that it has to wait for? 

There is no onus to send out new REQUESTS but the Organzier really should 
when SEQUENCE changes. 

Then again, if the messages got lost in transit then can the invitee do 
nothing with the REQUEST? 

All of this goes away as an issue if we get rid of the concept of applying 
deltas to the RECURRENCE-ID.  Then again maybe some folks like 
langiushing...

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...