Subject: RE: is DELETE "best effort"?

From: Yaron Goland <[email-masked]>
Date: Thu, 27 Jan 2000 17:19:14 -0800

Bill the answer for RFC 2518 is an unequivocal YES.

What is being argued is if we should change that YES to a no. This will
require issuing a new version of RFC 2518.

Until such a new version is issued the answer is YES.

BTW, Geoff, RFC 2518 already supports having the server refuse to change any
of the members if it can't delete the root.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:[email-masked]]
> Sent: Thu, January 27, 2000 2:02 PM
> To: [email-masked]
> Subject: Re: is DELETE "best effort"?
> 
> 
> 
> This topic is currently being hotly debated in the thread:
> "WebDAV Bindings - Issue Yaron.AtomicDelete"
> 
> Although 2518 currently implies "yes", the authors of the 
> BIND protocol
> extension have proposed that the answer be changed to "no".  
> Stay tuned (:-).
> 
> Minimally, we shall insist that a server be *allowed* to
> leave all member collections unmodified if it cannot delete
> the collection specified in the DELETE request.
> 
> Cheers,
> Geoff
> 
>    From: Yaron Goland <[email-masked]>
> 
>    Yes.
> 
>    > -----Original Message-----
>    > From: [email-masked] [mailto:[email-masked]]
>    > Sent: Thursday, January 27, 2000 11:46 AM
>    > To: [email-masked]
>    > Subject: is DELETE "best effort"?
>    > 
>    > 
>    > RFC-2518 doesn't come right out and say so, but I think 
> it implies
>    > that a DELETE on a collection is on a "best effort" 
> basis, where you
>    > can deduce what got DELETEd versus what didn't (and why) from a
>    > possible multistatus response.
>    > 
>    > Suppose I request a DELETE of /zoo/, where /zoo/ 
> contains /zoo/mammals
>    > and /zoo/birds.  Suppose there is a problem with the DELETE of
>    > /zoo/mammals (it's locked by my corporate rival, Snidely 
> Whiplash).
>    > Should the server, having discovered this, go ahead and attempt a
>    > DELETE of /zoo/birds?
>    > 
>    > Section 8.6.2 says that if you can't DELETE a resource, 
> you shouldn't
>    > DELETE its ancestors (for the sake of namespace 
> consistency).  It is
>    > silent on what you should do about the resource's 
> siblings, though
>    > (the example in 8.6.2 isn't bushy enough to show it).  
> There is a hint
>    > that some of the DELETEs may be allowed to succeed while 
> others fail
>    > in that 204 response codes are to be omitted from the multistatus
>    > because they are the default success code.
>    > 
>    > Is DELETE intended to be "best effort"?
>    > -- 
>    > [email-masked]   (WJCarpenter)           PGP
>    > [email-masked]                    0x91865119
>    > 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>    > 
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 27 Jan 2000 22:17:42 -0500

What concerns me is that the sequence:

"Is DELETE best effort?  YES."

will result in people believing that DELETE *must* be best effort,
i.e. a server is required to delete everything it can, even if it actually
knows (or could easily find out) that it cannot delete everything.

I agree that this behavior is not forbidden by rfc2518, but I also 
believe some implementors will misinterpret in one direction (i.e. DELETE 
must be all or nothing) or in the other direction (i.e. DELETE must
be best effort), so whatever answer we arrive at, we should make sure
it is clearly stated in the next rev of rfc2518.

Cheers,
Geoff