W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2002

14.4_CLARIFY_VH_DELETE_2, was: BIND vs. non-movable resources in RFC3253

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Sun, 27 Oct 2002 19:59:30 +0100
To: "DeltaV \(E-mail\)" <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMELIFKAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, October 25, 2002 10:46 PM
> To: DeltaV (E-mail); w3c-dist-auth@w3c.org
> Subject: RE: BIND vs. non-movable resources in RFC3253
> It looks like we have finally narrowed down this thread to
> one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2
> (i.e. can you delete the stable binding to a version history
> or version, if there are other bindings).  Any discussion of
> 14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing
> list, not to the general webdav mailing list.
> ...

Actually, I think there are *two* issues, one of which is the one above
(where I clearly disagree with the current resolution), and...

For all live properties that refer to version resources or version history
resources, which one of possibly multiple bindings should be reported? (I
think we all agree that the stable binding should be reported).

As we also have agreed (months ago) that the fact that the a deltaV live
property points to a specific URL does *not* guarantee that the reported URL
is still mapped (so a client can get a 404...), I hereby ask again to
consider the following alternate resolution to 14.4_CLARIFY_VH_DELETE_2:

Bindings to version resources or version history resources may be deleted in
any order. Removing the stable binding does not affect which URL will be
reported in the live properties -- the resource just itself isn't accessible
through the stable URL anymore. This relaxes the "stable URL" requirement
such that clients still can rely on the stable URL when being mapped to be
mapped to the initially created resource (it won't be reused). Upon
encountering a 404, they would however not be able to conclude that the
resource itself is gone (I'd still like to hear why that would be a

This model is completely deterministic and avoids special-casing DELETE and
BIND for these resources, therefore it would be a protocol simplification (a
hopefully shared goal of the WG :-).


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 27 October 2002 13:59:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC