- From: <bugzilla@soe.ucsc.edu>
- Date: Fri, 17 Feb 2006 04:56:22 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal
Priority|P2 |P3
Version|-13 |-14
------- Additional Comments From julian.reschke@greenbytes.de 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.
Received on Friday, 17 February 2006 12:56:29 UTC