Re: When to publish -12 - VFREEBUSY

Doug replied on 10/02/2003 01:44:02 PM:
> 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.

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)

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

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.

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

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

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

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:FALSE

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
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...