- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 23 May 2008 13:10:41 +0200
- To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- CC: Cyrus Daboo <cyrus@daboo.name>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, acl@webdav.org, Konstantin Breu <Konstantin.Breu@gmx.net>, 'WebDAV' <w3c-dist-auth@w3.org>
Wilfredo Sánchez Vega wrote: >> Going back to Wilfredo's mail...: >> >> > I had hoped to require that the principal URL returned in the >> > current-user-principal-resource property MUST be the same as the >> > principal-url property on the resource at that URL. That would avoid >> > requiring a client from having to fetch the >> > current-user-principal-resource property on a DAV resource, then fetch >> > the principal-url from there in order to know what to use in ACEs. >> > That's only feasible if the principal-url property must also be an >> > http(s) URL. >> >> Why wouldn't that work for servers that in fact do not have any WebDAV >> enabled principal resources? > > I agree with your comments, but don't understand this question. > There's no point in trying to discover the URL to your principal > resource if the server doesn't support them, since it wouldn't implement > the extension I proposed. Hm. OK, let's assume a server that has only one URI per principal, and that URI is a mailto URI. Obviously, you wouldn't able to PROPFIND the DAV:principal-URL property. The mailto URIs would be exposed in ACLs. DAV:current-user-principal-resource (*) would show expose the mailto URI. So, what would be the problem here with respect to your extension BR, Julian PS: I don't think that would be a terrible useful impl, I'm just trying to understand your previous statement about needing HTTP URIs for your extension. (*) Shouldn't that be "DAV:current-user-principal-URL", by the way?
Received on Friday, 23 May 2008 11:11:24 UTC