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

From: [email-masked]
Date: Fri, 17 Feb 2006 04:56:22 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
           Priority|P2                          |P3
            Version|-13                         |-14

------- Additional Comments From [email-masked]  2006-02-17 04:56 -------
Thanks for integrating most of the proposed stuff (thus lowering the prio).
Remaining concerns/proposals (see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz227>):

Section 5.2., para. 8:
OLD:

    A typical scenario in which mapped URLs do not appear as members of
    their parent collection is the case where a server allows links or
    redirects to non-WebDAV resources.  For instance, "/col/link" might
    not appear as a member of "/col/", although the server would respond
    with a 302 status to a GET request to "/col/link", thus the URL
    "/col/link" would indeed be mapped.  Similarly, a dynamically-
    generated page might have a URL mapping from "/col/index.html", thus
    this resource might respond with a 200 OK to a GET request yet not
    appear as a member of "/col/".

NEW:

    [[anchor7: Please re-insert subsection title here so that it's clear
    where normative text ends and examples start.]]

    A typical scenario in which mapped URLs do not appear as members of
    their parent collection is the case where a server allows links or
    redirects to non-WebDAV resources.  For instance, "/col/link" might
    not appear as a member of "/col/", although the server would respond
    with a 302 status to a GET request to "/col/link", thus the URL
    "/col/link" would indeed be mapped.  Similarly, a dynamically-
    generated page might have a URL mapping from "/col/index.html", thus
    this resource might respond with a 200 OK to a GET request yet not
    appear as a member of "/col/".

Section 9.1., para. 11:
OLD:

    Consequently, the 'multistatus' XML element for a collection resource
    with member URLs MUST include a 'response' XML element for each
    member URL of the collection, to whatever depth was requested.  It
    SHOULD NOT include any 'response' elements for resources that are not
    WebDAV-compliant.  Each 'response' element MUST contain an 'href'
    element that contains the URL of the resource on which the properties
    in the prop XML element are defined.  Results for a PROPFIND on a
    collection resource with internal member URLs are returned as a flat
    list whose order of entries is not significant.  Note that a resource
    may have only one value for a property of a given name, so the
    property may only show up once in PROPFIND responses.

NEW:

    Consequently, the 'multistatus' XML element for a collection resource
    MUST include a 'response' XML element for each member URL of the
    collection, to whatever depth was requested.  It SHOULD NOT include
    any 'response' elements for resources that are not WebDAV-compliant.
    Each 'response' element MUST contain an 'href' element that contains
    the URL of the resource on which the properties in the prop XML
    element are defined.  Results for a PROPFIND on a collection resource
    are returned as a flat list whose order of entries is not
    significant.  Note that a resource may have only one value for a
    property of a given name, so the property may only show up once in
    PROPFIND responses.

(simplify and fix language, for instance, "Results for a PROPFIND on a
collection resource with internal member URLs are returned as a flat" is plain
wrong; it also applies to non-internal member URLs; generally, having the
"with...member URLs" inserts is just unnecessary and confusing).

Reminder: we also need to take care of the problem mentioned in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0641.html>.

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