Hi Helge, --On August 16, 2008 9:30:36 AM +0200 Helge Heß <[EMAIL PROTECTED]> 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 _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
