- From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- Date: Thu, 1 Feb 2007 16:21:55 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Cyrus Daboo <cyrus@daboo.name>, "'acl@webdav.org'" <acl@webdav.org>, WebDAV <w3c-dist-auth@w3.org>
On Jan 31, 2007, at 10:55 AM, Julian Reschke wrote: > Cyrus Daboo schrieb: > >> The problem with that is that it not only returns the current >> user's principal, but any group principal that one is a member of. >> So how would you know from those which was the actual user >> principal? i.e. this approach is not 100% reliable. > > Well, you can easily filter out groups, but in the end you may still > end up with more than one resource. Filtering out groups is not correct. Nothing says that a user's principal can't also be a group; a user can have members. >> If there really isn't a way to reliably do this now, I would >> propose the following: define a new DAV:self-principal-resource (or >> just DAV:self) property that is available on any resource >> supporting ACL and which contains a single DAV:href pointing to the >> principal resource for the currently authorized user (or is empty >> if anonymous). > > I think the spec would have defined exactly that would there have > been a consensus that this kind of definition always is meaningful. So would it be reasonable to define this in an extention where we can define it meaningfully? Some background: In the context of CalDAV, some of us are considering the value of having one URL you can give to any user with which a CalDAV client can be configured to find your calendar server and take it from there. This requires that at least one (ideally any) CalDAV resource on the server be able to tell the connecting user where their principal resource is. The reason for that it that the principal has some important information that a client needs to bootstrap itself. In particular, it defined a property which tells the client where the user's home collection is, and another listing the valid calendar user addresses (needed to know who "I" am in the context of iTIP messages). What we are doing at Apple right now is we give each user the URL to their principal. This is no big deal if you can rely on a directory system to find that, but even then, it's a bit of an administrative bother. We're defining a string template from which you can compute this URL from other data about the user in the directory (eg. username). It's putting the directory in a position of needing to know something about the URL schema of the calendar server. Much easier would be to give all users the same URL (eg. the root resource) and give the client a way to locate the principal themselves. -wsv
Received on Friday, 2 February 2007 00:22:25 UTC