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

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

   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.

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

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

   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.

   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.

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

   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.

Cheers,
Geoff