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

Geoff,

let me try to summarize.

In the presence of BINDs, DELETE is defined as

1) removing the binding specified in the request URI,

2) optional deletion of the resource identified by the URI if there are no
references left to it. Note that references may be in other namespaces, on
other servers and even in different URI schemes.

Any spec that wants to cooperate with bindings can NOT change this semantics
of DELETE (or does RFC3253 explicitly say that a VHR can have only a single
binding???).


So we have a VCR that refers to a VHR through the DAV:version-history
property. The client issues a DELETE on the VHR URI. Possible results:

a) the server may refuse to perform the Delete, either because deletion of
VHRs is not supported, or because a VCR still refers to the VHR.

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

c) the server deletes the VHR and keeps the VCR version-controlled - in
which case the spec should say what happens to the
DAV:checked-in/DAV:checked-out and DAV:version-history.

I think RFC3253 needs to either forbid b) and c) or properly define the
semantics.

More below...

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, July 09, 2002 2:10 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: error condition for delete of VHR when VCR is in checked-in
> c ollection
>
>
>
>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>
>    >    > If you've deleted the version history, you have effectively
>    >    > trashed any historical references (e.g. in collection
>    >    > versions) to that version history.
>    >
>    >    Nope. I have deleted the binding to the version history, not
>    >    necessarily the information itself. In particular, my server
>    >    may be able to reconstruct it upon UNCHECKOUT of the versioned
>    >    collection "/a" (using the same URI).
>    >
>    > I'm not sure how an UNCHECKOUT of a VCCl is related to this
>    > thread, since an UNCHECKOUT request has no effect on a version
>    > history resource.  But in any case, postcondition
>    > DAV:delete-version-set in Section 5.6 states that deleting a
>    > version history resource deletes all versions in that version
>    > history.  So your server would not be able to reconstruct the
>    > version history once it was deleted.  Note that the errata issue
>    > 14_DIFFERENT_VH_DELETION_SEMANTICS_REQUIRED clarifies that
>    > deleting a member of a working collection just removes a binding
>    > to a VHR, but doesn't delete the VHR.
>
>    My theories goes like this :-)
>
>    - by checking in a VCC that contains a VCR member, I am effectively
>    creating a new binding to the VHR of this VCR member. This binding
>    may not be visible in my "public" URL namespace, but it's still
>    there
>
> I try to reserve the term "binding" for the sense in which it is
> used in the Bind protocol, namely the connection between a collection
> and one of its internal members.  In that sense, checking in a VCC

Bind: A relation between a single path segment (in a collection) and a
resource. (draft-ietf-webdav-binding-protocol-02)

> never creates a binding to a VHR, but rather just creates a reference
> to the VHR in its DAV:version-controlled-binding-set property
> (i.e. it doesn't create a new name for that VHR, but just uses an
> existing name to create a reference).

I don't think it's really relevant whether the collection version has a
reference or a binding. Servers may delay the de-allocation of a resource
until there is no reference left, whether it's visible or not.

If we allow clients to (permanently= destroy VHRs that are referenced in a
collection version, there's no way to satisfy the postconditions for an
UNCHECKOUT of the VCC, right? That's why our implementation keeps the
reference, and therefore is able to resurrect the VHR when needed.

>    - a subsequent delete on the VHR URL just deletes the original
> binding to
>    the VHR, but the version history resource (and the versions inside the
>    version history) is not affected
>
> Since the DAV:version-controlled-binding-set just has a reference to
> that VHR using its server-assigned URL, if you DELETE that URL, you
> break all references to that VHR from the DAV:v-c-b-s properties of
> collection versions.

So if the VHR can not be re-created, should the server forbid the delete?

>    - thus, upon UNCHECKOUT of the VCC, I can reconstruct the VHR
>    (re-creating the original binding)
>
> The members of the VCC also refer to the VHR via the server-assigned
> URL, so even if UNCHECKOUT could restore the version-controlled
> member of the VCC, the DAV:version-history property of that member
> would contain the VHR URL that was deleted.

But that's not a problem if the '*same* VHR is reconstructed at the original
URL.

>    Maybe these problems go away when we remove connection between
>    deleting the VHR and un-versioning a resource, but this is how it
>    looks right now.
>
> Deleting a VHR to "un-version" a resource is fine; it's just
> restoring it which is a problem.
>
>    >    > If you are going to let that deletion
>    >    > happen even when there is a VCR for that version history in
>    >    > some workspace, I don't see that it makes any sense to worry
>    >    > about whether or not the collection containing that VCR is
>    >    > checked in or checked out.
>    >
>    >    The issue is that RFC3253 doesn't define a method to switch off
>    >    version control on a resource, and therefore people are using
>    >    deletion on VHRs to switch off versioning (I couldn't find any
>    >    mention of this in the spec, though).
>    >
>    > I don't recall hearing of this approach, and don't see how
> it could be
>    > compatible with the spec, giving the DAV:delete-version-set
>    > postcondition.
>
>    OK. It was originally suggested in section 4.2 of
>    draft-dusseault-deltav-subset-00 [1], and up until some time ago,
>    it made a lot of sense to me.
>
>    Clarification: people use deletion of the VHR to both delete the
>    VHR and un-version-control the VCR. How would that violate the
>    DELETE sematics for VHRs?
>
> OK, I think I see where things may have gotten confused.
> The approach I was referring to (i.e. the one I didn't recall hearing
> about) was not the "unversion by delete VHR" approach (which I do
> remember), but rather the "restore by UNCHECKOUT".  If you are
> willing to permanently destroy the history for that resource, I
> agree that deleting the VHR is a reasonable/interoperable way to do so.
>
>    >    This conflates to separate things, but there doesn't seem to
>    >    be better way to do it (please don't say COPY/DELETE/MOVE,
>    >    because this creates a *new* resource).
>    >
>    > COPY/DELETE/MOVE is the only interoperable way of removing
>    > something from version control.  If you need a mechanism that
>    > doesn't create a new resource, I'd suggest something like
>    > allowing a PROPPATCH to remove the DAV:version-history property
>    > of the VCR, rather than trying anything related to VHR deletion.
>
>    Sounds good, and we'll look into this.
>
> Note: As indicated above, if you are willing to permanently destroy
> the history, deleting the VHR is a good interoperable way of taking
> a resource out of version control.  The PROPPATCH proposal is only
> needed if you want to retain the history while un-version-controlling
> the resource.
>
>    However, I now have a new question:
>
>    If - after the deletion of a VCR's VHR - the VCR is still
>    version-controlled - where does it's DAV:version-history property
>    point to?  Similarily, if the delete of the VHR deleted all
>    versions, where does DAV:checked-in/DAV:checked-out point to?
>
> I agree that the simplest model for deleting the VHR would be to
> un-version-control any VCR for that history, and remove any entries
> in DAV:version-controlled-binding-set that refer to that VHR.
> Alternatively, the server could just keep all those references,
> and return errors on all versioning operations, but that would
> leave things in a pretty broken state.
>
>    -> Seems that we need to clarify the post-conditions for deletions
>    of VHRs, right?
>
> It sounds like we actually agree on this one ... it was just the
> "restore via UNCHECKOUT" that was confusing things.
>
> Cheers,
> Geoff
>
>
>

Received on Tuesday, 9 July 2002 08:52:26 UTC