RE: error condition for delete of VHR when VCR is in checked-in c ollection

   From: Julian Reschke [mailto:[email protected]]

   > > > > b) the server deletes the VHR and un-version-controls the
   > > > > VCR (to avoid breaking the live versioning properties).

   > > > In what sense would the property be "broken"?  Clearly from
   > > > the server's point of view there is a good reason why it may
   > > > not want to so this, but from a protocol point I don't see a
   > > > problem.  For example, what would be the difference if the
   > > > version-history resource is unaccessible due to other
   > > > circumstances, such as authentication or reachability?
   > > > The semantics of a version-controlled resource can be
   > > > enforced even if the version-history resource does not exist.

   > > Even if both the resources referenced by DAV:checked-in and
   > > DAV:checked-out do not exist?

   > In principle, yes.  For example, if a site wanted to allow
   > anonymous users to see the current state of the website, by
   > browsing the version-controlled resources; but not allow them to
   > view the history or checked-in, checked-out states.  The server
   > may still ensure that the semantics are maintained.

   I think we need to distinguish between

   a) references to version histories / versions that are correct, but
   specific users may not dereference/GET them (I don't have any
   problem with that), and

   b) references that are dead (because the resource they point to is
   gone).

I don't see that this makes much of a difference to the protocol
client (other than that the error codes may be different when they
try to access the VHR/Version URLs).

   In case b), there's no way a subsequent CHECKIN or CHECKOUT can
   satisfy RFC3253's postconditions, so I'd consider this a broken
   state. There shouldn't be a protocol-tolerated way to get into this
   state, right?

Which CHECKOUT/CHECKIN postconditions couldn't be satisfied?
I do agree that some operations could not succeed (e.g. UNCHECKOUT).

Cheers,
Geoff