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 9:29 PM
> To: 'Webdav WG'
> Subject: 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

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
> provides this service.

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

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

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.

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

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

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

Received on Monday, 21 October 2002 16:24:38 UTC