[Design] 0.7 Chandler scheduling phasing proposal

[Grant Baillie]

On Feb 13, 2006, at 2:45 , Brian Moseley wrote:

> On 2/13/06, Jeffrey Harris <jeffrey at osafoundation.org> wrote:
>
>> This suggests to me that this requirement is asking Cosmo to give  
>> us two
>> read-only tickets, one for calendar data, one for freebusy, but  
>> only one
>> read-write ticket that applies to both of these.  I don't know if  
>> Cosmo
>> supports that (Brian?).
>
> it depends on how freebusy data is stored. if it's a separate resource
> inside a caldav calendar collection, then it could be ticketed
> separately of the enclosing calendar collection. if you're planning to
> use the caldav freebusy report, then there's no "sub-resource" to
> ticket independently of the calendar collection.
>
> to be honest, i haven't read the freebusy section of the caldav spec
> in enough detail to understand if it expects clients to stick
> VFREEBUSY components into calendar collections, expects servers to
> calculate freebusy time by examining all the events in the calendar,
> or allows some combination of both, so i can't speak with much
> authority yet on how cosmo will eventually implement freebusy support.

My understanding is that both should be supported. i.e. clients can  
query for all VFREEBUSY components inside a calendar, or (via a free- 
busy-query REPORT) could get free-busy info for the calendar (i.e.  
VEVENT & VFREEBUSY combined). It had been my intention to use the  
REPORT to support FB, though I hadn't thought about the privacy  
aspect Jeffrey brought up.

The CalDAV approach to access control for free-busy is to have a  
separate privilege (read-free-busy) that can be used to restrict  
access to FB & not the individual events. That doesn't work so well  
with tickets; one way to make this work would be to replace the  
"readonly" ticket element with <privileges>. (Though, besides read,  
read-free-busy & write, I'm not sure whether any other ACL privileges  
are worth supported).

--Grant