Re: When to publish -12 - VFREEBUSY

Craig Johnson wrote:

>  
> The current CAP spec (12e), including section 10.12.1, does not 
> reflect the central issue and outcome of the VFREEBUSY discussion in 
> late July referred to by Bruce.  Specifically: that a search for 
> available busy time information can, and preferably should, be 
> accomplished using a VFREEBUSY request (as in iTIP).  For example, the 
> following was proposed in that discussion:
> ...
>
> The example uses the SEARCH command with an iTIP VFREEBUSY to make the 
> request. The advantages/benefits are:
> * It creates consistency and continuity between the WG standards for 
> making a free-busy requests.
> * It makes life easier and more consistent on both sides of the wire:
> * It makes it easier for CUAs because there is only one way the 
> CUA must formulate a search that works for both iMIP and CAP 
> recipients (not a scheme for iMIP and a different scheme for CAP). The 
> CUA formulates the "VFREEBUSY search" not caring if it is intended for 
> recipients via CAP, or iMIP or some other mechanism.

Currently - Pre-CAP:

   (a.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA 
responds
           and the CU MAY be in the loop.

  (a.2)There is NO VFREEBUSY/CREATE in iMIP so the CUA will never see those.

In CAP-12-e:

   (b.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA 
responds
           and the CU MAY be in the loop.

           VFREEBUSY/REQUEST processed exactly like pre-CAP -- by the CUA.

  (b.2) There is still NO VFREEBUSY/CREATE in iMIP.

  (b.3) If CS has RECUR-EXPAND:TRUE :  (VFREEBUSY/REQUEST)

         New but reacts the same way to VFREEBUSY/REQUEST as currently
         done pre-CAP:   The CUA may find a VFREEBUSY/REQUEST in the CS that
         was deposited  by another CUA and the CUA responds and the CU 
MAY be in
         the loop. Just another way a CUA can process a request that may 
have originally
         been an iMIP request. Same latency issue as pre-CAP - allows CU 
in the loop.

         VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA.

         And there is consistency with all other iTIP methods, they are 
stored
         in the UNPROCESSED state until acted upon by a CUA.

  (b.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST)

         New but reacts the same way to VFREEBUSY/REQUEST as currently
         done pre-CAP:   The CUA may find a VFREEBUSY/REQUEST in the CS that
         was deposited  by another CUA and the CUA responds and the CU 
MAY be in
         the loop. Just another way a CUA can process a request that may 
have originally
         been an iMIP request. Same latency issue as pre-CAP - allows CU 
in the loop.

         VFREEBUSY/REQUET processed exactly like pre-CAP - by the CUA.

         And there is consistency with all other iTIP methods, they are 
stored
         in the UNPROCESSED state until acted upon by a CUA.

  (b.5) If the CS has RECUR-EXPAND:TRUE  : (VFREEBUSY/CREATE)

         As the VFREEBUSY REPLY components are created dynamically
         these are useless and have no value and will never be used so
         they should be tossed.

  (b.6) If the CS has RECUR-EXPAND:FALSE  : (VFREEBUSY/CREATE)

         As the VFREEBUSY REPLY components are computed based on
         the stored values, they will be used in the SEARCH results.

  (b.7) For CS with RECUR-EXPAND:TRUE (SEARCH)
       
          The CUA gets auto generated VFREEBUSY/REPLY.

  (b.8) For CS with RECUR-EXPAND:TRUE (SEARCH)
       
          The CUA gets computed results from previously stored
          VFREBUSY/CREATE  components or if none were stored
          the results are the same as no busy time.

I *think* you are proposing:

  
   (c.1) iMIP - the VFREEBUSY/REQUEST is seen by the CUA and the CUA 
responds
           and the CU MAY be in the loop.

  (c.2) There is still NO VFREEBUSY/CREATE in iMIP.

  (c.3) If CS has RECUR-EXPAND:TRUE :  (VFREEBUSY/REQUEST)

          The are auto processed by the CS.

         VFREEBUSY/REQUET  NOT processed exactly like pre-CAP
          so the CU can not be in the loop.

         And there is NOT  consistency with all other iTIP methods, they 
are
         not stored and never acted upon by a CUA.

  (c.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST)

          <I did not see you cover this in your reply>

  (c.5) If the CS has RECUR-EXPAND:TRUE  : (VFREEBUSY/CREATE)

          <I did not see you cover this in your reply>

  (c.6) If the CS has RECUR-EXPAND:FALSE  : (VFREEBUSY/CREATE)

         <I did not see you cover this in your reply>
         Looks as if you proposing that you can never search for VFREEBUSY?
         If so, you just broke RECUR-EXPAND:FALSE CSs.

  (c.7) For CS with RECUR-EXPAND:TRUE (SEARCH)
       
          <I did not see you cover this in your reply>  I think you are
          saying do not allow.

  (c.8) For CS with RECUR-EXPAND:TRUE (SEARCH)
       
          <I did not see you cover this in your reply> I think you are
          saying do not allow.

>
> * A Calendar Store would use the same code to respond to the VFREEBUSY 
> search request regardless of whether it came via CAP or iMIP. Again, 
> consistency and continuity! (Calendar Stores that support iTIP very 
> likely have code to handle VFREEBUSY requests. Adapting that code for 
> CAP is relatively simple.)

Except that is not how iMIP requests are always processed, so it is 
introducing an inconsistency.

> * Using a VFREEBUSY request is a more straightforward, 
> consistent, stable, and established method for CUAs to rely on than 
> other proposed methods (e.g. VQUERY).

As pointed out above, your proposal is currently incomplete, breaks 
EXPAND-RECUR:FALSE
CSs and treats some iTIP objects inconsistently with other iTIP objects 
in CAP.

The process described in 12-e allows for exactly the same as pre-CAP 
processing
(with CU/CUA intervention when wanted and its associated latency). 
(REQUEST/REPLY)

Plus the process described in 12-e allows for latency free replies. 
(CREATE/SEARCH).

It looks to me as if you want to remove the ability for the CU to 
process some
REQUEST/REPLY operations, and I see no new feature you are proposing.

Perhaps if you address issues above c.4, c.5, c.6, c.7, c.8 and why you want
to disallow the CU in the loop I'll understand why you think this is an 
improvement.

-- 

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

                We Do Standards - You Need Standards