Re: AW: DAV:principal-URL

On May 21, 2008, at 6:59 AM, Julian Reschke wrote:

> 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.

   Right, and having to do that query, which may not be supported  
anyway, doesn't seem like a good solution.

> 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.

   Agreed.

> 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?

   I guess I can only be concerned about those who do, since there is  
little point in getting a principal URI if you can't query it for  
information, other than to use it in ACEs, but I think such use is  
limited unless you have some way to map principal URLs to something  
you know about.

> 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.

	-wsv

Received on Thursday, 22 May 2008 17:26:50 UTC