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

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

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, February 07, 2003 7:38 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: request for un-version-control feature
>
>
>
> Could you motivate the need to unversion-control a resource
> but not delete it?  In particular, should a server that automatically

I don't see why this needs to be coupled. I do understand that there are
cases where servers do not support the concept of un-vcr-ing a resource, but
we have provably two independant implementations that both want/need to
support this feature and are looking for a interoperable way to do it
easily.

> puts all resources under version control fail such a request,
> or just ignore it?

I think in this case it's best to just return 405 (not allowed), just as a
RFC3253-conforming server would do it anyway.

Julian

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

Received on Friday, 7 February 2003 20:25:32 UTC