diff options
Diffstat (limited to 'doc/rfc/rfc1576.txt')
| -rw-r--r-- | doc/rfc/rfc1576.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc1576.txt b/doc/rfc/rfc1576.txt new file mode 100644 index 0000000..e9e2c17 --- /dev/null +++ b/doc/rfc/rfc1576.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group J. Penner +Request for Comments: 1576 DCA, Inc. +Category: Informational January 1994 + + + TN3270 Current Practices + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes the existing implementation of transferring + 3270 display terminal data using currently available telnet + capabilities. The name traditionally associated with this + implementation is TN3270. + + Information is provided to aid in the implementation of TN3270 + servers as well as client terminal emulators. + + The following areas pertaining to TN3270 implementations are covered + in this document: + + 1. the telnet options negotiated to transition from a 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 + + + +TN3270 Enhancements Working Group [Page 1] + +RFC 1576 TN3270 Current Practices January 1994 + + + 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 + + 3270 display terminal data differs from traditional display terminal + data in that it is block mode and uses EBCDIC instead of ASCII + character representation. These two differences are the primary + reason for the differentiation of TN3270 from standard Telnet in this + document. + +2. Background + + Existing complex IBM 3270 display terminal networks are not easily + integrated with the increasing number of multi-platform networking + environments, specifically TCP/IP. These complex networks include + terminals attached to a 3270 host using SNA (Systems Network + Architecture) and non-SNA connections. To address the issue of easily + connecting display terminals to 3270 hosts using IP networks, several + vendors have introduced telnet servers that provide TCP/IP users a + connection to existing IBM mainframes by supporting display terminal + emulation using a subset of the existing telnet protocol. Telnet + servers may exist on the host itself, or be connected to the host + using SNA or non-SNA methods. + + IBM terminals are generically referred to as 3270's which includes a + broad range of terminals and devices, not all of which actually begin + with the numbers 327x. + + 3270 terminals in the IBM SNA network environment have two sessions + with the host computer application. One is used for communicating + with the host application, the other is used for communicating with + the SSCP (System Services Control Point) that links the terminal with + the appropriate host computer. For the purposes of TN3270, this + distinction is not apparent or relevant since there is 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). A brief discussion on how some telnet + servers deal with this is included. + + + + +TN3270 Enhancements Working Group [Page 2] + +RFC 1576 TN3270 Current Practices January 1994 + + + In an SNA environment, a client session is identified by a Logical + Unit (LU) name. In a non-SNA environment, there is not a LU name + associated with a client session. The closest thing to a LU name in + the TN3270 environment is the client's IP address. Although some + telnet servers are connected to the host using SNA, TN3270 clients + using these servers have no defined way to determine the LU name + associated with the session. + + Telnet servers that exist in non-SNA environments do not have to be + concerned about providing TN3270 clients with support for the SNA + functions described in this document. + + TN3270 does not support typical SNA responses and is classified as a + non-SNA protocol. A TN3270 emulator is not aware or concerned about + how the telnet server is connected to a 3270 host application. + + 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 such as the SYSREQ and ATTN keys have + been mapped to existing telnet commands and are supported by some + telnet server implementations. + + Currently, support for 3270 terminal emulation over Telnet is + accomplished by 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 will be + described below. + + RFC 1041 [1] attempted to standardize the method of negotiating 3270 + terminal support by defining the 3270 Regime Telnet Option. + Historically, 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]. + + + + + + + + + + +TN3270 Enhancements Working Group [Page 3] + +RFC 1576 TN3270 Current Practices January 1994 + + +3. Telnet Options and Commands Used + + TN3270 makes use of existing Telnet options and does not define any + additional options or commands. + + 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 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: + + The TCP/IP port used to connect with is 23 (Telnet). + + At any place before and during the TN3270 connection negotiation + process, other telnet commands and data may be transferred and will + be interpreted under the existing telnet state. Some existing TN3270 + servers start a client connection using an NVT telnet dialog to + establish parameters needed 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 consisting of terminal model, + type and support of enhanced attribute bytes; an example is IBM- + 3278-2. The acceptable values are listed in RFC 1340, Assigned + + + +TN3270 Enhancements Working Group [Page 4] + +RFC 1576 TN3270 Current Practices January 1994 + + + Numbers [5]. Other values are in use that do not exist in [5]. + + The -2 following 3278 designates the alternate screen size. 3270 + terminals have the ability to 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 is capable of handling 3270 + extended data stream. This is interpreted to mean that the + terminal is able to handle structured fields, which are described + below. Some telnet server implementations also interpret this to + mean that 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 wishes 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 the above two cases causes the connection to not + satisfy the requirements for a valid TN3270 session. The telnet + client would then process data from the server as though it were NVT + ASCII data. + + + +TN3270 Enhancements Working Group [Page 5] + +RFC 1576 TN3270 Current Practices January 1994 + + + 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 does not support this option and responds negatively as shown + in the following example, the server will proceed 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 being go aheads are + 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 do + not negotiate this option even though they do not use the telnet go + ahead character. + + Server: IAC DO SUPPRESS-GO-AHEAD + Client: IAC WILL SUPPESS-GO-AHEAD + +4.3 Echo Option + + The Echo option [9] is negotiated by those servers that make use of + the telnet NVT mode to allow the user to enter information prior to + negotiating the options necessary for TN3270. This information + includes but is not limited to user identification, password and + destination 3270 host. Some servers accept the default for this + option which is for the client to not do a local echo of characters + the user enters at the keyboard. This allows the server to decide if + it should echo characters back to the client (or not in the case of + password). Echoing characters back to the client causes slow response + time since every character is typically echoed individually. Because + of this, some servers negotiate for the client to do it's own local + echoing (except for passwords). The following example illustrates + this case. + + + + + + + +TN3270 Enhancements Working Group [Page 6] + +RFC 1576 TN3270 Current Practices January 1994 + + + 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 + + The Timing Mark option [10] is used by some servers to test for the + continued presence of a TN3270 client. The following example will + assure the server the client is still alive. + + Server: IAC DO TIMING-MARK + Client: IAC WONT TIMING-MARK + +5. Testing for session presence + + The NOP command (hexadecimal F1) [11] is used by some servers to test + for the continued presence of a TN3270 client. If a client has + terminated abnormally, TCP/IP send errors will occur. The Timing Mark + option, described above, is also used to test for presence. + + Server: IAC NOP + Client: <ignore / no response> + +6. Handling 3270 data + + The 3270 data stream consists of a command and its associated data. + Commands include but are not limited to erase screen, erase and write + to screen and read current screen; see [6] for a complete description + of 3270 commands and parameters. + + The reason for negotiating the EOR telnet option [4] is to provide a + method for separating these commands since no length information is + specified. 3270 commands are interpreted by the telnet client in + their entirety. Each 3270 command and possible data is terminated + with the IAC EOR sequence. + + The Binary option [3] is also required since 3270 data may contain + the FF (hexadecimal) or IAC character. When this character is + encountered during a TN3270 connection it is handled as per the + Binary RFC [3]. + + + + +TN3270 Enhancements Working Group [Page 7] + +RFC 1576 TN3270 Current Practices January 1994 + + +7. 3270 Structured Fields + + 3270 structured fields provide a much wider range of features than + "old-style" 3270 data, such as support for graphics, partitions and + IPDS printer datastreams. A structured field is a 3270 data type that + allows non 3270 data to be embedded within 3270 data. Briefly, a + structured field consists of the structured field command followed by + one or more data blocks. Each data block has a length and a + structured field identifier, followed optionally by additional data. + + Not every TN3270 client can be expected to support all structured + field functions. There must be a mechanism by which those clients + that are capable of supporting some or all structured field functions + can indicate their wishes. This is typically done by adding "-E" to + the end of the terminal type string. That is, when the terminal + identifies itself as being able to handle extended attributes, it + also is capable of being able to send and receive structured fields. + + The design of 3270 structured fields provides a convenient means to + convey the level of support (including no support) for the various + structured field functions. This mechanism is the Read Partition + Query command, which is sent from the host application to the client. + The client responds with a Query Reply, listing which, if any, + structured field functions it supports. + + A TN3270 client that supports structured fields will respond to a + Read Partition Query command with the appropriate reply. The + sequence of events when a client receives a Read Partition Query and + does not support structured fields is left up to the client + implementation. Typically clients can identify at least this + structured field and reply with a null set. + +8. The 3270 ATTN (Attention) Key + + The 3270 ATTN key is interpreted by many host applications in an SNA + environment as an indication that the user wishes to interrupt the + execution of the current process. A majority of the telnet servers + currently accept the telnet IAC BREAK (code 243) [11] sequence to + signal this event. + + Use of this key requires 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(s), the + client transmits a Telnet BREAK command to the server. + + + + + +TN3270 Enhancements Working Group [Page 8] + +RFC 1576 TN3270 Current Practices January 1994 + + + - 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 is not supported in a non-SNA environment; therefore, a + TN3270 server representing non-SNA 3270 devices ignores any Telnet + BREAK commands it receives 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. The SYSREQ key is useful in + this environment when the host application becomes locked or the user + wishes to terminate the session without closing the Telnet + connection. + + The Telnet Interrupt Process (IP) command [11] is interpreted by some + telnet servers as a SYSREQ key. Other servers recognize the 3270 Test + Request key as a SYSREQ key. In an SNA environment, pressing this + key toggles the terminal between the host application session and the + SSCP session. Usually the user will enter LOGOFF once this key has + been pressed to terminate the application session and then select a + new host to connect to. Sometimes, if SYSREQ is pressed again, the + host application will become unlocked and normal activities may then + proceed. + + It is entirely up to the telnet server to interpret this command and + send the appropriate commands to the host as well as format the + resulting host data for display on the telnet client. The data format + during the SSCP session is in a slightly different format than normal + 3270 data. Since the telnet server has no way to pass this data + directly to the telnet client, it must either 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) that is identified as mapping to the 3270 SYSREQ + key. When the user presses this key(s), the client would either + transmit a Telnet IP command or 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. + + + + + + +TN3270 Enhancements Working Group [Page 9] + +RFC 1576 TN3270 Current Practices January 1994 + + +10. Items not addressed by TN3270 + + There are several items that are not supported by current TN3270 + implementations; 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 be of importance 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 in TN3270 is + part of what makes TN3270 efficient. + A negative response indicates some sort of error at the client + while processing the previously received data; this could be + caused by the host application building a 3270 datastream that + contains an invalid command, or by a mechanical error at the + client side, among other things. + Positive responses indicate 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 a 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. + + + + + +TN3270 Enhancements Working Group [Page 10] + +RFC 1576 TN3270 Current Practices January 1994 + + + [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. + +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. + + + + + + +TN3270 Enhancements Working Group [Page 11] + +RFC 1576 TN3270 Current Practices January 1994 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +TN3270 Enhancements Working Group [Page 12] +
\ No newline at end of file |