Supersedes & Replaces -- Updating and correcting articles

The argument for these headers is a msgid-list.

msgid-list = Message-ID *(FWS Message-ID)

These two headers take a list of message-ids (msgid-list) that the current
article is expected to replace or supersede. All listed articles MUST be
treated as though a "cancel" control message had arrived for the message,
except as detailed below.

Older software supported only Supersedes, and with only one Message-ID.
Until Multi-Super-Date, software SHOULD generate Supersedes with only
one Message-ID, and cancel control messages SHOULD be issued if needed for
other IDs.

The first message-id is called the immediate "predecessor" and other IDs are
predecessors to it, in a chain. The new article is the "successor."
Additional IDs beyond the immediate
predecessor SHOULD be added to the list if their successor was posted
less than 2 days after their own posting date. If older than that their
addition is optional. These additional IDs act
as an advisory that these messages were replaced or superseded, when their
actual immediate successor may never have arrived.

If the header is "Replaces" the new successor article SHOULD
effectively over-write the predecessor(s) so that any attempt to read
them shows the successor. Newsreaders should not show the article as an
"unread" article unless the replaced articles were themselves all unread.
A Replacement is considered a minor change, unworthy of being brought to
the attention of a person who read one of the predecessors. Newsreaders and
database systems MAY provide access to predecessors of articles
if they wish, but this should not be part of the course of normal newsreading,
and is in fact discouraged. In addition, since articles MAY be updated
to comply with laws (copyright violation, libel etc.) there may be legal
implications in providing access to predecessors.

Systems MAY treate Replaces as a synonym for Supersedes, if they do not
implement the semantics of Replaces.

If the header is "Supersedes" then the old articles SHOULD simply be
deleted, as in a cancel, and the new article inserted into the system like
any new article.

Attempts to fetch a replaced or superseded article either by number or by
Message-ID SHOULD retrieve instead the most recent successor. Some indication
that a newer version than was asked for has been delivered MAY be provided.
It is particularly encouraged that NNTP servers implement delivery of
successor upon requests by message-IDs so that WWW "news:" and "msg:" URLs
continue to work even when an article has a successor.

It is expected that "Replaces" will become the common header for routine
article changes and corrections, with Supersedes used for periodic postings
(possibly every N periodic postings) or updates that make major changes to
an article.

Note that a Replaces or Supersedes MAY change any aspect of an
article, including the Newsgroups line. If a successor is not in a
newsgroup of its predecessor, then the predecessor should simply be cancelled
in that newsgroup, with no pointer to the successor associated with it for
any fetch by newsgroup and article-number. While a system MAY be smart
about multiple replacements that restore an article back to a group, this
is not a requirement.

As with a cancel, systems MUST NOT delete or replace articles unless the
poster of the successor is authorized to cancel the predecessor.

Message-ID version numbers chain procedure.

Tools superseding or replacing messages should arrange so that the
Message-ID of a replacement follows the following set of rules, generating
what are known as "version-number" Message-IDs.

If the Local-Part of the predecessor's Message-ID ends in "%v=<n>", where <n>
is an integer version number, the new message-ID should replace the <n>
with the integer <n+1>. Example: Message-ID <foo%v=3@site.com> is
replaced by <foo%v=4@site.com>.

If the Local-Part of the predecessor's Message-ID does not end in "%v=<n>",
then the string "%v=1" should be appended to the Local-Part to generate the
successor Message-ID. Example: Message-ID <foo@site.com> is
replaced by <foo%v=1@site.com>.

Implementation and Use Note

Typically a news database will store a "pointer" of some sort between
replaced/superseded articles and their immediate successor or
most recent successor. Such pointers may be expired along with other
records in a news system's message-id lookup database. In addition, if
a "version-number" Message-ID is found, and the "root" version (without the
"%v=" tag, or with a "%v=0" tag) is not present on the server, a pointer
from that root to the most recent successor SHOULD also be stored, and kept
so long as there is a current successor in the system. (Systems should check
for both root forms, trying the "%v=0" form first, and the tagless form
2nd.)

Thus when a request for an article comes in that is not present (due to
superseding or replacement) a check can be made for a pointer record for
that Message-ID, or failing that, if the ID has a version-number, for a
pointer record for the root versionless ID. Such pointers can be followed
to the most recent successor.

Transition

Prior to Multi-Super-Date, a message may contain both a Replaces field and
a Supersedes field. This should be treated as a Replaces, with the Supersedes
added to assure that older systems still at least remove the predecessor.

Replaced-by

This header takes a message-id as argument.

Prior to Multi-Super-Date, if there is a need to Supersede by use of a simple
Cancel control message (due to inability to use multiple IDs in the
Supersedes header) then such control messages may contain a "Replaced-by"
header indicating the Message-ID of the successor the message that was
cancelled. Systems maintaining pointers from predecessors to successors
should use this record to update their pointers.

Note this header goes only on the cancel control message, not the successor.
The successor should have a Replaces and/or Supersedes listing the most
immediate predecessor.

Example 1 (FAQ)

The first edition of an FAQ is posted with a Message-ID of the form:
<groupname-faq@faqsite.com>. The next version, a week later, has:

Note that the long spacing between issues means the multi-entry Supersedes
is there primarily to preserve pointer records at sites not using the
version-number system for message-ids.

Under the above, requests for the root (original) message-ID will return
the most recent FAQ. On systems using the version-number system (which
is optional) requests for any Message-ID in the chain will return the most
recent, for all time. As such the URL "news:groupname-faq@faqsite.com" will
always work, making it suitable to appear in HTML.

Example 2 (Rapid-Fire articles)

A user posts a message <myuniquepart@mysite.com> to the net. She notices
a typo, and 2 minutes later, posts with:

Dates

Multi-Super-Date ... in one year. (1036-spencer required multiple-ID
supersedes, so by now just about everybody should already support it, is
this true?)

"Replaces" active -- whatever date we are putting for general compliance with
this spec by news database systems.

Issues

No syntax for the internals of message-ids has been declared on the net.
However, there
is no harm if a conforming message-id matches the syntax. The syntax
has been designed so that additional flags may be added to a message-id
if desired, in a general "%keyword=value" form prior to the at-sign.

Permanent message-ids as created by this system may even be implemented
by smart NNTP servers which fetch old messages from other servers,
increasing the availability of USENET messages considerably.

Unfortunately, it will be some time until any new feature is widely
deployed.