Re: When to publish -12 - VFREEBUSY

Bruce Wrote on 10/31/03 13:19:
> Craig wrote on 10/02/2003 07:35:54 AM:
> > The example uses the SEARCH command with a 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.
 
Respectfully, that misses the KEY point ... but gives me an opportunity
to restate it:  
!!! The WG standard for making a request for free-busy time is with the
VFREEBUSY object. !!!  
RFC 2445, p. 58:
 
   Component Name: VFREEBUSY
 
   Purpose: Provide a grouping of component properties that describe
   ... a request for free/busy time
 
(I shall refer to such an object as a "VFREEBUSY request".  It is a
VFREEBUSY object containing,
at least, a DTSTART and DTEND property defining the period of
interest.)
 
iTIP simply defines how iTIP 'wrappers' a "VFREEBUSY request" (which
uses METHOD:REQUEST).  
In CAP, the presence of the METHOD property is what distinguishes an
iTIP message (and iTIP handling)
from regular CAP.  It should not be expected that a strictly CAP
implementation of a
"VFREEBUSY request" would have a METHOD property.  
 
Which brings up the next point:
 
CAP does not (and with CAP-12e still does not) support this working
group's own standard 
for obtaining free-busy information: a "VFREEBUSY request".  This was
discussed and 
acknowledged in a previous thread.  That discussion concluded that
using a "VFREEBUSY
request" would be more appropriate and consistent with existing
standards.  It facilitates
a CUA needing free-busy information for several attendees, some
accessible via CAP and 
others via iMIP (or any future mechanism), to form a single "VFREEBUSY
request" and to 
issue that same request to all attendees.
 
Once again, my proposal is that CAP conform to and support the WG
standard by defining
the use of a "VFREEBUSY request" to obtain free-busy information.  It
makes little difference 
whether we give it's own command, or overload the SEARCH command.  A
CAP 
"VFREEBUSY request" would simply be:
 
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH (or GET-FREEBUSY)
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY       (start of "VFREEBUSY request")
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY         (end of "VFREEBUSY request")
C: END:VCALENDAR
 
C. Johnson