[CalendarServer-dev] use of X-CALENDARSERVER-ACCESS

Cyrus Daboo cdaboo at apple.com
Mon Aug 18 09:21:30 PDT 2008


Hi Helge,

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

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.


-- 
Cyrus Daboo



More information about the calendarserver-dev mailing list