[CalendarServer-dev] use of X-CALENDARSERVER-ACCESS
cdaboo at apple.com
Mon Aug 18 09:21:30 PDT 2008
--On August 16, 2008 9:30:36 AM +0200 Helge Heß <me at helgehess.eu> wrote:
>> After a while I found caldav-privateevents.txt, which details how
>> other CalDAV servers can also unlock the private option in iCal, but
>> it doesn't explain why X-CALENDARSERVER-ACCESS was chosen over CLASS
>> in the first place.
>> Can someone explain this to me? I'm sure there's a reason.
> The CLASS value is about classification, not about access. It tells
> the user how sensitive the information is, eg whether he is allowed to
> pass it on to other people. Its like the 'top secret' printing on a
> document, it doesn't actually prevent the use of the document. Thats
> the task of a the vault which contains the (classified) document.
Correct. The precise semantics of CLASS:PRIVATE or CLASS:CONFIDENTIAL are
not defined. We wanted something that was much more specific about which
iCalendar properties would be visible to different types of user with
different levels of access.
> Anyways, I'm also a bit confused about the iCal property. Why isn't
> this done using custom WebDAV ACL permissions?
A couple of reasons:
1) It would not be possible to create a calendar object that has the
desired ACL in a single request. You would have to do a PUT followed by an
ACL, so the client would have to play tricks like write out a "stub"
calendar object first, then do the ACL, the write out the actual calendar
data. Or we would have to extend PUT by e.g. having some HTTP request
headers. By putting the access control "element" inside the calendar data
the client can do a PUT to create the resource and assign the access level
all in one request.
2) ACLs are complicated when it comes to trying to figure out what
permissions different users may have. Just seeing a e.g.
"read-private-event" privilege on a calendar resource is not necessarily
sufficient to know for sure that it is a private event. With the access
specifier in the calendar data it is immediately clear to the client what
the access level is so that it can check/uncheck the appropriate widget in
We did look at all the possibilities, CLASS, ACLs, property in iCalendar
etc and really the later was the best one for the specific goals we had
with the time constraints we had. No one is saying that this is a perfect
solution. What we would like to do is use this as a jumping off point for
more debate in the calendar community to eventually come up with a robust
standard for this type of access control that everyone could adopt and
achieve interoperability with. Actually some of the design that did go into
our implementation was based on some early discussions that had taken place
in CalConnect as to how many levels of access are needed in cases like this.
More information about the calendarserver-dev