Subject: RE: Recommendations for integrating WebDAV and other applications

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 29 Jun 2001 14:01:34 -0400

From: Jason Coward [mailto:[email-masked]]

   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