Re: new DELETE vs collection lock issue

I agree that this section should be modified in the way Julian species 
below.

Cheers,
Geoff



Hi,

Section 7.5 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>) 
states...:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove a resource which has a URI which is an 
existing internal member URI of a write locked collection, this request 
MUST fail if the principal does not have a write lock on the collection."

(the same text appears in RFC2518bis-05).

This is consistent with RFC2518's definition of DELETE, namely 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.6.1>):

"If the DELETE method is issued to a non-collection resource whose URIs 
are an internal member of one or more collections, then during DELETE 
processing a server MUST remove any URI for the resource identified by 
the Request-URI from collections which contain it as a member."

However the requirement to remove *all* URIs mapped to the resource is 
incompatible with BIND (see 
<
http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4.p.1
>) 
and has been removed in RFC2518bis-05. Thus we should rewrite section 
7.5 as:

"As a consequence, when a principal issues a PUT or POST request to 
create a new resource under a URI which needs to be an internal member 
of a write locked collection to maintain HTTP namespace consistency, or 
issues a DELETE to remove an internal member URI of a write locked 
collection, this request MUST fail if the principal does not have a 
write lock on the collection."


Jason, could you please add this to the issues list?

Julian

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