- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Mon, 12 Nov 2007 11:29:30 -0500
- To: WebDAV <w3c-dist-auth@w3.org>
- Message-ID: <OF7FC10F81.6CD7BA63-ON85257391.005A4D8D-85257391.005A97E2@us.ibm.com>
All of the changes described below are fine with me.
Cheers,
Geoff
w3c-dist-auth-request@w3.org wrote on 11/11/2007 02:52:16 PM:
>
> (see
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.
> issue.2.1.1-bind-loops>)
>
> This is a simple clarification: when talking first about the potential
> of bind loops (cycles), state that a server is free to reject requests
> that would create them.
>
> Proposal to add:
>
> "Support for loops is OPTIONAL: servers MAY reject requests that would
> lead to the creation of a bind loop (see DAV:cycle-allowed precondition
> defined in Section 4)."
>
> to the end of Section 2.1.1.
>
> Best regards, Julian
>
w3c-dist-auth-request@w3.org wrote on 11/11/2007 03:21:05 PM:
>
> (see
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.
> issue.2.1.1-cycles>)
>
> While fixing the other issues, it occurred to me that we never introduce
> the term "cycle".
>
> Proposal to change the first sentence of 2.1.1 to:
>
> "Bindings to collections can result in loops ("cycles"), which servers
> MUST detect when processing "Depth: infinity" requests."
>
> Best regards, Julian
>
w3c-dist-auth-request@w3.org wrote on 11/11/2007 03:14:42 PM:
>
> (see
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.
> issue.4-precondition-language>)
>
> It seems that the way we use the precondition terminology is confusing
> when we actually talk about OPTIONAL features (I think we had the same
> problem with RFC3744).
>
> So for the definitions of DAV:cross-server-binding and
> DAV:cycle-allowed, I'd like to add one explanatory sentence:
>
> (DAV:cross-server-binding): If the resource identified by the
> DAV:href element in the request body is on another server from the
> collection identified by the Request-URI, the server MUST support
> cross-server bindings (servers that do not support cross-server bindings
> can use this condition code to signal the client exactly why the request
> failed).
>
> (DAV:cycle-allowed): If the DAV:href element identifies a
> collection, and if the Request-URI identifies a collection that is a
> member of that collection, the server MUST support cycles in the URI
> namespace (servers that do not support cycles can use this condition
> code to signal the client exactly why the request failed).
>
> (emphasis on the last sentences).
>
> Best regards, Julian
>
w3c-dist-auth-request@w3.org wrote on 11/11/2007 03:53:56 PM:
>
> (see
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.
> issue.2.5-move-creating-cycles>)
>
> As this question comes up every now and then, I'd like to add the
> example below, showing how a MOVE can cause a bind loop if collection
> bindings are supported:
>
> 2.5.2. Example: MOVE request causing a bind loop
>
> Note that in the presence of collection bindings, a MOVE request can
> cause the creating of a bind loop.
>
> Consider a the top level collections C1 and C2 with URIs "/CollW/"
> and "/CollX/". C1 also contains an additional binding named "CollY"
> to C2:
>
> +------------------+
> | Root Collection |
> | bindings: |
> | CollW CollX |
> +------------------+
> | |
> | |
> +------------------+ |
> | Collection C1 | |
> | bindings: | |
> | CollY | |
> +------------------+ |
> | |
> | |
> +------------------+
> | Collection C2 |
> | |
> | |
> +------------------+
>
> In this case, the MOVE request below would cause a bind loop:
>
> >> Request:
>
> MOVE /CollW HTTP/1.1
> Host: example.com
> Destination: /CollX/CollZ
>
>
> +------------------+
> | Root Collection |
> | bindings: |
> | CollX |
> +------------------+
> |
> |
> +------------------+ |
> | Collection C1 | |
> +----> | bindings: | |
> | | CollY | |
> | +------------------+ |
> | | |
> | | |
> | +------------------+
> | | Collection C2 |
> | | bindings: |
> | | CollZ |
> | +------------------+
> | |
> | |
> +-------------------+
>
> (I also changed the preceding example into a separate subsection).
>
> BR, Julian
>
Received on Monday, 12 November 2007 16:30:05 UTC