Re: CAP-12: 10.12.1 Searching for VFREEBUSY

[email protected] 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:
>
>          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 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.

>
> 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?? 

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.

-- 

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

              We Do Standards - You Need Standards