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