[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with invites to individual instances

Tim Hare wrote:

Doug - that was a fairly clear explanation, to me. If I am understanding things correctly, changing RID:123 to RID:ABC involves a CANCEL operation for the first 3 RIDs (1,2,3) and an ADD operation for the other RIDs (A,B,C) correct? Of course you don't have to ADD as many as you CANCEL or vice-versa. The only thing I have a quibble with here is the statement:

It does not need to involve a cancel explicitly.

A CANCEL does not *need* to be sent.

So the ORGANIZER could:

  (a) SEND 3 single instance CANCELs
      SEND 3 ADDs


      (2) round trips (you can not mix METHOD values
          in one iMIP packet or one CAP MIME object.


(b) SEND 3 instance modifications.


(1) round trip


(c) SEND an entire new object to the effected ATTENDEEs.


(1) round trip

The risk of (a) is that they could be rescheduled between the
CANCEL and the ADD. If the ATTENDEEs are resources and not people, that
might be a critical issue.

If done via iMIP the round trips account for more time.

The ORGANIZER CUA only has to remember the last SEQUENCE number that
an ATTENDEE replied to so that the ORGANIZER/CUA/CU can determine
*IF* the ATTENDEE replied at all. It is NOT used for history.

I don't think the ORGANIZER CUA has to remember the sequence number per attendee if it doesn't want to.... The ORGANIZER "owns" the UID and SEQUENCE values, in a sense. Because the ORGANIZER controls changes to the event represented by UID, it always has the most up-to-date and therefore the highest SEQUENCE.

That is all true. What if the ORGANIZER *never* gets a METHOD:REPLY from one or more ATTENDEEs?

Without remembering which ATTENDEE replied, the ORGANIZER could not
have the information in order to decide who to re-send a REQUEST.
In some situations the ORGANIZER will need to resend, in others
it could be considered an implicit "no thanks".

On other related topics, once I re-read iTIP/iCAL and understood that the UID should be globally unique for the event being scheduled/changed, then forwarding and delegation no longer seems to me to be a problem either -an event can be forwarded or delegated to another CUA - when/if it issues a REPLY then it will use the same UID and the ORGANIZER CUA becomes aware of that CUA's participation. If the delegated CUA never issues a REPLY then under iTIP I see no requirement for the ORGANIZER to worry about that CUA , since it can not be aware of it - correct?

True, the ORGANIZER never *has* to worry. It is an application specific requirement and not an iTIP requirement.


 Doug Royer                     |   http://INET-Consulting.com
 Doug@xxxxxxxxx                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

We Do Standards - You Need Standards

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature