[Ietf-calsify] iTIP and overridden instances

Arnaud Quillaud Arnaud.Quillaud at Sun.COM
Tue Apr 3 05:23:26 PDT 2007


Cyrus Daboo wrote:
> Hi folks,
> Here's a question about iTIP and overridden instances. Example, an 
> organizer sends out a weekly recurring meeting to a set of attendees, 
> using SEQUENCE:0. At some later point the organizer decides to add 
> another attendee to one instance of that meeting only. What does the 
> organizer now do in terms of iTIP messaging? Clearly the organizer 
> would send a copy of that single overridden instance in an iTIP 
> REQUEST to the new attendee. But what should the SEQUENCE be
(the following is not based on any actual implementation)

If it is the only change, I would say , keep it to 0.
If you bump it to 1 and assuming that some other attendees have not 
responded yet, those attendees may later on send a response with 
sequence 0. It is now hard to decide whether you should accept those 
"outdated" responses or discard them since there are other cases where 
you really want to discard them (e.g. change in start time).
> on that? Should the other attendees be notified of the change by also 
> sending a new REQUEST to them, and if so what is the SEQUENCE number?

Ideally, you could send a REQUEST with sequence 0 and RSVP set to false 
(for all attendees who have already replied) which would be silently 
merged by the attendees CUA with their own copy but in fact, most of the 
time, the REQUEST appears as a new invitation in the mail/calendar 
client on the attendee side. As an end user, I consider this to be an 
annoyance, especially for large meetings.

For what it is worth, Outlook is popping up a dialog box ("send only to 
new attendee or send to all ?"). This is probably the best option as 
only the end user can really determine whether a change is worth an update.

Arnaud Q

>
> I am going to pose some more questions about SEQUENCE number with 
> other scheduling scenarios to try and get a better understanding of 
> what people believe it is meant to do, so that it can better be 
> defined in the spec.
>



More information about the Ietf-calsify mailing list