[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Correct handling of Recurrence-id
Doug wrote on 07/07/2003 07:11:55 PM:
> If they do not equal and you are the ORGANIZER - then throw
> away their REPLY and generate them a new REQUEST as they do
> not have a clue what they are replying to.
You absolutely DO if the RECURRENCE-ID
is fixed. You absolutely DO NOT if the RECURRENCE-ID changed on each
reschedule. However the latter case is contrary to the RFC where
a fixed RECURRENCE-ID is clearly described:
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.
If RECURRENCE-ID were NOT fixed then
the only solution would be to rescyc ALL instances the invitee was invited
too, not just the one in question.
With a fixed RECURRENCE-ID identifying
the exact instance in question is trival (its part of the primary key used
to find the instance) and thus the Organizer can quickly and easily just
send a newer REQUEST for that particular instance. No need to rewrite
all instances the invitee has been invited to. No need to resend
all that extra data.
>
If they send you
> are REPLY that is less than the current object SEQUENCE, they
> are replying to old news anyway - no matter which model you use.
We have been talking about instance
specific workflow but your phrase "current object SEQUENCE" has
lots of loaded and undefined meaning.
Each instance in the set has its own
SEQUENCE value (thats how workflow for each instance can proceeded independent
of all the other instances!). SEQUENCE is NOT shared among all the
instances because if you did that then ANY reschedule of ANY single instance
would raise the shared SEQUENCE value and invalidate ALL workflow for ALL
other instances in the set.
That generates TONS of extra wasted
workflow messaging and renegotation. It also does NOT jive with the
way message sequencing works in 2446. If the UID/RECURRENCE-ID are
the primary keys to find the instance (per rule 1 in Section 2.1.5 in iTIP)
and SEQUENCE is the secondary key (per rule 2) then clearly each instance
MUST have its own SEQUENCE value.
So can you please clearly describe what
you mean be "the current object SEQUENCE" because it sounds like
it means each instance in the recurrence set shares the same SEQUENCE value...
> If you get an instance specific update for SEQUENCE:x
and you are an
> ATTENDEE and you have SEQUENCE:z (where z <= (x-2)), then DO a
REFRESH
> as you do not have a clue what SEQUENCE (x-1) is at all and no matter
> what model you use for RECURRENCE-ID, they will need to do a REFRESH.
Sorry but thats patently NOT true; its
ONLY true for the case of a RECURRENCE-ID that changs on each reschedule
(which is clearly contrary to the text from 2445 at top!)
If the RECURRENCE-ID is fixed then you
have no doubt that it refers to the same RECURRENCE-ID you have but at
a lower or higher SEQUENCE value. You use the UID/RECURRENCE-ID to
find the instance and then you check the SEQUENCE value.
As iTIP clearly describes in 2 places
its NOT an issue if you missed any intermediate REQUESTs since:
the
component with the highest numeric value for the
"SEQUENCE"
property obsoletes all other revisions of the component
with
lower values.
That means if find the correct instance
and detect that your SEQUENCE is 1 or 2 or 100 below the one in the REQUEST
then your copy is clearly obsolete. NO need for a REFRESH as the
REQUEST is a complete snapshot of that instance at that SEQUENCE value.
You simply accept, decline, etc and save away the new information.
Now if you are still thinking that Section 4.7.2 of iTIP justifys
the need to do a REFRESH because it says:
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.
then you need to consider some facts:
1: In order for the UID/RECURRENCE-ID
to match so you can do the SEQUENCE check of "larger" or "smaller"
then clearly UID & RECURRENCE-ID have to remain fixed! Otherwise
you cannot match the UID and RECURRENCE-ID values to the correct instance
in question to do the SEQUENCE check.
2: As noted by Section 2.1.5 a higher
SEQUENCE "obsoletes" all lower SEQUENCE values and this agrees
when it says that the invitees "version needs
to be updated.". However
since each REFRESH is a complete snapshot we no longer have to worry about
missed "updates" because we no longer need them. This was
another benefit of going to full snapshots on REQUESTs from the early model
of rolling changes forward (akin to changing the RECURRENCE-ID on each
reschedule). The new REQUEST obsoletes any lower SEQUENCE valued
info, plain and simple. No need to worry about missed updates, unless
of course you try to ignore 2445 and change RECURRENCE-ID each time you
reschedule.
3: The only way to recover a missed
reschedule REQUEST is to resync ALL instances; you cannot just resync a
single instance if RECURRENCE-ID changes. Lots of wasted bandwidth
and workflow thrashing. However the text clearly says "SHOULD
send a "REFRESH"" and NOT "MUST send a "REFRESH"
to the Organzier. In the delta model of RECURRENCE-IDs it would have
to be a MUST in order to restore order. SHOULD would not cut it.
> If you get an instance specific update for SEQUENCE:x
and you are an
> ATTENDEE and you have SEQUENCE:z (where z = (x-1), Then you DO
> have the latest object and can apply the instance change.
The new REQUEST does NOT mean that you
change the RECURRENCE-ID. Thats contrary to 2445 no matter how you
try to read bits of 2446.
Bruce
===========================================================================
Bruce Kahn
INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration
Phone: 978.399.6496
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...