- From: Slein, Judith A <JSlein@crt.xerox.com>
- Date: Mon, 27 Mar 2000 15:26:37 -0500
- To: "'Clemm, Geoff'" <gclemm@Rational.Com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
This looks like most of what we want for guaranteeing integrity of bindings. What we want to avoid is a situation where a binding might be broken or removed as a side effect of an operation on some other binding. We don't want a URI to stop working as a result of a DELETE or MOVE operation submitted to a different Request-URI. The sort of case we initially considered when talking about integrity is not entirely covered by your proposed language: Suppose you have two separate servers (or two parts of the namespace of one server that are separately managed) and you create a binding from a location on one server to a target resource on the other. Then unless you had some out-of-band way of collaborating on the creation of this new binding, the server managing the target resource would not know that this binding had been created. Then when the last binding it knows about is deleted, it will be free to destroy the resource, and the binding on the other server may be broken. The server can be obeying the rules you state in your message (as far as it knows) and still do something that will cause the binding to be broken. So we need to address some constraints to the server that allowed the binding to be created in the first place -- it should never have allowed the binding to be created unless it had some way to communicate the existence of the binding to the server managing the target resource. --Judy -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Wednesday, March 22, 2000 1:58 PM To: 'w3c-dist-auth@w3.org' Subject: RE: WebDAV Bindings - Issue Yaron.MrIntegrity I propose that we delete all uses of the term "integrity" from the spec, and instead say: RFC 2518 allows resource deletion requests, such as DELETE and MOVE, to do a "best effort" deletion on collections, where only some of the members of the collection are deleted following the request. In order to guarantee the more predictable BIND/UNBIND semantics when a binding unaware client is used to do authoring on a binding aware server, a binding aware server is required to map deletion requests into the appropriate UNBIND request. More formally: If a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a resource identified by the URL /path/x, and /path identifies a collection that supports the BIND/UNBIND methods, then the request MUST have the same effect as an UNBIND of x from /path. In particular, if the request succeeds, the binding named x MUST be removed from the collection indentified by /path, and whether or not the request succeeds, no other bindings from any other collection may be removed. As a corollary to this rule, if a DELETE request, MOVE request, or a request with an Overwrite:T header is applied to a collection identified by the URL /path1, then a resource identified by the URL /path1/path2/path3 MUST NOT be deleted if /path1/path2 supports the BIND/UNBIND operation. Cheers, Geoff -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Yaron Goland Sent: Sunday, January 16, 2000 8:49 PM To: w3c-dist-auth@w3.org Subject: WebDAV Bindings - Issue Yaron.MrIntegrity The last sentence of the last paragraph of section 4 reads "Implementations MUST ensure the integrity of bindings." Similar language is used in the second paragraph of section 5.1. However the term "integrity" was never well defined inside of the specification. As such it is impossible to comply with this requirement in an interoperable way. I would strongly caution against attempting to specify the definition for integrity, English is much too inexact a language for such an attempt to be successful. As such, I move that both sentences be removed and be replaced with a series of statements that define, in exact language, the requirements that are to be represented by the term "integrity", each sentence properly qualified with a MUST.
Received on Monday, 27 March 2000 15:27:05 UTC