[Ietf-calsify] Question on VFREEBUSY

[Lisa Dusseault]

These are good questions... my gut feel is that we certainly need 
separate documents, perhaps more separate documents than we already 
have.  In practice, iCalendar is used for 3 separate purposes:
  - import and export -- where you don't worry about saving VFREEBUSY 
information that duplicates event start/end times
  - invitation
  - CalDAV (or other access/sharing)

The CalDAV spec already has and requires some guidance on how to use 
parts of iCalendar in that context, and iTIP has some guidance for how 
to use iCalendar for invitation workflow, but I'm unaware of specific 
guidance for import/export even though that should probably exist (any 
volunteers?).  There are probably minor areas of iTIP workflow and 
iCalendar usage where we can make the separation cleaner, but as a 
basic document structure it's always seemed sensible to me the way the 
documents are divided.

Still, if anybody has other proposals for how the information should be 
factored into documents (or major sections within docs), speak up early 
rather than late.

Lisa

On Sep 2, 2005, at 1:55 PM, Doug Royer wrote:

>
> The original idea was that 2445 was the object dictionary.
> And 2446 was how to use 2445 objects. Many implementations
> ignore 2446 and just send 2445 objects and they ignore the
> 2446 restrictions.
>
> I agree with you. Bruce fought very hard to keep VFREEBUSY
> from being different than a 100% mapping of OPAQUE components
> in a calendar. So there was no point in having them in a 2445 object
> as the 2445 objects had exactly the same OPAQUE time blocks.
>
> VFREEBUSY existed so that you could make quick guess as to when
> someone was available.
>
> Your supposed to publish both your calendar and your VFREEBUSY
> calendars. Almost no one does that.
>
>
> Cyrus Daboo wrote:
>> Hi folks,
>> According to 2445 VFREEBUSY components are only supposed to be used 
>> in iTIP publish/request/reply methods. For some reason I was under 
>> the impression that I could use VFREEBUSY in a 'regular' calendar to 
>> indicate my own busy time without having to create a 'dummy' event to 
>> block out the time. What do other people think about the use of 
>> VFREEBUSY?
>> If its really the case that VFREEBUSY is only used by iTIP, then 
>> would it not make sense to move it to the iTIP bis document and drop 
>> it from 2445bis? That would remove VFREEBUSY and the FREEBUSY 
>> property from 2445bis.
>
> Is what is really the case is that ALL of 2445 is supposed to be used
> in iTIP only. Almost all calendar implementations out there PUBLISH
> their calendars, and yet do not add the METHOD:PUBLISH property and
> value.
>
>> Another thing: the FREEBUSY property contains three 'busy' types: 
>> BUSY, BUSY-TENTATIVE and BUSY-UNAVAILABLE. The first two are fairly 
>> easy to understand - they are based on the STATUS of VEVENTs within 
>> the busy-time period request. However, I can't see how a calendar 
>> user is supposed to indicate BUSY-UNAVAILABLE in their own calendar 
>> so that busy-time requests will generate that. That is, unless 
>> VFREEBUSY components could be created in 'regular' calendars in which 
>> case BUSY-UNAVAILABLE could be set and returned.
>
>
> BUSY-UNAVAILABE - example: Non-working hours. No VEVENT associated
> with it at all. They are not useless. And I agree with you that
> they should not be tied 100% to OPAQUE components in the calendar.
>
>
> So, should 2445 remain the data dictionary Or does it become a
> standalone document? If standalone I think you will find MANY issues
> like this that will force 2445 and 2446 to have a lot of rewrite.
>
>
>
> -- 
>
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
> <Doug.vcf>_______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify