Re: When to publish -12 - VFREEBUSY

[email protected]
Newsgroups gmane.ietf.calendar
Message-ID <OFCCF933C3.A1F6AC70-ON85256DD0.00698F68-85256DD0.006F7445@notesdev.ibm.com>
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 consistant nor continuous 
from the existing standards since its using CMD:SEARCH and no METHOD 
property.

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

I dont have time to look at your proposal now but Ill try to soon.  I see 
that Doug appears to have read it and responded though so Ill see what his 
take on it is first...

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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.