- 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