Subject: RE: BIND vs. non-movable resources in RFC3253

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 21 Oct 2002 15:28:36 -0400

The benefit that I want us to provide is giving the
client the ability to store away a URL in a text file (or
in some email) with the confidence that this URL will continue
to work, short of the complete destruction/disappearance of
the resource.  If another client is allowed to remap this
resource to a different URL, the original URL no longer
provides this service.

It's very analagous to making a version immutable.  It would
be simpler (and more "flexible") to allow any client to change
the content of a version, and just depend on "convention" to
leave the version content alone.  But then a client can't count
on this being true, and has to figure out some way to workaround
the lack of enforced semantics.  (This is just an analogy, so
if it doesn't work for you, please just ignore it, rather than
try to prove it "wrong" :-).

BTW, the term "stable" is used in section 1 of RFC3253, to 
describe this desireale characteristic of a version URL.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Monday, October 21, 2002 1:48 PM
To: Clemm, Geoff; 'Webdav WG'
Subject: RE: BIND vs. non-movable resources in RFC3253

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 21, 2002 7:27 PM
> To: 'Webdav WG'
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>
> The purpose of a stable URL for a version and a version
> history is to guarantee that that URL will always identify
> that resource.  This provides the client with two benefits:
> The first is that it can just pass that URL around
> and not have to worry about getting the wrong
> resource because that URL has been remapped to another
> resource.

Agreed and not controversial.

> The second is to give the client a "reliable" way to locate
> the resource (i.e. a mapping that only goes away when the
> resource no longer exists).

And here I still don't see the benefit. Forbidding MOVE just to achieve this
seems to be unnecessarily restrictive. The client can't rely on the resource
being available anyway -- what difference does it make *why* it's not
available anymore behind the request URI?

> I believe the second benefit is worth the added complexity
> of saying "the stable binding cannot be deleted if there
> are multiple entries in the DAV:parent-set".

You just introduced the new term "the stable binding" :-)

Again: if there's a choice between simplying and complicating things, we
should try to simplify the model, unless an *essential* feature requires
this. I fail to see why the second benefit would be essential.

> Whether or not this is a a significant benefit of course
> depends on whether your client takes advantage of it, but I

(*) *How* would a client take advantage of this benefit?

> think the cost is minimal, especially since these kinds of
> bindings are already constrained to never be remapped to
> another resource.

Why is this relevant? The ability not to re-use a previously assigned
binding is a property of the collection containing the binding. If my server
allows deletion of VHRs and/or versions, it will have to be able to take
care of this anyway -- it doesn't matter at all whether the binding
disappeared because of a DELETE or a MOVE.

So, I'm still unconvinced.

Can we concentrate on the question marked (*)?

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 21 Oct 2002 22:24:05 +0200

> Sent: Monday, October 21, 2002 9:29 PM
> To: 'Webdav WG'

So do I. The only difference is that I think that it's irrelevant whether
the resource was deleted or moved away. Could you please explain why this
would affect a client? The consequence (the prior URI not being mapped to a
resource anymore) is the same.

> resource to a different URL, the original URL no longer

It still can be used the same way as described by you. The only difference
is that if the URI mapping is removed, a client can not assume that the
resource itself was removed. But why would that matter? Could you please
state a use case where this really makes a difference? And if it really does
matter, where does this leave us with the BIND spec (see below)?

> try to prove it "wrong" :-).

Hm. I'll only state that I'm *not* proposing to make a version mutable. I
just think that making it *movable* makes the model much simpler and avoids
making special workarounds for bindings (note that this doesn'r *require* a
server to allow MOVE on it).

The intent of the BIND spec is to decouple names (bindings) from resources.
I think we should try to adhere to it. In particular, if existing protocols
need to be fixed to account for bindings, I fear that we're doing something
wrong.

> describe this desireale characteristic of a version URL.

Agreed (although it is "stable name" in RFC3253).

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 21 Oct 2002 13:24:52 -0700

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
resources to be directed. (It's additionally important that they stay in the
same place for the indentification usability issues Geoff outlined).

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.

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.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 21 Oct 2002 23:38:09 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Monday, October 21, 2002 10:25 PM
> To: WebDAV
> 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)?

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

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

> 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