Re: Dealing with invites to individual instances

[Doug Royer <Doug@xxxxxxxxx>]

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

      GET 6 REPLYs

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

.OR.

  (b) SEND 3 instance modifications.

      GET 3 REPLYs

      (1) round trip

.OR.

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

      GET 1 REPLY

      (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