Subject: RE: Namespace consistency

From: Jim Amsden <[email-masked]>
Date: Mon, 14 Sep 1998 19:19:50 -0400

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

It should be possible to configure a DAV server to have a document root
contained in "collection" that is not DAV compliant. For example, I use the
Java Web Server's doc.root of c:\some-path\public-html and set the doc.root for
my authoring web server to be c:\some-path\public-html\dav. This keeps the
authoring server and the production server out of each other's way, but uses
the same file system root for both. Other configurations are possible. The -08
spec does not prevent this, it only leaves it as a server option.

---

From: John Stracke <[email-masked]>
Date: Mon, 14 Sep 1998 17:26:56 -0700

Jim Amsden wrote:

> my authoring web server to be c:\some-path\public-html\dav.

Yeah, but then you can't use the same URI for authoring as for browsing, in which
case you might as well author via FTP.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |Beware of wizards, for you are crunchy   |
[email-masked]      | and good with ketchup.                  |
\====================================================================/
New area code for work number: 650

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 14 Sep 1998 18:59:14 -0700

I wrote:
> 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 Davis wrote:
> I agree that this is the implication of the protocol as it stands.

Yaron Goland wrote:
> Actually no, http://foo/bar does NOT have to be a collection just because
> http://foo/bar/blah is a collection.

Jim Davis wrote:
> I say, strike the restriction.

Mark Fisher wrote:
> Based on my experiences as a webmaster, I'd agree.

John Stracke wrote:
> I agree.

I am quite happy to alter the language of the -08 spec. so that the correct
meaning of these requirements is expressed, rather than the virus-like
behavior that the spec. can be read to imply, which people object to.

What I read from this rough consensus on the list is people would like the
language to read that a parent of a resource does not have to be a
WebDAV-collection.  However, if the parent of a WebDAV resource is itself
WebDAV compatible, then it has to be a WebDAV collection.

A couple of questions:

1) Should there be a policy for whether the parent of a resource must exist?
So, if http://foo/bar/blah exists, and is DAV-compliant, must resource
http://foo/bar/ exist?

My answer: Since we're not requiring the parent of a DAV resource to be a
DAV collection, there is no guarantee that a client will be able to retrieve
a listing of the other resources at a given level in the HTTP URL hierarchy.
Due to this, there isn't much of a difference between getting a 501 Not
Implemented for an existing resource that doesn't support PROPFIND, or
getting a 404 Not Found for a non-existing resource -- either way the client
won't be able to get an index.

So, my answer is that we shouldn't require a DAV-compliant resource to have
a parent resource.

2) Larry Masinter's question (intermediate collections):

> Must the intermediaries also be DAV compliant? Well, for one level
> it doesn't matter, but suppose:
>
> 1)  http://foo/bar is DAV compliant
> 2)  http://foo/bar/a/b/c/blah/ exists and is DAV compliant
> 3)  then must http://foo/bar/a/b be a (DAV-compliant) collection?
>
> This would leave out the possibility that http://foo/bar/a might
> be some kind of mapping? Or is it that "exists" needs elaboration
> to except that case where it's a redirection?

My answer: I think we should require all collections below a DAV-compliant
resource to also be DAV-compliant.  So, while it's OK to not be
DAV-compliant looking up a hierarchy tree, looking down the tree from a
DAV-compliant location should always be DAV-compliant.  This way DAV clients
will be able to get listings of the members of a collection once they're in
a DAV compliant portion of the namespace while going down the namespace
hierarchy, providing a less confusing user experience than if the behavior
of the namespace changed from level to level.

- Jim

---

From: Jim Davis <[email-masked]>
Date: Mon, 14 Sep 1998 19:41:32 PDT

>.. my answer is that we shouldn't require a DAV-compliant resource to have
>a parent resource.

Fine with me.  (Don't care much either way.)

> I think we should require all collections below a DAV-compliant
>DAV-compliant location should always be DAV-compliant. 

Strongly agree.

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 14 Sep 1998 20:43:56 PDT

> >DAV-compliant location should always be DAV-compliant. 

So a DAV-compliant resource can't be, say, a CGI script? Even in
'advanced DAV'?

If I have http://a/b/c/ and I want to add a CGI such that
 http://a/b/c/d is indirectly http://a/b/c/d.cgi, where
'd.cgi' computes a query, you might have http://a/b/c/d?e .
Now, is http://a/b/c/d.cgi a 'member' of http://a/b/c/ ?

Larry
--
http://www.parc.xerox.com/masinter

---

From: Jim Davis <[email-masked]>
Date: Tue, 15 Sep 1998 10:45:53 PDT

At 08:43 PM 9/14/98 PDT, Larry Masinter wrote:
>> Jim Whitehead wrote:

Hmm, I he did say all _collections_ below a DAV compliant resource, not all
resources of any kind.   But since 'collection' is a term defined by DAV,
what would it mean to be a 'collection' that is not 'DAV'.  Jim, did you
mean 'resource', or did you mean 'namespace' (in the HTTP sense, not XML).

I was assuming he meant 'namespace'.

On the other hand, what about the stronger claim (that all resources within
a collection must be DAV compliant).  It's not unreasonable.  What does it
mean to do PROPFIND on collection a/b/c, discover that it includes resource
a/b/c/d, but that one can't do PROPFIND on a/b/c/d?

>So a DAV-compliant resource can't be, say, a CGI script?

Of course it can be a CGI script.  That's one reason that DAV has source
links.  What do you see that would prohibit this?

>Now, is http://a/b/c/d.cgi a 'member' of http://a/b/c/ ?

I don't understand what you mean by 'indirectly' enough to speak to that,
but if a PROPFIND on http://a/b/c/d includes http://a/b/c/d.cgi, then 
d.cgi is a member of a/b/c.  Otherwise, not, because there is no other DAV
way to traverse the URL namespace except by issuing PROPFINDs.

---

From: John Stracke <[email-masked]>
Date: Tue, 15 Sep 1998 11:05:02 -0700

Jim Davis wrote:

> Of course it can be a CGI script.

That could be very difficult to implement, though.  If http://foo/bar/baz.cgi
is a CGI script, then http://foo/bar/baz.cgi/quux.html is a perfectly legal
URI as far as the protocol's concerned.  If descendants of DAV collections
must be DAV, then baz.cgi must implement all DAV methods in order for
quux.html to be compliant.  Of course, the server's DAV implementation can
provide helper code for baz.cgi to use, but it could still get pretty nasty.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      |"The avalanche has already started. It is|
[email-masked]      | too late for the pebbles to vote." -Kosh|
\====================================================================/
New area code for work number: 650

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Sep 1998 18:47:25 -0700

>Yeah, but then you can't use the same URI for authoring as for browsing,
>in which case you might as well author via FTP.

I've been meaning to get back to this comment all week.  Using the same
URI for authoring as for browsing should not be considered an "advantage"
of WebDAV.  In fact, it isn't an advantage at all.  The real advantage
of WebDAV is that it is able to respond accurately when a user attempts
to modify a derived resource instead of the source, and is able to control
access to its namespace via an authentication mechanism that is not based
on login names.  Assuming the URI would be the same for both authoring
and retrieving of resources is contrary to good site design, wherein the
name assigned to a resource is independent of its implementation.

The Web is not a distributed file system, a fact that has a whole set
of advantages and disadvantages.  However, I'd hope that a WebDAV
capable system would not puke and die if it was given a redirect to
the source resource that happened to be an ftp URL.  I'm not saying
that clients should be required to support such authoring modes, but
there are countless reasons why it would be a good idea.

....Roy

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Sep 1998 09:48:24 -0700

"Roy T. Fielding" wrote:

> of WebDAV.  In fact, it isn't an advantage at all.

Of *course* it is! If you have an authoring tool that's integrated with your
browser (at least to the extent of being able to send it "go to this URI"
commands), that's going to make it a *lot* easier to test the content you've
developed.  If the browser can't use the same URI as the authoring tool, then
you're going to have to do the translation by hand (which is essentially what
I have to do with Netscape Composer today, since my ISP doesn't support HTTP
PUT), or else teach the authoring tool to remap URIs that it sends to the
browser (possible, but messy).

--
/======================================================================\
|John (Francis) Stracke    |My opinions are my own.| S/MIME supported  |
|Software Retrophrenologist|===========================================|
|Netscape Comm. Corp.      |Id est fabula nostra, et non mutabimus eam!|
[email-masked]      | --House Falconguard and Affiliated Scum   |
\======================================================================/
New area code for work number: 650