W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2008

Re: AW: DAV:principal-URL

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 23 May 2008 13:10:41 +0200
Message-ID: <4836A631.7030909@gmx.de>
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.


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 

(*) Shouldn't that be "DAV:current-user-principal-URL", by the way?
Received on Friday, 23 May 2008 11:11:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:42 UTC