idnits 2.17.1 draft-ietf-tn3270e-ver2-enhance-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 1997) is 9842 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1041 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1576 (ref. '10') Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Telnet TN3270 Enhancements Working Group B. Kelly 2 Internet Draft Auburn University 3 Expiration Date: October 1997 May 1997 4 File name: draft-ietf-tn3270e-ver2-enhance-00.txt 6 TN3270 Enhancements 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document describes a protocol that more fully supports 3270 30 devices than do the existing tn3270 practices. Specifically, it 31 defines a method of emulating both the terminal and printer members 32 of the 3270 family of devices via Telnet; it provides for the ability 33 of a Telnet client to request that it be assigned a specific device- 34 name (also referred to as "LU name" or "network name"); finally, it 35 adds support for a variety of functions such as the ATTN key, the 36 SYSREQ key, and SNA response handling. 38 This protocol is negotiated under the TN3270E Telnet Option, and is 39 unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 40 [1]. 42 TABLE OF CONTENTS 44 1. Introduction ............................................... 2 45 2. TN3270E OVERVIEW ........................................... 4 46 3. COMMAND NAMES AND CODES .................................... 4 47 4. COMMAND MEANINGS ........................................... 5 48 5. DEFAULT SPECIFICATION ...................................... 7 49 6. MOTIVATION ................................................. 7 50 7. TN3270E SUB-NEGOTIATION RULES .............................. 7 51 7.1 DEVICE-TYPE Negotiation ................................ 7 52 7.1.1 Device Pools ...................................... 8 53 7.1.2 CONNECT Command ................................... 10 54 7.1.3 ASSOCIATE Command ................................. 10 55 7.1.4 Accepting a Request ............................... 11 56 7.1.5 REJECT Command .................................... 11 57 7.2 FUNCTIONS Negotiation .................................. 12 58 7.2.1 Commands .......................................... 12 59 7.2.2 List of TN3270E Functions ......................... 13 60 8. TN3270E DATA MESSAGES ...................................... 14 61 8.1 The TN3270E Message Header ............................. 15 62 8.1.1 DATA-TYPE Field ................................... 15 63 8.1.2 REQUEST-FLAG Field ................................ 16 64 8.1.3 RESPONSE-FLAG Field ............................... 16 65 8.1.4 SEQ-NUMBER Field .................................. 18 66 9. BASIC TN3270E .............................................. 18 67 9.1 3270 Mode and NVT Mode ................................. 18 68 10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 19 69 10.1 The SCS-CTL-CODES Function ............................. 19 70 10.2 The DATA-STREAM-CTL Function ........................... 20 71 10.3 The BIND-IMAGE Function ................................ 21 72 10.4 The RESPONSES Function ................................. 22 73 10.4.1 Response Messages ................................. 23 74 10.5 The SYSREQ Function .................................... 25 75 10.5.1 Background ........................................ 25 76 10.5.2 TN3270E Implementation of SYSREQ .................. 26 77 11. THE 3270 ATTN KEY .......................................... 27 78 12. 3270 STRUCTURED FIELDS ..................................... 28 79 13. IMPLEMENTATION GUIDELINES .................................. 28 80 13.1 3270 Data Stream Notes ................................. 28 81 13.2 Negotiation of the TN3270E Telnet Option ............... 28 82 13.3 A "Keep-alive" Mechanism ............................... 29 83 13.4 Examples ............................................... 29 84 14. SECURITY CONSIDERATIONS .................................... 33 85 15. REFERENCES ................................................. 33 86 16. AUTHOR'S NOTE .............................................. 34 87 17. AUTHOR'S ADDRESS ........................................... 34 89 1. Introduction 91 Currently, support for 3270 terminal emulation over Telnet is 92 accomplished by the de facto standard of negotiating three separate 93 Telnet Options - Terminal-Type [2], Binary Transmission [3], and End 94 of Record [4]. Note that there is no RFC that specifies this 95 negotiation as a standard. RFC 1041 attempted to standardize the 96 method of negotiating 3270 terminal support by defining the 3270 97 Regime Telnet Option. Very few developers and vendors ever 98 implemented RFC 1041. 100 This document will refer to the existing practice of negotiating 101 these three Telnet Options before exchanging the 3270 data stream as 102 "traditional tn3270". Traditional tn3270 is documented in [10]. 104 NOTE: Except where otherwise stated, this document does not 105 distinguish between Telnet servers that represent SNA devices and 106 those that represent non-SNA 3270 devices. 108 All references in this document to the 3270 data stream, 3270 data 109 stream commands, orders, structured fields and the like rely on [5]. 111 References to SNA Request and Response Units rely on [6]. References 112 to SNA versus non-SNA operation rely on [7]. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119. 118 There are several shortcomings in traditional tn3270; among them are 119 the following: 121 - It provides no capability for Telnet clients to emulate the 328x 122 class of printers. 124 - There is no mechanism by which a Telnet client can request that 125 a connection be associated with a given 3270 device-name. This 126 can be of importance when a terminal session is being 127 established, since many host applications behave differently 128 depending on the network name of the terminal. In the case of 129 printer emulation, this capability is an absolute necessity 130 because a large number of host applications have some method of 131 pre-defining printer destinations. 133 - The 3270 ATTN and SYSREQ keys are not universally supported. 135 - There is no support for the SNA positive/negative response 136 process. This is particularly important if printer emulation is 137 to function properly, but is also useful for some terminal 138 applications. A positive response is used to indicate that 139 the previously received data has been successfully processed. 140 A negative response indicates some sort of error has occurred 141 while processing the previously received data; this could be 142 caused by the host application building a 3270 data stream that 143 contains an invalid command, or by a mechanical error at the 144 client side, among other things. 146 - There is no mechanism by which the client can access the SNA 147 Bind information. The Bind image contains a detailed 148 description of the session between the Telnet server and the 149 host application. 151 - There is no mechanism by which the server can determine whether 152 a client supports 3270 structured fields, or a client can 153 request that it receive them. 155 2. TN3270E Overview 157 In order to address these issues, this document proposes a new Telnet 158 Option - TN3270E. Telnet clients and servers would be free to 159 negotiate support of the TN3270E option or not. If either side does 160 not support TN3270E, traditional tn3270 can be used; otherwise, a 161 sub-negotiation will occur to determine what subset of TN3270E will 162 be used on the session. It is anticipated that a client or server 163 capable of both types of 3270 emulation would attempt to negotiate 164 TN3270E first, and only negotiate traditional tn3270 if the other 165 side refuses TN3270E. 167 Once a client and server have agreed to use TN3270E, negotiation of 168 the TN3270E suboptions can begin. The two major elements of TN3270E 169 sub-negotiation are: 171 - a device-type negotiation that is similar to, but somewhat 172 more complicated than, the existing Telnet Terminal-Type Option. 174 - the negotiation of a set of supported 3270 functions, such as 175 printer data stream type (3270 data stream or SNA Character 176 Stream), positive/negative response exchanges, device status 177 information, and the passing of BIND information from server to 178 client. 180 Successful negotiation of these two suboptions signals the beginning 181 of 3270 data stream transmission. In order to support several of the 182 new functions in TN3270E, each data message must be prefixed by a 183 header. This header will contain flags and indicators that convey 184 such things as positive and negative responses and what type of data 185 follows the header (for example, 3270 data stream, SNA Character 186 Stream, or device status information). 188 3. Command Names and Codes 190 Please note that all numeric literals in this document specify 191 decimal values, unless they are preceded by "0x", in which case 192 a hexadecimal value is represented. 194 TN3270E 40 195 ASSOCIATE 00 196 CONNECT 01 197 DEVICE-TYPE 02 198 FUNCTIONS 03 199 IS 04 200 REASON 05 201 REJECT 06 202 REQUEST 07 203 SEND 08 205 Reason-codes 206 CONN-PARTNER 00 207 DEVICE-IN-USE 01 208 INV-ASSOCIATE 02 209 INV-NAME 03 210 INV-DEVICE-TYPE 04 211 TYPE-NAME-ERROR 05 212 UNKNOWN-ERROR 06 213 UNSUPPORTED-REQ 07 215 Function Names 216 BIND-IMAGE 00 217 DATA-STREAM-CTL 01 218 RESPONSES 02 219 SCS-CTL-CODES 03 220 SYSREQ 04 222 4. Command Meanings 224 Refer to the Telnet Protocol Specification [8] for the meaning of 225 IAC, DO, WILL, etc. 227 IAC WILL TN3270E 229 The sender of this command is willing to send TN3270E 230 information in subsequent sub-negotiations. 232 IAC WON'T TN3270E 234 The sender of this command refuses to send TN3270E information. 236 IAC DO TN3270E 238 The sender of this command is willing to receive TN3270E 239 information in subsequent sub-negotiations. 241 IAC DON'T TN3270E 243 The sender of this command refuses to receive TN3270E 244 information. 246 Note that while they are not explicitly negotiated, the equivalent of 247 the Telnet Binary Transmission Option [3] and the Telnet End of 248 Record Option [4] is implied in the negotiation of the TN3270E 249 Option. That is, a party to the negotiation that agrees to support 250 TN3270E is automatically required to support bi-directional binary 251 and EOR transmissions. 253 IAC SB TN3270E SEND DEVICE-TYPE IAC SE 255 Only the server may send this command. This command is used to 256 request that the client transmit a device-type and, optionally, 257 device-name information. 259 IAC SB TN3270E DEVICE-TYPE REQUEST 260 [ [CONNECT ] | [ASSOCIATE ] ] IAC SE 262 Only the client may send this command. It is used in response 263 to the server's SEND DEVICE-TYPE command, as well as to suggest 264 another device-type after the server has sent a DEVICE-TYPE REJECT 265 command (see below). This command requests emulation of a 266 specific 3270 device type and model. The REQUEST command may 267 optionally include either the CONNECT or the ASSOCIATE command 268 (but not both). If present, CONNECT must be followed by 269 and ASSOCIATE must be followed by . 270 (See the section entitled "DEVICE-TYPE Negotiation" for more 271 detailed information.) 273 IAC SB TN3270E DEVICE-TYPE IS CONNECT 274 IAC SE 276 Only the server may send this command. This command is used to 277 accept a client's DEVICE-TYPE REQUEST command and to return the 278 server-defined device-name. 280 IAC SB TN3270E DEVICE-TYPE REJECT REASON IAC SE 282 Only the server may send this command. This command is used to 283 reject a client's DEVICE-TYPE REQUEST command. 285 IAC SB TN3270E FUNCTIONS REQUEST IAC SE 287 Either side may send this command. This command is used to 288 suggest a set of 3270 functions that will be supported on this 289 session. It is also sent as an implicit rejection of a previous 290 FUNCTIONS REQUEST command sent by the other side (see the 291 section entitled "FUNCTIONS Negotiation" for more information). 292 Note that when used to reject a FUNCTIONS REQUEST command, the 293 function-list must not be identical to that received in the 294 previous REQUEST command. 296 IAC SB TN3270E FUNCTIONS IS IAC SE 298 Either side may send this command. This command is sent as a 299 response to a FUNCTIONS REQUEST command and implies acceptance 300 of the set of functions sent to it in the REQUEST command. Note 301 that the list of functions in the FUNCTIONS IS command must 302 match the list that was received in the previous FUNCTIONS 303 REQUEST command. 305 5. Default Specification 307 WON'T TN3270E 309 DON'T TN3270E 311 i.e., TN3270E will not be used. 313 6. Motivation 315 See the section entitled "Introduction". 317 7. TN3270E Sub-negotiation Rules 319 Once it has been agreed that TN3270E will be supported, the first 320 sub-negotiation must concern the DEVICE-TYPE (and possibly device- 321 name) information. Only after that has been successfully negotiated 322 can the client and server exchange FUNCTIONS information. Only after 323 both DEVICE-TYPE and FUNCTIONS have been successfully negotiated can 324 3270 data stream transmission occur. 326 7.1 DEVICE-TYPE Negotiation 328 Device-type names are NVT ASCII strings, all upper case. 330 Device-type (and device-name) negotiation begins when the server 331 transmits the DEVICE-TYPE SEND command to the client. The client 332 responds with the DEVICE-TYPE REQUEST command, which must include 333 a device-type and may include a resource-name or device-name 334 request. 336 Valid device-types are: 338 terminals: IBM-3278-2 IBM-3278-2-E (24 row x 80 col display) 339 IBM-3278-3 IBM-3278-3-E (32 row x 80 col display) 340 IBM-3278-4 IBM-3278-4-E (43 row x 80 col display) 341 IBM-3278-5 IBM-3278-5-E (27 row x 132 col display) 342 IBM-DYNAMIC (no pre-defined display size) 344 printers: IBM-3287-1 346 Note that the use of '3278' and '3287' is NOT intended to exclude 347 any particular device capabilities; they are used here only 348 because they are commonly known designations for a terminal and a 349 printer member of the 3270 family of devices. The intention is to 350 simplify the device-type negotiation (in comparison to traditional 351 tn3270) by minimizing the number of possible device-types, and by 352 breaking the association of a specific piece of IBM hardware with 353 a related set of data stream capabilities. For example, 354 negotiation of device-type IBM-3278-2-E does NOT in and of itself 355 preclude the use of any of the functions associated with a 356 physical 3279 model S2B. A client's ability to support the more 357 advanced functions of the 3270 data stream will be indicated not 358 by negotiation of an IBM device type and model number, but rather 359 by the combination of Read Partition Query and Query Reply. 361 All of the terminal device-types support a "primary" display size 362 of 24 rows by 80 columns. The "-3", "-4" and "-5" types each 363 support an "alternate" display size as noted in the above list. 364 The IBM-DYNAMIC device-type implies no pre-defined alternate 365 display size; this value will be passed from the client to host 366 applications as part of the Query Reply structured field, and it 367 can represent any display size the client and the host application 368 can support. 370 Terminal device-types with the "-E" suffix should only be 371 negotiated by clients that are willing to support some subset of 372 the 3270 "extended data stream". This usually includes at a 373 minimum support for extended colors and highlighting, but may also 374 include a number of other functions, such as graphics capability, 375 alternate character sets, and partitions. 377 Clients that negotiate a terminal device-type with the "-E" suffix 378 or the DYNAMIC type, as well as those that negotiate a printer 379 device-type, must be able to accept and respond to a Read 380 Partition Query command (see the section entitled "3270 Structured 381 Fields"). This allows the client to indicate to host applications 382 which subsets of the 3270 extended data stream the client is 383 willing to support. 385 In a VTAM/SNA environment, negotiation of IBM-DYNAMIC as the 386 device-type should result in a Bind in which the Presentation 387 Services Usage screen field (the eleventh byte in the logmode's 388 PSERVIC field) is set to 0x03, indicating that the alternate 389 screen size will be determined by the Query Reply (Usable Area). 391 7.1.1 Device Pools 393 An explanation of the CONNECT and ASSOCIATE commands first 394 requires a discussion of the organization of terminal and 395 printer device pools that the server maintains and from which 396 it selects device-names to assign to session requests. 397 Definition of a few terms is also in order. 399 The terms "device-name", "LU name" and "network name" can be 400 considered interchangeable in this document. They refer to 401 a specific terminal or printer device. 403 The term "resource-name" is less specific; it may refer to a 404 device-name, but it may also be the name of a pool of printer 405 or terminal devices. Such a named pool could serve to group 406 devices with similar operational or administrative 407 characteristics. In fact, this document places no restrictions 408 on how a server makes use of resource-names, so long as the 409 server can take a resource-name specified by the client and use 410 it to come up with a device-name to assign to the session. 411 Note, however, that servers must avoid allowing ambiguity; for 412 example, they must not allow the definition of a device-name 413 with the same name as that of a pool of devices. 415 Device-names and resource-names are specified as NVT ASCII 416 strings in which upper and lower case are considered 417 equivalent. The length of device-names and resource-names 418 should not exceed 8 bytes. 420 A "generic session request" is one which includes neither 421 the CONNECT nor the ASSOCIATE command, while a "specific 422 session request" is one that includes either the CONNECT or 423 the ASSOCIATE command. 425 If a TN3270E server wishes to support traditional tn3270 426 clients, it must maintain a set of terminal device-names 427 that can be used to satisfy requests from such clients for 428 terminal sessions. This same pool could be used to satisfy 429 generic requests for terminal sessions from TN3270E clients. 431 The server may also maintain any number of other pools of 432 device-names. For example, there could be a pool of terminal 433 device-names reserved for a specific department within the 434 organization, or a pool of terminal device-names that have 435 access to certain applications on the host. 437 For any of these terminal device pools, the TN3270E server may 438 also have defined a "partner" or "paired" printer device for 439 each terminal in the pool. There should be a unique, 440 one-to-one mapping between a terminal and its associated 441 printer. The reasoning behind such a configuration is to allow 442 for those host applications that produce printed output bound 443 for a printer whose device-name is determined by the 444 device-name of the terminal that initiated the print request. 445 These printer devices can only be assigned to specific printer 446 session requests that use the ASSOCIATE command (see below). 448 In addition, the TN3270E server may also maintain one or more 449 pools of printer device-names that are not associated with any 450 terminal. These printer devices can only be assigned to 451 specific printer session requests that use the CONNECT command 452 (see below). This allows for those host applications that 453 generate printed output bound for a printer whose device-name 454 is determined by something other than the device-name of the 455 terminal that initiated the print request (for example, when 456 the userid of the person signed on to a terminal determines the 457 print destination). It is also possible that a pool of printer 458 device-names could be maintained to satisfy generic requests 459 for printers (i.e., those that specify neither CONNECT nor 460 ASSOCIATE). 462 7.1.2 CONNECT Command 464 CONNECT can be used by the client in two ways: if the resource- 465 name it specifies is a device-name, then the client is 466 requesting a specific device-name. If the specified resource- 467 name is not a device-name, then the client is requesting any 468 one of the device-names associated with the resource-name. 470 In either case, the resource indicated by the specified 471 resource-name must not conflict with the device-type; e.g., if 472 the client requests DEVICE-TYPE IBM-3287-1 (a printer) and 473 specifies CONNECT T1000001, but T1000001 is a device-name 474 defined at the host as a terminal, then the server must deny 475 the request. Further, if the requested resource-name is a 476 device-name already associated with some other Telnet session, 477 or if it is not defined to the server, the server must deny the 478 request. 480 7.1.3 ASSOCIATE Command 482 ASSOCIATE can be used by the client only when requesting a 483 DEVICE-TYPE that represents a printer, and the specified 484 device-name must be that of a terminal that was returned by the 485 server in a previous DEVICE-TYPE IS CONNECT 486 command. 488 The ASSOCIATE command requests that this session be assigned 489 the device-name of the printer that is paired with the terminal 490 named in the request. If the device-type does not represent a 491 printer, or if the device-name is not that of a terminal, then 492 the server must deny the request. Also, if the server does not 493 have defined a partner printer for the specified terminal, it 494 must deny the request. 496 The use of the ASSOCIATE command is to be as follows: A client 497 first connects and requests a terminal from one of the terminal 498 pools; it then uses the terminal device-name returned by the 499 server (see "Accepting a Request", section 7.1.4 below) in a 500 second session request, this time asking for the printer that 501 is paired with the terminal session it just established. This 502 allows clients to associate a printer session with a terminal 503 rather than having to have prior knowledge of a printer 504 device-name. 506 7.1.4 Accepting a Request 508 The server must accept the client's request or deny it as a 509 whole - it cannot, for example, accept the DEVICE-TYPE request 510 but deny the CONNECT portion. 512 If the server wishes to accept the request, it sends back the 513 DEVICE-TYPE IS command confirming the requested device-type and 514 the CONNECT command specifying the device-name of the terminal 515 or printer assigned to this session. 517 Normally, the client should accept any DEVICE-TYPE IS 518 CONNECT sent by the server. 519 An exception to this would be if the client must (e.g., to 520 satisfy local-site policy) be connected to a specific LU name 521 and is presented with a device-name which does not match the 522 one requested by the client (this could happen, for example, if 523 the client requested what it thought was a device-name, but 524 what was defined at the server as the name of a pool of 525 devices). In this case, the client should reject the 526 DEVICE-TYPE IS command by terminating TN3270E negotiations. 528 7.1.5 REJECT Command 530 If the server wishes to deny the request, it sends back the 531 DEVICE-TYPE REJECT command with one of the following reason- 532 codes: 534 Reason code name Explanation 535 ---------------- ----------------------------------- 536 INV-DEVICE-TYPE The server does not support the 537 requested device-type. 539 INV-NAME The resource-name or device-name 540 specified in the CONNECT or ASSOCIATE 541 command is not known to the server. 543 DEVICE-IN-USE The requested device-name is 544 already associated with another 545 session. 547 TYPE-NAME-ERROR The requested device-name or 548 resource-name is incompatible 549 with the requested device-type 550 (such as terminal/printer mismatch). 552 UNSUPPORTED-REQ The server is unable to satisfy 553 the type of request sent by the 554 client; e.g., a specific terminal 555 or printer was requested but the 556 server does not have any such pools of 557 device-names defined to it, or the 558 ASSOCIATE command was used but no 559 partner printers are defined to the 560 server. 562 INV-ASSOCIATE The client used the ASSOCIATE 563 command and either the device-type 564 is not a printer or the device-name 565 is not a terminal. 567 CONN-PARTNER The client used the CONNECT command 568 to request a specific printer but 569 the device-name requested is the 570 partner to some terminal. 572 UNKNOWN-ERROR Any other error in device type or 573 name processing has occurred. 575 The process of negotiating a device-type and device-name that 576 are acceptable to both client and server may entail several 577 iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT 578 commands. The client must make use of the reason-code 579 specified by the server in any DEVICE-TYPE REJECT command(s) to 580 minimize the amount of negotiation necessary. For example, if 581 the client initially requests that it be assigned a specific 582 terminal device-name via the CONNECT command, and the server 583 rejects the request with a reason-code of UNSUPPORTED-REQ, the 584 client must make no further specific terminal requests in the 585 negotiations. If at any point in the process either side 586 wishes to "bail out," it can simply send a WON'T (or DON'T) 587 TN3270E command to the other side. At this point both sides 588 are free to negotiate other Telnet options (including 589 traditional tn3270). 591 7.2 FUNCTIONS Negotiation 593 Once the DEVICE-TYPE negotiation has successfully completed 594 (i.e, when the client receives a DEVICE-TYPE IS command that is 595 acceptable), the client must initiate the FUNCTIONS negotiation 596 by sending the FUNCTIONS REQUEST command to the server. After 597 this initial REQUEST command, both sides are free to transmit 598 FUNCTIONS REQUEST and FUNCTIONS IS commands as needed. 600 7.2.1 Commands 602 The FUNCTIONS REQUEST command contains a list of the TN3270E 603 functions that the sender would like to see supported on this 604 session. All functions not in the list are to be considered 605 unsupported. The list is terminated by the IAC code that 606 precedes the SE command. Functions may appear in any order in 607 the list. 609 Upon receipt of a FUNCTIONS REQUEST command, the recipient has 610 two choices: 612 - it may respond in the positive (meaning it agrees to support 613 all functions in the list, and not to transmit any data 614 related to functions not in the list). To do this, it sends 615 the FUNCTIONS IS command with the function-list exactly as it 616 was received. At this point, FUNCTIONS negotiation has 617 successfully completed. 619 - it may respond in the negative by sending a FUNCTIONS 620 REQUEST command in which the function-list differs from the 621 one it received (and not simply in the order of appearance 622 of functions in the list; at least one function must have 623 been added to, or removed from, the list). 625 To avoid endlessly looping, both parties must not add to the 626 function-list it receives any function that it has previously 627 added and that the other side has removed. 629 The process of sending FUNCTIONS REQUEST commands back and 630 forth continues until one side receives a function-list it is 631 willing to live with. It uses the FUNCTIONS IS command to 632 accept the list, and, once this command is received by the 633 other side, all necessary negotiation has been completed. At 634 this point, 3270 data stream transmission can begin. 636 Note that it is possible that the function-list agreed to is 637 null; this is referred to as "basic TN3270E". See the section 638 entitled "Basic TN3270E" for more information. 640 If an impasse is reached during FUNCTIONS negotiation (for 641 example, if a client requested and was granted a DEVICE-TYPE 642 representing a printer, but refuses to accept either the 643 SCS-CTL-CODES or DATA-STREAM-CTL function), then the 644 "offended" party should terminate the negotiation by sending 645 an IAC DON'T (or WON'T) TN3270E. 647 7.2.2 List of TN3270E Functions 649 The following list briefly describes the 3270 functions that 650 may be negotiated in the function-list: 652 Function Name Description 653 ------------- ----------- 654 SCS-CTL-CODES (Printer sessions only). Allows the use 655 of the SNA Character Stream (SCS) and SCS 656 control codes on the session. SCS is 657 used with LU type 1 SNA sessions. 659 DATA-STREAM-CTL (Printer sessions only). Allows the use 660 of the standard 3270 data stream. This 661 corresponds to LU type 3 SNA sessions. 663 RESPONSES Provides support for positive and 664 negative response handling. Allows the 665 server to reflect to the client any and 666 all definite, exception, and no response 667 requests sent by the host application. 669 BIND-IMAGE Allows the server to send the SNA Bind 670 image and Unbind notification to the 671 client. 673 SYSREQ Allows the client and server to emulate 674 some (or all, depending on the server) of 675 the functions of the SYSREQ key in an SNA 676 environment. 678 See the section entitled "Details of Processing TN3270E 679 Functions" for a more detailed explanation of the meaning and 680 use of these functions. 682 If in the process of functions negotiation an unrecognized 683 function code is recieved, the recipient should simply remove 684 that function code from the list and continue normal functions 685 negotiation. 687 8. TN3270E Data Messages 689 3270 device communications are generally understood to be block 690 oriented in nature. That is, each partner buffers data until an 691 entire "message" has been built, at which point the data is sent to 692 the other side. The "outbound message" (from host to device) 693 consists of a 3270 command and a series of buffer orders, buffer 694 addresses, and data, while the "inbound message" contains only buffer 695 orders, addresses and data. The end of a message is understood to be 696 the last byte transmitted (note that this discussion disregards SNA 697 chaining). The Telnet EOR command is used to delimit these natural 698 blocks of 3270 data within the Telnet data stream. 700 In TN3270E, each 3270 message must be prefixed with a TN3270E header, 701 which consists of five bytes and whose format is defined below (see 702 the section entitled "The TN3270E Message Header"). A "data message" 703 in TN3270E therefore has the following construction: 705 707 It should be noted that it is possible that, for certain message 708 types, there is no data portion present. In this case, the TN3270E 709 data message consists of: 711 713 If either side wishes to transmit the decimal value 255 and have it 714 interpreted as data, it must "double" this byte. In other words, a 715 single occurrence of decimal 255 will be interpreted by the other 716 side as an IAC, while two successive bytes containing decimal 255 717 will be treated as one data byte with a value of decimal 255. 719 It is strongly recommended that Telnet commands (other than IAC IAC) 720 should be sent between TN3270E data messages, with no header and no 721 trailing IAC EOR. If a TN3270E data message containing either IAC IP 722 (to be interpreted as 3270 Attention) or IAC AO (to be interpreted as 723 SYSREQ) is received, the receiver should defer processing the command 724 until the 3270 data has been processed (see the appropriate sections 725 for discussion of 3270 Attention and SYSREQ). If a TN3270E data 726 message containing any other IAC-command sequence (other than IAC 727 IAC) is received, it is implementation dependent when the IAC-command 728 sequence will be processed, but it must be processed. The receiver 729 may process it immediately, which in effect causes it to be processed 730 as if it had been received before the current TN3270E data message, 731 or the processing may be deferred until after the current TN3270E 732 data message has been processed. It is because of this ambiguity 733 that the presence of Telnet commands within a TN3270E data message 734 (i.e., between the header and the trailing IAC EOR) is not 735 recommended; neither clients nor servers should send such data. 737 8.1 The TN3270E Message Header 739 As stated earlier, each data message in TN3270E must be prefixed 740 by a header, which consists of five bytes and is formatted as 741 follows: 743 ----------------------------------------------------------- 744 | DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | SEQ-NUMBER | 745 ----------------------------------------------------------- 746 1 byte 1 byte 1 byte 2 bytes 748 8.1.1 DATA-TYPE Field 750 The DATA-TYPE field indicates how the data portion of the 751 message is to be interpreted by the receiver. Possible values 752 for the DATA-TYPE field are: 754 Data-type Name Code Meaning 755 -------------- ---- --------------------------------- 756 3270-DATA 0x00 The data portion of the message 757 contains only the 3270 data stream. 759 SCS-DATA 0x01 The data portion of the message 760 contains SNA Character Stream data. 762 RESPONSE 0x02 The data portion of the message 763 constitutes device-status information 764 and the RESPONSE-FLAG field indicates 765 whether this is a positive or negative 766 response (see below). 768 BIND-IMAGE 0x03 The data portion of the message is 769 the SNA bind image from the session 770 established between the server and the 771 host application. 773 UNBIND 0x04 The data portion of the message is 774 an Unbind reason code. 776 NVT-DATA 0x05 The data portion of the message is to 777 be interpreted as NVT data. 779 REQUEST 0x06 There is no data portion present in 780 the message. Only the REQUEST-FLAG 781 field has any meaning. 783 SSCP-LU-DATA 0x07 The data portion of the message is 784 data from the SSCP-LU session. 786 PRINT-EOJ 0x08 There is no data portion present in 787 the message. This value can be sent 788 only by the server, and only on a 789 printer session. 791 8.1.2 REQUEST-FLAG Field 793 The REQUEST-FLAG field only has meaning when the DATA-TYPE 794 field has a value of REQUEST; otherwise, the REQUEST-FLAG field 795 must be ignored by the receiver and should be set to 0x00 by 796 the sender. Possible values for the REQUEST-FLAG field are: 798 Request-Flag Name Code Meaning 799 ----------------- ---- --------------------------------- 800 ERR-COND-CLEARED 0x00 The client sends this to the server 801 when some previously encountered 802 printer error condition has been 803 cleared. (See the section entitled 804 "The RESPONSES Function" below.) 806 8.1.3 RESPONSE-FLAG Field 808 The RESPONSE-FLAG field only has meaning for certain values of 809 the DATA-TYPE field. For DATA-TYPE field values of 3270-DATA 810 and SCS-DATA, the RESPONSE-FLAG is an indication of whether or 811 not the sender of the data expects to receive a response. In 812 this case the possible values of RESPONSE-FLAG are: 814 Response-Flag Name Code Meaning 815 ------------------ ---- --------------------------------- 816 NO-RESPONSE 0x00 The sender does not expect the 817 receiver to respond either 818 positively or negatively to this 819 message. The receiver must 820 therefore not send any response 821 to this data-message. 823 ERROR-RESPONSE 0x01 The sender only expects the 824 receiver to respond to this message 825 if some type of error occurred, in 826 which case a negative response must 827 be sent by the receiver. 829 ALWAYS-RESPONSE 0x02 The sender expects the receiver to 830 respond negatively if an error 831 occurs, or positively if no errors 832 occur. One or the other must 833 always be sent by the receiver. 835 For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is 836 an actual response to a previous data message (which must by 837 definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA 838 and a RESPONSE-FLAG value of either ERROR-RESPONSE or ALWAYS- 839 RESPONSE). In this case the possible values of RESPONSE-FLAG 840 are: 842 Response-Flag Name Code Meaning 843 ------------------ ---- --------------------------------- 844 POSITIVE-RESPONSE 0x00 The previous message was received 845 and executed successfully with 846 no errors. 848 NEGATIVE-RESPONSE 0x01 The previous message was received 849 but an error(s) occurred while 850 processing it. 852 Accompanying status information will be found in the data 853 portion of the message. 855 For any other values of the DATA-TYPE field, the RESPONSE-FLAG 856 field must be ignored by the receiver and should be set to 0x00 857 by the sender. 859 8.1.4 SEQ-NUMBER Field 861 The SEQ-NUMBER field is only used when the RESPONSES function 862 has been agreed to. It contains a 2 byte binary number, and is 863 used to correlate positive and negative responses to the data 864 messages for which they were intended. This field must be sent 865 in network byte order ("big endian"). If either byte contains 866 a 0xff, it should be doubled to 0xffff before sending and 867 stripped back to 0xff upon receipt; this is standard IAC 868 escaping. See the section entitled "The RESPONSES Function" 869 for further information on the use of the SEQ-NUMBER field. 870 When the RESPONSES function is not agreed to, this field should 871 always be set to 0x0000 by the sender and ignored by the 872 receiver. 874 9. Basic TN3270E 876 As has been stated earlier, whether or not the use of each of the 877 TN3270E functions is allowed on a session is negotiated when the 878 connection is established. It is possible that none of the functions 879 are agreed to (in this case, the function-list in the FUNCTIONS 880 REQUEST and FUNCTIONS IS commands is null). This mode of operation 881 is referred to as "basic TN3270E". Note that, since neither the 882 SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to, 883 basic TN3270E refers to terminal sessions only. 885 Basic TN3270E requires the support of only the following TN3270E 886 header values: 888 Header field Value 889 ------------ ----- 890 DATA-TYPE 3270-DATA 891 DATA-TYPE NVT-DATA 893 The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used in 894 basic TN3270E. 896 9.1 3270 Mode and NVT Mode 898 At any given time, a TN3270E connection can be considered to be 899 operating in either "3270 mode" or "NVT mode". In 3270 mode, each 900 party may send data messages with the DATA-TYPE flag set to 3270- 901 DATA; sending a DATA-TYPE flag set to NVT-DATA constitutes a 902 request to switch modes. In NVT mode, each party may send data 903 messages with the DATA-TYPE flag set to NVT-DATA; sending 3270- 904 DATA is a request to switch modes. The connection is initially in 905 3270 mode when TN3270E operation is successfully negotiated. When 906 a party receives a message with a DATA-TYPE different from the 907 mode it is operating in, the mode of operation for the connection 908 is switched. Switching modes results in the client performing the 909 equivalent of a 3270 Erase/Reset operation, as described in [5], 910 using the default partition (screen) size. The server cannot 911 assume the client preserves any attributes of the previous 912 environment across a mode switch. 914 Note that even when sending NVT-DATA, each side should buffer data 915 until an entire message is built (for the client, this would 916 normally mean until the user presses Enter). At that point, a 917 complete TN3270E data message should be built to transmit the NVT 918 data. 920 Typically, NVT data is used by a server to interact with the user 921 of a client. It allows the server to do this using a simple NVT 922 data stream, instead of requiring a 3270 data stream. An example 923 would be a server which displays a list of 3270 applications to 924 which it can connect the client. The server would use NVT data to 925 display the list and read the user's choice. Then the server 926 would connect to the application, and begin the exchange of 3270 927 data between the application and the client. 929 10. Details of Processing TN3270E Functions 931 Agreement by both parties to a specific function in the FUNCTIONS 932 REQUEST function-list implies agreement by each party to support a 933 related set of values in the TN3270E header. It also implies a 934 willingness to adhere to the rules governing the processing of data 935 messages with regard to the agreed upon function. Either party that 936 fails to accept header values associated either with agreed upon 937 functions or with basic TN3270E, or attempts to use header values 938 associated with a function that is not a part of basic TN3270E and 939 was not agreed upon, will be considered non-conforming and in 940 violation of the protocol. The following sections detail for each 941 TN3270E function the associated header values and processing rules. 943 10.1 The SCS-CTL-CODES Function 945 This function can only be supported on a 3270 printer session. 947 Agreement to support this function requires that the party support 948 the following TN3270E header values: 950 Header field Value 951 ------------ ----- 952 DATA-TYPE SCS-DATA 953 DATA-TYPE PRINT-EOJ 955 A client representing a printer device uses this function to 956 indicate its willingness to accept a data stream that includes SCS 957 control codes. For the purposes of NVT mode versus 3270 mode, 958 SCS-DATA must be treated exactly like 3270-DATA (i.e., it can 959 cause a switch from NVT mode to 3270 mode). 961 When a printer device-type has been negotiated, either the SCS- 962 CTL-CODES function or the DATA-STREAM-CTL function, or both, must 963 be negotiated. This enables the server to know when it should and 964 should not accept a session with a host application on behalf of 965 the client. If only the SCS-CTL-CODES function is agreed to, then 966 the server will not establish sessions with host applications that 967 would send 3270 data stream control. If both SCS-CTL-CODES and 968 DATA-STREAM-CTL are agreed to, then the server will establish 969 sessions both with host applications that would send SCS control 970 codes and with those that would send 3270 orders. 972 The server should send a TN3270E message with DATA-TYPE set to 973 PRINT-EOJ at the end of each print job to indicate to the client 974 that it may now take whatever action is appropriate for its 975 environment (e.g., close a disk or spool file, etc.). The server 976 may have multiple criteria for determining when it should send a 977 PRINT-EOJ, such as receipt of SNA End Bracket from the host 978 application, or expiration of a pre-defined timeout value. 980 10.2 The DATA-STREAM-CTL Function 982 This function can only be supported on a 3270 printer session. 984 Agreement to support this function requires that the party support 985 the following TN3270E header values: 987 Header field Value 988 ------------ ----- 989 DATA-TYPE 3270-DATA 990 DATA-TYPE PRINT-EOJ 992 A client representing a printer device uses this function to 993 indicate its willingness to accept a data stream that includes 994 3270 orders and attributes. 996 When a printer device-type has been negotiated, either the SCS- 997 CTL-CODES function or the DATA-STREAM-CTL function, or both, must 998 be negotiated. This enables the server to know when it should and 999 should not accept a session with a host application on behalf of 1000 the client. If only the DATA-STREAM-CTL function is agreed to, 1001 then the server will not establish sessions with host applications 1002 that would send SCS control codes in a data stream. If both SCS- 1003 CTL-CODES and DATA-STREAM-CTL are agreed to, then the server will 1004 establish sessions both with host applications that would send SCS 1005 control codes and with those that would send 3270 orders. 1007 The server should send a TN3270E message with DATA-TYPE set to 1008 PRINT-EOJ at the end of each print job to indicate to the client 1009 that it may now take whatever action is appropriate for its 1010 environment (e.g., close a disk or spool file, etc.). The server 1011 may have multiple criteria for determining when it should send a 1012 PRINT-EOJ, such as receipt of SNA End Bracket from the host 1013 application, or expiration of a pre-defined timeout value. 1015 10.3 The BIND-IMAGE Function 1017 This function can only be supported when the TN3270E server 1018 represents SNA terminals and printers. 1020 Agreement to support this function requires that the party support 1021 the following TN3270E header values: 1023 Header field Value 1024 ------------ ----- 1025 DATA-TYPE BIND-IMAGE 1026 DATA-TYPE UNBIND 1027 DATA-TYPE SSCP-LU-DATA 1029 When BIND-IMAGE is in effect, the server must inform the client 1030 when an SNA session has been established with a host application, 1031 and when such a session has been terminated. It uses DATA-TYPE 1032 values of BIND-IMAGE and UNBIND to convey this information. 1034 When establishing an SNA session on behalf of a client, the server 1035 will receive a Bind RU from the host application. It will also 1036 receive a Start Data Traffic RU. Once both of these have been 1037 responded to positively by the server, it must then inform the 1038 client of the presence of this session by sending it a data 1039 message with the DATA-TYPE flag set to BIND-IMAGE. The data 1040 portion of this message must contain the bind image exactly as it 1041 was received in the Bind RU that the server accepted on behalf of 1042 the client. The format and maximum length of this bind image is 1043 defined in [6]. 1045 When an SNA session between the server and a host application is 1046 terminated, the server must send a data message to the client 1047 with the DATA-TYPE flag set to UNBIND. If the server was notified 1048 of the session termination via an SNA Unbind RU, it should include 1049 the Unbind reason code in the data portion of the message it sends 1050 to the client. If the server itself requested the SNA session 1051 termination (for example, as part of SYSREQ key processing), it 1052 should set the data portion of the UNBIND message to 0x01, 1053 indicating "normal end of session". 1055 Another aspect of the BIND-IMAGE function alters the allowable 1056 DATA-TYPE flag values slightly from the behavior described in the 1057 section entitled "Basic TN3270E". When BIND-IMAGE is in effect, 1058 data messages with DATA-TYPE set to 3270-DATA or SCS-DATA are not 1059 allowed before the first BIND-IMAGE is received by the client; 1060 only SSCP-LU-DATA or NVT-DATA can be used to transmit user- 1061 oriented data. The same applies to data messages exchanged after 1062 an UNBIND is sent and before another BIND-IMAGE is received by the 1063 client. Once the client receives a BIND-IMAGE data message, the 1064 allowable DATA-TYPE values, in addition to SSCP-LU-DATA, now 1065 include 3270-DATA and/or SCS-DATA, depending on whether a terminal 1066 or printer device-type was negotiated, and whether a printer 1067 client agreed to DATA-STREAM-CTL or SCS-CTL-CODES, or both. (See 1068 the section entitled "The SYSREQ Function" for further discussion 1069 of the SSCP-LU session in an SNA environment.) 1071 10.4 The RESPONSES Function 1073 This function can be supported for both terminal and printer 1074 sessions connected to both SNA and non-SNA servers. 1076 Agreement to support this function requires that the party support 1077 the following TN3270E header values: 1079 Header field Value 1080 ------------ ----- 1081 DATA-TYPE RESPONSE 1082 DATA-TYPE REQUEST 1083 RESPONSE-FLAG -all values- 1084 REQUEST-FLAG ERR-COND-CLEARED 1085 SEQ-NUMBER binary values from 0-32767 1087 Whenever a data message is sent with a DATA-TYPE of either SCS- 1088 DATA or 3270-DATA, the sender must set the RESPONSE-FLAG field to 1089 either NO-RESPONSE, ERROR-RESPONSE, or ALWAYS-RESPONSE. It is 1090 anticipated that the client side will normally set RESPONSE-FLAG 1091 to NO-RESPONSE. The server, if it represents an SNA device, 1092 should set RESPONSE-FLAG to reflect the response value set in the 1093 RH of the RU that generated this data message - Definite Response 1094 resulting in a RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception 1095 Response resulting in ERROR-RESPONSE being set, and No Response 1096 causing a setting of NO-RESPONSE. A non-SNA server should set 1097 RESPONSE-FLAG to ERROR-RESPONSE. 1099 In addition, the sender must keep a count of the messages with a 1100 DATA-TYPE of 3270-DATA or SCS-DATA that it sends on a given 1101 TN3270E session. This counter should start at zero for the first 1102 such message, and be incremented by one for each subsequent 1103 message. Note that this counter is independent of any SNA 1104 sequence numbers, and should not be reset to zero as a result of 1105 Bind or Unbind. If the counter reaches the maximum of 32767, it 1106 should be restarted at zero. The sender must place this value in 1107 the SEQ-NUMBER field of the TN3270E header before it sends the 1108 message. Note that the SEQ-NUMBER field must be set regardless of 1109 the value of the RESPONSE-FLAG field. 1111 10.4.1 Response Messages 1113 Whenever a data message with a DATA-TYPE of either SCS-DATA or 1114 3270-DATA is received, the receiver must attempt to process the 1115 data in the data portion of the message, then determine whether 1116 or not it should send a data message with a DATA-TYPE of 1117 RESPONSE. If the data message it has just processed had a 1118 RESPONSE-FLAG value of NO-RESPONSE, or if it had a value of 1119 ERROR-RESPONSE and there were no errors encountered while 1120 processing the data, then no RESPONSE type message should be 1121 sent. Otherwise, a data message should be sent in which the 1122 header DATA-TYPE field is set to RESPONSE, and in which the 1123 SEQ-NUMBER field is a copy of the SEQ-NUMBER field from the 1124 message to which this response corresponds. The RESPONSE-FLAG 1125 field in this header must have a value of either POSITIVE- 1126 RESPONSE or NEGATIVE-RESPONSE. A POSITIVE-RESPONSE should be 1127 sent if the previously processed message's header specified 1128 ALWAYS-RESPONSE and no errors were encountered in processing 1129 the data. A NEGATIVE-RESPONSE should be sent when 1131 1) the previously processed message specified ERROR-RESPONSE 1132 or ALWAYS-RESPONSE and 1134 2) some kind of error occurred while processing the data. 1136 Normally only the client will be constructing and sending these 1137 RESPONSE messages. A negative response sent by the client to 1138 the server is the equivalent of a Unit Check Status [7]. All 1139 references to device status and sense codes in this section 1140 rely on [7]. 1142 The data portion of a RESPONSE message must consist of one byte 1143 of binary data. The value of this byte gives a more detailed 1144 account of the results of having processed the previously 1145 received data message. The possible values for this byte are: 1147 For a RESPONSE-FLAG value of POSITIVE-RESPONSE - 1149 Value Meaning 1150 ----- ------- 1151 0x00 Successful completion (when sent by the client, 1152 this is equivalent to "Device End"). 1154 For a RESPONSE-FLAG value of NEGATIVE-RESPONSE - 1156 Value Meaning 1157 ----- ------- 1158 0x00 An invalid 3270 command was received 1159 (equivalent to "Command Reject"). 1161 0x01 Printer is not ready (equivalent to 1162 "Intervention Required"). 1164 0x02 An illegal 3270 buffer address or order 1165 sequence was received (equivalent to 1166 "Operation Check"). 1168 0x03 Printer is powered off or not connected 1169 (equivalent to "Component Disconnected"). 1171 When the server receives any of the above responses, it should 1172 pass along the appropriate information to the host application. 1173 The appropriate information is determined by whether the server 1174 represents an SNA or a non-SNA device. 1176 An SNA server should pass along a POSITIVE-RESPONSE from the 1177 client as an SNA positive Response Unit to the host 1178 application. It should translate a NEGATIVE-RESPONSE from the 1179 client into an SNA negative Response Unit in which the Sense 1180 Data Indicator bit is on and which contains one of the 1181 following sense codes: 1183 RESPONSE-FLAG Equivalent SNA Sense Code 1184 ------------- ---------- -------------- 1185 0x00 Command Reject 0x10030000 1187 0x01 Intervention Required 0x08020000 1189 0x02 Operation Check 0x10050000 1191 0x03 Component Disconnected 0x08310000 1193 A non-SNA server should pass along a POSITIVE-RESPONSE from the 1194 client by setting the Device End Status bit on. It should 1195 reflect a NEGATIVE-RESPONSE from the client by setting the Unit 1196 Check Status Bit on, and setting either the Command Reject, 1197 Intervention Required, or Operation Check Sense bit on when 1198 responding to the Sense command. 1200 In the case of Intervention Required or Component Disconnected 1201 being passed by the server to the host application, the host 1202 would normally refrain from sending any further data to the 1203 printer. If and when the error condition at the client has 1204 been resolved, the client must send to the server a data 1205 message whose header DATA-TYPE field is set to REQUEST, and 1206 whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that this 1207 message has no data portion. Upon receipt of this message, the 1208 server should pass along the appropriate information to the 1209 host application so that it may resume sending printer output. 1210 Again, the form of this information depends on whether the 1211 server represents an SNA or a non-SNA device. 1213 An SNA server should reflect an ERR-COND-CLEARED to the host 1214 application by sending an SNA LUSTAT RU with one of the 1215 following sense codes: 1217 - if the previous error condition was an Intervention 1218 Required, the server should send sense code 0x00010000 1220 - if the previous error condition was Component 1221 Disconnected, the server should send sense code 0x082B0000 1223 A non-SNA server should set the corresponding bits in the 1224 Ending Status and Sense Condition bytes. 1226 10.5 The SYSREQ Function 1228 This function can only be supported when the TN3270E server 1229 represents SNA devices. 1231 Agreement to support this function requires that the party support 1232 the following TN3270E header values: 1234 Header field Value 1235 ------------ ----- 1236 DATA-TYPE SSCP-LU-DATA 1238 The 3270 SYSREQ key can be useful in an SNA environment when the 1239 ATTN key is not sufficient to terminate a process. (See the 1240 section entitled "The 3270 ATTN Key" for more information.) 1242 10.5.1 Background 1244 In SNA, there is a session between the host application (the 1245 PLU, or Primary Logical Unit) and the TN3270E server 1246 representing the client (the SLU, or Secondary Logical Unit). 1247 This is referred to as the PLU-SLU session, and it is the one 1248 on which normal communications flow. There is also a session 1249 between the host telecommunications access method (the SSCP, or 1250 System Services Control Point) and the SLU, and it is referred 1251 to as the SSCP-LU session. This session is used to carry 1252 various control information and is normally transparent to the 1253 user; normal 3270 data stream orders are not allowed in this 1254 data. For more information, refer to [7]. 1256 The terminal display and keyboard are usually "owned" by the 1257 PLU-SLU session, meaning any data the user types is sent to the 1258 host application. The SYSREQ key is used to toggle ownership 1259 of the keyboard and display between the PLU-SLU session and the 1260 SSCP-LU session. In other words, the user is able to press 1261 SYSREQ and then communicate directly with the host SSCP. The 1262 user may then enter any valid Unformatted Systems Services 1263 commands, which are defined in the USS table associated with 1264 the SLU. The most common USS command users employ is "LOGOFF," 1265 which requests that the SSCP immediately terminate the PLU-SLU 1266 session. The usual reason for requesting such an action is 1267 that the host application (the PLU) has stopped responding 1268 altogether. 1270 Whenever the keyboard and display are owned by the SSCP-LU 1271 session, no data is allowed to flow in either direction on the 1272 PLU-SLU session. Once "in" the SSCP-LU session, the user may 1273 decide to switch back to the PLU-SLU session by again pressing 1274 the SYSREQ key. 1276 10.5.2 TN3270E Implementation of SYSREQ 1278 The design of some TN3270E servers allows them to fully support 1279 the SYSREQ key because they are allowed to send USS commands on 1280 the SSCP-LU session. Other TN3270E servers operate in an 1281 environment which does not allow them to send USS commands to 1282 the SSCP; this makes full support of the SYSREQ key impossible. 1283 For such servers, TN3270E provides for emulation of a minimal 1284 subset of functions, namely, for the sequence of pressing 1285 SYSREQ and typing LOGOFF that many users employ to immediately 1286 terminate the PLU-SLU session. 1288 The Telnet Abort Output (AO) command is the mechanism used to 1289 implement SYSREQ key support in TN3270E because, in a real SNA 1290 session, once the user presses the SYSREQ key, the host 1291 application is prevented from sending any more output to the 1292 terminal (unless the user presses SYSREQ a second time), but 1293 the user's process continues to execute. 1295 In order to implement SYSREQ key support, TN3270E clients that 1296 have agreed to the SYSREQ function should provide a key (or 1297 combination of keys) that is identified as mapping to the 3270 1298 SYSREQ key. When the user presses this key(s), the client 1299 should transmit a Telnet AO command to the server. 1301 Upon receipt of the AO command, a TN3270E server that has 1302 agreed to the SYSREQ function should enter what will be loosely 1303 termed "suspended mode" for the connection. If a server that 1304 has not agreed to the SYSREQ function receives an AO command, 1305 it should simply ignore it. Any attempt by the host 1306 application to send data to the client while the connection is 1307 "suspended" should be responded to by the server with a 1308 negative response, sense code 0x082D, indicating an "LU Busy" 1309 condition. The server should not transmit anything to the 1310 client on behalf of the host application. While the connection 1311 is "suspended," any data messages exchanged between the client 1312 and server should have the DATA-TYPE flag set to SSCP-LU-DATA; 1313 the data stream will be as defined in [7], specifically the 1314 section entitled "Operation in SSCP-SLU Session." 1315 At this point, the behavior of the server depends upon whether 1316 or not it is allowed to send USS commands on the SSCP-LU 1317 session. Servers that have this ability should simply act as a 1318 vehicle for passing USS commands and responses between the 1319 client and the SSCP. 1321 Servers that are not allowed to send USS commands on the SSCP- 1322 LU session should behave as follows: 1324 - if the user transmits the string LOGOFF (upper or lower case), 1325 the server should send an Unbind SNA RU to the host 1326 application. This will result in termination of the PLU-SLU 1327 session. If the BIND-IMAGE function was agreed upon, then 1328 the server should also send a data message to the client with 1329 the DATA-TYPE flag set to UNBIND and the data portion set to 1330 0x01. 1332 - if the user transmits anything other than LOGOFF, the server 1333 should respond with the string "COMMAND UNRECOGNIZED" to the 1334 client. The server should not send anything to the host 1335 application on behalf of the client. 1337 Regardless of which kind of server is present (i.e., whether or 1338 not it may send USS commands on the SSCP-LU session), while the 1339 connection is suspended, the user may press the "SYSREQ" key 1340 again. This will result in the transmission of another AO to 1341 the server. The server should then send to the host 1342 application an LUSTAT RU with a value of 0x082B indicating 1343 "presentation space integrity lost". The server will then 1344 "un-suspend" the Telnet connection to the client, meaning it 1345 will allow the host application to once again send data to the 1346 client. 1348 11. The 3270 ATTN Key 1350 The 3270 ATTN key is interpreted by many host applications in an SNA 1351 environment as an indication that the user wishes to interrupt the 1352 execution of the current process. The Telnet Interrupt Process (IP) 1353 command was defined expressly for such a purpose, so it is used to 1354 implement support for the 3270 ATTN key. This requires two things: 1356 - TN3270E clients should provide as part of their keyboard 1357 mapping a single key or a combination of keys that map to 1358 the 3270 ATTN key. When the user presses this key(s), the 1359 client should transmit a Telnet IP command to the server. 1361 - TN3270E servers should translate the IP command received from 1362 a TN3270E client into the appropriate form and pass it along 1363 to the host application as an ATTN key. In other words, the 1364 server representing an SLU in an SNA session should send 1365 a SIGNAL RU to the host application. 1367 The ATTN key is not supported in a non-SNA environment; therefore, a 1368 TN3270E server representing non-SNA 3270 devices should ignore any 1369 Telnet IP commands it receives from a client. 1371 12. 3270 Structured Fields 1373 3270 structured fields provide a much wider range of features than 1374 "old-style" 3270 data, such as support for graphics, partitions and 1375 IPDS printer data streams. It would be unreasonable to expect all 1376 TN3270E clients to support all possible structured field functions, 1377 yet there must be a mechanism by which those clients that are capable 1378 of supporting some or all structured field functions can indicate 1379 their wishes. 1381 The design of 3270 structured fields provides a convenient means to 1382 convey the level of support (including no support) for the various 1383 structured field functions. This mechanism is the Read Partition 1384 Query command, which is sent from the host application to the device. 1385 The device responds with a Query Reply structured field(s) listing 1386 which, if any, structured field functions it supports. 1388 The Query Reply is also used to indicate some device capabilities 1389 which do not require the use of structured fields, such as extended 1390 color support and extended highlighting capability. Most host 1391 applications will use Read Partition Query to precisely determine a 1392 device's capabilities when there has been some indication that the 1393 device supports the "extended data stream". 1395 Therefore, all TN3270E clients that negotiate a terminal device-type 1396 that contains a "-E" suffix, the DYNAMIC terminal type, or a printer 1397 device-type, must be able to respond to a Read Partition Query 1398 command. Note that these clients must support both the Read 1399 Partition Query (Type 02), and all forms of the Read Partition Query 1400 List (Type 03). 1402 13. Implementation Guidelines 1404 13.1 3270 Data Stream Notes 1406 Implementors of TN3270E clients should note that the command codes 1407 for the various 3270 Read and Write commands have different values 1408 depending on how the server is connected to the host (local versus 1409 remote, SNA versus non-SNA). Clients should be coded to check for 1410 the various possible values if they wish to be compatible with the 1411 widest range of servers. See [7] for further details. 1413 13.2 Negotiation of the TN3270E Telnet Option 1415 Since TN3270E is a Telnet Option governed by [8], both client and 1416 server are free to attempt to initiate negotiation of TN3270E by 1417 sending a DO TN3270E command. However, just as is usually the 1418 case with the Telnet DO TERMINAL-TYPE, it is anticipated that the 1419 server will normally be the one sending the DO TN3270E, and the 1420 client will be responding with a WILL or a WON'T TN3270E. 1422 13.3 A "Keep-alive" Mechanism 1424 In many environments, it is very helpful to have in place a 1425 mechanism that allows timely notification of the loss of a 3270 1426 session. TN3270E does not require that any form of keep-alive 1427 mechanism be employed by either clients or servers, but 1428 implementors wishing to support such a mechanism should consider 1429 the following guidelines. 1431 There are at least three possible means of providing a keep-alive 1432 mechanism in TN3270E: the TCP Keepalive, the Telnet IAC NOP 1433 command [8], and the Telnet DO TIMING-MARK option [9]. Each 1434 method has its advantages and disadvantages. It is recommended 1435 that TN3270E clients and servers that support keep-alives should 1436 support all three methods, and that both sides should always 1437 respond to TIMING-MARKs. 1439 Note that both clients and servers could be configured to 1440 "actively" implement keep-alives. That is, both sides could send 1441 a TIMING-MARK or a NOP or issue a TCP Keepalive in order to 1442 determine whether or not the partner is still alive. 1443 Alternatively, network administrators may wish to configure only 1444 one side to send keep-alives; in this case, the other side would 1445 be a "passive" participant which simply responds to the 1446 keep-alives it receives. 1448 Implementors who want their code to be capable of being an 1449 "active" keep-alive participant should make their client or server 1450 configurable so that administrators can set which, if any, keep- 1451 alive mechanism should be employed, and how often it should be 1452 used. 1454 Upon failure of a session on which keep-alives are used, both 1455 parties should make the proper notifications. A client should 1456 give the user some indication of the failure, such as an error 1457 code in the Operator Information Area of the screen. A server 1458 should notify the host application that the session has been 1459 terminated, for example by sending an UNBIND with type CLEANUP in 1460 an SNA environment. 1462 13.4 Examples 1464 The following example shows a TN3270E-capable server and a 1465 traditional tn3270 client establishing a connection: 1467 Server: IAC DO TN3270E 1468 Client: IAC WON'T TN3270E 1469 Server: IAC DO TERMINAL-TYPE 1470 Client: IAC WILL TERMINAL-TYPE 1471 Server: IAC SB TERMINAL-TYPE SEND IAC SE 1472 Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE 1473 Server: IAC DO EOR IAC WILL EOR 1474 Client: IAC WILL EOR IAC DO EOR 1475 Server: IAC DO BINARY IAC WILL BINARY 1476 Client: IAC WILL BINARY IAC DO BINARY 1477 (3270 data stream is exchanged) 1479 The following example shows a TN3270E-capable server and a 1480 TN3270E-capable client establishing a generic pool (non-specific) 1481 terminal session: 1483 Server: IAC DO TN3270E 1484 Client: IAC WILL TN3270E 1485 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1486 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE 1487 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT 1488 anyterm IAC SE 1489 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE 1490 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE 1491 (3270 data stream is exchanged) 1493 The following example shows a TN3270E-capable server and a 1494 TN3270E-capable client establishing a terminal session where the 1495 client requests a specific device-name: 1497 Server: IAC DO TN3270E 1498 Client: IAC WILL TN3270E 1499 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1500 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E 1501 CONNECT myterm IAC SE 1502 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT 1503 myterm IAC SE 1504 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES 1505 BIND-IMAGE IAC SE 1506 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES BIND-IMAGE 1507 IAC SE 1508 (3270 data stream is exchanged) 1510 The following example shows a TN3270E-capable server and a 1511 TN3270E-capable client establishing a terminal session where the 1512 client requests a resource-name and is returned a device-name 1513 chosen by the server: 1515 Server: IAC DO TN3270E 1516 Client: IAC WILL TN3270E 1517 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1518 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E 1519 CONNECT pool1 IAC SE 1521 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT 1522 term0013 IAC SE 1523 Client: IAC SB TN3270E FUNCTIONS REQUEST BIND-IMAGE IAC SE 1524 Server: IAC SB TN3270E FUNCTIONS IS BIND-IMAGE IAC SE 1525 (3270 data stream is exchanged) 1527 The following example shows a TN3270E-capable server and a 1528 TN3270E-capable client attempting to establish a terminal session; 1529 multiple attempts are necessary because the device-name initially 1530 requested by the client is already in use: 1532 Server: IAC DO TN3270E 1533 Client: IAC WILL TN3270E 1534 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1535 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 1536 CONNECT myterm IAC SE 1537 Server: IAC SB TN3270E DEVICE-TYPE REJECT REASON 1538 DEVICE-IN-USE IAC SE 1539 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 1540 CONNECT herterm IAC SE 1541 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT 1542 herterm IAC SE 1543 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE 1544 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE 1545 (3270 data stream is exchanged) 1547 The following example shows a TN3270E-capable server and a 1548 TN3270E-capable client establishing a printer session where the 1549 client requests a specific device-name, and where some amount of 1550 3270 function negotiation is required before an agreement is 1551 reached: 1553 Server: IAC DO TN3270E 1554 Client: IAC WILL TN3270E 1555 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1556 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT 1557 myprt IAC SE 1558 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT 1559 myprt IAC SE 1560 Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC 1561 Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL 1562 RESPONSES IAC SE 1563 Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC 1564 Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE 1565 (3270 data stream is exchanged) 1567 The following example shows a TN3270E-capable server and a 1568 TN3270E-capable client establishing first a specific terminal 1569 session, then a printer session where the "partner" printer for 1570 the assigned terminal is requested: 1572 Server: IAC DO TN3270E 1573 Client: IAC WILL TN3270E 1574 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1575 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT 1576 termxyz IAC SE 1577 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT 1578 termxyz IAC SE 1579 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE 1580 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE 1581 (3270 data stream is exchanged) 1582 . . 1583 . . 1584 (user decides to request a printer session, 1585 so client again connects to Telnet port on server) 1586 Server: IAC DO TN3270E 1587 Client: IAC WILL TN3270E 1588 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1589 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 1590 ASSOCIATE termxyz IAC SE 1591 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT 1592 termxyz's-prt IAC SE 1593 Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES 1594 RESPONSES IAC SE 1595 Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES 1596 IAC SE 1597 (3270 data stream is exchanged) 1599 The following example shows a TN3270E-capable server and a 1600 TN3270E-capable client establishing first a terminal session where 1601 a resource-name was requested and a server chosen device-name was 1602 returned, then a printer session where the "partner" printer for 1603 the assigned terminal is requested: 1605 Server: IAC DO TN3270E 1606 Client: IAC WILL TN3270E 1607 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1608 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT 1609 poolxyz IAC SE 1610 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT 1611 terma IAC SE 1612 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE 1613 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE 1614 (3270 data stream is exchanged) 1615 . . 1616 . . 1617 (user decides to request a printer session, 1618 so client again connects to Telnet port on server) 1619 Server: IAC DO TN3270E 1620 Client: IAC WILL TN3270E 1621 Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE 1622 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 1623 ASSOCIATE terma IAC SE 1624 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT 1625 terma's-prt IAC SE 1626 Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES 1627 RESPONSES IAC SE 1628 Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES 1629 IAC SE 1630 (3270 data stream is exchanged) 1632 14. Security Considerations 1634 Security issues are not addressed directly in this document. 1635 This is recognized as an important shortcoming in TN3270E as 1636 defined here, and work is continuing in the IETF TN3270E Working 1637 Group to address this shortcoming. Of particular importance is 1638 the lack of the ability to authenticate a client's "right" to 1639 be granted a specific device-name, especially in the case of a 1640 printer. 1642 In the meantime, implementation specific solutions are possible 1643 using, for example, Kerberos. 1645 15. References 1647 [1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM 1648 Corporation, January 1988. 1650 [2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP 1651 Software, Inc., February 1989. 1653 [3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD 1654 27, RFC 856, USC/Information Sciences Institute, May 1983. 1656 [4] Postel, J., "Telnet End of Record Option", RFC 885, USC/ 1657 Information Sciences Institute, December 1983. 1659 [5] "3270 Information Display System - Data Stream Programmer's 1660 Reference", publication number GA24-0059, IBM Corporation. 1662 [6] "SNA Formats", publication number GA27-3136, IBM Corporation. 1664 [7] "3174 Establishment Controller Functional Description", 1665 publication number GA23-0218, IBM Corporation. 1667 [8] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 1668 8, RFC 854, USC/Information Sciences Institute, May 1983. 1670 [9] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31, 1671 RFC 860, USC/Information Sciences Institute, May 1983. 1673 [10] J. Penner, "TN3270 Current Practices", RFC 1576, DCA Inc., 1674 January, 1994. 1676 16. Author's Note 1678 Portions of this document were drawn from the following sources: 1680 - A White Paper written by Owen Reddecliffe, WRQ Corporation, 1681 October 1991. 1683 - Experimental work on the part of Cleve Graves and Michelle 1684 Angel, OpenConnect Systems, 1992 - 1993. 1686 - Discussions at the 1993 IETF meetings. 1688 - Discussions on the "TN3270E" list, 1993-94 and 1997. 1690 17. Author's Address 1692 Bill Kelly 1693 Division of University Computing 1694 144 Parker Hall 1695 Auburn University, AL 36849 1697 Phone: (334) 844-4512 1698 EMail: kellywh@mail.auburn.edu