[Ietf-calsify] Recommendationsfor strippingdown iCaltoa manageable 'standard'

Anil SRIVASTAVA Anil.Srivastava at Sun.COM
Sat Oct 29 08:43:55 PDT 2005


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


More information about the Ietf-calsify mailing list