Subject: [Ietf-calsify] How to derive FREEBUSY;FBTYPE from a VEVENT?

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Fri Oct 28 07:30:47 2005

The FBTYPE parameter of FREEBUSY properties of VFREEBUSY components
can take one of the following values:

  - FREE
  - BUSY
  - BUSY-UNAVAILABLE
  - BUSY-TENTATIVE
  - x-name

How can a calendar application (e.g., CalDAV Server) derive the
proper FBTYPE value from a given VEVENT?

Assuming that the FBTYPE parameter of the FREEBUSY property of
a VFREEBUSY component should be derived from the TRANSP and
STATUS properties of the VEVENT component, does the following
table make sense?

     +---------------------------++------------------+
     |          VEVENT           || VFREEBUSY        |
     +-------------+-------------++------------------+
     | TRANSP      | STATUS      || FBTYPE           |
     +=============+=============++==================+
     | TRANSPARENT | <Any value> || FREE             |
     +-------------+-------------++------------------+
     |             | CANCELLED   || FREE             |
     |             +-------------++------------------+
     |             | <Undefined> || BUSY             |
     | OPAQUE      | CONFIRMED   ||                  |
     | <Undefined> +-------------++------------------+
     |             |    ???      || BUSY-UNAVAILABLE |
     |             +-------------++------------------+
     |             | TENTATIVE   || BUSY-TENTATIVE   |
     +-------------+-------------++------------------+

When would a calendar application derive FBTYPE=BUSY-UNAVAILABLE ?

When would a calendar application derive FBTYPE=x-name ?

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Oct 28 07:52:14 2005

Hi Bernard,

> When would a calendar application derive FBTYPE=x-name ?

I don't think either of these should ever be 'derived' from a VEVENT. 
Rather, if a user wants to specify those, they directly create a VFREEBUSY 
object in their calendar and use that.

That said, I certainly would like to see a table like the one you created 
appearing in either 2445bis or 2446bis.

One other thing that came up as I reviewed this: its not totally clear to 
me how free-busy is supposed to work with all day events. If I have an all 
day event marked with TRANSP=OPAQUE, should the FREEBUSY property specify a 
date-time or a date only? 2445 only seems to show timed cases and kind of 
implies that times are always required. Can this be clarified?

-- 
Cyrus Daboo

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 28 13:12:40 2005

Cyrus Daboo wrote:

> 
> One other thing that came up as I reviewed this: its not totally clear 
> to me how free-busy is supposed to work with all day events. If I have 
> an all day event marked with TRANSP=OPAQUE, should the FREEBUSY property 
> specify a date-time or a date only? 2445 only seems to show timed cases 
> and kind of implies that times are always required. Can this be clarified?

The ABNF in 2445 says:

fbvalue    = period *["," period]
      ;Time value MUST be in the UTC time format.

And:

      period     = period-explicit / period-start

      period-explicit = date-time "/" date-time
      ; [ISO 8601] complete representation basic format for a period of
      ; time consisting of a start and end. The start MUST be before the
      ; end.

      period-start = date-time "/" dur-value
      ; [ISO 8601] complete representation basic format for a period of
      ; time consisting of a start and positive duration of time.

The FREEBUSY property is a date-time only value in UTC. And 'period'
can not be a 'date' only value.

The reason that it is in UTC, is that the VREEBUSY property
only exists in a VFREEBUSY component, and a VFREEBUSY component
does not contain a VTIMEZONE component.

So without it being a UTC date/time value, it would be impossible
to determine what slice is busy across time zones for an 'all-day'
event in the ORGANIZERS unspecified time zone .

-- 

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

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051028/11212121/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 28 13:31:37 2005

Cyrus Daboo wrote:

> Rather, if a user wants to specify those, they directly create a 
> VFREEBUSY object in their calendar and use that.

I agree. An event could exist that if happens, I NEED to be there,
so I would mark MY time as BUSY. And have it in my calendar.

Other events could be likely to occur, yet I am not sure I will attend
and I would NOT mark MY time as BUSY. And have it in my calendar.

While both of the above VEVENTs from the ORGANIZER could have the TRANSP
property set to OPAQUE - meaning that it consumes time when booked
by the ATTENDEE.  So the ORGANIZER in both cases is saying this is
an OPAQUE VEVENT, if you decide to that you will be using that time
for that reason.

I can have the Dallas Cowboys football team on my calendar. Each game
could have a TRANSP:OPAQUE property because that is what I imported
from their web page ICS file.. Yet I will not be attending. I may
wish to just watch it on TV if I am not otherwise busy. So I would
mark that time as FREE and still have it on my calendar. I also may
have the super bowl game marked as BUSY even when I will not be
attending.

I do not think that you can have a table that says if TRANSP is OPAQUE
then the time MUST BE BUSY, even if on my calendar.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051028/20340a18/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Oct 28 14:06:02 2005

Am Freitag, 28. Oktober 2005 22:31 schrieb Doug Royer:
> from their web page ICS file.. 

Just because you got a calendar with "wrong" settings, doesn't mean the 
standard needs to support this...
The TRANSP needs to be used for automatic F/B creation, since that's the only 
hint a GW server (or a fat client) has about which time is free and which is 
busy.

> Yet I will not be attending. I may 
> wish to just watch it on TV if I am not otherwise busy. 

"Attending" doesn't necessarily mean that you are there. You can also attend 
via TV etc. All that's important is if you want to mark that time as free or 
not.

> So I would 
> mark that time as FREE and still have it on my calendar. 

Yes, TRANSP:FREE. Nobody stops you from modifying that football game from 
OPAQUE to FREE.

> I also may 

Sure, TRANSP:OPAQUE
Most calendaring apps (at least korganizer and evolution) let you select if 
the time of the event should be marked as busy or as free.

> then the time MUST BE BUSY, even if on my calendar.

RFC 2445 says: 
   Events that consume actual time for the individual or resource associated
   with the calendar SHOULD be recorded as OPAQUE, allowing them to be
   detected by free-busy time searches. Other events, which do not take
   up the individual's (or resource's) time SHOULD be recorded as
   TRANSPARENT, making them invisible to free-busy time searches.

So, you are right, it's not a MUST, "only" a SHOULD... Basically that 
paragraph says that there is a 1:1 correspondence.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer maintainer

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Oct 28 14:57:46 2005

> The TRANSP needs to be used for automatic F/B creation,

I disagree that it is a 'NEED'.

> since that's the only 

I do agree that it is a 'HINT'.

It is not the wrong settings. The ORGANIZER of the Dallas Cowboys
football team could in fact set and want it to be TRANSP:OPAQUE
because the game consumes time.

I do want my time to be FREE for the game because I will
not be attending, and because I want work to be able to book
that time in my calendar.

TRANSP:OPAQUE is what the ORGANIZER sent, it does not force
me to be busy simply because I have it on my calendar. It means
that -IF- I accept it as more important than work this
time, then I am BUSY.

FREEBUSY is for the calendar, not always the ORGANIZER and
not always a specific ATTENDEE.

It is also possible that I got a METHOD:REQUEST + TRANSP:OPAQUE
+ STATUS:CONFIRMED component and I want in my calendar even
when I sent a PARTSTAT=DECLINED METHOD:REPLY. My time is NOT
busy for that meeting that I decline to attend. While at the
same time having that entry in my calendar as I need to know
that a meeting is taking place.

Only the owner of the calendar knows if the time is booked
or FYI for a specific calendar.

A specific implementation might want to automate it as
you state above. However I will not be BUSY just because a I
have an iMIP vevent for a TV show entry from a calendar where
the entry is OPAQUE.

I can also come up with cases where OPAQUE always
means BUSY - a resource calendar for example. So I agree that
some implementation may want to automate the BUSY time. I disagree
that that the ORGANIZER always gets to mandate if I am BUSY.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4532 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20051028/67759bbc/smime-0001.bin