Subject: Re: Event owner in ICAL schema

From: "John Stracke" <[email-masked]>
Date: Thu, 7 Feb 2002 14:43:19 -0500

>We are now
>in the process of creating a new ICAL compliant calendar schema.

That's "iCalendar".

>In our
>existing calendar, we have every appointment owned by a person,
[...]
>As far as we have understood the RFC 2445, we are
>not able to find an equivalent attribute wherein we coudl store this
>information.

What about ORGANIZER?

/=================================================================\
|John Stracke                    |Principal Engineer              |
[email-masked]   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|Among animals, it's eat or be eaten. Among people, it's define or|
|be defined.                                                      |
\=================================================================/

---

From: [email-masked]
Date: Fri, 8 Feb 2002 10:27:52 -0500

Alan Davies wrote on 02/07/2002 05:31:11 PM:
> That text is a very strange (it seems to contradict iTIP 3.2.1, which
> specifies that a PUBLISH must have an ORGANIZER, but must not have
> ATTENDEEs), but I don't see why our answers were so wrong unless
> Lata's original schema does not allow for group scheduling.

Guess I was not clear enough so Ill try again.  There is NO contradiction 
w/iTIP since by PUBLISHing the entity it no longer exists in a single 
calendar!  As such, ORGANIZER is allowed in that case.  For the simple 
case of just creating an Appointment in my calendar, it only exists in a 
single users calendar (mine) and as such has no ORGANIZER.

Also I guess you didnt read far enough down my 1st reply.  I said "For any workflow entities, ORGANIZER is what you want... ".  Workflow entities means group scheduling (or other non-single user 
activity).

> When you say 'calendar entries that do not involve others' would the
> case of an entity where the ORGANIZER is the sole ATTENDEE count
> as involving others, which would therefore allow the ORGANIZER property
> to be present?

I think you are mixing up the use of ORGANIZER and ATTENDEE.  If you 
create an appointment on your calendar that does not involve doing any 
workflow (or PUBLISHing which is unidirectional workflow) then I have no 
ORGANIZER; no matter the number of ATTENDEE properties.  Is that no clear 
from the cited text??

I MAY have 1 or more ATTENDEE properties but we never spec'd out that it 
MUST be there since its never going outside the calendar then ATTENDEE is 
not really necessary in all cases.  There are valid cases where you may 
have ATTENDEEs for non-workflow entries (just think a bit, you will find 
some).

> Doug's reply about CAP and VAGENDAs seemed a more correct
> way to represent the concept of 'owner' in a schema, although the
> original question was about iCalendar alone.

Just to be 110% clear on this: My response said (and still is) that for 
non-workflow entries ORGANIZER is NOT allowed!  For workflow entries 
ORGANIZER _IS_ the way to go. 

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Fri, 8 Feb 2002 18:12:25 -0500

Doug replied on 02/08/2002 02:13:16 PM:
> > I think you are treating ORGANIZER as "Owner" of an entry and that is
> > NOT what it is designed for.
> > ...
> 
> No - I was just guessing that he might of meant 
> ORGANIZER.

The relevant part of Latas posting for this is probably this:

>                                                              In our
>existing calendar, we have every appointment owned by a person, namely
>an event_owner, every todo owned by a todo_owner and every journal owned
>by a journal owner. This is a mandatory field for every appointment,
>todo and journal.

Unless their system only allows entries that involve other users (that is 
no entries that never leave the users calendar) then ORGANIZER is not 
equivalent to an Owner.  My take on "every appointment", "every todo" and 
"every journal" is that it encompasses both those that never leave the 
single calendar and those that do.  For those that never leave, we have 
nothing to convey the Owner info.  For those that leave, ORGANIZER is 
essentially the equivalent.  However, it is possible that they _only_ have 
entries that are shared among multiple calendars and as such the short 
answer for them is ORGANIZER...

Boy how we like to digress when answering such a seemingly simple 
question...  ;^)

Lata: Its not clear if you really need to have "Owner" in the iCalendar 
schema mapping.  If you never map entries that never leave that single 
calendar (ie: you only use the schema when mapping meeting request, 
replys, etc) then you can get by with using ORGANIZER and all is well.  If 
you need to map entries that never leave the calendar (ie: for some 
backup/restore solution you want to build) then you will have to go the 
X-ORCL-... route...

Bruce