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: Tue, 16 Jul 2002 10:31:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B107761D98@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org

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

   > >  - thus, upon UNCHECKOUT of the VCC, I can reconstruct the VHR
   > > (re-creating the original binding)

   > Yes, but nothing in the semantics of UNCHECKOUT imply such a
   > reconstruction.

   OK, I can live with servers *not* doing that -- what I'd like to
   know is whether this behaviour (reconstructing the VHR) actually is
   RFC3253 compliant.

It is not compliant, in that no interoperable client will expect this
behavior.  It is compliant in that it is not forbidden.  So it really
is an implementor's judgement call.  If you think the "restore on
UNCHECKOUT" behavior is important, you can resurrect the version
history, and offer that as a "special feature" offered by your server.
But if the user issued the DELETE on the version history
explicitly to prevent this kind of resurrection (or to free up space
on the server), then you will make that user unhappy.

A similar kind of situation exists with versioned collections.
A collection version lets you resurrect deleted resources, which
would could violate the user's desire to free up the space from
that resource.  But we minimize that cost by using techniques
like delta storage, and we allow the user to control this behavior
by giving them an explicit VERSION-CONTROL operation.

Received on Tuesday, 16 July 2002 10:32:21 UTC

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