[CalendarServer-users] Three questions about principals

[Cyrus Daboo]

Hi Frank,

--On December 9, 2006 7:53:56 PM +0100 Frank Strauß 
<strauss at 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