Re: CAP & busytime?

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug responded on 03/31/2003 04:15:47 PM:
> Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> > 
> > Its unclear in the latest drafts so I wanted to ask the WG at
large 
> > something.  Does CAP allow for a CUA to get busytime from
the CS?
> 
> The same as with iTIP. You publish yours and make it available.

CAP commands do not map 1-to-1 onto
iTIP messages.  

In CAP I CREATE a component in one or
more TARGETs which may have some METHOD property value.  In iTIP I
send a message with a METHOD property value determined by iTIP.  CAP
always uses CREATE to create new entities (hmm, how do updates happen!)

For busytime, iTIP uses the VFREEBUSY
component with METHOD:REQUEST or METHOD:REPLY for requesting and responding,
respectively.  In CAP, I guess that would crudely map to a CREATE
command with particular TARGETs but there is NOTHING to lead me to belive
that the CS must do any actual processing beyond the actual request creation.
 

Nothing in CAP says that the CS works
in realtime to process the VFREEBUSY with METHOD:REQUEST as a realtime
busytime lookup and as such SHOULD result in busytime results being sent
back rather than "REQUEST-STATUS:2.0;VFREEBUSY Created" response.
 As such if my CUA CREATEs a VFREEBUSY with METHOD:REQUEST, all I
get back is essentially a "Yes, your VFREEBUSY was created in the
TARGET", NOT the actual results Im querying for!  So how does
my CUA get the RESULTS of the workflow query??  CAP is realtime so
I would assume that the query / response for busytime would/should be realtime
too!

> > The first paragraph in Section 1 says in
part:
> > 
> >              It further specifies
how to search for available busy time 
> > information.
> > 
> > but I dont see any prose that actually says how this is to be
done in 
> > CAP.  All of the commands and examples appear to be oriented
at entry 
> > creation/discovery/deletion but nowhere does there appear to
be 
> > consideration of something like "How do I get Pats, Bobs
and Dougs 
> > busytime?"
> 
> And you will notice that VFREEBUSY is in the ABNF for SEARCH.

Actually it is not.  The only ANBF
in SEARCH is: 

        search-cmd
  = searchparam ":" "SEARCH"

       searchparam   = *(

                    
; the following are optional,
                    
; but MUST NOT occur more than once

                    
  id-param
                    
/ localize-param
                    
/ latency-param

                    
; the following MUST occur exactly once and only
                    
; when the latency-param has been supplied and
                    
; MUST NOT be supplied if the latency-param is
                    
; not supplied.

                    
/ action-param

                    
; the following is optional,
                    
; and MAY occur more than once

                    
/ other-params

                    
)

Not a single mention of
VFREEBUSY.  In fact the ABNF under search is incomplete compared with
the ABNF under DELETE and CREATE which have create-vreply, create-vresponse,
etc. but thats a different matter.

> > Im merely guessing that I could SEARCH for
it but all the examples/prose 
> > talk about entries like VEVENTs and VTODOs.   Since busytime
is NOT an
> > actual entry but rather a conceptual thing ("Take all of
Bruces entries 
> > for today and that is his 'busytime' for today") Im unclear
how (or even 
> > _if_) busytime is addressed in CAP.  Yes we have VFREEBUSY
components 
> > but they are most typically synthesized by the system by amalgamating
> > the other entrys rather than being an actually separately maintained
> > _actual_ component.
> 
> We deferred 'roll-up' into VFREEBUSY. Yes it is unspecified. It would
> be an unspecified CUA-BOT.

So the text from Section 1 is wrong;
we do NOT provide a clear way to do realtime busytime lookups...

Given that a CUA can create VFREEBUSY
and query for them, etc I strongly suspect that VFREEBUSY and its use has
been overlooked or ignored.  What good is a calendaring and _SCHEDULING_
protocol if I cant get your schedule information??

If we treated VFREEBUSYs as 'meta' information
instead of an actual component that can be crated/updated/modified by a
CUA and thus NOT reflect the actual busytime of the TARGETs then I think
its a step closer to being better.  Otherwise we totally misconstruct
the busytime ablities in CAP to be totally useless compared to those in
iTIP (where we assumed the data to be generated dynamically rather than
statically and CERTAINLY NOT modifiable by the requestor/CU).

If we are going to defer it then we
should put in some prose to that effect so that its clear that CAP 1.0
does not accuratly provide a busytime lookup mechanism.

> > I may infer from the text under CREATE that
I (or my CUA) must CREATE 
> > the VFREEBUSY for it to exist (see create-vreply and create-comp).
 
> 
> Yes.

Ugh, see above about iTIP vs CAP in
this respect...

> > I may also infer from the text under DELETE
that I can delete VFREEBUSY 
> > data but not the actual entry that it represents (see delete-vreply)
> > which can also cause some serious quandries ("The VEVENT
is in my 
> > Calendar but it does not appear to be reflected in the VFREEBUSY
data 
> > that I retrieved.  Why not?")
> 
> TRANSPARENT entries will also not show up in your VFREEBUSY.
> Plus if you don't what that, do not allow a CUA or CUA-BOT to do that.

They show up with the proper fbparam
property parameter on each FREEBUSY within the VFREEBUSY.  Go check
4.8.2.6 Free/Busy Time
of 2445.

Bruce
===========================================================================
Bruce Kahn                  
             INet: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...