Subject: Re: Cap Free-Busy Request

From: [email-masked]
Date: Fri, 18 Jul 2003 23:08:31 -0400

Thank you Craig.  Thoughts/comments anyone?

"Craig Johnson" <[email-masked]>
Sent by: [email-masked]
07/18/2003 05:02 PM

        To:     <[email-masked]>
        cc: 
        Subject:        Cap Free-Busy Request

A discussion was started on Mar 31, 2003, regarding how a CUA can request 
free-busy information using CAP.  It was noted that the CAP spec promised 
to "specify how to search for available busy time information" but there 
was nothing in the spec that described how to do this.  While several 
ideas were discussed the key issue was not resolved.  Toward the end of 
the discussion Pat Egen called for proposals, with text, to resolve the 
issue.  So far, none have been presented.

I wish to make a proposal for requesting free-busy information via CAP.  

From the abovementioned discussion there seemed to be agreement on some 
issues:

-  The request should be simple: just specify targets and period of 
interest.

-  The request should be unambiguous.

-  The CS should reply to the request with the free-busy information (i.e. 
respond in real-time).

-  To respond in real-time, the CS should 
retrieve/compose/generate/formulate/synthesize (or whatever it needs to 
do) to provide the free-busy information.

With this in mind, my proposal for a CAP free-busy request is to use the 
SEARCH command with a VFREEBUSY object.  The following is an example:

C: BEGIN:VCALENDAR

C: VERSION:2.0

C: PRODID:-//Someone's Prodid

C: CMD;ID=FB001:SEARCH

C: TARGET:UserA

C: TARGET:UserB

C: BEGIN:VFREEBUSY

C: DTSTART:20030804T080000Z

C: DTEND:20030808T170000Z

C: END:VFREEBUSY

C: END:VCALENDAR

Upon receiving this command a Calendar Store (CS) will compose a response 
for each TARGET.  A sample response to the above request would be: 

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: 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: DTSTART:20030804T080000Z

S: DTEND:20030808T170000Z

S: DTSTAMP:20030710T131103Z

S: FREEBUSY:20030806T130000Z/20030805T150000Z

S: END:VFREEBUSY

S: END:VREPLY

S: END:VCALENDAR

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.

-  It is similar to an iTIP free-busy request which also uses VFREEBUSY.  
This creates uniformity and consistency between CAP and iTIP for 
requesting free-busy information.  This is somewhat important and 
advantageous.  Implementers will expect that a free-busy request, whether 
sent via iMIP/iTIP, CAP/iTIP, or CAP real-time, will result in the same 
data being returned!  Using a similar scheme for requesting free-busy 
information is a step toward uniformity.  In addition, this will 
facilitate and simplify implementations that already have code to handle 
iTIP free-busy requests by allowing re-use of that code for CAP free-busy 
requests.

-  It accommodates a free-busy request/response regardless of how (or 
whether) a Calendar Store supports VFREEBUSY as an AGENDA component (i.e. 
whether or not VFREEBUSY is listed on the COMPONENTS property in response 
to GET-CAPABILITIES).  Calendar Stores that support the VFREEBUSY 
component can create a response from them.  Calendar Stores that do not 
support the VFREEBUSY component can compose a response from VEVENTs and/or 
other vender specific data related to free-busy time.  CUAs are insulated 
from the specifics of how a Calendar Store internally represents free-busy 
information.

The ABNF to accommodate this proposal simply adds "freebusyc" to the 
"search-comp" definition.  The ABNF for "search-comp" was not in the most 
recent draft (this was noted by B Kahn  on 6/14/2003and acknowledged by D 
Royer on 6/19/2003.)  The following is the presumed ABNF for "search-comp" 
that includes "freebusyc".  It would appear in section "10.8 SEARCH 
Command"

   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     = "BEGIN" ":" "VFREEBUSY" CRLF

                 ; 

                 ; The following MUST occur exactly once.

                 ;

                   / dtstart

                   / dtend

                 ;

                 ; The following are optional,

                 ; but MUST NOT occur more than once.

                 ;

                   / dtstamp

                   / uid

                 ;

                 ; The following are optional,

                 ; and MAY occur more than once.

                 ;

                   / other-props

                   "END" ":" "VFREEBUSY" CRLF

I look forward to response and feedback regarding this proposal.

--C Johnson

---

From: Satya Vempati <[email-masked]>
Date: Mon, 21 Jul 2003 13:44:28 -0700

A high-level command to get FREEBUSY seems like a good addition. I have
one suggestion.
 
It seems that the FBTYPE implicit in VREPLY. Per RFC 2445, other FBTYPE's
are possible apart  from the simple FREE/BUSY. They are BUSY-UNAVAILABLE,
BUSY-TENTATIVE. You can add even more types through X-tokens.
 
Shouldn't there be an FBTYPE in the VREPLY?

-----Original Message-----
From: Craig Johnson [mailto:[email-masked]]
Sent: Friday, July 18, 2003 2:03 PM
To: [email-masked]
Subject: Cap Free-Busy Request

to “specify how to search for available busy time information” but there

C: BEGIN:VCALENDAR

C: VERSION:2.0

C: PRODID:-//Someone’s Prodid

C: CMD;ID=FB001:SEARCH

C: TARGET:UserA

C: TARGET:UserB

C: BEGIN:VFREEBUSY

C: END:VFREEBUSY

C: END:VCALENDAR

S: BEGIN:VCALENDAR

S: VERSION:2.0

S: CMD;ID=FB001:REPLY

S: TARGET:UserA

S: BEGIN:VREPLY

S: BEGIN:VFREEBUSY

S: END:VFREEBUSY

S: END:VREPLY

S: END:VCALENDAR

S: BEGIN:VCALENDAR

S: VERSION:2.0

S: CMD;ID=FB001:REPLY

S: TARGET:UserB

S: BEGIN:VREPLY

S: BEGIN:VFREEBUSY

S: END:VFREEBUSY

S: END:VREPLY

S: END:VCALENDAR

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

facilitate and simplify implementation! s that already have code to handle

The ABNF to accommodate this proposal simply adds “freebusyc” to the
“search-comp” definition.  The ABNF for “search-comp” was not in the most
recent draft (this was noted by B Kahn  on 6/14/2003 and acknowledged by D
Royer on 6/19/2003.)  The following is the presumed ABNF for “search-comp”
that includes “freebusyc”.  It would appear in section “10.8 SEARCH
Command”

                 ;

                 ;

                   calprops

                   other-props

                   1*(search-comp)

                 ; 

                 ;

                   / dtstart

                   / dtend

                 ;

                 ;

                   / dtstamp

                   / uid

                 ;

                 ;

                   / other-props

--C Johnson

---

From: "Craig Johnson" <[email-masked]>
Date: Mon, 21 Jul 2003 18:05:14 -0600

> Shouldn't there be an FBTYPE in the VREPLY?
 
An FBTYPE is not necessary when the FBTYPE=BUSY.  From RFC 2445:
 
4.2.9 Free/Busy Time Type

   Parameter Name: FBTYPE
 
   . . .                                 If not specified on a
property that allows this parameter, the default is BUSY.

The following would be equivalent:
 
FREEBUSY:20030805T100000Z/20030805T110000ZFREEBUSY;FBTYPE=BUSY:20030805T100000Z/20030805T110000Z

---

From: Satya Vempati <[email-masked]>
Date: Mon, 21 Jul 2003 17:49:47 -0700

Fair enough. Maybe you could just tweak the examples to hightlight both
UPN/Calid & FBTypes considerations to make them clearer.

-----Original Message-----
From: Craig Johnson [mailto:[email-masked]]
Sent: Monday, July 21, 2003 5:05 PM
To: [email-masked]
Subject: RE: Cap Free-Busy Request

 

 
FREEBUSY:20030805T100000Z/20030805T110000Z

FREEBUSY;FBTYPE=BUSY:20030805T100000Z/20030805T110000Z