[CalendarServer-users] Errors with group based access control

Frank Strauß strauss at ibr.cs.tu-bs.de
Fri Dec 15 02:10:47 PST 2006

Wilfredo Sánchez Vega wrote:
> Just FYI-
>   The server on trunk no longer uses the CalendarPrincipalURI attribute 
> on users, groups, and resources; all records are presently provisioned 
> regardless of whether this attribute or present or not.
>   The reason for this is that we are going to implement a new directory 
> schema, which is still in the works.  We found that having the server 
> host name in the user records was kind weak, because if you change the 
> host name, you have to update all of your user records.  So we'll be 
> using some intermediate record type to store server access information 
> and point the user records at that.

I'm not sure whether such an indirection would really make life easier.
If some LDAP client wants to get information on a user, this information 
is usually available by a request on the user's LDAP entry, and that's all.

For example, if I want to get Frank's email address, I request the 
attribute "email" from my entry on our LDAP server and get back 
"strauss at ibr.cs.tu-bs.de". That's it. It's not that I just get "strauss" 
and a pointer to another piece of information that will tell me that our 
institute currently has the email domain name "ibr.cs.tu-bs.de". The 
domain name is a kind of information that is hopefully well chosen when 
it was introduced and that changes very very rarely. So the benefit of 
easy access to the full email address is more important than an easy way 
to change it sometime in the future. And even _if_ we would have to 
change it, a simple script would do the job easily in the LDAP database. 
All the places out there where this information is already stored cannot 
be changed, anyway.

I think the same holds true for calendar principal URIs. I would prefer 
to add a note to the server documentation that the CalDAV server name 
should be well chosen (e.g., a "role name" like cal.ibr.cs.tu-bs.de, not 
the canonical host name) and keep the directory schema simple as it is now.

Just my $.02

PS: Just curious: Are there counter examples where such a kind of
     indirection is already modeled in LDAP schemas?

More information about the calendarserver-users mailing list