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

From: "Jay Parker" <[email-masked]>
Date: Tue, 24 Jun 2003 19:52:31 -0600

Doug,
 
RFC2446 section 2.1.5 seems to agree with Bruce.
 
"To maximize interoperability and to handle messages that arrive in an
   unexpected order, use the following rules:

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

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

   3.  "Attendees" send "REPLY" messages to the "Organizer".  For
       replies where the "UID" property value is the same, the value
of
       the "SEQUENCE" property indicates the revision of the component
       to which the "Attendee" is replying.  The reply with the
highest
       numeric value for the "SEQUENCE" property obsoletes all other
       replies with lower values.

   4.  In situations where the "UID" and "SEQUENCE" properties match,
       the "DTSTAMP" property is used as the tie-breaker. The
component
       with the latest "DTSTAMP" overrides all others. Similarly, for
       "Attendee" responses where the "UID" property values match and
       the "SEQUENCE" property values match, the response with the
       latest "DTSTAMP" overrides all others.

Rule 1. clearly states that the primary key is composed of *BOTH* the
UID *AND* the RECURRENCE-ID properties.  
 
4.7.2 also implies agreement with this by listing all three properties
UID, RECURRENCE-ID and SEQUENCE in that order.  4.7.2 further refers to
out-of-sequence messages as versioning problems; this also agrees with
Bruce's description.
 
I'm having difficulty understanding your previous statement that "Only
when the SEQUENCE number and UID are known does RECURRENCE-ID have any
meaning".  The RFC indicates that the RECURRENCE-ID is usable with just
the UID (i.e. without the sequence) since I can get the latest SEQUENCE
by doing a refresh of the UID/RECURRENCE-ID.
 
I'm also having difficulty understanding your affirmative response to
the observation that you need SEQUENCE to determine RECURRENCE-ID. 
Could you explain why you believe this to be the case?  This seems to be
in direct contradiction to using RECURRENCE-ID as part of the primary
key and SEQUENCE as the secondary key.
 
Regards,
Jay

>>> [email-masked] 6/24/2003 3:15:32 PM >>>

> 
> 
> [email-masked] wrote:
> 
>  >  > 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).
>  > 
>  > 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:
>  
>  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".
>  
>      ...
>  
>  
>  
>  -- 
>  
>    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, 24 Jun 2003 20:35:26 -0600

No where in the text below does it say that recurrence-id
is tied to sequence:0, other parts of the spec specifically
say that it is NOT.

The text you cited is for processing order of incoming
out of order objects.

Jay Parker wrote:
>    1.  The primary key for referencing a particular iCalendar component
>        recurring component, the primary key is composed of the "UID" and
>        property value.  For components where the "UID" is the same, the
>        lo! wer values."
>        replies where the "UID" property value is the same, the value of
>        to which the "Attendee" is replying.  The reply with the highest
>        the "DTSTAMP" property is used as the tie-breaker. The component
> &nbs! p;      the "SEQUENCE" property values match, the response with the

FOR SORTING incoming objects.

> 4.7.2 also implies agreement with this by listing all three 
> properties UID, RECURRENCE-ID and SEQUENCE in that order.  4.7.2 further 
> refers to out-of-sequence messages as versioning problems; this also 
> agrees with Bruce's description.

The implication does not exist and is exactly opposite to the
specific text in iCAL and iTIP. The text you cite is for determining
the processing and ordering of objects - read the section title.

The rule (3.) that you cite also says that the old objects are 'obsolete'.

Plus if you tie the recurrence-id to sequence zero - you can NEVER change
any recurrence rule. Which also is directly opposed to the text in iTIP
which specifically says that you can do that:

  4.4.2 Modify A Recurring Instance

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

You will also note from the example provided that the object
being modified just happens to be sequence zero, and it
is updating the object (changing the recurrence id) and per
the text itself 'changes an instance' of the even to SEQUENCE:1 .
That entire section assumes that you CAN update a recurrence rule.
If you tie the recurrence-id to sequence:0, then your hosed
and can  NEVER do another update.

> by doing a refresh of the UID/RECURRENCE-ID.

 From iCAL:

  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.

It does not say that you can ignore sequence if not zero.
And it does not say 'just kidding, ignore SEQUENCE and
only use zero'.

> key and SEQUENCE as the secondary key.

Same as above.

For CUA's that fix the recurrence-id to SEQUENCE zero they
MUST do a REFRESH to get the latest object - else they will
NEVER have a clue what the object instances are - unless
the just happen to be the same.

For implementations that want to throw away the UID and start
from scratch when a recurrence rule is updated, that is compliant
to iCAL and iTIP - it just breaks users local alarms. Implementations
that do not throw away the UID when recurrence id changes are
also compliant.  If you want to throw away the UID on recurrence
id changes, then in order to intemperate with implementations
that do not, simply do a REFRESH when you get any partial update
and then pretend that what you get back is sequence zero.

--