Re: BIND vs. non-movable resources in RFC3253

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:

>
>> 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:32:12 UTC