Subject: Clarification for Free/Busy

From: "V. Oliver" <[email-masked]>
Date: Mon, 24 Nov 2003 09:52:40 -0800

I am hoping that someone can clarify how to map from a VEVENT component's properties to what should be returned for a Free/Busy request. 
 
RFC 2445 states unambiguously that TRANSP is the property that is to be used to return Free/Busy status. From "4.8.2.7 Time Transparency":
 
Description: Time Transparency is the characteristic of an event that
   determines whether it appears to consume time on a calendar. 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.

This seems clear until I read the description of the free busy time type parameter, FBTYPE (a parameter of FREEBUSY, which is a property of a VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype):
 
Description: The parameter specifies the free or busy time type. The
   value FREE indicates that the time interval is free for scheduling.
   The value BUSY indicates that the time interval is busy because one
   or more events have been scheduled for that interval. The value
   BUSY-UNAVAILABLE indicates that the time interval is busy and that
   the interval can not be scheduled. The value BUSY-TENTATIVE indicates
   that the time interval is busy because one or more events have been
   tentatively scheduled for that interval. If not specified on a
   property that allows this parameter, the default is BUSY.
 
The above clearly states that there are four (4) levels of free/busy:
 
FREE 
BUSY
BUSY-UNAVAILABLE 
BUSY-TENTATIVE
 
What I'm missing is a way to map from an Event's TRANSP property which has only two states (FREE or BUSY) to these four states. 
 
Is the intention that free/busy should be reported by combining TRANSP with some other property or properties? If I just look at the value "tentative", I see that there are actually two places in an Event where I could potentially derive that value: PARTSTAT and STATUS. I don't see any explicit instruction in RFC 2445 for this.
 
Let me rephrase this a bit in the hope of getting a more exact answer. And instead of looking at a VEVENT and deciding what the FBTYPE should be, can we look at what the desired FBTYPE is and work backwards?
 
What does the VEVENT look like that would generate, for example, the following property in a VFREEBUSY component:
 
FREEBUSY;FBTYPE=BUSY-TENTATIVE:20031201T130000Z/20031201T140000Z
 
or to get even more explicit let's take several cases:
 
1. An attendee has been invited to an event and replied with a tentative acceptance. What does the Attendee's copy of that VEVENT look like in order to return 
 FREEBUSY;FBTYPE=BUSY-TENTATIVE:<dates>
 
2. An attendee has been invited to an event and replied with a decline. If the attendee retains that event (maybe he want to be able to change his mind later?), what does his copy of that VEVENT look like? I assume that he should report that timeslot as being "FREE": 
 FREEBUSY;FBTYPE=FREE:<dates>
 
3. An attendee has been invited to an event and replied with an acceptance. The organizer has then canceled the event, but the Attendee retains a copy (for whatever reason). What does the Attendee's copy of that VEVENT look like in order to return 
 FREEBUSY;FBTYPE=FREE:<dates>
 
4. What does anyone's (organizer or attendee) VEVENT copy look like to generate:
 FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:<dates>

In case it's not clear, I'm looking for someone to help me out by telling me that the associated VEVENT would look like:
 
TRANSP:<value>
STATUS:<value>
ATTENDEE:<whatever>
 
or any appropriate fields and values that are involved.

I'd appreciate any help the list can give.

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Nov 2003 14:04:44 -0700

V. Oliver wrote:

> I am hoping that someone can clarify how to map from a VEVENT 
> component's properties to what should be returned for a Free/Busy 
> request.
>  
> RFC 2445 states unambiguously that TRANSP is the property that is to 
> be used to return Free/Busy status. From "4.8.2.7 Time Transparency":
>  

SHOULD means you can break the rule if you want.
MUST means you can not break the rule and be compliant.

> This seems clear until I read the description of the free busy time 
> type parameter, FBTYPE (a parameter of FREEBUSY, which is a property 
> of a VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype):
>  
> What I'm missing is a way to map from an Event's TRANSP property which 
> has only two states (FREE or BUSY) to these four states.

It is not a 1:1 mapping.  That is a time can be marked as BUSY in the 
FREEBUSY reply
and not have an entry in the calendar. That is the issue at the heart of 
the debate about always
automatically returning the CALID busy time and not the CU busy time.

There is also the STATUS property that may help.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: Tim Hare <[email-masked]>
Date: Mon, 24 Nov 2003 23:10:32 -0500

One mapping that makes sense to me in my reading of RFC 2445 (others
might disagree) - hope the tabs format this correctly:

|  STATUS
of
VEVENT                             |

VEVENT in period
|
TENTATIVE             |
CONFIRMED             |
CANCELLED     | not there

abd
TRANSP             |                       |                       |               |

===============        |=================      |=================      |===========    |==========

No  / (none)
|
FREE                  |
FREE                  |
FREE          |
FREE

Yes/ OPAQUE    |
BUSY-TENTATIVE        |
BUSY-UNAVAILABLE      |
FREE          |
BUSY

Yes/
TRANSPARENT       |
FREE                  |
FREE                  |
FREE          |
FREE

Notice the last line is all "FREE" - this is because
TRANSPARENT is explicitly identified as being transparent to free-busy
searches.

Tim Hare

Interested Bystander, Non-Inc.

At 09:52 AM 11/24/03 -0800, you wrote:

I am
hoping that someone can clarify how to map from a VEVENT component's
properties to what should be returned for a Free/Busy request.

RFC 2445 states unambiguously that TRANSP is
the property that is to be used to return Free/Busy status. From
"4.8.2.7 Time Transparency":

Description: Time Transparency is the
characteristic of an event that

determines whether it appears to consume time on a
calendar. 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.

This seems clear until I read the description of the free busy time type
parameter, FBTYPE (a parameter of FREEBUSY, which is a property of a
VFREEBUSY component). From "4.2.9 Free/Busy Time Type"
(fbtype):

Description: The parameter specifies the free
or busy time type. The

value FREE indicates that the time interval is free
for scheduling.

The value BUSY indicates that the time interval is
busy because one

or more events have been scheduled for that interval.
The value

BUSY-UNAVAILABLE indicates that the time interval is
busy and that

the interval can not be scheduled. The value
BUSY-TENTATIVE indicates

that the time interval is busy because one or more
events have been

tentatively scheduled for that interval. If not
specified on a

property that allows this parameter, the default is
BUSY.

The above clearly states that there are four
(4) levels of free/busy:

FREE

BUSY

BUSY-UNAVAILABLE

BUSY-TENTATIVE

What I'm missing is a way to map from an
Event's TRANSP property which has only two states (FREE or BUSY) to these
four states.

Is the intention that free/busy should be
reported by combining TRANSP with some other property or properties? If I
just look at the value "tentative", I see that there are
actually two places in an Event where I could potentially derive that
value: PARTSTAT and STATUS. I don't see any explicit instruction in RFC
2445 for this.

Let me rephrase this a bit in the hope of
getting a more exact answer. And instead of looking at a VEVENT and
deciding what the FBTYPE should be, can we look at what the desired
FBTYPE is and work backwards?

What does the VEVENT look like that would
generate, for example, the following property in a VFREEBUSY component:

or to get even more explicit let's take several
cases:

1. An attendee has been invited to an event and
replied with a tentative acceptance. What does the Attendee's copy of
that VEVENT look like in order to return

FREEBUSY;FBTYPE=BUSY-TENTATIVE: <dates >

2. An attendee has been invited to an event and
replied with a decline. If the attendee retains that event (maybe he want
to be able to change his mind later?), what does his copy of that VEVENT
look like? I assume that he should report that timeslot as being
"FREE":

FREEBUSY;FBTYPE=FREE: <dates >

3. An attendee has been invited to an event and
replied with an acceptance. The organizer has then canceled the event,
but the Attendee retains a copy (for whatever reason). What does the
Attendee's copy of that VEVENT look like in order to return

FREEBUSY;FBTYPE=FREE: <dates >

4. What does anyone's (organizer or attendee)
VEVENT copy look like to generate:

FREEBUSY;FBTYPE=BUSY-UNAVAILABLE: <dates >

In case it's not clear, I'm looking for someone to help me out by telling
me that the associated VEVENT would look like:

TRANSP: <value >

STATUS: <value >

ATTENDEE: <whatever >

or any appropriate fields and values that are
involved.

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Mon, 24 Nov 2003 22:42:35 -0800 (Pacific Standard Time)

Ah.. the tabs did not do the trick :-); Tim.  I have recreated the
table.  Correct me if it does not look like the way you intended it to
be.

>                 |  STATUS of VEVENT
>                 |
>VEVENT in period | TENTATIVE      | CONFIRMED        | CANCELLED | not there
>and TRANSP       |                |                  |           |
>=================|=====================================================
>No / (none)      | FREE           | FREE             | FREE      | FREE
>Yes/ OPAQUE      | BUSY-TENTATIVE | BUSY-UNAVAILABLE | FREE      | BUSY
>Yes/ TRANSPARENT | FREE           | FREE             | FREE      | FREE
>
>Notice the last line is all "FREE" - this is because TRANSPARENT is
>explicitly identified as being transparent to free-busy searches.

A clarification: by the last 'not there' column you mean an event where
the attendee has 'declined' the invitation, ie. their PARTSTAT in that
event says 'DECLINED'

Anil

On 2003-11-24/23:10 [-0500], [email-masked] [Tim Hare] wrote:

> One mapping that makes sense to me in my reading of RFC 2445 (others might disagree) -
> hope the tabs format this correctly:
>
>                                         |  STATUS of
> VEVENT                             |
>  VEVENT in period       | TENTATIVE             | CONFIRMED             |
> CANCELLED     | not there
>  abd
> TRANSP             |                       |                       |               |
>  No  / (none)                   | FREE                  | FREE                  |
> FREE          | FREE
>  Yes/ OPAQUE    | BUSY-TENTATIVE        | BUSY-UNAVAILABLE      | FREE          | BUSY
>  Yes/ TRANSPARENT       | FREE                  | FREE                  |
> FREE          | FREE
>
> Notice the last line is all "FREE" - this is because TRANSPARENT is explicitly
> identified as being transparent to free-busy searches.
>
> Tim Hare
>       I am hoping that someone can clarify how to map from a VEVENT component's
>       RFC 2445 states unambiguously that TRANSP is the property that is to be
>       used to return Free/Busy status. From "4.8.2.7 Time Transparency":
>        
>       VFREEBUSY component). From "4.2.9 Free/Busy Time Type" (fbtype):
>        
>       What I'm missing is a way to map from an Event's TRANSP property which has
>       only two states (FREE or BUSY) to these four states.
>        
>       Is the intention that free/busy should be reported by combining TRANSP with
>       some other property or properties? If I just look at the value "tentative",
>       I see that there are actually two places in an Event where I could
>       potentially derive that value: PARTSTAT and STATUS. I don't see any
>       explicit instruction in RFC 2445 for this.
>        
>       Let me rephrase this a bit in the hope of getting a more exact answer. And
>       instead of looking at a VEVENT and deciding what the FBTYPE should be, can
>       we look at what the desired FBTYPE is and work backwards?
>        
>       What does the VEVENT look like that would generate, for example, the
>       following property in a VFREEBUSY component:
>        
>       1. An attendee has been invited to an event and replied with a tentative
>       acceptance. What does the Attendee's copy of that VEVENT look like in order
>       to return
>       2. An attendee has been invited to an event and replied with a decline. If
>       the attendee retains that event (maybe he want to be able to change his
>       mind later?), what does his copy of that VEVENT look like? I assume that he
>       should report that timeslot as being "FREE":
>       3. An attendee has been invited to an event and replied with an acceptance.
>       The organizer has then canceled the event, but the Attendee retains a copy
>       (for whatever reason). What does the Attendee's copy of that VEVENT look
>       like in order to return

-- 
__________
Anil SRIVASTAVA
[email-masked]

---

From: Dan Winship <[email-masked]>
Date: Tue, 25 Nov 2003 10:57:17 -0500

> >VEVENT in period | TENTATIVE      | CONFIRMED        | CANCELLED | not there

RFC 2445 says "The value BUSY indicates that the time interval is busy
because one or more events have been scheduled for that interval.
BUSY-UNAVAILABLE indicates that the time interval is busy and that the
interval can not be scheduled." So OPAQUE+CONFIRMED is BUSY, not
BUSY-UNAVAILABLE, since the interval has been scheduled. 

BUSY-UNAVAILABLE is like "I'm on vacation during this period" or "This
is a holiday" or "These hours are outside my work day". (Assuming a
work-related calendar.)

-- Dan

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Tue, 25 Nov 2003 10:09:50 -0800 (Pacific Standard Time)

That makes sense.  Still no feedback on if an attendee has declined an
invitation.  I am assuming that would mean FREE, regardless of the value
of TRANSP.

-- 
__________
Anil SRIVASTAVA
[email-masked]

---

From: Satyanarayana Vempati <[email-masked]>
Date: Tue, 25 Nov 2003 10:19:14 -0800

In a group scheduled calendar component, the STATUS property is
used by the "Organizer" to provide a confirmation of the event to the
"Attendees".

Shouldn't PARTSTAT also be taken into account for an attendee's
calendar?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dan Winship
Sent: Tuesday, November 25, 2003 7:57 AM
To: [email-masked]
Cc: Tim Hare; [email-masked]
Subject: Re: Clarification for Free/Busy

-- Dan

---

From: Doug Royer <[email-masked]>
Date: Tue, 25 Nov 2003 12:10:05 -0700

Don't forget the two new CAP TRANSP values:

            / "TRANSPARENT-NOCONFLICT" ; Transparent on busy time
            ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects
            ; can overlap it.

            / "OPAQUE-NOCONFLICT"  ; Opaque on busy time
            ; searches and no other OPAQUE or OPAQUE-NOCONFLICT objects
            ; can overlap it.

Dan Winship wrote:

>>>                |  STATUS of VEVENT
>>>                |
>>>VEVENT in period | TENTATIVE      | CONFIRMED        | CANCELED | not there
>>>and TRANSP       |                |                  |           |

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 25 Nov 2003 12:55:49 -0700

These discussions seem to presume the process can always be automated. A 
CU could
wish for the time to be BUSY in case they change their mind later. In 
which case the
CU would want the time to be BUSY even if declined.

The publishing of static VFREEBUSY information is a valid RFC-2446 thing 
to do, and it can
be independent of the CAP/BOOKED auto generated VFREEBUSY discussion.

So unless we are deprecating RFC-2446 VFREEBUSY/PUBLISH (and please no), 
then
I assume these discussions are assuming CAP auto generated VFREEBUSY BOOKED
replies?

--

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Tue, 25 Nov 2003 14:15:48 -0800 (Pacific Standard Time)

On 2003-11-25/12:55 [-0700], [email-masked] [Doug Royer] wrote:

>
> These discussions seem to presume the process can always be automated.
> A CU could wish for the time to be BUSY in case they change their mind
> later. In which case the CU would want the time to be BUSY even if
> declined.
>
> The publishing of static VFREEBUSY information is a valid RFC-2446
> thing to do, and it can be independent of the CAP/BOOKED auto
> generated VFREEBUSY discussion.
>
> So unless we are deprecating RFC-2446 VFREEBUSY/PUBLISH (and please
> no), then I assume these discussions are assuming CAP auto generated
> VFREEBUSY BOOKED replies?
>
>

Yes.

-- 
__________
Anil SRIVASTAVA
[email-masked]

---

From: Tim Hare <[email-masked]>
Date: Wed, 26 Nov 2003 23:08:37 -0500

First- let me apologize for the poor formatting of my table - I'll have to 
come up with a better way to reference information best suited to a table.

Second - to clarify one thing, the "not there" column means that the STATUS 
property of the VEVENT is not present, I was trying to provide for the case 
where we could not determine the status from the property.

Third - since the Free/Busy query is directed toward one explicit calendar 
UID,  I'm not sure we need to worry about attendee PARTSTAT - aren't we 
really querying the free/busy times on that VCALENDAR/VAGENDA ?

Fourth- I'm willing to accept that OPAQUE+CONFIRMED = BUSY instead of 
BUSY-UNAVAILABLE as Dan Winship stated, but then where do BUSY-UNAVAILABLE 
statuses come from - other parts of a CUA that "know" my normal working 
hours? In my use of my calendaring software at work, I have to schedule my 
vacation time on my calendar. I don't know how I'd indicate that to my 
software to return that as BUSY-UNAVAILABLE. Not saying it can't be 
done;  I'm just unclear about where it comes from.

Fifth- if an attendee has declined an invitation then the time on their 
calendar should be FREE if (and only if) there is no other VEVENT in that 
time period.

Sixth- this is for automated Free/Busy replies to a query, not to 
publishing free/busy time since that publishing effort could be done by any 
number of things.

Tim Hare

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 Nov 2003 12:57:19 -0700

Tim Hare wrote:

>
> Second - to clarify one thing, the "not there" column means that the 
> STATUS property of the VEVENT is not present, I was trying to provide 
> for the case where we could not determine the status from the property.
>
> Third - since the Free/Busy query is directed toward one explicit 
> calendar UID,  I'm not sure we need to worry about attendee PARTSTAT - 
> aren't we really querying the free/busy times on that VCALENDAR/VAGENDA ?
>
> BUSY-UNAVAILABLE as Dan Winship stated, but then where do 
> BUSY-UNAVAILABLE statuses come from - other parts of a CUA that "know" 
> my normal working hours? In my use of my calendaring software at work, 
> I have to schedule my vacation time on my calendar. I don't know how 
> I'd indicate that to my software to return that as BUSY-UNAVAILABLE. 
> Not saying it can't be done;  I'm just unclear about where it comes from. 

There is no predefined place it comes from. It is simply defended as 
time that can not
be scheduled. Perhaps it is a resource calendar that is off line for 
some specifically unspecified
reason.

> Fifth- if an attendee has declined an invitation then the time on 
> their calendar should be FREE if (and only if) there is no other 
> VEVENT in that time period. 

There is no predefined rule, it is up to the implementations which may 
have its own reasons.

Why do you think there has to be a predefined rule?

> publishing free/busy time since that publishing effort could be done 
> by any number of things.

I do not think that we can predefine what the rule is for calculating
the BUSY-UNAVAILABLE time. We simply have to define that what is
returned is the BUSY-UNAVALIABLE time.

What is returned for a company car calendar may have hard coded
that 1/2 a day after a multi day usage the car is always
unavailable (perhaps for inspection, service, or whatever).

--