RE: Move and Delete (was: bind draft issues)

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, March 08, 2003 7:44 PM
> To: 'Clemm, Geoff'; 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
> 
> 
> 
> 
> What about this model with respect to DELETE and bindings? Rough
> specification-like language follows...
> 
> ---
> When a client issues a DELETE request to a collection that has internal
> bindings, the preferred server behavior is naturally to achieve a
> complete success, whenever possible.  However, servers may behave
> differently depending on what bindings exist in the rest of the system.
> The collection being deleted may contain the last bindings to one or
> more resources. When the last binding to a resource is deleted, the
> server may be implemented to perform some cleanup (e.g. release tied-up
> storage resources).  If the server is unable to complete its cleanup,
> the server MAY do an incomplete recursive delete operation, leaving some
> resources behind. The server MAY leave parent collections of undeletable

...I think that's MUST...

> bindings/resources in place in order to preserve a consistent URL
> namespace -- this is equivalent to the behavior specified in RFC2518
> [section ref].  The benefit of maintaining a consistent namespace, to a
> server implementation, is that orphaned resources remain findable by
> clients, so that clients can take actions like changing permissions or
> removing locks and finish their DELETE operation.  In case of a partial
> DELETE success, the server MUST report individual undeleted
> bindings/resources, URL by URL, using the multi-status response body.

(except for result minimization as mandated by RFC2518, section 8.6.2.

>  At the other extreme, a DELETE request to a collection may be as simple
> as an atomic unbind, which is clearly preferable because to the client's
> point of view this is a complete success.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Saturday, 8 March 2003 14:10:12 UTC