[Ietf-calsify] Transparency, status, attendance and free-busy interactions

Lisa Dusseault lisa at osafoundation.org
Sat Oct 29 09:02:04 PDT 2005


Part of the iCalendar model confusion here is whether the VEVENT  
component is part of a personal calendar, or part of a shared  
repository of events.

In the case where VEVENTs are in a personal calendar, stored only on my  
machine (or on a server where other agents don't view the event as part  
of their calendar), then in that context it would be reasonable to  
model free-busy as being independent from attendance.    In this  
model/context:
  - Any event in a personal calendar that is confirmed and opaque would  
affect free-busy.
  - Even if there is no attendance list, it's on the personal calendar  
and opacity means it affects free-busy.
  - If there is an attendance list, and the user is not on that list,  
it's still on their personal calendar and thus opacity means it affects  
free-busy.
I believe this is the way most personal calendars work today, importing  
ICS files or storing data in ICS files locally or via WebCAL.

In the case where VEVENTs are in a shared repository, where multiple  
individuals view the same component, now attendance would affect  
free-busy.
  - If the user shows up as an attendee, and the event is confirmed, and  
the event is opaque, this would affect free-busy
  - Possibly opacity and status should be per-user properties.  Several  
attendees of a meeting might be in different stages of invitations --  
some confirmed, some only tentative.
I believe some shared calendar servers do work this way today and they  
should describe what they've actually implemented and what that means  
for iCalendar.

But what context dependencies mean for the overall discussion is that  
we can't discuss what free-busy means independent of context.  It may  
be very difficult to standardize this in just one way in RFC2445 bis  
and we should keep in mind other possibilities.  For example, we could  
split RFC2445 bis into several sections/documents
   1. the base format, used in many contexts
   2.  what different elements of the base format mean in import/export  
of ICS files for personal calendars
   3.  what different elements of the base format mean in iTIP usage

Lisa


On Oct 29, 2005, at 8:43 AM, Anil SRIVASTAVA wrote:

> On 2005-10-28/23:43 [-0400], bernard.desruisseaux at oracle.com  
> [Bernard...:
>
>> Carol,
>>
>> The table I posted in a separate thread was built with the
>> assumption that the "TENTATIVE" part in "BUSY-TENTATIVE" was
>> derived from STATUS:TENTATIVE based on the following information:
>>
>> RFC 2445, section 4.2.9 Free/Busy Time Type:
>>
>>  The value BUSY-TENTATIVE indicates that the time interval is busy
>>  because one or more events have been *tentatively scheduled* for
>>  that interval.
>>
>> RFC 2445, section 4.8.1.11 Status:
>>
>>  Description: In a group scheduled calendar component, the property is
>>  used by the "Organizer" to provide a confirmation of the event to the
>>  "Attendees". For example in a "VEVENT" calendar component, the
>>  "Organizer" can indicate that a meeting is tentative, confirmed or
>>  cancelled.
>>
>> You may ask "But what if I tentatively accepted the event?" (i.e.,
>> you set PARTSTAT=TENTATIVE on *your* ATTENDEE property). Shouldn't
>> the derived FBTYPE be BUSY-TENTATIVE even though the event might
>> have been confirmed by the Organizer (i.e., STATUS:CONFIRMED)?
>> It seems not.
>
> That being the case, I think it is clearly broken.  The attendees
> individual acceptance status has to play a role in the dynamically
> generated FB time.  If an attendee has not accepted the event or
> declined it, then clearly they are not attending the meeting the
> organizer put together and are therefor available.
>
> PARTSTAT of an attendee should take precedence over the STATUS  
> property.
>
>
> Anil
>
>>
>> Section 4.8.1.11 makes me believe that an attendee would not change
>> the value of the STATUS property set by the Organizer (i.e., "the
>> property is used by the Organizer..."). But I don't believe it is
>> the case for the TRANSP property given that its purpose is to "define
>> whether an event is transparent or not to busy time searches" on a
>> calendar. The same way you would ignore/modify the VALARM that you
>> would receive from the Organizer, you would also ignore/modify the
>> value of the TRANSP property as you wish.
>>
>> Cheers,
>> Bernard
>>
>> Carol Tsai wrote:
>>
>>> Hi Cameron,
>>>
>>> I was researching on how to create an iCal that has the show as time
>>> be Tentative when I came accross your posting
>>> (http://lists.osafoundation.org/pipermail/ietf-calsify/2004-August/ 
>>> 000050.html).
>>> I was wondering if you received a reply to that? I agree that the
>>> TRANSP property doesn't seem to have a Tentative option.
>>>
>>> Carol Tsai
>>>
>>> REARDEN commerce 1400 Fashion Island Blvd Suite 150 San Mateo Ca
>>> 94404
>>>
>>> T 650 212 8474 F 650 212 8499
>>>
>>> www.reardencommerce.com <http://www.reardencommerce.com>
>>>
>>> _______________________________________________ Ietf-calsify mailing
>>> list Ietf-calsify at osafoundation.org
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>
> -- 
> _______________
> Anil SRIVASTAVA
> anil.srivastava at Sun.COM
> _______________________________________________
> Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav



More information about the Ietf-calsify mailing list