Re: BugZilla issue 227: collection state

+1

Julian Reschke wrote:
> 
> Hi,
> 
> below are proposed changes for Section 5, resolving Bugzilla issue 227 
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=227>) and 
> applying editorial fixes:
> 
> 
> Section 5.1., para. 2:
> OLD:
> 
>    An HTTP URL namespace is said to be consistent if it meets the
>    following conditions: for every URL in the HTTP hierarchy there
>    exists a collection that contains that URL as an internal member.
>    The root, or top-level collection of the namespace under
>    consideration, is exempt from the previous rule.  The top-level
>    collection of the namespace under consideration is not necessarily
>    the collection identified by the absolute path '/', it may be
>    identified by one or more path segments (e.g. /servlets/webdav/...)
> 
> NEW:
> 
>    An HTTP URL namespace is said to be consistent if it meets the
>    following conditions: for every URL in the HTTP hierarchy there
>    exists a collection that contains that URL as an internal member URL.
>    The root, or top-level collection of the namespace under
>    consideration, is exempt from the previous rule.  The top-level
>    collection of the namespace under consideration is not necessarily
>    the collection identified by the absolute path '/', it may be
>    identified by one or more path segments (e.g. /servlets/webdav/...)
> 
> s/internal member/internal member URL/
> 
> 
> Section 5.2., para. 4:
> OLD:
> 
>    Although commonly a mapping consists of a single segment and a
>    resource, in general, a mapping consists of a set of segments and a
>    resource.  This allows a server to treat a set of segments as
>    equivalent (i.e. either all of the segments are mapped to the same
>    resource, or none of the segments are mapped to a resource).  For
>    example, a server that performs case-folding on segments will treat
>    the segments "ab", "Ab", "aB", and "AB" as equivalent, A client can
>    then use any of these segments to identify the resource.  Note that a
>    PROPFIND result will select one of these equivalent segments to
>    identify the mapping, so there will be one PROPFIND response element
>    per mapping, not one per segment in the mapping.
> 
> NEW:
> 
>    Although commonly a mapping consists of a single segment and a
>    resource, in general, a mapping consists of a set of segments and a
>    resource.  This allows a server to treat a set of segments as
>    equivalent (i.e. either all of the segments are mapped to the same
>    resource, or none of the segments are mapped to a resource).  For
>    example, a server that performs case-folding on segments will treat
>    the segments "ab", "Ab", "aB", and "AB" as equivalent.  A client can
>    then use any of these segments to identify the resource.  Note that a
>    PROPFIND result will select one of these equivalent segments to
>    identify the mapping, so there will be one PROPFIND response element
>    per mapping, not one per segment in the mapping.  Servers SHOULD
>    consistently use the same segment in PROPFIND responses.
> 
> Typo: "," instead of "."
> Change: added last sentence as discussed in 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2006JanMar/0677.html>
> 
> 
> Section 5.2., para. 9:
> 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:
> 
>  5.2.1.  Example - non WebDAV-compliant resource in collection
> 
>    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/".
> 
> (add subsection title so it becomes clear (again) that this is an 
> example, not a continuation of the normative text about collection srare 
> above)
> 
> 
> Section 5.2., para. 10:
> OLD:
> 
>    Some mappings to even WebDAV-compliant resources might not appear in
>    the parent collection.  An example for this case are servers that
>    support multiple alias URLs for each WebDAV compliant resource.  A
>    server may implement case-insensitive URLs, thus "/col/a" and
>    "/col/A" identify the same resource, yet only either "a" or "A" are
>    reported upon listing the members of "/col".  In cases where a server
>    treats a set of segments as equivalent, the server MUST expose only
>    one preferred segment per mapping, consistently chosen, in PROPFIND
>    responses.
> 
> NEW:
> 
>  5.2.2.  Example - URL of WebDAV-compliant resource not appearing in
>          parent collection
> 
>    Some mappings to even WebDAV-compliant resources might not appear in
>    the parent collection.  An example for this case are servers that
>    support multiple alias URLs for each WebDAV compliant resource.  A
>    server may implement case-insensitive URLs, thus "/col/a" and
>    "/col/A" identify the same resource, yet only either "a" or "A" are
>    reported upon listing the members of "/col".  In cases where a server
>    treats a set of segments as equivalent, the server MUST expose only
>    one preferred segment per mapping, consistently chosen, in PROPFIND
>    responses.
> 
> (same)
> 
> See also 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz227>. 
> 
> 
> Best regards, Julian
> 
> 
> 
> 
>

Received on Thursday, 4 May 2006 22:14:20 UTC