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