- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 16 Jul 2002 10:31:49 -0400
- 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. Cheers, Geoff
Received on Tuesday, 16 July 2002 10:32:21 UTC