Subject: BIND 506 status

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 11 Oct 2002 15:30:56 -0400

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]

I think the following rules must be obeyed:

- for any given HTTP GET header, PROPFIND depth 0 must return the same
values as DAV properties as a HEAD (with the same request headers) would
have

- PROPFIND depth 1 must produce the union of response elements of a) the
request URI and b) -- if the request URI identifies a WebDAV collection --
all it's internal direct members

- Any response element appearing in a multistatus response for depth > 1
should be the same if a PROPFIND depth 0 is made directly on it's URL

So,

- as there's really no problem with the resource
http://www.somehost.com/Coll/Bar, it should be reported as OK (200) or with
no status (this really is a multistatus minimization for the case where
properties are reported)

- equally, there's really no problem with the properties on the resource --
for instance, I should be able to PROPFIND the DAV:getlastmodified date even
if the collection contains a bind to itself

Basically, this is a problem similar to the one that has been discussed
before: what to do when PROPFIND wants to traverse a collection, but doesn't
have the access rights to do so: there is simply no spec-compliant way to
report that problem, so the consensus was not to report it at all.

In this case, I now lean to an extension that would be invisible to "old"
clients, and that also could be used to indicate the ACL problem mentioned
above.

For instance we could define preconditions for the traversal of the
children:

DAV:resource-must-only-occur-once: in a multistatus response body, each
resource must be only reported once

And then use a new element to marshall this kind of information

  <D:response>
      <D:href>http://www.somehost.com/Coll/Bar/</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Loop Demo</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
      <D:child-status>

<D:resource-must-only-occur-once><D:href>http://www.somehost.com/Coll/</D:hr
ef></D:resource-must-only-occur-once>
      </D:child-status>
   </D:response>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 11 Oct 2002 15:42:23 -0400

If we handled it the way proposed below, the old clients will just ignore
the new element, and the user will incorrectly conclude that the collection
had no child by that name.  With the original proposal, users of
old clients will be told that there is a child, and will get the
error message that they've already seen that child, so it is
being left out of the report.  I think the later is preferable.

Cheers,
Geoff