Subject: Re: When to publish -12 - VFREEBUSY

From: "Craig Johnson" <[email-masked]>
Date: Thu, 2 Oct 2003 05:35:54 -0600

Bruce wrote (listing unresolved issues):
> 1: Busytime in CAP

Doug wrote:
> So what's the issue?

Bruce wrote
> This was originally raised back ~ 31-Mar-2003 and briefly revisited in late july
>  ...
>  ... I can find NOTHING in CAP that actually "specifies how to
> search for available busy time information"

Doug wrote:
> How about the entire section named: "10.12.1 Searching for VFREEBUSY" ?

Now I write:

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:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY
C: END:VCALENDAR

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

<<Begin:Digression
Rather than using the SEARCH command (as shown above) somewhere (in the July discussion) it was suggested that we modify CAP's iTIP behavior to accommodate this VFREEBUSY search. Specifically: using CMD:CREATE with METHOD:REQUEST as follows:

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:CREATE
C: METHOD:REQUEST
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY
C: END:VCALENDAR

Normally, when CMD:CREATE - METHOD:REQUEST is used with a calendar object (VEVENT, VTODO, etc.), the CS stores the object in the "UNPROCESSED" state and replies with a successful REQUEST-STATUS to the CUA (basically saying: "I got it"). It was argued that an implementation which did this for a "VFREEBUSY search" implies some degree of latency in the free-busy search process... which is not good... so, instead, the CS should reply with the VFREEBUSY results instead of just an "I got it" ... and this would be the way CAP does a real-time request/response for free-busy information. I capitulated to this idea [but I have since become increasingly uncomfortable with this compromise along with some others mentioned in section 10.12.1.  But that's for another thread]. 
End:Digression>>

Nevertheless, there is nothing in the spec from that discussion about using VFREEBUSY to do a free-busy search.

So, here is my updated proposal, with ABNF, that defines how to perform a search for free-busy information via the SEARCH command. It goes in section 10.12 "SEARCH Command."

[[[ the following ABNF goes after the ABNF on page 122]]]

ABNF for a "SEARCH" object is:

search-object = "BEGIN" ":" "VCALENDAR" CRLF
              ;
              ; calprops MUST include 'search-cmd'
              ;
                calprops
                other-props
                1*(search-comp)
                "END" ":" "VCALENDAR" CRLF

search-comp   = queryc / freebusyc
                / iana-comp / x-component

freebusyc     = (as defined in iTIP)

[[[the following is a revised paragraph following the ABNF for searchparam on p 122]]]

The format of the request is the search command (search-cmd) followed
by one or more (queryc) "VQUERY" components or (freebusyc) VFREEBUSY 
components.

[[[the following goes somewhere in section 10.12 or 10.12.1]]]

When VFREEBUSY is used with the SEARCH command the CS should return 
free-busy information defined by the VFREEBUSY request. The result 
will contain one or more iCalendar components (one for each TARGET) 
containing the VFREEBUSY response enclosed in a "VREPLY". 

How a CS derives the response is an issue for the CS and not the CUA.
To formulate the VFREEBUSY response the CS may need to derive the
information from several sources depending on CS characteristics:
 (1) from VEVENTs that overlap the search period and having 
     TRANSP=OPAQUE or TRANSP=OPAQUE-NOCONFLICT;
 (2) if the CS has RECUR-EXPAND=TRUE, it should expand VEVENTs and 
     include instances which overlap the search period and
     have TRANSP=OPAQUE or TRANSP=OPAQUE-NOCONFLICT;
 (3) if the CS supports "Booked" VFREEBUSY objects, it must examine
     the FREEBUSY properties from these objects and include those
     that overlap the search period.
After gathering the relevent FREEBUSY time periods, the CS SHOULD
'normalize' the FREEBUSY information as specified by iTIP (i.e. 
remove duplicate busy time periods, ordering, etc.)

The following is an example of request for free-busy information for 
the week of August 4, 2003, 8:00am thru August 8, 2003, 5:00pm (gmt):

C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY
C: DTSTART:20030804T080000Z
C: DTEND:20030808T170000Z
C: ORGANIZER:CAP://acme.com/UserX
C: ATTENDEE:CAP://acme.com/usera
C: ATTENDEE:CAP://acme.com/userb
C: DTSTAMP:20031002T153207Z
C: UID://acme.com/0001000300450
C: END:VFREEBUSY
C: END:VCALENDAR

S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//Some Calendar Store
S: CMD;ID=FB001:REPLY
S: TARGET:userA
S: BEGIN:VREPLY
S: BEGIN:VFREEBUSY
S: ORGANIZER:CAP://acme.com/UserX
S: ATTENDEE:CAP://acme.com/usera
S: UID://acme.com/0001000300450
S: DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S: DTSTAMP:20030710T131103Z
S: FREEBUSY:20030805T100000Z/20030805T110000Z
S: FREEBUSY:20030805T140000Z/20030805T150000Z
S: END:VFREEBUSY
S: END:VREPLY
S: END:VCALENDAR

S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//Some Calendar Store
S: CMD;ID=FB001:REPLY
S: TARGET:userB
S: BEGIN:VREPLY
S: BEGIN:VFREEBUSY
S: ORGANIZER:CAP://acme.com/UserX
S: ATTENDEE:CAP://acme.com/userb
S: UID://acme.com/0001000300450
S: DTSTART:20030804T080000Z
S: DTEND:20030808T170000Z
S: DTSTAMP:20030710T131103Z
S: FREEBUSY:20030806T130000Z/20030805T150000Z
S: END:VFREEBUSY
S: END:VREPLY
S: END:VCALENDAR

----------------------
C Johnson

---

From: Doug Royer <[email-masked]>
Date: Thu, 02 Oct 2003 11:44:02 -0600

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:
> ...
>
> * 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-masked]                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards

---

From: [email-masked]
Date: Fri, 31 Oct 2003 15:19:59 -0500

Craig wrote on 10/02/2003 07:35:54 AM:
> The example uses the SEARCH command with an iTIP VFREEBUSY to make 
> the request. The advantages/benefits are:

Umm, I have to disagree with a couple of your points here.  iTIP currently 
defines how to do busytime lookups and thats with METHOD:REQUEST (iTIP, 
Section 3.3.2 REQUEST).  As such, CAP is not consistant nor continuous 
from the existing standards since its using CMD:SEARCH and no METHOD 
property.

>                                          It was argued that an 
> implementation which did this for a "VFREEBUSY search" implies some 
> degree of latency in the free-busy search process... which is not 
> good... so, instead, the CS should reply with the VFREEBUSY results 
> instead of just an "I got it" ... and this would be the way CAP does
> a real-time request/response for free-busy information.

Latency in busytime is not a good idea.  The busytime info should be as 
current as you can make it, not stale.  After all, what good is it to know 
my availability for next week based on my calendar yesterday; I may have 
already added other entries to my calendar that impact your decision 
making process on when to meet.

I dont have time to look at your proposal now but Ill try to soon.  I see 
that Doug appears to have read it and responded though so Ill see what his 
take on it is first...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Fri, 31 Oct 2003 15:18:34 -0500

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

You are not making a valid comparison here Doug. 

REQUEST is the METHOD property value but CREATE is the CMD property value. 
 I use CMD:CREATE with several different METHOD propety values (ie: 
METHOD:REQUEST to send an invitation/update, METHOD:REPLY to respond, etc)

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

How this iMIP VFREEBUSY/REQUEST critter gets into the 'unprocessed' queue 
in the CS is 100% NOT defined in CAP 1.0 so your last bit is making an 
assumption not based on any CAP text.

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

Still and apples to oranges comparison...

>   (b.3) If CS has RECUR-EXPAND:TRUE :  (VFREEBUSY/REQUEST)
[snip]
>   (b.4) If CS has RECUR-EXPAND:FALSE : : (VFREEBUSY/REQUEST)

The RECUR-EXPAND has no releation to the discussion of VFREEBUSY requests. 
 The request has a DTSTART and DTEND so ANY instance between those bounds 
should be reflected in the returned data.

>          in the UNPROCESSED state until acted upon by a CUA.

In a real time system like CAP it does NOT make sense to have the 
requesting CUA wait for the invitees CUA to respond to the REQUEST. 

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

Another invalid comparison.  (b.3) and (b.4) referred to the METHOD value 
(and no CMD value) but now you refer to the generic CMD:CREATE and no 
METHOD value.

Again, the RECUR-EXPAND has no relationship to the discussion...

> introducing an inconsistency.

Where in iMIP does it say how its processed by the receiving end? Nowhere. 
 Nor is there any text in iTIP that says how it is processed at the 
recieving end.  The only text in iTIP regarding VFREEBUSY REQUEST handling 
is:

   If the originator of the "REQUEST" method is not authorized to make a
   busy time request on the recipient's calendar system, then an
   exception message SHOULD be returned in a "REPLY" method, but no busy
   time data need be returned.

Thats it.  So its not prohibited to do what Craig suggested.

> As pointed out above, your proposal is currently incomplete, breaks 

EXPAND-RECUR is NOT related to busytime lookups, at least not the way its 
currently described in CAP-12-e.  EXPAND-RECUR is a capability to say if 
the EXPAND property is observed.  EXPAND is defined as:

   Purpose: This property is to notify the CS if it should or should not
   expand any component with recurrence rules into multiple instances in
   a query reply.

So if you are saying that the VFREEBUSY results will vary based on if 
EXPAND is supported then I think you have seriously misunderstood how a 
VFREEBUSY REQUEST functions.  iTIP clearly (Section 3.3.3 REQUEST):

   The "REQUEST" method in a "VFREEBUSY" calendar component is used to
   ask a "Calendar User" for their busy time information. The request
   may be for a busy time information bounded by a specific date and
   time interval.

The restriction table shows that for VFREEBUSY you use DTSTART and DTEND 
to bound the busytime search.  So data for instances outside that range 
should NOT be returned (although its not expressly written in iTIP as 
such).

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 31 Oct 2003 15:02:26 -0700

[email-masked] wrote:

> Umm, I have to disagree with a couple of your points here.  iTIP 
> currently defines how to do busytime lookups and thats with 
> METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST).  As such, CAP is not 
> consistent nor continuous from the existing standards since its using 
> CMD:SEARCH and no METHOD property. 

SEARCH for UNPROCESSED, it gets you the objects that have METHODs.
So, not true.

    SELECT VFREEBUSY WHERE state = 'UNPROCESSED'
 
   To get the iTIP  object stored.

Or

    SELECT VFREEBUSY WHERE state = 'BOOKED'

    To get the iTIP  object dynamically created (no latency).

> Latency in busytime is not a good idea.  The busytime info should be 
> as current as you can make it, not stale.  After all, what good is it 
> to know my availability for next week based on my calendar yesterday; 
> I may have already added other entries to my calendar that impact your 
> decision making process on when to meet. 

-- 

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 31 Oct 2003 15:07:18 -0700

> You are not making a valid comparison here Doug.  

I did not make a comparison - I said it has none.

>
> REQUEST is the METHOD property value but CREATE is the CMD property 
> value.  I use CMD:CREATE with several different METHOD propety values 
> (ie: METHOD:REQUEST to send an invitation/update, METHOD:REPLY to 
> respond, etc) 

Which has what to do with the topic?

> How this iMIP VFREEBUSY/REQUEST critter gets into the 'unprocessed' 
> queue in the CS is 100% NOT defined in CAP 1.0 so your last bit is 
> making an assumption not based on any CAP text.

How to get  UNPROCESSED objects (which are only iTIP objects) is clearly 
defined in CAP.
Why you think that VFREEBUSY does not apply to those sections of CAP
you have yet to explain.

--