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.
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.
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.
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.
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:
Message-ID: <groupname-faq%v=1@faqsite.com> Supersedes: <groupname-faq@faqsite.com>
The next one, another week later has:
Message-ID: <groupname-faq%v=2@faqsite.com> Supersedes: <groupname-faq%v=1@faqsite.com> <groupname-faq@faqsite.com>
The next one, another week later has:
Message-ID: <groupname-faq%v=3@faqsite.com> Supersedes: <groupname-faq%v=2@faqsite.com> <groupname-faq@faqsite.com>
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.
A user posts a message <myuniquepart@mysite.com> to the net. She notices a typo, and 2 minutes later, posts with:
Message-ID: <myuniquepart%v=1@mysite.com> Replaces: <myuniquepart@mysite.com>
3 minutes later she sees another typo, and posts:
Message-ID: <myuniquepart%v=2@mysite.com> Replaces: <myuniquepart%v=1@mysite.com> <myuniquepart@mysite.com>
The two bad versions will be replaced with the 3rd, even if a site never sees the 2nd due to batching or feed problems, and requests for the original will return the 3rd.
Control: cancel <myuniquepart@mysite.com> Replaced-by: <myuniquepart%v=2@mysite.com>
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.
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.