Subject: RE: Changing the attendee list without sending to all attendees

From: "Matt Hainje (Exchange)" <[email-masked]>
Date: Tue, 23 Feb 1999 13:40:15 -0800

In my described case, it is up to the organizer to decide who should receive
the new list of attendees.  Different people and situations will call for
different behavior, and I think that a blanket requirement such as that
below will only hinder iCalendar's usefulness.

The question still remains: does iCalendar support "arbitrarily" sending
requests and cancellations to subsets of the meeting's attendees, as
described below.  So far, I'm inclined to think not.

--Matt Hainje

PS - Apologies for sending out the original message as HTML.  I've left the
original message at the bottom of this thread for anyone that might have
missed it the first time.

-----Original Message-----
From: Lowde, Chris A [mailto:[email-masked]]
Sent: Tuesday, February 23, 1999 8:45 AM
To: Matt Hainje (Exchange); IETF-CalSch (E-mail)
Subject: RE: Changing the attendee list without sending to all attendees

Matt,
 
The list of attendees at a meeting is part of the information about the
meeting.  If the organiser either adds or removes an attendee then this
information should be sent to the other attendees, it could make a
difference to what they may want to do in respect of attending the meeting,
or to what level they may want to prepare for the meeting.
 
Chris. 
????????????????? 
Christopher A Lowde 
Texaco 
4800 Fournace Pl. 
Bellaire, TX 77401-2324 
Tel: +1(713)432-2901 
Fax: +1(713)838-4529 
mailto:[email-masked] 
-----Original Message-----
From: Matt Hainje (Exchange) [mailto:[email-masked]]
Sent: Thursday, February 18, 1999 18:57
To: IETF-CalSch (E-mail)
Subject: Changing the attendee list without sending to all attendees
I've come across an apparent shortcoming while trying to map a feature to
iCalendar.

The scenario is this: I want to remove an attendee without needing to notify
all current attendees of the change.  The idea would be to send a
cancellation just to the removed attendee, as shown in the example in iTIP
4.2.10.  The root of problem is that the cancellation must have an
incremented SEQUENCE, as stated in iTIP 3.2.5.

There are 2 possible implications from the incremented SEQUENCE:
1. The organizer's copy must also have the incremented SEQUENCE.  However,
this would require resending the meeting to all current attendees.
Otherwise, the SEQUENCE on responses from the original attendees will not
match that on the organizer's copy. 
2. Don't increment the organizer's SEQUENCE when sending the cancellation.
The problem here is that I can't re-invite the just-removed attendee because
that attendee's copy of the meeting now has a SEQUENCE greater than that of
the organizer.  The only way to re-invite that attendee would require
bumping the organizer's SEQUENCE by 2, e.g. remember that I've sent the
cancellation, and that would in turn require sending the meeting to all
attendees. 

Now, some might question the restriction on sending updates to all
attendees, but the fact of the matter is that everyone doesn't have a
"smart" client which can dispose of unnecessary requests.  So I would like
to minimize the requests and cancellations that must be sent.  Also, note
that the example in iTIP 4.2.10 does not mention that requests MUST be sent
to all remaining attendees.  It also interesting that the example shows the
organizer's SEQUENCE bumped by 2 (1 for the cancellation, 1 to supercede the
cancellation).

Are my requirements possible within iCalendar?

--Matt Hainje
Sent using Outlook 2000 and Office E-mail (build 2612)

---

From: [email-masked] (Steve Mansour)
Date: Tue, 23 Feb 1999 14:25:22 -0800

If I understand your issue correctly, ICAL does not address this at all. It
sounds like a protocol issue, not a data issue. It is addressed to some extent
in ITIP. There are no rules in ITIP that say an organizer must resend an event
or todo  when an Attendee accepts/declines/delegates etc. The problem was, as
you point out, that there was no right or wrong conditions under which ITIP
should require a resend of the event or todo.

Perhaps we need specify this point in the ITIP doc. I don't recall putting
anything in ITIP that states who the Organizer would send updates to. I believe
it was always assumed that when an update was sent out, it would be sent to all
attendees. A sort of exception to this was if an attendee requested a REFRESH.
ITIP Sections 3.2.2.1 and 3.2.2.2. may help clarify this.

-Steve