RE: BIND vs. non-movable resources in RFC3253

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 21, 2002 3:32 PM
> To: 'Webdav WG'
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>
> I believe the answer should be (c).
> The original binding to a version or a version
> history has special semantics (i.e. if you
> delete it, the resource is destroyed, and all bindings
> to it are destroyed), while additional bindings (such
> as those in a working collection) just have normal DELETE
> semantics, i.e. just that binding is deleted.
> So MOVE would not be allowed on the original binding,
> but is allowed on any other bindings.
> And yes, once the BIND protocol is standardized, the
> next revision of the DeltaV protocol should add the appropriate
> preconditions to handle BIND semantics.

I really have a problem with this approach. The BIND spec just clarified
DELETE to mean:

"The DELETE method requests that the server remove the binding between the
resource identified by the Request-URI and the binding name, the last path
segment of the Request-URI. The binding MUST be removed from its parent
collection, identified by the Request-URI minus its trailing slash (if
present) and final segment.

Once a resource is unreachable by any URI mapping, the server MAY reclaim
system resources associated with that resource. If DELETE removes a binding
to a resource, but there remain URI mappings to that resource, the server
MUST NOT reclaim system resources associated with the resource."

You seem to say that other specs are allowed to override this definition. In
which case I'd claim that the model that the BIND spec tries to establish
isn't correct, and that we shouldn't attempt to establish this definition
for deletes of bindings.

IMHO,

- up until now, specs usually defined DELETE as *both* removing the URI
mapping and the destruction of resources,

- the BIND spec changes this view so that the resource MAY be destroyed when
the last binding disappears,

- therefore, DELETE behaviour defined in old specs should now be understood
as definining what may occur when the last binding disappears.

In this particular case, I'd like to understand why we actually want to
forbid MOVE on versions and version histories. I understand that once a URI
has been allocated for a version or a VHR, it should never identity anything
else. So the defined contract basically guarantees that upon GET/PROPFIND on
this URI, I will either

- access the very same resource or
- that I'll get a 404.

I don't think that we need the special MOVE conditions to guarantee this.
From a client's point of view, it's irrelevant whether the resource is gone
or is now "somewhere else" (yes, servers may want to forbid the MOVE for
other reasons).

Julian

Received on Monday, 21 October 2002 10:21:18 UTC