Summary

  • NNTP put news distribution, retrieval and posting behind one stream protocol, but deployed servers did not necessarily offer all three jobs to every connection.
  • MODE READER let a client ask a mode-switching server to leave transit mode and expose reader facilities; a fresh CAPABILITIES response became the evidence of what the connection could now do.
  • The switch could reset session state, could not be pipelined or repeated, and did not itself grant posting, authentication or privacy. Role, permission and security remained distinct.

The socket stayed; the service changed

A news client connects to TCP port 119 and asks for capabilities. The answer includes IHAVE, the command used to offer an article to another news server, plus MODE-READER. It does not include READER. The client sends MODE READER. The reply is successful. A second capability list now includes READER, NEWNEWS and reader-oriented forms of LIST; IHAVE may be gone. The same endpoints and ordered byte stream now describe a different service surface.

This is a small transition with a large architectural consequence. An endpoint name and a port number identify where to begin a conversation. They do not fully identify what the conversation is authorized to become. The current state does.

NNTP needed this distinction because its original remit was unusually broad. RFC 977, published in 1986, specified distribution, inquiry, retrieval and posting of network news. A workstation could read selected articles from a central store. Cooperating hosts could also exchange copies for local storage. The same protocol family connected a person to a database and one news system to another.

Nothing in that combined grammar required one implementation to treat those workloads identically. Reader traffic asks for groups, article numbers, headers and bodies. Transit traffic offers or streams articles between peers. The trust relationships, indexes, rate limits and storage paths can differ even when the wire begins at the same rendezvous.

Deployment found the role before the standard named it

The explicit switch did not begin as a clean-sheet abstraction. RFC 2980 collected NNTP extensions already found in running software. It says MODE READER first appeared in INN and was used by a client to announce that it was a news-reading client. Some servers used the information to reconfigure themselves for better handling of reader commands.

That history matters. The command was not invented because the standards community preferred modal protocols. It recorded an operational fact: one listener could front different internal jobs, and clients needed a way to select the job they actually wanted.

RFC 2980 contrasted MODE READER with RFC 977’s SLAVE, which had not been widely implemented. The contrast is easy to overstate. SLAVE and MODE READER are not opposite settings in one symmetrical design. The useful evidence is narrower: deployment retained a need to say “treat this connection as a reader,” while an earlier hint about a subordinate server did not become the governing mechanism.

Capabilities turned an implementation detail into evidence

RFC 3977 made the split precise. It describes reading servers, transit servers and mode-switching servers. Before the switch, a mode-switching server is in transit mode. It advertises MODE-READER and does not advertise READER. After a successful MODE READER, it stops advertising MODE-READER, advertises READER, and may cease to advertise IHAVE even if that transfer command was offered before.

The change is not merely cosmetic. RFC 3977 requires a capability list to reflect the facilities available in the server’s current state. That turns CAPABILITIES into a time-bounded statement: true here, after these prior commands, for this session.

A client that caches the first list and continues using it after the switch has confused server identity with session evidence. A software package may implement IHAVE; the present connection may no longer allow it. The binary “supports NNTP” is weaker still. It says nothing about which role, which commands or which permissions are active.

The IANA NNTP Parameters registry preserves this vocabulary. MODE-READER names a switching server and the command; READER names availability of reader commands; IHAVE and STREAMING identify feed mechanisms. Registration coordinates labels. It does not promise that any particular endpoint offers them now.

A role switch is a parser boundary

RFC 3977 says MODE READER must not be pipelined. That rule prevents a client from sending the switch and several reader commands without first learning whether the boundary was accepted and what state emerged.

Imagine a client sends MODE READER, GROUP comp.protocols.tcp-ip and NEXT in one burst. A switching server may discard text received around the mode change; another may interpret it under the wrong command surface. The client then pairs replies with commands that the server never accepted. Pipelining is efficient only while both sides agree on the state in which queued commands will be interpreted.

The command must not be issued more than once in a session, and it must not follow security or privacy commands. The server may reset its state to what existed immediately after the initial connection before entering reader mode. Those rules refuse a seductive promise: that changing jobs will preserve every fact accumulated under the old job.

Selected group, current article, authentication assumptions and extension availability must therefore be treated according to the explicit contracts, not carried across because the TCP connection survived. Continuity of transport is not continuity of application state.

A reader was not automatically a publisher

Successful MODE READER has two normal replies. 200 says posting is allowed; 201 says posting is prohibited. Both indicate that reading mode is available. A 502 means reading service is permanently unavailable, after which the server closes the connection.

That three-way outcome keeps separate questions separate. May this connection enter the reader command surface? May it submit new articles? Is that service unavailable here? A client that treats “reader” as “can post” has silently enlarged the grant.

Even the greeting text is not the whole answer. The current capability list can express whether POST is actually available and can change after later state transitions. The lesson is not that response codes are useless. It is that coarse admission and fine-grained capability evidence have different scopes.

Security was another axis, not a side effect of mode

RFC 3977 gives an example in which STARTTLS appears only after the server has entered reading mode. RFC 4642 separately defines the privacy transition, while RFC 4643 defines authentication. Each can change the capabilities that follow.

MODE READER supplies neither. It identifies the desired service role to a server willing to switch. It does not prove who the client is, encrypt the stream or authorize posting. Conversely, an authenticated or encrypted connection is not automatically a reader session. Treating these dimensions as one flag would obscure both least privilege and failure diagnosis.

RFC 4644 adds streaming feed commands for transit. Their presence is evidence about the feed role, not a universal property of the server. The protocol became more intelligible by letting role, security and command availability change through named transitions rather than by pretending that one port implied one permanent persona.

The boundary is the durable invention

Modeful protocols are often criticized because hidden state makes clients fragile. MODE READER is valuable precisely where it makes state less hidden. The command names the requested transition, the response admits or refuses it, and a new capability list describes the resulting surface.

That does not make the design costless. A single endpoint multiplexing peer feeds and human reading can concentrate policy errors. Clients must re-evaluate assumptions. Servers must ensure that commands, credentials and selected objects do not leak across roles. Separate listeners might simplify some deployments.

The standards do not prove which architecture is universally better. They preserve a narrower operational law: when a connection changes jobs, the protocol must expose the boundary strongly enough that both sides can stop relying on the old job.

Sources and evidence limits

These documents establish specified behavior, standardization history and registered capability names. They do not establish present deployment share, current server architecture, traffic volume or an operator’s policy. The article therefore does not infer implementation prevalence from registration and does not treat MODE READER as authentication, encryption or posting permission.