Subject: Re: free-busy QUERY

From: "Craig Johnson" <[email-masked]>
Date: Thu, 24 Jul 2003 12:47:10 -0600

B Kahn Wrote:
 
> FWIW: CAP appears to be divergent from iTIP in doing 
> VFREEBUSY REQUEST/REPLYs given what I've read so far 
> in these recent threads.
 
YES!! YES!!  Thank-you! Thank-you!  That's one of the points I've been
making (or trying to).
 
The ability to deal with free-busy information is fundamental to
Calendaring & Scheduling.  It was so fundamental that the VFREEBUSY
object was established to handle it.  Two key purposes of the VFREEBUSY
object are (1) request busy time information, and (2) reply to a request
with busy time information.
 
As previously noted, the CAP spec (-10) does NOT define how to request
free-busy information.  So why doesn't CAP use the VFREEBUSY object to
make the request?  It seems so obvious.  I do not understand the
resistance toward using this Working Group's own standards to address
this issue.
 
Instead, to bolster a VQUERY method, there has been flurry of new "spec
text" generated and suggestions that appear to compromise CAP's support
for iTIP.  This makes me uneasy (especially with final call
approaching).  Using VQUERY for free-busy requests is divergent from the
Working Group's own standards.
 
Again, I propose that CAP use VFREEBUSY to make a request for free-busy
information.  It could be done using SEARCH:
 
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Someone's Prodid
C: CMD;ID=FB001:SEARCH
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: END:VFREEBUSY
C: END:VCALENDAR
 
Or we could give it its own command:
 
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Someone's Prodid
C: CMD;ID=FB001:GET-FREEBUSY
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: END:VFREEBUSY
C: END:VCALENDAR
 
In either case, the CS dynamically provides the return information. 
The request is simple.  It is unambiguous to the CS what data needs to
be returned.  Consistency and continuity with the Working Group's
previous standards are upheld.  Consistency between an iTIP vs CAP
free-busy is secured.

---

From: [email-masked]
Date: Fri, 25 Jul 2003 11:30:42 -0400

Craig responed on 07/24/2003 02:47:10 PM:
> Calendaring & Scheduling. 

Hear, hear!  Thats why it MUST be part of CAP 1.0 IMNHO.

> As previously noted, the CAP spec (-10) does NOT define how to 
> request free-busy information.  So why doesn?t CAP use the VFREEBUSY
> object to make the request?  It seems so obvious.  I do not 
> understand the resistance toward using this Working Group?s own 
> standards to address this issue.

Not sure its the entire WG resisting anything.  The lurker-to-participant 
ratio is quite high here (300+ lurkers to ~10 participants last I 
checked).

In any case, since CAP is using iTIP messages in the payloads it should be 
using the VFREEBUSY the same way it does other components.

> Again, I propose that CAP use VFREEBUSY to make a request for free-
> busy information.  It could be done using SEARCH:
> 
> C: BEGIN:VCALENDAR
> C: VERSION:2.0
> C: PRODID:-//Someone?s Prodid
> C: CMD;ID=FB001:SEARCH
> C: TARGET:usera
> C: TARGET:userb
> C: BEGIN:VFREEBUSY
> C: DTSTART:startrange
> C: DTEND:endrange
> C: END:VFREEBUSY
> C: END:VCALENDAR

In order to by a valid iTIP payload it would look more like:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Someone?s Prodid
C: CMD;ID=FB001:SEARCH
C: TARGET:UserA
C: TARGET:UserB
C: BEGIN:VFREEBUSY
C: ORGANIZER:UserA
C: ATTENDEE:UserA
C: ATTENDEE:UserB
C: DTSTAMP:19970613T190000Z
C: DTSTART:19970701T080000Z
C: DTEND:19970701T200000
C: UID:[email-masked]
C: END:VFREEBUSY
C: END:VCALENDAR

but the information in the TARGETs duplicates the info in the ATTENDEEs so 
it could be simplified by removing the TARGETs w/o violating CAP.  Also, a 
UID was added for a particular purpose, to match up REPLYs to REQUESTs. 
This is effectively duplicated in the ID property parameter on the CMD so 
it could also be simplified and removed from the CMD property.

While its reasonable to expect that the ORGANIZER value would match the 
requestors identity (since iTIP says "MUST be the request originator's 
address" which in CAP maps to their identity) it is possible that someone 
could use a different value.  This should be treated as a failure and the 
request rejected entirely.

Removing the duplicate properties by removing them from the iTIP payload 
is contrary to the intent of keeping the payload iTIP compliant.  Plus 
since CAP says that it makes no changes to iTIP relevant to scheduling 
workflow and busytime lookups would qualify as scheduling workflow then 
removing the ATTENDEE and UID properties from the iTIP payload would be 
contrary to the stated goal.

The ABNF for the SEARCH command should also reflect that VFREEBUSY and 
VQUERY components are mutually exclusive and not permitted w/in the same 
SEARCH command.

> C: PRODID:-//Someone?s Prodid

Another possibility but it has a non-iTIP payload so it is just as 
divergent as using SEARCH with a VQUERY so its not fixing the problem.  If 
the payload were the iTIP VFREEBUSY REQUEST (as described above) then 
thats another choice.

If being able to search the users queue for iMIP VFREEBUSY REQUESTs is 
something we need to have in CAP (I suspect it may be if the CUA has to 
perform iMIP fallback but wants the results returned to the users queue 
for it to find later) then perhaps a compromise is possible:

1: SEARCH on VFREEBUSY does NOT perform a busytime search for the TARGETs. 
 It would be the mechanism the CUA uses to search for iTIP VFREEBUSY 
messages in the TARGET queues.  As such the command would have an implcit 
STATE() = 'BOOKED' whenever the component in question were a VFREEBUSY.

2: GET-FREEBUSY DOES perform a busytime search for the ATTENDEEs (no need 
for TARGETs for this command).  It would be the mechanism the CUA uses to 
search for users free/busy time when trying to schedule meetings.  As such 
the command request and response payloads are fully iTIP compliant.

Thus we have iTIP compliance when doing scheduling workflow, we keep using 
iTIP payloads correctly and we have a clear and unambiguious means for 
doing the desired actions.

> In either case, the CS dynamically provides the return information. 

Oh yeah!...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Fri, 25 Jul 2003 11:23:18 -0600

[email-masked] wrote:

> 
> but the information in the TARGETs duplicates the info in the ATTENDEEs 
> so it could be simplified by removing the TARGETs w/o violating CAP. 
>  Also, a UID was added for a particular purpose, to match up REPLYs to 
> REQUESTs.  This is effectively duplicated in the ID property parameter 
> on the CMD so it could also be simplified and removed from the CMD 
> property.
 >
> address" which in CAP maps to their identity) it is possible that 
> someone could use a different value.  This should be treated as a 
> failure and the request rejected entirely.

And they will not match when the ORGANIZERs CUA was reached via an iMIP
message and the CUA uses CAP to get the data and iMIP to REPLY back
to the requester. I agree all data must be preserved for the flow to work.

The ATTENDEEs can not be removed from the VFREEBUSY REQUESTs for the
same reason, they may be iMIP addresses and not CAP addresses, so
the CUA will have to know who to forward them back to for
RECUR-EXPAND=false CUAs when the CUA is manually processing
the VFREEBUSY requests/replies.

> contrary to the stated goal.

In which case you could CMD:CREATE/METHOD:REQUEST a VFREEBUSY and
get back as the reply a CMD:REPLY/METHOD:REPLY VFREEBUSY - correct?
The advantage being that it is only one round trip to get the
results.

> VQUERY components are mutually exclusive and not permitted w/in the same 

I still do not see any reason to change the SEARCH command just for VFREEBUSY.
The existing syntax works. And I am not sure why searching for a component
will be broken and mutually exclusive. They don't seem mutually exclusive
to me and I have not seen posts explaining why.

> divergent as using SEARCH with a VQUERY so its not fixing the problem. 
>  If the payload were the iTIP VFREEBUSY REQUEST (as described above) 
> then thats another choice.

I do not follow the above. Not sure which way you are
saying does not work.

> 1: SEARCH on VFREEBUSY does NOT perform a busytime search for the 
> TARGETs.  It would be the mechanism the CUA uses to search for iTIP 
> VFREEBUSY messages in the TARGET queues.  As such the command would have 
> an implcit STATE() = 'BOOKED' whenever the component in question were a 
> VFREEBUSY.

In which case iTIP REQUESTS will always be ignored? What is the gain?
If you wanted to say that BOOKED == do the processing and UNPROCESSED
is get the raw components then yes I see your point. But declaring that
all searches for VFREEBUSY are not the 'UNPROCESSED' violates the
generic SEARCH rules. Why make VFREEBUSY an exception?

> 2: GET-FREEBUSY DOES perform a busytime search for the ATTENDEEs (no 
> need for TARGETs for this command).  It would be the mechanism the CUA 
> uses to search for users free/busy time when trying to schedule 
> meetings.  As such the command request and response payloads are fully 
> iTIP compliant.

Why not just process VFREEBUSY REQUEST component the same as every other
component? We already have a way to deposit (CREATE) iTIP REQUEST components
and  fetch iTIP REPLY components (QUERY). So far there have been zero new
features added - absolutely NONE.

The above is true for every iTIP component, not just VFREEBUSY. When
SEARCHING for VEVENT == BOOKED, you do not get the same results as
searching for the VEVENT != BOOKED components, you get the dynamic
live VEVENTs when searching for VEVENT == BOOKED. There is NO difference
here between VFREEBUSY and any other iTIP component.

We are just adding a clarification that VFREEBUSY == BOOKED means the
same as every other iTIP component - calculate the results and send
them back.

There is no new problem being solved. Just a clarification.

That in it self does not justify adding a new method/syntax to query just
for VFREEBUSY when the existing methods work for all iTIP components. And
if we specify that BOOKED means go calculate the results for VFREEBUSY
and UNPROCESSED means go get the raw iTIP messages then it is 100% compatible 
with existing CAP commands, methods, and usage.

Now if we want to optimize the path so that we do not have to have
two full round trips to get the data, then that is a new useful
feature.

If we take Bruce's original proposal that a reply to a unmodified
CMD:CREATE/METHOD:REQUEST VFREEBUSY returns a BOOKED and dynamically
CMD:REPLY/METHOD:REPLY VFREEBUSY, then that works for CS that
have RECUR-EXPAND=true. Then we have added a new useful feature.

I would like that to not be the action when the CS has RECUR-EXPAND=false
as those  CS's can NOT dynamically create VFREEBUSY data as a CS
can allow recurrence rules to be stored and not know how to expand
them.

> Thus we have iTIP compliance when doing scheduling workflow, we keep 
> using iTIP payloads correctly and we have a clear and unambiguious means 
> for doing

Again I was not clear which method you were proposing. So are you saying
that we treat iTIP VFREEBUSY components exactly like every other iTIP
component? That is in all cases a SEARCH where BOOKED are dynamic real
time results? And that != BOOKED is for the raw iTIP packets? If so
yes we agree as that is 100% just like every other component.

-- 

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

                 We Do Standards - You Need Standards