idnits 2.17.1 draft-ietf-tn3270e-extensions-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 a Security Considerations 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 is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 414: '...he BID is "Forced" and the client MUST...' RFC 2119 keyword, line 456: '... MUST return positive response to th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 17, 2002) is 8045 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) -- Missing reference section? '1' on line 527 looks like a reference -- Missing reference section? '2' on line 529 looks like a reference -- Missing reference section? '3' on line 530 looks like a reference -- Missing reference section? '4' on line 531 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TN3270E Working Group G. Pullen 2 Internet-Draft: Alcatel USA 3 Extends: RFC 2355 M. Williams 4 Expiration Date: October 2002 S2 Systems 5 April 17, 2002 7 TN3270E Functional Extensions 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with 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 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999, 2000, 2001, 2002). All 34 Rights Reserved. 36 Abstract 38 This draft addresses issues and implementation problems defined and 39 discussed at the TN3270E/TN5250E Interoperability Events. It does 40 not replace the current TN3270 Enhancements protocol. It describes 41 functional extensions to the TN3270E protocol. The TN3270E function 42 negotiation mechanism is used to allow the server and client to 43 determine which, if any, of these functions will be supported during 44 a session. This preserves backward compatibility between clients 45 and servers that do not support these features. 47 Among the issues to be address by this draft are SNA/TN3270E 48 Contention state resolution and SNA Sense Code support. 50 1. Table of Contents 52 1. Table of Contents . . . . . . . . . . . . . . . . . . . 2 53 2. Negotiated Function Codes . . . . . . . . . . . . . . . 3 54 3. Negotiated Function Example . . . . . . . . . . . . . . 3 55 4. Contention Resolution Function . . . . . . . . . . . . . 4 56 4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . 4 57 4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . 4 58 4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . 4 59 4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . 5 60 4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . 5 61 4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . 6 62 4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . 7 63 4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . 8 64 4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . 9 65 5. SNA Sense Code Function . . . . . . . . . . . . . . . . 12 66 6. References . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. Term Definitions . . . . . . . . . . . . . . . . . . . . 13 68 8. Abbreviations . . . . . . . . . . . . . . . . . . . . . 14 69 9. Conventions . . . . . . . . . . . . . . . . . . . . . . 14 70 10. Author's Note . . . . . . . . . . . . . . . . . . . . . 14 71 11. Change Log . . . . . . . . . . . . . . . . . . . . . . 14 72 12. Author's Address . . . . . . . . . . . . . . . . . . . . 15 74 2. Negotiated Function Codes 76 To maintain backward compatibility with clients and servers that do 77 not support the extended TN3270E functions all new functionality 78 will be negotiated. The current TN3270E function negotiation rules 79 apply. Either side may request one or more of the extended 80 functions by adding them to the function code list during TN3270E 81 function negotiations. Either side may reject the function by 82 removing it from the function list. 84 The extended TN3270E function negotiation codes are defined as: 86 CONTENTION-RESOLUTION 5 87 SNA-SENSE 7 89 3. Negotiated Function Example 91 The SNA-SENSE function support is enabled by the negotiation below: 93 Server: IAC DO TN3270E 94 Client: IAC WILL TN3270E 95 . . . 96 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 97 Server: IAC SB TN3270E FUNCTIONS IS ... SNA-SENSE IAC SE 99 Support is disabled by the negotiation below (the server does not 100 support the SNA-SENSE function): 102 Server: IAC DO TN3270E 103 Client: IAC WILL TN3270E 104 . . . 105 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 106 Server: IAC SB TN3270E FUNCTIONS REQUEST ... IAC SE 107 Client: IAC SB TN3270E FUNCTIONS IS ... IAC SE 109 4. Contention Resolution Function 111 This function addresses shortcomings in the current TN3270E (RFC 112 2355) specification that stem from the fact that SNA is a 113 send/receive state oriented protocol, while TN3270E is relatively 114 state free. The following subsections define the problems to be 115 addressed and the methods to resolve those issues. 117 4.1 Keyboard Restore Problem 119 The Keyboard Restore problem concerns uncertainty over when the 120 client can send data to the TN3270E server. TN3270E provides for an 121 End-Of-Record (EOR) mechanism, which allows the client to determine 122 where the boundary is between 3270 data stream commands. The server 123 sends EOR whenever it sends data to the client for which the LIC 124 (Last-In-Chain) indicator was set. Clients have no choice but to 125 interpret the presence of EOR as an indication that it is okay to go 126 ahead and send data back to the host (providing the 3270 data-stream 127 has restored the keyboard). Since it is not uncommon for the Server 128 to receive a LIC from the host with no CDI (Change Direction 129 Indicator) set, a serious problem is created where the client will 130 send data to the server when it does not own the send state. 132 The solution is for the server to provide the client with an 133 indication that it may send data. The Send Data Indicator (SDI) 134 mechanism will be discussed later in this document. 136 4.2 Implied Keyboard Restore Problem 138 The Implied Keyboard Restore problem occurs when an application 139 never explicitly sets the keyboard restore bit of the WCC byte in 140 any of the 3270 data streams during a bracket. In SNA, EB is 141 considered an "implied" keyboard restore in this case. However, 142 since TN clients are not aware of the bracket or direction state the 143 client is not aware that it is allowed to send data and often hangs 144 in X-CLOCK state. 146 The solution for this problem is for the server to detect the 147 implied keyboard restore condition and send the Keyboard Restore 148 Indicator (KRI) flag to inform the client that its keyboard is 149 unlocked (ready state). 151 4.3 BID Problem 153 In SNA, when a session is in the BETB (Between Bracket), the Primary 154 LU (PLU), or host, may bid for the bracket by either sending an 155 explicit or implicit BID. The Secondary LU (SLU), or terminal, 156 processes the BID, either granting the bracket to the host or 157 rejecting the request. Having granted the bracket the SLU must 158 enter the X-CLOCK (Time) input inhibited state. 160 An implicit BID occurs when the session is BETB and the host sends a 161 message to the SLU with Begin Bracket (BB) indicated. No BID 162 actually flows but is implied. The SLU may accept or reject as if a 163 BID had been sent. 165 In the TN3270 world, there is no mechanism for including the client 166 in the BID process. The server must process the BID on the client's 167 behalf, without the ability to request the client yield the send 168 state. This leads to a variety of problems when the client attempts 169 to send data inbound after the server has sent positive response to 170 a BID from the host. These problems include hung or lost sessions, 171 lost data, or SNA or host application error messages, depending on 172 data flow, timing, and how the server handles the BID process. 174 This problem can be addressed by allowing the BID to propagate to 175 the client. When the server receives a valid BID (implicit or 176 explicit) from the host (i.e. one that occurs in the BETB state) it 177 will forward it to the client. The client will respond either 178 positively or negatively. Having granted the BID (positive 179 response), the client enters the X-CLOCK input inhibited state until 180 the session reenters contention state. 182 4.4 Signal Problem 184 The Signal problem occurs when the PLU sends a Signal in order to 185 force the SLU to yield direction. For example, when the secondary 186 has rejected a BID and the host needs to override it. The BID 187 reject may occur when the user types some data (perhaps an 188 unintentional depression of the space bar) and does not press an AID 189 key. The SNA architecture provides that the primary (host) can send 190 a Signal. The secondary should reply with a positive response, send 191 a null RU with Change Direction to yield direction (and Begin 192 Bracket if appropriate), and enter send inhibit state. 194 With TN3270 there is no way for the server to force the client to 195 yield the send state. 197 4.5 CONTENTION-RESOLUTION Implementation 199 This section defines a new negotiated TN3270E function called 200 CONTENTION-RESOLUTION. Support of this function implies that both 201 the client and the server are able to handle the SDI, KRI and Signal 202 header flags and the BID data type as defined in this specification. 204 This function is intended for SNA TN3270E environments only. 205 Non-SNA server implementations should ALWAYS disable this function 206 during TN3270E function negotiations. 208 When the CONTENTION-RESOLUTION function is supported, the 209 REQUEST-FLAG header field is interpreted as a bit mask, instead of a 210 byte value, to allow the field to be used for Send Data, Keyboard 211 Restore and Signal indicators. 213 4.5.1 Send Data Indicator (SDI) 215 To use the Send Data Indicator the CONTENTION-RESOLUTION function 216 must be supported by and agreed upon by both the server and client 217 during TN3270E function negotiations. SDI is only valid for TN3270E 218 terminals in PLU-SLU session (3270-DATA type). SDI is not used for 219 SSCP-LU mode to avoid the overhead of the server having to BID to 220 send asynchronous SSCP-LU-DATA records to the client. 222 SDI is meaningful only when sent by the server. It is sent in the 223 REQUEST-FLAG field of the TN3270E header. The SDI bit mask is: 225 SEND-DATA-MASK 0x01 227 A bit value of 1 (true) indicates to the client that it holds the 228 send state. A bit value of 0 (false) indicates the server (and host 229 by extension) holds the send state. 231 In SNA LU-LU session, the server sends SDI when the host 232 relinquishes send state with either the CDI or the EBI set in the 233 SNA RU header. 235 It is valid for the server to send a null 3270-DATA message (TN3270E 236 header and EOR, no data) to indicate the send state to the client. 237 This allows the server and client to handle a NULL RU containing EBI 238 or CDI received from the host. 240 The server ignores SDI in messages from the client and processes any 241 data as usual depending on data type. 243 When SDI is received by the client and the current TN3270E message 244 has been processed (upon receipt of EOR) the client may send data to 245 the server. If RESPONSES have been negotiated, the client must send 246 RESPONSES to the server regardless of the send state. Upon receipt 247 of SDI, the client must send all pending RESPONSE messages before 248 sending any keyboard input to the server. 250 SDI is not a replacement for the 3270 data stream WCC Keyboard 251 Restore bit. The client must track the 3270 WCC Keyboard Restore 252 flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to determine 253 whether or not it can start sending data to the server. If keyboard 254 restore (WCC or KRI) is received, the keyboard input must still be 255 buffered until the SDI is received. 257 The client may send an ATTN key (IAC IP) regardless of the keyboard 258 State, including input inhibited state. ATTN causes the server to 259 send a SIGNAL to the host requesting Change Direction. This may 260 allow the user to recover from a direction state timing or 261 synchronization problem (i.e. server neglected to send SDI). The 262 client should avoid subsequent ATTN keys until it receives direction 263 from the host. The server may disregard successive ATTN keys while 264 waiting for the first ATTN to be processed and direction is yielded 265 by the host. 267 The client may also send SYSREQ (if enabled by TN3270E function 268 negotiation) to override the input inhibit state. This allows the 269 user to switch to SSCP-LU session (possibly to logoff). 271 The RESET key is used to clear local terminal and X-SYSTEM error 272 conditions. RESET purges all buffered (type-ahead) keystrokes, 273 except when entered to remove terminal Insert mode. In this case, a 274 second RESET is required to purge the type-ahead buffer. RESET does 275 restore the keyboard allowing the user to begin typing buffered 276 keystrokes. However, it does NOT clear the X-CLOCK condition or 277 allow the client to override the send state and forward data to the 278 server. 280 4.5.2 Keyboard Restore Indicator (KRI) 282 To use the Keyboard Restore Indicator the CONTENTION-RESOLUTION 283 Function must be supported by and agreed upon by both the server and 284 Client during TN3270E function negotiations. KRI is only valid for 285 TN3270E terminals in PLU-SLU session (3270-DATA type mode). 287 KRI is meaningful only when sent by the server. KRI is sent in the 288 REQUEST-FLAG field of the TN3270E header. The KRI bit mask is: 290 KEYBOARD-RESTORE-MASK 0x02 292 A bit value of 1 (true) indicates to the client that its keyboard 293 has been restored. The client's X-CLOCK indicator is turned off, 294 allowing the user to enter data. However, the client may not 295 send data to the server until it has also received SDI from the 296 server (which may be set in the same REQUEST-FLAG field). 298 Logically, the client treats KRI the same as it does the 3270 WCC 299 Keyboard Restore bit. KRI is not a replacement for the 3270 data 300 stream WCC Keyboard Restore bit. The client must still track both 301 the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard 302 state. Normally, one or the other will be received. However, the 303 client should not balk if both are received on a 3270-DATA message. 305 The server ignores KRI in messages from the client and processes any 306 data as usual depending on data type. 308 The server sends KRI when it detects an "implied" keyboard restore 309 during LU-LU session. The server must track whether the host 310 application has explicitly set the keyboard restore bit of the 311 WCC byte in any of the 3270 data streams during a bracket. If not, 312 the server must set KRI in the TN3270E message header when EB is set 313 in the SNA header. 315 It is valid for the server to send a null 3270-DATA message (TN3270E 316 Header and EOR, no data) to indicate the KRI to the client. This 317 allows the server and client to handle a NULL RU containing EBI 318 received from the host. 320 4.5.3 BID Data Type 322 To use the BID data type the CONTENTION-RESOLUTION function must be 323 supported by and agreed upon by both the server and client during 324 TN3270E function negotiations. The BID data type message is only 325 valid on terminal sessions in 3270-DATA (LU-LU) mode. The BID data 326 type is not valid during SSCP-LU mode, NVT mode, or on printer 327 sessions. 329 The BID DATA-TYPE code is defined as: 331 Data-type Name Code Meaning 332 -------------- ---- ------------------------------------------- 333 BID 0x09 The server indicates that the host has sent 334 an implicit or explicit BID by sending this 335 data type to the client. 337 The server sends the new TN3270E BID data type to the client upon 338 receipt of either an implicit or an explicit BID from the host. The 339 server must never send BID to the client when the host already has 340 direction (holds send state). 342 To send the BID data type the server inserts the BID data type in 343 the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in 344 the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the 345 RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER. The 346 server should use the next number in the progression of sequence 347 numbers. An End-of-Record (EOR) is appended immediately after the 348 TN3270E header (there is no data portion for a BID message). 350 The BID data type must always receive a response from the client 351 regardless of whether the RESPONSES function is supported on the 352 session. The client's positive or negative response to a BID should 353 be exactly the same as those defined in the TN3270 Enhancements RFC, 354 unless the SNA Sense Code Function (defined in section 6) is used by 355 the client to communicate a more specific code. The SEQ-NUMBER is 356 returned by the client in its response, to allow the server to 357 coordinate the response with the BID. 359 When the client receives a BID message it is accepted by returning 360 a positive response, or rejected by returning a negative response. 361 The format of a positive response is the same as the positive 362 response defined for the TN3270E RESPONSES function (i.e., RESPONSE 363 data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER 364 from BID). When the client accepts the BID the keyboard state goes 365 to input inhibited, the client displays the X-CLOCK symbol and may 366 not send data until SDI is received from the server. 368 When the server receives a BID response from the client, it is 369 responsible for constructing the appropriate SNA response to the 370 host. 372 If the client already has buffered data to be sent to the host the 373 client can reject the BID. The negative response uses the TN3270E 374 RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code 375 in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client 376 supports the SNA Sense Codes function, there is no defined reason 377 information in the data portion of the negative response. The 378 server rejects the host's BID with a "Bracket Bid Reject" sense code 379 (0x08130000). The client's send state should remain unchanged upon 380 negatively responding to a BID (i.e. if send state is input 381 inhibited, it stays that way). 383 If the client supports the SNA Sense Code function, it has the 384 option of returning "Receiver in Transmit Mode" (0x081B0000) sense 385 code. This may be returned to reject the Bid when the user has 386 started typing data but has not yet pressed an AID key. 388 A potential race condition exists, where the client sends data at 389 the same time the server is sending a BID to the client. The race 390 condition is handled by the server, and is relatively transparent to 391 the client. When the server receives data before the expected 392 response to the BID, the data is treated as an implied negative 393 response. The server sends the Bracket Bid Reject (0x08130000) 394 negative response to the host's BID and forwards the client's data 395 to the host. When the client's response to the BID is received it 396 is discarded by the server. The client's keyboard state should be 397 input inhibited, whether it responded positively or negatively to 398 the BID, because it has not received SDI for the data it sent 399 previously. 401 4.5.4 SIGNAL Indicator 403 To use the SIGNAL indicator the CONTENTION-RESOLUTION function must 404 be supported by and agreed upon by both the server and client during 405 TN3270E function negotiations. The SIGNAL indicator is only valid 406 on BID data type messages. The SIGNAL indicator is sent in the 407 REQUEST-FLAG field of the TN3270E header. 409 The SIGNAL bit mask is: 411 SIGNAL-MASK 0x04 413 A bit value of 1 (true) indicates that a Signal has been received 414 from the PLU. Therefore the BID is "Forced" and the client MUST 415 forfeit the send state. 417 The client must always respond to a BID with the SIGNAL indicator, 418 as described in the BID section. It is not necessary for the client 419 to echo the SIGNAL indicator in its response. However, the server 420 should not balk if the client does echo the SIGNAL indicator. The 421 server must maintain in it's state machine that it is awaiting a 422 response to a SIGNAL indicator. 424 When a Signal is received from the PLU the TN3270E Server's 425 behavior may be summarized as follows: 427 Send positive response to the host for the Signal 428 If the host already has direction, or in contention state. . . 429 there is nothing more to do 430 Else client has direction. . . 431 send BID with Signal to client and wait for reply or data 432 If data received first. . . 433 forward data to host as normal (will carry CD) 434 Else response received first. . . 435 send null RU CD to Host (with BB if necessary) 437 Upon receipt of Signal from the host, the server returns positive 438 response to the host, regardless of whether the host or client holds 439 direction. If the host holds direction (send state), there is 440 nothing more to be done. The client should already be awaiting data 441 from the host. 443 If the client holds direction, the server sends a BID with the 444 SIGNAL indicator set to inform the client that it no longer holds 445 send state and its keyboard state is input inhibited. The server 446 will receive either data or a positive response from the client. 448 The server forwards any inbound data from the client to the host, 449 while awaiting response to the signal BID. The inbound data record 450 will cause the direction (CD) state to return to the host. When the 451 positive response is received from the client the server has nothing 452 further to do. 454 If the server receives only a response from the client, the server 455 sends a null RU with Change Direction (CD) to the host. The client 456 MUST return positive response to the server. If the client sends 457 negative response to a SIGNAL, even though it is not allowed to do 458 so, the server treats it as a positive response and handles it 459 accordingly. 461 The Client's behavior when a BID containing the Signal indicator is 462 summarized as: 464 Receive BID with Signal indicator 465 If client has direction and buffered keystrokes with AID. . . 466 send first AID buffer 467 Else host has direction (race condition) or no AID. . . 468 the buffered keystrokes are left unchanged 469 Return positive response to Signal 470 Enter X-CLOCK input inhibited mode 471 Buffer any keystrokes/AID typed after the Signal 473 A Signal does not cause the client to purge any buffered keystrokes. 474 If the client holds direction when the Signal is received, it may 475 send one buffered AID message (if any) before sending positive 476 response to the Signal. If the Host already had direction (race 477 condition) or no AID key is buffered, the type-ahead buffer is 478 retained, as is. 480 The client then accepts the BID, and enters input inhibit mode. No 481 further buffered data may be forwarded to the host until direction 482 is returned to the client. 484 The following diagram illustrates how the client should handle 485 buffered keystrokes relative to BID/SIGNAL processing: 487 |<--- Data typed before BID --->|<--- Data typed after BID --->| 488 | is displayed on the screen. | is NOT displayed on screen. | 490 This allows the host application to do a Read Buffer, update the 491 portion of the screen it wants to change, put the cursor back to the 492 right place for the suspended input and restore the keyboard. The 493 client then streams the buffered keystrokes into the screen image. 494 Upon completion of these processes the screen image should be 495 restored correctly. 497 5. SNA Sense Code Function 499 This function is intended for SNA TN3270E environments only. 500 Non-SNA server implementations should ALWAYS disable this function 501 during TN3270E function negotiations. 503 When the server and client operate in an SNA environment, it is 504 impractical to perpetuate the one-byte error code mapping style of 505 TN3270E. Especially, when SNA already provides a table of defined 506 Sense codes. The SNA Sense Code function allows the client to 507 return SNA Sense codes to the server, which are in turn forwarded to 508 the SNA Host as a negative response. 510 The client indicates that the data portion of the response message 511 contains a 4-byte SNA sense code by setting the following code in 512 the RESPONSE-FLAG field: 514 SNA-SENSE-CODE 2 516 The SNA-SENSE function may be negotiated on either terminal or 517 printer sessions. When the SNA-SENSE and RESPONSES functions have 518 been negotiated, the server is committed to accepting SNA-SENSE-CODE 519 responses to 3270-DATA, SCS-DATA (LU1) and BID data type messages. 521 The client retains the option of providing specific SNA Sense codes, 522 or letting the server map all errors to the appropriate SNA sense 523 codes. 525 6. References 527 [1] IBM's "3174 Functional Description", Bookshelf book CN7A7003, 528 GA23-0218-11. 529 [2] IBM's "Systems Network Architecture Formats", GA27-3136-14. 530 [3] RFC 2355 531 [4] IBM's "IPDS and SCS Technical Reference", S544-5312-00. 533 7. Term Definitions 535 This section defines some of the terms used in this document. 537 Input Inhibited - 538 a state where the client does not hold send state. Either the 539 client has presented an AID message to the host or the host has 540 gained direction via the BID process. The keyboard state is any 541 of the type-ahead or keyboard disabled states. 543 Only SYSREQ or ATTN may be forwarded to the server while the 544 client is in Input Inhibited state. SYSREQ and ATTN should never 545 be buffered by the client. 547 Keyboard Disabled - 548 a keyboard state where keystrokes may NOT be buffered by the 549 client. Keyboard disabled states include (X-f), etc. 551 Keyboard States - 552 define the various modes a keyboard may be in during a TN3270E 553 session. 555 When the client holds send state the keyboard is in Ready state. 556 The client is free to process all keyboard input and forward any 557 entered or buffered AID data to the server. 559 An Input Inhibited state is entered when the client surrenders 560 send state by sending an AID buffer or granting a BID request 561 from the host. 563 The diagram below summarizes the various keyboard states: 565 ------------------------------------------------------------- 566 Ready | Input Inhibited 567 |----------------------------------------------------- 568 | Type-ahead | Keyboard Disabled 569 |----------------------------+------------------------ 570 | X-CLOCK | X-SYSTEM | . . . | X-f | . . . 571 ------------------------------------------------------------- 573 Type-ahead - 574 is a state in which the client (terminal) may buffer keystrokes 575 when the keyboard is an Input Inhibited state. Displayed 576 keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System 577 Lock). Keystrokes (text and AID keys) are buffered waiting for 578 send state to be returned to the client. 580 8. Abbreviations 582 BB Begin Bracket, byte 2 bit 0 of RH of BC RU 583 BC Begin chain, byte 0 bit 6 of RH 584 BC RU An RU with BC = 1 585 EB End Bracket, byte 2 bit 1 of RH of BC RU 586 EC End chain, byte 0 bit 7 of RH 587 EC RU An RU with EC = 1 588 FI Format Indicator, byte 0 bit 4 of RH 589 FIC First In Chain - an RU with BC = 1 and EC = 0 590 IPDS Intelligent Printer Data Stream 591 LIC Last In Chain - an RU with BC = 0 and EC = 1 592 LU Logical Unit 593 LUn Logical Unit Type n, n = 0, 1, 2, etc. 594 MIC Middle In Chain - an RU with BC = 0 and EC = 0 595 OIC Only In Chain - an RU with BC = 1 and EC = 1 596 RH Request Header, 3 byte header on SNA RU 597 RU Request Unit, an SNA frame starting with an RH 598 SNA Systems Network Architecture 600 9. Conventions 602 - Byte order is big-endian, e.g. bit 0 is the most significant bit. 604 10. Author's Note 606 Portions of this document were drawn from the following sources: 607 - Contention Resolution proposal by Rodger Erickson (Wall Data). 608 - SNA Sense Code Support proposal by Derek Bolton (Cisco Systems). 609 - Discussions on the TN3270E list and at the TN3270E/TN5250E 610 Interoperability Events, 1997-1998. Particularly contributions 611 by Jim Mathewson II (IBM), Derek Bolton, Michael Boe, and Diane 612 Henderson (Cisco Systems). 614 11. Change Log 616 - Removed FMH and Byte-Doubling Suppression Support with consensus 617 of TN3270E Work Group. 619 12. Author's Addresses 621 Gene Pullen Alcatel USA, Inc. 622 1000 Coit Road 623 Plano, Texas 75075 624 Email: gene.pullen@usa.alcatel.com 626 Marty Williams S2 Systems, Inc. 627 4965 Preston Park Blvd 628 Suite 800 629 Plano, Texas 75093 630 Email: marty_williams@s2systems.com 632 Draft Expiration Date: October 2002 634 Full Copyright Statement 636 Copyright (c) The Internet Society (1999, 2000, 2001, 2002). All Rights 637 Reserved. 639 This document and translations of it may be copied and furnished to 640 others, and derivative works that comment on or otherwise explain it or 641 assist in its implementation may be prepared, copied, published and 642 distributed, in whole or in part, without restriction of any kind, 643 provided that the above copyright notice and this paragraph are 644 included on all such copies and derivative works. However, this 645 document itself may not be modified in any way, such as by removing the 646 copyright notice or references to the Internet Society or other 647 Internet organizations, except as needed for the purpose of developing 648 Internet standards in which case the procedures for copyrights defined 649 in the Internet Standards process must be followed, or as required to 650 translate it into languages other than English. 652 The limited permissions granted above are perpetual and will not be 653 revoked by the Internet Society or its successors or assigns. 655 This document and the information contained herein is provided on an 656 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 657 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 658 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 659 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 660 FITNESS FOR A PARTICULAR PURPOSE.