[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
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.
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