Re: CAP & busytime?

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 03/31/2003 06:12:54 PM:
> > 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.  
> 
> In fact we squashed the CS from doing any work for the CUA.
> You need to have your CUA or a CUA-BOT do it for you.

I dont recall that decision and I certainly
think making VFREEBUSY data totally disjoint from the contents of the associated
calendar is a BAD idea.  It makes busytime useless if we have no clear
and consistant design for doing busytime lookups and now busytime data
is maintained.  

How can any CU reasonably expect to
do any kind of scheduling with other users if busytime information is NOT
guaranteed to be in sync w/the calendar contents (or reasonably close to
it assuming some lag in updating)?

We already mandate that a CS MUST provide
support for a READBUSYTIMEINFO VCAR so its reasonable to expect that the
CS would maintain that busytime info rather than relying on CUAs to do
this maintenance or some totally unspecified "Bot" mechanism.
  After all, since VFREEBUSY have NO linkage information to the actual
entries in a calendar (go recheck 2445 if you dont believe me, Section
4.6.4 Free/Busy Component) there is very little chance that a CUA can properly
maintain the 'digested' info in a VFREEBUSY.    And making the
prescious 'thin' clients 

The only reasonble source for keeping
the VFREEBUSY accurate is to have it done by the CS as changes are made
to the calendar.  _Assuming_ that an unspecified "Bot" mechanism
 is the way that it should/would/MAY be done is NOT sufficient here
if we want that key functionality in CAP.  CAP 1.0 needs to provide
that basic functionality in it or we severly risk loosing user adoption.

> > Actually it is not.  The only ANBF
in SEARCH is:
> 
> Read more text...:
> 
>       comp-name  = "VEVENT"  /
"VTODO"     / "VJOURNAL" / "VFREEBUSY"
>                  / "VALARM"
 / "DAYLIGHT"  / "STANDARD" / "VAGENDA"
>                  / "VCAR"
   / "VCALSTORE" / "VQUERY"   / "VTIMEZONE"
>                  / x-comp
   / iana-comp
> 
> 
> And comp-name is used in:
> 
>    cal-query  = "SELECT"   SP  
cap-val  SP
>                 "FROM"
    SP   comp-name SP
>                 "WHERE"
   SP   cap-expr
> 

Umm, sorry but that ABNF is NOT under
SEARCH.   That ABNF is part of Section 6.1.1. CAL-QUERY Value Type
which is concerned with "Registration
of text/calendar MIME value type CAL-QUERY"

Perhaps you meant to say "SELECT"
instead of SEARCH..??

A cal-query data type is used for the
QUERY (Section 8.26), RESTRICTION (Section 8.33) and SCOPE (Section 8.34)
properties.  The latter 2 are related to VCARs.  The former appears
ONLY referenced in the ABNF for the VQUERY component (Section 9.6).  If
you recheck your draft you will find that the ONLY references to a VQUERY
component usage is in the CREATE command:

 create-comp = agendac / carc /
queryc
               / timezonec / freebusyc
               / eventc / todoc / journalc
               / iana-comp / x-component

NOWHERE else in the ABNF do I find any
reference to the queryc.   As such it is illegal for me to use a VQUERY
in any other command OTHER than a CREATE one (a comment I made many moon
ago but must have been forgotten).  

Then again, the create-object in the
ABNF is referenced NOWHERE in the draft either so something is either very
wrong w/the find text feature of MSIE or there is some really bad ABNF
here...  However this is a topic for a new thread I think...

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