idnits 2.17.1 draft-ietf-tn3270e-tn5250e-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 154 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC1205, updated by this document, for RFC5378 checks: 1991-02-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9142 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 1533 looks like a reference -- Missing reference section? '13' on line 1613 looks like a reference -- Missing reference section? '11' on line 1555 looks like a reference -- Missing reference section? '12' on line 1558 looks like a reference -- Missing reference section? '10' on line 1552 looks like a reference -- Missing reference section? '15' on line 1567 looks like a reference -- Missing reference section? '5' on line 1538 looks like a reference -- Missing reference section? '16' on line 1570 looks like a reference -- Missing reference section? '17' on line 1573 looks like a reference -- Missing reference section? '18' on line 1576 looks like a reference -- Missing reference section? '8' on line 1546 looks like a reference -- Missing reference section? '2' on line 1530 looks like a reference -- Missing reference section? '1' on line 1527 looks like a reference -- Missing reference section? '4' on line 1535 looks like a reference -- Missing reference section? '6' on line 1541 looks like a reference -- Missing reference section? '7' on line 1543 looks like a reference -- Missing reference section? '9' on line 1549 looks like a reference -- Missing reference section? '14' on line 1609 looks like a reference -- Missing reference section? '19' on line 1616 looks like a reference -- Missing reference section? '20' on line 1582 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TN3270E Working Group T. Murphy, Jr. 2 Internet-Draft: P. Rieth 3 Updates: RFC 1205 J. Stevens 4 Expiration Date: October, 1999 IBM Corporation 5 April 1999 7 5250 Telnet Enhancements 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html.This document is an Internet-Draft. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This draft describes the interface to the IBM 5250 Telnet server that 37 allows client Telnet to request a Telnet terminal or printer session 38 using a specific device name. If a requested device name is not 39 available, a method to retry the request using a new device name is 40 described. Methods to request specific Telnet session settings and 41 auto-signon function are also described. 43 By allowing a Telnet client to select the device name, the 5250 44 Telnet server opens the door for applications to set and/or extract 45 useful information about the Telnet client. Some possibilities are 46 1) selecting a customized device name associated with a particular 47 user profile name for National Language Support or subsystem routing, 48 2) connecting PC and network printers as clients and 3) auto-signon 49 using clear-text or DES-encrypted password exchange. 51 Applications may need to use system API's on the AS/400 in order to 52 extract Telnet session settings from the device name description. 53 Refer to the Retrieve Device Description (QDCRDEVD) API described in 54 the AS/400 System API book [3] on how to extract information using 55 the DEVD0600 and DEVD1100 templates. 57 This draft describes how the IBM 5250 Telnet server supports Work 58 Station Function (WSF) printers using 5250 Display Station Pass- 59 Through. A response code is returned by the Telnet server to 60 indicate success or failure of the WSF printer session. 62 1. Table of Contents 64 CONTENTS 66 1. Table of Contents.................................. 3 67 2. Enhancing Telnet Negotiations...................... 4 68 3. Standard Telnet Option Negotiation................. 5 69 4. Enhanced Telnet Option Negotiation................. 7 70 5. Enhanced Display Emulation Support................. 10 71 6. Enhanced Display Auto-Signon and Password 72 Encryption......................................... 11 73 6.1 Password Substitutes Processing.............. 15 74 6.2 Handling passwords of length 9 and 10........ 18 75 6.3 Example Password Substitute Calculation...... 18 76 7. Device Name Collision Processing................... 19 77 8. Enhanced Printer Emulation Support................. 20 78 9. Telnet Printer Terminal Types...................... 22 79 10. Telnet Printer Startup Response Record for Printer 80 Emulators.......................................... 25 81 10.1 Example of a Success Response Record......... 26 82 10.2 Example of an Error Response Record.......... 27 83 10.3 Response Codes............................... 28 84 11. Printer Steady-State Pass-Through Interface........ 29 85 11.1 Example of a Print Record.................... 32 86 11.2 Example of a Print Complete Record........... 33 87 11.3 Example of a Null Print Record............... 34 88 12. End-to-End Print Example........................... 35 89 13. Author's Note...................................... 40 90 14. References......................................... 40 91 15. Security Considerations............................ 41 92 16. Author's Address................................... 41 93 17. Relation to Other RFC's............................ 42 95 LIST OF FIGURES 97 Figure 1. Example of a success status response 98 record....................................... 26 99 Figure 2. Example of an error response record.......... 27 100 Figure 3. Layout of the printer pass-through 101 header....................................... 29 102 Figure 4. Server sending client data with a print 103 record....................................... 32 104 Figure 5. Client sending server a print complete 105 record....................................... 33 106 Figure 6. Server sending client a null print 107 record....................................... 34 109 2. Enhancing Telnet Negotiations 111 The 5250 Telnet server enables clients to negotiate both terminal and 112 printer device names through Telnet Environment Options Negotiations, 113 defined in the Standards Track RFC 1572 [13]. 115 The purpose of RFC 1572 is to exchange environment information using 116 a set of standard or custom variables. By using a combination of 117 both standard VAR's and custom USERVAR's, the 5250 Telnet server 118 allows client Telnet to request a pre-defined specific device by 119 name. 121 If no pre-defined device exists then the device will be created, with 122 client Telnet having the option to negotiate device attributes, such 123 as the code page, character set, keyboard type, etc. 125 Since printers can now be negotiated as a device name, new terminal 126 types have been defined to request printers. For example, you can 127 now negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE 128 options [11]. 130 Finally, the 5250 Telnet server will allow exchange of user profile 131 and password information, where the password may be in either clear- 132 text or encrypted form. If a valid combination of profile and 133 password is received, then the client is allowed to bypass the sign- 134 on panel. The setting of the QRMTSIGN system value must be either 135 *VERIFY or *SAMEPRF for the bypass of the sign-on panel to succeed. 137 3. Standard Telnet Option Negotiation 139 Telnet server option negotiation typically begins with the issuance, 140 by the server, of an invitation to engage in terminal type 141 negotiation with the Telnet client (DO TERMINAL-TYPE) [11]. The 142 client and server then enter into a series of sub-negotiations to 143 determine the level of terminal support that will be used. After the 144 terminal type is agreed upon, the client and server will normally 145 negotiate a required set of additional options (EOR [12], BINARY 146 [10], SGA [15]) that are required to support "transparent mode" or 147 full screen 5250/3270 block mode support. As soon as the required 148 options have been negotiated, the server will suspend further 149 negotiations, and begin with initializing the actual virtual device 150 on the AS/400. A typical exchange might start like the following: 152 AS/400 Telnet server Enhanced Telnet client 153 -------------------------- ------------------------- 154 IAC DO TERMINAL-TYPE --> 155 <-- IAC WILL TERMINAL-TYPE 156 IAC SB TERMINAL-TYPE SEND 157 IAC SE --> 158 IAC SB TERMINAL-TYPE IS 159 <-- IBM-5555-C01 IAC SE 160 IAC DO EOR --> 161 <-- IAC WILL EOR 162 <-- IAC DO EOR 163 IAC WILL EOR --> 164 . 165 . 166 (other negotiations) . 168 Actual bytes transmitted in the above example are shown in hex below. 170 AS/400 Telnet server Enhanced Telnet client 171 -------------------------- ------------------------- 172 FF FD 18 --> 173 <-- FF FB 18 174 FF FA 18 01 FF F0 --> 175 FF FA 18 00 49 42 4D 2D 176 35 35 35 35 2D 43 30 31 177 <-- FF F0 178 FF FD 19 --> 179 <-- FF FB 19 180 <-- FF FD 19 181 FF FB 19 --> 182 . 183 . 184 (other negotiations) . 186 Some negotiations are symmetrical between client and server and some 187 are negotiated in one direction only. Also, it is permissible and 188 common practice to bundle more than one response or request, or 189 combine a request with a response, so the actual exchange may look 190 different in practice to what is shown above. 192 4. Enhanced Telnet Option Negotiation 194 In order to accommodate the new environment option negotiations, the 195 server will bundle an environment option invitation along with the 196 standard terminal type invitation request to the client. 198 A client should either send a negative acknowledgment (WONT NEW- 199 ENVIRON), or at some point after completing terminal-type 200 negotiations, but before completing the full set of negotiations 201 required for 5250 transparent mode, engage in environment option 202 sub-negotiation with the server. A maximum of 1024 bytes of 203 environment strings may be sent to the server. A recommended 204 sequence might look like the following: 206 AS/400 Telnet server Enhanced Telnet client 207 -------------------------- ------------------------- 208 IAC DO NEW-ENVIRON 209 IAC DO TERMINAL-TYPE --> 210 (2 requests bundled) 211 <-- IAC WILL NEW-ENVIRON 212 IAC SB NEW-ENVIRON SEND 213 VAR IAC SE --> 214 IAC SB NEW-ENVIRON IS 215 VAR "USER" VALUE "JONES" 216 USERVAR "DEVNAME" VALUE "MYDEVICE07" 217 <-- IAC SE 218 <-- IAC WILL TERMINAL-TYPE 219 (do the terminal type 220 sequence first) 221 IAC SB TERMINAL-TYPE SEND 222 IAC SE --> 223 IAC SB TERMINAL-TYPE IS 224 <-- IBM-5555-C01 IAC SE 225 (terminal type negotiations 226 completed) 227 IAC DO EOR --> 228 (server will continue 229 with normal transparent 230 mode negotiations) 231 <-- IAC WILL EOR 232 . 233 . 234 (other negotiations) . 236 Actual bytes transmitted in the above example are shown in hex below. 238 AS/400 Telnet server Enhanced Telnet client 239 -------------------------- ------------------------- 240 FF FD 27 241 FF FD 18 --> 242 (2 requests bundled) 243 <-- FF FB 27 244 FF FA 27 01 00 FF F0 --> 245 FF FA 27 00 00 55 53 45 246 52 01 4A 4F 4E 45 53 03 247 44 45 56 4E 41 4D 45 01 248 4D 59 44 45 56 49 43 45 249 <-- 30 37 FF F0 250 <-- FF FB 18 251 (do the terminal type 252 sequence first) 253 FF FA 18 01 FF F0 --> 254 FF FA 18 00 49 42 4D 2D 255 35 35 35 35 2D 43 30 31 256 <-- FF F0 257 FF FD 19 --> 258 (server will continue 259 with normal transparent 260 mode negotiations) 261 <-- FF FB 19 262 . 263 . 264 (other negotiations) . 266 RFC 1572 defines 6 standard VAR's: USER, JOB, ACCT, PRINTER, 267 SYSTEMTYPE, and DISPLAY. The USER standard VAR will hold the value 268 of the AS/400 user profile name to be used in auto-signon requests. 269 The Telnet server will make no direct use of the additional 5 VAR's, 270 nor are any of them required to be sent. All standard VAR's and 271 their values that are received by the Telnet server will be placed in 272 a buffer, along with any USERVAR's received (described below), and 273 made available to a registered initialization exit program to be used 274 for any purpose desired. 276 There are some reasons you may want to send NEW-ENVIRON negotiations 277 prior to TERMINAL-TYPE negotiations. With AS/400 TELNET server, 278 several virtual device modes can be negotiated: 1) VTxxx device 2) 279 3270 device 3) 5250 device (includes Network Station). The virtual 280 device mode selected depends on the TERMINAL-TYPE negotiated plus any 281 other TELNET option negotiations necessary to support those modes. 282 The AS/400 TELNET server will create the desired virtual device at 283 the first opportunity it thinks it has all the requested attributes 284 needed to create the device. This can be as early as completion of 285 the TERMINAL-TYPE negotiations. 287 For the case of Transparent mode (5250 device), then the moment 288 TERMINAL-TYPE, BINARY, and EOR options are negotiated the TELNET 289 server will go create the virtual device. Receiving any NEW-ENVIRON 290 negotiations after these option negotiations are complete will result 291 in the NEW-ENVIRON negotiations having no effect on device 292 attributes, as the virtual device will have already been created. 293 So, for Transparent mode, NEW-ENVIRON negotiations are effectively 294 closed once EOR is negotiated, since EOR is generally the last option 295 done. 297 For other devices modes (such as VTxxx or 3270), you cannot be sure 298 when the AS/400 TELNET server thinks it has all the attributes to 299 create the device. Recall that NEW-ENVIRON negotiations are 300 optional, and therefore the AS/400 TELNET server need not wait for 301 any NEW-ENVIRON options prior to creating the virtual device. It is 302 in the clients best interest to send NEW-ENVIRON negotiations as soon 303 as possible, preferably before TERMINAL-TYPE is negotiated. That 304 way, the client can be sure the requested attributes were received 305 before the virtual device is created. 307 5. Enhanced Display Emulation Support 309 RFC 1572 style USERVAR variables have been defined to allow a 310 compliant Telnet client more control over the Telnet server virtual 311 device on the AS/400. These USERVAR's allow the client Telnet to 312 create or select a previously created virtual device. If the virtual 313 device does not exist and must be created, then the USERVAR variables 314 are used to create and initialize the device attributes. If the 315 virtual device already exists, the device attributes are modified. 317 The USERVAR's defined to accomplish this are: 319 USERVAR VALUE EXAMPLE DESCRIPTION 320 -------- ---------------- ---------------- ------------------- 321 DEVNAME us-ascii char(x) MYDEVICE07 Display device name 322 KBDTYPE us-ascii char(3) USB Keyboard type 323 CODEPAGE us-ascii char(y) 437 Code page 324 CHARSET us-ascii char(y) 1212 Character set 326 x - up to a maximum of 10 characters 327 y - up to a maximum of 5 characters 329 For a description of the KBDTYPE, CODEPAGE and CHARSET parameters and 330 their permissible values, refer to Chapter 8 in the Communications 331 Configuration Reference [5] and also to Appendix C in National 332 Language Support [16]. 334 The CODEPAGE and CHARSET USERVAR's must be associated with a KBDTYPE 335 USERVAR. If either CODEPAGE or CHARSET are sent without KBDTYPE, 336 they will default to system values. A default value for KBDTYPE can 337 be sent to force CODEPAGE and CHARSET values to be used. 339 AS/400 system objects such as device names, user profiles, clear-text 340 passwords, programs, libraries, etc. are required to be specified in 341 English Upper Case (EUC). This includes: 343 Any letter (A-Z), any number (0-9), special characters (# $ _ @) 345 Therefore, where us-ascii is specified for VAR or USERVAR values, it 346 is recommended that upper-cased ASCII values be sent, which will be 347 converted to EBCDIC by the Telnet server. 349 A special case occurs for encrypted passwords (described in the next 350 section), where both the initial password and user profile used to 351 build the encrypted password must be EBCDIC English Upper Case, in 352 order to be properly authenticated by the Telnet server. 354 6. Enhanced Display Auto-Signon and Password Encryption 356 Several 5250 Telnet server specific USERVAR's will be defined. One 357 will carry a random seed to be used in Data Encryption Standard (DES) 358 password encryption, and another will carry the encrypted copy of the 359 password. This would use the same 7-step DES-based password 360 substitution scheme as APPC and Client Access. For a description of 361 DES encryption, refer to Federal Information Processing Standards 362 Publications (FIPS) 46-2 [17] and 81 [18], which can be found at the 363 Federal Information Processing Standards Publications link: 365 http://www.itl.nist.gov/div897/pubs/by-num.htm 367 For a description of the 7-step password substitution scheme, refer 368 to these IBM Customer Support FTP Server links: 370 ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps 371 ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps.Z 372 ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.zip 374 If encrypted password exchange is not required, clear-text password 375 exchange is permitted using the same USERVAR's defined for 376 encryption. For this case, the random client seed should be set to 377 either an empty value (RFC 1572 preferred method) or to hexadecimal 378 zeros to indicate the password is not encrypted, but is clear-text. 380 It should be noted that security of clear-text password exchange 381 cannot be guaranteed unless the network is physically protected or a 382 trusted network (such as an intranet). If your network is vulnerable 383 to IP address spoofing or directly connected to the Internet, you 384 should engage in encrypted password exchange to validate a clients 385 identity. 387 Additional VAR's and USERVAR's have also been defined to allow an 388 auto-signon user greater control over their startup environment, 389 similar to what is supported using the Open Virtual Terminal 390 (QTVOPNVT) API [3]. 392 The standard VAR's supported to accomplish this are: 394 VAR VALUE EXAMPLE DESCRIPTION 395 -------- ---------------- ---------------- ------------------- 396 USER us-ascii char(x) USERXYZ User profile name 398 x - up to a maximum of 10 characters 399 The custom USERVAR's defined to accomplish this are: 401 USERVAR VALUE EXAMPLE DESCRIPTION 402 -------- ---------------- ---------------- ------------------- 403 IBMRSEED binary(8) 8-byte hex field Random client seed 404 IBMSUBSPW binary(10) 10-byte hex field Substitute password 405 IBMCURLIB us-ascii char(x) QGPL Current library 406 IBMIMENU us-ascii char(x) MAIN Initial menu 407 IBMPROGRAM us-ascii char(x) QCMD Program to call 409 x - up to a maximum of 10 characters 411 In order to communicate the server random seed value to the client, 412 the server will request a USERVAR name made up of a fixed part (the 8 413 characters "IBMRSEED" immediately followed by an 8-byte hexadecimal 414 variable part, which is the server random seed. The client generates 415 its own 8-byte random seed value, and uses both seeds to encrypt the 416 password. Both the encrypted password and the client random seed 417 value are then sent to the server for authentication. RFC 1572 rules 418 will need to be adhered to when transmitting the client random seed 419 and substituted password values to the server. Specifically, since a 420 typical environment string is a variable length hexadecimal field, 421 the hexadecimal fields are required to be escaped and/or byte stuffed 422 according to the RFC 854 [8], where any single byte could be mis- 423 construed as a Telnet IAC or other Telnet option negotiation control 424 character. The client must escape and/or byte stuff any bytes which 425 could be seen as a RFC 1572 [13] option, specifically VAR, VALUE, ESC 426 and USERVAR. 428 The following illustrates the encrypted case: 430 AS/400 Telnet server Enhanced Telnet client 431 -------------------------- ------------------------------- 432 IAC DO NEW-ENVIRON --> 433 <-- IAC WILL NEW-ENVIRON 434 IAC SB NEW-ENVIRON SEND 435 USERVAR "IBMRSEEDxxxxxxxx" 436 USERVAR "IBMSUBSPW" 437 VAR USERVAR IAC SE --> 438 IAC SB NEW-ENVIRON IS 439 VAR "USER" VALUE "DUMMYUSR" 440 USERVAR "IBMRSEED" VALUE "yyyyyyyy" 441 USERVAR "IBMSUBSPW" VALUE "zzzzzzzz" 442 <-- IAC SE 443 . 444 . 445 (other negotiations) . 447 In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 448 seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed and 449 "zzzzzzzz" is an 8-byte hexadecimal encrypted password. If the 450 password is not valid, then the sign-on panel is displayed. If the 451 password is expired, then the Change Password panel is displayed. 453 Actual bytes transmitted in the above example are shown in hex below, 454 where the server seed is "7D3E488F18080404", the client seed is 455 "4E4142334E414233" and the encrypted password is "DFB0402F22ABA3BA". 456 The user profile used to generate the encrypted password is 457 "44554D4D59555352" (DUMMYUSR), with a clear-text password of 458 "44554D4D595057" (DUMMYPW). 460 AS/400 Telnet server Enhanced Telnet client 461 -------------------------- ------------------------- 462 FF FD 27 --> 463 <-- FF FB 27 464 FF FA 27 01 03 49 42 4D 465 52 53 45 45 44 7D 3E 48 466 8F 18 08 04 04 03 49 42 467 4D 53 55 42 53 50 57 03 468 00 FF F0 --> 469 FF FA 27 00 00 55 53 45 470 52 01 44 55 4D 4D 59 55 471 53 52 03 49 42 4D 52 53 472 45 45 44 01 4E 41 42 33 473 4E 41 42 33 03 49 42 4D 474 53 55 42 53 50 57 01 DF 475 B0 40 2F 22 AB A3 BA FF 476 <-- F0 478 The following illustrates the clear-text case: 480 AS/400 Telnet server Enhanced Telnet client 481 -------------------------- ------------------------- 482 IAC DO NEW-ENVIRON --> 483 <-- IAC WILL NEW-ENVIRON 484 IAC SB NEW-ENVIRON SEND 485 USERVAR "IBMRSEEDxxxxxxxx" 486 USERVAR "IBMSUBSPW" 487 VAR USERVAR IAC SE --> 488 IAC SB NEW-ENVIRON IS 489 VAR "USER" VALUE "DUMMYUSR" 490 USERVAR "IBMRSEED" VALUE 491 USERVAR "IBMSUBSPW" VALUE "yyyyyyyy" 492 <-- IAC SE 493 . 494 . 495 (other negotiations) . 497 In this example, "xxxxxxxx" is an 8-byte hexadecimal random server 498 seed, "yyyyyyyyyy" is a 10-byte us-ascii client clear-text password. 499 If the password has expired, then the sign-on panel is displayed. 501 Actual bytes transmitted in the above example are shown in hex below, 502 where the server seed is "7D3E488F18080404", the client seed is empty 503 and the clear-text password is "44554D4D595057" (DUMMYPW). The user 504 profile used is "44554D4D59555352" (DUMMYUSR). 506 AS/400 Telnet server Enhanced Telnet client 507 -------------------------- ------------------------- 508 FF FD 27 --> 509 <-- FF FB 27 510 FF FA 27 01 03 49 42 4D 511 52 53 45 45 44 7D 3E 48 512 8F 18 08 04 04 03 49 42 513 4D 53 55 42 53 50 57 03 514 00 FF F0 --> 515 FF FA 27 00 00 55 53 45 516 52 01 44 55 4D 4D 59 55 517 53 52 03 49 42 4D 52 53 518 45 45 44 01 03 49 42 4D 519 53 55 42 53 50 57 01 44 520 <-- 55 4D 4D 59 50 57 FF F0 522 6.1 Password Substitutes Processing 524 Both APPC and Client Access use well-known DES encryption algorithms 525 to create encrypted passwords. A Network Station or Enhanced Client 526 can generate compatible encrypted passwords if they follow these 527 steps, details of which can be found in the Federal Information 528 Processing Standards 46-2 [17]. 530 1. Padded_PW = Left justified user password padded to the right 531 with '40'X to 8 bytes. 533 The users password must be left justified in an 8 byte 534 variable and padded to the right with '40'X up to an 8 byte 535 length. If the users password is 8 bytes in length, no 536 padding would occur. For computing password substitutes for 537 passwords of length 9 and 10 see section "Handling passwords 538 of length 9 and 10" below. Passwords less than 1 byte or 539 greater than 10 bytes in length are not valid. Please note, 540 if password is not in EBCDIC, it must be converted to EBCDIC 541 uppercase. 543 2. XOR_PW = Padded_PW xor '5555555555555555'X 545 The padded password is Exclusive OR'ed with 8 bytes of '55'X. 547 3. SHIFT_RESULT = XOR_PW << 1 549 The entire 8 byte result is shifted 1 bit to the left; the 550 leftmost bit value is discarded, and the rightmost bit value 551 is cleared to 0. 553 4. PW_TOKEN = DES_ECB_mode(SHIFT_RESULT, /* key */ 554 userID_in_EBCDIC_uppercase /* data */ ) 556 This shifted result is used as key to the Data Encryption 557 Standard (Federal Information Processing Standards 46-2 [17]) 558 to encipher the user identifier. When the user identifier is 559 less than 8 bytes, it is left justified in an 8 byte variable 560 and padded to the right with '40'X. When the user identifier 561 is 9 or 10 bytes, it is first padded to the right with '40'X 562 to a length of 10 bytes. Then bytes 9 and 10 are "folded" 563 into bytes 1-8 using the following algorithm: 565 Bit 0 is the high-order bit (i.e. has value of '80'X). 567 Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1 568 Exclusive OR'ed with byte 9, bits 0 and 1. 569 Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1 570 Exclusive OR'ed with byte 9, bits 2 and 3. 571 Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1 572 Exclusive OR'ed with byte 9, bits 4 and 5. 573 Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1 574 Exclusive OR'ed with byte 9, bits 6 and 7. 575 Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1 576 Exclusive OR'ed with byte 10, bits 0 and 1. 577 Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1 578 Exclusive OR'ed with byte 10, bits 2 and 3. 579 Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1 580 Exclusive OR'ed with byte 10, bits 4 and 5. 581 Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1 582 Exclusive OR'ed with byte 10, bits 6 and 7. 584 User identifier greater than 10 bytes or less than 1 byte are 585 not the result of this encryption id known as PW_TOKEN in the 586 paper. 588 5. Increment PWSEQs and store it. 590 Each LU must maintain a pair of sequence numbers for ATTACHs 591 sent and received on each session. Each time an ATTACH is 592 generated, (and password substitutes are in use on the 593 session) the sending sequence number, PWSEQs, is incremented 594 and saved for the next time. Both values are set to zero at 595 BIND time. So the first use of PWSEQs has the value of 1, 596 and increases by one with each use. A new field is added to 597 the ATTACH to carry this sequence number. However, in 598 certain error conditions, it is possible for the sending side 599 to increment the sequence number and the receiver may not 600 increment it. When the sender sends a subsequent ATTACH, the 601 receiver will detect a missing sequence. This is allowed. 602 However the sequence number received must always be larger 603 than the previous one, even if some are missing. 605 The maximum number of consecutive missing sequence numbers 606 allowed is 16. If this is exceeded, the session is unbound 607 with a protocol violation. 609 Note: The sequence number must be incremented for every 610 ATTACH sent. However, the sequence number field is only 611 required to be included in the FMH5 if a password substitute 612 is sent (byte 4, bit 3 on). 614 6. RDrSEQ = RDr + PWSEQs /* RDr is server seed. */ 616 The current value of PWSEQs is added to RDr, the random value 617 received from the partner LU on this session, yielding 618 RDrSEQ, essentially a predictably modified value of the 619 random value received from the partner LU at BIND time. 621 7. PW_SUB = DES_CBC_mode(PW_TOKEN, /* key */ 622 (RDrSEQ, /* 8 bytes */ 623 RDs, /* 8 bytes */ 624 ID xor RDrSEQ, /* 16 bytes */ 625 PWSEQs, /* 8 bytes */ 626 ) /* data */ 627 ) 629 The PW_TOKEN is used as a key to the DES function to generate 630 a 8 bytes value for the following string of inputs. The DES 631 CBC mode Initialization Vector (IV) used is 8 bytes of '00'X. 633 RDrSEQ: the random data value received from the partner LU 634 plus the sequence number. 636 RDs: the random data value sent to the partner LU on BIND 637 for this session. 639 A 16 byte value created by: 641 - padding the user identifier with '40'X to a 642 length of 16 bytes. 644 - Exclusive OR the two 8 byte halves of the padded 645 user identifier with the RDrSEQ value. 647 Note: User ID must first be converted to EBCDIC 648 upper case. 650 PWSEQs: the sequence number. 652 This is similar to the process used on LU-LU verification as 653 described in the Enhanced LU-LU Bind Security. The resulting 654 enciphered random data is the 'password substitute'. 656 6.2 Handling passwords of length 9 and 10 658 1. Generate PW_TOKENa by using characters 1 to 8 of the 659 password and steps 1-4 from the previous section. 661 2. Generate PW_TOKENb by using characters 9 and 10 and steps 662 1-4 from the previous section. In this case Padded_PW 663 from step 1 will be characters 9 and 10 padded to the right 664 with '40'X, for a total length of 8. 666 3. PW_TOKEN = PW_TOKENa xor PW_TOKENb 668 4. Now compute PW_SUB by performing steps 5-7 from the 669 previous section. 671 6.3 Example Password Substitute Calculation 673 ID: USER123 674 Password: ABCDEFG 675 Server seed: '7D4C2319F28004B2'X 676 Client seed: '08BEF662D851F4B1'X 677 PWSEQs: 1 (PWSEQs is a sequence number needed in the 678 7-step encryption, and it is always one) 680 Encrypted Password should be : '5A58BD50E4DD9B5F'X 682 7. Device Name Collision Processing 684 Device name collision occurs when a Telnet client sends the Telnet 685 server a virtual device name that it wants to use, but that device is 686 already in use on the server. When this occurs, the Telnet server 687 sends a request to the client asking it to try another device name. 688 The environment option negotiation uses the USERVAR name of DEVNAME 689 to communicate the virtual device name. The following shows how the 690 Telnet server will request the Telnet client to send a different 691 DEVNAME when device name collision occurs. 693 AS/400 Telnet server Enhanced Telnet client 694 -------------------------- ------------------------- 695 IAC SB NEW-ENVIRON SEND 696 VAR USERVAR IAC SE --> 698 Server requests all environment variables be sent. 700 IAC SB NEW-ENVIRON IS USERVAR 701 "DEVNAME" VALUE "MYDEVICE1" 702 USERVAR "xxxxx" VALUE "xxx" 703 ... 704 <-- IAC SE 706 Client sends all environment variables, including DEVNAME. Server 707 tries to select device MYDEVICE1. If the device is already in use, 708 server requests DEVNAME be sent again. 710 IAC SB NEW-ENVIRON SEND 711 USERVAR "DEVNAME" IAC SE --> 713 Server sends a request for a single environment variable: DEVNAME 715 IAC SB NEW-ENVIRON IS USERVAR 716 <-- "DEVNAME" VALUE "MYDEVICE2" IAC SE 718 Client sends one environment variable, calculating a new value of 719 MYDEVICE2. If MYDEVICE2 is different from the last request, then 720 server tries to select device MYDEVICE2, else server disconnects 721 client. If MYDEVICE2 is also in use, server will send DEVNAME request 722 again, and keep doing so until it receives a device that is not in 723 use, or the same device name twice in row. 725 8. Enhanced Printer Emulation Support 727 RFC 1572 style USERVAR variables have been defined to allow a 728 compliant Telnet client more control over the Telnet server virtual 729 device on the AS/400. These USERVAR's allow the client Telnet to 730 select a previously created virtual device or auto-create a new 731 virtual device with requested attributes. 733 This makes the enhancements available to any Telnet client that 734 chooses to support the new negotiations. 736 The USERVAR's defined to accomplish this are: 738 USERVAR VALUE EXAMPLE DESCRIPTION 739 ------------- ---------------- ---------------- ------------------- 740 DEVNAME us-ascii char(x) PRINTER1 Printer device name 741 IBMIGCFEAT us-ascii char(6) 2424J0 IGC feature (DBCS) 742 IBMMSGQNAME us-ascii char(x) QSYSOPR *MSGQ name 743 IBMMSGQLIB us-ascii char(x) QSYS *MSGQ library 744 IBMFONT us-ascii char(x) 12 Font 745 IBMFORMFEED us-ascii char(1) C | U | A Formfeed 746 IBMTRANSFORM us-ascii char(1) 1 | 0 Transform 747 IBMMFRTYPMDL us-ascii char(x) *IBM42023 Mfg. type and model 748 IBMPPRSRC1 binary(1) 1-byte hex field Paper source 1 749 IBMPPRSRC2 binary(1) 1-byte hex field Paper source 2 750 IBMENVELOPE binary(1) 1-byte hex field Envelope hopper 751 IBMASCII899 us-ascii char(1) 1 | 0 ASCII 899 support 752 IBMWSCSTNAME us-ascii char(x) *NONE WSCST name 753 IBMWSCSTLIB us-ascii char(x) *LIBL WSCST library 755 x - up to a maximum of 10 characters 757 The "IBM" prefix on the USERVAR's denotes AS/400 specific attributes. 759 The DEVNAME USERVAR is used both for displays and printers. The 760 IBMFONT and IBMASCII899 are used only for SBCS environments. 762 For a description of most of these parameters (drop the "IBM" from 763 the USERVAR) and their permissible values, refer to Chapter 8 in the 764 Communications Configuration Reference [5]. 766 The IBMIGCFEAT supports the following variable DBCS language 767 identifiers in position 5 (positions 1-4 must be '2424', position 6 768 must be '0'): 770 'J' = Japanese 'K' = Korean 771 'C' = Traditional Chinese 'S' = Simplified Chinese 773 The IBMPPRSRC1, IBMPPRSRC2 and IBMENVELOPE custom USERVAR's do not map 774 directly to their descriptions in Chapter 8 in the Communications 775 Configuration Reference [5]. To map these, use the index listed here: 777 IBMPPRSRC1 HEX IBMPPRSRC2 HEX IBMENVELOPE HEX 778 ---------- ----- ---------- ----- ----------- ----- 779 *NONE 'FF'X *NONE 'FF'X *NONE 'FF'X 780 *MFRTYPMDL '00'X *MFRTYPMDL '00'X *MFRTYPMDL '00'X 781 *LETTER '01'X *LETTER '01'X *B5 '06'X 782 *LEGAL '02'X *LEGAL '02'X *MONARCH '09'X 783 *EXECUTIVE '03'X *EXECUTIVE '03'X *NUMBER9 '0A'X 784 *A4 '04'X *A4 '04'X *NUMBER10 '0B'X 785 *A5 '05'X *A5 '05'X *C5 '0C'X 786 *B5 '06'X *B5 '06'X *DL '0D'X 787 *CONT80 '07'X *CONT80 '07'X 788 *CONT132 '08'X *CONT132 '08'X 789 *A3 '0E'X *A3 '0E'X 790 *B4 '0F'X *B4 '0F'X 791 *LEDGER '10'X *LEDGER '10'X 793 Note 1: For IBMPPRSRC2, *CONT80 and *CONT132 support starts at V3R7. 795 Note 2: For IBMPPRSRC1 and IBMPPRSRC2, *A3, *B4 and *LEDGER support 796 starts at V3R7. 798 9. Telnet Printer Terminal Types 800 New Telnet options are defined for the printer pass-through mode of 801 operation. To enable printer pass-through mode, both the client and 802 server must agree to at least support the Transmit-Binary, End-Of- 803 Record, and Terminal-Type Telnet options. The following are new 804 terminal types for printers: 806 TERMINAL-TYPE DESCRIPTION 807 ------------- ------------------- 808 IBM-5553-B01 Double-Byte printer 809 IBM-3812-1 Single-Byte printer 811 Specific characteristics of the IBM-5553-B01 or IBM-3812-1 printers 812 are specified through the USERVAR IBMMFRTYPMDL, which specifies the 813 manufacturer type and model. 815 An example of a typical negotiation process to establish printer 816 pass-through mode of operation is shown below. In this example, the 817 server initiates the negotiation by sending the DO TERMINAL-TYPE 818 request. 820 For DBCS environments, if IBMTRANSFORM is set to 1 (use Host Print 821 Transform), then the virtual device created is 3812, not 5553. 822 Therefore, IBM-3812-1 should be negotiated for TERMINAL-TYPE, and not 823 IBM-5553-B01. 825 AS/400 Telnet server Enhanced Telnet client 826 -------------------------- -------------------------- 827 IAC DO NEW-ENVIRON --> 828 <-- IAC WILL NEW-ENVIRON 829 IAC SB NEW-ENVIRON SEND 830 VAR USERVAR IAC SE --> 831 IAC SB NEW-ENVIRON IS 832 USERVAR "DEVNAME" VALUE "PCPRINTER" 833 USERVAR "IBMMSGQNAME" VALUE "QSYSOPR" 834 USERVAR "IBMMSGQLIB" VALUE "*LIBL" 835 USERVAR "IBMTRANSFORM" VALUE "0" 836 USERVAR "IBMFONT" VALUE "12" 837 USERVAR "IBMFORMFEED" VALUE "C" 838 USERVAR "IBMPPRSRC1" VALUE ESC '01'X 839 USERVAR "IBMPPRSRC2" VALUE '04'X 840 USERVAR "IBMENVELOPE" VALUE IAC 'FF'X 841 <-- IAC SE 842 IAC DO TERMINAL-TYPE --> 843 <-- IAC WILL TERMINAL-TYPE 844 IAC SB TERMINAL-TYPE SEND 845 IAC SE --> 846 IAC SB TERMINAL-TYPE IS IBM-3812-1 847 <-- IAC SE 848 IAC DO BINARY --> 849 <-- IAC WILL BINARY 850 IAC DO EOR --> 851 <-- IAC WILL EOR 853 Some points about the above example. The IBMPPRSRC1 value requires 854 escaping the value using ESC according to RFC 1572 [13]. The 855 IBMPPRSRC2 does not require an ESC character since '04'X has no 856 conflict with RFC 1572 options. Finally, to send 'FF'X for the 857 IBMENVELOPE value, escape the 'FF'X value by using another 'FF'X 858 (called "doubling"), so as not to have the value interpreted as a 859 Telnet character per RFC 854 [8]. 861 Actual bytes transmitted in the above example are shown in hex below. 863 AS/400 Telnet server Enhanced Telnet client 864 -------------------------- -------------------------- 865 FF FD 27 --> 866 <-- FF FB 27 867 FF FA 27 01 00 03 FF F0 --> 868 FF FA 27 00 03 44 45 56 869 4E 41 4D 45 01 50 43 50 870 52 49 4E 54 45 52 03 49 871 42 4D 4D 53 47 51 4E 41 872 4D 45 01 51 53 59 53 4F 873 50 52 03 49 42 4D 4D 53 874 47 51 4C 49 42 01 2A 4C 875 49 42 4C 03 49 42 4D 54 876 52 41 4E 53 46 4F 52 4D 877 01 30 03 49 42 4D 46 4F 878 4E 54 01 31 32 03 49 42 879 4D 46 4F 52 4D 46 45 45 880 44 01 43 03 49 42 4D 50 881 50 52 53 52 43 31 01 02 882 01 03 49 42 4D 50 50 52 883 53 52 43 32 01 04 03 49 884 42 4D 45 4E 56 45 4C 4F 885 <-- 50 45 01 FF FF FF F0 886 FF FD 18 --> 887 <-- FF FB 18 888 FF FA 18 01 FF F0 --> 889 FF FA 18 00 49 42 4D 2D 890 <-- 33 38 31 32 2D 31 FF F0 891 FF FD 00 --> 892 <-- FF FB 00 893 FF FD 19 --> 894 FF FB 19 896 10. Telnet Printer Startup Response Record for Printer Emulators 898 Once Telnet negotiation for a 5250 pass-through mode is completed, 899 the 5250 Telnet server will initiate a virtual printer power-on 900 sequence on behalf of the Telnet client. The Telnet server will 901 supply a Startup Response Record to the Telnet client with the status 902 of the printer power-on sequence, indicating success or failure of 903 the virtual printer power-on sequence. 905 This section shows an example of two Startup Response Records. The 906 source device is a type 3812 model 01 printer with name "PCPRINTER" 907 on the target system "TARGET". 909 Figure 1 shows an example of a successful response; Figure 2 shows an 910 example of an error response. 912 10.1 Example of a Success Response Record 914 The response record in Figure 1 was sent by an AS/400 at Release 915 V4R2. It is an example of the target sending back a successful 916 Startup Response Record. 918 +--------------------------------------------------------------------+ 919 | +----- Pass-Through header | 920 | | +--- Response data | 921 | | | +---- Start diagnostic information | 922 | | | | | 923 | +----------++----------++--------------------------------------- | 924 | | || || | 925 | 004912A090000560060020C0003D0000C9F9F0F2E3C1D9C7C5E34040D7C3D7D9 | 926 | | | T A R G E T P C P R | 927 | +------+ | 928 | Response Code (I902) | 929 | | 930 | ---------------------------------------------------------------- | 931 | | 932 | C9D5E3C5D9400000000000000000000000000000000000000000000000000000 | 933 | I N T E R | 934 | | 935 | +------- End of diagnostic information | 936 | | | 937 | -----------------+ | 938 | | | 939 | 000000000000000000 | 940 +--------------------------------------------------------------------+ 941 Figure 1. Example of a success response record. 943 - '0049'X = Length pass-through data, including this length field 944 - '12A0'X = GDS LU6.2 header 945 - '90000560060020C0003D0000'X = Fixed value fields 946 - 'C9F9F0F2'X = Response Code (I902) 947 - 'E3C1D9C7C5E34040'X = System Name (TARGET) 948 - 'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) 950 10.2 Example of an Error Response Record 952 The response record in Figure 2 is one that reports an error. The 953 virtual device named "PCPRINTER", is not available on the target 954 system "TARGET", because the device is not available. You would 955 normally see this error if the printer was already assigned to 956 another Telnet session. 958 +--------------------------------------------------------------------+ 959 | +----- Pass-Through header | 960 | | +--- Response data | 961 | | | +---- Start diagnostic information | 962 | | | | | 963 | +----------++----------++--------------------------------------- | 964 | | || || | 965 | 004912A09000056006008200003D0000F8F9F0F2E3C1D9C7C5E34040D7C3D7D9 | 966 | | | T A R G E T P C P R | 967 | +------+ | 968 | Response Code (8902) | 969 | | 970 | ---------------------------------------------------------------- | 971 | | 972 | C9D5E3C5D9400000000000000000000000000000000000000000000000000000 | 973 | I N T E R | 974 | | 975 | +------- End of diagnostic information | 976 | | | 977 | -----------------+ | 978 | | | 979 | 000000000000000000 | 980 +--------------------------------------------------------------------+ 981 Figure 2. Example of an error response record. 983 - '0049'X = Length pass-through data, including this length field 984 - '12A0'X = GDS LU6.2 header 985 - '90000560060020C0003D0000'X = Fixed value fields 986 - 'F8F9F0F2'X = Response Code (8902) 987 - 'E3C1D9C7C5E34040'X = System Name (TARGET) 988 - 'D7C3D7D9C9D5E3C5D940'X = Object Name (PCPRINTER) 990 10.3 Response Codes 992 The Start-Up Response Record success response codes: 994 CODE DESCRIPTION 995 ---- ------------------------------------------------------ 996 I901 Virtual device has less function than source device 997 I902 Session successfully started 998 I906 Automatic sign-on requested, but not allowed. 999 Session still allowed; a sign-on screen will be 1000 coming. 1002 The Start-Up Response Record error response codes: 1004 CODE DESCRIPTION 1005 ---- ------------------------------------------------------ 1006 2702 Device description not found. 1007 2703 Controller description not found. 1008 2777 Damaged device description. 1009 8901 Device not varied on. 1010 8902 Device not available. 1011 8903 Device not valid for session. 1012 8906 Session initiation failed. 1013 8907 Session failure. 1014 8910 Controller not valid for session. 1015 8916 No matching device found. 1016 8917 Not authorized to object. 1017 8918 Job canceled. 1018 8920 Object partially damaged. 1019 8921 Communications error. 1020 8922 Negative response received. 1021 8923 Start-up record built incorrectly. 1022 8925 Creation of device failed. 1023 8928 Change of device failed. 1024 8929 Vary on or vary off failed. 1025 8930 Message queue does not exist. 1026 8934 Start-up for S/36 WSF received. 1027 8935 Session rejected. 1028 8936 Security failure on session attempt. 1029 8937 Automatic sign-on rejected. 1030 8940 Automatic configuration failed or not allowed. 1031 I904 Source system at incompatible release. 1033 11. Printer Steady-State Pass-Through Interface 1035 The information in this section applies to the passthrough session 1036 after the receipt of startup confirmation records is complete. 1038 Following is the printer header interface used by Telnet. 1040 +--------------------------------------------------------------------+ 1041 | +-- Length of structure (LLLL) | 1042 | | | 1043 | | +-- GDS identifier | 1044 | | | | 1045 | | | +-- Data flow record | 1046 | | | | | 1047 | | | | +-- Length of pass-through specific header (LL) | 1048 | | | | | | 1049 | | | | | +-- Flags | 1050 | | | | | | | 1051 | | | | | | +-- Printer operation code | 1052 | | | | | | | | 1053 | | | | | | | +-- Diagnostic field - zero pad to | 1054 | | | | | | | | LL specified | 1055 | | | | | | | | | 1056 | | | | | | | | +-- Printer data | 1057 | | | | | | | | | | 1058 | +--+ +--+ +--+ ++ +--+ ++ +----------+ +----------------+ | 1059 | | | | | | | || | | || | | | | | 1060 | xxxx 12A0 xxxx xx xxxx xx xxxxxxxxxxxx ... print data ... | 1061 | | 1062 +--------------------------------------------------------------------+ 1063 Figure 3. Layout of the printer pass-through header 1065 BYTES 0-1: Length of structure including this field (LLLL) 1067 BYTES 2-3: GDS Identifier ('12A0'X) 1068 BYTE 4-5: Data flow record 1070 This field contains flags that describe what type of data 1071 pass-through should expect to find following this header. 1072 Generally, bits 0-2 in the first byte are mutually exclusive 1073 (that is, if one of them is set to '1'B, the rest will 1074 be set to '0'B.) The bits, and their meanings follow. 1076 BIT DESCRIPTION 1078 0 Start-Up confirmation 1079 1 Termination record 1080 2 Start-Up Record 1081 3 Diagnostic information included 1082 4 - 5 Reserved 1083 6 Reserved 1084 7 Printer record 1085 8 - 13 Reserved 1086 14 Client-originated (inbound) printer record 1087 15 Server-originated (outbound) printer record 1089 BYTE 6: Length printer pass-through header including this field (LL) 1091 BYTES 7-8: Flags 1093 BYTE 7 BITS: xxxx x111 --> Reserved 1094 xxxx 1xxx --> Last of chain 1095 xxx1 xxxx --> First of chain 1096 xx1x xxxx --> Printer now ready 1097 x1xx xxxx --> Intervention Required 1098 1xxx xxxx --> Error Indicator 1100 BYTE 8 BITS: xxxx xxxx --> Reserved 1102 BYTE 9: Printer operation code 1104 '01'X Print/Print complete 1105 '02'X Clear Print Buffers 1107 BYTE 10-LL: Diagnostic information (1) 1109 If BYTE 7 = xx1x xxxx then bytes 10-LL may contain: 1110 Printer ready C9 00 00 00 02 1112 If BYTE 7 = x1xx xxxx then bytes 10-LL may contain: (2) 1113 Command/parameter not valid C9 00 03 02 2x 1114 Print check C9 00 03 02 3x 1115 Forms check C9 00 03 02 4x 1116 Normal periodic condition C9 00 03 02 5x 1117 Data stream error C9 00 03 02 6x 1118 Machine/print/ribbon check C9 00 03 02 8x 1120 If BYTE 7 = 1xxx xxxx then bytes 10-LL may contain: (3) 1121 Cancel 08 11 02 00 00 1122 Invalid print parameter 08 11 02 29 00 1123 Invalid print command 08 11 02 28 00 1125 Diagnostic information notes: 1127 1. LL is the length of the structure defined in Byte 6. If 1128 no additional data is present, the remainder of the 1129 structure must be padded with zeroes. 1131 2. These are printer SIGNAL commands. Further information on 1132 these commands may be obtained from the 5494 Remote Control 1133 Unit Functions Reference guide [2]. Refer to your AS/400 printer 1134 documentation for more specific information on these data stream 1135 exceptions. Some 3812 and 5553 errors that may be seen: 1137 Machine check C9 00 03 02 11 1138 Graphics check C9 00 03 02 26 1139 Print check C9 00 03 02 31 1140 Form jam C9 00 03 02 41 1141 Paper jam C9 00 03 02 47 1142 End of forms C9 00 03 02 50 1143 Printer not ready C9 00 03 02 51 1144 Data stream - class 1 C9 00 03 02 66 loss of text 1145 Data stream - class 2 C9 00 03 02 67 text appearance 1146 Data stream - class 3 C9 00 03 02 68 multibyte control error 1147 Data stream - class 4 C9 00 03 02 69 multibyte control parm 1148 Cover unexpectedly open C9 00 03 02 81 1149 Machine check C9 00 03 02 86 1150 Machine check C9 00 03 02 87 1151 Ribbon check C9 00 03 02 88 1153 3. These are printer negative responses. Further information 1154 on these commands may be obtained from the 5494 Remote 1155 Control Unit Functions Reference guide [2]. 1157 The print data will start in byte LL+1. 1159 11.1 Example of a Print Record 1161 Figure 4 shows the server sending the client data with a print 1162 record. This is normally seen following receipt of a Success 1163 Response Record, such as the example in Figure 1. 1165 +--------------------------------------------------------------------+ 1166 | +-- Length of structure (LLLL) | 1167 | | +-- GDS identifier | 1168 | | | +-- Data flow record | 1169 | | | | +-- Length of pass-through specific header (LL) | 1170 | | | | | +-- Flags | 1171 | | | | | | +-- Printer operation code | 1172 | | | | | | | +-- Zero pad to LL specified (0A) | 1173 | | | | | | | | +-- Printer data | 1174 | | | | | | | | | | 1175 | +--+ +--+ +--+ ++ +--+ ++ +----------+ +---------------------------| 1176 | | | | | | | || | | || | | | | 1177 | 0085 12A0 0101 0A 1800 01 000000000000 34C4012BD20345FF2BD2044C0002| 1178 | | 1179 | ------------------------------------------------------------ | 1180 | | 1181 | 2BD2040D00002BD20A8501010201030204022BD20309022BD2061100014A | 1182 | | 1183 | ------------------------------------------------------------ | 1184 | | 1185 | 402BD20601010000012BD306F60000FFFF2BD20A48000001000000010100 | 1186 | | 1187 | ------------------------------------------------------------ | 1188 | | 1189 | 2BD10705000B0090012BD2044900F02BD206404A403DE02BD2041500F034 | 1190 | | 1191 | end of printer data | 1192 | -------------------------+ | 1193 | | | 1194 | C4012BD10381FF002BC8034001 | 1195 +--------------------------------------------------------------------+ 1196 Figure 4. Server sending client data with a print record 1198 - '0085'X = Logical record length, including this byte (LLLL) 1199 - '12A0'X = GDS LU6.2 header 1200 - '0101'X = Data flow record (server to client) 1201 - '0A'X = Length of pass-through specific header (LL) 1202 - '1800'X = First of chain / Last of chain indicators 1203 - '01'X = Print 1204 - '000000000000'X = Zero pad header to LL specified 1205 - '34C401'X = First piece of data for spooled data 1206 - Remainder is printer data/commands/orders 1208 11.2 Example of a Print Complete Record 1210 Figure 5 shows the client sending the server a print complete record. 1211 This would normally follow receipt of a print record, such as the 1212 example in Figure 4. This indicates successful completion of a print 1213 request. 1215 +--------------------------------------------------------------------+ 1216 | +-- Length of structure (LLLL) | 1217 | | +-- GDS identifier | 1218 | | | +-- Data flow record | 1219 | | | | +-- Length of pass-through specific header (LL) | 1220 | | | | | +-- Flags | 1221 | | | | | | +-- Printer operation code | 1222 | | | | | | | | 1223 | +--+ +--+ +--+ ++ +--+ ++ | 1224 | | | | | | | || | | || | 1225 | 000A 12A0 0102 04 0000 01 | 1226 +--------------------------------------------------------------------+ 1227 Figure 5. Client sending server a print complete record 1229 - '000A'X = Logical record length, including this byte (LLLL) 1230 - '12A0'X = GDS LU6.2 header 1231 - '0102'X = Data flow response record (client to server) 1232 - '04'X = Length of pass-through specific header (LL) 1233 - '0000'X = Good Response 1234 - '01'X = Print Complete 1236 11.3 Example of a Null Print Record 1238 Figure 6 shows the server sending the client a null print record. 1239 The null print record is the last print command the server sends to 1240 the client for a print job, and indicates to the printer there is no 1241 more data. The null data byte '00'X is optional, and in some cases 1242 may be omitted (in particular, this scenario occurs in DBCS print 1243 streams). 1245 This example would normally follow any number of print records, such 1246 as the example in Figure 4. This indicates successful completion of 1247 a print job. The client normally responds to this null print record 1248 with another print complete record, such as in Figure 5. 1250 +--------------------------------------------------------------------+ 1251 | +-- Length of structure (LLLL) | 1252 | | +-- GDS identifier | 1253 | | | +-- Data flow record | 1254 | | | | +-- Length of pass-through specific header (LL) | 1255 | | | | | +-- Flags | 1256 | | | | | | +-- Printer operation code | 1257 | | | | | | | +-- Zero pad to LL specified (0A) | 1258 | | | | | | | | +-- Printer data | 1259 | | | | | | | | | | 1260 | +--+ +--+ +--+ ++ +--+ ++ +----------+ ++ | 1261 | | | | | | | || | | || | | || | 1262 | 0011 12A0 0101 0A 0800 01 000000000000 00 | 1263 +--------------------------------------------------------------------+ 1264 Figure 6. Server sending client a null print record 1266 - '0011'X = Logical record length, including this byte 1267 - '12A0'X = GDS LU6.2 header 1268 - '0101'X = Data flow record 1269 - '0A'X = Length of pass-through specific header (LL) 1270 - '0800'X = Last of Chain 1271 - '01'X = Print 1272 - '000000000000'X = Zero pad header to LL specified 1273 - '00'X = Null data byte 1275 12. End-to-End Print Example 1277 The next example shows a full print exchange between a Telnet client 1278 and server for a 526 byte spooled file. Selective translation of the 1279 hexadecimal streams into 1) Telnet negotiations and 2) ASCII/EBCDIC 1280 characters are done to aid readability. Telnet negotiations are 1281 delimited by '(' and ')' parenthesis characters; ASCII/EBCDIC 1282 conversions are bracketed by '|' vertical bar characters. 1284 AS/400 Telnet server Enhanced Telnet client 1285 --------------------------------- --------------------------------- 1286 FFFD27 --> 1288 (IAC DO NEW-ENVIRON) 1289 <-- FFFB27 1291 (IAC WILL NEW-ENVIRON) 1293 FFFD18FFFA270103 49424D5253454544 1294 7EA5DFDDFD300404 0003FFF0 --> 1296 (IAC DO TERMINAL-TYPE 1297 IAC SB NEW-ENVIRON SEND USERVAR 1298 IBMRSEED xxxxxxxx VAR USERVAR 1299 IAC SE) 1301 <-- FFFB18 1303 (IAC WILL TERMINAL-TYPE) 1305 FFFA1801FFF0 --> 1307 (IAC SB TERMINAL-TYPE SEND IAC 1308 SE) 1310 FFFA27000349424D 52534545447EA5DF 1311 DDFD300404000344 45564E414D450144 1312 554D4D5950525403 49424D4D5347514E 1313 414D450151535953 4F50520349424D4D 1314 5347514C4942012A 4C49424C0349424D 1315 464F4E5401313103 49424D5452414E53 1316 464F524D01310349 424D4D4652545950 1317 4D444C012A485049 490349424D505052 1318 5352433101020103 49424D5050525352 1319 433201040349424D 454E56454C4F5045 1320 01FFFF0349424D41 5343494938393901 1321 <-- 30FFF0 1322 (IAC SB NEW-ENVIRON IS USERVAR 1323 IBMRSEED xxxxxxxx VAR 1324 USERVAR DEVNAME VALUE DUMMYPRT 1325 USERVAR IBMMSGQNAME VALUE QSYSOPR 1326 USERVAR IBMMSGQLIB VALUE *LIBL 1327 USERVAR IBMFONT VALUE 11 1328 USERVAR IBMTRANSFORM VALUE 1 1329 USERVAR IBMMFRTYPMDL VALUE *HPII 1330 USERVAR IBMPPRSRC1 VALUE ESC '01'X 1331 USERVAR IBMPPRSRC2 VALUE '04'X 1332 USERVAR IBMENVELOPE VALUE IAC 1333 USERVAR IBMASCII899 VALUE 0 1334 IAC SE) 1336 <-- FFFA180049424D2D 333831322D31FFF0 1338 (IAC SB TERMINAL-TYPE IS 1339 IBM-3812-1 IAC SE) 1340 FFFD19 --> 1342 (IAC DO EOR) 1343 <-- FFFB19 1345 (IAC WILL EOR) 1347 FFFB19 --> 1349 (IAC WILL EOR) 1350 <-- FFFD19 1352 (IAC DO EOR) 1353 FFFD00 --> 1355 (IAC DO BINARY) 1356 <-- FFFB00 1358 (IAC WILL BINARY) 1359 FFFB00 --> 1361 (IAC WILL BINARY) 1362 <-- FFFD00 1364 (IAC DO BINARY) 1366 004912A090000560 060020C0003D0000 | - { | 1367 C9F9F0F2C5D3C3D9 E3D7F0F6C4E4D4D4 |I902ELCRTP06DUMM| (EBCDIC) 1368 E8D7D9E340400000 0000000000000000 |YPRT | 1369 0000000000000000 0000000000000000 | | 1370 0000000000000000 00FFEF --> | | 1372 (73-byte startup success response 1373 record ... IAC EOR) 1374 00DF12A001010A18 0001000000000000 | | 1375 03CD1B451B283130 551B287330703130 | E (10U (s0p10| (ASCII) 1376 2E30306831327630 733062303033541B |.00h12v0s0b003T | 1377 287330421B266440 1B266C304F1B266C |(s0B &d@ &l0O &l| 1378 303038431B266C30 3035431B28733070 |008C &l005C (s0p| 1379 31372E3130683130 7630733062303030 |17.10h10v0s0b000| 1380 541B283130551B28 73307031372E3130 |T (10U (s0p17.10| 1381 6831307630733062 303030541B287330 |h10v0s0b000T (s0| 1382 421B2664401B266C 314F1B266C303035 |B &d@ &l1O &l005| 1383 431B287330703137 2E31306831307630 |C (s0p17.10h10v0| 1384 733062303030541B 266C314F1B287330 |s0b000T &l1O (s0| 1385 7031372E31306831 3076307330623030 |p17.10h10v0s0b00| 1386 30541B2873307031 372E313068313076 |0T (s0p17.10h10v| 1387 3073306230303054 1B266C30303543FF |0s0b000T &l005C | 1388 EF --> | | 1390 (... 223-byte print record ... 1391 ... first of chain ... 1392 ... last of chain ... IAC EOR) 1393 <-- 000A12A001020400 0001FFEF 1395 (10-byte print complete header) 1396 031012A001010A10 0001000000000000 | | 1397 03FFFF1B451B2831 30551B2873307031 | E (10U (s0p1| (ASCII) 1398 372E313068313076 3073306230303054 |7.10h10v0s0b000T| 1399 1B287330421B2664 401B266C314F1B26 | (s0B &d@ &l1O &| 1400 6C303035431B266C 31481B266C314F1B |l005C &l1H &l1O | 1401 266C3032411B266C 31431B266C303030 |&l02A &l1C &l000| 1402 38451B266C303038 431B266C30303439 |8E &l008C &l0049| 1403 461B266130521B26 6C303035430A0A0A |F &a0R &l005C | 1404 0A0A0A0A1B26612B 3030303130561B26 | &a+00010V &| 1405 6C303035431B2661 2B30303231364820 |l005C &a+00216H | 1406 2020202020202020 2020202020202020 | | 1407 2020202020205072 696E74204B657920 | Print Key | 1408 4F75747075742020 2020202020202020 |Output | 1409 2020202020202020 2020202020202020 | | 1410 2020202020205061 6765202020310D0A | Page 1 | 1411 1B26612B30303231 3648202020203537 | &a+00216H 57| 1412 3639535331205634 52334D3020393830 |69SS1 V4R3M0 980| 1413 373203FFFF392020 2020202020202020 |72 9 | 1414 202020202020454C 4352545030362020 | ELCRTP06 | 1415 2020202020202020 202030332F33312F | 03/31/| 1416 3939202031363A33 303A34350D0A1B26 |99 16:30:45 &| 1417 612B303032313648 0D0A1B26612B3030 |a+00216H &a+00| 1418 3231364820202020 446973706C617920 |216H Display | 1419 4465766963652020 2E202E202E202E20 |Device . . . . | 1420 2E203A2020515041 444556303033510D |. : QPADEV003Q | 1421 0A1B26612B303032 3136482020202055 | &a+00216H U| 1422 73657220202E202E 202E202E202E202E |ser . . . . . .| 1423 202E202E202E202E 203A202052434153 | . . . . : RCAS| 1424 54524F0D0A1B2661 2B3030323136480D |TRO &a+00216H | 1425 0A1B26612B303032 313648204D41494E | &a+00216H MAIN| 1426 2020202020202020 2020202020202020 | | 1427 2020202020202020 20202041532F3430 | AS/40| 1428 30204D61696E204D 656E750D0A1B2661 |0 Main Menu &a| 1429 2B30303203FFFF31 3648202020202020 |+002 16H | 1430 2020202020202020 2020202020202020 | | 1431 2020202020202020 2020202020202020 | | 1432 2020202020202020 2020202020202020 | | 1433 2020202020202053 797374656D3A2020 | System: | 1434 20454C4352545030 360D0A1B26612B30 | ELCRTP06 &a+0| 1435 3032313648205365 6C656374206F6E65 |0216H Select one| 1436 206F662074686520 666F6C6C6F77696E | of the followin| 1437 673A0D0A1B26612B 3030323136480D0A |g: &a+00216H | 1438 1B26612B30303231 3648202020202020 | &a+00216H | 1439 312E205573657220 7461736B730D0A1B |1. User tasks | 1440 26612B3030323136 4820202020202032 |&a+00216H 2| 1441 2E204F6666696365 207461736B730D0A |. Office tasks | 1442 1B26612B30303231 36480D0A1B26612B | &a+00216H &a+| 1443 3030323136482020 20202020342E2046 |00216H 4. F| 1444 696C65732C206C69 627261726965732C |iles, libraries,| 1445 20616EFFEF | an | 1447 (... 784-byte print record ... 1448 ... first of chain ... IAC EOR) 1449 <-- 000A12A001020400 0001FFEF 1451 (10-byte print complete header) 1453 020312A001010A00 0001000000000000 | | 1454 64206603FFFF6F6C 646572730D0A1B26 |d f olders &| (ASCII) 1455 612B303032313648 0D0A1B26612B3030 |a+00216H &a+00| 1456 3231364820202020 2020362E20436F6D |216H 6. Com| 1457 6D756E6963617469 6F6E730D0A1B2661 |munications &a| 1458 2B3030323136480D 0A1B26612B303032 |+00216H &a+002| 1459 3136482020202020 20382E2050726F62 |16H 8. Prob| 1460 6C656D2068616E64 6C696E670D0A1B26 |lem handling &| 1461 612B303032313648 202020202020392E |a+00216H 9.| 1462 20446973706C6179 2061206D656E750D | Display a menu | 1463 0A1B26612B303032 3136482020202020 | &a+00216H | 1464 31302E20496E666F 726D6174696F6E20 |10. Information | 1465 417373697374616E 74206F7074696F6E |Assistant option| 1466 730D0A1B26612B30 3032313648202020 |s &a+00216H | 1467 202031312E20436C 69656E7420416363 | 11. Client Acc| 1468 6573732F34303020 7461736B730D0A1B |ess/400 tasks | 1469 26612B3030323136 480D0A1B26612B30 |&a+00216H &a+0| 1470 303231364803ED20 2020202039302E20 |0216H 90. | 1471 5369676E206F6666 0D0A1B26612B3030 |Sign off &a+00| 1472 323136480D0A1B26 612B303032313648 |216H &a+00216H| 1473 2053656C65637469 6F6E206F7220636F | Selection or co| 1474 6D6D616E640D0A1B 26612B3030323136 |mmand &a+00216| 1475 48203D3D3D3E0D0A 1B26612B30303231 |H ===> &a+0021| 1476 36480D0A1B26612B 3030323136482046 |6H &a+00216H F| 1477 333D457869742020 2046343D50726F6D |3=Exit F4=Prom| 1478 707420202046393D 5265747269657665 |pt F9=Retrieve| 1479 2020204631323D43 616E63656C202020 | F12=Cancel | 1480 4631333D496E666F 726D6174696F6E20 |F13=Information | 1481 417373697374616E 740D0A1B26612B30 |Assistant &a+0| 1482 3032313648204632 333D53657420696E |0216H F23=Set in| 1483 697469616C206D65 6E750D0A1B26612B |itial menu &a+| 1484 3030323136480D0A 1B26612B30303231 |00216H &a+0021| 1485 36480D0CFFEF |6H | 1487 (... 515-byte print record ... 1488 IAC EOR) 1489 <-- 000A12A001020400 0001FFEF 1491 (10-byte print complete header) 1492 001412A001010A00 0001000000000000 | | 1493 03021B45FFEF | E | (ASCII) 1495 (... 20-byte print record ... 1496 IAC EOR) 1497 <-- 000A12A001020400 0001FFEF 1499 (10-byte print complete header) 1500 001112A001010A08 0001000000000000 1501 00FFEF --> 1503 (... 17-byte NULL print record ... 1504 ... last of chain ... IAC EOR) 1505 <-- 000A12A001020400 0001FFEF 1507 (10-byte print complete header) 1509 13. Author's Note 1511 Discussion of this draft should occur in one of these mailing lists: 1513 TN3270E List (Roger Fajman raf@cu.nih.gov). Send subscription 1514 requests as e-mail with "subscribe tn3270e your_full_name" to 1515 listserv@list.nih.gov. 1517 Midrange-L List (David Gibbs david@midrange.com). Send 1518 subscription requests as email with "subscribe midrange-l 1519 your_internet_address" to majordomo@midrange.com. 1521 Telnet Working Group Mailing List: Send subscription requests as 1522 email with "subscribe telnet-ietf" to telnet-ietf- 1523 request@bsdi.com. 1525 14. References 1527 [1] IBM, "IBM 5250 Information Display System, Functions Reference 1528 Manual", SA21-9247-6, March 1987. 1530 [2] IBM, "5494 Remote Control Unit, Functions Reference", SC30- 1531 3533-04, August 1995. 1533 [3] IBM, "AS/400 System API Reference", SC41-5801-01, February 1998. 1535 [4] IBM, "AS/400 TCP/IP Configuration and Reference", SC41-5420-02, 1536 September 1998. 1538 [5] IBM, "AS/400 Communications Configuration", SC41-5401-00, August 1539 1997. 1541 [6] IBM, "SNA Formats", GA27-3136-13, November 1993. 1543 [7] IBM, "Using the Pageprinter 3812 with System/36 or System/38", 1544 S544-3343-01, September 1997. 1546 [8] Postel, J. and J. Reynolds, "TELNET PROTOCOL SPECIFICATION", RFC 1547 854, USC/Information Sciences Institute, May 1983. 1549 [9] Postel, J. and J. Reynolds, "TELNET OPTION SPECIFICATIONS", RFC 1550 855, USC/Information Sciences Institute, May 1983. 1552 [10] Postel, J. and J. Reynolds, "TELNET BINARY TRANSMISSION", RFC 1553 856, USC/Information Sciences Institute, May 1983. 1555 [11] VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, FTP 1556 Software, Inc., February 1989. 1558 [12] Postel, J. and J. Reynolds, "TELNET END OF RECORD OPTION", RFC 1559 885, USC/Information Sciences Institute, December 1983. 1561 [13] Alexander, S., "Telnet Environment Option", RFC 1572, Lachman 1562 Technology, Inc., January 1994. 1564 [14] Chmielewski, P., "5250 Telnet Interface", RFC 1205, IBM 1565 Corporation, February 1991. 1567 [15] Postel, J. and J. Reynolds, "TELNET SUPPRESS GO AHEAD OPTION", 1568 RFC 858, Information Sciences Institute, May 1983. 1570 [16] IBM, "AS/400 National Language Support", SC41-5101-01, February 1571 1998. 1573 [17] Data Encryption Standard (DES), Federal Information Processing 1574 Standards Publication 46-2, January 22, 1988. 1576 [18] DES Modes of Operation, Federal Information Processing 1577 Standards Publication 81, December 1980. 1579 [19] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, STD 1580 2, USC/Information Sciences Institute, October 1994. 1582 [20] IBM, "IBM Pageprinter 3812 Programming Reference", S544-3268. 1584 15. Security Considerations 1586 Security considerations of passwords are discussed in Section 6. 1588 16. Author's Address 1590 Thomas E. Murphy, Jr. Phone: (607) 752-5482 1591 IBM Corporation Fax: (607) 752-5421 1592 1701 North Street Email: murphyte@us.ibm.com 1593 Endicott, NY 13760 1595 Paul F. Rieth Phone: (607) 752-5474 1596 IBM Corporation Fax: (607) 752-5421 1597 1701 North Street Email: rieth@us.ibm.com 1598 Endicott, NY 13760 1600 Jeffrey S. Stevens Phone: (607) 752-5488 1601 IBM Corporation Fax: (607) 752-5421 1602 1701 North Street Email: jssteven@us.ibm.com 1603 Endicott, NY 13760 1605 17. Relation to Other RFC's 1607 UPDATES 1609 This draft is an update to RFC 1205 [14], which describes the 5250 1610 Telnet Interface. This update enhances that description to 1611 include device negotiation as well as printer support. 1613 This draft makes use of RFC 1572 [13] to enhance communications 1614 with 5250 Telnet clients. RFC 1572 is currently on the Standards 1615 Track as a Proposed Standard, and is listed in Assigned Numbers 1616 [19].