RE: BIND 506 status

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



-----Original Message----- 
From: Julian Reschke [mailto:julian.reschke@greenbytes.de] 
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