diff options
Diffstat (limited to 'doc/rfc/rfc2877.txt')
| -rw-r--r-- | doc/rfc/rfc2877.txt | 2019 |
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc2877.txt b/doc/rfc/rfc2877.txt new file mode 100644 index 0000000..a36d530 --- /dev/null +++ b/doc/rfc/rfc2877.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group T. Murphy, Jr. +Request for Comments: 2877 P. Rieth +Category: Informational J. Stevens +Updates: 1205 IBM Corporation + July 2000 + + + 5250 Telnet Enhancements + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This memo describes the interface to the IBM 5250 Telnet server that + allows client Telnet to request a Telnet terminal or printer session + using a specific device name. If a requested device name is not + available, a method to retry the request using a new device name is + described. Methods to request specific Telnet session settings and + auto-signon function are also described. + + By allowing a Telnet client to select the device name, the 5250 + Telnet server opens the door for applications to set and/or extract + useful information about the Telnet client. Some possibilities are + 1) selecting a customized device name associated with a particular + user profile name for National Language Support or subsystem routing, + 2) connecting PC and network printers as clients and 3) auto-signon + using clear-text or DES-encrypted password exchange. + + Applications may need to use system API's on the AS/400 in order to + extract Telnet session settings from the device name description. + Refer to the Retrieve Device Description (QDCRDEVD) API described in + the AS/400 System API book [3] on how to extract information using + the DEVD0600 and DEVD1100 templates. + + This memo describes how the IBM 5250 Telnet server supports Work + Station Function (WSF) printers using 5250 Display Station Pass- + Through. A response code is returned by the Telnet server to + indicate success or failure of the WSF printer session. + + + + + +Murphy, et al. Informational [Page 1] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +Table of Contents + + 1. Enhancing Telnet Negotiations...................... 3 + 2. Standard Telnet Option Negotiation................. 3 + 3. Enhanced Telnet Option Negotiation................. 4 + 4. Enhanced Display Emulation Support................. 7 + 5. Enhanced Display Auto-Signon and Password + Encryption......................................... 8 + 5.1 Password Substitutes Processing.............. 12 + 5.2 Handling passwords of length 9 and 10........ 14 + 5.3 Example Password Substitute Calculation...... 15 + 6. Device Name Collision Processing................... 15 + 7. Enhanced Printer Emulation Support................. 16 + 8. Telnet Printer Terminal Types...................... 18 + 9. Telnet Printer Startup Response Record for Printer + Emulators.......................................... 20 + 9.1 Example of a Success Response Record......... 20 + 9.2 Example of an Error Response Record.......... 21 + 9.3 Response Codes............................... 22 + 10. Printer Steady-State Pass-Through Interface........ 23 + 10.1 Example of a Print Record.................... 25 + 10.2 Example of a Print Complete Record........... 27 + 10.3 Example of a Null Print Record............... 27 + 11. End-to-End Print Example........................... 28 + 12. Authors' Note...................................... 33 + 13. References......................................... 33 + 14. Security Considerations............................ 35 + 15. Authors' Addresses................................. 35 + 16. Relation to Other RFC's............................ 35 + 17. Full Copyright Statement........................... 36 + +LIST OF FIGURES + + Figure 1. Example of a success status response + record....................................... 20 + Figure 2. Example of an error response record.......... 21 + Figure 3. Layout of the printer pass-through + header....................................... 23 + Figure 4. Server sending client data with a print + record....................................... 26 + Figure 5. Client sending server a print complete + record....................................... 27 + Figure 6. Server sending client a null print + record....................................... 28 + + + + + + + +Murphy, et al. Informational [Page 2] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +1. Enhancing Telnet Negotiations + + The 5250 Telnet server enables clients to negotiate both terminal and + printer device names through Telnet Environment Options Negotiations, + defined in the Standards Track RFC 1572 [13]. + + The purpose of RFC 1572 is to exchange environment information using + a set of standard or custom variables. By using a combination of + both standard VAR's and custom USERVAR's, the 5250 Telnet server + allows client Telnet to request a pre-defined specific device by + name. + + If no pre-defined device exists then the device will be created, with + client Telnet having the option to negotiate device attributes, such + as the code page, character set, keyboard type, etc. + + Since printers can now be negotiated as a device name, new terminal + types have been defined to request printers. For example, you can + now negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE + options [11]. + + Finally, the 5250 Telnet server will allow exchange of user profile + and password information, where the password may be in either clear- + text or encrypted form. If a valid combination of profile and + password is received, then the client is allowed to bypass the sign- + on panel. The setting of the QRMTSIGN system value must be either + *VERIFY or *SAMEPRF for the bypass of the sign-on panel to succeed. + +2. Standard Telnet Option Negotiation + + Telnet server option negotiation typically begins with the issuance, + by the server, of an invitation to engage in terminal type + negotiation with the Telnet client (DO TERMINAL-TYPE) [11]. The + client and server then enter into a series of sub-negotiations to + determine the level of terminal support that will be used. After the + terminal type is agreed upon, the client and server will normally + negotiate a required set of additional options (EOR [12], BINARY + [10], SGA [15]) that are required to support "transparent mode" or + full screen 5250/3270 block mode support. As soon as the required + options have been negotiated, the server will suspend further + negotiations, and begin with initializing the actual virtual device + on the AS/400. A typical exchange might start like the following: + + + + + + + + + +Murphy, et al. Informational [Page 3] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + IAC DO TERMINAL-TYPE --> + <-- IAC WILL TERMINAL-TYPE + IAC SB TERMINAL-TYPE SEND + IAC SE --> + IAC SB TERMINAL-TYPE IS + <-- IBM-5555-C01 IAC SE + IAC DO EOR --> + <-- IAC WILL EOR + <-- IAC DO EOR + IAC WILL EOR --> + . + . + (other negotiations) . + + Actual bytes transmitted in the above example are shown in hex below. + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + FF FD 18 --> + <-- FF FB 18 + FF FA 18 01 FF F0 --> + FF FA 18 00 49 42 4D 2D + 35 35 35 35 2D 43 30 31 + <-- FF F0 + FF FD 19 --> + <-- FF FB 19 + <-- FF FD 19 + FF FB 19 --> + . + . + (other negotiations) . + + Some negotiations are symmetrical between client and server and some + are negotiated in one direction only. Also, it is permissible and + common practice to bundle more than one response or request, or + combine a request with a response, so the actual exchange may look + different in practice to what is shown above. + +3. Enhanced Telnet Option Negotiation + + In order to accommodate the new environment option negotiations, the + server will bundle an environment option invitation along with the + standard terminal type invitation request to the client. + + + + + + +Murphy, et al. Informational [Page 4] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + A client should either send a negative acknowledgment (WONT NEW- + ENVIRON), or at some point after completing terminal-type + negotiations, but before completing the full set of negotiations + required for 5250 transparent mode, engage in environment option + sub-negotiation with the server. A maximum of 1024 bytes of + environment strings may be sent to the server. A recommended + sequence might look like the following: + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + IAC DO NEW-ENVIRON + IAC DO TERMINAL-TYPE --> + (2 requests bundled) + <-- IAC WILL NEW-ENVIRON + IAC SB NEW-ENVIRON SEND + VAR IAC SE --> + IAC SB NEW-ENVIRON IS + VAR "USER" VALUE "JONES" + USERVAR "DEVNAME" + VALUE "MYDEVICE07" + <-- IAC SE + <-- IAC WILL TERMINAL-TYPE + (do the terminal type + sequence first) + IAC SB TERMINAL-TYPE SEND + IAC SE --> + IAC SB TERMINAL-TYPE IS + <-- IBM-5555-C01 IAC SE + (terminal type negotiations + completed) + IAC DO EOR --> + (server will continue + with normal transparent + mode negotiations) + <-- IAC WILL EOR + . + . + (other negotiations) . + + Actual bytes transmitted in the above example are shown in hex below. + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + FF FD 27 + FF FD 18 --> + (2 requests bundled) + <-- FF FB 27 + FF FA 27 01 00 FF F0 --> + + + +Murphy, et al. Informational [Page 5] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + FF FA 27 00 00 55 53 45 + 52 01 4A 4F 4E 45 53 03 + 44 45 56 4E 41 4D 45 01 + 4D 59 44 45 56 49 43 45 + <-- 30 37 FF F0 + <-- FF FB 18 + (do the terminal type + sequence first) + FF FA 18 01 FF F0 --> + FF FA 18 00 49 42 4D 2D + 35 35 35 35 2D 43 30 31 + <-- FF F0 + FF FD 19 --> + (server will continue + with normal transparent + mode negotiations) + <-- FF FB 19 + . + . + (other negotiations) . + + RFC 1572 defines 6 standard VAR's: USER, JOB, ACCT, PRINTER, + SYSTEMTYPE, and DISPLAY. The USER standard VAR will hold the value + of the AS/400 user profile name to be used in auto-signon requests. + The Telnet server will make no direct use of the additional 5 VAR's, + nor are any of them required to be sent. All standard VAR's and + their values that are received by the Telnet server will be placed in + a buffer, along with any USERVAR's received (described below), and + made available to a registered initialization exit program to be used + for any purpose desired. + + There are some reasons you may want to send NEW-ENVIRON negotiations + prior to TERMINAL-TYPE negotiations. With AS/400 TELNET server, + several virtual device modes can be negotiated: 1) VTxxx device 2) + 3270 device 3) 5250 device (includes Network Station). The virtual + device mode selected depends on the TERMINAL-TYPE negotiated plus any + other TELNET option negotiations necessary to support those modes. + The AS/400 TELNET server will create the desired virtual device at + the first opportunity it thinks it has all the requested attributes + needed to create the device. This can be as early as completion of + the TERMINAL-TYPE negotiations. + + For the case of Transparent mode (5250 device), then the moment + TERMINAL-TYPE, BINARY, and EOR options are negotiated the TELNET + server will go create the virtual device. Receiving any NEW-ENVIRON + negotiations after these option negotiations are complete will result + in the NEW-ENVIRON negotiations having no effect on device + attributes, as the virtual device will have already been created. + + + +Murphy, et al. Informational [Page 6] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + So, for Transparent mode, NEW-ENVIRON negotiations are effectively + closed once EOR is negotiated, since EOR is generally the last option + done. + + For other devices modes (such as VTxxx or 3270), you cannot be sure + when the AS/400 TELNET server thinks it has all the attributes to + create the device. Recall that NEW-ENVIRON negotiations are + optional, and therefore the AS/400 TELNET server need not wait for + any NEW-ENVIRON options prior to creating the virtual device. It is + in the clients best interest to send NEW-ENVIRON negotiations as soon + as possible, preferably before TERMINAL-TYPE is negotiated. That + way, the client can be sure the requested attributes were received + before the virtual device is created. + +4. Enhanced Display Emulation Support + + RFC 1572 style USERVAR variables have been defined to allow a + compliant Telnet client more control over the Telnet server virtual + device on the AS/400. These USERVAR's allow the client Telnet to + create or select a previously created virtual device. If the virtual + device does not exist and must be created, then the USERVAR variables + are used to create and initialize the device attributes. If the + virtual device already exists, the device attributes are modified. + + The USERVAR's defined to accomplish this are: + + USERVAR VALUE EXAMPLE DESCRIPTION + -------- ---------------- ---------------- ------------------- + DEVNAME us-ascii char(x) MYDEVICE07 Display device name + KBDTYPE us-ascii char(3) USB Keyboard type + CODEPAGE us-ascii char(y) 437 Code page + CHARSET us-ascii char(y) 1212 Character set + + x - up to a maximum of 10 characters + y - up to a maximum of 5 characters + + For a description of the KBDTYPE, CODEPAGE and CHARSET parameters and + their permissible values, refer to Chapter 8 in the Communications + Configuration Reference [5] and also to Appendix C in National + Language Support [16]. + + The CODEPAGE and CHARSET USERVAR's must be associated with a KBDTYPE + USERVAR. If either CODEPAGE or CHARSET are sent without KBDTYPE, + they will default to system values. A default value for KBDTYPE can + be sent to force CODEPAGE and CHARSET values to be used. + + + + + + +Murphy, et al. Informational [Page 7] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + AS/400 system objects such as device names, user profiles, clear-text + passwords, programs, libraries, etc. are required to be specified in + English Upper Case (EUC). This includes: + + Any letter (A-Z), any number (0-9), special characters (# $ _ @) + + Therefore, where us-ascii is specified for VAR or USERVAR values, it + is recommended that upper-cased ASCII values be sent, which will be + converted to EBCDIC by the Telnet server. + + A special case occurs for encrypted passwords (described in the next + section), where both the initial password and user profile used to + build the encrypted password must be EBCDIC English Upper Case, in + order to be properly authenticated by the Telnet server. + +5. Enhanced Display Auto-Signon and Password Encryption + + Several 5250 Telnet server specific USERVAR's will be defined. One + will carry a random seed to be used in Data Encryption Standard (DES) + password encryption, and another will carry the encrypted copy of the + password. This would use the same 7-step DES-based password + substitution scheme as APPC and Client Access. For a description of + DES encryption, refer to Federal Information Processing Standards + Publications (FIPS) 46-2 [17] and 81 [18], which can be found at the + Federal Information Processing Standards Publications link: + + http://www.itl.nist.gov/div897/pubs/by-num.htm + + For a description of the 7-step password substitution scheme, refer + to these IBM Customer Support FTP Server links: + + ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps + ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps.Z + ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.zip + + If encrypted password exchange is not required, clear-text password + exchange is permitted using the same USERVAR's defined for + encryption. For this case, the random client seed should be set to + either an empty value (RFC 1572 preferred method) or to hexadecimal + zeros to indicate the password is not encrypted, but is clear-text. + + It should be noted that security of clear-text password exchange + cannot be guaranteed unless the network is physically protected or a + trusted network (such as an intranet). If your network is vulnerable + to IP address spoofing or directly connected to the Internet, you + should engage in encrypted password exchange to validate a clients + identity. + + + + +Murphy, et al. Informational [Page 8] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + Additional VAR's and USERVAR's have also been defined to allow an + auto-signon user greater control over their startup environment, + similar to what is supported using the Open Virtual Terminal + (QTVOPNVT) API [3]. + + The standard VAR's supported to accomplish this are: + + VAR VALUE EXAMPLE DESCRIPTION + -------- ---------------- ---------------- ------------------- + USER us-ascii char(x) USERXYZ User profile name + + x - up to a maximum of 10 characters + + The custom USERVAR's defined to accomplish this are: + + USERVAR VALUE EXAMPLE DESCRIPTION + -------- ---------------- ---------------- ------------------- + IBMRSEED binary(8) 8-byte hex field Random client seed + IBMSUBSPW binary(10) 10-byte hex field Substitute password + IBMCURLIB us-ascii char(x) QGPL Current library + IBMIMENU us-ascii char(x) MAIN Initial menu + IBMPROGRAM us-ascii char(x) QCMD Program to call + + x - up to a maximum of 10 characters + + In order to communicate the server random seed value to the client, + the server will request a USERVAR name made up of a fixed part (the 8 + characters "IBMRSEED" immediately followed by an 8-byte hexadecimal + variable part, which is the server random seed. The client generates + its own 8-byte random seed value, and uses both seeds to encrypt the + password. Both the encrypted password and the client random seed + value are then sent to the server for authentication. RFC 1572 rules + will need to be adhered to when transmitting the client random seed + and substituted password values to the server. Specifically, since a + typical environment string is a variable length hexadecimal field, + the hexadecimal fields are required to be escaped and/or byte stuffed + according to the RFC 854 [8], where any single byte could be mis- + construed as a Telnet IAC or other Telnet option negotiation control + character. The client must escape and/or byte stuff any bytes which + could be seen as a RFC 1572 [13] option, specifically VAR, VALUE, ESC + and USERVAR. + + + + + + + + + + +Murphy, et al. Informational [Page 9] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + The following illustrates the encrypted case: + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------------- + IAC DO NEW-ENVIRON --> + <-- IAC WILL NEW-ENVIRON + IAC SB NEW-ENVIRON SEND + USERVAR "IBMRSEEDxxxxxxxx" + USERVAR "IBMSUBSPW" + VAR USERVAR IAC SE --> + IAC SB NEW-ENVIRON IS + VAR "USER" VALUE "DUMMYUSR" + USERVAR "IBMRSEED" VALUE "yyyyyyyy" + USERVAR "IBMSUBSPW" VALUE "zzzzzzzz" + <-- IAC SE + . + . + (other negotiations) . + + In this example, "xxxxxxxx" is an 8-byte hexadecimal random server + seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed and + "zzzzzzzz" is an 8-byte hexadecimal encrypted password. If the + password is not valid, then the sign-on panel is displayed. If the + password is expired, then the Change Password panel is displayed. + + Actual bytes transmitted in the above example are shown in hex below, + where the server seed is "7D3E488F18080404", the client seed is + "4E4142334E414233" and the encrypted password is "DFB0402F22ABA3BA". + The user profile used to generate the encrypted password is + "44554D4D59555352" (DUMMYUSR), with a clear-text password of + "44554D4D595057" (DUMMYPW). + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + FF FD 27 --> + <-- FF FB 27 + FF FA 27 01 03 49 42 4D + 52 53 45 45 44 7D 3E 48 + 8F 18 08 04 04 03 49 42 + 4D 53 55 42 53 50 57 03 + 00 FF F0 --> + FF FA 27 00 00 55 53 45 + 52 01 44 55 4D 4D 59 55 + 53 52 03 49 42 4D 52 53 + 45 45 44 01 4E 41 42 33 + 4E 41 42 33 03 49 42 4D + + + + + +Murphy, et al. Informational [Page 10] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + 53 55 42 53 50 57 01 DF + B0 40 2F 22 AB A3 BA FF + <-- F0 + + The following illustrates the clear-text case: + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + IAC DO NEW-ENVIRON --> + <-- IAC WILL NEW-ENVIRON + IAC SB NEW-ENVIRON SEND + USERVAR "IBMRSEEDxxxxxxxx" + USERVAR "IBMSUBSPW" + VAR USERVAR IAC SE --> + IAC SB NEW-ENVIRON IS + VAR "USER" VALUE "DUMMYUSR" + USERVAR "IBMRSEED" VALUE + USERVAR "IBMSUBSPW" VALUE "yyyyyyyy" + <-- IAC SE + . + . + (other negotiations) . + + In this example, "xxxxxxxx" is an 8-byte hexadecimal random server + seed, "yyyyyyyyyy" is a 10-byte us-ascii client clear-text password. + If the password has expired, then the sign-on panel is displayed. + + Actual bytes transmitted in the above example are shown in hex below, + where the server seed is "7D3E488F18080404", the client seed is empty + and the clear-text password is "44554D4D595057" (DUMMYPW). The user + profile used is "44554D4D59555352" (DUMMYUSR). + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + FF FD 27 --> + <-- FF FB 27 + FF FA 27 01 03 49 42 4D + 52 53 45 45 44 7D 3E 48 + 8F 18 08 04 04 03 49 42 + 4D 53 55 42 53 50 57 03 + 00 FF F0 --> + FF FA 27 00 00 55 53 45 + 52 01 44 55 4D 4D 59 55 + 53 52 03 49 42 4D 52 53 + 45 45 44 01 03 49 42 4D + 53 55 42 53 50 57 01 44 + <-- 55 4D 4D 59 50 57 FF F0 + + + + +Murphy, et al. Informational [Page 11] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +5.1 Password Substitutes Processing + + Both APPC and Client Access use well-known DES encryption algorithms + to create encrypted passwords. A Network Station or Enhanced Client + can generate compatible encrypted passwords if they follow these + steps, details of which can be found in the Federal Information + Processing Standards 46-2 [17]. + + 1. Padded_PW = Left justified user password padded to the right with + '40'X to 8 bytes. + + The users password must be left justified in an 8 byte variable + and padded to the right with '40'X up to an 8 byte length. If the + users password is 8 bytes in length, no padding would occur. For + computing password substitutes for passwords of length 9 and 10 + see section "Handling passwords of length 9 and 10" below. + Passwords less than 1 byte or greater than 10 bytes in length are + not valid. Please note, if password is not in EBCDIC, it must be + converted to EBCDIC uppercase. + + 2. XOR_PW = Padded_PW xor '5555555555555555'X + + The padded password is Exclusive OR'ed with 8 bytes of '55'X. + + 3. SHIFT_RESULT = XOR_PW << 1 + + The entire 8 byte result is shifted 1 bit to the left; the + leftmost bit value is discarded, and the rightmost bit value is + cleared to 0. + + 4. PW_TOKEN = DES_ECB_mode(SHIFT_RESULT, /* key */ + userID_in_EBCDIC_uppercase /* data */ ) + + This shifted result is used as key to the Data Encryption Standard + (Federal Information Processing Standards 46-2 [17]) to encipher + the user identifier. When the user identifier is less than 8 + bytes, it is left justified in an 8 byte variable and padded to + the right with '40'X. When the user identifier is 9 or 10 bytes, + it is first padded to the right with '40'X to a length of 10 + bytes. Then bytes 9 and 10 are "folded" into bytes 1-8 using the + following algorithm: + + Bit 0 is the high-order bit (i.e. has value of '80'X). + + Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1 + Exclusive OR'ed with byte 9, bits 0 and 1. + Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1 + Exclusive OR'ed with byte 9, bits 2 and 3. + + + +Murphy, et al. Informational [Page 12] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1 + Exclusive OR'ed with byte 9, bits 4 and 5. + Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1 + Exclusive OR'ed with byte 9, bits 6 and 7. + Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1 + Exclusive OR'ed with byte 10, bits 0 and 1. + Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1 + Exclusive OR'ed with byte 10, bits 2 and 3. + Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1 + Exclusive OR'ed with byte 10, bits 4 and 5. + Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1 + Exclusive OR'ed with byte 10, bits 6 and 7. + + User identifier greater than 10 bytes or less than 1 byte are not + the result of this encryption id known as PW_TOKEN in the paper. + + 5. Increment PWSEQs and store it. + + Each LU must maintain a pair of sequence numbers for ATTACHs sent + and received on each session. Each time an ATTACH is generated, + (and password substitutes are in use on the session) the sending + sequence number, PWSEQs, is incremented and saved for the next + time. Both values are set to zero at BIND time. So the first use + of PWSEQs has the value of 1, and increases by one with each use. + A new field is added to the ATTACH to carry this sequence number. + However, in certain error conditions, it is possible for the + sending side to increment the sequence number and the receiver may + not increment it. When the sender sends a subsequent ATTACH, the + receiver will detect a missing sequence. This is allowed. + However the sequence number received must always be larger than + the previous one, even if some are missing. + + The maximum number of consecutive missing sequence numbers allowed + is 16. If this is exceeded, the session is unbound with a + protocol violation. + + Note: The sequence number must be incremented for every ATTACH + sent. However, the sequence number field is only required to be + included in the FMH5 if a password substitute is sent (byte 4, bit + 3 on). + + 6. RDrSEQ = RDr + PWSEQs /* RDr is server seed. */ + + The current value of PWSEQs is added to RDr, the random value + received from the partner LU on this session, yielding RDrSEQ, + essentially a predictably modified value of the random value + received from the partner LU at BIND time. + + + + +Murphy, et al. Informational [Page 13] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + 7. PW_SUB = DES_CBC_mode(PW_TOKEN, /* key */ + (RDrSEQ, /* 8 bytes */ + RDs, /* 8 bytes */ + ID xor RDrSEQ, /* 16 bytes */ + PWSEQs, /* 8 bytes */ + ) /* data */ + ) + + The PW_TOKEN is used as a key to the DES function to generate + a 8 bytes value for the following string of inputs. The DES + CBC mode Initialization Vector (IV) used is 8 bytes of '00'X. + + RDrSEQ: the random data value received from the partner LU + plus the sequence number. + + RDs: the random data value sent to the partner LU on BIND + for this session. + + A 16 byte value created by: + + - padding the user identifier with '40'X to a + length of 16 bytes. + + - Exclusive OR the two 8 byte halves of the padded + user identifier with the RDrSEQ value. + + Note: User ID must first be converted to EBCDIC + upper case. + + PWSEQs: the sequence number. + + This is similar to the process used on LU-LU verification as + described in the Enhanced LU-LU Bind Security. The resulting + enciphered random data is the 'password substitute'. + +5.2 Handling passwords of length 9 and 10 + + 1. Generate PW_TOKENa by using characters 1 to 8 of the password and + steps 1-4 from the previous section. + + 2. Generate PW_TOKENb by using characters 9 and 10 and steps 1-4 from + the previous section. In this case Padded_PW from step 1 will be + characters 9 and 10 padded to the right with '40'X, for a total + length of 8. + + 3. PW_TOKEN = PW_TOKENa xor PW_TOKENb + + + + + +Murphy, et al. Informational [Page 14] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + 4. Now compute PW_SUB by performing steps 5-7 from the previous + section. + +5.3 Example Password Substitute Calculation + + ID: USER123 + Password: ABCDEFG + Server seed: '7D4C2319F28004B2'X + Client seed: '08BEF662D851F4B1'X + PWSEQs: 1 (PWSEQs is a sequence number needed in the + 7-step encryption, and it is always one) + + Encrypted Password should be : '5A58BD50E4DD9B5F'X + +6. Device Name Collision Processing + + Device name collision occurs when a Telnet client sends the Telnet + server a virtual device name that it wants to use, but that device is + already in use on the server. When this occurs, the Telnet server + sends a request to the client asking it to try another device name. + The environment option negotiation uses the USERVAR name of DEVNAME + to communicate the virtual device name. The following shows how the + Telnet server will request the Telnet client to send a different + DEVNAME when device name collision occurs. + + AS/400 Telnet server Enhanced Telnet client + -------------------------- ------------------------- + IAC SB NEW-ENVIRON SEND + VAR USERVAR IAC SE --> + + Server requests all environment variables be sent. + + IAC SB NEW-ENVIRON IS USERVAR + "DEVNAME" VALUE "MYDEVICE1" + USERVAR "xxxxx" VALUE "xxx" + ... + <-- IAC SE + + Client sends all environment variables, including DEVNAME. Server + tries to select device MYDEVICE1. If the device is already in use, + server requests DEVNAME be sent again. + + IAC SB NEW-ENVIRON SEND + USERVAR "DEVNAME" IAC SE --> + + + + + + + +Murphy, et al. Informational [Page 15] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + Server sends a request for a single environment variable: DEVNAME + + IAC SB NEW-ENVIRON IS USERVAR + <-- "DEVNAME" VALUE "MYDEVICE2" IAC SE + + Client sends one environment variable, calculating a new value of + MYDEVICE2. If MYDEVICE2 is different from the last request, then + server tries to select device MYDEVICE2, else server disconnects + client. If MYDEVICE2 is also in use, server will send DEVNAME + request again, and keep doing so until it receives a device that is + not in use, or the same device name twice in row. + +7. Enhanced Printer Emulation Support + + RFC 1572 style USERVAR variables have been defined to allow a + compliant Telnet client more control over the Telnet server virtual + device on the AS/400. These USERVAR's allow the client Telnet to + select a previously created virtual device or auto-create a new + virtual device with requested attributes. + + This makes the enhancements available to any Telnet client that + chonoses to support the new negotiations. + + The USERVAR's defined to accomplish this are: + + USERVAR VALUE EXAMPLE DESCRIPTION + ------------- ---------------- ---------------- ------------------- + DEVNAME us-ascii char(x) PRINTER1 Printer device name + IBMIGCFEAT us-ascii char(6) 2424J0 IGC feature (DBCS) + IBMMSGQNAME us-ascii char(x) QSYSOPR *MSGQ name + IBMMSGQLIB us-ascii char(x) QSYS *MSGQ library + IBMFONT us-ascii char(x) 12 Font + IBMFORMFEED us-ascii char(1) C | U | A Formfeed + IBMTRANSFORM us-ascii char(1) 1 | 0 Transform + IBMMFRTYPMDL us-ascii char(x) *IBM42023 Mfg. type and model + IBMPPRSRC1 binary(1) 1-byte hex field Paper source 1 + IBMPPRSRC2 binary(1) 1-byte hex field Paper source 2 + IBMENVELOPE binary(1) 1-byte hex field Envelope hopper + IBMASCII899 us-ascii char(1) 1 | 0 ASCII 899 support + IBMWSCSTNAME us-ascii char(x) *NONE WSCST name + IBMWSCSTLIB us-ascii char(x) *LIBL WSCST library + + x - up to a maximum of 10 characters + + The "IBM" prefix on the USERVAR's denotes AS/400 specific attributes. + + The DEVNAME USERVAR is used both for displays and printers. The + IBMFONT and IBMASCII899 are used only for SBCS environments. + + + +Murphy, et al. Informational [Page 16] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + For a description of most of these parameters (drop the "IBM" from + the USERVAR) and their permissible values, refer to Chapter 8 in the + Communications Configuration Reference [5]. + + The IBMIGCFEAT supports the following variable DBCS language + identifiers in position 5 (positions 1-4 must be '2424', position 6 + must be '0'): + + 'J' = Japanese 'K' = Korean + 'C' = Traditional Chinese 'S' = Simplified Chinese + + The IBMTRANSFORM and IBMASCII899 values correspond to: + + '1' = Yes '2' = No + + The IBMFORMFEED values correspond to: + + 'C' = Continuous 'U' = Cut 'A' = Autocut + + The IBMPPRSRC1, IBMPPRSRC2 and IBMENVELOPE custom USERVAR's do not + map directly to their descriptions in Chapter 8 in the Communications + Configuration Reference [5]. To map these, use the index listed + here: + + IBMPPRSRC1 HEX IBMPPRSRC2 HEX IBMENVELOPE HEX + ---------- ----- ---------- ----- ----------- ----- + *NONE 'FF'X *NONE 'FF'X *NONE 'FF'X + *MFRTYPMDL '00'X *MFRTYPMDL '00'X *MFRTYPMDL '00'X + *LETTER '01'X *LETTER '01'X *B5 '06'X + *LEGAL '02'X *LEGAL '02'X *MONARCH '09'X + *EXECUTIVE '03'X *EXECUTIVE '03'X *NUMBER9 '0A'X + *A4 '04'X *A4 '04'X *NUMBER10 '0B'X + *A5 '05'X *A5 '05'X *C5 '0C'X + *B5 '06'X *B5 '06'X *DL '0D'X + *CONT80 '07'X *CONT80 '07'X + *CONT132 '08'X *CONT132 '08'X + *A3 '0E'X *A3 '0E'X + *B4 '0F'X *B4 '0F'X + *LEDGER '10'X *LEDGER '10'X + + Note 1: For IBMPPRSRC2, *CONT80 and *CONT132 support starts at V3R7. + + Note 2: For IBMPPRSRC1 and IBMPPRSRC2, *A3, *B4 and *LEDGER support + starts at V3R7. + + + + + + + +Murphy, et al. Informational [Page 17] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +8. Telnet Printer Terminal Types + + New Telnet options are defined for the printer pass-through mode of + operation. To enable printer pass-through mode, both the client and + server must agree to at least support the Transmit-Binary, End-Of- + Record, and Terminal-Type Telnet options. The following are new + terminal types for printers: + + TERMINAL-TYPE DESCRIPTION + ------------- ------------------- + IBM-5553-B01 Double-Byte printer + IBM-3812-1 Single-Byte printer + + Specific characteristics of the IBM-5553-B01 or IBM-3812-1 printers + are specified through the USERVAR IBMMFRTYPMDL, which specifies the + manufacturer type and model. + + An example of a typical negotiation process to establish printer + pass-through mode of operation is shown below. In this example, the + server initiates the negotiation by sending the DO TERMINAL-TYPE + request. + + For DBCS environments, if IBMTRANSFORM is set to 1 (use Host Print + Transform), then the virtual device created is 3812, not 5553. + Therefore, IBM-3812-1 should be negotiated for TERMINAL-TYPE, and not + IBM-5553-B01. + + AS/400 Telnet server Enhanced Telnet client + -------------------------- -------------------------- + IAC DO NEW-ENVIRON --> + <-- IAC WILL NEW-ENVIRON + IAC SB NEW-ENVIRON SEND + VAR USERVAR IAC SE --> + IAC SB NEW-ENVIRON IS + USERVAR "DEVNAME" VALUE "PCPRINTER" + USERVAR "IBMMSGQNAME" VALUE "QSYSOPR" + USERVAR "IBMMSGQLIB" VALUE "*LIBL" + USERVAR "IBMTRANSFORM" VALUE "0" + USERVAR "IBMFONT" VALUE "12" + USERVAR "IBMFORMFEED" VALUE "C" + USERVAR "IBMPPRSRC1" VALUE ESC '01'X + USERVAR "IBMPPRSRC2" VALUE '04'X + USERVAR "IBMENVELOPE" VALUE IAC 'FF'X + <-- IAC SE + IAC DO TERMINAL-TYPE --> + <-- IAC WILL TERMINAL-TYPE + IAC SB TERMINAL-TYPE SEND + IAC SE --> + + + +Murphy, et al. Informational [Page 18] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + IAC SB TERMINAL-TYPE IS IBM-3812-1 + <-- IAC SE + IAC DO BINARY --> + <-- IAC WILL BINARY + IAC DO EOR --> + <-- IAC WILL EOR + + Some points about the above example. The IBMPPRSRC1 value requires + escaping the value using ESC according to RFC 1572 [13]. The + IBMPPRSRC2 does not require an ESC character since '04'X has no + conflict with RFC 1572 options. Finally, to send 'FF'X for the + IBMENVELOPE value, escape the 'FF'X value by using another 'FF'X + (called "doubling"), so as not to have the value interpreted as a + Telnet character per RFC 854 [8]. + + Actual bytes transmitted in the above example are shown in hex below. + + AS/400 Telnet server Enhanced Telnet client + -------------------------- -------------------------- + FF FD 27 --> + <-- FF FB 27 + FF FA 27 01 00 03 FF F0 --> + FF FA 27 00 03 44 45 56 + 4E 41 4D 45 01 50 43 50 + 52 49 4E 54 45 52 03 49 + 42 4D 4D 53 47 51 4E 41 + 4D 45 01 51 53 59 53 4F + 50 52 03 49 42 4D 4D 53 + 47 51 4C 49 42 01 2A 4C + 49 42 4C 03 49 42 4D 54 + 52 41 4E 53 46 4F 52 4D + 01 30 03 49 42 4D 46 4F + 4E 54 01 31 32 03 49 42 + 4D 46 4F 52 4D 46 45 45 + 44 01 43 03 49 42 4D 50 + 50 52 53 52 43 31 01 02 + 01 03 49 42 4D 50 50 52 + 53 52 43 32 01 04 03 49 + 42 4D 45 4E 56 45 4C 4F + <-- 50 45 01 FF FF FF F0 + FF FD 18 --> + <-- FF FB 18 + FF FA 18 01 FF F0 --> + FF FA 18 00 49 42 4D 2D + <-- 33 38 31 32 2D 31 FF F0 + FF FD 00 --> + <-- FF FB 00 + FF FD 19 --> + + + +Murphy, et al. Informational [Page 19] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + FF FB 19 + +9. Telnet Printer Startup Response Record for Printer Emulators + + Once Telnet negotiation for a 5250 pass-through mode is completed, + the 5250 Telnet server will initiate a virtual printer power-on + sequence on behalf of the Telnet client. The Telnet server will + supply a Startup Response Record to the Telnet client with the status + of the printer power-on sequence, indicating success or failure of + the virtual printer power-on sequence. + + This section shows an example of two Startup Response Records. The + source device is a type 3812 model 01 printer with name "PCPRINTER" + on the target system "TARGET". + + Figure 1 shows an example of a successful response; Figure 2 shows an + example of an error response. + +9.1 Example of a Success Response Record + + The response record in Figure 1 was sent by an AS/400 at Release + V4R2. It is an example of the target sending back a successful + Startup Response Record. + + +------------------------------------------------------------------+ + | +----- Pass-Through header | + | | +--- Response data | + | | | +---- Start diagnostic information| + | | | | | + | +----------++----------++--------------------------------------- | + | | || || | + | 004912A090000560060020C0003D0000C9F9F0F2E3C1D9C7C5E34040D7C3D7D9 | + | | | T A R G E T P C P R | + | +------+ | + | Response Code (I902) | + | | + | ---------------------------------------------------------------- | + | | + | C9D5E3C5D9400000000000000000000000000000000000000000000000000000 | + | I N T E R | + | | + | +------- End of diagnostic information | + | | | + | -----------------+ | + | | | + | 000000000000000000 | + +------------------------------------------------------------------+ + Figure 1. Example of a success response record. + + + +Murphy, et al. Informational [Page 20] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + - '0049'X = Length pass-through data, including this length field + - '12A0'X = GDS LU6.2 header + - '90000560060020C0003D0000'X = Fixed value fields + - 'C9F9F0F2'X = Response Code (I902) + - 'E3C1D9C7C5E34040'X = System Name (TARGET) + - 'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) + +9.2 Example of an Error Response Record + + The response record in Figure 2 is one that reports an error. The + virtual device named "PCPRINTER", is not available on the target + system "TARGET", because the device is not available. You would + normally see this error if the printer was already assigned to + another Telnet session. + + +------------------------------------------------------------------+ + | +----- Pass-Through header | + | | +--- Response data | + | | | +---- Start diagnostic information| + | | | | | + | +----------++----------++--------------------------------------- | + | | || || | + | 004912A09000056006008200003D0000F8F9F0F2E3C1D9C7C5E34040D7C3D7D9 | + | | | T A R G E T P C P R | + | +------+ | + | Response Code (8902) | + | | + | ---------------------------------------------------------------- | + | | + | C9D5E3C5D9400000000000000000000000000000000000000000000000000000 | + | I N T E R | + | | + | +------- End of diagnostic information | + | | | + | -----------------+ | + | | | + | 000000000000000000 | + +------------------------------------------------------------------+ + Figure 2. Example of an error response record. + + - '0049'X = Length pass-through data, including this length field + - '12A0'X = GDS LU6.2 header + - '90000560060020C0003D0000'X = Fixed value fields + - 'F8F9F0F2'X = Response Code (8902) + - 'E3C1D9C7C5E34040'X = System Name (TARGET) + - 'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) + + + + + +Murphy, et al. Informational [Page 21] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +9.3 Response Codes + + The Start-Up Response Record success response codes: + + CODE DESCRIPTION + ---- ------------------------------------------------------ + I901 Virtual device has less function than source device + I902 Session successfully started + I906 Automatic sign-on requested, but not allowed. + Session still allowed; a sign-on screen will be + coming. + + The Start-Up Response Record error response codes: + + CODE DESCRIPTION + ---- ------------------------------------------------------ + 2702 Device description not found. + 2703 Controller description not found. + 2777 Damaged device description. + 8901 Device not varied on. + 8902 Device not available. + 8903 Device not valid for session. + 8906 Session initiation failed. + 8907 Session failure. + 8910 Controller not valid for session. + 8916 No matching device found. + 8917 Not authorized to object. + 8918 Job canceled. + 8920 Object partially damaged. + 8921 Communications error. + 8922 Negative response received. + 8923 Start-up record built incorrectly. + 8925 Creation of device failed. + 8928 Change of device failed. + 8929 Vary on or vary off failed. + 8930 Message queue does not exist. + 8934 Start-up for S/36 WSF received. + 8935 Session rejected. + 8936 Security failure on session attempt. + 8937 Automatic sign-on rejected. + 8940 Automatic configuration failed or not allowed. + I904 Source system at incompatible release. + + + + + + + + + +Murphy, et al. Informational [Page 22] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +10. Printer Steady-State Pass-Through Interface + + The information in this section applies to the passthrough session + after the receipt of startup confirmation records is complete. + + Following is the printer header interface used by Telnet. + + +------------------------------------------------------------------+ + | +-- Length of structure (LLLL) | + | | | + | | +-- GDS identifier | + | | | | + | | | +-- Data flow record | + | | | | | + | | | | +-- Length of pass-through specific header (LL) | + | | | | | | + | | | | | +-- Flags | + | | | | | | | + | | | | | | +-- Printer operation code | + | | | | | | | | + | | | | | | | +-- Diagnostic field - zero pad to| + | | | | | | | | LL specified | + | | | | | | | | | + | | | | | | | | +-- Printer data | + | | | | | | | | | | + | +--+ +--+ +--+ ++ +--+ ++ +----------+ +----------------+ | + | | | | | | | || | | || | | | | | + | xxxx 12A0 xxxx xx xxxx xx xxxxxxxxxxxx ... print data ... | + | | + +------------------------------------------------------------------+ + Figure 3. Layout of the printer pass-through header + + BYTES 0-1: Length of structure including this field (LLLL) + + BYTES 2-3: GDS Identifier ('12A0'X) + + BYTE 4-5: Data flow record + + This field contains flags that describe what type of + data pass-through should expect to find following this + header. Generally, bits 0-2 in the first byte are + mutually exclusive (that is, if one of them is set to ' + 1'B, the rest will be set to '0'B.) The bits, and their + meanings follow. + + + + + + + +Murphy, et al. Informational [Page 23] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + BIT DESCRIPTION + + 0 Start-Up confirmation + 1 Termination record + 2 Start-Up Record + 3 Diagnostic information included + 4 - 5 Reserved + 6 Reserved + 7 Printer record + 8 - 13 Reserved + 14 Client-originated (inbound) printer record + 15 Server-originated (outbound) printer record + + BYTE 6: Length printer pass-through header including this + field (LL) + + BYTES 7-8: Flags + + BYTE 7 BITS: xxxx x111 --> Reserved + xxxx 1xxx --> Last of chain + xxx1 xxxx --> First of chain + xx1x xxxx --> Printer now ready + x1xx xxxx --> Intervention Required + 1xxx xxxx --> Error Indicator + + BYTE 8 BITS: xxxx xxxx --> Reserved + + BYTE 9: Printer operation code + + '01'X Print/Print complete + '02'X Clear Print Buffers + + BYTE 10-LL: Diagnostic information (1) + + If BYTE 7 = xx1x xxxx then bytes 10-LL may contain: + Printer ready C9 00 00 00 02 + + If BYTE 7 = x1xx xxxx then bytes 10-LL may contain: (2) + Command/parameter not valid C9 00 03 02 2x + Print check C9 00 03 02 3x + Forms check C9 00 03 02 4x + Normal periodic condition C9 00 03 02 5x + Data stream error C9 00 03 02 6x + Machine/print/ribbon check C9 00 03 02 8x + + If BYTE 7 = 1xxx xxxx then bytes 10-LL may contain: (3) + Cancel 08 11 02 00 + Invalid print parameter 08 11 02 29 + + + +Murphy, et al. Informational [Page 24] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + Invalid print command 08 11 02 28 + + Diagnostic information notes: + + 1. LL is the length of the structure defined in Byte 6. If no + additional data is present, the remainder of the structure must + be padded with zeroes. + + 2. These are printer SIGNAL commands. Further information on these + commands may be obtained from the 5494 Remote Control Unit + Functions Reference guide [2]. Refer to your AS/400 printer + documentation for more specific information on these data stream + exceptions. Some 3812 and 5553 errors that may be seen: + + Machine check C9 00 03 02 11 + Graphics check C9 00 03 02 26 + Print check C9 00 03 02 31 + Form jam C9 00 03 02 41 + Paper jam C9 00 03 02 47 + End of forms C9 00 03 02 50 + Printer not ready C9 00 03 02 51 + Data stream - class 1 C9 00 03 02 66 loss of text + Data stream - class 2 C9 00 03 02 67 text appearance + Data stream - class 3 C9 00 03 02 68 multibyte control error + Data stream - class 4 C9 00 03 02 69 multibyte control parm + Cover unexpectedly open C9 00 03 02 81 + Machine check C9 00 03 02 86 + Machine check C9 00 03 02 87 + Ribbon check C9 00 03 02 88 + + 3. These are printer negative responses. Further information on + these commands may be obtained from the 5494 Remote Control Unit + Functions Reference guide [2]. + + The print data will start in byte LL+1. + +10.1 Example of a Print Record + + Figure 4 shows the server sending the client data with a print + record. This is normally seen following receipt of a Success + Response Record, such as the example in Figure 1. + + + + + + + + + + +Murphy, et al. Informational [Page 25] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + +--------------------------------------------------------------------+ + | +-- Length of structure (LLLL) | + | | +-- GDS identifier | + | | | +-- Data flow record | + | | | | +-- Length of pass-through specific header (LL) | + | | | | | +-- Flags | + | | | | | | +-- Printer operation code | + | | | | | | | +-- Zero pad to LL specified (0A) | + | | | | | | | | +-- Printer data | + | | | | | | | | | | + | +--+ +--+ +--+ ++ +--+ ++ +----------+ +---------------------------| + | | | | | | | || | | || | | | | + | 0085 12A0 0101 0A 1800 01 000000000000 34C4012BD20345FF2BD2044C0002| + | | + | ------------------------------------------------------------ | + | | + | 2BD2040D00002BD20A8501010201030204022BD20309022BD2061100014A | + | | + | ------------------------------------------------------------ | + | | + | 402BD20601010000012BD306F60000FFFF2BD20A48000001000000010100 | + | | + | ------------------------------------------------------------ | + | | + | 2BD10705000B0090012BD2044900F02BD206404A403DE02BD2041500F034 | + | | + | end of printer data | + | -------------------------+ | + | | | + | C4012BD10381FF002BC8034001 | + +--------------------------------------------------------------------+ + Figure 4. Server sending client data with a print record + + - '0085'X = Logical record length, including this byte (LLLL) + - '12A0'X = GDS LU6.2 header + - '0101'X = Data flow record (server to client) + - '0A'X = Length of pass-through specific header (LL) + - '1800'X = First of chain / Last of chain indicators + - '01'X = Print + - '000000000000'X = Zero pad header to LL specified + - '34C401'X = First piece of data for spooled data + - Remainder is printer data/commands/orders + + + + + + + + + +Murphy, et al. Informational [Page 26] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +10.2 Example of a Print Complete Record + + Figure 5 shows the client sending the server a print complete record. + This would normally follow receipt of a print record, such as the + example in Figure 4. This indicates successful completion of a print + request. + + +-------------------------------------------------------------------+ + | +-- Length of structure (LLLL) | + | | +-- GDS identifier | + | | | +-- Data flow record | + | | | | +-- Length of pass-through specific header (LL) | + | | | | | +-- Flags | + | | | | | | +-- Printer operation code | + | | | | | | | | + | +--+ +--+ +--+ ++ +--+ ++ | + | | | | | | | || | | || | + | 000A 12A0 0102 04 0000 01 | + +-------------------------------------------------------------------+ + Figure 5. Client sending server a print complete record + + - '000A'X = Logical record length, including this byte (LLLL) + - '12A0'X = GDS LU6.2 header + - '0102'X = Data flow response record (client to server) + - '04'X = Length of pass-through specific header (LL) + - '0000'X = Good Response + - '01'X = Print Complete + +10.3 Example of a Null Print Record + + Figure 6 shows the server sending the client a null print record. + The null print record is the last print command the server sends to + the client for a print job, and indicates to the printer there is no + more data. The null data byte '00'X is optional, and in some cases + may be omitted (in particular, this scenario occurs in DBCS print + streams). + + This example would normally follow any number of print records, such + as the example in Figure 4. This indicates successful completion of + a print job. The client normally responds to this null print record + with another print complete record, such as in Figure 5. + + + + + + + + + + +Murphy, et al. Informational [Page 27] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + +------------------------------------------------------------------+ + | +-- Length of structure (LLLL) | + | | +-- GDS identifier | + | | | +-- Data flow record | + | | | | +-- Length of pass-through specific header (LL) | + | | | | | +-- Flags | + | | | | | | +-- Printer operation code | + | | | | | | | +-- Zero pad to LL specified (0A) | + | | | | | | | | +-- Printer data | + | | | | | | | | | | + | +--+ +--+ +--+ ++ +--+ ++ +----------+ ++ | + | | | | | | | || | | || | | || | + | 0011 12A0 0101 0A 0800 01 000000000000 00 | + +------------------------------------------------------------------+ + Figure 6. Server sending client a null print record + + - '0011'X = Logical record length, including this byte + - '12A0'X = GDS LU6.2 header + - '0101'X = Data flow record + - '0A'X = Length of pass-through specific header (LL) + - '0800'X = Last of Chain + - '01'X = Print + - '000000000000'X = Zero pad header to LL specified + - '00'X = Null data byte + +11. End-to-End Print Example + + The next example shows a full print exchange between a Telnet client + and server for a 526 byte spooled file. Selective translation of the + hexadecimal streams into 1) Telnet negotiations and 2) ASCII/EBCDIC + characters are done to aid readability. Telnet negotiations are + delimited by '(' and ')' parenthesis characters; ASCII/EBCDIC + conversions are bracketed by '|' vertical bar characters. + + AS/400 Telnet server Enhanced Telnet client + ------------------------------- --------------------------------- + FFFD27 --> + + (IAC DO NEW-ENVIRON) + <-- FFFB27 + + (IAC WILL NEW-ENVIRON) + + FFFD18FFFA270103 49424D5253454544 + 7EA5DFDDFD300404 0003FFF0 --> + + (IAC DO TERMINAL-TYPE + IAC SB NEW-ENVIRON SEND USERVAR + + + +Murphy, et al. Informational [Page 28] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + IBMRSEED xxxxxxxx VAR USERVAR + IAC SE) + + <-- FFFB18 + + (IAC WILL TERMINAL-TYPE) + + FFFA1801FFF0 --> + + (IAC SB TERMINAL-TYPE SEND IAC + SE) + + FFFA27000349424D 52534545447EA5DF + DDFD300404000344 45564E414D450144 + 554D4D5950525403 49424D4D5347514E + 414D450151535953 4F50520349424D4D + 5347514C4942012A 4C49424C0349424D + 464F4E5401313103 49424D5452414E53 + 464F524D01310349 424D4D4652545950 + 4D444C012A485049 490349424D505052 + 5352433101020103 49424D5050525352 + 433201040349424D 454E56454C4F5045 + 01FFFF0349424D41 5343494938393901 + <-- 30FFF0 + + (IAC SB NEW-ENVIRON IS USERVAR + IBMRSEED xxxxxxxx VAR + USERVAR DEVNAME VALUE DUMMYPRT + USERVAR IBMMSGQNAME VALUE QSYSOPR + USERVAR IBMMSGQLIB VALUE *LIBL + USERVAR IBMFONT VALUE 11 + USERVAR IBMTRANSFORM VALUE 1 + USERVAR IBMMFRTYPMDL VALUE *HPII + USERVAR IBMPPRSRC1 VALUE ESC '01'X + USERVAR IBMPPRSRC2 VALUE '04'X + USERVAR IBMENVELOPE VALUE IAC + USERVAR IBMASCII899 VALUE 0 + IAC SE) + + <-- FFFA180049424D2D 333831322D31FFF0 + + (IAC SB TERMINAL-TYPE IS + IBM-3812-1 IAC SE) + FFFD19 --> + + (IAC DO EOR) + <-- FFFB19 + + + + +Murphy, et al. Informational [Page 29] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + (IAC WILL EOR) + + FFFB19 --> + + (IAC WILL EOR) + <-- FFFD19 + + (IAC DO EOR) + FFFD00 --> + + (IAC DO BINARY) + <-- FFFB00 + + (IAC WILL BINARY) + FFFB00 --> + + (IAC WILL BINARY) + <-- FFFD00 + + (IAC DO BINARY) + + 004912A090000560 060020C0003D0000 | - { | + C9F9F0F2C5D3C3D9 E3D7F0F6C4E4D4D4 |I902ELCRTP06DUMM| (EBCDIC) + E8D7D9E340400000 0000000000000000 |YPRT | + 0000000000000000 0000000000000000 | | + 0000000000000000 00FFEF --> | | + + (73-byte startup success response + record ... IAC EOR) + 00DF12A001010A18 0001000000000000 | | + 03CD1B451B283130 551B287330703130 | E (10U (s0p10| (ASCII) + 2E30306831327630 733062303033541B |.00h12v0s0b003T | + 287330421B266440 1B266C304F1B266C |(s0B &d@ &l0O &l| + 303038431B266C30 3035431B28733070 |008C &l005C (s0p| + 31372E3130683130 7630733062303030 |17.10h10v0s0b000| + 541B283130551B28 73307031372E3130 |T (10U (s0p17.10| + 6831307630733062 303030541B287330 |h10v0s0b000T (s0| + 421B2664401B266C 314F1B266C303035 |B &d@ &l1O &l005| + 431B287330703137 2E31306831307630 |C (s0p17.10h10v0| + 733062303030541B 266C314F1B287330 |s0b000T &l1O (s0| + 7031372E31306831 3076307330623030 |p17.10h10v0s0b00| + 30541B2873307031 372E313068313076 |0T (s0p17.10h10v| + 3073306230303054 1B266C30303543FF |0s0b000T &l005C | + EF --> | | + + (... 223-byte print record ... + ... first of chain ... + ... last of chain ... IAC EOR) + + + +Murphy, et al. Informational [Page 30] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + <-- 000A12A001020400 0001FFEF + + (10-byte print complete header) + 031012A001010A10 0001000000000000 | | + 03FFFF1B451B2831 30551B2873307031 | E (10U (s0p1| (ASCII) + 372E313068313076 3073306230303054 |7.10h10v0s0b000T| + 1B287330421B2664 401B266C314F1B26 | (s0B &d@ &l1O &| + 6C303035431B266C 31481B266C314F1B |l005C &l1H &l1O | + 266C3032411B266C 31431B266C303030 |&l02A &l1C &l000| + 38451B266C303038 431B266C30303439 |8E &l008C &l0049| + 461B266130521B26 6C303035430A0A0A |F &a0R &l005C | + 0A0A0A0A1B26612B 3030303130561B26 | &a+00010V &| + 6C303035431B2661 2B30303231364820 |l005C &a+00216H | + 2020202020202020 2020202020202020 | | + 2020202020205072 696E74204B657920 | Print Key | + 4F75747075742020 2020202020202020 |Output | + 2020202020202020 2020202020202020 | | + 2020202020205061 6765202020310D0A | Page 1 | + 1B26612B30303231 3648202020203537 | &a+00216H 57| + 3639535331205634 52334D3020393830 |69SS1 V4R3M0 980| + 373203FFFF392020 2020202020202020 |72 9 | + 202020202020454C 4352545030362020 | ELCRTP06 | + 2020202020202020 202030332F33312F | 03/31/| + 3939202031363A33 303A34350D0A1B26 |99 16:30:45 &| + 612B303032313648 0D0A1B26612B3030 |a+00216H &a+00| + 3231364820202020 446973706C617920 |216H Display | + 4465766963652020 2E202E202E202E20 |Device . . . . | + 2E203A2020515041 444556303033510D |. : QPADEV003Q | + 0A1B26612B303032 3136482020202055 | &a+00216H U| + 73657220202E202E 202E202E202E202E |ser . . . . . .| + 202E202E202E202E 203A202052434153 | . . . . : RCAS| + 54524F0D0A1B2661 2B3030323136480D |TRO &a+00216H | + 0A1B26612B303032 313648204D41494E | &a+00216H MAIN| + 2020202020202020 2020202020202020 | | + 2020202020202020 20202041532F3430 | AS/40| + 30204D61696E204D 656E750D0A1B2661 |0 Main Menu &a| + 2B30303203FFFF31 3648202020202020 |+002 16H | + 2020202020202020 2020202020202020 | | + 2020202020202020 2020202020202020 | | + 2020202020202020 2020202020202020 | | + 2020202020202053 797374656D3A2020 | System: | + 20454C4352545030 360D0A1B26612B30 | ELCRTP06 &a+0| + 3032313648205365 6C656374206F6E65 |0216H Select one| + 206F662074686520 666F6C6C6F77696E | of the followin| + 673A0D0A1B26612B 3030323136480D0A |g: &a+00216H | + 1B26612B30303231 3648202020202020 | &a+00216H | + 312E205573657220 7461736B730D0A1B |1. User tasks | + 26612B3030323136 4820202020202032 |&a+00216H 2| + + + +Murphy, et al. Informational [Page 31] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + 2E204F6666696365 207461736B730D0A |. Office tasks | + 1B26612B30303231 36480D0A1B26612B | &a+00216H &a+| + 3030323136482020 20202020342E2046 |00216H 4. F| + 696C65732C206C69 627261726965732C |iles, libraries,| + 20616EFFEF | an | + + (... 784-byte print record ... + ... first of chain ... IAC EOR) + <-- 000A12A001020400 0001FFEF + + (10-byte print complete header) + + 020312A001010A00 0001000000000000 | | + 64206603FFFF6F6C 646572730D0A1B26 |d f olders &| (ASCII) + 612B303032313648 0D0A1B26612B3030 |a+00216H &a+00| + 3231364820202020 2020362E20436F6D |216H 6. Com| + 6D756E6963617469 6F6E730D0A1B2661 |munications &a| + 2B3030323136480D 0A1B26612B303032 |+00216H &a+002| + 3136482020202020 20382E2050726F62 |16H 8. Prob| + 6C656D2068616E64 6C696E670D0A1B26 |lem handling &| + 612B303032313648 202020202020392E |a+00216H 9.| + 20446973706C6179 2061206D656E750D | Display a menu | + 0A1B26612B303032 3136482020202020 | &a+00216H | + 31302E20496E666F 726D6174696F6E20 |10. Information | + 417373697374616E 74206F7074696F6E |Assistant option| + 730D0A1B26612B30 3032313648202020 |s &a+00216H | + 202031312E20436C 69656E7420416363 | 11. Client Acc| + 6573732F34303020 7461736B730D0A1B |ess/400 tasks | + 26612B3030323136 480D0A1B26612B30 |&a+00216H &a+0| + 303231364803ED20 2020202039302E20 |0216H 90. | + 5369676E206F6666 0D0A1B26612B3030 |Sign off &a+00| + 323136480D0A1B26 612B303032313648 |216H &a+00216H| + 2053656C65637469 6F6E206F7220636F | Selection or co| + 6D6D616E640D0A1B 26612B3030323136 |mmand &a+00216| + 48203D3D3D3E0D0A 1B26612B30303231 |H ===> &a+0021| + 36480D0A1B26612B 3030323136482046 |6H &a+00216H F| + 333D457869742020 2046343D50726F6D |3=Exit F4=Prom| + 707420202046393D 5265747269657665 |pt F9=Retrieve| + 2020204631323D43 616E63656C202020 | F12=Cancel | + 4631333D496E666F 726D6174696F6E20 |F13=Information | + 417373697374616E 740D0A1B26612B30 |Assistant &a+0| + 3032313648204632 333D53657420696E |0216H F23=Set in| + 697469616C206D65 6E750D0A1B26612B |itial menu &a+| + 3030323136480D0A 1B26612B30303231 |00216H &a+0021| + 36480D0CFFEF |6H | + + (... 515-byte print record ... + IAC EOR) + + + +Murphy, et al. Informational [Page 32] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + <-- 000A12A001020400 0001FFEF + + (10-byte print complete header) + 001412A001010A00 0001000000000000 | | + 03021B45FFEF | E | (ASCII) + + (... 20-byte print record ... + IAC EOR) + <-- 000A12A001020400 0001FFEF + + (10-byte print complete header) + 001112A001010A08 0001000000000000 + 00FFEF --> + + (... 17-byte NULL print record ... + ... last of chain ... IAC EOR) + <-- 000A12A001020400 0001FFEF + + (10-byte print complete header) + +12. Authors' Note + + Discussion of this memo should occur in one of these mailing lists: + + TN3270E List (Roger Fajman raf@cu.nih.gov). Send subscription + requests as e-mail with "subscribe tn3270e your_full_name" to + listserv@list.nih.gov. + + Midrange-L List (David Gibbs david@midrange.com). Send + subscription requests as email with "subscribe midrange-l + your_internet_address" to majordomo@midrange.com. + + Telnet Working Group Mailing List: Send subscription requests as + email with "subscribe telnet-ietf" to telnet-ietf- + request@bsdi.com. + +13. References + + [1] IBM, "IBM 5250 Information Display System, Functions Reference + Manual", SA21-9247-6, March 1987. + + [2] IBM, "5494 Remote Control Unit, Functions Reference", SC30- + 3533-04, August 1995. + + [3] IBM, "AS/400 System API Reference", SC41-5801-01, February + 1998. + + + + + +Murphy, et al. Informational [Page 33] + +RFC 2877 5250 Telnet Enhancements July 2000 + + + [4] IBM, "AS/400 TCP/IP Configuration and Reference", SC41-5420-02, + September 1998. + + [5] IBM, "AS/400 Communications Configuration", SC41-5401-00, + August 1997. + + [6] IBM, "SNA Formats", GA27-3136-13, November 1993. + + [7] IBM, "Using the Pageprinter 3812 with System/36 or System/38", + S544-3343-01, September 1997. + + [8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", + STD 8, RFC 854, May 1983. + + [9] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD + 8, RFC 855, May 1983. + + [10] Postel, J. and J. Reynolds, "Telnet Binary Transmission", STD + 27, RFC 856, May 1983. + + [11] VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, + February 1989. + + [12] Postel, J. and J. Reynolds, "Telnet End of Record Option", RFC + 885, December 1983. + + [13] Alexander, S., "Telnet Environment Option", RFC 1572, January + 1994. + + [14] Chmielewski, P., "5250 Telnet Interface", RFC 1205, February + 1991. + + [15] Postel, J. and J. Reynolds, "Telnet Supress Go Ahead Option", + STD 29, RFC 858, May 1983. + + [16] IBM, "AS/400 National Language Support", SC41-5101-01, February + 1998. + + [17] Data Encryption Standard (DES), Federal Information Processing + Standards Publication 46-2, January 22, 1988. + + [18] DES Modes of Operation, Federal Information Processing + Standards Publication 81, December 1980. + + [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [20] IBM, "IBM Pageprinter 3812 Programming Reference", S544-3268. + + + +Murphy, et al. Informational [Page 34] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +14. Security Considerations + + Security considerations of passwords are discussed in Section 6. + +15. Authors' Addresses + + Thomas E. Murphy, Jr. + IBM Corporation + 1701 North Street + Endicott, NY 13760 + + Phone: (607) 752-5482 + Fax: (607) 752-5421 + EMail: murphyte@us.ibm.com + + + Paul F. Rieth + IBM Corporation + 1701 North Street + Endicott, NY 13760 + + Phone: (607) 752-5474 + Fax: (607) 752-5421 + EMail: rieth@us.ibm.com + + + Jeffrey S. Stevens + IBM Corporation + 1701 North Street + Endicott, NY 13760 + + Phone: (607) 752-5488 + Fax: (607) 752-5421 + EMail: jssteven@us.ibm.com + +16. Relation to Other RFC's + + UPDATES + + This memo is an update to RFC 1205 [14], which describes the 5250 + Telnet Interface. This update enhances that description to + include device negotiation as well as printer support. + + This memo makes use of RFC 1572 [13] to enhance communications + with 5250 Telnet clients. RFC 1572 is currently on the Standards + Track as a Proposed Standard, and is listed in Assigned Numbers + [19]. + + + + +Murphy, et al. Informational [Page 35] + +RFC 2877 5250 Telnet Enhancements July 2000 + + +17. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Murphy, et al. Informational [Page 36] + |