Cyrus Daboo wrote:
Hi Frank,
--On December 9, 2006 7:53:56 PM +0100 Frank Strauß <strauss@ibr.cs.tu-bs.de> 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.