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: Tuesday, October 22, 2002 12:28 AM
> To: WebDAV
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>    > From: Jim Whitehead
>    >
>    > Perhaps what's lying at the core of this issue is a difference in
>    > assumption over who controls the namespace. The binding
>    > specification assumes that in WebDAV-compliant portions of the
>    > namespace, the client has a large degree of control over naming
>    > and deletion. Resources are created at locations the client
>    > specifies, can be moved to places the client wants, and rebound
>    > to new names at will.
>    >
>    > The non-movable resources in DeltaV are typically created by the
>    > server, at names the server chooses. Often these resources won't
>    > be represented the same way as "file-like" resources, and will
>    > instead be acting as the handle for a computational process that
>    > queries the versioned repository to return property data. That
>    > is, they act more like a servlet or a CGI.  In this case, it's
>    > important for the server to have these resources at the place
>    > where it created them, since that's where its software expects
>    > queries against those
>    nobody is saying that this is a non-compliant way to implement
>    RFC3253. The point is -- just because some servers choose to
>    implement RFC3253 this way, should this prevent other implementors
>    to implement "full" namespace control (except of re-use of assigned
>    version and VHR URIs)?
> Yes, I believe that is precisely what RFC3253 should say.  To refer to
> my earlier analogy, just because some clients want immutable content,
> should this prevent implementors from implementing "full" content
> control (i.e. allowing modification to checked in versions).  The
> answer here is also, "yes".

The answer is yes, but for a different reason. It is a stated goal of the
spec that versions have stable URIs and that they are immutable. Nobody
wants to change that.

>    > resources to be directed. (It's additionally important that they
>    > stay in the same place for the indentification usability issues
>    > Geoff outlined).
>    Again, no.
> I disagree.
>    It's important that a URI that has once been assigned to a version
>    or VHR never is assigned to anything else.
> We all agree on that.  But the fact that a stable URI should have this
> characteristic, does not imply that it should not also have the other
> characteristic we are discussion in this thread.

And I didn't say that. I'm just saying but both goals are independant of
each other, or, more precisely, that the first one doesn't require the
second one.

I wrote:

>    However, for a client it is clearly not relevant whether it's
>    getting a 404 because the resource was destroyed or because it was
>    moved away (or for that matter, just the binding was deleted and
>    the resource was moved to non-accessible storage). I'd like to hear
>    why this is relevant, because it demonstratibly causes a conflict
>    between the RFC3253 and the BIND spec.

So again -- why is this relevant? I'd really like to understand this.

> The fact that a particular resource has additional restrictions
> in no way "conflicts" with the BIND spec.  There will be a variety
> of reasons why a DELETE request will fail (authorization, locking,
> etc.).  This is just another reason that applies to this particular
> binding.  The condition is easy to specify and easy to understand
> (i.e. the DAV:parent-set must have only one member for DELETE to
> succeed on this URI).

It's not the resource that has additional restrictions, it's a particular
binding to that resource. And this IMHO clearly contradicts the BIND spec.

Quoting:

"A BIND request does not create a new resource, but simply makes available a
new URI for submitting requests to an existing resource.  The new URI is
indistinguishable from any other URI when submitting a request to a
resource."

BTW: this sentence doesn't take into account that access rights may depend
on the collection containing the binding, and on the fact that different
bindings to the same resource may be subject to protection by different
locks. So we may need to rephrase this anyway.

"Bindings are added and removed by a variety of existing HTTP methods.  A
method that creates a new resource, such as PUT, COPY, and MKCOL, adds a
binding.  A method that deletes a resource, such as DELETE, removes a
binding.  A method that moves a resource (e.g. MOVE) both adds a binding (in
the destination collection) and removes a binding (in the source
collection).  The BIND method introduced here provides a mechanism for
adding a second binding to an existing resource.  There is no difference
between an initial binding added by PUT, COPY, or MKCOL, and additional
bindings added with BIND."

So MOVE should be the same as BIND/DELETE. If you can BIND/DELETE, you
should be able to do MOVE as well.

>    > IMO, accommodating this difference requires explicitly
>    > acknowledging the two different classes of resource binding
>    > behavior (fixed vs. free) and then explicitly adding language
>    > describing the behavior of fixed types to the binding
>    > specification (something similar to Stephan's language would
>    > probably work). Revisions to DeltaV can indicate, for all DeltaV
>    > resource types, what kind of binding behavior they exhibit.
>    Yes, the BIND spec should say something about these kind of
>    resources. No, RFC3253 should not require implementors to actually
>    restrict themselves to this kind of implementation.
> I disagree.  It is not an implementation issue,
> it is a client visible semantics issue.  Is another client allowed to
> "hide" the resource at some other URL?  No, and neither should it
> be able to change the "stable URL" for a version or version history.

Again, I didn't say that.

But: if clients are allowed to DELETE a version, I fail to see why moving it
to somewhere else is a problem. It won't be available anymore at it's
"stable" URI in both cases. Both the BIND spec and HTTP clearly say that a
client can not rely on the resource actually being destroyed:

http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7:

"The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot be
guaranteed that the operation has been carried out, even if the status code
returned from the origin server indicates that the action has been completed
successfully. However, the server SHOULD NOT indicate success unless, at the
time the response is given, it intends to delete the resource or move it to
an inaccessible location."

and BIND...:

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

And no, I didn't say that the stable URI may be changed. Only the URI
assigned at resource creation time has the "stability" property, and the
fact that the resource can be moved away doesn't conflict with this more
than the resource being deletable. The client-observable will be the same:

1) The resource at the stable URI is gone and
2) The stable URI will never be mapped to a different resource.

>    Trouble is, RFC3253 already talks about bindings to non-movable
>    resources (for instance, a working collection contains bindings to
>    version history resources). So we need to define what happens when
>    you apply DELETE to a VHR-URI while another binding still appears
>    somewhere else. Stefan's proposal works fine if your VHR resources
>    are restricted in the way you explained. However, I'd strongly
>    object to *requiring* this kind of implementation.
> This is a client semantics issue, not an implementation issue.

So please state what should happen when the VHR is deleted while a working
collection exists that contains a binding to the VHR.

>    Again, the primary and uncontroversial goal is that a version or
>    VHR URI is never assigned to a different resource. This takes care
>    of all the use cases I heard. I've yet to hear why it would be a
>    problem if it's moved away. Why would it matter to a client?
> This is only one of the goals, and the additional goal
> we are discussing in this thread is consistent with this other goal.

Yes. And again, for client-observable stability of the original URI the
second goal is not required. If you have a use case in mind where this
really makes a difference to a client, please state it.

>    > As for why we should add this language -- the idea is to make it
>    > so that a client, when encountering resources of both types, can
>    > behave intelligently, without having to perform trial and error
>    > to accomplish useful tasks.
>    Sure. Whatever a server implements, a client should be able to
>    discover.
> Querying a server to find out what it implements is the trial and
> error that we want the client to not have to do in this case.

Yes. I didn't say that. In particular, I proposed a precondition name (which
is used in response bodies). It still allows the client to discover what
went wrong when it attempted the BIND.

>    To start with, BIND will need a precondition such as
>    DAV:member-name-available - the member name to be created is
>    available for use (because although not in use, it may be unusable
>    because it already identified a VHR or a version)
> It is more likely that the server will not support a BIND into
> that version or version history namespace, since as Jim pointed out,
> commonly this namespace is a computation based on the state of the
> resource, and not an actual directory or folder.  But we could
> certainly add such a precondition if that error code is important.

I think we need it for completeness. A server may very well allow bindings
into this part of the namespace.

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

Received on Monday, 21 October 2002 19:16:44 UTC