Cyrus Daboo wrote: > Hi Frank, > > --On December 9, 2006 7:53:56 PM +0100 Frank Strauß > <[EMAIL PROTECTED]> wrote: > >> What is the purpose of group and resource principals having a password? > > Whilst there may not be "humans" directly posing as a group or a > resource, and "automated system" might. e.g,. a meeting room has a > little hardware device with LCD screen on its door. This device is a > calendar client that displays the current bookings for the room by > accessing the CalDAV calendar for the resource. The device is programmed > to login as the resource. > > (I've actually seen hardware devices like that, though they did not have > CalDAV support).
Ah, thanks for the inspiration: We actually have a panel PC at an iMac pool of our institute, which primarily controls a self-made door unlocking mechanism upon user authentication against our user directory. I could imaging to allow people to access a room calendar via this panel PC, also. Furthermore, I just read parts of RFC 3744. I think now I better understand why the term "principal" was introduced, instead of talking about users. Thanks! However, I still cannot imagine what kind of entity could act as a group principal. Can you help my imagination? >> Is there a way to configure the repository, so that anonymous access is >> allowed (to make some public calendars accessible to anyone) but without >> exposing the identities of all users and groups through the /calendars/ >> and /principals/ hierarchies? > > You can edit repository.xml to include a "/calendars/public" hierarchy > and add DAV:all, DAV:read inheritable privileges for that. Note that you > could use WebDAV protocol to create the collection and set the ACLs via > a client, but the "inheritable" option is a private extension we have > and not exposed. Thanks. Ok. My question was related to the ACLs of the "magically" provisioned /principals/ and /calendars/ hierarchies (whithout making the whole store anonymously unaccessible). >> I think, I vaguely understand the purpose of resources in VEVENTs. But >> what is the purpose of resource *principals*? (Without knowing any >> better, I would probably model some resources as calendars with an >> appropriate ACL, e.g., if I would like to keep an eye on free/busy times >> of a room.) > > A resource needs to have a principal associated with it if it is to > partake in scheduling operations (i.e. you want to book a meeting room > at the same time you send out an invite to attendees). Since CalDAV > scheduling operations rely on principal properties (e.g., > schedule-inbox-URL, calendar-user-address-set etc) there has to be a > principal for every "schedulable" entity on the server. Thanks a lot for the explanation. _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
