I agree with Tony. His example is remarkably realistic. This happens all
the time.
"Tony Small (Exchange)" <tonysm@Exchange.Microsoft.com> on 02/23/99
08:47:28 PM
To: "'Andre Courtemanche'" <andrec@cst.ca>,
"'ietf-calendar@imc.org'" <ietf-calendar@imc.org>
cc: (bcc: Pat R Egen/Egen Consulting/01)
Subject: RE: Changing the attendee list without sending to
all attendees
Andre,
I disagree. Here's the scenario:
1. I invite 200 people to a meeting.
2. "Oops!" I forgot to add John Smith. I need to send the meeting to him
as
well.
3. The next day, my manager comes to me and says I should also invite Mary
Joe. I need to send a meeting to her as well.
If we always sent meeting requests with attendee changes to everyone, 200
people would receive a useless meeting request twice.
We implemented this feature - the ability to add attendees and only send
meeting requests to those added - due to high customer demand. The
organizer can of course, still choose to send an update to everyone, but
the
organizer should really make that choice to best suit his/her needs.
Tony
-----Original Message-----
From: Andre Courtemanche [mailto:andrec@cst.ca]
Sent: Tuesday, February 23, 1999 5:37 PM
To: 'ietf-calendar@imc.org'
Subject: RE: Changing the attendee list without sending to all attendees
Matt,
It certainly makes more sense to send all the new
information to all attendees. Not automatically sending
the information to all other attendees means that there
is no way for attendees to ensure they have the latest
info, other than by asking a "Refreshed" copy from the
owner.
Why should they only find out about a change of
information about the other attendees after they
request an update from the owner ? Not a very good user
experience.
IMO, Information should be sent when attendee information
changes, keeping all data consistent for everybody in
the meeting --
Andre Courtemanche
CS&T.
-----Original Message-----
From: sman@netscape.com [mailto:sman@netscape.com]
Sent: Tuesday, February 23, 1999 5:25 PM
To: Matt Hainje (Exchange)
Cc: 'Lowde, Chris A'; IETF-CalSch (E-mail)
Subject: Re: Changing the attendee list without sending to all attendees
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
"Matt Hainje (Exchange)" wrote:
> 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:lowdeca@texaco.com]
> 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:lowdeca@texaco.com
> -----Original Message-----
> From: Matt Hainje (Exchange) [mailto:mattha@Exchange.Microsoft.com]
> 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)
Attachment:
att1.eml
Description: Binary data