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