RE: request for un-version-control feature

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

Julian

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

Received on Monday, 10 February 2003 14:15:20 UTC