RE: BIND vs. non-movable resources in RFC3253

I agree with Stefan's proposal.

The key semantics that we wanted to maintain is that "if the
resource exists, it exists at the original URL".  Stefan's
proposal maintains this semantics, without the complexity that
could result from a "delete all the bindings" approach.
With the DAV:parent-set property, a client can try to delete
all the bindings, if it wants to do so, and can deal with any
deletion failures as they arise.

Note that 3253 does not have any "delete all the bindings"
wording, so his proposal is consistent with 3253.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

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 
Reschke:

>
>> Clemm, Geoff
>>
>> 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
>
>