Summary

  • IHAVE begins with a Message-ID, not an article body. A receiver can report that the article is already known, defer the decision, or ask the sender to transmit the complete article.
  • A request for the body is only the first gate. After receiving it, the server can accept, defer or reject the transfer under local checks; even a positive transfer acknowledgement does not guarantee permanent retention.
  • CHECK and TAKETHIS later separated the same decisions into pipeline-friendly operations. They increased throughput without turning an advisory request into a transfer of ownership or policy authority.

Three offers at the first gate

Imagine a sender holding three short news articles. It does not immediately push all three bodies. Instead, it presents three compact identity tokens. The receiver recognizes one from its history, lacks enough resources to decide about another, and asks to see the third. The first body is spared, the second remains eligible for retry, and only the third consumes the full transfer cost.

That third article then reaches a second gate. Its syntax may be malformed, its groups may be unacceptable, its distribution may be outside local policy, or storage may have become unavailable. The server that requested the bytes can still refuse them. The important historical innovation was not simply duplicate detection. It was a visible state machine that postponed expensive carriage until desire was known, while reserving final judgment until the evidence needed for judgment had arrived.

The bandwidth problem came first

RFC 1036 records an earlier Netnews mechanism built from ihave and sendme control messages. One system advertised the Message-IDs it possessed; another requested the identifiers it lacked. The exchanges could be batched because the cost of offering a single identifier might approach the cost of a very short article.

That older exchange exposes the economics behind the later command. Store-and-forward news spread across links whose capacity, schedule and price varied sharply. Sending every article merely to discover that the neighbor already held it wasted scarce carriage. An identity-first offer converted the receiver's history into a bandwidth decision.

The mechanism also established an enduring distinction. A Message-ID was sufficient to ask whether a particular article was wanted, but it was not a substitute for the article. The identifier controlled the negotiation; the full headers and body supplied the material that could actually be inspected and stored.

IHAVE put two verdicts on the wire

RFC 977 turned that idea into the NNTP IHAVE command. The client sends a Message-ID. The server may reply 335 to request the article, 435 when it does not want it, or 436 when the transfer should be tried again later. Only after 335 does the client send the article, terminated in the normal NNTP manner.

A second reply follows the body. 235 means the article was transferred successfully, 436 marks a temporary failure, and 437 rejects the article without inviting a retry. The document explicitly allows rejection after inspection for reasons including unwanted newsgroups or distribution, insufficient storage, excessive length, and garbled headers.

This two-step vocabulary prevents a misleading compression. “The server accepted the Message-ID” is not a final acceptance; the server merely requested enough information to decide. Likewise, “the client sent the article” says nothing about the second reply. An operational record that keeps only one of the two verdicts erases the protocol's central boundary.

Modern NNTP sharpened the states

RFC 3977 preserves the two-stage exchange and clarifies how failures behave. IHAVE cannot be pipelined: the client must wait for the first response before sending the article and must wait for the second response before treating the transaction as complete. If a response never arrives, the transfer is treated as a temporary failure rather than presumed success.

The modern specification also separates transit from posting. IHAVE is for transferring an already-formed article between peers; POST is for injecting a new article. A transit receiver is expected to recognize a repeated offer of the same identifier or article consistently enough to suppress needless duplicates, but local policy still controls whether the offered material belongs on that server.

This matters for evidence. The first response describes desire at a moment in time. The second describes the result of one attempted transfer. Neither proves that the server later retained the article, offered it to readers, or forwarded it to every next hop.

A positive reply was never a custody receipt

RFC 977 warns that a server returning 235 may later discover the article is unacceptable and silently discard it. RFC 4644 carries the same warning into streaming: after a successful 239 response to TAKETHIS, later processing may still discard the article.

That qualification is easy to overlook because success codes look definitive. They are definitive only for the defined transaction boundary. They say that the peer accepted responsibility for this transfer exchange, not that a universal archive, reader-visible catalogue or downstream propagation obligation now exists.

The practical consequence is that delivery evidence must be layered. A positive NNTP response proves more than a sent byte count, but less than later storage, serving or onward relay. Conflating these layers turns a protocol acknowledgement into a fictional guarantee.

Streaming moved the waiting, not the authority

Classic IHAVE pays a round trip for each first-stage decision and then another for the body result. RFC 4644 introduced streaming commands so several decisions could be in flight. CHECK asks whether an article identified by Message-ID is wanted. TAKETHIS sends the complete article and produces the final accept-or-reject response.

The split permits many CHECK commands and article transfers to proceed without serial waiting. Yet CHECK remains advisory: the receiver must not assume the sender will obey it. A sender may use TAKETHIS without a preceding CHECK when site policy or an adaptive strategy permits, and the receiver must still make the final decision.

Streaming therefore changes queue geometry, not custody. It can fill a long-delay link efficiently, but it does not force a peer to store an article, remove local filters or surrender the right to reject after body inspection.

Site agreement sat outside the command grammar

RFC 5537 places these transfers in the wider Netnews architecture. The ancient ihave and sendme control messages had become largely obsolete on the Internet, although some UUCP environments still used them. Modern peering instead depended on arrangements between sites about what to exchange and how to transport it.

Those arrangements are not encoded by a bare Message-ID. Peers decide which hierarchies, distributions and article classes they want; they may use IHAVE, streaming, batch feeds or other agreed transport. The protocol makes each offer and verdict legible, while the authority to establish a feed and the policy to retain material remain with the sites.

This is why “accepted by NNTP” is too broad a historical claim. One must ask: accepted at which gate, by which peer, under which peering policy, and with what later evidence of custody?

The offer that kept its limits

IHAVE succeeded by refusing to let one word—acceptance—cover the whole journey. The sender first exposed identity. The receiver chose whether the body was worth carrying. The receiver then inspected the body and issued a transfer result. Later storage and propagation remained separate observations.

CHECK and TAKETHIS preserved the same boundaries while allowing the link to stay busy. The protocol became faster without pretending that speed abolished discretion. In a distributed system, an efficient offer can save bandwidth; only the receiving custodian can decide what the offered object becomes.

Sources