RFC 1576

RFC 1576: TN3270 Current Practices 💖

Okay bestie, welcome to RFC 1576! 🧚 Here's the title-block tea so you don't have to scroll: it's an Informational RFC written by J. Penner of DCA, Inc., filed under the Network Working Group and dated January 1994. The header doesn't list any RFCs it obsoletes or updates, so it's not replacing or changing anything else. 🎀

Status of this Memo ✨

This memo is here to give the Internet community information 💅 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈

Abstract 🦋

This doc describes how 3270 display terminal data gets transferred using the telnet capabilities that already exist. The name people usually attach to this setup is TN3270 🍓

It's also here to help you build TN3270 servers and client terminal emulators 🫶 These are the areas it covers:

1. the telnet options negotiated to go from an NVT ASCII state to a TN3270 state, ready to process incoming 3270 data stream commands
2. the method for sending and receiving 3270 data
3. the method of handling some special keys known as SYSREQ and ATTN using current available telnet commands
4. the events that will transition a TN3270 session back to an NVT session

Table of Contents 🌸

1.  Motivation  . . . . . . . . . . . . . . . . . . .   2
2.  Background  . . . . . . . . . . . . . . . . . . .   2
3.  Telnet Options and Commands Used  . . . . . . . .   4
4.  Connection Negotiation  . . . . . . . . . . . . .   4
4.1 3270 Regime Option  . . . . . . . . . . . . . . .   6
4.2 Suppress Go Ahead Option  . . . . . . . . . . . .   6
4.3 Echo Option . . . . . . . . . . . . . . . . . . .   6
4.4 Timing Mark Option  . . . . . . . . . . . . . . .   7
5.  Testing for session presence  . . . . . . . . . .   7
6.  Handling 3270 data  . . . . . . . . . . . . . . .   7
7.  3270 Structured Fields  . . . . . . . . . . . . .   8
8.  The 3270 ATTN (Attention) Key . . . . . . . . . .   8
9.  The 3270 SYSREQ Key . . . . . . . . . . . . . . .   9
10. Items not addressed by TN3270 . . . . . . . . . .  10
11. References  . . . . . . . . . . . . . . . . . . .  10
12. Security Considerations . . . . . . . . . . . . .  11
13. Author's Note . . . . . . . . . . . . . . . . . .  11
14. Author's Address  . . . . . . . . . . . . . . . .  12

1. Motivation 🌟

Okay so, 3270 display terminal data is different from regular display terminal data in two ways: it's block mode, and it uses EBCDIC instead of ASCII for character representation. Those two differences are the main reason this document separates TN3270 from standard Telnet. It's giving "not the same vibe," and that's the whole point 💅

2. Background 🌸

Existing IBM 3270 display terminal networks don't plug in easily to all the multi-platform networking environments out there, especially TCP/IP. Those networks include terminals attached to a 3270 host using SNA (Systems Network Architecture) and non-SNA connections. So to make it easier to hook display terminals up to 3270 hosts over IP networks, several vendors made telnet servers. These give TCP/IP users a connection to existing IBM mainframes by supporting display terminal emulation with a subset of the existing telnet protocol 🦋 Telnet servers can live on the host itself, or they can be connected to the host using SNA or non-SNA methods.

IBM terminals are generically called 3270's, and that covers a broad range of terminals and devices. Not all of them actually start with the numbers 327x, so don't let the name fool you 🙈

3270 terminals in an IBM SNA network have two sessions with the host computer application. One session talks to the host application, and the other talks to the SSCP (System Services Control Point) that links the terminal with the right host computer. For TN3270 purposes this distinction isn't apparent or relevant, because there's actually only a single telnet session with the host computer or server. 💖 On an IBM SNA network, the 3270 terminal has a special key that toggles between the two sessions (SYSREQ). There's a brief discussion of how some telnet servers handle this below.

In an SNA environment, a client session is identified by a Logical Unit (LU) name. In a non-SNA environment there's no LU name tied to a client session. The closest thing to an LU name in the TN3270 environment is the client's IP address. Some telnet servers are connected to the host using SNA, but TN3270 clients using those servers have no defined way to figure out the LU name associated with their session 😭

Telnet servers in non-SNA environments don't have to worry about giving TN3270 clients support for the SNA functions described in this document 🧚

TN3270 doesn't support typical SNA responses, so it's classified as a non-SNA protocol. A TN3270 emulator isn't aware of, or concerned with, how the telnet server is connected to a 3270 host application. Not its business, bestie 💅

NOTE: Except where otherwise stated, this document does not distinguish between telnet servers that represent SNA devices and those that represent non-SNA 3270 devices.

Some typical "SNA" functions, like the SYSREQ and ATTN keys, have been mapped to existing telnet commands and are supported by some telnet server implementations ✨

Right now, 3270 terminal emulation over Telnet works because of the de facto standard of negotiating three separate Telnet Options: Terminal-Type [2], Binary Transmission [3], and End of Record [4]. This negotiation and the resulting data flow get described below 🎀

RFC 1041 [1] tried to standardize how 3270 terminal support gets negotiated by defining the 3270 Regime Telnet Option. Historically though, very few developers and vendors ever implemented RFC 1041 🥲

All references in this document to the 3270 datastream, SNA versus non-SNA operation, 3270 datastream commands, orders, structured fields and the like rely on [6]. References to SNA Request and Response Units rely on [7]. References to SNA and SSCP rely on [12] 📚

3. Telnet Options and Commands Used 💜

TN3270 makes use of existing Telnet options. It does not define any additional options or commands, which is honestly iconic of it 👑

    Telnet option    Value (decimal)
    -------------    ---------------
    BINARY            0
    TERMINAL-TYPE    24
    EOR              25

Additional options may be used during a TN3270 session and are interpreted as per their respective RFCs. These are [1] 3270-REGIME, [8] SUPPRESS-GO-AHEAD, [9] ECHO and [10] TIMING-MARK. Other options should be rejected unless they are specifically handled by the client for NVT mode.

Commands that may be encountered during a TN3270 session, and that are described in RFC 854 [11], include NOP, BREAK and Interrupt Process 🍓

4. Connection Negotiation 🎀

The following example shows a TN3270-capable server and a TN3270 client establishing a connection. Let's go, bestie 🦋

The TCP/IP port used to connect is 23 (Telnet).

At any place before and during the TN3270 connection negotiation process, other telnet commands and data may be transferred, and they'll be interpreted under the existing telnet state. Some existing TN3270 servers start a client connection using an NVT telnet dialog first, to set up the parameters they need to complete the TN3270 connection to the desired host.

The order of negotiating terminal type, EOR and BINARY is not significant. This example shows a typical TN3270 connection 💅

Server:  IAC DO TERMINAL-TYPE

Client:  IAC WILL TERMINAL-TYPE

Server:  IAC SB TERMINAL-TYPE SEND IAC SE

Client:  IAC SB TERMINAL-TYPE IS <terminal type>IAC SE

Where <terminal type> is a string made up of the terminal model, type and support of enhanced attribute bytes. An example is IBM-3278-2. The acceptable values are listed in RFC 1340, Assigned Numbers [5]. Other values are in use that do not exist in [5] 🌈

The -2 after 3278 designates the alternate screen size. 3270 terminals can switch between the standard (24x80) screen size and an alternate screen size. Model -2 is 24x80, which is the same as the standard size. Model -3 is 32x80, model -4 is 43x80, and model -5 is 27x132 ✨

Appending the two character string -E to the end of the terminal type signifies that the terminal can handle the 3270 extended data stream. This is interpreted to mean the terminal is able to handle structured fields, which are described below. Some telnet server implementations also interpret this to mean the terminal is capable of handling extended attributes (highlighting, field validation, character set, outlining, etc.) [6] 💖

The 3279 series of terminals is capable of extended attributes, while the 3278 series is not 🧚

Server:  IAC DO EOR IAC WILL EOR
Client:  IAC WILL EOR IAC DO EOR
Server:  IAC DO BINARY IAC WILL BINARY
Client:  IAC WILL BINARY IAC DO BINARY
Server:  <3270 data stream> IAC EOR
Client:  <3270 data stream> IAC EOR
     .            .
     .            .

To terminate the connection, the socket is closed by one of the session partners. Typically, when the user logs off of the host, the telnet server closes the connection 👋

If the telnet server wants to go back to NVT mode, it may issue the following telnet options:

Server:  IAC WONT BINARY
Client:  IAC DONT BINARY

     or

Server:  IAC WONT EOR
Client:  IAC DONT EOR

Either one of those two cases causes the connection to stop satisfying the requirements for a valid TN3270 session. The telnet client would then process data from the server as though it were NVT ASCII data 😭

The following examples show how a TN3270 client handles the 3270-REGIME, SUPPRESS-GO-AHEAD, ECHO and TM options 🦋

4.1 3270 Regime Option 💜

Very few servers support the 3270 Regime Telnet Option. If the client doesn't support this option and responds negatively, as shown in the following example, the server will move on to the more typical example shown above.

Server:  IAC DO 3270-REGIME
Client:  IAC WONT 3270-REGIME
 Normal negotiation:
Server:  IAC DO TERMINAL-TYPE
   ...  (see above)

4.2 Suppress Go Ahead Option 🌸

The Suppress Go Ahead option [8] is requested by some servers. The Suppress Go Ahead option RFC lists the default as go aheads being transmitted to signal the receiver to begin transmitting. Since TN3270 negotiates binary and end-of-record and is a block mode protocol, the telnet go ahead character is not sent. Most servers don't negotiate this option even though they don't use the telnet go ahead character, which is a whole mood 💅

Server:  IAC DO SUPPRESS-GO-AHEAD
Client:  IAC WILL SUPPESS-GO-AHEAD

4.3 Echo Option 🎀

Okay so the Echo option [9] is what servers negotiate when they use telnet NVT mode and want the user to type stuff in before the TN3270 options get set up. That stuff includes (but isn't limited to!) user identification, the password, and which destination 3270 host you want 💅

Some servers just go with the default, which is that the client does not do a local echo of what the user types on the keyboard. That way the server gets to decide whether characters get echoed back to the client (or not, for passwords) 🙈 Echoing back is painfully slow because every single character usually gets echoed one at a time 🐌 So some servers negotiate for the client to do its own local echoing instead, except for passwords. Here's how that goes:

      Server:  IAC DO ECHO
      Client:  IAC WILL ECHO
        (Client does local display of all characters)
      Server:  IAC WONT ECHO
      Client:  IAC DONT ECHO
        (Client enters password - not locally displayed or remotely
      echoed)
      Server:  IAC DO ECHO
      Client:  IAC WILL ECHO
     (Client resumes local display of all characters)

4.4 Timing Mark Option ⏰

Some servers use the Timing Mark option [10] to check that a TN3270 client is still around. The example below is the one that reassures the server the client is still alive 🫶

      Server:  IAC DO TIMING-MARK
      Client:  IAC WONT TIMING-MARK

---

5. Testing for session presence 🔍

Some servers send the NOP command (hexadecimal F1) [11] to check whether a TN3270 client is still hanging around. If a client has terminated abnormally, TCP/IP send errors will show up 😬 The Timing Mark option from above is also used to test for presence.

      Server:  IAC NOP
      Client:  <ignore / no response>

6. Handling 3270 data 🧚

The 3270 data stream is a command plus its associated data. Commands include (but aren't limited to) erase screen, erase and write to screen, and read current screen. Check [6] for the full rundown on 3270 commands and parameters 📖

We negotiate the EOR telnet option [4] so there's a way to separate these commands, since no length information is specified. 3270 commands get interpreted by the telnet client in their entirety, and each 3270 command and its possible data gets ended with the IAC EOR sequence ✨

The Binary option [3] is also required, because 3270 data may contain the FF (hexadecimal) or IAC character. When that character shows up during a TN3270 connection, it's handled as per the Binary RFC [3] 🌸

7. 3270 Structured Fields 🦋

3270 structured fields come with a much wider range of features than "old-style" 3270 data, like support for graphics, partitions, and IPDS printer datastreams. A structured field is a 3270 data type that lets non-3270 data get embedded inside 3270 data. Basically, a structured field is the structured field command followed by one or more data blocks. Each data block has a length and a structured field identifier, and optionally some extra data after that 🧩

Not every TN3270 client can be expected to support all structured field functions, so there absolutely has to be a way for clients that can support some or all of them to say so. This is typically done by adding -E to the end of the terminal type string. So when the terminal says it can handle extended attributes, it's also able to send and receive structured fields 👑

The design of 3270 structured fields gives you a neat way to share the level of support (including no support at all) for the various structured field functions. That mechanism is the Read Partition Query command, which the host application sends to the client. The client answers with a Query Reply that lists which structured field functions it supports, if any 🎀

A TN3270 client that supports structured fields will respond to a Read Partition Query command with the appropriate reply. What happens when a client gets a Read Partition Query but doesn't support structured fields is left up to the client implementation. Typically, clients can at least identify this structured field and reply with a null set 🤷‍♀️

8. The 3270 ATTN (Attention) Key 🔔

The 3270 ATTN key is interpreted by lots of host applications in an SNA environment as "hey, the user wants to interrupt whatever's running right now." A majority of telnet servers currently accept the telnet IAC BREAK (code 243) [11] sequence to signal this event 💥

Using this key takes two things:

• The TN3270 clients provide, as part of their keyboard mapping, a single key or a combination of keys that map to the 3270 ATTN key. When the user presses this key (or keys), the client transmits a Telnet BREAK command to the server.
• The TN3270 servers translate the BREAK command received from a TN3270 client into the appropriate form and pass it along to the host application as an ATTN key. In other words, the server representing an SLU in an SNA session would send a SIGNAL RU to the host application 🚀

The ATTN key isn't supported in a non-SNA environment, so a TN3270 server representing non-SNA 3270 devices just ignores any Telnet BREAK commands it gets from a client 🙃

9. The 3270 SYSREQ Key 🌈

The 3270 SYSREQ key is useful in an environment where the telnet server is attached to the host using SNA. It's especially handy when the host application gets locked up, or when the user wants to end the session without closing the Telnet connection 🔐

Some telnet servers interpret the Telnet Interrupt Process (IP) command [11] as a SYSREQ key, and others recognize the 3270 Test Request key as one. In an SNA environment, pressing this key toggles the terminal between the host application session and the SSCP session. Usually the user types LOGOFF once the key has been pressed to end the application session, then picks a new host to connect to. Sometimes, if SYSREQ gets pressed again, the host application unlocks and normal activities can carry on 🔄

It's entirely up to the telnet server to interpret this command, send the right commands to the host, and format the resulting host data for display on the telnet client. The data format during the SSCP session is a little different from normal 3270 data. Since the telnet server has no way to pass this data straight to the telnet client, it either has to handle it entirely and ignore SYSREQ events, or convert it to 3270 data to present to the client 🧠

To implement SYSREQ key support, TN3270 clients provide a key (or combination of keys) mapped to the 3270 SYSREQ key. When the user presses it, the client sends either a Telnet IP command or a Test Request key to the server, depending on the server implementation 📨

TN3270 servers representing non-SNA 3270 terminals may ignore any Telnet IP commands or Test Request keys they receive from a client 🌸

10. Items not addressed by TN3270 🚧

There are several things current TN3270 implementations don't support. Among them are the following:

• TN3270 provides no capability for clients to emulate the 328x class of printers. 🖨️
• There is no mechanism by which a Telnet client can request that a connection be associated with a given 3270 device-name. This can matter a lot when a terminal session is being established, since many host applications behave differently depending on the network name of the terminal 👀
• The 3270 ATTN and SYSREQ keys are not universally supported.
• There is no support for the SNA positive/negative response process. All data that is sent is assumed to either be handled or ignored. The lack of SNA response processing is part of what makes TN3270 efficient ⚡ A negative response indicates some sort of error at the client while processing the previously received data. That could be caused by the host application building a 3270 datastream with an invalid command, or by a mechanical error on the client side, among other things. Positive responses indicate that processing of the previously received data has completed.
• There is no mechanism by which the client can access the SNA BIND information. The BIND image in an SNA environment contains a detailed description of the session between the telnet server and the host application 📋
• The connection negotiation does not make it clear whether clients should support 3270 structured fields 🤔

11. References 📚

[1] Rekhter, Y., "Telnet 3270 Regime Option", RFC 1041, IBM Corporation, January 1988.

[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP Software, Inc., February 1989.

[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, USC/Information Sciences Institute, May 1983.

[4] Postel, J., "Telnet End of Record Option", RFC 885, USC/Information Sciences Institute, December 1983.

[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

[6] "3270 Information Display System - Data Stream Programmer's Reference", publication number GA23-0059, IBM Corporation.

[7] "Systems Network Architecture - Formats", publication number GA27-3136, IBM Corporation.

[8] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option", STD 29, RFC 858, USC/Information Sciences Institute, May 1983.

[9] Postel, J., and J. Reynolds, "Telnet Echo Option", STD 28, RFC 857, USC/Information Sciences Institute, May 1983.

[10] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, USC/Information Sciences Institute, May 1983.

[11] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, USC/Information Sciences Institute, May 1983.

[12] "Systems Network Architecture - Concepts and Products", publication number GC30-3072, IBM Corporation.

12. Security Considerations 💀

Security issues are not discussed in this memo.

Real talk: this memo has zero security content. Not one word. Proceed with extreme caution and a lot of vibes, bestie 😭🔥

13. Author's Note 🫶

Portions of this document were drawn from the following sources:

• A White Paper written by Owen Reddecliffe, WRQ Corporation, October 1991.
• Experimental work on the part of Cleve Graves and Michelle Angel, OpenConnect Systems, 1992 - 1993.
• Discussions at the March 1993 IETF meeting and TN3270 BOF at Interop August 1993.
• Discussions on the "TN3270E" list, 1993.

14. Author's Address 💌

   Jon Penner
   DCA, Inc.
   2800 Oakmont Drive
   Austin, TX 78664

   Phone: (512) 388-7090 FAX
   EMail: jjp@bscs.com
          or dca/g=Jon/s=Penner/ou=DCAAUS@mhs.attmail.com