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

RE: request for un-version-control feature

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Mon, 10 Feb 2003 20:11:15 +0100
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEAPGHAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Saturday, February 08, 2003 2:25 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: request for un-version-control feature
> The main part of the question was:
> "Could you motivate the need to unversion-control a resource."
> The fact that "two implementations want to do it" is not the
> most compelling answer (there are lots of things that you could
> get two implementations to agree on that would not merit
> adding to a standard protocol).

Well, if there are multiple implementations that want it, it's certainly
nice if you can marshall it. That was the point of the proposal. Right now,
I really don't care which kind of activity this leads to (deltaV addendum,
private informational RFC, ...).

Regarding the what-is-the-need-question: it makes a difference whether you
are building a new system that accurately reflects the deltaV model, or if
you are busing deltaV to HTTP-marshall requests between systems that exist
independantly of WebDAV. In the latter case, you really can't choose --
you'll have to come up with a way to marshall that type of request (or
you'll have to live with an unhappy customer).

In general, I understand why a system would version everything, or a system
where the decision about what is version-controlled is made by the server.
What I don't really see is the use case for a system that has an explicit
"enable" but no "disable" call.

> Note: I'm not saying there are no compelling use cases ...
> just that I haven't heard any yet.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 10 February 2003 14:15:20 UTC

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