Subject: [Bug 26] URL syntax in PROPFIND

From: [email-masked]
Date: Tue, 18 Oct 2005 11:23:35 -0700

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Oct 2005 20:56:42 +0200

Proposed resolution for 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=26>:

As far as I can tell, the current draft of RFC2518bis changes the end of 
the description for PROPFIND from:

"All servers MUST support returning a response of content type text/xml 
or application/xml that contains a multistatus XML element that 
describes the results of the attempts to retrieve the various properties.

If there is an error retrieving a property then a proper error result 
MUST be included in the response. A request to retrieve the value of a 
property which does not exist is an error and MUST be noted, if the 
response uses a multistatus XML element, with a response XML element 
which contains a 404 (Not Found) status value.

Consequently, the multistatus XML element for a collection resource with 
member URIs MUST include a response XML element for each member URI of 
the collection, to whatever depth was requested. Each response XML 
element MUST contain an href XML element that gives the URI 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 
URIs are returned as a flat list whose order of entries is not significant.

In the case of allprop and propname, if a principal does not have the 
right to know whether a particular property exists then the property 
should be silently excluded from the response." 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.1.p.4>)

to

"All servers MUST support returning a response of content type text/xml 
or application/xml that contains a multistatus XML element that 
describes the results of the attempts to retrieve the various 
properties. The multistatus contains one response element for each 
resource in the scope of the request (in no required order) or may be 
empty if no resources match the request.

If there is an error retrieving a property then a proper error result 
MUST be included in the response. A request to retrieve the value of a 
property which does not exist is an error and MUST be noted, if the 
response uses a multistatus XML element, with a response XML element 
which contains a 404 (Not Found) status value.

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. Each response XML 
element MUST contain an href XML element that gives the URL of the 
resource on which the properties in the prop XML element are defined. 
URLs for collections appearing in the results MUST end in a slash 
character. 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.

A server enumerating the members of a collection using absolute URLs in 
a PROPFIND response MUST use a common prefix in those URLs, and that 
prefix MUST be the absolute URL used in the response to refer to the 
parent collection.

Unless otherwise notified, clients may expect that the URL for the 
parent collection in the PROPFIND response will be the same URL that was 
used to refer to the parent collection in the PROPFIND request. Servers 
MAY use an alternate URL for the parent collection in a PROPFIND 
response, but in this case the server MUST include a Content-Location 
header whose value is the fully-qualified URL used by the server to 
refer to the parent collection in this response.

URLs in a PROPFIND response body MAY be represented as fully- qualified 
URLs, in which case they must all contain the full parent collection URL 
(scheme, host, port, and absolute path). Alternatively, these URLs MAY 
be absolute paths (not containing scheme, host or port), but in this 
case they must all still contain the full parent collection path.

If a server allows resource names to include characters that arenít 
legal in HTTP URL paths, these characters must be URI-escaped on the 
wire. For example, it is illegal to use a space character or double- 
quote in a URI [5]. URIs appearing in PROPFIND or PROPPATCH XML bodies 
(or other XML marshalling defined in this specification) are still 
subject to all URI rules, including forbidden characters.

Properties may be subject to access control. In the case of allprop and 
propname, if a principal does not have the right to know whether a 
particular property exists then the property MAY be silently excluded 
from the response." 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.2.p.7>)

The problems that I see here are

- it makes statements about the multistatus format, which applies to 
other methods than PROPFIND as well,

- consequently, it repeats lots of things that appear in section 12 
("multistatus") in different words

- it throws in discussion of escaping "native" resource names to URIs, 
which is really a completely different topic (and again has nothing to 
do with PROPFIND at all)

- it makes a new MUST-level requirement about collection URLs ending in 
slashes that as far as I can tell has no WG consensus

- it incorrectly claims that PROPFIND may result in an empty multistatus 
element

My proposal would be to remove all of these changes, but to add a 
forward reference to section 12 instead. We then should concentrate on 
getting section 12 right (which, funny enough, has it's own ticket 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=46>).

So the proposed change would be:

Section 8., para. 30:
OLD:

    All servers MUST support returning a response of content type text/
    xml or application/xml that contains a multistatus XML element that
    describes the results of the attempts to retrieve the various
    properties.  The multistatus contains one response element for each
    resource in the scope of the request (in no required order) or may be
    empty if no resources match the request.

NEW:

    All servers MUST support returning a response of content type text/
    xml or application/xml that contains a multistatus XML element that
    describes the results of the attempts to retrieve the various
    properties.

Section 8., para. 32:
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.  Each
    response XML element MUST contain an href XML element that gives the
    URL of the resource on which the properties in the prop XML element
    are defined.  URLs for collections appearing in the results MUST end
    in a slash character.  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.

NEW:

    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.  Each
    response XML element MUST contain an href XML element that gives the
    URL of the resource on which the properties in the prop XML element
    are defined (see Section 13.15 for a discussion of allowable values
    inside the href elements).  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.

Section 8., para. 33:
OLD:

    A server enumerating the members of a collection using absolute URLs
    in a PROPFIND response MUST use a common prefix in those URLs, and
    that prefix MUST be the absolute URL used in the response to refer to
    the parent collection.

    Unless otherwise notified, clients may expect that the URL for the
    parent collection in the PROPFIND response will be the same URL that
    was used to refer to the parent collection in the PROPFIND request.
    Servers MAY use an alternate URL for the parent collection in a
    PROPFIND response, but in this case the server MUST include a
    Content-Location header whose value is the fully-qualified URL used
    by the server to refer to the parent collection in this response.

    URLs in a PROPFIND response body MAY be represented as fully-
    qualified URLs, in which case they must all contain the full parent
    collection URL (scheme, host, port, and absolute path).
    Alternatively, these URLs MAY be absolute paths (not containing
    scheme, host or port), but in this case they must all still contain
    the full parent collection path.

    If a server allows resource names to include characters that aren't
    legal in HTTP URL paths, these characters must be URI-escaped on the
    wire.  For example, it is illegal to use a space character or double-
    quote in a URI [5].  URIs appearing in PROPFIND or PROPPATCH XML
    bodies (or other XML marshalling defined in this specification) are
    still subject to all URI rules, including forbidden characters.

    Properties may be subject to access control.  In the case of allprop
    and propname, if a principal does not have the right to know whether
    a particular property exists then the property MAY be silently
    excluded from the response.

NEW:

    Properties may be subject to access control.  In the case of allprop
    and propname, if a principal does not have the right to know whether
    a particular property exists then the property MAY be silently
    excluded from the response.

Best regards, Julian

--- draft-ietf-webdav-rfc2518bis-latest.xml	2005-10-18 19:36:56.000000000 +0100
+++ draft-ietf-webdav-rfc2518bis-latest.26.xml	2005-10-18 19:49:47.000000000 +0100
@@ -1308,9 +1308,7 @@
    All servers MUST support returning a response of content type 
    text/xml or application/xml that contains a multistatus XML element 
    that describes the results of the attempts to retrieve the various 
-   properties.  The multistatus contains one response element for each 
-   resource in the scope of the request (in no required order) or may
-   be empty if no resources match the request. 
+   properties. 
     </t>
     <t>
    If there is an error retrieving a property then a proper error 
@@ -1325,42 +1323,11 @@
    URL of the collection, to whatever depth was requested. Each 
    response XML element MUST contain an href XML element that gives the 
    URL of the resource on which the properties in the prop XML element 
-   are defined.  URLs for collections appearing in the results MUST end 
-   in a slash character.  Results for a PROPFIND on a collection 
+   are defined (see <xref target="multistatus"/>
+   for a discussion of allowable values inside the href elements).  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. 
-    </t>
-    <t>
-   A server enumerating the members of a collection using absolute URLs 
-   in a PROPFIND response MUST use a common prefix in those URLs, and 
-   that prefix MUST be the absolute URL used in the response to refer 
-   to the parent collection.  
-    </t>
-    <t>
-   Unless otherwise notified, clients may expect that the URL for the 
-   parent collection in the PROPFIND response will be the same URL that 
-   was used to refer to the parent collection in the PROPFIND request.  
-   Servers MAY use an alternate URL for the parent collection in a 
-   PROPFIND response, but in this case the server MUST include a 
-   Content-Location header whose value is the fully-qualified URL used 
-   by the server to refer to the parent collection in this response.   
-    </t>
-
-    <t>
-   URLs in a PROPFIND response body MAY be represented as fully-
-   qualified URLs, in which case they must all contain the full parent 
-   collection URL (scheme, host, port, and absolute path).  
-   Alternatively, these URLs MAY be absolute paths (not containing 
-   scheme, host or port), but in this case they must all still contain 
-   the full parent collection path. 
-    </t>
-    <t>
-   If a server allows resource names to include characters that aren't 
-   legal in HTTP URL paths, these characters must be URI-escaped on the 
-   wire. For example, it is illegal to use a space character or double-
-   quote in a <xref target="RFC2396">URI</xref>.  URIs appearing in PROPFIND or PROPPATCH 
-   XML bodies (or other XML marshalling defined in this specification) 
-   are still subject to all URI rules, including forbidden characters. 
+   order of entries is not significant.  
     </t>
     <t>
    Properties may be subject to access control. In the case of allprop 
@@ -3923,7 +3890,7 @@
     
   </section>
   
-  <section title="multistatus XML Element">
+  <section title="multistatus XML Element" anchor="multistatus">
        <t><list style="hanging">
       <t hangText="Name: ">multistatus</t>
   <t hangText="Namespace: ">DAV:</t>