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