W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2003

request for un-version-control feature

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Fri, 7 Feb 2003 18:26:33 +0100
To: <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEMHGGAA.julian.reschke@greenbytes.de>


As far as I know, there has been a long discussion about whether this
feature is required or not. Fact is, it's missing from RFC3253, yet several
systems need a way to implement it.

Several workaround have been discussed, but IMHO all of them have some
disadvantages, and furthermore there's no interoperability here:

1) COPY to new resource / DELETE old / MOVE back

Disadvantage: creates new resource (ACLs are lost, DAV:resource-id changes),
requires multiple steps

2) DELETE on version history resource

Disadvantage: actually requires that VHRs are supported, also it's quit
possible that the version history should be preserved

3) PROPPATCH/remove on live properties such as DAV:checked-in,
DAV:checked-out or DAV:version-history

Disadvantage: messy and breaks RFC3253 (because the properties are

Therefore I think that an (optional) new method "UNVERSION-CONTROL" makes
most sense. Servers won't need to support it, and it's presence can easily
be detected using OPTIONS and PROPFIND/supported-method-set.

I can think of one optional parameter that would be marshalled in the
request body: whether the version history should be deleted as well or not.

Feedback appreciated,


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 7 February 2003 12:26:39 UTC

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