Re: AW: DAV:principal-URL

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?