Summary

  • RFC 818 assigned port 107 to an optional Remote User Telnet service: the application reached by the caller was capable of initiating another Telnet connection instead of merely presenting a host executive.
  • BBN's TC68K put an inbound Server Telnet and an outbound User Telnet back to back through a pseudo-teletype. The bridge reused running components, but it still contained two TCP connections, two Telnet endpoints and several local authority boundaries.
  • A successful test observed that particular chain at that time. The port number located a capability; it did not authenticate the operator, authorize an outbound target or prove application completion.

Port 23 normally ended at an executive

Early Telnet had a recognisable front door. A User Telnet initiated a connection; a Server Telnet listened at port 23 and usually attached the caller to the host's executive. On TOPS-20 that might mean EXEC. On Unix it might mean a shell. The remote machine exposed a general environment in which the user could choose the next program.

That convention rested on a deeper design. RFC 764, published in 1980, described Telnet as a general, bidirectional byte facility for terminal devices and terminal-oriented processes. Its common object was the Network Virtual Terminal, an imaginary keyboard-and-printer interface that prevented every host from having to know every other terminal. Optional behaviour could be negotiated; refusal returned both ends to the minimum NVT state.

The labels User and Server were practical rather than constitutional. The User host normally held the physical terminal, but the same document offered a more portable definition: in terminal-to-terminal or process-to-process use, User was the side that initiated the communication. The role belonged to a connection. It was not a permanent rank attached to a machine.

Port 23 nevertheless made one application shape dominant. Connect there and the remote Server Telnet was expected to deliver a terminal session to a general service host. That assumption became awkward on machines that had networking but no executive worth entering.

The small host did not need to pretend it had a shell

RFC 818, published in November 1982, began with an unglamorous exception. A small host might have very limited functionality and no executive. On such a machine, a general Telnet login was unnecessary. A specific application could be useful enough to deserve a well-known rendezvous of its own.

The specified application was surprising: User Telnet. A host choosing to provide the Remote User Telnet service listened at port 107. The incoming connection still used Telnet, yet the capability behind it was the program that could itself act as the User side of another Telnet connection.

This was not a semantic trick in which a server was renamed a client. There was a listening service at the outer boundary, and there was an outbound User Telnet inside the host. RFC 818 made the composition addressable. It did not erase either process.

The distinction matters because well-known numbers answer only a narrow question: which local listener is intended for this kind of exchange? The number does not say who may call, which destination the internal User Telnet may reach or what the final application will do.

Sixteen serial lines and one reusable process graph

RFC 818's example came from running machinery at Bolt Beranek and Newman. The TC68K was a terminal concentrator built around a Motorola MC68000. It had one network connection, sixteen RS-232 terminal connections and a programmable timer. Its Micro-Operating System ran IP, ICMP, TCP and Telnet.

The machine already contained two useful pieces. User TC-Telnet let a person at an attached terminal connect to a network host. Server Telnet did the reverse kind of adaptation: it fronted devices with no network awareness, including remote printers, plotters and computers.

BBN had TC68Ks in several buildings and needed an operational way to test a remote unit. Rather than design a new management protocol, its software put a User Telnet back to back with a Server Telnet. An operator opened a Telnet connection to the remote concentrator and appeared to the User TC-Telnet as though sitting at a terminal local to that unit. The operator could then create the outbound connection and inspect statistics already maintained by the standard application.

The memo says the only additional software needed was a pseudo-teletype driver. To an application the PTY looked like a terminal. Internally it provided a character stream between two processes.

This was Running-Code Primacy in miniature. The implementation did not enlarge the shared protocol merely because one site had an operational need. It reused Telnet's existing wire agreement and placed a small, local adapter between programs that already worked.

One terminal view concealed two conversations

For the operator, the result could feel like one continuous console. The implementation graph was more exact:

  1. the operator's local User Telnet opened an incoming TCP connection;
  2. the TC68K's Server Telnet terminated that connection;
  3. a PTY carried a local character stream into the TC68K User Telnet;
  4. that User Telnet initiated a second TCP connection to the selected target.

Each Telnet connection had its own state. Each could negotiate options independently. Either TCP connection could close while the other process still existed. A character accepted on the first stream was not thereby acknowledged by the final application on the second.

RFC 818 does not define a universal option translator, an end-to-end security association or a rule for propagating every failure across the PTY. Calling the arrangement back to back should not tempt us to turn it into a transparent pipe. Telnet carries data and interspersed controls; local NVT mapping and process behaviour still happen at both endpoints.

The later RFC 854 helps explain why the graph was legitimate. It retained the symmetric view of terminals and processes, while acknowledging that symmetry was an operating principle rather than an iron law. The same host could be Server on the incoming connection and User on the outgoing one. There was no contradiction because the verbs referred to different relationships.

A green test had a precise evidence boundary

RFC 818 says the arrangement verified that the network path between two TC68Ks was operational. That statement should be kept at its observed scale.

A successful session showed that the caller reached the listening service, the inbound Telnet processed enough of the exchange, the PTY transferred the relevant stream, the outbound User Telnet created the tested connection and the target returned enough information for the operator to see its statistics. That is meaningful operational evidence. It covers more than an ICMP echo and less than every property of the network.

It did not prove that another route would work, that every Telnet option survived the composition or that a printer completed a job. It did not identify the human merely because characters arrived from a socket. It did not show that the listener had authority to reach any arbitrary destination.

This distinction between transport and verdict is easy to lose in a console. A familiar prompt collapses many layers into one visual surface. Good operations reconstructs the hidden chain: admission, local bridging, outbound selection, remote acceptance and final work.

The common terminal remained the safe floor

By 1989, RFC 1123 described Telnet primarily as the standard remote-login protocol linking a keyboard/display to a command interpreter. Yet its requirements continued to name User and Server Telnet separately. Both had required control functions; both had to handle unsupported commands; every implementation had to retain option negotiation and fall back to NVT when richer agreements failed.

That combination is important. Symmetry made process composition possible. Role-specific duties kept the composition intelligible. A minimum common state let endpoints refuse optional behaviour without being declared invalid. A TC68K could offer port 107; another host could decline to offer it. Publication did not create deployment by decree.

The current IANA Service Name and Transport Protocol Port Number Registry still carries rtelnet at port 107 with the description Remote Telnet Service. The row preserves a coordination reference. It is not evidence that the service is currently deployed, secure or supported by a particular product. Nor does the registry's UDP row turn RFC 818 into a datagram protocol: the memo specified Telnet on a connection.

A serial port eventually needed more than characters

Fifteen years after RFC 818, RFC 2217 used Telnet for another access-server boundary. A client could reach a serial port connected to an outbound modem, printer, plotter or monitoring device. Experience had made the missing semantics visible.

A bare character stream could not reliably express baud rate, data width, parity, stop bits, modem-signal changes and two different layers of flow control. RFC 2217 therefore defined a Telnet COM-PORT-OPTION. The endpoints negotiated it with the ordinary WILL, WON'T, DO and DON'T machinery. Once accepted, explicit commands changed port state and explicit notifications reported line state.

Most revealingly, the server acknowledged a configuration command after processing it and reported the value actually set. TCP had already acknowledged receipt of bytes. The later reply established a different fact: the access server had applied a value, which might differ from the requested one.

The security section also separated admission from cleanup. Authentication was one concern. When a session ended, the server was expected to disconnect the remote service and reset the serial geometry to a known administrator-defined state. Otherwise one caller's local choices could become the next caller's inherited reality.

RFC 2217 is not presented here as a documented descendant or replacement for RFC 818. It is a later test of the same architectural boundary. Reusing a stream is cheap. As soon as local hardware decisions matter, those decisions need named commands, reports and an owner responsible for restoring state.

A number located the service; it did not own the chain

RFC 818's deepest lesson is smaller than a modern remote-access platform and more durable than port 107. A stable common interface allowed a site to rearrange local implementation roles. The shared layer said how Telnet peers could converse. The TC68K decided which processes to join and whether to expose that composition. The operator chose a target under whatever local controls existed. The target still decided what service to perform.

Registration named the door. Listening made the door real on one host. Authentication could name a caller. Authorization could limit the next connection. Application evidence could prove the work. None of those verbs could substitute for all the others.

The client became a service because running components made that composition useful—not because a registry transformed a program into an authority.