RE: DELETE in WebDAV Advanced Collections

I suspect but I won't swear that I'm backing up Roy's interpretation of this
situation. If you issue the DELETE method you are deleting the resource. I
will conveniently skip the whole question of "what" the resource is and
posit that a resource can have multiple names. So if you delete the resource
then all its other names get deleted as well.

How one wants to interpret this can be a real pain. I really like Roy's
example about "current weather in Irvine" and "weather on 4/22/1999".
Deleting the first should not necessarily end up in the second link being
removed. That is because the resource behind "current weather in Irvine" is
NOT (in this example anyway) the same resource as "weather on 4/22/1999."
The fact that for a 24 hour period they happen to return the same bits isn't
relevant to figuring out what the "resource" is that is supposed to be
deleted. The fact that for 24 hours they point to the exact same file isn't
relevant either. Let us hope whomever implements "current weather in Irvine"
does so using an HTTP server redirect so that a delete will limit its
damage.

Between the DELETE issue and Jim's proposal it seems that advanced
collections needs to create both a BIND and UNBIND method. Personally, I
like the symmetry.

			Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Thursday, April 22, 1999 7:47 AM
> To: 'WebDAV'
> Subject: DELETE in WebDAV Advanced Collections
> 
> 
> If you look at version 3.2 of the Advanced Collections spec, 
> you will see
> that we are defining DELETE to mean just one binding to the 
> resource gets
> removed, the one identified by the request-URI.  If there are multiple
> bindings to the resource, the rest remain, and the resource 
> continues to be
> accessible through them.
> 
> We realize that in the end we need two operations, one of 
> which removes a
> single binding and the other of which removes all bindings to 
> a resource.
> The issue is whether to interpret DELETE as removing a single 
> binding and
> introduce a new DESTROY method to remove all bindings, or to 
> introduce a new
> UNBIND method to remove a single binding and interpret DELETE 
> as removing
> all bindings.
> 
> There has been some discussion on the mailing list of the proposed
> definition of DELETE as removing a single binding, but I would like to
> solicit more.
> 
> This definition appears, on the surface at least, to 
> contradict RFC 2068,
> which says that the methods defined there apply to resources. 
>  For DELETE,
> it says, "The DELETE method requests that the origin server delete the
> resource identified by the Request-URI."  (It also says that 
> the client
> should not assume that the operation has been carried out, 
> even if a success
> status code is returned, so that may give us some room to maneouver.)
> 
> RFC 2518 explicitly states that a DELETE must result in the 
> removal of all
> URIs from their collections for the resource identified by 
> the request-URI.
> 
> What has led us to our proposed definition of DELETE as 
> removing one binding
> is a concern about the versioning spec.  In the context a 
> versioning, it
> would be nice for down-level clients to be able to issue 
> DELETE requests and
> have something reasonable happen.  But in the context of 
> versioning, the
> only thing it makes sense to do is remove a single binding.
> 
> --Judy
> 
> Judith A. Slein
> XR&T/Xerox Architecture Center
> jslein@crt.xerox.com
> 8*222-5169
>

Received on Thursday, 22 April 1999 19:28:38 UTC