Summary

  • RFC 977 treated duplicate news as a link-dependent cost: on interactive peers, sites could compare what each already held before sending article text.
  • The same RFC retained flood-and-discard for single-transaction UUCP links, where sending a batch could finish sooner than negotiating each transfer.

In February 1986, Brian Kantor and Phil Lapsley published RFC 977, the proposed Network News Transfer Protocol. Its most revealing claim was not that one transport should conquer Usenet. It was that the cost of a duplicate depended on the connection carrying it. On an interactive stream, two hosts could ask what each had and decide what to send. On a link that opened only once a day, the conversation needed to arrange that decision could cost more than the duplicate itself.

The problem was structural. In the traditional arrangement described by the RFC, news moved from host to host by flooding: each site forwarded new articles to its feeds, which forwarded them onward. A site with two feeds might receive the same article twice. With a one-way or scheduled transfer, the sender could not conveniently stop to ask whether the receiver already had it. The receiver accepted the batch and discarded duplicates after transmission. That used time and communications capacity, but it kept the session simple.

NNTP added a conversation. A client could ask a server which newsgroups had appeared, then ask for message identifiers in the groups it wanted. It requested the articles it lacked. In the other direction, a host could tell a peer which articles it had recently received; the peer could distinguish items already in its collection from those it still needed. The article body was no longer the first evidence that a particular message had crossed the link. Hosts could compare identifiers first.

That distinction depended on the path. RFC 977 says well-connected hosts on a local or other fast network might distribute news more efficiently with NNTP than with traditional methods such as UUCP. But it also explains why UUCP’s batch logic made sense: on a single-transaction link, especially one used once daily, sending all articles and letting the receiver remove duplicates could reduce total delivery time. Interactive negotiation was not automatically cheaper just because it transmitted fewer bytes.

The RFC describes another use that is easy to blur with inter-site transfer. A university or office could keep a central news spool and let workstations read from it over a local network. Users selected items from shared storage instead of keeping another full copy on every machine. An intermediate server could cache recently retrieved articles. This was a reader-access and storage arrangement; it did not mean every Usenet site shared one central database.

RFC 850 had already standardized the shape of a USENET article while leaving transmission methods flexible: sites could choose their hardware and software and whether to batch news. RFC 977 worked within that varied world. It specified a stream-based way to inquire, retrieve, post and exchange articles, while acknowledging a different transport’s advantage on intermittent lines. The design was conditional and plural: use the conversation when the network can sustain it; keep batching where it saves time.

The record proves a protocol design, not a universal migration. RFC 977 does not tell us what share of Usenet moved to NNTP in 1986, quantify bandwidth saved, or show that every implementation avoided duplicate transfers. Its contribution is narrower: it made article selection a live exchange between peers, so a receiver could say what it wanted and what it already had before the sender shipped another copy.

Source records: RFC 977, Network News Transfer Protocol; RFC 850, Standard for Interchange of USENET Messages; RFC 1036, Standard for Interchange of USENET Messages.