- From: Clemm, Geoff <gclemm@rational.com>
- Date: Fri, 29 Jun 2001 14:01:34 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
From: Jason Coward [mailto:jason.coward@mongoosetech.com] BTW, what constitutes a "namespace" in DAV, I'm still not totally clear on this. Would the namespace be the URL prefix (before the DAV resource portion of the URI) without the host (i.e. /portal/dav) or would it be (/dav) or is it something totally different? A "namespace" in DAV is just an HTTP namespace, i.e. a hierarchical namespace where "/" delimits segments of the namespace (see Section 5.1 of RFC 2518). Perhaps you are thinking of what DAV calls a "consistent" namespace? A consistent namespace is one where every resource is a member of the collection that contains it, or as section 5.1 states: "for every URL in the HTTP hierarchy there exists a collection that contains that URL as an internal member". (Now we all know that the internal members of a collection are resources, and not URLs, but let's not go there right now :-). | The public access URL is not very nice though (people want to just go | to http://localhost/), so the URI for / might relocate the user down | into /public/... We would handle this by having the root URL be an index page that redirects appropriately based on user context (including authentication/authorization credentials, device, language preferences, browser version, etc.). Note though that this might make it challenging to support interoperable locking semantics, since locks are URL based. If the redirecting is always to the same place while the client holds the lock token (which is likely to be the case), it probably won't be bad in practice. In particular, I might be inclined to forward/redirect the "public" request to "/" to a public collection inside the DAV namespace (proper usage?) that contained BINDings, which are essentially symbolic links to other DAV resources that can maintain properties such as access control permissions, separate from those defined on the target of the link. I assume by BINDings, you are referring to what is described in the BIND protocol? If so, the result of a BIND call is like a Unix hard link, not like a symbolic link, because a BIND call does not create a new resource, and does not maintain properties, such as access control permissions, that are separate from those defined on the target of the binding. Cheers, Geoff
Received on Friday, 29 June 2001 13:55:09 UTC