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

RE: request for un-version-control feature

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 7 Feb 2003 13:38:18 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE201DA025D@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

Could you motivate the need to unversion-control a resource
but not delete it?  In particular, should a server that automatically
puts all resources under version control fail such a request,
or just ignore it?


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Friday, February 07, 2003 12:27 PM
To: ietf-dav-versioning@w3.org
Subject: request for un-version-control feature


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 13:38:52 UTC

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