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

Re: Dealing with invites to individual instances





Mark Swanson wrote:


Agreed. I can't find anything in iTIP that notifies attendees of disappearing recurring instances. It would seem like the courtious thing to do would be to send a cancel/request to those attendees.


I think you've made a good point. Doing a cancel/request means the problem is solved within the iTIP spec - and I've noticed that under those circumstances a very hot place would have to freeze over before iTIP would be modified to handle it differently. :-)

Your making it way too complicated. iTIP is a protocol to transfer information to ATTENDEEs, it is not an extension of the CUA implementation. You only have to convey the needed information to the ATTENDEE. There does not need to be an all encompassing object that represents the state of all ATTENDEEs status on the wire. Just send the effected ATTENDEEs the information they need.

For:

  UID:U1
  SEQUENCE:S1
  with five instances (I1, I2, I3, I4, and I5).

If ATTENDEEs A1 and A2 are to have instance I1 removed from their
calendar and ATTENDEEs A3 and A4 are not, then bump the SEQUENCE number
in ORGANIZER cal store and send CANCEL:I1 to A1 and A2. You do not
need to send anything to A3 and A4. A1 and A2 reply:

   ORGANIZER now is at SEQUENCE:S1+1
   A1 last responded to SEQUENCE:S1+1
   A2 last responded to SEQUENCE:S1+1
   A3 last responded to SEQUENCE:S1
   A4 last responded to SEQUENCE:S1

   A3 and A4 last responded to SEQUENCE:S1 and it does not matter
   to A3 and A4 because nothing changed they need to care about.

   The ORGANIZER CUA only has to compare the current component
   (SEQUENCE:S1+1 in this example) to the change that the
   ORGANIZER-CU wishes. Simply compare the changes to the
   SEQUENCE:S1+1 object and see which ATTENDEEs it effects.

If later A3 is to be canceled from instance I2. The ORGANIZER-CUA looks
at the object and can tell that it only effects A3, so only
A3 is sent the CANCEL:I2 object. And A3 replies:

   ORGANIZER is now at SEQUENCE:S1+2.
   A1 last responded to SEQUENCE:S1+1
   A2 last responded to SEQUENCE:S1+1
   A3 last responded to SEQUENCE:S1+2
   A4 last responded to SEQUENCE:S1

Now for some reason A2 does a full or instance REFRESH,
so the ORGANIZER sends them an object (S1+2) as it effects A2.
There is no need or requirement that the S1+2 object sent to A3
above look exactly like the object now sent to A2 (for full
REFRESH the current object can use EXDATE, RDATE, RRULE, and
EXRULE to convey the current state of the object), and A2 replies:

   ORGANIZER is now at SEQUENCE:S1+2.
   A1 last responded to SEQUENCE:S1+1
   A2 last responded to SEQUENCE:S1+2
   A3 last responded to SEQUENCE:S1+2
   A4 last responded to SEQUENCE:S1

If later something changes that effects one or more ATTENDEEs.
Lets say all of them because the LOCATION changes. So the
ORGANIZER-CUA bumps the SEQUENCE number to S1+3. And
sends them to A1, A2, A3, and A4. And they reply.

   ORGANIZER is now at  SEQUENCE:S1+3
   A1 last responded to SEQUENCE:S1+3
   A2 last responded to SEQUENCE:S1+3
   A3 last responded to SEQUENCE:S1+3
   A4 last responded to SEQUENCE:S1+3

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.

If the current change effects an ATTENDEE in the 'current' (pre changed) object. And if it does send them the update information.

When you reschedule, you bump the SEQUENCE number. It makes the old
instances disappear - that is what a reschedule is. The same is true
of the update shown in iTIP. When the new updated UID is sent with
the new SEQUENCE, the old instances go away.

It does not matter if the ATTENDEE was invited to one or more instances.
It does not matter if the ATTENDEE was invited to the initial instance.
When the ORGANIZER needs to send an ATTENDEE an object - send them
what they need so that the ATTENDEE-CU can decide if they will attend.
No history needed.

The same is true for CANCEL. Simply send the effected ATTENDEEs
a full or instance CANCEL. If it does not effect other ATTENDEEs
then do not send them anything. If anyone does a REFRESH, send
them an object that represents the current ORGANIZER view of the
object as it effects that ATTENDEE.

There's bound to be a number of little implementation details like this. It sure would be nice if they were captured in a common location.


--

 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