Subject: [Bug 227] Collection state definition in conflict between BIND and RFC2518bis

From: [email-masked]
Date: Tue, 14 Feb 2006 12:30:56 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|-12                         |-13

------- Additional Comments From [email-masked]  2006-02-14 12:30 -------
Comments in pre-draft (-13) as of 2006-02-13:

Section 5.2., para. 3:
OLD:

    When a WebDAV resource has a URL U, such that U is the same as URL V
    plus a single additional path segment, then if the resource
    identified by V is WebDAV compliant it MUST be a collection that has
    U as an internal member URL.  For example, if
    "http://example.com/bar/blah" is a WebDAV resource, then if
    "http://example.com/bar/" is WebDAV compliant, it MUST be a
    collection and MUST contain "http://example.com/bar/blah" as an
    internal member.

NEW:

    For all WebDAV compliant resources A and B, identified by URLs "U"
    and "V" respectively, such that "V" is equal to "U/SEGMENT", A MUST
    be a collection that contains a mapping from "SEGMENT" to B. So, if
    resource B with URL "http://example.com/bar/blah" is WebDAV compliant
    and if resource A with URL "http://example.com/bar/" is WebDAV
    compliant, then resource A must be a collection and must contain a
    mapping from "blah" to B.

(I think the text proposed by Geoff ("NEW") is slightly more readable; if the
current text is kept, "WebDAV resource" probably should be replaced by "WebDAV
compliant resource").

Section 5.2., para. 4:
OLD:

    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.

NEW:
    Collection resources MAY have mappings to non-WebDAV compliant
    resources 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/blah" is not WebDAV compliant and the
    resource A with "URL http://example.com/bar/" identifies a
    collection, then A may or may not have a mapping from "blah" to X.

Again, I think the NEW text is more readable. Furthermore, the 2nd part of the
current spec text is incorrect; if "http://example.com/bar/index.html" is not an
 internal member URI, then it *will* not appear in a PROPFIND response (and so on).

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.