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

Re: Dealing with invites to individual instances

I may have covered this in my other post, but I will cover it here just in case:

I do not think it is a violation of iTIP to send each ATTENDEE a unique object. As I have re-read the protocols, I don't think unaffected ATTENDEEs need to see all changes, unless the ATTENDEE is affected, then they MUST see the changes. Refering to my previous post, UID:1, RID:123 changed to UID:1, RID:ABC - since "W" is invited to instance 3, W has to be notified when 3 disappears. Sending unique objects is, to me, a perfectly acceptable way to do it.

Tim Hare

At 10:50 AM 8/21/03 -0600, you wrote:

Tim Hare wrote:
It seems to me that the rescheduling process, either of one instance, or of a whole recurrence set, should require the ORGANIZER to notify all ATTENDEEs. Because we allow ATTENDEEs to be added to individual instances, there must be at least a partial expansion of the recurrence set to allow that - which in essence makes copies of the list of ATTENDEEs (one copy per instance), which can be updated individually. However this is implemented by a product, rescheduling should process the entire list of ATTENDEEs and notify them, but what I think we're seeing is a place where it sort of breaks down..

Why do you feel that unaffected ATTENDEEs need to see all changes?

In a worst case scenario no two ATTENDEEs would be attending the
same set of instances. Do you feel that is is a violation of iTIP
for the ORGANIZER to send each ATTENDEE (worst case) a unique
object tailored just for them?


 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