idnits 2.17.1 draft-ietf-tn3270e-extensions-03.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 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 are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 431: '...he BID is "Forced" and the client MUST...' RFC 2119 keyword, line 473: '... 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 (October 8, 2001) is 8237 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? '2' on line 884 looks like a reference -- Missing reference section? '1' on line 882 looks like a reference -- Missing reference section? '4' on line 886 looks like a reference -- Missing reference section? '3' on line 885 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 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: April 2002 5 October 8, 2001 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). All Rights 34 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, SNA Sense Code support, Function 49 Management Header support, and TN3270E header byte-doubling 50 suppression. 52 1. Table of Contents 54 1. Table of Contents . . . . . . . . . . . . . . . . . . . 2 55 2. Negotiated Function Codes . . . . . . . . . . . . . . . 3 56 3. Negotiated Function Example . . . . . . . . . . . . . . 3 57 4. Contention Resolution Function . . . . . . . . . . . . . 4 58 4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . 4 59 4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . 4 60 4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . 4 61 4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . 5 62 4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . 5 63 4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . 6 64 4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . 7 65 4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . 8 66 4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . 9 67 5. Function Management Header (FMH) Support Function . . . 12 68 5.1 FMH Overview . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1.1 LU1 FMH1 Support . . . . . . . . . . . . . . . . . . . . 13 70 5.1.2 Usage of DSSEL in FMH1 . . . . . . . . . . . . . . . . . 13 71 5.1.3 Structured Field Data Stream . . . . . . . . . . . . . . 14 72 5.1.4 IPDS Data Stream . . . . . . . . . . . . . . . . . . . . 14 73 5.2 FMH Data Type . . . . . . . . . . . . . . . . . . . . . 14 74 5.3 Server Implementation . . . . . . . . . . . . . . . . . 15 75 5.3.1 Bind Processing . . . . . . . . . . . . . . . . . . . . 15 76 5.3.2 Host/Server Flow . . . . . . . . . . . . . . . . . . . . 15 77 5.3.3 Client/Server Flow . . . . . . . . . . . . . . . . . . . 16 78 5.3.4 FMH Responses . . . . . . . . . . . . . . . . . . . . . 16 79 5.4 Client Implementation . . . . . . . . . . . . . . . . . 17 80 6. SNA Sense Code Function . . . . . . . . . . . . . . . . 18 81 7. TN3270E Header Byte-doubling Suppression Function . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . 20 83 9. Term Definitions . . . . . . . . . . . . . . . . . . . . 20 84 10. Abbreviations . . . . . . . . . . . . . . . . . . . . . 21 85 11. Conventions . . . . . . . . . . . . . . . . . . . . . . 21 86 12. Author's Note . . . . . . . . . . . . . . . . . . . . . 22 87 13. Author's Address . . . . . . . . . . . . . . . . . . . . 22 89 2. Negotiated Function Codes 91 To maintain backward compatibility with clients and servers that do 92 not support the extended TN3270E functions all new functionality 93 will be negotiated. The current TN3270E function negotiation rules 94 apply. Either side may request one or more of the extended 95 functions by adding them to the function code list during TN3270E 96 function negotiations. Either side may reject the function by 97 removing it from the function list. 99 The extended TN3270E function negotiation codes are defined as: 101 CONTENTION-RESOLUTION 5 102 FMH-SUPPORT 6 103 SNA-SENSE 7 104 SUPPRESS-HEADER-BYTE-DOUBLING 8 106 3. Negotiated Function Example 108 The SNA-SENSE function support is enabled by the negotiation below: 110 Server: IAC DO TN3270E 111 Client: IAC WILL TN3270E 112 . . . 113 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 114 Server: IAC SB TN3270E FUNCTIONS IS ... SNA-SENSE IAC SE 116 Support is disabled by the negotiation below (the server does not 117 support the SNA-SENSE function): 119 Server: IAC DO TN3270E 120 Client: IAC WILL TN3270E 121 . . . 122 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 123 Server: IAC SB TN3270E FUNCTIONS REQUEST ... IAC SE 124 Client: IAC SB TN3270E FUNCTIONS IS ... IAC SE 126 4. Contention Resolution Function 128 This function addresses shortcomings in the current TN3270E (RFC 129 2355) specification that stem from the fact that SNA is a 130 send/receive state oriented protocol, while TN3270E is relatively 131 state free. The following subsections define the problems to be 132 addressed and the methods to resolve those issues. 134 4.1 Keyboard Restore Problem 136 The Keyboard Restore problem concerns uncertainty over when the 137 client can send data to the TN3270E server. TN3270E provides for an 138 End-Of-Record (EOR) mechanism, which allows the client to determine 139 where the boundary is between 3270 data stream commands. The server 140 sends EOR whenever it sends data to the client for which the LIC 141 (Last-In-Chain) indicator was set. Clients have no choice but to 142 interpret the presence of EOR as an indication that it is okay to go 143 ahead and send data back to the host (providing the 3270 data-stream 144 has restored the keyboard). Since it is not uncommon for the Server 145 to receive a LIC from the host with no CDI (Change Direction 146 Indicator) set, a serious problem is created where the client will 147 send data to the server when it does not own the send state. 149 The solution is for the server to provide the client with an 150 indication that it may send data. The Send Data Indicator (SDI) 151 mechanism will be discussed later in this document. 153 4.2 Implied Keyboard Restore Problem 155 The Implied Keyboard Restore problem occurs when an application 156 never explicitly sets the keyboard restore bit of the WCC byte in 158 any of the 3270 data streams during a bracket. In SNA, EB is 159 considered an "implied" keyboard restore in this case. However, 160 since TN clients are not aware of the bracket or direction state the 161 client is not aware that it is allowed to send data and often hangs 162 in X-CLOCK state. 164 The solution for this problem is for the server to detect the 165 implied keyboard restore condition and send the Keyboard Restore 166 Indicator (KRI) flag to inform the client that its keyboard is 167 unlocked (ready state). 169 4.3 BID Problem 171 In SNA, when a session is in the BETB (Between Bracket), the Primary 172 LU (PLU), or host, may bid for the bracket by either sending an 173 explicit or implicit BID. The Secondary LU (SLU), or terminal, 174 processes the BID, either granting the bracket to the host or 175 rejecting the request. Having granted the bracket the SLU must 176 enter the X-CLOCK (Time) input inhibited state. 178 An implicit BID occurs when the session is BETB and the host sends a 179 message to the SLU with Begin Bracket (BB) indicated. No BID 180 actually flows but is implied. The SLU may accept or reject as if a 181 BID had been sent. 183 In the TN3270 world, there is no mechanism for including the client 184 in the BID process. The server must process the BID on the client's 185 behalf, without the ability to request the client yield the send 186 state. This leads to a variety of problems when the client attempts 187 to send data inbound after the server has sent positive response to 188 a BID from the host. These problems include hung or lost sessions, 189 lost data, or SNA or host application error messages, depending on 190 data flow, timing, and how the server handles the BID process. 192 This problem can be addressed by allowing the BID to propagate to 193 the client. When the server receives a valid BID (implicit or 194 explicit) from the host (i.e. one that occurs in the BETB state) it 195 will forward it to the client. The client will respond either 196 positively or negatively. Having granted the BID (positive 197 response), the client enters the X-CLOCK input inhibited state until 198 the session reenters contention state. 200 4.4 Signal Problem 202 The Signal problem occurs when the PLU sends a Signal in order to 203 force the SLU to yield direction. For example, when the secondary 204 has rejected a BID and the host needs to override it. The BID 205 reject may occur when the user types some data (perhaps an 206 unintentional depression of the space bar) and does not press an AID 207 key. The SNA architecture provides that the primary (host) can send 208 a Signal. The secondary should reply with a positive response, send 209 a null RU with Change Direction to yield direction (and Begin 210 Bracket if appropriate), and enter send inhibit state. 212 With TN3270 there is no way for the server to force the client to 213 yield the send state. 215 4.5 CONTENTION-RESOLUTION Implementation 217 This section defines a new negotiated TN3270E function called 218 CONTENTION-RESOLUTION. Support of this function implies that both 219 the client and the server are able to handle the SDI, KRI and Signal 220 header flags and the BID data type as defined in this specification. 222 This function is intended SNA TN3270E environments only. Non-SNA 223 server implementations should ALWAYS disable this function during 224 TN3270E function negotiations. 226 When the CONTENTION-RESOLUTION function is supported, the 227 REQUEST-FLAG header field is interpreted as a bit mask, instead of a 228 byte value, to allow the field to be used for Send Data, Keyboard 229 Restore and Signal indicators. 231 4.5.1 Send Data Indicator (SDI) 233 To use the Send Data Indicator the CONTENTION-RESOLUTION function 234 must be supported by and agreed upon by both the server and client 235 during TN3270E function negotiations. SDI is only valid for TN3270E 236 terminals in PLU-SLU session (3270-DATA type). SDI is not used for 237 SSCP-LU mode to avoid the overhead of the server having to BID to 238 send asynchronous SSCP-LU-DATA records to the client. 240 SDI is meaningful only when sent by the server. It is sent in the 241 REQUEST-FLAG field of the TN3270E header. The SDI bit mask is: 243 SEND-DATA-MASK 0x01 245 A bit value of 1 (true) indicates to the client that it holds the 246 send state. A bit value of 0 (false) indicates the server (and host 247 by extension) holds the send state. 249 In SNA LU-LU session, the server sends SDI when the host 250 relinquishes send state with either the CDI or the EBI set in the 251 SNA RU header. 253 It is valid for the server to send a null 3270-DATA message (TN3270E 254 header and EOR, no data) to indicate the send state to the client. 255 This allows the server and client to handle a NULL RU containing EBI 256 or CDI received from the host. 258 The server ignores SDI in messages from the client and processes any 259 data as usual depending on data type. 261 When SDI is received by the client and the current TN3270E message 262 has been processed (upon receipt of EOR) the client may send data to 263 the server. If RESPONSES have been negotiated, the client must send 264 RESPONSES to the server regardless of the send state. Upon receipt 265 of SDI, the client must send all pending RESPONSE messages before 266 sending any keyboard input to the server. 268 SDI is not a replacement for the 3270 data stream WCC Keyboard 269 Restore bit. The client must track the 3270 WCC Keyboard Restore 270 flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to determine 271 whether or not it can start sending data to the server. If keyboard 272 restore (WCC or KRI) is received, the keyboard input must still be 273 buffered until the SDI is received. 275 The client may send an ATTN key (IAC IP) regardless of the keyboard 276 State, including input inhibited state. ATTN causes the server to 277 send a SIGNAL to the host requesting Change Direction. This may 278 allow the user to recover from a direction state timing or 279 synchronization problem (i.e. server neglected to send SDI). The 280 client should avoid subsequent ATTN keys until it receives direction 281 from the host. The server may disregard successive ATTN keys while 282 waiting for the first ATTN to be processed and direction is yield by 283 the host. 285 The client may also send SYSREQ (if enabled by TN3270E function 286 negotiation) to override the input inhibit state. This allows the 287 user to switch to SSCP-LU session (possibly to logoff). 289 The RESET key is used to clear local terminal and X-SYSTEM error 290 conditions. RESET purges all buffered (type-ahead) keystrokes, 291 except when entered to remove terminal Insert mode. In this case, a 292 second RESET is required to purge the type-ahead buffer. RESET does 293 restore the keyboard allowing the user to begin typing buffered 294 keystrokes. However, it does NOT clear the X-CLOCK condition or 295 allow the client to override the send state and forward data to the 296 server. 298 4.5.2 Keyboard Restore Indicator (KRI) 300 To use the Keyboard Restore Indicator the CONTENTION-RESOLUTION 301 Function must be supported by and agreed upon by both the server and 302 Client during TN3270E function negotiations. KRI is only valid for 303 TN3270E terminals in PLU-SLU session (3270-DATA type mode). 305 KRI is meaningful only when sent by the server. KRI is sent in the 306 REQUEST-FLAG field of the TN3270E header. The KRI bit mask is: 308 KEYBOARD-RESTORE-MASK 0x02 310 A bit value of 1 (true) indicates to the client that its keyboard 311 has been restored. The client's X-CLOCK indicator is turned off, 312 allowing the user to enter data. However, the client may not 313 send data to the server until it has also received SDI from the 314 server (which may be set in the same REQUEST-FLAG field). 316 Logically, the client treats KRI the same as it does the 3270 WCC 317 Keyboard Restore bit. KRI is not a replacement for the 3270 data 318 stream WCC Keyboard Restore bit. The client must still track both 319 the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard 320 state. Normally, one or the other will be received. However, the 321 client should not balk if both are received on a 3270-DATA message. 323 The server ignores KRI in messages from the client and processes any 324 data as usual depending on data type. 326 The server sends KRI when it detects an "implied" keyboard restore 327 during LU-LU session. The server must track whether the host 328 application has explicitly set the keyboard restore bit of the 329 WCC byte in any of the 3270 data streams during a bracket. If not, 330 the server must set KRI in the TN3270E message header when EB is set 331 in the SNA header. 333 It is valid for the server to send a null 3270-DATA message (TN3270E 334 Header and EOR, no data) to indicate the KRI to the client. This 335 allows the server and client to handle a NULL RU containing EBI 336 received from the host. 338 4.5.3 BID Data Type 340 To use the BID data type the CONTENTION-RESOLUTION function must be 341 supported by and agreed upon by both the server and client during 342 TN3270E function negotiations. The BID data type message is only 343 valid on terminal sessions in 3270-DATA (LU-LU) mode. The BID data 344 type is not valid during SSCP-LU mode, NVT mode, or on printer 345 sessions. 347 The BID DATA-TYPE code is defined as: 349 Data-type Name Code Meaning 350 -------------- ---- ------------------------------------------- 351 BID 0x09 The server indicates that the host has sent 352 an implicit or explicit BID by sending this 353 data type to the client. 355 The server sends the new TN3270E BID data type to the client upon 356 receipt of either an implicit or an explicit BID from the host. The 357 server must never send BID to the client when the host already has 358 direction (holds send state). 360 To send the BID data type the server inserts the BID data type in 361 the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in 362 the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the 363 RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER. The server 364 should use the next number in the progression of sequence numbers. An 365 End-of-Record (EOR) is appended immediately after the TN3270E header 366 (there is no data portion for a BID message). 368 The BID data type must always receive a response from the client 369 regardless of whether the RESPONSES function is supported on the 370 session. The client's positive or negative response to a BID should 371 be exactly the same as those defined in the TN3270 Enhancements RFC, 372 unless the SNA Sense Code Function (defined in section 6) is used by 373 the client to communicate a more specific code. The SEQ-NUMBER is 374 returned by the client in its response, to allow the server to 375 coordinate the response with the BID. 377 When the client receives a BID message it is accepted by returning 378 a positive response, or rejected by returning a negative response. 379 The format of a positive response is the same as the positive 380 response defined for the TN3270E RESPONSES function (i.e., RESPONSE 381 data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER 382 from BID). When the client accepts the BID the keyboard state goes 383 to input inhibited, the client displays the X-CLOCK symbol and may 384 not send data until SDI is received from the server. 386 When the server receives a BID response from the client, it is 387 responsible for constructing the appropriate SNA response to the host. 389 If the client already has buffered data to be sent to the host the 390 client can reject the BID. The negative response uses the TN3270E 391 RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code 392 in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client 393 supports the SNA Sense Codes function, there is no defined reason 394 information in the data portion of the negative response. The 395 server rejects the host's BID with a "Bracket Bid Reject" sense code 396 (0x08130000). The client's send state should remain unchanged upon 397 negatively responding to a BID (i.e. if send state is input 398 inhibited, it stays that way). 400 If the client supports the SNA Sense Code function, it has the 401 option of returning "Receiver in Transmit Mode" (0x081B0000) sense 402 code. This may be returned to reject the Bid when the user has 403 started typing data but has not yet pressed an AID key. 405 A potential race condition exists, where the client sends data at 406 the same time the server is sending a BID to the client. The race 407 condition is handled by the server, and is relatively transparent to 408 the client. When the server receives data before the expected 409 response to the BID, the data is treated as an implied negative 410 response. The server sends the Bracket Bid Reject (0x08130000) 411 negative response to the host's BID and forwards the client's data 412 to the host. When the client's response to the BID is received it 413 is discarded by the server. The client's keyboard state should be 414 input inhibited, whether it responded positively or negatively to 415 the BID, because it has not received SDI for the data it sent 416 previously. 418 4.5.4 SIGNAL Indicator 420 To use the SIGNAL indicator the CONTENTION-RESOLUTION function must 421 be supported by and agreed upon by both the server and client during 422 TN3270E function negotiations. The SIGNAL indicator is only valid 423 on BID data type messages. The SIGNAL indicator is sent in the 424 REQUEST-FLAG field of the TN3270E header. 426 The SIGNAL bit mask is: 428 SIGNAL-MASK 0x04 430 A bit value of 1 (true) indicates that a Signal has been received 431 from the PLU. Therefore the BID is "Forced" and the client MUST 432 forfeit the send state. 434 The client must always respond to a BID with the SIGNAL indicator, as 435 described in the BID section. It is not necessary for the client to 436 echo the SIGNAL indicator in its response. However, the server 437 should not balk if the client does echo the SIGNAL indicator. The 438 server must maintain in it's state machine that it is awaiting a 439 response to a SIGNAL indicator. 441 When a Signal is received from the PLU the TN3270E Server's 442 behavior may be summarized as follows: 444 Send positive response to the host for the Signal 445 If the host already has direction, or in contention state. . . 446 there is nothing more to do 447 Else client has direction. . . 448 send BID with Signal to client and wait for reply or data 449 If data received first. . . 450 forward data to host as normal (will carry CD) 451 Else response received first. . . 452 send null RU CD to Host (with BB if necessary) 454 Upon receipt of Signal from the host, the server returns positive 455 response to the host, regardless of whether the host or client holds 456 direction. If the host holds direction (send state), there is 457 nothing more to be done. The client should already be awaiting data 458 from the host. 460 If the client holds direction, the server sends a BID with the 461 SIGNAL indicator set to inform the client that it no longer holds 462 send state and its keyboard state is input inhibited. The server 463 will receive either data or a positive response from the client. 465 The server forwards any inbound data from the client to the host, 466 while awaiting response to the signal BID. The inbound data record 467 will cause the direction (CD) state to return to the host. When the 468 positive response is received from the client the server has nothing 469 further to do. 471 If the server receives only a response from the client, the server 472 sends a null RU with Change Direction (CD) to the host. The client 473 MUST return positive response to the server. If the client sends 474 negative response to a SIGNAL, even though it is not allowed to do 475 so, the server treats it as a positive response and handles it 476 accordingly. 478 The Client's behavior when a BID containing the Signal indicator is 479 summarized as: 481 Receive BID with Signal indicator 482 If client has direction and buffered keystrokes with AID. . . 483 send first AID buffer 484 Else host has direction (race condition) or no AID. . . 485 the buffered keystrokes are left unchanged 486 Return positive response to Signal 487 Enter X-CLOCK input inhibited mode 488 Buffer any keystrokes/AID typed after the Signal 490 A Signal does not cause the client to purge any buffered keystrokes. 491 If the client holds direction when the Signal is received, it may 492 send one buffered AID message (if any) before sending positive 493 response to the Signal. If the Host already had direction (race 494 condition) or no AID key is buffered, the type-ahead buffer is 495 retained, as is. 497 The client then accepts the BID, and enters input inhibit mode. No 498 further buffered data may be forwarded to the host until direction 499 is returned to the client. 501 The following diagram illustrates how the client should handle 502 buffered keystrokes relative to BID/SIGNAL processing: 504 |<--- Data typed before BID --->|<--- Data typed after BID --->| 505 | is displayed on the screen. | is NOT displayed on screen. | 507 This allows the host application to do a Read Buffer, update the 508 portion of the screen it wants to change, put the cursor back to the 509 right place for the suspended input and restore the keyboard. The 510 client then streams the buffered keystrokes into the screen image. 511 Upon completion of these processes the screen image should be 512 restored correctly. 514 5. Function Management Header (FMH) Support Function 516 Function Management Headers are not permitted in LU2 or LU3. 517 Initially, they were not used in LU1 either. Consequently, no 518 provision was made for them in TN3270 or TN3270E. Subsequently, 519 support for FMHs over LU1 has been added to SNA based applications 520 and devices. Requirements to support LU1 DBCS (Kanji etc.) and 521 IPDS printer applications are driving this effort for TN3270E FMH 522 support. 524 A de facto standard has arisen for handling Structured Field data 525 stream FMHs in both TN3270 and TN3270E. This de facto standard is 526 referred to below as "silent FMH support". Only FMH1 is supported 527 and merely forwarded, in both directions, as data. The receiver 528 must recognize that the FMH is present by inspecting the first few 529 bytes of the Telnet record and determining that they do not look 530 like valid SCS data. This is workable because FMH1 is a fixed 531 6-byte string, and it only occurs at the start of a record. 533 The TN3270E FMH support function expands on silent FMH support by 534 adding a mechanism for transferring FMHs through a server using a 535 new TN3270E FMH data type. The main argument for adding this 536 function is to allow clients and servers to formally determine 537 whether the other side can "really" support FMH flows. Since, this 538 functionality is negotiable, client/server vendors can make the 539 determination of the merits of knowing whether the other side truly 540 supports LU1 Function Management Headers. 542 5.1 FMH Overview 544 FMH usage in its simplest terms: 546 - There is only one FMH per chain, starting at the beginning of the 547 chain. 548 - The FMH may be spread over multiple RUs if too long for one. The 549 Format Indicator (FI) is 1 in the BC RU and 0 in the rest. 551 At the next level of complexity: 553 - There may be multiple FMHs, consecutively, at the start of the 554 chain. 555 - The presence of an FMH following the current one is indicated by 556 the concatenation flag at byte 1, bit 0 of the current. 557 - As with a single FMH, these FMHs may continue over several RUs, 558 but only the first RU has the FI flag on. FI=0 on subsequent RUs. 560 The concatenation flag in the preceding FMH is sufficient to 561 introduce it. However, the description of FMHs in [2] only requires 562 a (concatenated sequence of) FMH to start at the start of an RU, not 563 necessarily at the start of a chain. It states that any RU in the 564 chain may have the FI flag on and thus start with an FMH, though the 565 preceding RU ended with ordinary data. 567 This would be awkward for TN3270E, since the RU boundaries are not 568 visible to the clients. Fortunately, it is awkward for higher-level 569 Host applications also, e.g. CICS and IMS applications. These 570 generally do not see RU boundaries either. Moreover, it is 571 contradicted by the description of sense code 400F in [2]. So it is 572 not surprising that the 3174 does not support this generality. 574 5.1.1 LU1 FMH1 Support 576 LU1 supports only FMH1. By default, LU1 sessions use SCS data 577 stream. FMH1 is used to introduce support for an alternate data 578 stream. 580 The FMH1 format is: 582 byte 0 | 1 | 2 | 3 | 4 .. n 583 +------------------------------------------------------------ 584 |length|concat| type |medium|subaddr|flags| DSP | DSSEL 585 +------------------------------------------------------------ 586 bits 8 1 7 4 4 4 4 3 588 Where: 589 length FMH length = (n+1) 590 concat Concatenation Flag = (0) 591 type FMH Type (FMH1 = 1) 592 medium (console = 0) 593 subaddr (0) 594 flags Bit 0 - Send/Receive Indicator (SRI: Send=0, Receive=1) 595 DSP Data-stream Profile 596 - 0xB = Structured Field Data Stream 597 - 0xD = IPDS Data Stream 598 DSSEL Destination Selection 600 5.1.2 Usage of DSSEL in FMH1 602 FMH1 describes the data-stream of accompanying data. The 603 accompanying data can be in a single chain (BEDS) or spread over 604 multiple chains (BDS ... EDS). For TN3270E, the client is only able 605 to support BEDS for inbound FMHs, because the server will assume CD 606 at the end of each chain. 608 It is also possible to abort the data-stream (ADS instead of EDS), 609 suspend a data-stream (SDS), and resume it later (RDS). In practice 610 SDS/RDS are only used to insert console output into a longer 611 transfer of data. 613 The entire data-stream must be within a bracket. If EB occurs after 614 BDS but before EDS then the data-stream is implicitly aborted. 616 5.1.3 Structured Field Data Stream 618 This is used by DBCS and IPDS printers so that a Read Partition 619 Query exchange can be conducted with an LU1 printer. (See [1].) 621 Outbound FMH1: 0x0601000B6000 622 Inbound FMH1: 0x0601008B6000 (SRI bit on) 624 BC RU 625 length = 6 626 concat = 0 627 DSP = 0xB 628 DSSEL = BEDS 630 Since the DSSEL = BEDS, the Structured Field data-stream is from the 631 end of the FMH to the end of the chain. 633 The usage is bi-directional, but always as one from the host 634 application and a reply from the secondary. 636 5.1.4 IPDS Data Stream 638 (See [4].) 640 Usage: 0x0601300D4000, 0x0601300D2000 642 OIC RU 643 length = 6 644 concat = 0 645 DSP = 0xD 646 DSSEL = BDS, EDS 647 No data following FMH in the same chain. 649 Although no ADS is sent, an EB before EDS implicitly aborts the data 650 stream. 652 5.2 FMH Data Type 654 To use the FMH data type the FMH-SUPPORT function must be 655 supported by and agreed upon by both the server and client during 656 TN3270E function negotiations. The FMH data type message is only 657 valid on LU1 printer sessions in SCS-DATA mode. The FMH data 658 type is not valid during SSCP-LU mode, NVT mode, or on terminal or 659 LU3 (DCS) printer sessions. The FMH DATA-TYPE code is defined as: 661 Data-type Name Code Meaning 662 -------------- ---- ------------------------------------------- 663 FMH-DATA 0x0A The sender indicates that the data portion 664 of the message contains one or more Function 665 Management Headers. 667 The FMH-DATA data type is bi-directional, meaning both the client 668 and server can send this data type. 670 5.3 Server Implementation 672 If the FMH function has been negotiated, the server forwards the FMH 673 data as part of the record, just as for normal data, and sets the 674 FMH-DATA type in the TN3270E header. 676 If the FMH function was not negotiated the server may send the same 677 with the SCS-DATA type. This maintains backward compatibility for 678 servers that invoke silent FMH support. 680 There is a trade-off between making many data checks in the server, 681 thereby keeping the client interface simple, and minimizing the 682 server's knowledge of the data-stream, thereby preserving 683 flexibility. This proposal takes the latter approach. In 684 particular, except for silent FMH support, the server does not know 685 which FMH types the client supports. 687 5.3.1 Bind Processing 689 Since TN3270E does not permit the client to reject the Bind, the 690 server must police the bind parameters as far as possible. 692 If the server receives an LU1 Bind with byte 6 bit 1 set to 1 (FMHs 693 will be used), but the client has not negotiated FMH function, then 694 the server may choose to reject the Bind with sense 0x08350006. 695 This is left optional (perhaps on customer configuration) in order 696 to accommodate silent FMH support. However, when providing such 697 support, the server is recommended to perform additional checks on 698 the data, as outlined below. 700 5.3.2 Host/Server Flow 702 When the server receives an RU from the host application on an LU1 703 session FI = 1 and category = FMD, the server checks that the FMH is 704 supported in principle. The server returns 0x400F0000 sense code if 705 the Bind did not indicate FMHs or the FMH is not at the beginning of 706 a chain. When providing silent FMH support to the client, the 707 server may make the following optional checks, in this order: 709 Sense Code Cause 710 ---------- ----- 711 0x10082009 Invalid header length (must be 6). 712 0x1008C000 Invalid FMH type (must be 1). 713 0x10086006 Invalid Data-stream Profile (must be 0xB or 0xD). 714 0x10080000 Other invalid parameters in FMH. 716 Example: 717 0x0601000B6000 718 0x0601300D4000 719 0x0601300D2000 721 The server either sends a negative response to the Host application 722 or forwards the data to the client. 724 Note: If neither the FMH nor the SNA-SENSE functions are negotiated 725 then it is recommended that the server only permit a specific list 726 of FMHs from the Host. 728 The existing function is to send EOJ to the client. There is no 729 change required here. 731 5.3.3 Client/Server Flow 733 When the server receives an FMH-DATA record from the client, it 734 forwards the record to the Host application with FI set in the Begin 735 Chain RU. 737 If the server receives a message FMH-DATA type but the FMH function 738 was not negotiated, the server may choose either of two actions: 740 - Terminate the LU-LU session. It is suggested that, if BIND was 741 negotiated, the UNBIND should carry a reason code of 0xFE. 742 (If some future extension allows for SNA sense codes to flow to 743 the client in the unbind image, the code to be used here should 744 be 0x400F0000.) 746 - Behave, for that message only, as though FMH function was 747 negotiated. 749 The server is not required to validate FMH-DATA messages received 750 from the client. 752 If the server has sent a silent FMH (SCS-DATA type) to the client, 753 the server must compare the first 6 bytes of the data for being 754 0x0601008B6000. If so, it sets FI in the Begin Chain RU. 756 5.3.4 FMH Responses 758 If SNA-SENSE-CODE is not supported, and the client returns a 759 negative response to a silent FMH (SCS-DATA) or FMH-DATA type, the 760 server is unable to determine whether the client objects to the FMH or 761 the ensuing data. However, of the identified FMHs requiring support, 762 only the Structured Field Data Stream can have data in the same 763 chain. Even then, the cause of the rejection is likely to be that 764 the client does not support FMHs. Therefore, it is recommended to 765 the server interpret the negative response as a rejection of the FMH 766 itself. The server should send negative response with 0x10080000 767 Sense code to the Host. 769 If SNA-SENSE-CODE is supported the server takes the first four bytes 770 of data following the TN3270E header as an SNA sense code and sends 771 these, unchanged and unchecked, in the negative response to the host. 772 There are many SNA sense codes associated with FMH errors that the 773 client may return. Most are at the application level and begin with 774 0x1008. 776 In addition to codes previously defined, below are some common FMH 777 Sense codes: 779 Sense Code Cause 780 ---------- ----- 781 0x10080000 Invalid parameters in FMH. 782 0x08350006 Bind has byte 6 bit 1 set to 1 (FMHs will be used) but 783 printer does not support FMHs. 784 0x400F0000 Incorrect use of FI (not BC RU), or Bind error 785 (byte 6/bit 1 set to 0). The FI flag is not echoed 786 in the SNA response. 788 5.4 Client Implementation 790 A client that negotiates FMH function takes responsibility for 791 validating the FMH-DATA messages. If an error is found in a 792 received FMH, the client must send a NEGATIVE-RESPONSE. 794 If SNA-SENSE has been negotiated, the SNA-SENSE is set in the 795 Response header field with the appropriate 4-byte SNA sense code in 796 data field. Otherwise, the response field is set to NEGATIVE- 797 RESPONSE and the data field contains the one byte Command Reject 798 (0x0) status code. 800 A client that negotiates the FMH function must set FMH-DATA type on 801 all records it sends that start with an FMH. 803 If a client receives EOJ after BDS and before EDS then the client 804 should infer ADS. 806 6. SNA Sense Code Function 808 This function is intended for SNA TN3270E environments only. 809 Non-SNA server implementations should ALWAYS disable this function 810 during TN3270E function negotiations. 812 When the server and client operate in an SNA environment, it is 813 impractical to perpetuate the one-byte error code mapping style of 814 TN3270E. Especially, when SNA already provides a table of defined 815 Sense codes. The SNA Sense Code function allows the client to 816 return SNA Sense codes to the server, which are in turn forwarded to 817 the SNA Host as a negative response. 819 The client indicates that the data portion of the response message 820 contains a 4-byte SNA sense code by setting the following code in 821 the RESPONSE-FLAG field: 823 SNA-SENSE-CODE 2 825 The SNA-SENSE function may be negotiated on either terminal or 826 printer sessions. When the SNA-SENSE and RESPONSES functions have 827 been negotiated, the server is committed to accepting SNA-SENSE-CODE 828 responses to 3270-DATA, SCS-DATA (LU1), BID and FMH-DATA data type 829 messages. 831 The client retains the option of providing specific SNA Sense codes, 832 or letting the server map all errors to the appropriate SNA sense 833 codes. 835 7. TN3270E Header Byte-doubling Suppression Function 837 A performance bottleneck facing Telnet server and client vendors is, 838 any 0xFF within an outbound data stream must be byte-doubled (a 839 second 0xFF inserted into the data stream) by the sender in order to 840 differentiate actual data from Telnet IAC commands. The receiver of 841 the data stream must then scan through the data stream removing the 842 inserted 0xFF bytes. With header-based protocols, like TN3270E, 843 Telnet byte-doubling forces the header to be variable length, to 844 allow for any 0xFF bytes that may occur within the header. 846 From discussions on the TN3270E list, it was determined that Telnet 847 Byte-doubling Suppression would best be handled outside of the 848 TN3270E standard as a new Telnet negotiated option. This will allow 849 other block mode protocols (i.e. traditional TN3270, and TN5250) to 850 take advantage of the proposed option. 852 However, the variable length header issue is within the scope of the 853 TN3270E standard. This draft proposes a method to make the TN3270E 854 header fixed length by eliminating byte-doubling of the 5 header 855 bytes. This function will extend the TN3270E standard to address 856 this issue. Although this function is proposed in anticipation of a 857 new Suppress Byte-doubling Telnet option, it is intended to be 858 independent of whether such a Telnet option is negotiated. 860 When the SUPPRESS-HEADER-BYTE-DOUBLING function is enabled the 861 TN3270E header will never be byte-doubled in either direction 862 (client to server/server to client). Therefore, the size of the 863 TN3270E header will ALWAYS be 5 bytes when the Header Byte-doubling 864 function is in effect. 866 The sender of a TN3270E message guarantees that the first five 867 (header) bytes of the record will not contain any embedded Telnet 868 commands. The sender must byte-double the data portion of the 869 TN3270E message. 871 The receiver of the message must validate that the message received 872 does begin with a valid TN3270E header, to avoid misinterpreting 873 asynchronous Telnet command packets between TN3270E records. The 874 receiver must also be cognizant of whether a TN3270E header is 875 expected to avoid problems that may occur if bytes in the middle of 876 a chain of buffers are not scanned properly. When the receiver has 877 determined that a valid TN3270E header is present it must skip past 878 the header to begin scanning for byte-doubled 0xFF characters. 880 8. References 882 [1] IBM's "3174 Functional Description", Bookshelf book CN7A7003, 883 GA23-0218-11. 884 [2] IBM's "Systems Network Architecture Formats", GA27-3136-14. 885 [3] RFC 2355 886 [4] IBM's "IPDS and SCS Technical Reference", S544-5312-00. 888 9. Term Definitions 890 This section defines some of the terms used in this document. 892 Input Inhibited - 893 a state where the client does not hold send state. Either the 894 client has presented an AID message to the host or the host has 895 gained direction via the BID process. The keyboard state is any 896 of the type-ahead or keyboard disabled states. 898 Only SYSREQ or ATTN may be forwarded to the server while the 899 client is in Input Inhibited state. SYSREQ and ATTN should never 900 be buffered by the client. 902 Keyboard Disabled - 903 a keyboard state where keystrokes may NOT be buffered by the 904 client. Keyboard disabled states include (X-f), etc. 906 Keyboard States - 907 define the various modes a keyboard may be in during a TN3270E 908 session. 910 When the client holds send state the keyboard is in Ready state. 911 The client is free to process all keyboard input and forward any 912 entered or buffered AID data to the server. 914 An Input Inhibited state is entered when the client surrenders 915 send state by sending an AID buffer or granting a BID request 916 from the host. 918 The diagram below summarizes the various keyboard states: 920 ------------------------------------------------------------- 921 Ready | Input Inhibited 922 |----------------------------------------------------- 923 | Type-ahead | Keyboard Disabled 924 |----------------------------+------------------------ 925 | X-CLOCK | X-SYSTEM | . . . | X-f | . . . 926 ------------------------------------------------------------- 928 Type-ahead - 929 is a state in which the client (terminal) may buffer keystrokes 930 when the keyboard is an Input Inhibited state. Displayed 931 keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System 932 Lock). Keystrokes (text and AID keys) are buffered waiting for 933 send state to be returned to the client. 935 10. Abbreviations 937 ADS Abort Destination Selection, value of DSSEL 938 BB Begin Bracket, byte 2 bit 0 of RH of BC RU 939 BC Begin chain, byte 0 bit 6 of RH 940 BC RU An RU with BC = 1 941 BDS Begin Destination Selection, value of DSSEL 942 BEDS Begin and End Destination Selection, value of DSSEL 943 DCA Document Content Architecture 944 DSP Data-stream Profile, byte 3 bits 4-7 of FMH 945 DSSEL Destination Selection, byte 4 bits 0-2 of FMH 946 EB End Bracket, byte 2 bit 1 of RH of BC RU 947 EC End chain, byte 0 bit 7 of RH 948 EC RU An RU with EC = 1 949 EDS End Destination Selection, value of DSSEL 950 FI Format Indicator, byte 0 bit 4 of RH 951 FIC First In Chain - an RU with BC = 1 and EC = 0 952 FMD Function Management Data (user data, not FMH) 953 FMH Function Management Header, a SNA data header 954 IPDS Intelligent Printer Data Stream 955 LIC Last In Chain - an RU with BC = 0 and EC = 1 956 LU Logical Unit 957 LUn Logical Unit Type n, n = 0, 1, 2, etc. 958 MIC Middle In Chain - an RU with BC = 0 and EC = 0 959 OIC Only In Chain - an RU with BC = 1 and EC = 1 960 RDS Resume Destination Selection, value of DSSEL 961 RH Request Header, 3 byte header on SNA RU 962 RU Request Unit, an SNA frame starting with an RH 963 SDS Suspend Destination Selection, value of DSSEL 964 SNA Systems Network Architecture 966 11. Conventions 968 - Byte order is big-endian, e.g. bit 0 is the most significant bit. 970 12. Author's Note 972 Portions of this document were drawn from the following sources: 973 - Contention Resolution proposal by Rodger Erickson (Wall Data). 974 - SNA Sense Code and Function Management Header Support proposal 975 by Derek Bolton (Cisco Systems). 976 - TN3270E Byte-doubling Suppression proposal by Marty Williams 977 (Cisco Systems). 978 - Discussions on the TN3270E list and at the TN3270E/TN5250E 979 Interoperability Events, 1997-1998. Particularly contributions 980 by Jim Mathewson II (IBM), Derek Bolton, Michael Boe, and Diane 981 Henderson (Cisco Systems). 983 13. Author's Addresses 985 Gene Pullen Alcatel USA, Inc. 986 1000 Coit Road 987 Plano, Texas 75075 988 Email: gene.pullen@usa.alcatel.com 990 Marty Williams Email: mwilliam@dmans.com 992 Draft Expiration Date: April 2002 994 Full Copyright Statement 996 Copyright (c) The Internet Society (1999, 2000, 2001). All Rights 997 Reserved. 999 This document and translations of it may be copied and furnished to 1000 others, and derivative works that comment on or otherwise explain it or 1001 assist in its implementation may be prepared, copied, published and 1002 distributed, in whole or in part, without restriction of any kind, 1003 provided that the above copyright notice and this paragraph are included 1004 on all such copies and derivative works. However, this document itself 1005 may not be modified in any way, such as by removing the copyright notice 1006 or references to the Internet Society or other Internet organizations, 1007 except as needed for the purpose of develop- ing Internet standards in 1008 which case the procedures for copyrights defined in the Internet 1009 Standards process must be followed, or as required to translate it into 1010 languages other than English. 1012 The limited permissions granted above are perpetual and will not be 1013 revoked by the Internet Society or its successors or assigns. 1015 This document and the information contained herein is provided on an "AS 1016 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1017 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1018 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1019 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1020 FITNESS FOR A PARTICULAR PURPOSE.