request for un-version-control feature

Hi.

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
protected).


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,

Julian

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

Received on Friday, 7 February 2003 12:26:39 UTC