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:
(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.
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.
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
Description: S/MIME Cryptographic Signature