Re: Status of the CALSCH working group

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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