idnits 2.17.1 draft-clark-telnet-control-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '5' on line 660 looks like a reference -- Missing reference section? '1' on line 649 looks like a reference -- Missing reference section? '6' on line 662 looks like a reference -- Missing reference section? '2' on line 651 looks like a reference -- Missing reference section? '3' on line 654 looks like a reference -- Missing reference section? '4' on line 657 looks like a reference -- Missing reference section? '7' on line 307 looks like a reference -- Missing reference section? '8' on line 354 looks like a reference -- Missing reference section? '9' on line 409 looks like a reference -- Missing reference section? '10' on line 456 looks like a reference -- Missing reference section? '11' on line 501 looks like a reference -- Missing reference section? '12' on line 555 looks like a reference -- Missing reference section? '13' on line 601 looks like a reference -- Missing reference section? '14' on line 633 looks like a reference -- Missing reference section? '15' on line 665 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 3 Network Working Group Glen Clark 4 Request for Comments: nnnn Cisco Systems, Inc. 5 Category: Standards Track July 1997 6 Revision: 0006 8 Telnet Com Port Control Option 9 11 Preamble: 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To learn the current status of any Internet-Draft, please check 24 the "1id-abstracts.txt" listing containing in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Status Section: 30 This document specifies an Internet standards track protocol for the 31 Internet community, and requests discussion and suggestions for 32 improvements. Please refer to the current edition of the 33 "Internet Official Protocol Standards" (STD 1) for the 34 standardization state and status of this protocol. Distribution of 35 this memo is unlimited. 37 Introduction Section: 38 This memo proposes a protocol to allow greater use of modems 39 attached to a network for outbound dialing purposes. 41 Discussion: 42 The Telnet protocol defines an interactive, character-oriented 43 communications session. It was originally designed to establish 44 a session between a client and a remote login service running 45 on a host. [5] 47 Clark Page [1] 48 RFC: NNNN Telnet Com Port Control Option July, 1997 50 Many new business functions require a person to connect to remote 51 services to retrieve or deposit information. By in large, these 52 remote services are accessed via an async dial up connection. 53 This new class of functions include: 54 - dial up connections to the Internet 55 - connecting to bulletin boards 56 - connecting to internal and external databases 57 - sending and receiving faxes. 59 The general nature of this new class of function requires an 60 interactive, character-oriented communications session via an 61 async modem. This is typically known as outbound modem dialing. 63 To help defer the cost of installing and maintaining additional 64 phone lines which may be used very little per person, many equipment 65 manufacturers have added the ability to establish a Telnet session 66 directly to the outbound ports on many of the most popular access 67 servers and routers, here after referred to as access servers. 69 However, the current Telnet protocol definitions are not sufficient 70 to fully support this new use. There are three new areas of 71 functionality which need to be added to the Telnet protocol to 72 successfully support the needs of outbound modem dialing. 73 These are: 74 - The ability for the client to send com port configuration 75 information to the access server which is connected to the 76 outbound modem. This is needed to ensure the data being 77 transmitted and received by the modem is formatted correctly 78 at the byte level. 80 - The ability for the access server to inform the client of any 81 modem line or signal changes such as RLSD changes (carrier 82 detect). This information is vital, since many client software 83 packages use this information to determine if a session with the 84 remote service has been established. RLSD changes are also 85 used for signaling in Class I faxing [6]. 87 - The ability to manage flow control between the client and 88 the access server which does not interfere with the flow 89 control mechanisms used by the session between the client and 90 the remote service. Unfortunately RFC 1372 "Telnet Remote 91 Flow Control Option" [2] can not be used for this purpose 92 because it relies on sending XON/XOFF style characters which 93 maybe transmitted or received as a normal course of the 94 client / remote service session. 96 Clark Page [2] 97 RFC: NNNN Telnet Com Port Control Option July, 1997 99 Though this discussion has focused on outbound modem dialing as 100 the primary use of this protocol, the protocol can also be used 101 for any serial device attached to an access server. 102 Such devices could be: 103 - serial printers 104 - plotters 105 - monitoring devices such as pipe line monitors or medical 106 monitors 107 - general office equipment such as photo-copiers and cash 108 registers 110 Definition of Terms: 111 Access Server - Any network device which accepts Telnet sessions 112 and passes the data received to a com port, and 113 passes data received from the com port to the 114 client via the Telnet session. 116 Baud Rate - For the purposes of this document, baud rate will 117 mean the communications of data in bits per second. 119 Client - Any network device which initiates a Telnet session 120 to an access server. 122 Outbound - Transmission of data from the modem attached to the 123 access server to a remote service. 125 Inbound - Transmission of data from the remote service to the 126 modem attached to the access server. 128 Remove Service - Any service which accepts dial-up connections, 129 including fax machines. 131 Clark Page [3] 132 RFC: NNNN Telnet Com Port Control Option July, 1997 134 Illustration: 136 ===================== 137 | | 138 | CLIENT |\ 139 | | \ < ---- Local Area / Enterprise Network 140 ===================== \ 141 \ 142 \ 143 ============================= 144 | Telnet Interface | 145 | | | 146 | | | 147 | ACCESS SERVER | | 148 | | | 149 | | | 150 | Com Port Interface | 151 ============================= 152 | 153 | 154 ================== 155 | | 156 | MODEM | 157 | | 158 ================== 159 | 160 Access to Remove Service | 161 most commonly Public Switched ----->| 162 Network | 163 | 164 | 165 ====================== 166 Could be Internet Service | | 167 Provider, Bulletin Board | | 168 or FAX machine | REMOTE SERVICE | 169 | | 170 | | 171 ====================== 173 Clark Page [4] 174 RFC: NNNN Telnet Com Port Control Option July, 1997 176 Table of Contents 177 1. Negotiation of the Com Port 178 Control Option Protocol .................. 6 179 2. Com Port Configuration Commands .................. 6 180 Version 181 Baud Rate 182 Data Bit Size 183 Parity 184 Stop Bit size 185 3. Special Com Port Control Commands ................. 9 186 XON/XOFF Flow Control 187 HARDWARE Flow Control 188 BREAK Signal 189 DTR Signal 190 RTS Signal 191 4. Notification of Com Port and .................. 12 192 Modem Line Changes 193 5. Flow Control .................. 13 194 6. Security Considerations .................. 14 196 Command Names and Codes: 197 COM-PORT-OPTION 40 199 Client to Access Server Access Server to Client 200 SIGNATURE text text 201 SET-BAUDRATE 1 101 202 SET-DATASIZE 2 102 203 SET-PARITY 3 103 204 SET-STOPSIZE 4 104 205 SET-CONTROL 5 105 206 NOTIFY-LINESTATE 6 106 207 NOTIFY-MODEMSTATE 7 107 208 FLOWCONTROL-SUSPEND 8 108 209 FLOWCONTROL-RESUME 9 109 210 SET-LINESTATE-MASK 10 110 211 SET-MODEMSTATE-MASK 11 111 212 PURGE-DATA 12 112 214 Discussion: As initially proposed, com port configuration commands 215 are only sent from the client to the access server. 216 There is no current vision that the access server 217 would initiate the use of a com port configuration 218 command, only the notify commands. However, to allow 219 for access server initiated com port configurations 220 different command values have been established. 222 Clark Page [5] 223 RFC: NNNN Telnet Com Port Control Option July 1997 225 1. Negotiation of the Com Port Control Option Protocol 226 The negotiation of the com port control option protocol uses the 227 standard Telnet negotiation protocol mechanism: 229 IAC WILL COM-PORT-OPTION 230 The sender of this command is willing to send com port 231 control option commands. 232 IAC WONT COM-PORT-OPTION 233 The sender of this command refuses to send com port 234 control option commands. 235 IAC DO COM-PORT-OPTION 236 The sender of this command is willing to accept com port 237 control option commands. 238 IAC DONT COM-PORT-OPTION 239 The sender of this command refuses to accept com port control 240 options commands. 242 Typically a client will use WILL and WONT, while an access server 243 will use DO and DONT. 245 2. Com Port Configuration Commands 246 Once DO and WILL have been negotiated, the client may send any of 247 the following commands. The client can send these commands at any 248 time and multiple times throughout the Telnet session. Each 249 command transmitted from the client to the access server must be 250 acknowledged once the command has been processed by the access 251 server. This confirmation informs the client of the value set 252 at the access server after the processing of the command. 253 This acknowledgment is not used to acknowledge the receipt of 254 the command, which is handled at the TCP protocol layer. Its 255 purpose is to inform the client of the value in use, which may be 256 different than the value requested in the client's command. 257 For example, the client may request a baud rate higher than the 258 access service can provide. If an acknowledgment is not received 259 by the client within a reasonable time (such as twice the delay 260 acknowledgment timer), the client may wish to resend the command 261 or terminate the session. 263 Though the commands may be sent from the client to the access 264 server in any sequence, there are sequences which may result in 265 invalid configurations for the com port (for example: EVEN parity 266 is only valid if the data size is set to less than 8 bits). Thus 267 it is recommended that commands be issued in the following 268 sequence: 269 1. SET-BAUDRATE 270 2. SET-DATASIZE 271 3. SET-PARITY 272 4. SET-STOPSIZE 274 Clark Page [6] 275 RFC: NNNN Telnet Com Port Control Option July 1997 277 IAC SB COM-PORT-OPTION SIGNATURE IAC SE 278 This command may be sent by either the client or the access server 279 to exchange signature information. If the command is sent 280 without it is a request from the sender to receive 281 the signature text of the receiver. The text may be a 282 combination of any characters. There is no structure to the 283 field. It may contain manufacturer information, 284 version number information, or any other information desired. 285 If an IAC character appears in the text it must be translated to 286 IAC-IAC to avoid conflict with the IAC which terminates the 287 command. 289 IAC SB COM-PORT-OPTION SET-BAUD IAC SE 290 This command is sent by the client to the access server to set 291 the baud rate of the com port. The value is four octets (4 bytes). 292 The value is represented in network standard format. The value 293 is the baud rate being requested. A special case is the value 0. 294 If the value is zero the client is requesting the current baud 295 rate of the com port on the access server. 297 Discussion: Though baud rates used today form a very sparse space, 298 and the initial version of the option used an index 299 based baud rate table, after much discussion with a 300 number of groups it has been determined that the 301 actual baud rate should be used. There are two main 302 reasons. 1) It limits the number of updates to the 303 option as faster baud rates come into use, 304 2) It provides the greatest amount of flexibility 305 in the selection of the baud rates. 307 Clark Page [7] 308 RFC: NNNN Telnet Com Port Control Option July 1997 310 IAC SB COM-PORT-OPTION SET-DATASIZE IAC SE 311 This command is sent by the client to the access server to set the 312 data bit size. The command can also be sent to query the current 313 data bit size. The value is one octet (byte). The value is an index 314 into the following value table: 315 Value Data Bit Size 316 0 Request Current Data Bit Size 317 1 Available for Future Use 318 2 Available for Future Use 319 3 Available for Future Use 320 4 Available for Future Use 321 5 5 322 6 6 323 7 7 324 8 8 325 9-127 Available for Future Use 327 Discussion: There are only eight possible values for the data bit 328 size, only four have ever been used historically and 329 only two are commonly used today. The use of the 330 command-value format is recommended to preserve 331 consistency with other commands. It also reduces the 332 number of commands defined in the protocol, and allows 333 for future expansion. 335 IAC SB COM-PORT-OPTION SET-PARITY IAC SE 336 This command is sent by the client to the access server to set 337 the parity. The command can also be sent to query the current 338 parity. The value is one octet (byte). The value is an index into 339 the following value table: 340 Value Parity [1] 341 0 Request Current Data Size 342 1 NONE 343 2 ODD 344 3 EVEN 345 4 MARK 346 5 SPACE 347 6-127 Available for Future Use 349 Discussion: There are only five possible values for parity 350 commonly used today. The use of the command-value 351 format is recommended to preserve consistency with 352 other commands. 354 Clark Page [8] 355 RFC: NNNN Telnet Com Port Control Option July 1997 357 IAC SB COM-PORT-OPTION SET-STOPSIZE IAC SE 358 This command is sent by the client to the access server to set the 359 number of stop bits. The command can also be sent to query the 360 current stop bit size. The value is one octet (byte). The value 361 is an index into the following value table: 362 Value Stop Bit Size 363 0 Request Current Data Size 364 1 1 365 2 2 366 3 1.5 367 4-127 Available for Future Use 369 Discussion: Stop bit 1.5 is supported by most com port hardware 370 only if data size is set to 5 bits. It is not 371 commonly used. 373 3. Special Com Port Control Commands 374 The client can send this command to the access server at any time 375 and multiple times throughout the Telnet session. Each command 376 transmitted from the client to the access server is acknowledged 377 with a confirmation of the command and the actual value set. The 378 client should expect a response within a reasonable time (such as 379 twice the delay acknowledgment timer). The client may wish to 380 resend any command which is not acknowledged or terminate the 381 session. 383 IAC SB COM-PORT-OPTION SET-CONTROL IAC SE 384 This command is sent by the client to the access server to set 385 special com port options. The command can also be sent to query 386 the current option value. The value is one octet (byte). The 387 value is an index into the following value table: 388 Value Control Commands 389 0 Request Com Port Flow Control Setting 390 (outbound/both) 391 1 Use No Flow Control (outbound/both) 392 2 Use XON/XOFF Flow Control (outbound/both) 393 3 Use HARDWARE Flow Control (outbound/both) 394 4 Request BREAK State 395 5 Set BREAK State ON 396 6 Set BREAK State OFF 397 7 Request DTR Signal State 398 8 Set DTR Signal State ON 399 9 Set DTR Signal State OFF 400 10 Request RTS Signal State 401 11 Set RTS Signal State ON 402 12 Set RTS Signal State OFF 403 13 Request Com Port Flow Control Setting (inbound) 404 14 Use No Flow Control (inbound) 405 15 Use XON/XOFF Flow Control (inbound) 406 16 Use HARDWARE Flow Control (inbound) 408 (Table continues on next page) 409 Clark Page [9] 410 RFC: NNNN Telnet Com Port Control Option July 1997 412 17 Use DCD Flow Control (outbound/both) 413 18 Use DTR Flow Control (inbound) 414 19 Use DSR Flow Control (outbound/both) 415 20-127 Available for Future Use 417 Discussion: Flow control options were divided into inbound and 418 outbound to take full advantage of existing programming 419 interfaces and access server capabilities. 421 Discussion: The outbound values should set flow control for both 422 outbound and inbound. If inbound is to be, or can be, 423 set separately it should be done after the setting of 424 the outbound value. 426 Discussion: If the access server is not able to set inbound flow 427 control differently from the outbound flow control, it 428 should ignore the inbound flow control commands and 429 set the flow control option based on the outbound flow 430 control commands only. 432 IAC SB COM-PORT-OPTION SET-LINESTATE-MASK IAC SE 433 This command is sent by the client to the access server to set a 434 bit mask for the sending of the NOTIFY-LINESTATE option (see 435 section 4). When the LINESTATE changes on the access server, 436 the access server will "AND" the new LINESTATE with the 437 LINESTATE-MASK. If the result is not zero, the access server 438 will send the result of the "AND" as the value in a 439 NOTIFY-LINESTATE com port option. If more than one bit satisfies 440 the LINESTATE-MASK, only one NOTIFY-LINESTATE, with all the 441 satisfying bits, will be sent to the client. The 442 SET-LINESTATE-MASK may be any combination of bits as listed below. 443 These are the same bit values used in the NOTIFY-LINESTATE option. 444 The SET-LINESTATE-MASK values are based on the most popular UART 445 (com port control chip) in use. [1] 446 Bit Position Value Meaning 447 7 128 Time-out Error 448 6 64 Transfer Shift Register Empty 449 5 32 Transfer Holding Register Empty 450 4 16 Break-detect Error 451 3 8 Framing Error 452 2 4 Parity Error 453 1 2 Overrun Error 454 0 1 Data Ready 456 Clark Page [10] 457 RFC: NNNN Telnet Com Port Control Option July 1997 459 Discussion: The SET-LINESTATE-MASK value of 0 will prevent the 460 access server from sending NOTIFY-LINESTATE options 461 to the client. 463 Discussion: The SET-LINESTATE-MASK value of 255 will allow the 464 access server to send a NOTIFY-LINESTATE option to the 465 client each time the LINESTATE changes on the access 466 server. 468 Discussion: The initial LINESTATE-MASK at the access server is 0. 470 Discussion: The client does not have to send a new 471 SET-LINESTATE-MASK after receiving a 472 NOTIFY-LINESTATE. The LINESTATE-MASK on the access 473 server is retained until set by the client or reset at 474 the start of a new Telnet session. 476 IAC SB COM-PORT-OPTION SET-MODEMSTATE-MASK IAC SE 477 This command is sent by the client to the access server to set a 478 bit mask for the sending of the NOTIFY-MODEMSTATE option (see 479 section 4). When the MODEMSTATE changes on the access server, 480 the access server will "AND" the new MODEMSTATE with the 481 MODEMSTATE-MASK. If the result is not zero, the access server 482 will send the result of the "AND" as the value in a 483 NOTIFY-MODEMSTATE com port option. If more than one bit satisfies 484 the MODEMSTATE-MASK, only one NOTIFY-MODEMSTATE, with all the 485 satisfying bits, will be sent to the client. The 486 SET-MODEMSTATE-MASK may be any combination of bits as listed 487 below. These are the same bit values used in the 488 NOTIFY-MODEMSTATE option. The SET-MODEMSTATE-MASK values are 489 based on the most popular UART (com port control chip) in use. [1] 490 Bit Position Value Meaning 491 7 128 Receive Line Signal Detect 492 (also known as Carrier Detect) 493 6 64 Ring Indicator 494 5 32 Data-Set-Ready Signal State 495 4 16 Clear-To-Send Signal State 496 3 8 Delta Receive Line Signal Detect 497 2 4 Trailing-edge Ring Detector 498 1 2 Delta Data-Set-Ready 499 0 1 Delta Clear-To-Send 501 Clark Page [11] 502 RFC: NNNN Telnet Com Port Control Option July 1997 504 Discussion: The SET-MODEMSTATE-MASK value of 0 will prevent the 505 access server from sending NOTIFY-MODEMSTATE options 506 to the client. 508 Discussion: The SET-MODEMSTATE-MASK value of 255 will allow the 509 access server to send a NOTIFY-MODEMSTATE option to the 510 client each time the MODEMSTATE changes on the access 511 server. 513 Discussion: The initial MODEMSTATE-MASK at the access server is 255. 515 Discussion: The client does not have to send a new 516 SET-MODEMSTATE-MASK after receiving a 517 NOTIFY-MODEMSTATE. The MODEMSTATE-MASK on the access 518 server is retained until set by the client or reset at 519 the start of a new Telnet session. 521 IAC SB COM-PORT-OPTION PURGE-DATA IAC SE 522 This command is sent by the client to the access server to instruct 523 the access server to immediately clear all data from the buffer or 524 buffers referenced by the value. The value is one octet 525 (byte). The value is an index into the following value table: 526 Value Purge Data Buffer 527 0 Available for Future Use 528 1 Purge access server receive data buffer 529 2 Purge access server transmit data buffer 530 3 Purge both the access server receive data buffer 531 and the access server transmit data buffer 532 4-127 Available for Future Use 534 4. Notification of Com port and Modem Line Changes 535 The access server can send these commands to the client any time 536 and multiple times throughout the Telnet session. The access 537 server should send the appropriate command to the client as soon 538 as the com port or modem line changes occurs. The client does 539 not issue a response to these commands. 541 IAC SB COM-PORT-OPTION NOTIFY-LINESTATE IAC SE 542 The value is one octet (byte). The value is a bit level 543 composition made up from the value table below. Multiple bit 544 values may be set in a single transmission. The values are based 545 on the most popular UART (com port control chip) in use. [1] 546 Bit Position Value Meaning 547 7 128 Time-out Error 548 6 64 Transfer Shift Register Empty 549 5 32 Transfer Holding Register Empty 550 4 16 Break-detect Error 551 3 8 Framing Error 552 2 4 Parity Error 553 1 2 Overrun Error 554 0 1 Data Ready 555 Clark Page [12] 556 RFC: NNNN Telnet Com Port Control Option July 1997 558 Discussion: The LINESTATE is the line state of the UART on 559 the access server. 561 IAC SB COM-PORT-OPTION NOTIFY-MODEMSTATE IAC SE 562 The value is one octet (byte). The value is a bit level 563 composition made up from the value table below. Multiple bit 564 values may be set in a single transmission. The values are based 565 on the most popular UART (com port control chip) in use. [1] 566 Bit Position Value Meaning 567 7 128 Receive Line Signal Detect 568 (also known as Carrier Detect) 569 6 64 Ring Indicator 570 5 32 Data-Set-Ready Signal State 571 4 16 Clear-To-Send Signal State 572 3 8 Delta Receive Line Signal Detect 573 2 4 Trailing-edge Ring Detector 574 1 2 Delta Data-Set-Ready 575 0 1 Delta Clear-To-Send 577 5. Flow Control 578 The client and/or access server can send these commands any time 579 and multiple times throughout the Telnet session. 581 IAC SB COM-PORT-OPTION FLOWCONTROL-SUSPEND IAC SE 582 The sender of this command is requesting that the receiver suspend 583 transmission of both data and commands until the 584 FLOWCONTROL-RESUME is transmitted by the sender. 586 IAC SB COM-PORT-OPTION FLOWCONTROL-RESUME IAC SE 587 The sender of this command is requesting that the receiver resume 588 transmission of both data and commands. 590 Discussion: Established Telnet sessions are initially in a 591 resume state between the client and the access server 592 and the access server and the client. There is no 593 need to send the resume command during session 594 initialization. 596 Discussion: Multiple concurrent suspend commands may be sent. 597 Secondary suspend commands can be ignored. 598 Transmission will resume with the sending of a 599 single resume command. 601 Clark Page [13] 602 RFC: NNNN Telnet Com Port Control Option July 1997 604 Discussion: The flow control option is designed to handle client 605 to access server flow control for the Telnet session. 606 This option has been added in deference to 607 RFC 1372: Telnet Remote Flow Control Option [2]. 608 RFC 1372 uses a simple character XON/XOFF technology 609 to implement flow control. This can lead to two 610 problems. First, the flow control characters may 611 be valid data values. Second, the flow control 612 characters may be used for end to end flow control 613 (client application to remote dial up service). 615 6. Security Considerations 616 There are two security issues to discuss; authentication 617 and resetting resources. 619 Authentication can follow either the Kerberos authentication 620 protocol established in RFC 1411 [3] or the SPX authentication 621 protocol established in RFC 1412 [4]. 623 Once the Telnet session between the client and the access 624 server has been terminated, the access server should ensure 625 the connection to the remote service is disconnected and the 626 com port geometry (baud rate, data size, stop bits, parity, 627 and flow control) is reset to a factory or administrator defined 628 configuration. This ensures the com port is in a known state 629 and ready to receive the next client session. This will make 630 operations more predicable and avoid problems which might occur 631 from starting a new session with random com port configurations. 633 Clark Page [14] 634 RFC: NNNN Telnet Com Port Control Option July 1997 636 Author Address: 638 Glen Clark, Software Architect 639 Cisco Systems, Inc. 640 170 West Tasman Drive 641 San Jose, CA 96134 642 USA 644 Internet: glenc@cisco.com 645 WEB: www.cisco.com 647 Reference Section: 649 [1] Joe Campbell. C Programmer's Guide to Serial Communications, 650 Second Edition. Indianapolis: SAMS Publishing, 1993. 213-224. 651 [2] Internet Engineering Task Force, Telnet Working Group, 652 C. Hedrick and D. Borman, "Telnet Remote Flow Control Option", 653 RFC 1372, Cray Research, Inc., October 1992. 654 [3] Internet Engineering Task Force, Telnet Working Group, 655 D. Borman, "Telnet Authentication: Kerberos Version 4", 656 RFC 1411, Cray Research, Inc., January 1993. 657 [4] Internet Engineering Task Force, Telnet Working Group, 658 K. Alagappan, "Telnet Authentication: SPX", 659 RFC 1412, Digital Equipment Corporation, January 1993. 660 [5] D. E. Comer and David Stevens. Internetworking with TCP/IP, 661 Volume III. Prentice Hall, 1993. 662 [6] Andrew Margolis. The FAX Modem Sourcebook. John Wiley & Sons. 663 1995. 665 Clark Page [15]