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.
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.
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-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature