Subject: RE: BIND vs. non-movable resources in RFC3253

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 21 Oct 2002 09:31:55 -0400

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.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Sunday, October 20, 2002 6:19 AM
To: 'Webdav WG'
Subject: BIND vs. non-movable resources in RFC3253

Hi,

RFC3253 defines several kinds of resources that MUST NOT be moved, for
instance version resources ([1]) and version history resources ([2]).

How does this impact the ability to create additional bindings?

a) You can't (so do we need additional preconditions)?
b) You can, but you can't delete the original binding (so do we need to
extend the DELETE semantics)?
c) We don't care -- BIND/DELETE may work, although MOVE is forbidden (in
which case I'd like zo understand why).

Julian

[1] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.15>
[2] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.8>

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 21 Oct 2002 16:20:44 +0200

> From: [email-masked] [mailto:[email-masked]]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 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

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 21 Oct 2002 16:31:29 +0200

The conformant behaviour would be to disallow DELETE on "the" uri of a
version/version history unless the uri is already the last bindung to 
the
resource.

This would avoid the requirement that *all other* binding must be 
removed
which is exactly the opposite of what the binding spec (currently) says.

//Stefan

Am Montag, 21.10.02, um 16:20 Uhr (Europe/Berlin) schrieb Julian