idnits 2.17.1 draft-ietf-tn3270e-extensions-01.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 429: '...he BID is "Forced" and the client MUST...' RFC 2119 keyword, line 471: '... 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 (May 3, 2000) is 8758 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 882 looks like a reference -- Missing reference section? '1' on line 880 looks like a reference -- Missing reference section? '4' on line 884 looks like a reference -- Missing reference section? '3' on line 883 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: M. Williams 3 Extends: RFC 2355 OpenConnect Systems 4 Expiration Date: November 2000 May 3, 2000 6 TN3270E Functional Extensions 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (1999). All Rights Reserved. 34 Abstract 36 This draft addresses issues and implementation problems defined and 37 discussed at the TN3270E/TN5250E Interoperability Events. It does 38 not replace the current TN3270 Enhancements protocol. It describes 39 functional extensions to the TN3270E protocol. The TN3270E function 40 negotiation mechanism is used to allow the server and client to 41 determine which, if any, of these functions will be supported during 42 a session. This preserves backward compatibility between clients 43 and servers that do not support these features. 45 Among the issues to be address by this draft are SNA/TN3270E 46 Contention state resolution, SNA Sense Code support, Function 47 Management Header support, and TN3270E header byte-doubling 48 suppression. 50 1. Table of Contents 52 1. Table of Contents . . . . . . . . . . . . . . . . . . . 2 53 2. Negotiated Function Codes . . . . . . . . . . . . . . . 3 54 3. Negotiated Function Example . . . . . . . . . . . . . . 3 55 4. Contention Resolution Function . . . . . . . . . . . . . 4 56 4.1 Keyboard Restore Problem . . . . . . . . . . . . . . . . 4 57 4.2 Implied Keyboard Restore Problem . . . . . . . . . . . . 4 58 4.3 Bid Problem . . . . . . . . . . . . . . . . . . . . . . 4 59 4.4 Signal Problem . . . . . . . . . . . . . . . . . . . . . 5 60 4.5 CONTENTION-RESOLUTION Implementation . . . . . . . . . . 5 61 4.5.1 SEND-DATA Indicator (SDI) . . . . . . . . . . . . . . . 6 62 4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . 7 63 4.5.3 BID Data Type . . . . . . . . . . . . . . . . . . . . . 8 64 4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . 9 65 5. Function Management Header (FMH) Support Function . . . 12 66 5.1 FMH Overview . . . . . . . . . . . . . . . . . . . . . . 12 67 5.1.1 LU1 FMH1 Support . . . . . . . . . . . . . . . . . . . . 13 68 5.1.2 Usage of DSSEL in FMH1 . . . . . . . . . . . . . . . . . 13 69 5.1.3 Structured Field Data Stream . . . . . . . . . . . . . . 14 70 5.1.4 IPDS Data Stream . . . . . . . . . . . . . . . . . . . . 14 71 5.2 FMH Data Type . . . . . . . . . . . . . . . . . . . . . 14 72 5.3 Server Implementation . . . . . . . . . . . . . . . . . 15 73 5.3.1 Bind Processing . . . . . . . . . . . . . . . . . . . . 15 74 5.3.2 Host/Server Flow . . . . . . . . . . . . . . . . . . . . 15 75 5.3.3 Client/Server Flow . . . . . . . . . . . . . . . . . . . 16 76 5.3.4 FMH Responses . . . . . . . . . . . . . . . . . . . . . 16 77 5.4 Client Implementation . . . . . . . . . . . . . . . . . 17 78 6. SNA Sense Code Function . . . . . . . . . . . . . . . . 18 79 7. TN3270E Header Byte-doubling Suppression Function . . . 19 80 8. References . . . . . . . . . . . . . . . . . . . . . . . 20 81 9. Term Definitions . . . . . . . . . . . . . . . . . . . . 20 82 10. Abbreviations . . . . . . . . . . . . . . . . . . . . . 21 83 11. Conventions . . . . . . . . . . . . . . . . . . . . . . 21 84 12. Author's Note . . . . . . . . . . . . . . . . . . . . . 22 85 13. Author's Address . . . . . . . . . . . . . . . . . . . . 22 87 2. Negotiated Function Codes 89 To maintain backward compatibility with clients and servers that do 90 not support the extended TN3270E functions all new functionality 91 will be negotiated. The current TN3270E function negotiation rules 92 apply. Either side may request one or more of the extended 93 functions by adding them to the function code list during TN3270E 94 function negotiations. Either side may reject the function by 95 removing it from the function list. 97 The extended TN3270E function negotiation codes are defined as: 99 CONTENTION-RESOLUTION 5 100 FMH-SUPPORT 6 101 SNA-SENSE 7 102 SUPPRESS-HEADER-BYTE-DOUBLING 8 104 3. Negotiated Function Example 106 The SNA-SENSE function support is enabled by the negotiation below: 108 Server: IAC DO TN3270E 109 Client: IAC WILL TN3270E 110 . . . 111 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 112 Server: IAC SB TN3270E FUNCTIONS IS ... SNA-SENSE IAC SE 114 Support is disabled by the negotiation below (the server does not 115 support the SNA-SENSE function): 117 Server: IAC DO TN3270E 118 Client: IAC WILL TN3270E 119 . . . 120 Client: IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE 121 Server: IAC SB TN3270E FUNCTIONS REQUEST ... IAC SE 122 Client: IAC SB TN3270E FUNCTIONS IS ... IAC SE 124 4. Contention Resolution Function 126 This function addresses shortcomings in the current TN3270E (RFC 127 2355) specification that stem from the fact that SNA is a 128 send/receive state oriented protocol, while TN3270E is relatively 129 state free. The following subsections define the problems to be 130 addressed and the methods to resolve those issues. 132 4.1 Keyboard Restore Problem 134 The Keyboard Restore problem concerns uncertainty over when the 135 client can send data to the TN3270E server. TN3270E provides for an 136 End-Of-Record (EOR) mechanism, which allows the client to determine 137 where the boundary is between 3270 data stream commands. The server 138 sends EOR whenever it sends data to the client for which the LIC 139 (Last-In-Chain) indicator was set. Clients have no choice but to 140 interpret the presence of EOR as an indication that it is okay to go 141 ahead and send data back to the host (providing the 3270 data-stream 142 has restored the keyboard). Since it is not uncommon for the Server 143 to receive a LIC from the host with no CDI (Change Direction 144 Indicator) set, a serious problem is created where the client will 145 send data to the server when it does not own the send state. 147 The solution is for the server to provide the client with an 148 indication that it may send data. The Send Data Indicator (SDI) 149 mechanism will be discussed later in this document. 151 4.2 Implied Keyboard Restore Problem 153 The Implied Keyboard Restore problem occurs when an application 154 never explicitly sets the keyboard restore bit of the WCC byte in 156 any of the 3270 data streams during a bracket. In SNA, EB is 157 considered an "implied" keyboard restore in this case. However, 158 since TN clients are not aware of the bracket or direction state the 159 client is not aware that it is allowed to send data and often hangs 160 in X-CLOCK state. 162 The solution for this problem is for the server to detect the 163 implied keyboard restore condition and send the Keyboard Restore 164 Indicator (KRI) flag to inform the client that its keyboard is 165 unlocked (ready state). 167 4.3 BID Problem 169 In SNA, when a session is in the BETB (Between Bracket), the Primary 170 LU (PLU), or host, may bid for the bracket by either sending an 171 explicit or implicit BID. The Secondary LU (SLU), or terminal, 172 processes the BID, either granting the bracket to the host or 173 rejecting the request. Having granted the bracket the SLU must 174 enter the X-CLOCK (Time) input inhibited state. 176 An implicit BID occurs when the session is BETB and the host sends a 177 message to the SLU with Begin Bracket (BB) indicated. No BID 178 actually flows but is implied. The SLU may accept or reject as if a 179 BID had been sent. 181 In the TN3270 world, there is no mechanism for including the client 182 in the BID process. The server must process the BID on the client's 183 behalf, without the ability to request the client yield the send 184 state. This leads to a variety of problems when the client attempts 185 to send data inbound after the server has sent positive response to 186 a BID from the host. These problems include hung or lost sessions, 187 lost data, or SNA or host application error messages, depending on 188 data flow, timing, and how the server handles the BID process. 190 This problem can be addressed by allowing the BID to propagate to 191 the client. When the server receives a valid BID (implicit or 192 explicit) from the host (i.e. one that occurs in the BETB state) it 193 will forward it to the client. The client will respond either 194 positively or negatively. Having granted the BID (positive 195 response), the client enters the X-CLOCK input inhibited state until 196 the session reenters contention state. 198 4.4 Signal Problem 200 The Signal problem occurs when the PLU sends a Signal in order to 201 force the SLU to yield direction. For example, when the secondary 202 has rejected a BID and the host needs to override it. The BID 203 reject may occur when the user types some data (perhaps an 204 unintentional depression of the space bar) and does not press an AID 205 key. The SNA architecture provides that the primary (host) can send 206 a Signal. The secondary should reply with a positive response, send 207 a null RU with Change Direction to yield direction (and Begin 208 Bracket if appropriate), and enter send inhibit state. 210 With TN3270 there is no way for the server to force the client to 211 yield the send state. 213 4.5 CONTENTION-RESOLUTION Implementation 215 This section defines a new negotiated TN3270E function called 216 CONTENTION-RESOLUTION. Support of this function implies that both 217 the client and the server are able to handle the SDI, KRI and Signal 218 header flags and the BID data type as defined in this specification. 220 This function is intended SNA TN3270E environments only. Non-SNA 221 server implementations should ALWAYS disable this function during 222 TN3270E function negotiations. 224 When the CONTENTION-RESOLUTION function is supported, the 225 REQUEST-FLAG header field is interpreted as a bit mask, instead of a 226 byte value, to allow the field to be used for Send Data, Keyboard 227 Restore and Signal indicators. 229 4.5.1 Send Data Indicator (SDI) 231 To use the Send Data Indicator the CONTENTION-RESOLUTION function 232 must be supported by and agreed upon by both the server and client 233 during TN3270E function negotiations. SDI is only valid for TN3270E 234 terminals in PLU-SLU session (3270-DATA type). SDI is not used for 235 SSCP-LU mode to avoid the overhead of the server having to BID to 236 send asynchronous SSCP-LU-DATA records to the client. 238 SDI is meaningful only when sent by the server. It is sent in the 239 REQUEST-FLAG field of the TN3270E header. The SDI bit mask is: 241 SEND-DATA-MASK 0x01 243 A bit value of 1 (true) indicates to the client that it holds the 244 send state. A bit value of 0 (false) indicates the server (and host 245 by extension) holds the send state. 247 In SNA LU-LU session, the server sends SDI when the host 248 relinquishes send state with either the CDI or the EBI set in the 249 SNA RU header. 251 It is valid for the server to send a null 3270-DATA message (TN3270E 252 header and EOR, no data) to indicate the send state to the client. 253 This allows the server and client to handle a NULL RU containing EBI 254 or CDI received from the host. 256 The server ignores SDI in messages from the client and processes any 257 data as usual depending on data type. 259 When SDI is received by the client and the current TN3270E message 260 has been processed (upon receipt of EOR) the client may send data to 261 the server. If RESPONSES have been negotiated, the client must send 262 RESPONSES to the server regardless of the send state. Upon receipt 263 of SDI, the client must send all pending RESPONSE messages before 264 sending any keyboard input to the server. 266 SDI is not a replacement for the 3270 data stream WCC Keyboard 267 Restore bit. The client must track the 3270 WCC Keyboard Restore 268 flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to determine 269 whether or not it can start sending data to the server. If keyboard 270 restore (WCC or KRI) is received, the keyboard input must still be 271 buffered until the SDI is received. 273 The client may send an ATTN key (IAC IP) regardless of the keyboard 274 State, including input inhibited state. ATTN causes the server to 275 send a SIGNAL to the host requesting Change Direction. This may 276 allow the user to recover from a direction state timing or 277 synchronization problem (i.e. server neglected to send SDI). The 278 client should avoid subsequent ATTN keys until it receives direction 279 from the host. The server may disregard successive ATTN keys while 280 waiting for the first ATTN to be processed and direction is yield by 281 the host. 283 The client may also send SYSREQ (if enabled by TN3270E function 284 negotiation) to override the input inhibit state. This allows the 285 user to switch to SSCP-LU session (possibly to logoff). 287 The RESET key is used to clear local terminal and X-SYSTEM error 288 conditions. RESET purges all buffered (type-ahead) keystrokes, 289 except when entered to remove terminal Insert mode. In this case, a 290 second RESET is required to purge the type-ahead buffer. RESET does 291 restore the keyboard allowing the user to begin typing buffered 292 keystrokes. However, it does NOT clear the X-CLOCK condition or 293 allow the client to override the send state and forward data to the 294 server. 296 4.5.2 Keyboard Restore Indicator (KRI) 298 To use the Keyboard Restore Indicator the CONTENTION-RESOLUTION 299 Function must be supported by and agreed upon by both the server and 300 Client during TN3270E function negotiations. KRI is only valid for 301 TN3270E terminals in PLU-SLU session (3270-DATA type mode). 303 KRI is meaningful only when sent by the server. KRI is sent in the 304 REQUEST-FLAG field of the TN3270E header. The KRI bit mask is: 306 KEYBOARD-RESTORE-MASK 0x02 308 A bit value of 1 (true) indicates to the client that its keyboard 309 has been restored. The client's X-CLOCK indicator is turned off, 310 allowing the user to enter data. However, the client may not 311 send data to the server until it has also received SDI from the 312 server (which may be set in the same REQUEST-FLAG field). 314 Logically, the client treats KRI the same as it does the 3270 WCC 315 Keyboard Restore bit. KRI is not a replacement for the 3270 data 316 stream WCC Keyboard Restore bit. The client must still track both 317 the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard 318 state. Normally, one or the other will be received. However, the 319 client should not balk if both are received on a 3270-DATA message. 321 The server ignores KRI in messages from the client and processes any 322 data as usual depending on data type. 324 The server sends KRI when it detects an "implied" keyboard restore 325 during LU-LU session. The server must track whether the host 326 application has explicitly set the keyboard restore bit of the 327 WCC byte in any of the 3270 data streams during a bracket. If not, 328 the server must set KRI in the TN3270E message header when EB is set 329 in the SNA header. 331 It is valid for the server to send a null 3270-DATA message (TN3270E 332 Header and EOR, no data) to indicate the KRI to the client. This 333 allows the server and client to handle a NULL RU containing EBI 334 received from the host. 336 4.5.3 BID Data Type 338 To use the BID data type the CONTENTION-RESOLUTION function must be 339 supported by and agreed upon by both the server and client during 340 TN3270E function negotiations. The BID data type message is only 341 valid on terminal sessions in 3270-DATA (LU-LU) mode. The BID data 342 type is not valid during SSCP-LU mode, NVT mode, or on printer 343 sessions. 345 The BID DATA-TYPE code is defined as: 347 Data-type Name Code Meaning 348 -------------- ---- ------------------------------------------- 349 BID 0x09 The server indicates that the host has sent 350 an implicit or explicit BID by sending this 351 data type to the client. 353 The server sends the new TN3270E BID data type to the client upon 354 receipt of either an implicit or an explicit BID from the host. The 355 server must never send BID to the client when the host already has 356 direction (holds send state). 358 To send the BID data type the server inserts the BID data type in 359 the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in 360 the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the 361 RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER. The server 362 should use the next number in the progression of sequence numbers. An 363 End-of-Record (EOR) is appended immediately after the TN3270E header 364 (there is no data portion for a BID message). 366 The BID data type must always receive a response from the client 367 regardless of whether the RESPONSES function is supported on the 368 session. The client's positive or negative response to a BID should 369 be exactly the same as those defined in the TN3270 Enhancements RFC, 370 unless the SNA Sense Code Function (defined in section 6) is used by 371 the client to communicate a more specific code. The SEQ-NUMBER is 372 returned by the client in its response, to allow the server to 373 coordinate the response with the BID. 375 When the client receives a BID message it is accepted by returning 376 a positive response, or rejected by returning a negative response. 377 The format of a positive response is the same as the positive 378 response defined for the TN3270E RESPONSES function (i.e., RESPONSE 379 data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER 380 from BID). When the client accepts the BID the keyboard state goes 381 to input inhibited, the client displays the X-CLOCK symbol and may 382 not send data until SDI is received from the server. 384 When the server receives a BID response from the client, it is 385 responsible for constructing the appropriate SNA response to the host. 387 If the client already has buffered data to be sent to the host the 388 client can reject the BID. The negative response uses the TN3270E 389 RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code 390 in RESPONSE-FLAG field, SEQ-NUMBER from BID). Unless the client 391 supports the SNA Sense Codes function, there is no defined reason 392 information in the data portion of the negative response. The 393 server rejects the host's BID with a "Bracket Bid Reject" sense code 394 (0x08130000). The client's send state should remain unchanged upon 395 negatively responding to a BID (i.e. if send state is input 396 inhibited, it stays that way). 398 If the client supports the SNA Sense Code function, it has the 399 option of returning "Receiver in Transmit Mode" (0x081B0000) sense 400 code. This may be returned to reject the Bid when the user has 401 started typing data but has not yet pressed an AID key. 403 A potential race condition exists, where the client sends data at 404 the same time the server is sending a BID to the client. The race 405 condition is handled by the server, and is relatively transparent to 406 the client. When the server receives data before the expected 407 response to the BID, the data is treated as an implied negative 408 response. The server sends the Bracket Bid Reject (0x08130000) 409 negative response to the host's BID and forwards the client's data 410 to the host. When the client's response to the BID is received it 411 is discarded by the server. The client's keyboard state should be 412 input inhibited, whether it responded positively or negatively to 413 the BID, because it has not received SDI for the data it sent 414 previously. 416 4.5.4 SIGNAL Indicator 418 To use the SIGNAL indicator the CONTENTION-RESOLUTION function must 419 be supported by and agreed upon by both the server and client during 420 TN3270E function negotiations. The SIGNAL indicator is only valid 421 on BID data type messages. The SIGNAL indicator is sent in the 422 REQUEST-FLAG field of the TN3270E header. 424 The SIGNAL bit mask is: 426 SIGNAL-MASK 0x04 428 A bit value of 1 (true) indicates that a Signal has been received 429 from the PLU. Therefore the BID is "Forced" and the client MUST 430 forfeit the send state. 432 The client must always respond to a BID with the SIGNAL indicator, as 433 described in the BID section. It is not necessary for the client to 434 echo the SIGNAL indicator in its response. However, the server 435 should not balk if the client does echo the SIGNAL indicator. The 436 server must maintain in it's state machine that it is awaiting a 437 response to a SIGNAL indicator. 439 When a Signal is received from the PLU the TN3270E Server's 440 behavior may be summarized as follows: 442 Send positive response to the host for the Signal 443 If the host already has direction, or in contention state. . . 444 there is nothing more to do 445 Else client has direction. . . 446 send BID with Signal to client and wait for reply or data 447 If data received first. . . 448 forward data to host as normal (will carry CD) 449 Else response received first. . . 450 send null RU CD to Host (with BB if necessary) 452 Upon receipt of Signal from the host, the server returns positive 453 response to the host, regardless of whether the host or client holds 454 direction. If the host holds direction (send state), there is 455 nothing more to be done. The client should already be awaiting data 456 from the host. 458 If the client holds direction, the server sends a BID with the 459 SIGNAL indicator set to inform the client that it no longer holds 460 send state and its keyboard state is input inhibited. The server 461 will receive either data or a positive response from the client. 463 The server forwards any inbound data from the client to the host, 464 while awaiting response to the signal BID. The inbound data record 465 will cause the direction (CD) state to return to the host. When the 466 positive response is received from the client the server has nothing 467 further to do. 469 If the server receives only a response from the client, the server 470 sends a null RU with Change Direction (CD) to the host. The client 471 MUST return positive response to the server. If the client sends 472 negative response to a SIGNAL, even though it is not allowed to do 473 so, the server treats it as a positive response and handles it 474 accordingly. 476 The Client's behavior when a BID containing the Signal indicator is 477 summarized as: 479 Receive BID with Signal indicator 480 If client has direction and buffered keystrokes with AID. . . 481 send first AID buffer 482 Else host has direction (race condition) or no AID. . . 483 the buffered keystrokes are left unchanged 484 Return positive response to Signal 485 Enter X-CLOCK input inhibited mode 486 Buffer any keystrokes/AID typed after the Signal 488 A Signal does not cause the client to purge any buffered keystrokes. 489 If the client holds direction when the Signal is received, it may 490 send one buffered AID message (if any) before sending positive 491 response to the Signal. If the Host already had direction (race 492 condition) or no AID key is buffered, the type-ahead buffer is 493 retained, as is. 495 The client then accepts the BID, and enters input inhibit mode. No 496 further buffered data may be forwarded to the host until direction 497 is returned to the client. 499 The following diagram illustrates how the client should handle 500 buffered keystrokes relative to BID/SIGNAL processing: 502 |<--- Data typed before BID --->|<--- Data typed after BID --->| 503 | is displayed on the screen. | is NOT displayed on screen. | 505 This allows the host application to do a Read Buffer, update the 506 portion of the screen it wants to change, put the cursor back to the 507 right place for the suspended input and restore the keyboard. The 508 client then streams the buffered keystrokes into the screen image. 509 Upon completion of these processes the screen image should be 510 restored correctly. 512 5. Function Management Header (FMH) Support Function 514 Function Management Headers are not permitted in LU2 or LU3. 515 Initially, they were not used in LU1 either. Consequently, no 516 provision was made for them in TN3270 or TN3270E. Subsequently, 517 support for FMHs over LU1 has been added to SNA based applications 518 and devices. Requirements to support LU1 DBCS (Kanji etc.) and 519 IPDS printer applications are driving this effort for TN3270E FMH 520 support. 522 A de facto standard has arisen for handling Structured Field data 523 stream FMHs in both TN3270 and TN3270E. This de facto standard is 524 referred to below as "silent FMH support". Only FMH1 is supported 525 and merely forwarded, in both directions, as data. The receiver 526 must recognize that the FMH is present by inspecting the first few 527 bytes of the Telnet record and determining that they do not look 528 like valid SCS data. This is workable because FMH1 is a fixed 529 6-byte string, and it only occurs at the start of a record. 531 The TN3270E FMH support function expands on silent FMH support by 532 adding a mechanism for transferring FMHs through a server using a 533 new TN3270E FMH data type. The main argument for adding this 534 function is to allow clients and servers to formally determine 535 whether the other side can "really" support FMH flows. Since, this 536 functionality is negotiable, client/server vendors can make the 537 determination of the merits of knowing whether the other side truly 538 supports LU1 Function Management Headers. 540 5.1 FMH Overview 542 FMH usage in its simplest terms: 544 - There is only one FMH per chain, starting at the beginning of the 545 chain. 546 - The FMH may be spread over multiple RUs if too long for one. The 547 Format Indicator (FI) is 1 in the BC RU and 0 in the rest. 549 At the next level of complexity: 551 - There may be multiple FMHs, consecutively, at the start of the 552 chain. 553 - The presence of an FMH following the current one is indicated by 554 the concatenation flag at byte 1, bit 0 of the current. 555 - As with a single FMH, these FMHs may continue over several RUs, 556 but only the first RU has the FI flag on. FI=0 on subsequent RUs. 558 The concatenation flag in the preceding FMH is sufficient to 559 introduce it. However, the description of FMHs in [2] only requires 560 a (concatenated sequence of) FMH to start at the start of an RU, not 561 necessarily at the start of a chain. It states that any RU in the 562 chain may have the FI flag on and thus start with an FMH, though the 563 preceding RU ended with ordinary data. 565 This would be awkward for TN3270E, since the RU boundaries are not 566 visible to the clients. Fortunately, it is awkward for higher-level 567 Host applications also, e.g. CICS and IMS applications. These 568 generally do not see RU boundaries either. Moreover, it is 569 contradicted by the description of sense code 400F in [2]. So it is 570 not surprising that the 3174 does not support this generality. 572 5.1.1 LU1 FMH1 Support 574 LU1 supports only FMH1. By default, LU1 sessions use SCS data 575 stream. FMH1 is used to introduce support for an alternate data 576 stream. 578 The FMH1 format is: 580 byte 0 | 1 | 2 | 3 | 4 .. n 581 +------------------------------------------------------------ 582 |length|concat| type |medium|subaddr|flags| DSP | DSSEL 583 +------------------------------------------------------------ 584 bits 8 1 7 4 4 4 4 3 586 Where: 587 length FMH length = (n+1) 588 concat Concatenation Flag = (0) 589 type FMH Type (FMH1 = 1) 590 medium (console = 0) 591 subaddr (0) 592 flags Bit 0 - Send/Receive Indicator (SRI: Send=0, Receive=1) 593 DSP Data-stream Profile 594 - 0xB = Structured Field Data Stream 595 - 0xD = IPDS Data Stream 596 DSSEL Destination Selection 598 5.1.2 Usage of DSSEL in FMH1 600 FMH1 describes the data-stream of accompanying data. The 601 accompanying data can be in a single chain (BEDS) or spread over 602 multiple chains (BDS ... EDS). For TN3270E, the client is only able 603 to support BEDS for inbound FMHs, because the server will assume CD 604 at the end of each chain. 606 It is also possible to abort the data-stream (ADS instead of EDS), 607 suspend a data-stream (SDS), and resume it later (RDS). In practice 608 SDS/RDS are only used to insert console output into a longer 609 transfer of data. 611 The entire data-stream must be within a bracket. If EB occurs after 612 BDS but before EDS then the data-stream is implicitly aborted. 614 5.1.3 Structured Field Data Stream 616 This is used by DBCS and IPDS printers so that a Read Partition 617 Query exchange can be conducted with an LU1 printer. (See [1].) 619 Outbound FMH1: 0x0601000B6000 620 Inbound FMH1: 0x0601008B6000 (SRI bit on) 622 BC RU 623 length = 6 624 concat = 0 625 DSP = 0xB 626 DSSEL = BEDS 628 Since the DSSEL = BEDS, the Structured Field data-stream is from the 629 end of the FMH to the end of the chain. 631 The usage is bi-directional, but always as one from the host 632 application and a reply from the secondary. 634 5.1.4 IPDS Data Stream 636 (See [4].) 638 Usage: 0x0601300D4000, 0x0601300D2000 640 OIC RU 641 length = 6 642 concat = 0 643 DSP = 0xD 644 DSSEL = BDS, EDS 645 No data following FMH in the same chain. 647 Although no ADS is sent, an EB before EDS implicitly aborts the data 648 stream. 650 5.2 FMH Data Type 652 To use the FMH data type the FMH-SUPPORT function must be 653 supported by and agreed upon by both the server and client during 654 TN3270E function negotiations. The FMH data type message is only 655 valid on LU1 printer sessions in SCS-DATA mode. The FMH data 656 type is not valid during SSCP-LU mode, NVT mode, or on terminal or 657 LU3 (DCS) printer sessions. The FMH DATA-TYPE code is defined as: 659 Data-type Name Code Meaning 660 -------------- ---- ------------------------------------------- 661 FMH-DATA 0x0A The sender indicates that the data portion 662 of the message contains one or more Function 663 Management Headers. 665 The FMH-DATA data type is bi-directional, meaning both the client 666 and server can send this data type. 668 5.3 Server Implementation 670 If the FMH function has been negotiated, the server forwards the FMH 671 data as part of the record, just as for normal data, and sets the 672 FMH-DATA type in the TN3270E header. 674 If the FMH function was not negotiated the server may send the same 675 with the SCS-DATA type. This maintains backward compatibility for 676 servers that invoke silent FMH support. 678 There is a trade-off between making many data checks in the server, 679 thereby keeping the client interface simple, and minimizing the 680 server's knowledge of the data-stream, thereby preserving 681 flexibility. This proposal takes the latter approach. In 682 particular, except for silent FMH support, the server does not know 683 which FMH types the client supports. 685 5.3.1 Bind Processing 687 Since TN3270E does not permit the client to reject the Bind, the 688 server must police the bind parameters as far as possible. 690 If the server receives an LU1 Bind with byte 6 bit 1 set to 1 (FMHs 691 will be used), but the client has not negotiated FMH function, then 692 the server may choose to reject the Bind with sense 0x08350006. 693 This is left optional (perhaps on customer configuration) in order 694 to accommodate silent FMH support. However, when providing such 695 support, the server is recommended to perform additional checks on 696 the data, as outlined below. 698 5.3.2 Host/Server Flow 700 When the server receives an RU from the host application on an LU1 701 session FI = 1 and category = FMD, the server checks that the FMH is 702 supported in principle. The server returns 0x400F0000 sense code if 703 the Bind did not indicate FMHs or the FMH is not at the beginning of 704 a chain. When providing silent FMH support to the client, the 705 server may make the following optional checks, in this order: 707 Sense Code Cause 708 ---------- ----- 709 0x10082009 Invalid header length (must be 6). 710 0x1008C000 Invalid FMH type (must be 1). 711 0x10086006 Invalid Data-stream Profile (must be 0xB or 0xD). 712 0x10080000 Other invalid parameters in FMH. 714 Example: 715 0x0601000B6000 716 0x0601300D4000 717 0x0601300D2000 719 The server either sends a negative response to the Host application 720 or forwards the data to the client. 722 Note: If neither the FMH nor the SNA-SENSE functions are negotiated 723 then it is recommended that the server only permit a specific list 724 of FMHs from the Host. 726 The existing function is to send EOJ to the client. There is no 727 change required here. 729 5.3.3 Client/Server Flow 731 When the server receives an FMH-DATA record from the client, it 732 forwards the record to the Host application with FI set in the Begin 733 Chain RU. 735 If the server receives a message FMH-DATA type but the FMH function 736 was not negotiated, the server may choose either of two actions: 738 - Terminate the LU-LU session. It is suggested that, if BIND was 739 negotiated, the UNBIND should carry a reason code of 0xFE. 740 (If some future extension allows for SNA sense codes to flow to 741 the client in the unbind image, the code to be used here should 742 be 0x400F0000.) 744 - Behave, for that message only, as though FMH function was 745 negotiated. 747 The server is not required to validate FMH-DATA messages received 748 from the client. 750 If the server has sent a silent FMH (SCS-DATA type) to the client, 751 the server must compare the first 6 bytes of the data for being 752 0x0601008B6000. If so, it sets FI in the Begin Chain RU. 754 5.3.4 FMH Responses 756 If SNA-SENSE-CODE is not supported, and the client returns a 757 negative response to a silent FMH (SCS-DATA) or FMH-DATA type, the 758 server is unable to determine whether the client objects to the FMH or 759 the ensuing data. However, of the identified FMHs requiring support, 760 only the Structured Field Data Stream can have data in the same 761 chain. Even then, the cause of the rejection is likely to be that 762 the client does not support FMHs. Therefore, it is recommended to 763 the server interpret the negative response as a rejection of the FMH 764 itself. The server should send negative response with 0x10080000 765 Sense code to the Host. 767 If SNA-SENSE-CODE is supported the server takes the first four bytes 768 of data following the TN3270E header as an SNA sense code and sends 769 these, unchanged and unchecked, in the negative response to the host. 770 There are many SNA sense codes associated with FMH errors that the 771 client may return. Most are at the application level and begin with 772 0x1008. 774 In addition to codes previously defined, below are some common FMH 775 Sense codes: 777 Sense Code Cause 778 ---------- ----- 779 0x10080000 Invalid parameters in FMH. 780 0x08350006 Bind has byte 6 bit 1 set to 1 (FMHs will be used) but 781 printer does not support FMHs. 782 0x400F0000 Incorrect use of FI (not BC RU), or Bind error 783 (byte 6/bit 1 set to 0). The FI flag is not echoed 784 in the SNA response. 786 5.4 Client Implementation 788 A client that negotiates FMH function takes responsibility for 789 validating the FMH-DATA messages. If an error is found in a 790 received FMH, the client must send a NEGATIVE-RESPONSE. 792 If SNA-SENSE has been negotiated, the SNA-SENSE is set in the 793 Response header field with the appropriate 4-byte SNA sense code in 794 data field. Otherwise, the response field is set to NEGATIVE- 795 RESPONSE and the data field contains the one byte Command Reject 796 (0x0) status code. 798 A client that negotiates the FMH function must set FMH-DATA type on 799 all records it sends that start with an FMH. 801 If a client receives EOJ after BDS and before EDS then the client 802 should infer ADS. 804 6. SNA Sense Code Function 806 This function is intended for SNA TN3270E environments only. 807 Non-SNA server implementations should ALWAYS disable this function 808 during TN3270E function negotiations. 810 When the server and client operate in an SNA environment, it is 811 impractical to perpetuate the one-byte error code mapping style of 812 TN3270E. Especially, when SNA already provides a table of defined 813 Sense codes. The SNA Sense Code function allows the client to 814 return SNA Sense codes to the server, which are in turn forwarded to 815 the SNA Host as a negative response. 817 The client indicates that the data portion of the response message 818 contains a 4-byte SNA sense code by setting the following code in 819 the RESPONSE-FLAG field: 821 SNA-SENSE-CODE 2 823 The SNA-SENSE function may be negotiated on either terminal or 824 printer sessions. When the SNA-SENSE and RESPONSES functions have 825 been negotiated, the server is committed to accepting SNA-SENSE-CODE 826 responses to 3270-DATA, SCS-DATA (LU1), BID and FMH-DATA data type 827 messages. 829 The client retains the option of providing specific SNA Sense codes, 830 or letting the server map all errors to the appropriate SNA sense 831 codes. 833 7. TN3270E Header Byte-doubling Suppression Function 835 A performance bottleneck facing Telnet server and client vendors is, 836 any 0xFF within an outbound data stream must be byte-doubled (a 837 second 0xFF inserted into the data stream) by the sender in order to 838 differentiate actual data from Telnet IAC commands. The receiver of 839 the data stream must then scan through the data stream removing the 840 inserted 0xFF bytes. With header-based protocols, like TN3270E, 841 Telnet byte-doubling forces the header to be variable length, to 842 allow for any 0xFF bytes that may occur within the header. 844 From discussions on the TN3270E list, it was determined that Telnet 845 Byte-doubling Suppression would best be handled outside of the 846 TN3270E standard as a new Telnet negotiated option. This will allow 847 other block mode protocols (i.e. traditional TN3270, and TN5250) to 848 take advantage of the proposed option. 850 However, the variable length header issue is within the scope of the 851 TN3270E standard. This draft proposes a method to make the TN3270E 852 header fixed length by eliminating byte-doubling of the 5 header 853 bytes. This function will extend the TN3270E standard to address 854 this issue. Although this function is proposed in anticipation of a 855 new Suppress Byte-doubling Telnet option, it is intended to be 856 independent of whether such a Telnet option is negotiated. 858 When the SUPPRESS-HEADER-BYTE-DOUBLING function is enabled the 859 TN3270E header will never be byte-doubled in either direction 860 (client to server/server to client). Therefore, the size of the 861 TN3270E header will ALWAYS be 5 bytes when the Header Byte-doubling 862 function is in effect. 864 The sender of a TN3270E message guarantees that the first five 865 (header) bytes of the record will not contain any embedded Telnet 866 commands. The sender must byte-double the data portion of the 867 TN3270E message. 869 The receiver of the message must validate that the message received 870 does begin with a valid TN3270E header, to avoid misinterpreting 871 asynchronous Telnet command packets between TN3270E records. The 872 receiver must also be cognizant of whether a TN3270E header is 873 expected to avoid problems that may occur if bytes in the middle of 874 a chain of buffers are not scanned properly. When the receiver has 875 determined that a valid TN3270E header is present it must skip past 876 the header to begin scanning for byte-doubled 0xFF characters. 878 8. References 880 [1] IBM's "3174 Functional Description", Bookshelf book CN7A7003, 881 GA23-0218-11. 882 [2] IBM's "Systems Network Architecture Formats", GA27-3136-14. 883 [3] RFC 2355 884 [4] IBM's "IPDS and SCS Technical Reference", S544-5312-00. 886 9. Term Definitions 888 This section defines some of the terms used in this document. 890 Input Inhibited - 891 a state where the client does not hold send state. Either the 892 client has presented an AID message to the host or the host has 893 gained direction via the BID process. The keyboard state is any 894 of the type-ahead or keyboard disabled states. 896 Only SYSREQ or ATTN may be forwarded to the server while the 897 client is in Input Inhibited state. SYSREQ and ATTN should never 898 be buffered by the client. 900 Keyboard Disabled - 901 a keyboard state where keystrokes may NOT be buffered by the 902 client. Keyboard disabled states include (X-f), etc. 904 Keyboard States - 905 define the various modes a keyboard may be in during a TN3270E 906 session. 908 When the client holds send state the keyboard is in Ready state. 909 The client is free to process all keyboard input and forward any 910 entered or buffered AID data to the server. 912 An Input Inhibited state is entered when the client surrenders 913 send state by sending an AID buffer or granting a BID request 914 from the host. 916 The diagram below summarizes the various keyboard states: 918 ------------------------------------------------------------- 919 Ready | Input Inhibited 920 |----------------------------------------------------- 921 | Type-ahead | Keyboard Disabled 922 |----------------------------+------------------------ 923 | X-CLOCK | X-SYSTEM | . . . | X-f | . . . 924 ------------------------------------------------------------- 926 Type-ahead - 927 is a state in which the client (terminal) may buffer keystrokes 928 when the keyboard is an Input Inhibited state. Displayed 929 keyboard state may be either X-CLOCK (Time) or X-SYSTEM (System 930 Lock). Keystrokes (text and AID keys) are buffered waiting for 931 send state to be returned to the client. 933 10. Abbreviations 935 ADS Abort Destination Selection, value of DSSEL 936 BB Begin Bracket, byte 2 bit 0 of RH of BC RU 937 BC Begin chain, byte 0 bit 6 of RH 938 BC RU An RU with BC = 1 939 BDS Begin Destination Selection, value of DSSEL 940 BEDS Begin and End Destination Selection, value of DSSEL 941 DCA Document Content Architecture 942 DSP Data-stream Profile, byte 3 bits 4-7 of FMH 943 DSSEL Destination Selection, byte 4 bits 0-2 of FMH 944 EB End Bracket, byte 2 bit 1 of RH of BC RU 945 EC End chain, byte 0 bit 7 of RH 946 EC RU An RU with EC = 1 947 EDS End Destination Selection, value of DSSEL 948 FI Format Indicator, byte 0 bit 4 of RH 949 FIC First In Chain - an RU with BC = 1 and EC = 0 950 FMD Function Management Data (user data, not FMH) 951 FMH Function Management Header, a SNA data header 952 IPDS Intelligent Printer Data Stream 953 LIC Last In Chain - an RU with BC = 0 and EC = 1 954 LU Logical Unit 955 LUn Logical Unit Type n, n = 0, 1, 2, etc. 956 MIC Middle In Chain - an RU with BC = 0 and EC = 0 957 OIC Only In Chain - an RU with BC = 1 and EC = 1 958 RDS Resume Destination Selection, value of DSSEL 959 RH Request Header, 3 byte header on SNA RU 960 RU Request Unit, an SNA frame starting with an RH 961 SDS Suspend Destination Selection, value of DSSEL 962 SNA Systems Network Architecture 964 11. Conventions 966 - Byte order is big-endian, e.g. bit 0 is the most significant bit. 968 12. Author's Note 970 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 (OpenConnect 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 Address 984 Gene Pullen Marty Williams 985 gbp@openconnect.com martyw@cisco.com 986 OpenConnect Systems Cisco Systems 987 2711 LBJ Freeway 7025 Kit Creek Rd. 988 Dallas, TX 75234 Research Triangle Park, NC 27709-4987 990 Draft Expiration Date: November 2000