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

From: Doug Royer <[email-masked]>
Date: Thu, 25 Feb 1999 20:33:56 -0800 (PST)

> Date: Thu, 25 Feb 1999 18:25:16 +0000
> From: John Stracke <[email-masked]>
>
> Doug Royer wrote:
> 
> > What if its a public figure - and they do not want others to know
> > that they are attending?
> 
> Then they shouldn't be on the calendar at all--not sending the update...

I don't think so. What if its a Baseball game and the iCalendar
object is part of an e-commerce packet that includes credit card
information for payment? There is just going need to be a way for
the CS + ORGANIZER to decide who can see what.

> ...wouldn't prevent people from using REFRESH to find out anyway.

I also am a proponent of allowing the CS + ORGANIZER to decide if *all*
of the ATTENDEE properties are sent out on an update or REFRESH,
or just the person makeing the REFRESH request.

> 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.
How would you know?

Looking forward to meeting you in Menlo Park in two weeks!

-Doug

---

From: John Stracke <[email-masked]>
Date: Sun, 07 Mar 1999 23:11:34 +0000

Doug Royer wrote:

> information for payment?

Then, obviously, that ecommerce app has to be built not to broadcast the
credit card info, no matter what.  That doesn't have anything to do with
whether everybody gets the iCal messages.

> What if the ORGANIZER is a process (program) and not a person.

Somewhere or other, there's a person.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/