Summary

  • A checkgroups body was an exhaustive snapshot of the groups represented within its scope, including descriptions and moderation status. Omission therefore had operational meaning: an agent honoring the request was being asked to remove an omitted group.
  • Scope exclusions and a monotonically increasing serial made comparison safer. They identified which part of the namespace the snapshot covered and helped a server reject an older catalogue after it had honored a newer one.
  • Neither completeness nor freshness created authority. The media type carried no authorization information, and every Netnews agent retained the right to authenticate, decline or adapt the requested reconciliation under local policy.

The fourth card

Suppose two serving agents each hold four entries beneath the same hierarchy. Three are expected; the fourth is a local survivor from an earlier catalogue. A control article arrives with a complete three-entry body, a scope that covers the hierarchy but excludes one named sub-tree, and a serial higher than the last one either server honored.

The first operator accepts the issuer, compares the complete set and sends the fourth entry to review before retiring it. The second authenticates the same message but preserves that entry because a local community still depends on it. Neither server touches the excluded sub-tree. When an older copy later reappears, both recognize its lower serial and refuse to roll their catalogues backward.

The striking fact is not that their inventories diverge. It is that the protocol could make the evidence for comparison exact without pretending to own the result. checkgroups standardized the offered catalogue, its boundary and its sequence. It left execution with the custodians of the receiving systems.

An early list for a local administrator

RFC 1036 described the earlier form with unusual operational clarity. The body of a checkgroups control message contained the official list of newsgroups and their descriptions. A news host compared that list with the groups it currently carried, reported obsolete or newly available groups to the local Usenet administrator and updated descriptions from the supplied body.

That workflow already separated three things that are easy to collapse: a transported reference list, the host's current inventory and the administrator's response. The document did not describe an invisible universal database mutation. It described comparison performed at a particular host and information presented to the person responsible for that host.

The list was useful precisely because it could expose drift. A local entry could be absent from the official list; an official entry could be absent locally; a matching name could carry an outdated description. Each discrepancy was evidence for action, not proof that action had already occurred everywhere.

Completeness made silence meaningful

The later architecture in RFC 5537 gave the format sharper semantics. A checkgroups message requests that an agent ensure the listed groups exist, remove groups within the represented hierarchy that are not listed, and bring descriptions and moderation status into agreement.

Those removal semantics depend on a demanding rule: the body must contain the complete list for every hierarchy it represents. It must not carry only a convenient subset. If a supposed snapshot were partial, absence would become ambiguous. An omitted group might be obsolete, or it might merely have been left out of this installment. Exhaustiveness turns omission into a usable statement.

This is a general lesson in reconciliation systems. A delta says what changed. A complete snapshot also says what does not belong, but only inside a declared boundary. Treating a partial list as complete can destroy valid local state; treating a complete list as a loose suggestion prevents reliable cleanup.

Scope drew a fence around absence

Completeness alone is dangerous when the namespace has delegated or independently managed branches. RFC 5537 therefore defines the chkscope parameter. Positive prefixes include hierarchies in the message's scope; prefixes beginning with an exclamation mark exclude them. Inclusion is evaluated before exclusion regardless of the order in which the tokens appear.

The distinction lets a publisher say, in effect: reconcile this hierarchy, except for that sub-hierarchy whose catalogue is maintained elsewhere. A conforming body should also avoid listing groups outside its intended scope, because older software may not understand chkscope and could otherwise act on names it was never meant to reconcile.

Scope is thus more than a query filter. It determines where omission is evidence. Outside the fence, silence means nothing. Inside it, an omitted name can support a removal request. Any audit that records the body but discards the effective scope loses the fact needed to interpret absence safely.

A serial resisted stale rollback

The optional chksernr parameter adds ordering. Its value is positive, rises whenever the corresponding list changes and never decreases. Subsequent lists with the same scope carry the new value. A server is advised to remember the last serial it honored and decline a message with a smaller serial or no serial at all.

This is not a timestamp and not a global version of all Netnews. It is a forward-moving sequence attached to a particular catalogue scope. The specification deliberately places no numeric upper bound beyond the header's size limits and warns implementations not to assume that the value fits a native integer type. Comparison must survive long operational histories rather than depend on a machine word.

The serial solves a narrow but consequential problem. Distributed control traffic can arrive late, be replayed or traverse unequal paths. Once a server has accepted a newer complete snapshot, an older one should not silently restore names or metadata that the newer catalogue superseded.

The media type refused to impersonate authority

The registered application/news-checkgroups body encodes group names, descriptions and moderation markers. Its registration also states the missing capability plainly: the media type provides no authorization information. Authorization must be obtained through another mechanism.

That negative property is a design boundary. A well-formed, complete and newer list can still be unauthorized. Conversely, a server may trust the issuer yet choose not to apply every requested change automatically. Format validity, source authentication, hierarchy authority and local execution are separate judgments.

RFC 5537 reinforces the separation. Group-control messages require Approved, but agents need an authentication and authorization arrangement before acting. No Netnews agent is required to honor a control message. The protocol can define the request perfectly without granting the sender compulsory power over a receiver's catalogue.

Observation remained server-specific

RFC 3977 supplies a useful counterpoint through NNTP's LIST ACTIVE command. It reports the groups known to the queried server together with status information. That is an observation of one serving agent, not a reconstruction of the authoritative hierarchy snapshot and not proof of universal adoption.

Comparing LIST ACTIVE with a trusted checkgroups body can reveal missing names, unexpected names and status differences. It cannot by itself explain why they differ. The server may have declined the control message, retained a local exception, excluded a sub-tree, delayed an administrative decision or stopped offering a group while retaining historical metadata.

Reliable reporting must therefore name both surfaces: the received reconciliation claim and the observed local inventory. “The hierarchy removed a group” is too broad when the evidence shows only that a scoped list omitted it and one server acted.

The article and header registries named instruments, not owners

RFC 5536 identifies a control article as an article requesting action beyond ordinary storage and relay. The permanent Control entry in the IANA Message Headers Registry keeps that field recognizable. The media-type registration similarly stabilizes the syntax of a checkgroups body.

These registries make interoperable instruments possible. They do not publish the canonical membership of every hierarchy, appoint every hierarchy custodian, certify the person in Approved or record which servers executed a request. Registration governs the envelope and body format. Catalogue ownership remains an operational relationship outside those registries.

Reconciliation without a fictional centre

checkgroups is historically interesting because it solved several hard problems at once without solving the wrong one. It made an omission interpretable by requiring completeness. It constrained that interpretation with scope. It reduced stale rollback with a monotonic serial. It carried enough metadata to compare names, descriptions and moderation status.

Yet each safeguard stopped short of central command. The receiving agent still determined whom to trust and what to change. A local exception could remain visible as an exception instead of being mistaken for packet loss or covert corruption. Two inventories could diverge while both operators understood exactly what the same offered snapshot had asked them to do.

That is a durable model for distributed administration: strengthen the statement until it is precise enough to reconcile, but do not confuse precision with possession. A complete list can describe a whole hierarchy. It cannot, by itself, own every copy of that hierarchy.

Sources