On Wed, 14 Jan 2004, Fred Baker wrote:
I'd be happier bumping the number any time the file is changed, so that the
tombstone supercedes the removed file and a subsequent posting supercedes
the tombstone.
Absolutely. Principals of version control are broken otherwise.
In the preferences space, I'd rather see the file extension change as well
so it would be possible to determine w/o parsing the file content that it
is a tombstone.
I am very concerned about the accumulation of tombstones forever, though.
If we don't want to accumulate draft versions forever, what makes
tombstones different? I would far rather age them out after some interval,
such as six months.
As was noted, a mechanism must be maintained to track names and such a
mechanism SHOULD be visible to the ietf community. Doesn't have to be the
drafts directory.
If they are aged, it should be based on natural IETF cycles and not the
current arbitrary 6 months ... for example, a draft associated with a
working group should have the tombstone remain until some time after the
WG closes ... 1 year? That should include drafts submitted to but not
owned by a WG. Individual drafts should retain the tombstone for
substantially longer than 6 months. Perhaps 2 years.
Regarding the clarification about expiration occuring the moment the
processing reopens after a meeting... a better approach would be 15 days
AFTER ALL drafts submitted while processing was suspended and processed.
I wonder how many WG drafts are resubmitted these days to reset the clock
rather than because there were substantive changes? Needless churn. It
seems quite reasonable that a WG would have reference materials written
early in the cycle for discussion which don't change but are still
important 2 years later as the WG is perhaps finishing the official RFC
track documents. Perhaps even later as RFCs progress thru the standards
track. WG chairs should have a mechanism which allows them to extend the
expiration of WG drafts w/o churn of version, etc.
Dave Morris