Subject: Changing the attendee list without sending to all attendees

From: "Matt Hainje (Exchange)" <[email-masked]>
Date: Thu, 18 Feb 1999 16:57:29 -0800

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: "Lowde, Chris A" <[email-masked]>
Date: Tue, 23 Feb 1999 10:45:11 -0600

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] <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

 

 
 
--Matt Hainje

---

From: Andre Courtemanche <[email-masked]>
Date: Tue, 23 Feb 1999 20:36:41 -0500

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: [email-masked] [mailto:[email-masked]]
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.
>
> 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
> ?????????????????
> mailto:[email-masked]
However,
> this would require resending the meeting to all current attendees.
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.

---

From: [email-masked]
Date: Wed, 24 Feb 1999 10:06:09 -0500

Tony,

If the extra, 201st person you added to that meeting was Bill Gates, do you
think it would influence the decsion of the first 200 guests about whether
or not they will attend?

Frequently the guest list is a MAJOR factor that influences attendance.  I
agree that all the extra messages are a pain, but changes in the guest
list, the agenda, or the location can also be important.  If it is up to
the OWNER of the meeting to decide whether to refresh all guests' data,
inevitably guests may not get information they want.  I think it should be
left up to the individual GUEST/user to define if they what types of
changes they want to be notified about.  If you adopt any other model other
than "send all changes" things seem to get complicated really quickly over
functionality.

michael

"Tony Small (Exchange)" <[email-masked]> on 02/23/99
08:47:28 PM

To:   "'Andre Courtemanche'" <[email-masked]>, "[email-masked]'"
      <[email-masked]>
cc:    (bcc: Michael Bandes/ON Technology)
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:[email-masked]]
Sent: Tuesday, February 23, 1999 5:37 PM
To: [email-masked]'
Subject: RE: Changing the attendee list without sending to all attendees

Matt,

Andre Courtemanche
CS&T.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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

-Steve

receive
for
that
sending
left the
have
attendees
However,
cancellation.
because
that of
the
all

---

From: Vinod_Seraphin/CAM/[email-masked]
Date: Wed, 24 Feb 1999 13:58:36 -0500

If you wanted to send an iCal message to a subset of the original invitees or to
an additional invitee, I believe this can be done by leaving the SEQUENCE number
the same and updating the DTSTAMP.  The IMIP document lists several properties
which if changed must result in an increment of SEQUENCE.  ATTENDEE is not one
of them.

DTSTAMP should be used by clients to break tie-breakers when the sequence
numbers are the same.  A more recent DTSTAMP indicates this is the more recent
message regarding this sequence number.

- Vinod

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Feb 1999 15:09:41 -0800 (PST)

> From: "Matt Hainje (Exchange)" <[email-masked]>
> Date: Thu, 18 Feb 1999 16:57:29 -0800
> 

I think this is an implementation detail and in some cases
everyone needs to be updated, and in others no one else needs
to be updated.

If the VEVENT was for a public meeting - say a Town Hall meeting
with your congressional representative. I do not think that each
person will want their CAP, iRIP, or iMIP address sent out
to everyone attending.  --> It would simply be spam bait.

In other implementations - it might be necessary to send out
everything.

I think only the CUA and the ORGANIZER knows the answer. I don't
think there is one answer.

If you decide to not send out ATTENDEE updates to everyone. The
implementation needs to assure that whatever the implementation
considers important re-sends (SEQUENCE++) the object. Any such
implementation will have to track this to assure it does not violate
any CAP or iTIP rules.

I can also see that in the case of the public meeting, a REFRESH
only replies with one ATTENDEE - the one who send the REFRESH.
In some cases - the other ATTENDEEs are none of their business.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Feb 1999 15:25:52 -0800 (PST)

> From: "Tony Small (Exchange)" <[email-masked]>
> Date: Tue, 23 Feb 1999 17:47:28 -0800
> 
> organizer can of course, still choose to send an update to everyone, but the

I agree - for events with thousands of people. Just think of the
usless information sent to thousands of people who will never
notice anyting changed on their calendar - yet they may have
received thousands of email's!!!

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Feb 1999 15:39:34 -0800 (PST)

> 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
> The question still remains: does iCalendar support "arbitrarily" sending

When you say 'cancellations', do you mean the one ATTENDEE saying they
will not attend?

If you mean the event is METHOD:CANCEL, then it must be sent to all.
If something that the originating CUA or ORGANIZER sees as important.
Then it would need to be sent to all attendees. Yet I don't see it
as desirable to send the same VEVENT to all attendees. Some
implementations may require that it is not passable to see all
other attendees.

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Feb 1999 15:42:03 -0800 (PST)

> From: "Daniel J. Mitchell" <[email-masked]>
> Date: Wed, 24 Feb 1999 09:34:29 -0700
> 
> [email-masked] wrote:
>  One more thing this brings up, then, is if updates should be sent to
> people who've declined the meeting. If you send out a request to 200
> people, they all decline because they're not interested, and _then_ Bill
> Gates is added to the meeting, should the first 200 people be given the
> chance to change their minds, or should they be left out of the update
> cycle because they sent their decline too hastily?

What if Mr. Gates does not want every one else to know he is attending?
It might be an appointment for a non-business meeting. He may
be attending an event for his personal enjoyment.

It seems to me that only the ORGANIZER and originating CUA would
know the correct answer.

-Doug

---

From: "Matt Hainje (Exchange)" <[email-masked]>
Date: Wed, 24 Feb 1999 16:02:50 -0800

No, the scenario is exactly as described in iTIP 4.2.10, "Removing
Attendees".  The problem occurs when a "cancelled" attendee must be
re-invited.  The user scenarios for such a possibility are somewhat obscure,
but they exist nonetheless.  It appears that the rules surrounding the
SEQUENCE property will not allow an un-invited person to be re-invited
without sending an update to all attendees, because the "re-invitation"
would need a SEQUENCE higher than that of the cancellation, which is in turn
higher than that held by all other attendees.

--Matt Hainje

-----Original Message-----
From: Doug Royer [mailto:[email-masked]]
Sent: Wednesday, February 24, 1999 3:40 PM
To: [email-masked]
Subject: RE: Changing the attendee list without sending to all attendees

receive

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Feb 1999 18:05:59 -0800 (PST)

> Date: Wed, 24 Feb 1999 16:02:50 -0800
> 

In iTIP is says in 2.1.4 ...

	...The rules for incrementing the
   "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are
   paraphrased here in terms of how they are applied in [iTIP]. ...

   ...   
   
     . The "SEQUENCE" property value MUST be incremented each time the
      "Organizer" uses the "ADD" or "CANCEL" methods.

Yikes. This has to be an ERROR. When I read it, I read it as:
The SEQUENCE number must be incremented each time the component has had
an ADD (add instance to meeting) which I think would be necessary,
or the component is in its entirety is canceled.

But what I thought - is not what it says.

However, there is no need to send out the new appointment
to "all" attendees. 2.1.4 also says:

   The value of the "SEQUENCE" property contained in a response from an
   "Attendee" may not always match the "Organizer's" revision.
   Implementations may choose to have the CUA indicate to the CU that
   the response is to an entry that has been revised and allow the CU to
   decide whether or not to accept the response.

I would think it would be okay for a CS implementation when it got an
update for an event, where an unrelated ATTENDEE(s) had already been
removed from the master copy as the only change, the CS may accept the
data as an update. And optionally send an updated event to the updating
ATTENDEE. Where the CUA + CU may decide again to change things. In fact
for the CUA + CU to make such a decision (implied by what 2.1.4 says
above) that must be what happens?

Or we need to change 2.1.4 to say when the entire component
is CANCELED.

So I do not see SEQUENCE as an attribute of the component "on disk",
(although it would need to be stored) as much as I see it as a way for
CUA's to tell the CS which instance they are talking about. It requires
more work on the CS side. But at times like this I think its what the
user wants - just make it work. We may have to work out some examples
to make sure interoperatability works. I don't think its a big issue.

So it would be possible for a user to say that they will not
be attending SEQUENCE:2, then later say that they will be attending
SEQUENCE:3, only for the CS to say (in effect) we are now at SEQUENCE:4.
Have the CUA do a REFRESH, then the CUA (+ optionally the CU) resubmit
the update. Again requires some code in the CUA. But it look as if
its too late to change iTIP.

Or did I miss the point again :-)

-Doug

---

From: Doug Royer <[email-masked]>
Date: Sun, 7 Mar 1999 15:22:14 -0800 (PST)

> > > I expect most such people can use out-of-band
> > > mechanisms (e.g., sending ordinary email to the organizer);
> >
> > What if the ORGANIZER is a process (program) and not a person.
> 
> Somewhere or other, there's a person.

Yes - and the reason we have computers is so that computers
can do things for us and so we don't have to monitor everything
all of the time.

-Doug

---

From: [email-masked]
Date: Wed, 17 Mar 1999 12:15:57 -0500

I agree with Tony. His example is remarkably realistic.  This happens all
the time.

                                                              
 To:      "'Andre Courtemanche'" <[email-masked]>,             
          "[email-masked]'" <[email-masked]>   
                                                              
 cc:      (bcc: Pat R Egen/Egen Consulting/01)                

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

Andre,

Tony

-----Original Message-----
From: Andre Courtemanche [mailto:[email-masked]]
Sent: Tuesday, February 23, 1999 5:37 PM
To: [email-masked]'
Subject: RE: Changing the attendee list without sending to all attendees

Matt,

Andre Courtemanche
CS&T.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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

-Steve

receive
for
that
sending
left the
have
attendees
However,
cancellation.
because
that of
the
all