Tim Bray wrote:
On Oct 31, 2005, at 2:03 PM, Luke Arno wrote:
* "Note: deleting a member also removes it from all the collections to
which it belongs."
I don't think we ought to legislate this.
I think that if an entry shows up in multiple collections, it's still
the same entry, and the semantics of DELETE are "make this resource go
away", so I think that it would be very surprising if we changed them
to "remove from one collection". -Tim
RFC2518 (WebDAV) used to specify exactly that, but since then the
working group has come to consensus that this is not what's expected,
and RFC2518bis is going to change that.
Note that the BIND spec
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>,
through WG last call and waiting for submission to the IESG) explicitly
says
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#delete.and.bindings>):
"When there are multiple bindings to a resource, a DELETE applied to
that resource MUST NOT remove any bindings to that resource other than
the one identified by the Request-URI. For example, suppose the
collection identified by the URI "/a" has a binding named "x" to a
resource R, and another collection identified by "/b" has a binding
named "y" to the same resource R. Then a DELETE applied to "/a/x"
removes the binding named "x" from "/a" but MUST NOT remove the binding
named "y" from "/b" (i.e. after the DELETE, "/y/b" continues to identify
the resource R). In particular, although Section 8.6.1 of [RFC2518]
states that 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", a server that supports the binding protocol
MUST NOT follow this requirement."
..and the draft for RFC2518bis
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.html>)
indeed removes that requirement.
Note that BIND also specifies optional discovery of alternate URIs for a
given resource, and detection of when URIs indeed map to the same
resource (aka fs inode).
So -1 on baking in a requirement that's not in HTTP, and contradicts
what WebDAV is going to do.
Best regards, Julian
