Subject: [Ietf-calsify] Question on VFREEBUSY

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Sep 2 07:34:57 2005

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.

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.

-- 
Cyrus Daboo

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Sep 2 13:55: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/20050902/21392a8b/smime.bin

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Fri Sep 2 14:51:41 2005

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Sep 2 20:32:39 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050902/afb9d431/smime-0001.bin

---

From: timi.soinio at nokia.com (Timi Soinio)
Date: Sun Sep 4 23:02:32 2005

> - CalDAV (or other access/sharing)

In addition to these three usage purposes, I would also consider 
synchronization (with e.g. OMA DS) as a fourth important purpose for 
using iCalendar. Technically, it resembles import and export cases but 
it can contain some iCal properties that normally are left out from 
simple import/export (PUBLISH?) cases, e.g. ATTENDEE information.

-Timi

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 5 11:09:13 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050905/d48918b9/smime.bin

---

From: TimHare at comcast.net (Tim Hare)
Date: Mon Sep 5 15:42:50 2005

I think if we are going to discuss sync we need a draft which documents how 
we can fit with SyncML or other generalized synchronization efforts to 
avoid reinventing the wheel.

At 02:08 PM 9/5/2005, Doug Royer wrote:

>In addition to those, synchronization information needs to
>be defined. As how to merge if both sides edited the same
>VEVENT.
>
>This is not a calsify issue as it has not been covered in any
>spec I have seen. I think this would have to be a new draft.
>
>
>Timi Soinio wrote:
>>using iCalendar. Technically, it resembles import and export cases but it 
>>can contain some iCal properties that normally are left out from simple 
>>import/export (PUBLISH?) cases, e.g. ATTENDEE information.
>>-Timi
>>_______________________________________________
>_______________________________________________

Tim Hare
Interested Bystander, Non-Inc.