Subject: Re: Auto reply and VFREEBUSY

From: "Craig Johnson" <[email-masked]>
Date: Fri, 7 Nov 2003 10:20:48 -0700

Doug wrote

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

That is an interesting new distinction.

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

Keep in mind that waiting two hours or two days until each ATTENDEE fires up their CUA and finally responds to the request renders free-busy searches practically useless. It is pragmatically undesirable (a point made in several previous threads.)

It is worth noting that a substantial majority of 'Calendar Stores' operating today, particularly in corporate environments, respond to free-busy requests (iCAL standard or proprietary) without the involvement of some 'ATTENDEE/CUA' equivalent.  In other words, auto-reply is the de facto mode of operation.  Anything less in those environments would be unacceptable.

Nevertheless, some entity or application may wish to operate in the "high latency" mode. I don't think anything proposed so far precludes that.

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

That's a move in the right direction, but I think we can do better. We don't say SEARCH+REPLY, MOVE+REPLY, or MODIFY+REPLY because a REPLY is inherent with the command. Why can't a free-busy reply also be inherent?

I think breaking away from the CREATE command would, also, be preferable.  We could more simply use GET-FREEBUSY (a new command) or overload the SEARCH command. The reply would be inherent, just like other CAP commands. That makes much more sense.  We would have the following variations for VFREEBUSY requests: (The following should be in mono-spaced font to display correctly.  My apologies to recipients where this doesn't happen.)

iTIP/iMIP            iTIP/CAP             CAP

BEGIN:VCALENDAR      BEGIN:VCALENDAR      BEGIN:VCALENDAR
VERSION:2.0          VERSION:2.0          VERSION:2.0
PRODID://somecalid   PRODID://somecalid   PRODID://somecalid
                     CMD:CREATE           CMD:GET-FREEBUSY or SEARCH
METHOD:REQUEST       METHOD:REQUEST       
BEGIN:VFREEBUSY      BEGIN:VFREEBUSY      BEGIN:VFREEBUSY
DTSTART:BegOfPeriod  DTSTART:BegOfPeriod  DTSTART:BegOfPeriod
DTEND:EndOfPeriod    DTEND:EndOfPeriod    DTEND:EndOfPeriod
ORGANIZER: ...       ORGANIZER: ...       ORGANIZER: ...
ATTENDEE: ...        ATTENDEE: ...        ATTENDEE: ...
UID: ...             UID: ...             UID: ...
DTSTAMP: ...         DTSTAMP: ...         DTSTAMP: ...
END:VFREEBUSY        END:VFREEBUSY        END:VFREEBUSY
END:VCALENDAR        END:VCALENDAR        END:VCALENDAR

Note that the "VFREEBUSY request" component is identical in all cases.  The VFREEBUSY defines a request for free-busy information.  The CAP version doesn't include a METHOD property because it would then be bound by iTIP/CAP handling rules.  "CMD:CREATE" wouldn't make sense because we are not "creating" the accompanying VFREEBUSY component.  CAP can inherently reply directly to the request.

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

If the CS is capable, it would be MUCH preferable (and useful) for the CS to "auto-reply" to the iTIP/iMIP request.  Some 'Calendar Stores' do that already (ibid. the de facto behavior).  A CS that isn't capable could hold the request for the CUA to act on.

>> Are you suggesting that a Calendar Store is not capable of 
>> handling a VFREEBUSY request and providing a direct response?
>
>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?

I don't think anything is broken. It will be the Calendar Store's prerogative to "auto-reply" or "hold for CUA".  Some Calendar Stores may characteristically behave one way or the other.  Perhaps some Calendar Stores will allow a CU setting to determine the behavior on a per calendar basis.

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

I concur! and further... A "Calendar Store" is ALSO capable of injecting other "busy" information into an "auto-reply" (e.g. work schedule, holidays).  I am very familiar with such Calendar Stores.  Of course, that extra information is outside the scope of CAP.  Nonetheless, such information is characteristic of some 'Calendar Stores' just as it may be characteristic of a CUA.  It is easily accommodated by VFREEBUSY requests and responses. Given a time period (DTSTART and DTEND) a Calendar Store can whip up a VFREEBUSY response containing busy times for appointments (regular and recurring), holidays, work-schedule, the works.

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

Yup. I was careless in forming my statement. Let me move the reference and rephrase:

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

The key point: using a "VFREEBUSY component" to make the request as per WG definition.  CAP still hasn't got it.  (But I hope were getting closer.)

>> 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.
>
>Real time VFREEBUSY calculations and replies are in -12.
>It was not missed or skipped.

The section you are thinking of attempts to describe a "VFREEBUSY/QUERY". That's not the same as a "VFREEBUSY request" (which is still not in CAP).

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

Yes, I said I would respond.  However, subsequently it was deemed that your post (which detailed "how various CS types might derive free-busy information") was secondary to the key issue of "how a CUA makes the request". We'd like to keep the focus on that and not get sidetracked. Once that's resolved its simpler to move on to the issues in your post. 

That's also why in one of the proposals we had a statement to the effect: "How a CS derives a free-busy response from its data is an issue for the CS and not the CUA." The CUA should be able to issue a "VFREEBUSY request" regardless of what the CS does internally to produce a response (the CUA being capable, of course).

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

Perhaps some CSs will be 'configurable' by the CU/CUA to operate in either mode (on a per calendar basis).

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

Again, the real-time VFREEBUSY you refer to is a "VFREEBUSY/QUERY", and not a "VFREEBUSY request" (the WG defined method for requesting free-busy information). There are differences. These differences were discussed in a previous thread; and, actually, Doug and Bruce corrected me and brought some of these to my attention...

One specific point: A "VFREEBUSY request" has all the information needed to formulate a valid "VFREEBUSY response": (Attendee, Organizer, UID, DTStart, DTEnd). This is something "VFREEBUSY/QUERY" lacks.  

Suppose we did a "VFREEBUSY/QUERY".  The result might include multiple 'booked' and 'generated' VFREEBUSY components.  What UID would the resulting VFREEBUSY component(s) have?  Would they retain their own UID?  Would they each get a consistent UID?  Where from?  What about organizer & attendee? Does each VFREEBUSY have its own?  Does it have either of them?  These could be derived from the Session Identity and Target and the QUERY could 'magically' plug these values into every VFREEBUSY component produced by the QUERY.  But that's unlike any other SEARCH/QUERY operation in CAP.  Nothing does that.  It seems that a VFREEBUSY/QUERY would require some special handling to produce "valid" VFREEBUSY responses.  (I hope not to see a "magic mode" that facilitates this.)

I don't think many have thoroughly reviewed the new section which describes VFREEBUSY/QUERY issues and constraints. The section is new with CAP-12 and hasn't had the scrutiny that other sections have had.  I'm not sure I've yet seen a "QUERY" statement that "does the trick" for a free-busy search. Those that come close are somewhat complicated ("booked" vs "unprocessed", etc.)

I am not suggesting that "VFREEBUSY/QUERY" can never work and should be abandoned.  But it is clearly NOT the best choice for making "a request for free-busy information" ... and it's not the mechanism the WG defined in 2445 (and 2446).  A "VFREEBUSY request" is very straightforward and does not suffer the drawbacks and unresolved issues of a VFREEBUSY/QUERY.

C Johnson

(BTW:  Thanks for the interaction.  I'm finding it useful.)

---

From: Doug Royer <[email-masked]>
Date: Fri, 07 Nov 2003 13:27:13 -0700

> That is an interesting new distinction.

That's what I have been trying to figure out how to say for a while :-)

> Keep in mind that waiting two hours or two days until each ATTENDEE 
> fires up their CUA and finally responds to the request renders 
> free-busy searches practically useless. It is pragmatically 
> undesirable (a point made in several previous threads.)

In which case the CUA that contacts the CS would want to use the CALID 
mode and
not the CU mode. (or see below)

> It is worth noting that a substantial majority of ‘Calendar Stores’ 
> operating today, particularly in corporate environments, respond to 
> free-busy requests (iCAL standard or proprietary) without the 
> involvement of some ‘ATTENDEE/CUA’ equivalent. In other words, 
> auto-reply is the de facto mode of operation. Anything less in those 
> environments would be unacceptable.

That may be true, however the opposite it true for web calendars. Where 
often the user must
publish a VFREEBUSY manually and its contents may be a superset of the the
publicly available calendar.

With web calendars the CU/CUA publishes their VFREEBUSY calendar so the
requester does not have to wait. The requester just gets the CU's 
'published' VFREEBUSY,
no delay. Currently how you get that is somewhat random as CAP does not 
yet exist.

We could modify 10.12.1 to say something like:

for CS that RECUR-EXPAND/TRUE:

A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to
indicate CUs busy time.

When the requester wishes the CU busy time SEARCH for VFREEBUSY/PUBLISH.

When the requester wishes the CALID busy time SEARCH for VFREEBUSY/booked.

Then state that if a VFREEBUSY/PUBLISH is NOT in the CALID, then the CS 
returns
an automatically calculated VFREEBUSY/booked value.

And tweak the RECUR-EXPAND/FALSE to match:

A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to
indicate CUs busy time.

When the requester wishes the CU busy time SEARCH for VFREEBUSY/PUBLISH.

When the requester wishes the CALID busy time SEARCH for VFREEBUSY/booked.

Then state that if there is no VFREEBUSY/PUBLISH in the CALID, a successful
empty VFREEBUSY be returned.

And as a RECUR-EXPAND/FALSE CS can not automatically generate VFREEBUSY
booked items, then all requests will be treated as if they are
a SEARCH VFREEBUSY/PUBLISH.

> Nevertheless, some entity or application may wish to operate in the 
> "high latency" mode. I don’t think anything proposed so far precludes 
> that.

The only way it would be precluded is if all searches for VFREEBUSY return
automatically calculated results. Which was one of the original proposals.

> That's a move in the right direction, but I think we can do better. We 
> don’t say SEARCH+REPLY, MOVE+REPLY, or MODIFY+REPLY because a REPLY is 
> inherent with the command. Why can't a free-busy reply also be inherent?

> I think breaking away from the CREATE command would, also, be 
> preferable. We could more simply use GET-FREEBUSY (a new command) or 
> overload the SEARCH command. The reply would be inherent, just like 
> other CAP commands. That makes much more sense. We would have the 
> following variations for VFREEBUSY requests: (The following should be 
> in mono-spaced font to display correctly. My apologies to recipients 
> where this doesn't happen.)

> iTIP/iMIP iTIP/CAP CAP
> .......
> Note that the "VFREEBUSY request" component is identical in all cases. 
> The VFREEBUSY defines a request for free-busy information. The CAP 
> version doesn't include a METHOD property because it would then be 
> bound by iTIP/CAP handling rules. "CMD:CREATE" wouldn't make sense 
> because we are not "creating" the accompanying VFREEBUSY component. 
> CAP can inherently reply directly to the request.

Is that not already what "10.12.1 Searching for VFREEBUSY" does +/- some 
minor tweaks?

And some implementations currently allow the CU to PUBLISH their CU 
VFREEBUSY
on the calendar, so CREATE/METHOD:PUBLISH is valid.

>
> If the CS is capable, it would be MUCH preferable (and useful) for the 
> CS to "auto-reply" to the iTIP/iMIP request. Some ‘Calendar Stores’ do 
> that already (ibid. the de facto behavior). A CS that isn’t capable 
> could hold the request for the CUA to act on.

Yes. And only when that is the desired behavior of the requester, else 
the requester
could never ask for the CU busy time vs the CALID busy time.

> I don't think anything is broken. It will be the Calendar Store's 
> prerogative to "auto-reply" or "hold for CUA". Some Calendar Stores 
> may characteristically behave one way or the other. Perhaps some 
> Calendar Stores will allow a CU setting to determine the behavior on a 
> per calendar basis.

Yes. It would only be broken if we only allowed auto-generate of the reply.

> I concur! and further... A "Calendar Store" is ALSO capable of 
> injecting other "busy" information into an "auto-reply" (e.g. work 
> schedule, holidays). I am very familiar with such Calendar Stores. Of 
> course, that extra information is outside the scope of CAP. 
> Nonetheless, such information is characteristic of some ‘Calendar 
> Stores’ just as it may be characteristic of a CUA. It is easily 
> accommodated by VFREEBUSY requests and responses. Given a time period 
> (DTSTART and DTEND) a Calendar Store can whip up a VFREEBUSY response 
> containing busy times for appointments (regular and recurring), 
> holidays, work-schedule, the works.

Yes.

> Perhaps some CSs will be ‘configurable’ by the CU/CUA to operate in 
> either mode (on a per calendar basis).

I do not have a problem with configurable, but we need to allow the 
fetching of CU vs
CALID as separate tasks that might return the same results.

>
> One specific point: A "VFREEBUSY request" has all the information 
> needed to formulate a valid "VFREEBUSY response": (Attendee, 
> Organizer, UID, DTStart, DTEnd). This is something "VFREEBUSY/QUERY" 
> lacks.

Maybe I am misunderstanding you, but a VFREEBUSY/REQUEST is prohibited
from having ATTENDEE and UID (See iTIP page 32).

And VFREEBUSY/QUERY does allow searching for any contents in a VFREEBUSY
(unprocessed or booked, manually created or auto generated) which would 
include
the DTSTART and DTEND values.

> Suppose we did a "VFREEBUSY/QUERY". The result might include multiple 
> 'booked' and 'generated VFREEBUSY components.

As written you would get the calculated results for BOOKED.

> What UID would the resulting VFREEBUSY component(s) have?

Who cares as you would need one per unique request, so why not just
generate a new UID for each VFREEBUSY/REPLY?

> Would they retain their own UID?

If they are auto-generated, I would have a new UID for each reply.
If not, they would contain what had been stored.

> Would they each get a consistent UID? Where from? What about organizer 
> & attendee?

Per iTIP, the ATTENDEE in a VFREEBUSY/REPLY is the "address of the 
recipient replying".
And the ORGANIZER "MUST be the request originator's address"

> Does each VFREEBUSY have its own? Does it have either of them? These 
> could be derived from the Session Identity and Target and the QUERY 
> could ‘magically’ plug these values into every VFREEBUSY component 
> produced by the QUERY. But that’s unlike any other SEARCH/QUERY 
> operation in CAP. Nothing does that. It seems that a VFREEBUSY/QUERY 
> would require some special handling to produce "valid" VFREEBUSY 
> responses. (I hope not to see a "magic mode" that facilitates this.)

Again, I feel that the VFREEBUSY/SEARCH be the auto generated one
for the CALID.

I think the WG wants auto generated VFREEBUSY/REPLY, so that does mean some
kind of magic mode.

> I don’t think many have thoroughly reviewed the new section which 
> describes VFREEBUSY/QUERY issues and constraints. The section is new 
> with CAP-12 and hasn’t had the scrutiny that other sections have had. 
> I'm not sure I’ve yet seen a "QUERY" statement that "does the trick" 
> for a free-busy search. Those that come close are somewhat complicated 
> ("booked" vs "unprocessed", etc.)
> I am not suggesting that "VFREEBUSY/QUERY" can never work and should 
> be abandoned. But it is clearly NOT the best choice for making "a 
> request for free-busy information" ... and it’s not the mechanism the 
> WG defined in 2445 (and 2446). A "VFREEBUSY request" is very 
> straightforward and does not suffer the drawbacks and unresolved 
> issues of a VFREEBUSY/QUERY.

My only strong feelings is that the iTIP/VFREEBUSY still be the CU 
VFREEBUSY/REPLY
as it currently is (even if it happens to be the same as the CALID 
VFREEBUSY/REPLY).

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