Subject: Re: Correct handling of Recurrence-id

From: [email-masked]
Date: Thu, 12 Jun 2003 15:29:26 -0400

Doug replied on 05/29/2003 07:38:37 PM:
> >  > 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.
> > 
> > This must be your interpretation of iTIP.  However I see NOTHING in 
iTIP 
> > that expressly says "1 more than it has" (even paraphrased)...
> 
> True - that text is not in iTIP. Are you suggesting that SEQUENCE never
> changes?

Not sure how you got "SEQUENCE never changes" from "I see NOTHING in iTIP 
that expressly says '1 more than it has' (even paraphrased)"...   Still if 
your CUA wants to do a REFRESH if it misses just 1 REQUEST then thats your 
perogative but its not necessary if the REQUEST is a complete snapshot of 
the instance; the higher SEQUENCE one just obsoletes the older one.

Im saying that UID and RECURRNECE-ID never changes!  Everything else can 
change.  (Primary keys cannot change, the rest can!)

> >  > 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.
> > 
> > Umm, this sounds as if you need SEQUENCE to determine RECURRENCE-ID.
> 
> You do.

No, no, no!!  Is iTIP section 2.1.5 NOT understandable??  Its quite clear 
in its ordering: 

1: UID/RECURRENCE-ID is the primary key
2: SEQUENCE is the secondary key (hence you do NOT, NOT NOT use SEQUENCE 
to look for RECURRNECE-ID)
3: DTSTAMP as a tie breaker (aka tertiary key for when UID/RECURRENCE-ID 
matched _then_ SEQUENCE matched!)

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

Sure you can:  The DTSTART is the intended start time for the instance 
identified by the UID/RECURRENCE-ID primary key for the given SEQUENCE 
secondary key.  Its only a problem if you change the primary key to a new 
value (ie: RECURRNECE-ID gets the new DTSTART value).

If the RECURRENCE-ID never changes then its not an issue.  Its easily 
demonstrated, go recheck the examples Ive provided already.  Is this not a 
clear concept? 

RECURRENCE-ID cannot ever change or you have 0% chance of resyncing 
workflow if you miss 1 REQUEST in the process.

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

You will NEVER EVER have a CANCEL with SEQUENCE:0.  Since entries are 
created at SEQUENCE:0 and iTIP Section 3.2.5 CANCEL clearly says:

   When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

then if I wanted to CANCEL an instance I would send the UID/RECURRENCE-ID 
I used all along with a higher SEQUENCE value.  No problem there.  What am 
I missing??

There is one workflow faupaux introduced in the rush to simplify the 
original method list down to the present set; CANCELing just an invitee 
and not the actual instance.  If you read all of the prose in nearly all 
of the CANCEL sections in iTIP (3.2.5 for VEVENTs, 3.4.5 for VTODOs) you 
should not that there is NO prose about cancelling participation in the 
entry; it all talks about cancelling "of an existing event" or "of an 
existing "VTODO"".  Thats because we had another method for 'uninviting' 
ATTENDEEs.  At some point before we shipped someone changed the 
restriction tables to include:

    ATTENDEE        0+     MUST include all "Attendees" being removed
                           the event. MUST include all "Attendees" if
                           the entire event is cancelled.

this was a mistake IMNHO because it now means that if I want to uninvite 
someone I have to CANCEL them (and thus rev SEQUENCE).  This means then 
that I would have to invalidate my existing responses because SEQUENCE has 
changed.  We didnt make the same mistake for VJOURNALs though where it was 
left as:

    ATTENDEE         0+

  This is probably related to the cut/paste mistakes that are evident by 
such text as:

   (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
       be specified with the "RANGE" property parameter value of
       THISANDPRIOR (or THISANDFUTURE)  to indicate cancellation of the
       specified "VTODO" calendar component and all instances before (or
       after); or

under Section 3.5.3 CANCEL for VJOURNALs.  Notice that it refers to VTODO 
still...  Ye Editors did make some mistakes and this was one of them. 
Still it is not unrecoverable.  As an Organizer I can send a new REQUEST 
at the new SEQUENCE value to the existing ATTENDEEs that remain and either 
renegotate their participation or if their CUAs are clever enough the 
process could be semi-automatic.

Still _none_ of this answers the question how a delta model will work for 
the missed REQUEST case.  Its all a digression because its impossible to 
demonstrate resyncing in the delta case... 

To paraphrase: Show me the iTIP!  Show me the iTIP!

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: [email-masked]
Date: Thu, 12 Jun 2003 15:52:01 -0400

Ki wrote on 05/30/2003 03:59:09 PM:
>  Thanks you Bruce! You put in a lot of examples and did a in-depth 
analysis
> of why delta changes RECURRENCE-IDs is a bad thing and I agree with you
> 100%.

You're welcome.  Im glad to hear that the examples were clear and 
informative.

> So far, I also don't see a convincing example for the benefit of delta
> changes
> RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work 
for
> Bruce's samples.

I havent seen any delta model examples yet and I doubt I ever will.  Steve 
Silverberg, Derik Stenerson, Frank Dawson and I spent ~4+ hours at the 
Chicago IETF going over all the cases with a fine tooth comb before we all 
agreed that a delta model just wont work.  Thats why we went to the 
absolute model for everything (and why iTIP messages are supposed to be 
complete snapshots that can just obsolete previous ones, etc).  If you 
want to verify this, get in touch w/any of them.

This however was not the first time this question came up.  If you read 
the archives you will find that Dan Hickman raised the question back in 
July 1999 (Subject "Recurrence ID changes?") and I had expected that that 
would be the last the issue would be heard from.  Guess I was mistaken. 

> Just to add one more perspective to this, Microsoft Exchange 2000 
iTIP/iMIP
> works with recurring instances with the model of RECURRENCE-IDs never
> change. I believe
> this is same for Notes. Bruce, can you confirm?

Lotus Organizer, Lotus Notes, Microsoft Outlook (not Outlook Express 
though) and Microsoft Exchange all use a fixed, unchanging RECURRENCE-ID. 

Im sure other products do too since as you've astutely noted using a delta 
model where RECURRENCE-ID changes can get you into unrecoverable 
situations quite easily.  I just dont happen to have other products 
in-house to test with (but Im always available to interop test if anyone 
is interested).

Bruce

---

From: Satya Vempati <[email-masked]>
Date: Wed, 18 Jun 2003 14:59:56 -0700

How do you handle the case of changed RRULE with recurrence-id and
SEQUENCE:0? If the RRULEs change, you wouldn't have a RECURRENCE-ID that
you can refer to.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, June 18, 2003 2:01 PM
To: [email-masked]
Subject: Re: Fw: Correct handling of Recurrence-id

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

[email-masked] 

Doug Royer <[email-masked]> 
Sent by: [email-masked] 

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

To
[email-masked] 
cc
Subject
Re: Fw: Correct handling of Recurrence-id

[email-masked] wrote:
> 
> I don't really consider this a fix since A RESCHEDULE without anyway to 
> 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.

> Also this does not fix the  BUG of changing recurrence-id's on a 
> 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 
> 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.

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.

-- 

 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: Satya Vempati <[email-masked]>
Date: Tue, 24 Jun 2003 16:32:01 -0700

Is it possible to get one or more of the original authors of iCAL/iTIP to
clarify how RECURRENCE-IDs should be handled?

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 2:16 PM
To: [email-masked]
Subject: Re: Fw: Correct handling of Recurrence-id

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

    ...

--

---

From: [email-masked]
Date: Thu, 26 Jun 2003 17:55:34 -0400

On 5/27/2003 04:22:30AST I replied:
> 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. 

Actually as some have noted privatley this is not necessary. 

Given the prose in iTIP above and the text from Section 3.2.2 REQUEST, all 
that is necessary to do is send an iTIP REQUEST message with the current 
instances in it.  This is legal since it contains the current description 
of each of the instances the invitee is effectively up to date with the 
Organzier.  The relevant bit from iTIP Sections 3.2.2 REQUEST is:

   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.

so by another valid way to invite someone is to just send the current 
version of each instance (assuming a fixed RECURRENCE-ID that is).  Since 
the UID/RECURRENCE-ID are not on the invitees calendar they are treated as 
new invitations and workflow can begin.  Had an invitee already been 
invited to other instances then they are unaffected and only the remaining 
instance defintiions need be sent.  Of course its possible to send all 
instance defintions and then the invitees CUA could use the rules in 
Section 2.1.5 to match the UID / RECURRENCE-ID / SEQUENCE / DTSTAMP values 
to decide what to do w/the REQUEST.

The other way I described it also works but could mistakenly make some 
think that the CUA must preserve both the SEQUENCE:0 definition and then 
all the current ones and thats not necessary.  Both ways will achieve the 
same effect.

Does this jive with your expectations Arnaud?

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