On Feb 13, 2006, at 2:45 , Brian Moseley wrote:
On 2/13/06, Jeffrey Harris <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
