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).
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.
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. -- Cyrus Daboo