W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2002

RE: BIND vs. non-movable resources in RFC3253

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 21 Oct 2002 19:48:06 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCGEPOFJAA.julian.reschke@gmx.de>

> 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
Received on Monday, 21 October 2002 13:48:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:27 UTC