Re: When to publish -12 - VFREEBUSY

Bruce wrote (listing unresolved issues):
> 1: Busytime in CAP

Doug wrote:
> So what's the issue?

Bruce wrote
> This was originally raised back ~ 31-Mar-2003 and briefly revisited in late july
>  ...
>  ... I can find NOTHING in CAP that actually "specifies how to
> search for available busy time information"

Doug wrote:
> How about the entire section named: "10.12.1 Searching for VFREEBUSY" ?

Now I write:

The current CAP spec (12e), including section 10.12.1, does not reflect the central issue and outcome of the VFREEBUSY discussion in late July referred to by Bruce.  Specifically: that a search for available busy time information can, and preferably should, be accomplished using a VFREEBUSY request (as in iTIP).  For example, the following was proposed in that discussion:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY
C: END:VCALENDAR

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.
* It makes life easier and more consistent on both sides of the wire:
* It makes it easier for CUAs because there is only one way the CUA must formulate a search that works for both iMIP and CAP recipients (not a scheme for iMIP and a different scheme for CAP). The CUA formulates the "VFREEBUSY search" not caring if it is intended for recipients via CAP, or iMIP or some other mechanism.
* A Calendar Store would use the same code to respond to the VFREEBUSY search request regardless of whether it came via CAP or iMIP. Again, consistency and continuity! (Calendar Stores that support iTIP very likely have code to handle VFREEBUSY requests. Adapting that code for CAP is relatively simple.)
* Using a VFREEBUSY request is a more straightforward, consistent, stable, and established method for CUAs to rely on than other proposed methods (e.g. VQUERY).

<<Begin:Digression
Rather than using the SEARCH command (as shown above) somewhere (in the July discussion) it was suggested that we modify CAP's iTIP behavior to accommodate this VFREEBUSY search. Specifically: using CMD:CREATE with METHOD:REQUEST as follows:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:CREATE
C: METHOD:REQUEST
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY
C: END:VCALENDAR

Normally, when CMD:CREATE - METHOD:REQUEST is used with a calendar object (VEVENT, VTODO, etc.), the CS stores the object in the "UNPROCESSED" state and replies with a successful REQUEST-STATUS to the CUA (basically saying: "I got it"). 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. I capitulated to this idea [but I have since become increasingly uncomfortable with this compromise along with some others mentioned in section 10.12.1.  But that's for another thread]. 
End:Digression>>

Nevertheless, there is nothing in the spec from that discussion about using VFREEBUSY to do a free-busy search.

So, here is my updated proposal, with ABNF, that defines how to perform a search for free-busy information via the SEARCH command. It goes in section 10.12 "SEARCH Command."

[[[ the following ABNF goes after the ABNF on page 122]]]

ABNF for a "SEARCH" object is:

search-object = "BEGIN" ":" "VCALENDAR" CRLF
              ;
              ; calprops MUST include 'search-cmd'
              ;
                calprops
                other-props
                1*(search-comp)
                "END" ":" "VCALENDAR" CRLF

search-comp   = queryc / freebusyc
                / iana-comp / x-component

freebusyc     = (as defined in iTIP)

[[[the following is a revised paragraph following the ABNF for searchparam on p 122]]]

The format of the request is the search command (search-cmd) followed
by one or more (queryc) "VQUERY" components or (freebusyc) VFREEBUSY 
components.

[[[the following goes somewhere in section 10.12 or 10.12.1]]]

When VFREEBUSY is used with the SEARCH command the CS should return 
free-busy information defined by the VFREEBUSY request. The result 
will contain one or more iCalendar components (one for each TARGET) 
containing the VFREEBUSY response enclosed in a "VREPLY". 

How a CS derives the response is an issue for the CS and not the CUA.
To formulate the VFREEBUSY response the CS may need to derive the
information from several sources depending on CS characteristics:
 (1) from VEVENTs that overlap the search period and having 
     TRANSP=OPAQUE or TRANSP=OPAQUE-NOCONFLICT;
 (2) if the CS has RECUR-EXPAND=TRUE, it should expand VEVENTs and 
     include instances which overlap the search period and
     have TRANSP=OPAQUE or TRANSP=OPAQUE-NOCONFLICT;
 (3) if the CS supports "Booked" VFREEBUSY objects, it must examine
     the FREEBUSY properties from these objects and include those
     that overlap the search period.
After gathering the relevent FREEBUSY time periods, the CS SHOULD
'normalize' the FREEBUSY information as specified by iTIP (i.e. 
remove duplicate busy time periods, ordering, etc.)

The following is an example of request for free-busy information for 
the week of August 4, 2003, 8:00am thru August 8, 2003, 5:00pm (gmt):

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:20030804T080000Z
C: DTEND:20030808T170000Z
C: ORGANIZER:CAP://acme.com/UserX
C: ATTENDEE:CAP://acme.com/usera
C: ATTENDEE:CAP://acme.com/userb
C: DTSTAMP:20031002T153207Z
C: UID://acme.com/0001000300450
C: END:VFREEBUSY
C: END:VCALENDAR

S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//Some Calendar Store
S: CMD;ID=FB001:REPLY
S: TARGET:userA
S: BEGIN:VREPLY
S: BEGIN:VFREEBUSY
S: ORGANIZER:CAP://acme.com/UserX
S: ATTENDEE:CAP://acme.com/usera
S: UID://acme.com/0001000300450
S: DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S: DTSTAMP:20030710T131103Z
S: FREEBUSY:20030805T100000Z/20030805T110000Z
S: FREEBUSY:20030805T140000Z/20030805T150000Z
S: END:VFREEBUSY
S: END:VREPLY
S: END:VCALENDAR

S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//Some Calendar Store
S: CMD;ID=FB001:REPLY
S: TARGET:userB
S: BEGIN:VREPLY
S: BEGIN:VFREEBUSY
S: ORGANIZER:CAP://acme.com/UserX
S: ATTENDEE:CAP://acme.com/userb
S: UID://acme.com/0001000300450
S: DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S: DTSTAMP:20030710T131103Z
S: FREEBUSY:20030806T130000Z/20030805T150000Z
S: END:VFREEBUSY
S: END:VREPLY
S: END:VCALENDAR

----------------------
C Johnson