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 Jim Whitehead
> Sent: Monday, October 21, 2002 10:25 PM
> To: WebDAV
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>
>
> 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

Jim,

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

> resources to be directed. (It's additionally important that they stay in
the
> same place for the indentification usability issues Geoff outlined).

Again, no.

It's important that a URI that has once been assigned to a version or VHR
never is assigned to anything else. 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.

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

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.

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?

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

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)

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

Received on Monday, 21 October 2002 17:38:43 UTC