Re: Status of the CALSCH working group

Doug replied on 11/07/2003 04:14:11 PM:
> > VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems 

> > to me that there are several ambiguities here. I think that we must be 

> > clear about a requirement that servers MUST provide "currently 
> > accurate" freebusy information in response to an appropriate request. 
> > And I'm definitely confused about why one would want to permit the use 

> > of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the 

> > ITIP syntax for requesting this information.
> 
> Because some want and expect the CU (user) VFREEBUSY and others want the
> CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU 
VFREEBUSY
> that just might be the same as the CALID VFREEBUSY.

We have never drawn a distinction between a CUs availability or a 
calendars before.  Are you saying you have some proposal in mind for 
drawing a distinction?  Something like hierarchical calendars with 
busytime / content rollup or "calendar bundling"?  Please say no...

CUs like to schedule with other CUs, not with an abstract 'calendar'; I 
want to meet with Bob, not with a calendar that Bob is an owner or 
co-owner of or one that Bob has no actual association with but he gave me 
the RelCALID for.  iTIP defined busytime in terms of user interactions 
because that's how people work.  In CAP, the behavior should be the same. 
To this end CUs are more likely to be targeting the either a particular CU 
by name or the calFBURL (RFC 2739) for that CU rather than any arbitrary 
calendar that may be associated somehow to the CU. 

Early on we had the implicit assumption that each CU had a default 
calendar where they did their C&S and so a busytime check of that calendar 
would reflect that users availability; we did not model things such that 
the users availability was spread out across potentially dozens of 
calendars.  Just like a user does not keep their 'calendar' in separated 
out across a paper Dayrunner (TM) , a PDA calendar, Voice Mail messages 
(phone tag arranging) and other non-interlinked sources simply because its 
not convenient and its easy to miss entries.  Trying to draw distinctions 
beyond how people work in ill-fitting ways is a recipe for disaster and 
confusion.  (RFC 2739 provides calOtherFBURLs for those users who want to 
have multiple sources but they are not the 'primary' source that calFBURL 
defines...)

Also, busytime should be reflective of the contents of the particular 
target.   A CUA should not be allowed to arbitrary monkey with the 
VFREEBUSY data that the CS would return so that it is not reflective of 
the calendar it is associated with.  Otherwise when someone does a 
busytime lookup they see that the target is available from 10AM-11AM today 
when in fact they are in a meeting which has TRANSP:OPAQUE which defeats 
the usefulness of busytime AND violates the definition of TRANSP 
(iCalendar, Section 4.8.2.7 Time Transparency).

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