[Design] 0.7 Chandler scheduling phasing proposal

[Lisa Dusseault]

On Feb 13, 2006, at 3:42 PM, Grant Baillie wrote:

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

This is all correct and one further thing:  it will work easier if  
the client uploads VEVENTs for most of its data, and lets the server  
calculate busy time from those.  Then for events that the client  
doesn't want to upload, or time that the user simply wants to block  
out (e.g. noon to 1 for lunch daily), the client should upload  
VFREEBUSY components only for those.  This avoids duplicating free- 
busy time in both VEVENTs and VFREEBUSY components, avoids errors  
synchronizing between two different busy-time stores, and is more  
efficient...

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

Tickets can be defined for any privilege according to the proposed  
wire syntax.  A request for a read-free-busy ticket would have a body  
something like this.  The server can choose to allow it or not, of  
course.

    <D:ticketinfo xmlns:D="DAV:" >
      <D:privilege><C:read-free-busy  
xmlns:C="urn:ietf:params:xml:ns:caldav"/></D:privilege>
      <D:timeout>Second-3600</D:timeout>
    </D:ticketinfo>

lisa