Subject: Re: Question for list

From: [email-masked]
Date: Tue, 12 Apr 1988 12:37:52 -0400

Doug Royer wrote, in part:
>This means that ORGANIZER is only relevant when the object is pushed
>outside of the users original calendar. Although I don't see why
>it can't be there.

If you just have an "appointment" (i.e., a non-group scheduled event) on 
your calendar, then when you export into an iCalendar format the METHOD 
would have to be PUBLISH or CANCEL and there MUST be no ORGANIZER because 
it is not a group scheduled event. If you had an ORGANIZER than it should 
also have ATTENDEE properties or it is an invalid group scheduled event 
represented in the iCalendar format. 
By restricting the occurrence of ORGANIZER from non-group scheduled 
events, you minimize the chance of misinterpretation as an invalid group 
scheduled event.
So the logic went... But I think this is not an unreasonable restriction.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 12 Apr 2000 09:27:30 -0700

> represented in the iCalendar format.

Not true. A PUBLISH event MUST have an ORGANIZER (And iTIP clearly
states that in the restriction tables) . Because you can PUBLISH for
public view. And it might not have any ATTENDEEs:

	Example of such a PUBLISH:

	The local little league team is having try outs this 
	Saturday - ORGANIZER:....

	And there are NO attendees because you sent it out
	to [email-masked] and you have no idea who is
	on the list, or who will be attending or not.

Anyone wishing to attend the event now knows who the ORGANIZER is,
and as the ORGANIZER is a cal-address, they can possibly look
directly with their CUA and CAP (Assuming VCAR access allowed).

They can also forward the object to anyone. And as the object
contains an ORGANIZER, the new receptionist know who the ORGANIZER
is, and that it is not necessarily the person that sent them the email.

And iTIP specifies that ORGANIZER is a MUST for 
VEVENT, VTODO, and VJOURNAL PUBLISH objects.

Bruces example although a real life issue, is out of scope for
both iTIP and CAP.

> By restricting the occurrence of ORGANIZER from non-group scheduled events,
> you minimize the chance of misinterpretation as an invalid group scheduled
> event.
>

---

From: Mark Paterson <[email-masked]>
Date: Thu, 13 Apr 2000 10:38:18 -0400

A PUBLISH event MUST have an ORGANIZER

What is a non-group scheduled event? There seems to be a consensus from the 
email that's been flying back and forth that the distinction here is based 
on wether there is an attendee list or not. It may be that specs define 
this somewhere (I admit I don't know them backwards and forwards and can't 
recite lines from them as some of you can) but the real distinction I think 
is whether the event effects more than one person. In each of the examples 
that have been put forth in the last few emails on the subject (the 
softball tryouts, the boss informing his employee of his vacation) more 
than one person is being effected wether or not there is a real attendee 
list in the more traditional sense.

So something may be a non-group scheduled event while it sits in your 
Agenda on your computer when you go to PUBLISH it you are in fact changing 
it to be an event that now effects a group of people wether or not these 
people are actually part of an attendee list or not. Therefore once you 
decide to send out a PUBLISH you now need an ORGANIZER so the recipient's 
CUA can properly keep track of it.

Once again, as I mentioned above, I don't know the specs off by heart and I 
am not trying to interpret them here in any way but rather I am trying to 
take a step back and look at it from the consumer level of what makes 
common sense.

Mark Paterson
--
Mark Paterson ([email-masked])
Director, Client Development, CS&T - Lexacom

---

From: [email-masked] (Steve Mansour)
Date: Thu, 13 Apr 2000 09:34:15 -0700

> CUA can properly keep track of it.

This is the spirit of what we put into iTIP. In particular, the Organizer is
required so that if you receive an updated version of the PUBLISH'd event, you
have some basis for determining that the update is legitimate -- from a "role"
point of view, not from a security point of view.  Only the Organizer can
change the event (see iTIP 6.1.1 Spoofing the "Organizer")

Furthermore, if someone puts a copy of a published event into their calendar
and does a REFRESH, we need to know where to direct the refresh request. It
goes back to the Organizer.

-Steve