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: Friday, February 14, 2003 9:17 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: request for un-version-control feature
>
>
>
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>
>    > From: Clemm, Geoff
>    >
>    > 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.
>
> New standard protocol features do not come for free ... they introduce
> additional complexity into the protocol, especially for client and
> server implementations that try to fully implement the protocol (to
> maximize interoperability).  So I believe it is reasonable to at least

I wasn't actually asking for a "standard protocol feature". I was looking
for an agreement between those that *do* want that feature, so that *their*
servers can interoperate.

Note that under that proposal, any existing RFC3253 server would be
compliant, because it specifically allows servers not to implement it (just
like RFC3253 is silent about whether new resources are automatically
version-controlled or not).

> require a compelling use case (and even that is not sufficient, when
> there is not agreement on how to handle that use case, e.g. the
> rejection of the Translate header).

That's correct, but I don't think the comparison makes sense here. The
reason for the rejection of the "translate" header is that it's in direct
violation of the base spec (RFC2616). I don't see any problem like that with
a potential UNVERSION-CONTROL feature.

> ...
> If you included in the standard every feature provided by any system,
> the protocol would be unusably complex, and would provide no basis
> for effective inter-operation.  So every system will have a set of
> non-standard features and extensions that it supports.  Only ones that
> are considered widely needed will end up in the standard protocol.

Yes. That's why this feature hasn't made it into RFC3253. But that doesn't
mean that it can't make it into a different specification, possibly just an
informational RFC.

Given the choice of several people coming up with proprietary and
undocumented solutions, or having them agree on a common protocol and have
that published as RFC, I definitively prefer the latter. Don't you?

>    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.
>
> The burden of proof is on the proponent of a new feature.  A new
> feature is accepted because you have convinced people that it is
> useful/necessary, not just because nobody demonstrated it was not
> useful.
>
> Note that there are use cases for deleting the history of a resource
> (which is marshalled by issuing a DELETE request against the
> version-history resource).  What has not been demonstrated is the need
> to "disconnect" a resource from its history without deleting the
> history.

As far as I understand, RFC3253 makes no promise at all about what happens
with a VCR when it's version history is deleted. Will it end up unversioned,
or will it's version properties be left dangling (pointing to resources that
have been removed)? I think that if RFC3253 would mandate the former, less
people would be asking for this feature.

Julian

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

Received on Friday, 14 February 2003 18:46:33 UTC