Re: RECURRENCE-ID discussion

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 08/07/2003 05:17:43 PM:
> And the ORIGINAL SEQUENCE:0 FULL object can not contain a RECURRENCE-ID.

Says who?  Its nowhere in any text
or table in iTIP.  Its perfectly valid to send:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1com
   RECURRENCE-ID:19970701T210000Z
   SEQUENCE:0
   ORGANIZER:Mailto:A@xxxxxxxxxxx
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@xxxxxxxxxxx
   ATTENDEE:Mailto:B@xxxxxxxxxxx
   ATTENDEE:Mailto:C@xxxxxxxxxxx
   ATTENDEE:Mailto:D@xxxxxxxxxxx
   DESCRIPTION:IETF-C&S Conference Call
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:20030814T210000Z
   DTEND:20030814T220000Z
   LOCATION:Conference Call to resolve RECURRENCE-ID
   DTSTAMP:20030811T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

NOWHERE in iCalendar or iTIP do we ever
say this is NOT allowed.  Sorry but you are creating new semantics
for REQUEST that simply do not exist in iTIP.  iTIP 3.2.2 REQUEST
says that REQUEST is used for multiple actions:

     .  Invite "Attendees"
to an event;
     .  Reschedule an existing event;
     .  Response to a REFRESH request;
     .  Update the details of an existing event, without
rescheduling it;
     .  Update the status of "Attendees" of an
existing event, without
        rescheduling it;
     .  Reconfirm an existing event, without rescheduling
it;
     .  Forward a "VEVENT" to another uninvited
CU.
     .  For an existing "VEVENT" calendar component,
delegate the role of
        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component,
changing the role of
        "Organizer" to another CU.

and it later says how to differentiate
between these different cases with the text:

   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.

and:

3.2.2.1 Rescheduling an Event

   The "REQUEST" method may be used to reschedule an event.
A
   rescheduled event involves a change to the existing event in terms
of
   its time or recurrence intervals and possibly the location or
   description. If the recipient CUA of a "REQUEST" method
finds that
   the "UID" property value already exists on the calendar,
but that the
   "SEQUENCE" (or "DTSTAMP") property value in
the "REQUEST" method is
   greater than the value for the existing event, then the "REQUEST"
   method describes a rescheduling of the event.

3.2.2.2 Updating or Reconfirmation of an Event

   The "REQUEST" method may be used to update or reconfirm
an event. An
   update to an existing event does not involve changes to the time
or
   recurrence intervals, and might not involve a change to the location
   or description for the event. If the recipient CUA of a "REQUEST"
   method finds that the "UID" property value already exists
on the
   calendar and that the "SEQUENCE" property value in the
"REQUEST" is
   the same as the value for the existing event, then the "REQUEST"
   method describes an update of the event details, but no rescheduling
   of the event.

So, if the UID / RECURRENCE-ID are not
found for a repeating instance then "then
the "REQUEST" is for a new "VEVENT" calendar component."
(aka an invitation).  

If the UID / RECURRENCE-ID are found
for the repeating instance and the SEQUENCE value is "greater"
(not just 1+) "then the "REQUEST"
method describes a rescheduling of the event."
(aka a reschedule in case the section header wasnt clue enough).  

If the UID / RECURRENCE-ID are found
for the repeating instance and the SEQUENCE value is the same (factoring
in DTSTAMP too) "then the "REQUEST"
method describes an update of the event details, but no rescheduling of
the event." (aka an update
in case the section header wasnt clue enough here too). 

The CUA does NOT construct semantics
based on just the properties in the message; it bases it on them and those
it has (or does not have) locally!  Any other behaviour is contrary
to iTIP and a misapplication of it.

> And if it does contain a RECURRENCE-ID, then
it is a object modify
> as defined  by iTIP and not an new invitation.

You seem to be ignoring the application
of Section 2.1.5 Message Sequencing rules when you read the Section 3 messages.
 Because the workflow process needs to be able to deal with different
kinds of messages that may arrive in different order than they were sent,
we created Section 2.1.5 as a common place for explaining how to sequence
them all.  This also had the benefit of not making us having to expressly
say "If you find the "UID" (or the "UID" / "RECURRENCE-ID"
pair in the case of a repeating instance) ..." in every place in the
Section 3 texts.  It made for a smaller draft and made editing easier.
 

I say this because you keep saying that
there is no RECURRENCE-ID on an invitation and Im guessing that you think
this because the text from 3.2.2 does not expressly say "RECURRENCE-ID"
in it somewhere.  However neither do the 3.2.2.1 or 3.2.2.2 texts
so perhaps you think that you cannot have RECURRENCE-IDs on reschedules
or updates too then??...

> Do you disagree that iTIP says that if it has
a RECURRENCE-ID and
> METHOD:REQUEST that it is a modify and not a new invitation?

Yes. If you understand the function
of Section 2.1.5 and correctly apply it to all the Section 3 texts you
should see that iTIP NEVER says that a METHOD:REQUEST without a RECURRENCE-ID
is an invitation, otherwise its a reschedule.  iTIP NEVER draws that
distinction.

If one correctly reads the text in 3.2.2
(and 3.2.2.1 and 3.2.2.2) then you should see that the recipients interpretation
of the message is dependent on what they _already_ know about the instance
in question and not just the senders intent!  

So, if you never got the SEQUENCE:0
thru SEQUENCE:5 REQUESTS (they got lost in a disk crash enroute or your
Admin was messing with you or some coworker was getting even or...) and
you do receive the SEQUENCE:6 REQUEST then you should treat it like an
invitation even though from the Organizers point of view it was the 6th
reschedule of the instance (to which you may have only recently been added
or were an 'original' ATTENDEE).  

It does not matter to you really in
that you can correctly join the workflow for that instance by simply sending
back a REPLY with the UID / RECURRENCE-ID / SEQUENCE values you just got.
 If you recieve one or some of the previous SEQUENCE valued REQUESTS
later then you simply can treat them as obsoleted REQUESTs for an instance
you already have more current info and ignore them.  That of course
assumes a fixed RECURRENCE-ID model so that you can do the correct obsolete
determination.  

Otherwise you have to go thru all the
extra gyrations and thrashing I described in my analysis for Tim last week.

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