Subject: [Ietf-calsify] is the ORGANIZER an ATTENDEE?

From: gafter at google.com (Neal Gafter)
Date: Thu Aug 18 15:32:30 2005

Is the organizer of an event implicitly an attendee? Many of the calendar 
clients I've tried do not add the organizer as an attendee in the .ics for a 
meeting, but do treat the organizer as busy during such an event. I could 
not find anything in the specs suggesting that the organizer is implicitly 
an attendee of such an event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050818/77b6a75d/attachment.htm

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Thu Aug 18 15:38:08 2005

On 19. Aug 2005, at 00:32 Uhr, Neal Gafter wrote:
> Is the organizer of an event implicitly an attendee?

No.

> Many of the calendar clients I've tried do not add the organizer as  
> an attendee in the .ics for a meeting, but do treat the organizer  
> as busy during such an event.

Could you please elaborate? Which clients do so?

> I could not find anything in the specs suggesting that the  
> organizer is implicitly an attendee of such an event.

Because it isn't. The one organizing the meeting doesn't have to take  
part in a meeting for somewhat obvious reasons.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: gafter at google.com (Neal Gafter)
Date: Thu Aug 18 16:09:50 2005

> Could you please elaborate? Which clients do so?

I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is just my 
misunderstanding. If I invite my friend to lunch by creating an event with 
him as an attendee but don't add myself as an attendee, it still shows up on 
my calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050818/a814393f/attachment.html

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Aug 18 16:19:53 2005

That is a feature/bug of the GUI you are using.

There are valid reasons to be the ORGANIZER and not attending
an event.

It is also possible to have something on your calendar and
not show as busy. Most vendors did what ever they wanted
with ORGANIZER and ATTENDEE.

Neal Gafter wrote:
> On 8/18/05, Helge Hess <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is just 
> my misunderstanding.  If I invite my friend to lunch by creating an 
> event with him as an attendee but don't add myself as an attendee, it 
> still shows up on my calendar.
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: text/x-vcard
Size: 373 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050818/c103ee8f/Doug.vcf

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Thu Aug 18 16:26:01 2005

On 19. Aug 2005, at 01:09 Uhr, Neal Gafter wrote:
> I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is  
> just my misunderstanding.  If I invite my friend to lunch by  
> creating an event with him as an attendee but don't add myself as  
> an attendee, it still shows up on my calendar.

You  probably interpret the output of those tools incorrectly. What  
the calendar shows in those applications has nothing to do with the  
attendees, both just display the physical calendar records present in  
the respective calendar collections (a "folder" in Outlook, a  
"calendar" in iCal).
A lot of PIM applications lack filtering on attendees which hurts a  
lot with shared calendars.

Usually you are an attendee or at least an organizer, but this is not  
strictly required in either of the apps (eg think of a shared folder  
containing events of other people).

To check whether they treat the organizer as 'busy' publish your  
calendar as a freebusy file. It should _not_ contain the events where  
you are just an organizer but no attendee. (AFAIK iCal doesn't  
support freebusy, so you can only check with Outlook).

Greets,
   Helge

PS: people also often mix up the 'organizer' with the attendee with  
the role 'chair'. Different things in iCal (and often in real world).
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Aug 18 16:56:58 2005

Hi Helge,

--On August 19, 2005 1:25:58 AM +0200 Helge Hess 
<[email-masked]> wrote:

> you are just an organizer but no attendee. (AFAIK iCal doesn't  support
> freebusy, so you can only check with Outlook).

Hang on - this is mixing the concept of free busy time calculation with 
whether an organiser is implicitly an attendee. From my reading of 2445 the 
ONLY property that is used to determine free-busy state is the TRANSP 
property - whether or not you are listed as an ATTENDEE or ORGANIZER is 
irrelevant. So I think your assertion above is wrong unless 
TRANSP:TRANSPARENT is specified in the event.

One could certainly make the case that an 'organised' event at which you 
are not an attendee should by default be transparent - but the client ought 
to use the TRANSP property to explicitly set that rather than infer it when 
TRANSP is not present.

-- 
Cyrus Daboo

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Aug 18 18:36:36 2005

At 7:56 PM -0400 8/18/05, Cyrus Daboo wrote:
>Hang on - this is mixing the concept of free busy time calculation 
>with whether an organiser is implicitly an attendee. From my reading 
>of 2445 the ONLY property that is used to determine free-busy state 
>is the TRANSP property - whether or not you are listed as an 
>ATTENDEE or ORGANIZER is irrelevant. So I think your assertion above 
>is wrong unless TRANSP:TRANSPARENT is specified in the event.

This would be correct if the TRANSP property MUST be specified in a 
VEVENT.  But 2445 explicitly says TRANSP is optional.  Moreover the 
description of VEVENT suggests that absent a TRANSP property, TRANSP 
= OPAQUE.  But the language is not explicit.

It seems to me that TRANSP=OPAQUE should be the default, because it's 
probably most often the case that organizers are also attendees. 
There are classic exceptions to this, I know. (I would leave handling 
this to implementor.)  I suggest that 2445bis always make the default 
state of TRANSP = OPAQUE, rather than have its state depend on the 
inclusion of ATTENDEE and/or ORGANIZER properties.

>
>One could certainly make the case that an 'organised' event at which 
>you are not an attendee should by default be transparent - but the 
>client ought to use the TRANSP property to explicitly set that 
>rather than infer it when TRANSP is not present.

One could.  But one ought not. :-)  I certainly agree that including 
it removes any ambiguity.  But I can't quite convince myself TRANSP 
MUST occur.  As long as the default is clear, I'd rather save the 
bits on the wire - call me old-fashioned. :-)

-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung:
   Wir m?ssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Aug 18 18:56:02 2005

Ah <sheepish grin>, OPAQUE is already the default....Nevermind...

At 6:35 PM -0700 8/18/05, John W Noerenberg II wrote:
>It seems to me that TRANSP=OPAQUE should be the default, because 
>it's probably most often the case that organizers are also 
>attendees. There are classic exceptions to this, I know. (I would 
>leave handling this to implementor.)  I suggest that 2445bis always 
>make the default state of TRANSP = OPAQUE, rather than have its 
>state depend on the inclusion of ATTENDEE and/or ORGANIZER 
>properties.

<mutter><mutter><mutter>

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Aug 18 19:10:28 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050818/92c1f5d9/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Aug 18 19:22:40 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050818/36e70d6f/smime.bin

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Aug 18 20:47:09 2005

At 8:10 PM -0600 8/18/05, Doug Royer wrote:
>
>TRANSP is for the VEVENT, not the ORGANIZER.

You are exactly right.

At 8:22 PM -0600 8/18/05, Doug Royer wrote:
>The issue is: Should your CUA show VEVENTs where you are not attending
>and are the ORGANIZER?
>
>If it does, and if the VEVENT is tagged as OPAQUE, then it is an
>OPAQUE VEVENT. And OPAQUE means found in busy searches.

Yup.  Restating the question:  Should your CUA show OPAQUE VEVENTs 
when you are not an ATTENDEE but are the ORGANIZER?

>
>iCal is for exchanging information between CUA's.

Well, iCalendar is for exchanging information between calendars, not CUAs.

>Most CUAs use it as the storage format.

Perhaps.  It is an implementation choice.  I won't hazard an opinion 
whether it is a good choice. :-)

>  It looks to me as if your CUA correctly told the recipients of the 
>VEVENT that it is OPAQUE.

I can't agree with this.  The CUA is part of the calendar software 
for managing a user's calendar.  But it is not *all* of the calendar 
software.

I claim that how this question is answered is a matter for the 
implementor, so how the calendar software interprets the properties 
is beyond our scope.  For example, the user may instruct the calendar 
software to regard an OPAQUE VEVENT for which the user is an 
ORGANIZER but not an ATTENDEE as FREE time for the user.  So a query 
for the user's free/busy time, would report the time spanned by the 
VEVENT as FREE.  However, a query for VEVENTs that span the time 
specified for the OPAQUE VEVENT would return this OPAQUE VEVENT in 
the list of VEVENTs satisfying the conditions of the query.  Bear in 
mind the source of the query may be the user's CUA or it may be some 
other object capable of querying the user's calendar.  The source of 
the query really doesn't matter, as far as this discussion goes.

As a user of the calendar software I may want to know about the 
events I've scheduled regardless of whether I'm an attendee; or I may 
want to know about the events for which I'm an attendee.

As a user of the calendar software I may want to know about the 
events my secretary has scheduled (if I'm a control freak); or I may 
want to know about the events those who report to me are attending 
(if I'm a control monster). :-)

-- 

john noerenberg

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Aug 19 03:10:09 2005

> when you are not an ATTENDEE but are the ORGANIZER?

I still think the discussion is going in the wrong direction. What the 
CUA shows is a view thing and to be decided by the CUA, its not 
standardized in the iCal spec. Most CUAs store arbitary collections of 
events and show _all_ of them, even if you are neither an organizer nor 
an attendee. And this is actually required for shared folders since you 
want to see items in other people calendars even if you are not a 
participant.

So some CUA may show organizer events, maybe tagged with some icon or 
allow some filtering ("show events organized by me"), etc. Plenty of 
freedom for the client to show the contained information in useful and 
innovative ways.

The important thing is how to calculate the freebusy information and 
this is specified in iCal. It involves both, processing the attendee's 
and the TRANSP field since it is associated with some specific user:
---snip---
When used to publish busy time, the "ORGANIZER" property specifies
the calendar user associated with the published busy time
---snap---
So while your local calendar can store arbitary events, a published vfb 
entity is bound to some user. This is after all necessary to be able to 
process the data inside when the vfb is retrieved!
I agree that the spec isn't perfectly clear about that, but as far as I 
can see this is the only useful interpretation?

On Aug 19, 2005, at 1:56, Cyrus Daboo wrote:
> of 2445 the ONLY property that is used to determine free-busy state is 
> the TRANSP property - whether or not you are listed as an ATTENDEE or 
> ORGANIZER is irrelevant. So I think your assertion above is wrong 
> unless TRANSP:TRANSPARENT is specified in the event.

That doesn't make a lot of sense to me. In what real-world situation 
would a freebusy entry not be bound to a specific attendee? What would 
a vfb consumer do with such a file?

> client ought to use the TRANSP property to explicitly set that rather 
> than infer it when TRANSP is not present.

I interpret the TRANSP property as an additional property to consider 
whether the event is free or busy. Eg a 'birthday event' would be 
marked transparent and not show up as busy, even if the the calendar 
user is an attendee.

Greets,
   Helge

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Aug 19 07:01:00 2005

Hi Helge,

--On August 19, 2005 12:11:29 PM +0200 Helge Hess 
<[email-masked]> wrote:

> would a freebusy entry not be bound to a specific attendee? What would a
> vfb consumer do with such a file?

VFREEBUSY components are obviously a different matter - I've was describing 
the behaviour for VEVENT components.

> whether the event is free or busy. Eg a 'birthday event' would be marked
> transparent and not show up as busy, even if the the calendar user is an
> attendee.

OK, I think its clear that 2445bis needs to say a lot more about what 
components/properties imply busy time for the 'owner' of the calendar 
containing the components. Here's an attempt at this:

+-------------------------------------------------------------+
|           | ORGANIZER/ATTENDEE | TRANSP       | Free/Busy   |
|           +====================+==============+=============+
|           |                    |              |             |
|           | No ORGANIZER       | Not present  | Busy        |
|           | or ATTENDEE        | TRANSPARENT  | Free        |
|           |                    | OPAQUE       | Busy        |
|           |                    |              |             |
|           +--------------------+--------------+-------------+
|           |                    |              |             |
| VEVENT    | ATTENDEE           | Not present  | Busy        |
|           | matching 'owner'   | TRANSPARENT  | Free        |
|           |                    | OPAQUE       | Busy        |
|           |                    |              |             |
|           +--------------------+--------------+-------------+
|           |                    |              |             |
|           | ORGANIZER          | Not present  | Free        |
|           | matching 'owner'   | TRANSPARENT  | Free        |
|           | no matching        | OPAQUE       | Busy        |
|           | ATTENDEE           |              |             |
|           |                    |              |             |
+-----------+--------------------+--------------+-------------+

+-------------------------------------------------------------+
|           | iTIP                  | Contributes to 'owners' |
|           |                       | free/busy               |
|           +=======================+=========================+
|           |                       |                         |
|           | No ORGANIZER          | Yes                     |
|           | or ATTENDEE           |                         |
|           | (not iTIP)            |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | REPLY ATTENDEE        | Yes                     |
|           | matching 'owner'      |                         |
|           | (see Notes 2 & 3)     |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
| VFREEBUSY | REPLY ATTENDEE not    | No                      |
|           | matching 'owner'      |                         |
|           | (see Note 2)          |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | PUBLISH ORGANIZER     | Yes                     |
|           | matching 'owner'      |                         |
|           | (see Note 1)          |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | PUBLISH ORGANIZER     | No                      |
|           | not matching 'owner'  |                         |
|           | (see Note 1)          |                         |
|           |                       |                         |
+-----------+-----------------------+-------------------------+

        Notes:

        1. PUBLISH'ed VFREEBUSY cannot contain ATTENDEEs,
        only ORGANIZER.

        2. The ORGANIZER in a REQUEST/REPLY iTIP exchange
        is irrelevant for purposes of free busy 'ownership'.

        3. Its not clear why an 'owner' would have their own
        REPLY in their calendar.

-- 
Cyrus Daboo

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Aug 19 07:55:42 2005

On 19. Aug 2005, at 16:00 Uhr, Cyrus Daboo wrote:
> VFREEBUSY components are obviously a different matter - I've was  
> describing the behaviour for VEVENT components.

Ah, OK, I see what you mean now ;-) Yes, I agree then, the freebusy  
marker in the context of the VEVENT is just the TRANSP.

But then the only purpose of this marker is to generate a VFREEBUSY  
(or some similiar internal object representation) from the VEVENT?!  
It doesn't have a lot of value to display this attribute in the CUA  
since the availability of someone must be based on the VFREEBUSY  
information anyway.

However, this still doesn't have anything to do with the question of  
the original poster (subject) though this started an impressive  
thread ;-)
I hope we all agree the the ORGANIZER is *not* an ATTENDEE in any  
case and MUST be listed as an ATTENDEE if he intends to take part in  
the timeslot?

>> marked
> OK, I think its clear that 2445bis needs to say a lot more about  
> what components/properties imply busy time for the 'owner' of the  
> calendar containing the components. Here's an attempt at this:
>
>

Honestly I cannot follow this table. What is the "Free/Busy" column  
used for in the context of the operation of a CUA?

During event scheduling we will always need to retrieve the VFREEBUSY  
which is based on the ATTENDEE (+ the TRANSP).

Thanks,
   Helge

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Fri Aug 19 09:56:55 2005

Helge: The availability of a calendar user is based foremost on the 
VEVENTs, actually.  The CUA creates VEVENT objects and can then 
calculate free-busy time from those.  The only time you need VFREEBUSY 
is
   - to send free-busy time rollups over the wire
   - to export (or import) or send a blocked-out period of time that 
isn't an event

So in CalDAV, for example, we'd expect >90% of the components in a 
calendar would be VEVENT components, and only a few would be VFREEBUSY 
components stored to block out un-schedulable time (many users/CUAs 
might not have any VFREEBUSY components created).  The CalDAV server 
calculates what times are free and busy (for the REPORT) by using both 
VEVENTs and VFREEBUSYs.

Cyrus: This table does look like the kind of thing we need in the 
revised 2445 only it is less readable than I'd hope -- I'd start by 
removing the first column and using VEVENT or VFREEBUSY as a title 
instead of a first column.  Maybe then organizer and transparency could 
be the X and Y axes instead of both being in columns.

Also, wouldn't TRANSPARENT Not Present be the same as 
TRANSPARENT=OPAQUE in every case?

Lisa

On Aug 19, 2005, at 7:55 AM, Helge Hess wrote:

> (or some similiar internal object representation) from the VEVENT?! It 
> doesn't have a lot of value to display this attribute in the CUA since 
> the availability of someone must be based on the VFREEBUSY information 
> anyway.
>
>
> the original poster (subject) though this started an impressive thread 
> ;-)
> I hope we all agree the the ORGANIZER is *not* an ATTENDEE in any case 
> and MUST be listed as an ATTENDEE if he intends to take part in the 
> timeslot?
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 19 11:30:29 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/076d85be/smime.bin

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Fri Aug 19 11:41:56 2005

At 12:11 PM +0200 8/19/05, Helge Hess wrote:
>I still think the discussion is going in the wrong direction. What 
>the CUA shows is a view thing and to be decided by the CUA, its not 
>standardized in the iCal spec.

Exactly so.

>Most CUAs store arbitary collections of events and show _all_ of 
>them, even if you are neither an organizer nor an attendee.

What any particular CUA does is an implementation choice.  Even if I 
agree with you (and I'm inclined to agree - not that I think it's 
correct) that most show *all* events regardless of the value of 
ORGANIZER and ATTENDEE, that doesn't necessarily mean the protocol 
demands this.  So this second statement is not relevant in light of 
your first comment.

>And this is actually required for shared folders since you want to 
>see items in other people calendars even if you are not a 
>participant.

Well, just because user2 wants to see events in user1's calendar, 
there's no stipulation that user1 agrees.  But this takes us way far 
afield of the original question.

>this is specified in iCal. It involves both, processing the 
>attendee's and the TRANSP field since it is associated with some 
>specific user:

Agreed.

>the calendar user associated with the published busy time

Oh my goodness! Yes, this is what 2445 4.6.4 says.  I'm not sure 
about this...<sigh>... Well, 2445 is just a PROPOSED protocol. 
What's going on in this section needs some careful thought - more 
than I've given it.

>---snap---
>So while your local calendar can store arbitary events, a published 
>vfb entity is bound to some user. This is after all necessary to be 
>able to process the data inside when the vfb is retrieved!

Yes, but the only users to which it should be bound are ATTENDEEs.

>I agree that the spec isn't perfectly clear about that, but as far 
>as I can see this is the only useful interpretation?

"isn't perfectly clear" is a generous description imho. :-)  The way 
in which 4.6.4 describes the use of ORGANIZER for publishing 
VFREEBUSY components conflicts with the way in which ORGANIZER is 
used in VEVENTSs.  This seems like a very bad idea.

-- 
john noerenberg
[email-masked]
   --------------------------------------------------------------------
   We all learn here by the honorable path of horrible mistakes.
   -- Katherine Paterson, "The Master Puppeteer," 1975
   --------------------------------------------------------------------

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 19 11:56:23 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/3a2a3c41/smime-0001.bin