W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Resolving outstanding issues in DeltaV

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 25 Jun 2001 00:58:20 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B103625787@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: John Hall [mailto:johnhall@evergo.net]

   > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff

   > A garbage collector that deletes objects that still have 
   > references to them is as much of a bug (and arguably, more of 
   > a bug) than a garbage collector that misses some objects.

   Missing objects is fatal.

Not for the servers of many members of this working group.

   Deleting objects that have references, in a loosely coupled system where
   the references are understood to be conditional (files on the web --
   ever seen a broken link?) is a feature.

Not for the servers of many members of this working group,
whose users are not happy to receive a "404" for information
they have committed to their versioning system.

   >    Solutions to problem 1 might involve something like a "orphaned
   >    resources report" that allowed the storage losses to be "found".
   > Such a report is reasonable (and we certainly will be 
   > providing a custom report of this kind for my server), but 
   > since this report is independent of the current feature set, 
   > I would not suggest holding up standardizing on the current 
   > set of features in order to reach consensus on the semantics 
   > and protocol for this report.

   This report would not cause changes to the current feature set, but
   without it the feature set is not complete without additions.  Is
   completeness required to be a draft, or just relative stability?

There are always additional interesting and worthwhile features that
could be added to any IETF protocol, and therefore "completeness" is
never required or expected from an ietf standard.

Received on Monday, 25 June 2001 00:52:40 UTC

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