CAP-12: 10.12.1 Searching for VFREEBUSY

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 protected]
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.