Re: When to publish -12 - VFREEBUSY

[email protected] wrote:

>
> Craig wrote on 10/02/2003 07:35:54 AM:
> > The example uses the SEARCH command with an iTIP VFREEBUSY to make
> > the request. The advantages/benefits are:
> > * It creates consistency and continuity between the WG standards for
> > making a free-busy requests.
>
> Umm, I have to disagree with a couple of your points here.  iTIP 
> currently defines how to do busytime lookups and thats with 
> METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST).  As such, CAP is not 
> consistent nor continuous from the existing standards since its using 
> CMD:SEARCH and no METHOD property. 


SEARCH for UNPROCESSED, it gets you the objects that have METHODs.
So, not true.

    SELECT VFREEBUSY WHERE state = 'UNPROCESSED'
 
   To get the iTIP  object stored.

Or

    SELECT VFREEBUSY WHERE state = 'BOOKED'

    To get the iTIP  object dynamically created (no latency).



>
> >                                          It was argued that an
> > implementation which did this for a "VFREEBUSY search" implies some
> > degree of latency in the free-busy search process... which is not
> > good... so, instead, the CS should reply with the VFREEBUSY results
> > instead of just an "I got it" ... and this would be the way CAP does
> > a real-time request/response for free-busy information.
>
> Latency in busytime is not a good idea.  The busytime info should be 
> as current as you can make it, not stale.  After all, what good is it 
> to know my availability for next week based on my calendar yesterday; 
> I may have already added other entries to my calendar that impact your 
> decision making process on when to meet. 


-- 

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