Re: [Bug 26] URL syntax in PROPFIND

I agree some of the text on PROPFIND can be moved to the section on  
Multi-Status.   I had been cleaning that up and clearly hadn't  
finished.  I'll take this opportunity to clean both sections up.  I  
think the section on general Multi-Status usage is now big enough to  
warrant a few sub-sections which you'll see shortly.  It's probably not  
done yet, of course.

One point of confusion, you lost me on the reference to section 13.15.  
How does that discuss what's allowable in <href>?

Lisa

On Oct 18, 2005, at 11:56 AM, Julian Reschke wrote:

> 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>

Received on Wednesday, 16 November 2005 02:47:59 UTC