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

   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.

OK, that wasn't clear before (there was a request earlier to get
an UNVERSION-CONTROL method into the standard protocol).

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

Yes, that was my impression as well.  In particular, this is the use
case that Lisa identified in her email on this thread.

I personally would be willing to require that deleting a version
history converts all version-controlled resources for that
version-history into non-version-controlled resources, if that
addresses the primary use case that is motivating the request for an
UNVERSION-CONTROL method.  (And if it doesn't, please motivate
the use case where you want to keep the version history, and you
want to keep a version-controlled resource, but you no longer want
that version-controlled resource to be associated with that version
history.)

Edgar: Does this also address your request for an UNBASELINE-CONTROL
operation (i.e. if we defined that deleting the
version-controlled-configuration causes the associated
baseline-controlled collection to no longer be baseline controlled)?

Cheers,
Geoff

Received on Sunday, 2 March 2003 08:33:23 UTC