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 <[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.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
