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

> From: [email protected]
> [mailto:[email protected]]On Behalf Of Tim Ellison
> Sent: Tuesday, July 09, 2002 6:51 PM
> To: [email protected]
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
>
>
>
>
> Julian wrote:
> > > Julian wrote:
> > >
> > > > 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).

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?

> I just wondered what you meant by the properties being 'broken'.  If you
> envisage that to mean the references cannot be 'de-referenced' then there
> are multiple reasons why that may be the case.  I see DELETE to be the
> inverse of BIND (and agree with your descriptions earlier in the thread),
> plus whatever further semantics we choose to apply to DELETE for
> convenience.
>
> Regards,
> Tim
>
>
>