- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 10 Feb 2006 17:16:09 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227 lisa@osafoundation.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|lisa@osafoundation.org |elias@cse.ucsc.edu Status|ASSIGNED |NEW ------- Additional Comments From lisa@osafoundation.org 2006-02-10 17:16 ------- Wow, I think I understood the meaning of the last paragraph there for the first time when I tried to restate it. I think I finally got it when I imagined a use case -- a collection might have a dynamically generated HTML child which is not a valid WebDAV resource, but is still a valid HTML resource. Thus I tried to illustrate the paragraph with such a use case. So this is how I thought to explain it: Collection resources MAY have internal members with mappings to non-WebDAV compliant children in the HTTP URL namespace hierarchy but are not required to do so. For example, if the resource X with URL "http://example.com/bar/index.html" is not WebDAV compliant and the resource with URL "http://example.com/bar/" identifies a collection, then collection "bar" might or might not have an internal member with a mapping from "index.html" to the resource X. If the collection doesn't have such an internal member, presumably the consequence is that the "index.html" resource might not show up in PROPFIND responses, might not be locked when the collection is locked, might not have WebDAV properties, and so on. It seems this wide range of behaviorts might be harmful to interoperability. What if the server decided to list the resource in PROPFIND responses but didn't give it properties, or left it unlisted but forbade PUT requests to the binding segment, and so on. Have we seen any WebDAV servers which do this, which have bindings to non-WebDAV members? Is it interoperable? If not, should we discourage this behavior? Assigning to Elias so he can schedule discussion if necessary. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 11 February 2006 01:16:54 UTC