Summary

  • RFC 1041 proposed one 3270-REGIME Telnet option, but RFC 1576 recorded that very few developers implemented it. Running systems instead combined Terminal-Type, Binary and EOR into traditional TN3270.
  • The three-option convention established a usable presentation regime and message boundaries. It did not expose a requested device/LU name, the SNA BIND behind the gateway, a correlated processing response or one universal meaning for ATTN and SYSREQ.
  • TN3270E later made device allocation, BIND state and positive/negative responses separately negotiable. Its richer record still did not authenticate a user, guarantee every function or prove a human or business outcome.

The option designed for the job lost

In January 1988, RFC 1041 proposed a clean answer to a difficult transition. Telnet normally presented a Network Virtual Terminal. IBM 3270 displays used a different world: EBCDIC rather than NVT ASCII, block-oriented commands rather than an ordinary character stream, and terminal models whose dimensions and features affected what a host could send.

The new Telnet option 29, 3270-REGIME, would let the client offer an ordered list of regimes and let the server choose one both could support. Agreement would imply binary data and IAC EOR record boundaries. The same option described how to return to NVT ASCII and how to renegotiate a terminal type.

RFC 1041 paid unusual attention to the instant of change. A client entering negotiation should stop accepting user data. A server should avoid sending data while the regime was undecided. It could announce the new regime only after outstanding bytes had gone, and each side changed interpretation at a specified send or receive event. Switching might require flushing data in both directions. The document understood that a label applied one moment too early could cause valid bytes to be parsed under the wrong grammar.

The design was coherent. It did not become the installed center. RFC 1576, whose RFC Editor record dates it to January 1994 and classifies it as Informational, says very few developers and vendors implemented RFC 1041.

That statement is bounded. “Very few” is not none, and an Informational record is not a census. It is nevertheless enough to explain why RFC 1576 documented another practice rather than treating the earlier standard as operational fact.

Three existing switches became one regime

Traditional TN3270 reused three Telnet options:

  • Terminal-Type identified a 3270 emulation such as a particular model and screen size.
  • Binary allowed the eight-bit data path required by the 3270 stream.
  • End of Record made the end of each block visible as IAC EOR.

The base Telnet specification, Binary Transmission option and End of Record option supplied the components. No one of them meant “TN3270”. Running implementations composed them.

RFC 1091 made Terminal-Type deliberately asymmetric. The server asked; the client answered and could cycle through alternatives. Sending a new type could require the client to change its emulator, but receiving the name did not oblige the server to change processing immediately. Binary and EOR also had their own Telnet negotiation state and direction.

RFC 1576 treated the order of the three negotiations as unimportant. Once an appropriate terminal type, binary transmission and EOR were in place, both sides exchanged complete 3270 commands terminated by EOR. If the server later withdrew either Binary or EOR, the connection no longer satisfied the TN3270 regime and the client interpreted subsequent server data as NVT ASCII.

This worked because the common contract stayed narrow. EOR supplied a boundary, not a result. Binary preserved octets, not meaning. Terminal-Type selected a representation, not a physical machine. The gateway still owned the translation between the Telnet-facing client and whatever SNA or non-SNA path reached the host application.

The screen hid two sessions

In an SNA environment, a 3270 terminal ordinarily had one session with the host application and another with the System Services Control Point. The second path carried control and service interactions. TN3270 showed the client one Telnet connection. It did not make the SNA split visible or let the emulator discover how the server itself was attached.

The missing identity was concrete. SNA sessions used Logical Unit names. Traditional TN3270 offered no standard way for a client to request that its connection be associated with a specific 3270 device name, and no defined way to learn the LU assigned behind an SNA-connected server. RFC 1576 calls the client's IP address the closest thing to an LU name in the TN3270 environment. “Closest” is not equivalent: an address locates one network endpoint; it does not name the host-side logical device through which an application distinguishes sessions.

This gap mattered because host applications could behave differently according to the terminal's network name. A terminal-type string such as a 3278 model answered what representation the emulator offered. It did not answer which logical unit the server allocated.

The -E suffix created another bounded hint. It indicated that a client could handle structured fields and was often read as support for extended attributes. RFC 1576 notes that implementations did not all interpret it identically. A familiar terminal name therefore remained a convention between peers, not a complete capability inventory.

A record end was not a processing receipt

EOR solved framing. A 3270 command and its associated data had no outer length in traditional TN3270, so IAC EOR told the receiver where one complete block ended. That is valuable evidence: it separates blocks and allows the receiver to begin interpreting one message.

It says nothing about what happened after the boundary. RFC 1576 explicitly lists the SNA positive/negative response process among what traditional TN3270 did not support. Data sent through the connection was assumed either handled or ignored. An SNA positive response could report that prior data had been processed. A negative response could expose an invalid command or a mechanical failure at the client. Traditional TN3270 did not carry that result back.

This is the sharpest evidence boundary in the design. TCP delivery and EOR can establish that a delimited block reached the peer's Telnet path. They do not establish that the emulator accepted its command, drew a correct screen, that a printer acted, that the host application saw a reply or that a person understood what appeared.

Presence tests were narrower still. Some servers sent Telnet NOP or used Timing Mark to learn whether the client process remained reachable. NOP required no answer; an abnormally terminated client might eventually become visible as a TCP send error. A live connection is not an application receipt, and it is certainly not human presence.

The special keys exposed the adapter

ATTN and SYSREQ looked like keys but crossed several authority boundaries. Many SNA host applications interpreted ATTN as a request to interrupt current processing. Many TN3270 servers mapped it from Telnet BREAK and translated that command toward the host. A non-SNA server could simply ignore BREAK.

SYSREQ was even less uniform. Some servers interpreted Telnet Interrupt Process as SYSREQ; others used a 3270 Test Request. In SNA, the key could move the terminal between its application session and the SSCP session. The client-facing Telnet stream had no direct form for all SSCP data, so the server had to handle that interaction, convert it, or ignore the event.

The user's keystroke, the client's Telnet command, the server's mapping, the SNA control event, the application's interruption and the screen that followed were therefore separate facts. Recording only “SYSREQ sent” would grant the first layer authority over the rest.

TN3270E restored facts one by one

RFC 1646 and RFC 1647 quickly described extensions for the state traditional TN3270 omitted. The later Standards Track RFC 2355, identified by its official record, consolidated TN3270E in 1998.

TN3270E did not redefine Terminal-Type as universal truth. It created a new option with two explicit negotiations. First, client and server agreed on a device type and optionally a requested resource or device name. A server could accept and return the assigned device name or reject the request with a reason such as unknown name, device in use or type/name mismatch. Only then did the peers negotiate a function set.

Those functions were separable. BIND-IMAGE let an SNA-connected server report when its host-application session began or ended and pass the accepted BIND image. RESPONSES added message headers, response-request flags and sequence numbers so a positive or negative processing result could be tied to the block that caused it. SYSREQ and printer controls had their own entries. The agreed list could also be empty—basic TN3270E.

Silence still had grammar. Under RESPONSES, a message could request no response, a response only on error or a response in every case. A missing reply after NO-RESPONSE was not a success receipt; it was the expected absence of one. Without the RESPONSES function, the sequence field was ignored. Without BIND-IMAGE, the client did not gain the bind record merely because TN3270E itself had been negotiated.

Fallback also remained deliberate. If either side refused TN3270E, traditional TN3270 could still be used. A richer option did not erase installed compatibility. It provided a way to know which stronger records were actually present.

Running code was evidence, not sovereignty

The historical temptation is to choose a winner. RFC 1041 was formally tidy but sparsely implemented. Traditional TN3270 was widely enough established to deserve documentation. TN3270E later recovered missing structure.

That sequence supports a more useful conclusion. A specification does not reconfigure the world by publication. Running code can reveal the thinner agreement that participants were actually willing to maintain. But installed practice does not acquire authority over facts it never represented.

Heng Lu's running-code argument supplies the editorial lens: observe the system that acts rather than letting the document claim reality on its behalf. His essay on a minimum common specification and localized future decisions explains why the three-option settlement could be valuable: it reused a small common vocabulary while the gateway and endpoints retained local control. His reality-layer discipline prevents the next mistake—turning a representation, a connection and a processing outcome into one symbol called “terminal”. These are retrospective editorial applications, not claims about the RFC authors' intentions.

The enduring lesson of RFC 1576 is not that three options are better than one. It is that every claim should stop where its record stops. Terminal-Type could name an emulation. Binary could preserve bytes. EOR could close a block. A device name, SNA bind, processing result, interrupt and human consequence each required another receipt.

Sources