Subject: Re: Namespace consistency

From: [email-masked] (Howard Modell)
Date: Thu, 10 Sep 1998 13:28:27 -0700

H>From [email-masked]  Thu Sep 10 11:53:20 1998
H>Resent-Message-Id: <[email-masked]>
H>MMDF-Warning:  Parse error in original version of preceding line at paris.ics.uci.edu
H>From: Jim Whitehead <[email-masked]>
H>To: WEBDAV WG <[email-masked]>
H>Date: Thu, 10 Sep 1998 11:32:02 -0700
H>X-Priority: 3 (Normal)
H>X-MSMail-Priority: Normal
H>Importance: Normal
H>Subject: Namespace consistency
H>
H>Larry Masinter writes:
H>># DAV compliant
H>>#   resources MUST maintain the consistency of the HTTP URL namespace.
H>>
H>>Is there a definition of what 'the consistency of the HTP URL namespace'
H>>means? It's not defined anywhere, and this sentence only gives an example.
H>
H>This does appear to be an omission in the specification.
H>
H>By consistency, we meant:
H>
H>No gaps: Given HTTP URL U, for all unique HTTP URL Ux, where Ux is
H>constructed from U by removing all characters to the right of a "/", Ux MUST
H>be the HTTP URL of a WebDAV collection.
H>
H>So, if there is an HTTP URL:
H>
H>http://www.foo.bar.org/a/b/c
H>
H>Then
H>
H>http://www.foo.bar.org/a/b/
H>http://www.foo.bar.org/a/
H>
H>MUST be HTTP URLs of WebDAV collection resources.
H>
H>There are two ways to maintain this consistency when a new resource is
H>created:
H>
H>a) create intermediate collections automatically
H>b) refuse to create a resource if intermediate collections do not yet exist.
H>
H>The example in Section 4.3 implies we were recommending option b).
H>
H>Also, consistency implies:
H>
H>100% containment: Given HTTP URL U, U MUST be a member URL of the collection
H>whose URL, Uc, is contructed by removing the trailing path segment of U.
H>Exception: when U is the top-level resource, "/", of a namespace (i.e., the
H>first slash after the domain name in an HTTP URL), it belongs to no
H>collection, since it is the URI of the root collection.
H>
H>- Jim
H>

So if I have a personal webspace, ...

http://warlok.ds.boeing.com/~howie/

.. and I choose I create a "WebDAV collection" in my space, ..

http://warlok.ds.boeing.com/~howie/a/b/c

.. am I in violation of the rules above since the URL of my personal space
is NOT of and by itself the URL of a collection?

<signed>
Howard S. Modell
________________________________________________________________________
 Comptg Sys.Progr-Analyst/4           POBox 3707, m/s 4A-25, Boeing ISDS
 [email-masked]           Seattle, WA 98124-2207
 http://warlok.ds.boeing.com/~howie/  (206)662-0189[v] (206)662-4018[f]

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 11 Sep 1998 17:01:57 -0700

> is NOT of and by itself the URL of a collection?

Well, actually, the URL of http://warlok.ds.boeing.com/~howie/ is a correct
URL for a collection, since it has a trailing slash.  But, what you're
probably asking is whether the resource identified by
http://warlok.ds.boeing.com/~howie/ needs to be of type WebDAV collection.
The implication of the requirement in section 4.3 (no namespace gaps)
combined with the requirement in section 4.1 that namespaces must behave as
DAV collections even if they weren't created with WebDAV, is that yes, the
resource identified by http://warlok.ds.boeing.com/~howie/ needs to be of
type WebDAV collection if http://warlok.ds.boeing.com/~howie/a/b/c is
WebDAV-compliant.

- Jim

---

From: Jim Davis <[email-masked]>
Date: Sat, 12 Sep 1998 12:06:06 PDT

>type WebDAV collection if http://warlok.ds.boeing.com/~howie/a/b/c is

I agree that this is the implication of the protocol as it stands.

I would like to raise an objection to it, as it would prohibit one from
supporting DAV methods on anything smaller than the full namespace of a
server.    
It is often useful for various subtrees of a server's namespace to support
different sets of methods (sometimes via cgi scripts, without assistance
from the server maintainer) and there is no benefit to this restriction
(unlike the one requiring internal consistency).

I have been meaning to complain about this for a while but didn't because
it seems to be trivial.  I was having a hard time imagining anyone being so
picky as to insist on this point (and, perhaps, denying me the covetted
"100 % Pure DAV" sticker for my server?) but perhaps it's better to face it
now.  In fact, this very issue has been raised in some discussions internal
to Xerox.  People have said to me "We would like to support DAV methods in
this subtree but we don't want to support them on the root but the protocol
says we MUST do it, so can we still use DAV?".  So Howie isn't the only one
worrying about it.

I say, strike the restriction.

---

From: John Stracke <[email-masked]>
Date: Mon, 14 Sep 1998 10:51:27 -0700

> I say, strike the restriction.

I agree.  If we do, then even someone with an ordinary ISP account could run
DAV on their account, given a CGI implementation.

Also, consider that DAV is a potential security risk (depending on the
implementation, of course), so there will be people who want to have only some
areas of their server run DAV extensions.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|Both candidates  |
|Software Retrophrenologist|=======================/are better than a|
|Netscape Comm. Corp.      |megalomaniac mutant lab mouse bent on    |
[email-masked]      |world domination...but it's pretty close.|
\====================================================================/
New area code for work number: 650