Re: AW: DAV:principal-URL

[Julian Reschke <[e-mail]>]

Wilfredo Sánchez Vega wrote:
> 
>   The reason I brought this up was that is affects 
> draft-sanchez-webdav-current-principal-00 which I submitted.
> 
>   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.

Let's assume that the principal URL can be something like a mailto: URL.

As far as I understand, RFC 3744 requires to use the principal URL in 
the ACL request, and it would be very strange if it didn't come back in 
the DAV:acl property.

So assuming we'd have a mailto URL in all these places, how can a client 
- in general - find the associated HTTP URL? The 
DAV:principal-property-search report *could* do that, as long as the 
server supports searching on the DAV:principal-URL property.

Geoff said:

GC>  If we believe that it is reasonable to require that the 
DAV:principal-URL be an HTTP URL, then I'm fine with just requiring this 
in RFC3774bis.
GC> If we don't require that, then I don't think we can require that 
there be a way to "find" that principal, since as you say, if you can 
find it using the information in the DAV:principal-URL, you should have 
been able to format that information as an HTTP URL.

...so I'm really tempted to state that, after all, the principal URL 
needs to be an HTTP URL.

However, Section 2 states:

"A URI of any scheme MAY be used to identify a principal resource. 
However, servers implementing this specification MUST expose principal 
resources at an http(s) URL, which is a privileged scheme that points to 
resources that have additional properties, as described in Section 4. 
So, a principal resource can have multiple URIs, one of which has to be 
an http(s) scheme URL. Although an implementation SHOULD support 
PROPFIND and MAY support PROPPATCH to access and modify information 
about a principal, it is not required to do so."

So if a server chooses not to fulfill "SHOULD support PROPFIND", what 
would that buy us?

Is anybody aware of a server that exposes principals as non-HTTP 
resources, or as HTTP resources not supporting PROPFIND?

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?


BR, Julian