Subject: Re: Cap Free-Busy Request - vs QUERY?

From: "Craig Johnson" <[email-masked]>
Date: Mon, 21 Jul 2003 11:18:10 -0600

D Royer asked: > Would you want to disallow:> > C: BEGIN:VCALENDAR> C: VERSION:2.0> C: PRODID:-//Someone's Prodid> C: CMD;ID=FB001:SEARCH> C: TARGET:CalA> C: TARGET:CalB> C: BEGIN:VQUERY> C: QUERY:SELECT DTSTART,DTEND,FREEBUSY FROM VFREEBUSY> C:  WHERE DTEND >= '20030808T170000Z'> C:  AND DTSTART <= '20030804T080000Z'> C: END:VQUERY No, I do not suggest we disallow this QUERY.  Such a QUERY is necessary for Calendar Stores that support the VFREEBUSY component.  Allow me to elaborate on a few distinguishing issues... 1. Let's make a distinction between "a request for free-busy information" and "a QUERY for VFREEBUSY components".  This distinction comes clearly into focus when dealing with a Calendar Store that does not support the VFREEBUSY component. Suppose we have a simple Calendar Store that supports VEVENTs but does not support VTODO, VJOURNAL or VFREEBUSY (i.e. VEVENT is on the COMPONENTS property; VTODO, VJOURNAL and VFREEBUSY are not).  The Calendar Store is capable of providing free-busy information, but how do you get it?  A QUERY of VFREEBUSY would be formally invalid because it is not listed on the COMPONENTS property.  Would a QUERY of VTODOs be valid?  No.  Why would a VFREEBUSY be any different?  Nothing in the CAP spec allows for this incongruency (i.e. no-where does the spec indicate that a Calendar Store must support a QUERY of VFREEBUSY regardless of whether it is listed on the COMPONENTS property.) This is avoided by making SEARCH/VFREEBUSY the way to "request free-busy information".  It works regardless of how the Calendar Store keeps track of "free-busy" information (i.e. whether or not it supports the VFREEBUSY component).  SEARCH/VQUERY only works for Calendar Stores that support the VFREEBUSY object. 2.  A SEARCH/VQUERY may not return the same information as a SEARCH/VFREEBUSY (although both will return the needed information). Suppose we have a Calendar Store that supports the VFREEBUSY component.  Within a VAGENDA there is a VFREEBUSY object for each month containing FREEBUSY properties for busy times in that month.  Now, suppose I need free-busy information for a particular week* - A SEARCH/VQUERY would find the VFREEBUSY object(s) that overlap the week of interest.  The VFREEBUSY object would be returned with FREEBUSY properties for the entire month , not just FREEBUSY properties for the requested week.- A SEARCH/VFREEBUSY would also find the VFREEBUSY object(s) that overlap the week of interest.  However, in creating a response, the SEARCH/VFREEBUSY can include only FREEBUSY properties overlapping the week of interest and others can be left out. 3. The above QUERY may need additional criteria to return the correct information: C: QUERY:SELECT DTSTART,DTEND,FREEBUSY FROM VFREEBUSYC:  WHERE DTEND >= '20030808T170000Z'C:  AND DTSTART <= '20030804T080000Z'C:  AND STATE() = 'BOOKED'. The addition of STATE() = 'BOOKED' is necessary to avoid retrieving 'unprocessed' VFREEBUSY records that may be present in the VAGENDA. QUERY is a 'nuts and bolts' way of getting information; powerful and flexible ... but inherently complex.  In contrast, a 'VFREEBUSY request' is a 'high level' operation; very specific ...  but simple. Thanks,--C Johnson

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Jul 2003 10:16:28 -0600

Craig Johnson wrote:
>
> 
> No, I do not suggest we disallow this QUERY.  Such a QUERY is necessary 
> for Calendar Stores that support the VFREEBUSY component.  Allow me 
> to elaborate on a few distinguishing issues...
> 
>  
> 1. Let's make a distinction between "a request for free-busy 
> information" and "a QUERY for VFREEBUSY components".  This distinction 
> comes clearly into focus when dealing with a Calendar Store that does 
> not support the VFREEBUSY component.
> 

After thinking about this, there is no difference. With all other
components they are booked or not. Why should VFREEBUSY be any different?
This WG decided on dynamically created VFREEBUSY replies from the CS.
It did not decide (as you use in your example below) that they be
kind of static relative to a month (or whatever time frame).

> 
> Suppose we have a simple Calendar Store that supports VEVENTs but does 
> not support VTODO, VJOURNAL or VFREEBUSY (i.e. VEVENT is on the 
> COMPONENTS property; VTODO, VJOURNAL and VFREEBUSY are not).  The 
> Calendar Store is capable of providing free-busy information, but how do 
> you get it?  A QUERY of VFREEBUSY would be formally invalid because it 
> is not listed on the COMPONENTS property.  Would a QUERY of VTODOs be 
> valid?  No.  Why would a VFREEBUSY be any different?  Nothing in the CAP 
> spec allows for this incongruency (i.e. no-where does the spec indicate 
> that a Calendar Store must support a QUERY of VFREEBUSY regardless of 
> whether it is listed on the COMPONENTS property.)

If a CS does not support other components they also can not be returned.
Why make VFREEBUSY an exception? If the CS did not support VFREEBUSY
could I not just do this in a single search command:

	QUERY:SELECT DTSTART,DTEND FROM VEVENT
          WHERE DTSTART >= range AND DTEND <= range
          AND ( TRANSP = 'OPAQUE' OR TRANSP = 'OPAQUE-NOCONFLICT' )
	QUERY:SELECT DTSTART,DTEND FROM VTODO
          WHERE DTSTART >= range AND DTEND <= range
          AND ( TRANSP = 'OPAQUE' OR TRANSP = 'OPAQUE-NOCONFLICT' )
	
Which is how I dynamically calculate VFREEBUSY information anyway.
Trimming the results to the CUA's exact start/stop times is trivial.
As is combining the results into blocks of time and forming a VFREEBUSY
component from those results.

> This is avoided by making SEARCH/VFREEBUSY the way to "request free-busy 
> information".  It works regardless of how the Calendar Store keeps track 
> of "free-busy" information (i.e. whether or not it supports the 
> VFREEBUSY component).  SEARCH/VQUERY only works for Calendar Stores that 
> support the VFREEBUSY object.

Why should a 'BOOKED' VFREEBUSY be any different than any other component?

> 2.  A SEARCH/VQUERY may not return the same information as a 
> SEARCH/VFREEBUSY (although both will return the needed information).

As this WG has decided on dynamic VFREEBUSY replies, why do you
think they would not satisfy the QUERY? Do you envision that
each CALOWNERs CUA will deposit exactly the correct VFREEBUSY information
for each month into the CS? It is my understanding that this WG decided
that the VFREEBUAY replies be dynamic, so that would then be useless. So where
would these replies come from? And who would use the static results
that you example below (month boundary)?

> Suppose we have a Calendar Store that supports the VFREEBUSY component.  
> Within a VAGENDA there is a VFREEBUSY object for each month containing 
> FREEBUSY properties for busy times in that month.  Now, suppose I need 
> free-busy information for a particular week…

Bruces assertion was that booked VFREEBUSY entries are calculated and not
stored.  You are proposing two booked VFREEBUSY dynamic component replies.
Please explain why a CUA would want each of the two. Then maybe I can
understand the difference.

> - A SEARCH/VQUERY would find the VFREEBUSY object(s) that overlap the 
> week of interest.  The VFREEBUSY object would be returned with FREEBUSY 
> properties for the entire month ,not just FREEBUSY properties for the requested week.

The entire proposal on this list was for a dynamic VFREEBUSY, your
assertion assumes that they are not dynamic. So you invented a second
type of VFREEBUSY. Correct?

> - A SEARCH/VFREEBUSY would also find the VFREEBUSY object(s) that 
> overlap the week of interest.  However, in creating a response, the 
> SEARCH/VFREEBUSY can include only FREEBUSY properties overlapping the 
> week of interest and others can be left out.

Why not just declare that booked VFREEEBUSY's return what the CUA
asks for in the QUERY and in the time range specified in the QUERY?
If VFREEBUSY replies are dynamic as this WG wants, then 100% of
all VFREEBUSY components stored into the TARGET can be thrown away
and ignored anyway. They would NEVER be fetched as this WG wants
dynamic VFREEBUSY replies.

The only thing that I can think of is if a CUA wished to add
blocked out time to a TARGET by storing a VFREEBUSY. But there
would be no way to undo or change the contents of one once
stored. That should be on the 'do not do that' list.

Can anyone think of any reason that a CUA would want a static
booked VFREEBUSY reply when a dynamic one that is guaranteed to represent
the state of the TARGET is available?

> The addition of STATE() = 'BOOKED' is necessary to avoid retrieving 
> 'unprocessed' VFREEBUSY records that may be present in the VAGENDA.

Yes - thanks.
And with dynamic VFREEBUSY replies 100% of all non-booked VFREEBUSY
components can be ignored and never stored by the CS - correct?

> QUERY is a 'nuts and bolts' way of getting information; powerful and 
> flexible ... but inherently complex.  In contrast, a 'VFREEBUSY request' 
> is a 'high level' operation; very specific ...  but simple.

The VFREEBUSY component was invented because iMIP is not real time and
a CUA needed to be able to make best guess as scheduling on the first
attempt. Having the CS dynamically create a VFREEBUSY seems to be
what this WG wants. I do not see that having two kinds of dynamically
created VFREEBUSY replies is useful.

-- 

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

                 We Do Standards - You Need Standards