From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Fri Nov 02 2001 - 18:45:29 CST
>>>>> "Charles" == Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
Charles> A killfile cannot distinguish between a FAQ which you have
Charles> seen reposted umpteen times before, and a revision that you
Charles> might very much want to see.
FAQ authors concerned about this problem put the version number or last
updated date in the subject line, which allows a killfile to do exactly
that. (If you only want to see my FAQ when it changes, then killfile on
the whole subject; if you never want to see it even when it changes, then
use a substring or regexp match on the constant part of the subject.)
To summarize the rest of the issue, as I see it:
Replaces was originally proposed as an idea to allow the replacement
of an article without changing its article number.
This doesn't work because a regularly-replaced article would not expire,
and therefore the group's lowmark would not increase, causing problems
for readers. Accordingly, the proposal was extended with various kludges
involving message-id and xref in order to allow the article to be given
a new number while still informing readers that it's not really a new
article.
The proposal thus extended is not, IMO, implementable, and no known
implementations of it exist yet. While it is _possible_ to implement
some of the suggestions, it is impractical in that it requires
significant additional baggage in the server in order to support one
minor feature of extremely marginal utility.
The original proposals involving putting the old article number in
Xref are not implementable without _serious_ difficulty on clusters
where article numbering is done independently of the main spool,
because the numbering server (which generates the xref) will have no
feasible way to determine the original number.
The message-id versioning ideas are, IMO, a very bad idea in that they
are defining semantics for what was previously a strictly opaque value.
Many server implementations reduce the actual message-id to its MD5 hash
at the earliest available opportunity and use only the hash internally.
Accordingly, in my opinion the entire feature should be removed from
the draft.
-- Andrew.