RE: is DELETE "best effort"?

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:geoffrey.clemm@rational.com]
> Sent: Thu, January 27, 2000 2:02 PM
> To: w3c-dist-auth@w3.org
> 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 <yarong@Exchange.Microsoft.com>
> 
>    Yes.
> 
>    > -----Original Message-----
>    > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
>    > Sent: Thursday, January 27, 2000 11:46 AM
>    > To: w3c-dist-auth@w3.org
>    > 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"?
>    > -- 
>    > bill@carpenter.ORG   (WJCarpenter)           PGP
>    > bill@bubblegum.net                    0x91865119
>    > 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>    > 
>

Received on Thursday, 27 January 2000 20:26:04 UTC