Subject: Re: When to publish - 12 - VFREEBUSY

From: "Craig Johnson MRB" <[email-masked]>
Date: Wed, 5 Nov 2003 16:03:51 -0700

Doug Wrote
>cjohnson wrote
>> I wish Doug were correct. But CAP-12e has no provision that permits
>> the CUA to make a free-busy request using the VFREEBUSY component
>> and get a direct response.
>
>Nor does iTIP - it has to be processed by the CUA - correct?

See response below.

>> - It's not in Section 10.12.1. That section attempts to define how to get
>> VFREEBUSY components using a VQUERY.
>> - It's not done using iTIP (CMD:CREATE, METHOD:REQUEST). All [iTIP]
>> messages are deposited in the CS in the UNPROCESSED state. The CUA
>> simply gets a "success" response. (Section 10.4).
>
>Which is exactly how iMIP does it to your mailbox to later be
>processed by your CUA - correct?

Are you suggesting that only a CUA understands a VFREEBUSY request and 
only a CUA can respond to it?  Are you suggesting that a Calendar Store is not
capable of handling a VFREEBUSY request and providing a direct response?

If so, I respectfully but strongly disagree.  I can think of no compelling reason 
to impose such a limitation on the CS.  I can think of many to the contrary.

To refocus on the issue:

CAP does not support this WG's established definition (standard) for 
requesting free-busy information using the VFREEBUSY component ... 
and provide a direct real-time response.  (RFC 2445, p 58)

This point was made in a previous discussion thread which, after
some give-and-take, eventually concurred on the issue. We anticipated 
this would be included in CAP-12; but, for reasons unknown it was left
out.  A proposed solution has been provided several times.

It was discussed, there was concurrence, and solution provided.  What criteria 
has not been met for this issue to be incorporated into CAP?  What objections 
can there be to have CAP conform with this WG's own standards?

C Johnson

---

From: Doug Royer <[email-masked]>
Date: Thu, 06 Nov 2003 07:08:31 -0700

> Are you suggesting that only a CUA understands a VFREEBUSY request
  > and only a CUA can respond to it?

The new limitation of the auto reply CAP mode is that the
requester will not get the CU's blocked out time, but the
CALID's busy time. In iTIP/iMIP mode the requester can get the CU's
blocked out time as the CUA knows about other of the CU's
calendars.

If we make everything always auto reply, then we can no longer
get the CU's blocked out time (When it differs from the one
specific calendar the requester connected to with CAP ).

Plus not all CS's can respond (reasons given in previous post).

I am suggesting that the 'auto' response (which is a new idea in CAP)
be done with CREATE/VFREEBUSY+REPLY.

And that the CUA  non-'auto' response be done as it is now with
iTIP/iMIP in the CUA (data stored in the CS) so that the
existing iTIP flow not be altered.

Currently the iTIP/iMIP method gets you the CU's busy time as
determined by the CUA.

   > Are you suggesting that a Calendar Store is not

A VFREEBUSY/REQUEST is not auto respond to now and is not a real
time reply in 2445, 2446, or 2447. So why break CUA's that ADD the users
blocked out time or merge multiple blocked out times from multiple
different calendars from working correctly?

There has been no requirement that what the CUA sent matched 100%
to items any user can find in a named calendar. A simple example
could be that the CUA always adds in the company holiday schedule
calendar to the users busy time.

In the email reply to your post I listed several conditions and showed
how unconditionally changing the iTIP flow from the CUA to the CS
using the text you provided would break some implementations.
(Not all CS's can expand recurrence instances so they can not auto reply.)

  > If so, I respectfully but strongly disagree.  I can think of
  > no compelling reason to impose such a limitation on the CS.
  > I can think of many to the contrary.
  >
  > To refocus on the issue:
  >

RFC 2445 does not specify real time processing of VFREEBUSY
and the words 'real-time' are NOT in that section or any other
section of 2445, or 2447. And its usage in 2446 is not on point,
except for enabling CAP (unnamed) as the new real-time transport.

Real time is what CAP adds.

  > out.  A proposed solution has been provided several times.

Real time VFREEBUSY calculations and replies are in -12.
It was not missed or skipped.

Your proposal was incomplete and failed to take into account
several items (see my reply to your post). You indicated that you
would digest my reply and comment. And I hoped fill in the missing
conditions that you did not take into account in your proposal.

  > It was discussed, there was concurrence, and solution provided.
  > What criteria has not been met for this issue to be incorporated
  > into CAP?  What objections can there be to have CAP conform
  > with this WG's own standards?

There was more than one proposal sent and there were questions asked
that still have not been answered about those proposals.

Again CAP does have real time VFREEBUSY replies which is new to CAP
and did not exist in 2445, 2446, or 2447,

The text put in CAP allows for the new auto reply by the CS.
And the text in CAP allows for exactly the same iTIP flow now used.

Given that the CUA is what puts data into a CS and the CUA is
what gets data out of a CS, the CUA can pick iTIP/iMIP
(CU busy time) mode or the new auto-responce CAP (CALID
busy time) mode .

--

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

                 We Do Standards - You Need Standards