RE: BIND vs. non-movable resources in RFC3253

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:julian.reschke@gmx.de]
Sent: Monday, October 21, 2002 1:48 PM
To: Clemm, Geoff; 'Webdav WG'
Subject: 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: 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