Device-types are deliberately limited to a small set of logical names (IBM-3278-x, IBM-3287-1) rather than a comprehensive list of physical IBM hardware models. This simplifies negotiation and decouples capability discovery from device naming: actual extended data stream capabilities are determined via the Read Partition Query / Query Reply mechanism, not by the device-type string.

The FUNCTIONS negotiation uses a counter-offer model (both sides may send REQUEST with differing lists) rather than a simple accept/reject, enabling convergence to a mutually supported subset without requiring either side to know in advance exactly what the other supports. The anti-loop rule (do not re-add a function the other side removed) bounds the negotiation.

The Telnet IP command was chosen to implement the 3270 ATTN key because IP was explicitly defined in the Telnet specification for interrupting a running process, which matches the SNA semantics of ATTN. The Telnet AO command was chosen for SYSREQ because it reflects the SNA behavior of preventing further host output while the user's process continues executing.

TN3270E introduces separate terminal and printer device pools (generic vs. specific, with optional partner/paired printers) to prevent terminals with host-application significance from being 'accidentally' consumed by generic session requests, while still allowing specific requests to draw from either pool.

3270 Read and Write command codes have different values depending on whether the server connects to the host locally or remotely, and via SNA or non-SNA. Clients must check for all possible values to remain compatible with the widest range of servers.

If either side refuses TN3270E (WON'T or DON'T), traditional tn3270—negotiating Terminal-Type, Binary Transmission, and End of Record separately—remains available as a fallback. A TN3270E-capable implementation is expected to attempt TN3270E first and fall back to traditional tn3270 only on refusal.

TN3270E is entirely unrelated to the Telnet 3270 Regime Option defined in RFC 1041; the two options use separate negotiation and cannot be combined. RFC 1041 saw very little adoption in practice.

Agreement to support TN3270E automatically implies support for bi-directional binary transmission and End of Record (EOR), equivalent to negotiating the Telnet Binary Transmission Option and Telnet End of Record Option separately. These are not explicitly re-negotiated.

Clients negotiating a terminal device-type with '-E' suffix, the DYNAMIC type, or any printer device-type MUST be able to respond to both the Read Partition Query (Type 02) and all forms of the Read Partition Query List (Type 03) 3270 structured field commands.

Implementations wishing to support keep-alives SHOULD accept both Telnet IAC NOP and Telnet DO TIMING-MARK, and SHOULD always respond to TIMING-MARKs. Either or both sides may be configured to actively send NOPs or TIMING-MARKs; the interval and mechanism should be administrator-configurable.

It is strongly recommended that Telnet commands (other than IAC IAC) be sent between TN3270E data messages, without a header and without a trailing IAC EOR. Placing Telnet commands inside a data message (between the header and trailing IAC EOR) is explicitly discouraged because processing order is implementation-dependent.

The FUNCTIONS IS command sent in acceptance must contain a function-list that exactly matches the list received in the preceding FUNCTIONS REQUEST command. To avoid infinite loops, neither party should re-add a function it previously proposed and the other side removed.

The server must accept or reject the client's DEVICE-TYPE REQUEST as a whole—it cannot accept the device-type portion while denying the CONNECT or ASSOCIATE portion of the same request.

TN3270E clients MUST provide a key mapping for the 3270 ATTN key that transmits a Telnet IP command. Servers MUST translate the received IP into an SNA SIGNAL RU to the host application. Non-SNA servers MUST ignore Telnet IP commands.

TN3270E clients that support the SYSREQ function MUST map a key or key combination to the 3270 SYSREQ key and transmit a Telnet AO command upon that keypress. Servers that agreed to SYSREQ MUST enter 'suspended mode' on receipt of AO, responding to host data with SNA sense code 0x082D ('LU Busy') and restricting DATA-TYPE to SSCP-LU-DATA.

When a printer device-type (IBM-3287-1) is negotiated, at least one of SCS-CTL-CODES or DATA-STREAM-CTL (or both) MUST be included in the FUNCTIONS negotiation. This enables the server to know which types of host application sessions to accept on behalf of the client.

When a printer error condition indicated by Intervention Required or Component Disconnected has been cleared, the client MUST send a data message with DATA-TYPE=REQUEST and REQUEST-FLAG=ERR-COND-CLEARED (0x00) with no data portion, so the server can notify the host application to resume sending printer output.

When BIND-IMAGE is in effect, data messages with DATA-TYPE 3270-DATA or SCS-DATA are not permitted before the client receives the first BIND-IMAGE message, nor between an UNBIND and the next BIND-IMAGE. Only SSCP-LU-DATA or NVT-DATA may carry user-oriented data during those intervals.

When BIND-IMAGE is in effect, the server MUST send a BIND-IMAGE data message to the client once the SNA Bind RU and Start Data Traffic RU have been responded to positively. The data portion MUST contain the bind image exactly as received. An UNBIND message must be sent when the SNA session terminates.

When the RESPONSES function is in effect, the sender MUST set the SEQ-NUMBER field for every 3270-DATA or SCS-DATA message regardless of the RESPONSE-FLAG value. The counter starts at zero and increments by one per message, wrapping at 32767.

Five TN3270E functions may be negotiated: SCS-CTL-CODES (SCS/LU-type-1 printer data), DATA-STREAM-CTL (3270 data stream for printers), RESPONSES (positive/negative response handling), BIND-IMAGE (SNA Bind and Unbind notification), and SYSREQ (SYSREQ key emulation for SNA sessions).

RESPONSE messages (DATA-TYPE=0x02) contain a 1-byte data payload. For POSITIVE-RESPONSE, 0x00 means successful completion ('Device End'). For NEGATIVE-RESPONSE, 0x00=Command Reject, 0x01=Intervention Required, 0x02=Operation Check, 0x03=Component Disconnected.

TN3270E is assigned Telnet Option code 40. Its sub-commands are: ASSOCIATE (00), CONNECT (01), DEVICE-TYPE (02), FUNCTIONS (03), IS (04), REASON (05), REJECT (06), REQUEST (07), SEND (08). Reason-codes and function names are also defined in this section.

Security issues are not addressed in this document. Authentication mechanisms are anticipated to be added in the future, with a primary use case being authorization of specific users to access designated terminal or printer device-names.

security

A TN3270E connection operates in either '3270 mode' or 'NVT mode'. The connection starts in 3270 mode after successful negotiation. Sending a DATA-TYPE of NVT-DATA while in 3270 mode (or 3270-DATA while in NVT mode) constitutes a mode switch request. A mode switch causes the client to perform the equivalent of a 3270 Erase/Reset operation using the default partition size.

TN3270E connection setup proceeds in strict sequence: (1) WILL/DO TN3270E option negotiation; (2) DEVICE-TYPE sub-negotiation (server sends SEND DEVICE-TYPE, client responds with REQUEST, server replies with IS or REJECT); (3) FUNCTIONS sub-negotiation (client initiates with REQUEST, resolved with IS); (4) 3270 data stream exchange. No phase may be skipped or reordered.

Every TN3270E data message is prefixed by a 5-byte header: DATA-TYPE (1 byte), REQUEST-FLAG (1 byte), RESPONSE-FLAG (1 byte), SEQ-NUMBER (2 bytes). The message format is <TN3270E Header><data><IAC EOR>, or <TN3270E Header><IAC EOR> when no data is present.

The DATA-TYPE field (1 byte) encodes message content type: 3270-DATA (0x00), SCS-DATA (0x01), RESPONSE (0x02), BIND-IMAGE (0x03), UNBIND (0x04), NVT-DATA (0x05), REQUEST (0x06), SSCP-LU-DATA (0x07).

The RESPONSE-FLAG field (1 byte) has dual meaning: for DATA-TYPE 3270-DATA or SCS-DATA it indicates response expectation (NO-RESPONSE=0x00, ERROR-RESPONSE=0x01, ALWAYS-RESPONSE=0x02); for DATA-TYPE RESPONSE it carries the actual response (POSITIVE-RESPONSE=0x00, NEGATIVE-RESPONSE=0x01). For all other DATA-TYPE values it must be ignored by the receiver and set to 0x00 by the sender.

The SEQ-NUMBER field is 2 bytes of binary data, used only when the RESPONSES function is agreed to. It contains a sequence number in the range 0–32767 that correlates response messages to the data messages they acknowledge; it wraps back to zero after reaching 32767.