W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2002

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 10 Jul 2002 08:04:52 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1077612EC@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

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

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

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

Received on Wednesday, 10 July 2002 08:05:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC