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.
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.
A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to indicate CUs busy time.
A CREATE/VFREEBUSY/PUBLISH may be stored on the CS by the owner to indicate CUs busy time.
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.
> 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
.......
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.
Perhaps some CSs will be ‘configurable’ by the CU/CUA to operate in either mode (on a per calendar basis).
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).
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?
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?
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.
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature