- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 21 Oct 2002 16:20:44 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 3:32 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > I believe the answer should be (c). > The original binding to a version or a version > history has special semantics (i.e. if you > delete it, the resource is destroyed, and all bindings > to it are destroyed), while additional bindings (such > as those in a working collection) just have normal DELETE > semantics, i.e. just that binding is deleted. > So MOVE would not be allowed on the original binding, > but is allowed on any other bindings. > And yes, once the BIND protocol is standardized, the > next revision of the DeltaV protocol should add the appropriate > preconditions to handle BIND semantics. I really have a problem with this approach. The BIND spec just clarified DELETE to mean: "The DELETE method requests that the server remove the binding between the resource identified by the Request-URI and the binding name, the last path segment of the Request-URI. The binding MUST be removed from its parent collection, identified by the Request-URI minus its trailing slash (if present) and final segment. Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If DELETE removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource." You seem to say that other specs are allowed to override this definition. In which case I'd claim that the model that the BIND spec tries to establish isn't correct, and that we shouldn't attempt to establish this definition for deletes of bindings. IMHO, - up until now, specs usually defined DELETE as *both* removing the URI mapping and the destruction of resources, - the BIND spec changes this view so that the resource MAY be destroyed when the last binding disappears, - therefore, DELETE behaviour defined in old specs should now be understood as definining what may occur when the last binding disappears. In this particular case, I'd like to understand why we actually want to forbid MOVE on versions and version histories. I understand that once a URI has been allocated for a version or a VHR, it should never identity anything else. So the defined contract basically guarantees that upon GET/PROPFIND on this URI, I will either - access the very same resource or - that I'll get a 404. I don't think that we need the special MOVE conditions to guarantee this. From a client's point of view, it's irrelevant whether the resource is gone or is now "somewhere else" (yes, servers may want to forbid the MOVE for other reasons). Julian
Received on Monday, 21 October 2002 10:21:18 UTC