[CalendarServer-users] Three questions about principals

[Frank Strauß]

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

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.