Subject: CAP-12: 10.12.1 Searching for VFREEBUSY

From: [email-masked]
Date: Mon, 19 Jan 2004 13:41:12 -0500

In checking out my last big concerns in CAP I ran across some text in 
Section 10.12.1 Searching for VFREEBUSY that I think may be wrong (or at 
least unclear).  In general, I think the new text is a big improvment and 
Im glad to see it.  However I would like to make it clearer to avoid any 
confusion.  The latest CAP-12 draft says:

10.12.1 Searching for VFREEBUSY

   If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the
   "VFREEBUSY" component in the "COMPONENTS" value in a reply to the
   "GET-CAPABILITY" command, then it is the CS's responsibility and not
   the CUA's responsibility to provide the correct "VFREEBUSY"
   information for a calendar.

[Snip, snip]

   Such a CS MUST dynamically create the results of a search for
   "VFREEBUSY" components at search time when searching for STATE() =
   'BOOKED' items.

   For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE"
   and have the "VFREEBUSY" component in the "COMPONENTS" value in the
   "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on
   the CS. These CSs then MUST return a "VFREEBUSY" component calculated
   from the stored components. If no "VFREEBUSY" information is
   available for the "TARGET" calendar, then a "VFREEBUSY" with no
   blocked out time will be returned with a success code. A CUA sets the
   "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY"
   component without a "METHOD" creating a "BOOKED" entry.

   If a CS does not set the "VFREEBUSY" value in the "COMPONENTS"
   "CAPABILITY" value, the CS does not support the "VFREEBUSY" component
   and all creation and searching for a "VFREEBUSY" component MUST fail.
   Examples of calendars that may be in this category are public event
   calendars that will never require scheduling with other UPNs.

First off, why is VFREEBUSY contingent on the CS's ability or inability to 
RECUR-EXPAND?   Since RECUR-EXPAND is defined as:

   Description: If TRUE then the endpoint can expand an object into
   multiple instances as defined by its recurrence rules when the
   "EXPAND" property is supplied. If FALSE then the endpoint ignores the
   "EXPAND" property.

it merely tells the CUA if the CS supports result expansion or not.  It 
has _nothing_ to do with the CS's ability (or inability) to handle repeat 
instances internally and thus generate the correct VFREEBUSY on demand. 

As I read the text above it appears as if BOTH the "RECUR-EXPAND:TRUE" and 
"RECUR-EXPAND:FALSE" CSs will do the same thing anyway (or close to it). 
That is, for the TRUE case:

         a CS MUST dynamically create the results of a search for
   "VFREEBUSY" components at search time when searching for STATE() =
   'BOOKED' items.

and for the FALSE case:

           These CSs then MUST return a "VFREEBUSY" component calculated
   from the stored components.

These are nearly identical except that in the FALSE case it appears as if 
the data could reflect STATE() != BOOKED items.  This is not good and 
probably a phrasing issue rather than a technical one.  After all, I doubt 
the intent is to have th CS, in this case, return VFREEBUSY that reflects 
pending invitations or reschedules that the CU has not yet taken any 
action on.

Secondly, the text in the 3rd cited paragraph above is self contradictory. 
 First it says "CUA MAY store the "VFREEBUSY" information on the CS" but 
then it goes on to say "These CSs then MUST return a "VFREEBUSY" component 
calculated from the stored components."  I believe the former sentence is 
incorrect or at least poorly phrased and that the latter sentence is 100% 
accurate (with the caveat about "stored components" above).   A CUA should 
NOT be able to modify the VFREEBUSY for a calendar in such a way that it 
does NOT reflect the calendars contents.  Otherwise it is possible for a 
CUA to make the VFREEBUSY data not reflect the calendars contents at all 
and this is not goodness.

I think that by simply removing the text "a CUA MAY store the "VFREEBUSY" 
information on the CS" should resolve this (although it would mean a 
slight editoral change to the first half of that sentence to be useful) 
will resolve this potential disasterous feature.

Finally, I wonder about the text:

                                                     A CUA sets the
   "VFREEBUSY" time on a those calendars by creating a "VFREEBUSY"
   component without a "METHOD" creating a "BOOKED" entry.

This appears to allow a CUA to create VFREEBUSY data (for the CS to 
preserve) that does NOT reflect the actual contents of the actual 
calendar.  Why would we want to make the VFREEBUSY data NOT accurately 
represent the state of the calendars booked contents??  If there is 
nothing on the calendar or it ALL entries that have TRANSP:TRANSPARENT or 
TRANSP:TRANSPARENT-NOCONFLICT properties then one would expect a VFREEBUSY 
with no FREEBUSY properties in it, NOT something the CUA may have forged.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Jan 2004 13:06:56 -0700

[email-masked] wrote:

>
> First off, why is VFREEBUSY contingent on the CS's ability or 
> inability to RECUR-EXPAND?   Since RECUR-EXPAND is defined as:

If the CS allows the CUA to store non-expanted objects.
AND IF  the CS can NOT expand objects.

Then there is NO WAY the CS can auto-expand them and create a
dynamic VFREEBUSY object as many on this WG list want.

This is an iTIP problem as well as there is NO requirement for iTIP 
endpoints
to all support recurring rules.

And we covered this already last month and in the discussions that
led up to the text being inserted.

-- 

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: Doug Royer <[email-masked]>
Date: Mon, 19 Jan 2004 13:17:30 -0700

[email-masked] wrote:

> As I read the text above it appears as if BOTH the "RECUR-EXPAND:TRUE" 
> and "RECUR-EXPAND:FALSE" CSs will do the same thing anyway (or close 
> to it).  That is, for the TRUE case:
>
> These are nearly identical except that in the FALSE case it appears as 
> if the data could reflect STATE() != BOOKED items.  This is not good 
> and probably a phrasing issue rather than a technical one.  After all, 
> I doubt the intent is to have the CS, in this case, return VFREEBUSY 
> that reflects pending invitations or reschedules that the CU has not 
> yet taken any action on. 

Now it is up to the CUA and it can ask and get what it wants in both cases.
What is the problem?

>
> Secondly, the text in the 3rd cited paragraph above is self 
> contradictory.  First it says "CUA MAY store the "VFREEBUSY" 
> information on the CS" but then it goes on to say "These CSs then MUST 
> return a "VFREEBUSY" component calculated from the stored components." 
>  I believe the former sentence is incorrect or at least poorly phrased 
> and that the latter sentence is 100% accurate (with the caveat about 
> "stored components" above).   A CUA should NOT be able to modify the 
> VFREEBUSY for a calendar in such a way that it does NOT reflect the 
> calendars contents.  Otherwise it is possible for a CUA to make the 
> VFREEBUSY data not reflect the calendars contents at all and this is 
> not goodness. 

As we discussed already, the current iTIP VFREEBUSY model is calculated
by the CUA taking into account optionally more than one calendars.

The CAP VFREEBUSY is calculated by the CS without knowledge of other
calendars.

>
> I think that by simply removing the text "a CUA MAY store the 
> "VFREEBUSY" information on the CS" should resolve this (although it 
> would mean a slight editorial change to the first half of that 
> sentence to be useful) will resolve this potential disastrous feature. 

If we remove that, then we do not keep iTIP compatibility. As currently 
the CUA
send and calculate the VFREEBUSY components that may or might not
be the same as the busy time on the one specific CAP calendar.

> represent the state of the calendars booked contents?? 

That is the way iTIP works now. The CUA and not the CS calculates the
VFREEBUSY time. Now both work.

>  If there is nothing on the calendar or it ALL entries that have 
> TRANSP:TRANSPARENT or TRANSP:TRANSPARENT-NOCONFLICT properties then 
> one would expect a VFREEBUSY with no FREEBUSY properties in it, NOT 
> something the CUA may have forged.

No more or less than now with iTIP and pre-CAP.
And again ask for the calculated VFREEBUSY if you want the CS calculated 
VFREEBUSY.
And ask for any iTIP VFREEBUSY when you want the CUA calculated VFREEBUSY.

We keep 100% compatibility with pre-CAP iTIP.
And add the ability to get CS calculated VFREEBUSY results.

--