Subject: Cap Free-Busy Request; some compelling thoughts

From: "Craig Johnson" <[email-masked]>
Date: Wed, 23 Jul 2003 11:30:36 -0600

Perhaps this narrative will provide insight that some might find compelling. . .
 
We have a preliminary CAP implementation in use by customers (early adopters) both inside and outside our organization.  Months ago, we were attempting to satisfy the need of these customers to perform a CAP real-time busy search.  At the time the only option offered by the CAP spec was the iTIP approach (not real-time).  Customers were not enthused about this approach and deficiency in CAP.
 
Later, we posed the SEARCH/VQUERY concept.  It got a cool reception.  The response was that "it seems like a step backward" compared with the simplicity of an iTIP request.  We assured them the spec was not yet final and something better might be forthcoming.
 
After implementing the CAP iTIP-VFREEBUSY request/response, the idea of using a VFREEBUSY request 'directly' occurred to us.  We implemented it as an X-GETFREEBUSY command.  Implementation was very quick because it leveraged the already existing iTIP-VFREEBUSY code.
 
When presented to customers the response was universally positive and enthusiastic!  "That's more like it."  "That makes much more sense."  The simplicity and consistency with iTIP were also positives. Considering the previous alternatives, these customers urged us to lobby the CalSch WG to adopt this method of requesting free-busy information.  They would very much like to see it in the spec so they can deal with other CAP implementations in a similar manner.
 
The proposal for using VFREEBUSY (dtstart, dtend) to request free-busy information is not a recent idea.  It has been implemented, adopted and in use for over two months.  The experience has been very good at both ends.
 
Our experience has been compelling.  In sharing this narrative I'm hoping the WG can benefit from our experience and from the response of CAP adopters* and that it might be compelling to the WG at-large.   If presented a choice, I am confident potential CAP adopters would choose the 'VFREEBUSY request' over 'VQUERY request' by a significant majority.
 
I see no problem offering both in the spec.  While some call it as unnecessary, our experience indicates otherwise.  Why not give adopters two ways to "get a cart up a hill"?  Adopters can choose whether they want to "push it by hand" or "pull it with a truck".  Let's give them a "truck".  It's what they want.
 
--cjohnson

---

From: John Stracke <[email-masked]>
Date: Wed, 23 Jul 2003 13:39:13 -0400

Craig Johnson wrote:

> If presented a choice, I am confident potential CAP adopters would 
> choose the 'VFREEBUSY request' over 'VQUERY request' by a significant 
> majority.
>  
> I see no problem offering both in the spec.  While some call it as 
> unnecessary

Actually, I'd call the VQUERY version unnecessary--it doesn't match 
users' expectations, and it doesn't match the implementation style of 
any product I've heard of (except Exchange, which isn't going to 
implement CAP anyway).  When you give someone access to your freebusy 
information, they expect the *current* information, not whatever it was 
when last you updated your store.

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|The Player's Litany: The Wind is the Storm, and the Storm is|
|Data, and the Data is Life. --Daniel Keys Moran             |
\============================================================/

---

From: [email-masked]
Date: Wed, 23 Jul 2003 14:06:51 -0400

Craig wrote on 07/23/2003 01:30:36 PM:
>                               At the time the only option offered by 
> the CAP spec was the iTIP approach (not real-time).

Umm, iTIP busytime REQUEST/REPLY can be done "real-time"; there is no 
store-and-forward lag inherent in iTIP.  iMIP is the store-and-forward 
binding (aka email binding) of iTIP.  CAP is a superset of what started 
out as iRIP, the real-time binding of iTIP.

In CAP it should just be a matter of using an iTIP Section 3.3.2 REQUEST 
whose response is an iTIP Section 3.3.3 REPLY message.    iTIP VFREEBUSY 
REPLYs are defined as:

   The "REPLY" method in a "VFREEBUSY" calendar component is used to
   respond to a busy time request. The method is sent by the recipient
   of a busy time request to the originator of the request.

so since the CAP server needs to generate some kind of response for the 
VFREEBUSY REQUEST its logical that it generate this. 

I have not been able to keep track of the recent flury of emails this 
thread so perhaps I missed some discussion on why this is NOT doable in 
CAP utilizing iTIP messages. 

BTW: Back on 3-Apr-03 I had proposed we reinstate the CAP-Draft-03 (thru 
05) text regarding CS and VFREEBUSY creation/maintenance.  It was removed 
in Draft-06 w/o any WG discussion and this went unnoticed for a while.  I 
think any design that expects CUAs to maintain busytime data is inherently 
flawed and unscalable; the CS is best suited to do this mainteance and 
this results in much more accurate busytime data.  Exactly how the CS does 
this internally is not relevant to CAP since thats an implementation 
detail. 

Yes Virginia that means someone could code up a CS that statically 
calculates the data at some interval and thus is not as consistanly 
accurate as a dynamically calculated/updated CS but so??   We cannot 
design a protocol to deal with poor implementation details and provide the 
functionality users want.   In any case, was there any disent or thought 
to readding the prose back and would it address some of the busytime 
concerns others have too?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Jul 2003 12:40:11 -0600

> when last you updated your store.

I think the confusion is that some may not know that this WG already
decided that VFREEBUSY information is dynamic. So the QUERY *will*
return dynamically generated information and not 'whatever it
was last when you updated your store.'. So I think we agree.
This is not in the -10 version of CAP as it was decided upon just
as -10 was coming out. It however *IS* in -11 that is coming out
this weekend.

Text in -11 version to soon be published (based on the WG input
and existing CAP text):

<section anchor="SEARCHVFREEBUSY" title="Searching for VFREEBYSY">

  For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "TRUE"
  and have the "VFREEBUSY" component in the "COMPONENTS" value in
  the "CAPABILITY" reply, the CS MUST dynamically create the results
  of a search for the "VFREEBUSY" component at search time.
  For these CSs it is the the CS is responsibility and not the CUAs
  responsibility to provide the correct "VFREEBUSY" information for
  a calendar. If a CUA  performs a "CREATE" "VFREEBUSY" the CS MUST
  return success and not store the "VFREEBUSY" component.

  For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE"
  and have the "VFREEBUSY" component in the "COMPONENTS" value in
  the "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information
  on the CS. These CSs then MUST return a "VFREEBUSY" component
  calculated from the stored components. If no "VFREEBUSY" information
  is available for the "TARGET" calendar, then a "VFREEBUSY" with
  no blocked out time will be returned with a success code.

  If a CS does not set the "VFREEBUSY" value in the "COMPONENTS"
  "CAPABILITY" value, the CS does not support the "VFREEBUSY"
  component and all creation and searching for a "VFREEBUSY"
  component MUST fail. Examples of calendars that may be in this
  category are public event calendars that will never require
  scheduling with other UPNs.

--

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: John Stracke <[email-masked]>
Date: Wed, 23 Jul 2003 14:46:38 -0400

Doug Royer wrote:

>> users' expectations
> decided that VFREEBUSY information is dynamic.

Oops.  Sorry, I missed that.  OK, then, whether you ask for it by one 
type of request or another is not something users will care about.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|"Who died and made you king?" "My father."|
\==========================================/