[Design] 0.7 Chandler scheduling phasing proposal
grant at osafoundation.org
Mon Feb 13 15:42:45 PST 2006
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
>> 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).
More information about the Design