Summary

  • A Netnews Supersedes field names exactly one earlier article by Message-ID. The new article is still processed as an ordinary, separately identified publication.
  • Withdrawal of the predecessor is handled like a cancel: each serving site authenticates and authorizes the request and applies its own local action. One site may remove its copy while another retains it.
  • Cancel-Lock and Cancel-Key later supplied stronger proof for cancel and supersede requests, but authentication never became a promise of global erasure.

Two servers, one revision, different pasts

Picture a corrected technical notice arriving at two Usenet serving sites. Both accept the revision. At the first site, the withdrawal credential checks out and local policy permits the older notice to be removed from normal service. At the second, the credential cannot be validated—or policy declines to act—so the predecessor remains beside its replacement.

The revision has not failed at the second site. It is present there just as it is at the first. What differs is the local history visible to readers. One server shows only the correction; the other shows both versions.

That asymmetry is the key to Supersedes. It did not grant an author a distributed transaction that could atomically replace every copy. It packaged a request about an old article with a new article whose life did not depend on that request succeeding.

Cancellation came first

The earlier machinery appears in RFC 1036. A cancel control article named its target by Message-ID. A receiving system that could cancel the article was to do so locally; a system that could not perform the action was not thereby empowered to rewrite some universal store.

Authorization was already a problem. The specification compared the Sender or From of the cancel request with the corresponding field on the target and also allowed local administrators to act. This was an attempt to distinguish correction from vandalism, but header resemblance was weak evidence in an open distributed system.

The historical lesson is not that cancel was equivalent to deletion. It is that withdrawal was always an operation performed by particular sites against particular stored copies. Distribution had multiplied the places where authority had to be evaluated.

Supersedes added a new article, not a mutable version

RFC 5536 defines the Netnews Supersedes field with a deliberately narrow value: one Message-ID identifying the article to be superseded. It describes the effect as though a cancel request for that target were processed immediately before the new article were handled normally with the Supersedes field removed.

That formulation prevents a seductive but inaccurate model. The revision does not enter the predecessor's record and overwrite its body. It has its own Message-ID, its own headers and its own route through the network. The field links two distinct publications while asking sites to change how one of them is served.

The order also matters. Withdrawal is not a precondition for admitting the replacement. The replacement remains a normal article rather than an all-or-nothing repair command.

The serving site owned the withdrawal decision

RFC 5537 makes the division explicit. Supersedes is not itself a control message, but its request to withdraw the named predecessor is authenticated and authorized under the same rules as cancel. If the request is honored, the site performs the same action it would for a valid cancel.

Whether the request is honored or not, however, the new article is handled normally. A server is not supposed to reject the correction merely because it keeps the old copy. Nor does accepting the correction prove that the old copy vanished.

This is why “replaced” is not a single observable state. It can mean that a relationship between two article identities is present, that a local user interface prefers the newer article, or that a particular server removed the predecessor from ordinary retrieval. The RFCs establish the request and processing boundary, not a universal view across all archives.

RFC 5537 also records the practical cost of weak authorization: many sites historically ignored cancel and supersede requests because authenticating them was difficult and malicious cancellation was attractive. A posting agent should stop a user from trying to supersede somebody else's article, but every downstream site still confronts its own evidence and policy.

Keys improved proof without creating sovereignty

RFC 8315 gave this decision a better cryptographic basis. An original article can carry a Cancel-Lock. A later cancel or superseding article supplies a Cancel-Key whose derived value can be compared with that lock. The mechanism lets a site test knowledge associated with the original posting instead of trusting a similar-looking address alone.

Stronger authentication closes an important abuse path, but it does not merge the network into one database. A matching key can support authorization at a site that implements the mechanism. It cannot force an offline archive to purge a copy, invalidate quotations, retract gateway exports or dictate the retention policy of every independent operator.

The distinction is operationally valuable. Systems can become more confident about who requested withdrawal without making a false claim about where all copies went.

The same word did not mean the same recall everywhere

The name Supersedes also crossed a protocol boundary. RFC 2156, concerned with mapping between Internet mail and X.400, defines a mail field that may contain one or more message identifiers. RFC 5536 warns that its Netnews field has no connection with that email version.

The IANA Message Headers Registry preserves the distinction with separate standard entries for mail and Netnews. A familiar field name is therefore not permission to import Netnews withdrawal semantics into a mailbox, or to assume that an email client, archive and news server share one recall model.

Registry status stabilizes a name and reference. It does not measure present-day support, certify a site's policy or prove deletion.

Revision survived the failure of recall

Supersedes solved a modest but durable problem: how to publish a correction and signal which earlier article it should displace without making correction delivery hostage to perfect global cleanup. Its architecture assumed independent stores and separated the two outcomes accordingly.

That choice leaves a messier history. Readers may encounter both versions. Archives may preserve what a serving site no longer shows. Operators must explain whether “superseded” means linked, hidden, locally withdrawn or actually absent from a particular corpus.

But the alternative fiction—a button that edits the distributed past everywhere—would have been worse. Netnews made the revision a new fact and the withdrawal a request. The corrected record could travel forward even when the old record could not be called back.