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

From: Doug Royer <[email-masked]>
Date: Fri, 18 Jul 2003 17:42:44 -0600

[I think I mis-emailed this one - it may be a duplicate]

Craig Johnson wrote:

> This proposal has several advantages:
> 
> -  It is simple and straightforward.  No ambiguity about the request.
> 
> -  It is ‘natural’ and ‘familiar’ because it uses an already defined, 
> well understood object (VFREEBUSY) of which one purpose is “to describe 
> a request for free/busy time” (RFC 2445, p. 58).  We aren’t reinventing 
> or proposing something new or radically different.

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

-- 

  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

---

From: "Craig Johnson" <[email-masked]>
Date: Tue, 22 Jul 2003 22:33:12 -0600

In Doug's response, his VFREEBUSY 'models' for a Calendar Store were not the same as I was describing.  Hence, many unnecessary questions, misunderstanding and confusion.  Allow me to attempt to clarify and differentiate . . . Between Doug and I, I identified at least 4 models regarding how a Calendar Stores might deal with VFREEBUSY components: A.  VFREEBUSY appears on the COMPONENTS property; VFREEBUSY components are static/real entities. [Doug seemed surprised at this model, but it has been discussed several times in previous threads.  Because VFREEBUSY is treated on an equally plane with VEVENT, VTODO, and VJOURNAL it is the most logical model one might derive from a casual reading of the spec.]
B.  VFREEBUSY appears on the COMPONENTS property; VFREEBUSY components are dynamic.
C.  VFREEBUSY does not appear on the COMPONENTS property; VFREEBUSY components are not supported; however, the Calendar Store is capable of providing free-busy information (read on for further clarification**).
D.  VFREEBUSY does not appear on the COMPONENTS property; VFREEBUSY components are not supported; it cannot provide VFREEBUSY components or free-busy information.
 
    The models I was referring to are A and C.  The model Doug primarily refered to is B; he questioned the viability of A; and thought my Model C was Model D.
    Model A maintains some or all free-busy information within static/real VFREEBUSY objects.  Past threads discussed issues and complexities involved with maintaining such data.  Doug's response asserted in several places that the "WG decided that VFREEBUSY be generated dynamically".  Did that also mean that Model A is dead?  That no-one should implement Model A?  Or did it simply mean that Model B is preferred?    Model B and C are actually quite similar.  They both dynamically provide VFREEBUSY information.  The key difference is the presence/absence of VFREEBUSY on the COMPONENTS property and the implications of what that means.    What does it mean when VFREEBUSY (or any other component) is listed on the COMPONENTS property?  The spec simply states that if a component appears on the COMPONENTS property then the component is "supported by the endpoint".  What does "supported" mean?    One defition is that "supported" means that I can CREATE the component; also MODIFY, DELETE, MOVE and SEARCH the component (using VQUERY with 'SELECT component-name').  What in the spec tells me I can do some but not all these operations on a component?  Nothing in the spec differentiates what "support" means for VEVENT, VNOTE, VJOURNAL  vs  VFREEBUSY.  Nothing in the spec regarding GET-CAPABILITIES provides 'finer' granularity to say something like "you can SEARCH, but cannot CREATE, MODIFY, DELETE or MOVE".  "Supported" seems like an all or nothing deal (unless we change the spec).    This inconsistency was encountered while attempting to implement a Type B Calendar Store.  I could conceivably do a SEARCH/VQUERY, but I could not CREATE, DELETE, or MODIFY of 'dynamic' VFREEBUSY components.  That's what compelled me to Model C.    **For Model C and D  VFREEBUSY is not a supported component.  A strict interpretation might be "you cannot send/receive any VFREEBUSY object from the endpoint" (Model D).  A less strict interpretation is that the component is not supported, meaning "you cannot CREATE, MODIFY, DELETE or SEARCH for VFREEBUSY (ie use VFREEBUSY in a VQUERY SELECT clause)" (Model C).  The SPEC does not provide much clarity regarding these two interpretations, but I chose the latter.  But, whether you accept this interpretation or not is inconsequential to my proposal.     This resolved the issues with CREATE, DELETE, MODIFY, and the complexities of trying to interpret the SEARCH/VQUERY criteria and applying that to dynamic VFREEBUSY components.  But, then, how do I get free-busy information?  A VFREEBUSY request (dtstart, dtend) was the answer.  It turns out that a VFREEBUSY request also works for models A and B* and is much simpler* and doesn't deal with the inconsistencies described above. With the above explanations in mind, I can response to some of Doug's questions and comments: D Royer Wrote:

> 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? The difference is a "high level" request for free-busy information vs a "low level" query of VFREEBUSY objects (whether dynamic or static).The "high-level" request shields the CUA from idiosyncrasies inherent in "dynamic vs static" implementations.  It works with all models.  It is much simpler to understand and implement.I'm somewhat confident the "low-level" approach can produce the same information... if it is correctly constructed.
> This WG decided on dynamically created VFREEBUSY replies from the CS. I'm all for that.  My proposal is consistent with that.
> 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). Again, is Model A 'dead'?The example was derived from a previous thread that discussed possible implementations and implications for static VFREEBUSY objects.  I do not mean to imply that that is the way it should be done* but to illustrate differences in the reply between using a "high-level" and "low-level" method for getting free-busy data.  If Model A is not supported* then say so in the spec.
> > 
> > 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?  You are thinking "Model D".  I am thinking "Model C".  VFREEBUSY is not an exception for Model C. > 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. A CUA might encounter VCAR rights problems trying to issue the above commands.  But, Model C allows free-busy request so it isn't necessary to resort to a request against VEVENTs. Does your CS issue this command to itself?  Seems like it would be trivial to convert a VFREEBUSY request (dtstart, dtend) into this form.  It does not seem as trivial to convert a VQUERY of VFREEBUSY components, with all the potential variations and permutations of the query criteria, into this form.  (Another compelling reason I moved from Model B to Model C).
> 
> > 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?Sorry.  I'm lost on what your question is here.  I think it's a Model C/Model D issue.  That makes it moot.
> > 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? I said "both will return the needed information".  I think that is the same as saying "they will satisfy the query" I believe for Model B and C the same information will be returned.  Model A can potentially be different, although it may be the same. > 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)  Again, I am not trying to imply how a Model A calendar store might organize its static VFREEBUSY data.  Ideas for that were discussed on previous threads.  They are presented here only to show potential differences between FREEBUSY responses of Model A and that of Model B/C. Model B and C do provide 'dynamic' data, consistent with the WG decision (which, BTW, is not reflected in the spec).
> 
> > 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.Again, a Model A vs Model B/C issue.
> > - 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? No.  Didn't invent anything.  Just describing model A (as per previous threads).
> 
> > - 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.If you don't support Type A then that would be true.
> 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.Now, you are saying I cannot do a CREATE, MODIFY, DELETE of VFREEBUSY components; that VFREEBUSY is different than the other components.  Where is that in the spec?  What operations are possible with the VFREEBUSY component?  Only SEARCH/VQUERY?  If that's the case, I have another proposal in mind.
> 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?If you support Model A you have to expect static booked VFREEBUSY replies (perhaps along with some dynamically generated ones).  Yes, there are many complications involved to support Model A.  
> > 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? Not correct.  Whether or not they are stored depends on the CS and CUA... and non-booked (ie unprocessed) VFREEBUSY components usually have little to do with 'dynamic' VFREEBUSY components.There are two types of "unprocessed" VFREEBUSY objects that may show up in your VAGENDA:  (1) a request for your free-busy time (an iTIP request), and (2) a response to a free-busy request that you made (an iTIP reply).  A request might be handled immediately by the CS and not stored; but if it's handled by a CUA or CUA-BOT it will be stored until it gets handled.  A response would be stored until a CUA retrieves and deletes it.It seems necessary that "unprocessed" vs "booked" needs to be specified in VFREEBUSY SEARCH/VQUERY operations.  With my proposal it is not necessary; it is implied we are dealing with "booked" entities. > 
> > 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. Again, we agree on this point!  Dynamically created VFREEBUSY is the preferred way to go.  My proposal supports this!  There is no issue about that. > I do not see that having two kinds of dynamically
> created VFREEBUSY replies is useful.
There are not two kinds of dynamic VFREEBUSY replies.  Only one.  However, there are two proposed ways of making the request.  One simple, one not. One easy to understand, one not.  One easy to implement, one not as easy. My proposal has been implemented and running on a preliminary CAP implementation for over two months... with great success and acceptance.  More on this in another post...