idnits 2.17.1 draft-gellens-telnet-char-option-03.txt: ** The Abstract section seems to be numbered 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-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [O], [6], [TTABLE], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 194: '...(CHARSET ACCEPTED); it MUST NOT ignore...' RFC 2119 keyword, line 210: '...ences. After doing so, each side MUST...' RFC 2119 keyword, line 226: '... the server side MUST issue a negative...' RFC 2119 keyword, line 227: '... The client side MUST respond to the o...' RFC 2119 keyword, line 331: '... MUST be quoted to confo...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 299 has weird spacing: '... of the octet...' -- 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 (July 24, 1996) is 10137 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 510 looks like a reference -- Missing reference section? 'TTABLE' on line 568 looks like a reference -- Missing reference section? '2' on line 521 looks like a reference -- Missing reference section? '3' on line 197 looks like a reference -- Missing reference section? '6' on line 304 looks like a reference -- Missing reference section? '4' on line 509 looks like a reference -- Missing reference section? '5' on line 513 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Gellens 2 INTERNET DRAFT Unisys 3 July 24, 1996 4 Document: draft-gellens-telnet-char-option-03.txt 5 Postscript: draft-gellens-telnet-char-option-03.ps 7 TELNET CHARSET Option 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum 18 of six months and may be updated, replaced, or obsoleted 19 by other documents at any time. It is inappropriate to 20 use Internet-Drafts as reference material or to cite them 21 other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please 24 check the ``1id-abstracts.txt'' listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 A mailing list has been established for discussion of 31 this (and related) topics. To subscribe, send mail to: 32 telnet-request@mv.Unisys.com 34 Items for redistribution to the list should be sent to: 35 telnet@mv.Unisys.com 37 1. Abstract 39 This document specifies a mechanism for passing character 40 set and translation information between a TELNET client 41 and server. Use of this mechanism enables an application 42 used by a TELNET user to send and receive data in the 43 correct character set. 45 Either side can (subject to option negotiation) at any 46 time request that a (new) character set be used. 48 2. Command Names and Codes 50 CHARSET.......................xx 52 REQUEST ....................01 53 ACCEPTED ...................02 54 REJECTED ...................03 55 TTABLE-IS ..................04 56 TTABLE-REJECTED ............05 57 TTABLE-ACK .................06 58 TTABLE-NAK .................07 60 As a convenience, standard TELNET text and codes for 61 commands used in this document are reproduced here 62 (excerpted from [1]): 64 All TELNET commands consist of at least a two byte 65 sequence: the "Interpret as Command" (IAC) escape 66 character followed by the code for the command. The 67 commands dealing with option negotiation are three byte 68 sequences, the third byte being the code for the option 69 referenced. ... [O]nly the IAC need be doubled to be sent 70 as data, and the other 255 codes may be passed 71 transparently. The following are [some of] the defined 72 TELNET commands. Note that these codes and code 73 sequences have the indicated meaning only when 74 immediately preceded by an IAC. 76 NAME CODE MEANING 78 SE 240 End of subnegotiation parameters. 80 SB Indicates that what follows is 81 250 82 subnegotiation of the indicated 83 option. 85 WILL (option 251 Indicates the desire to begin 86 code) performing, or confirmation that 87 you are now performing, the 88 indicated option. 90 WON'T 252 Indicates the refusal to perform, 91 (option or continue performing, the 92 code) indicated option. 94 DO (option 253 Indicates the request that the 95 code) other party perform, or 96 confirmation that you are expecting 97 the other party to perform, the 98 indicated option. 100 DON'T 254 Indicates the demand that the other 101 (option party stop performing, or 102 code) confirmation that you are no longer 103 expecting the other party to 104 perform, the indicated option. 106 IAC 255 Data Byte 255. 108 3. Command Meanings 110 A very simple meta-syntax is used, where most tokens 111 represent previously defined items (such as IAC); angle- 112 brackets (``<>``) are used for items to be further defined; 113 curly-braces (``{}'') are used around optional items; 114 ellipses represent repeated sequences of items; and quotes 115 are used for literal strings. 117 IAC WILL CHARSET 118 The sender REQUESTS permission to, or AGREES to, use 119 CHARSET option subnegotiation to choose a character set. 121 IAC WON'T CHARSET 122 The sender REFUSES to use CHARSET option subnegotiation 123 to choose a character set. 125 IAC DO CHARSET 126 The sender REQUESTS that, or AGREES to have, the other 127 side use CHARSET option subnegotiation to choose a 128 character set. 130 IAC DON'T CHARSET 131 The sender DEMANDS that the other side not use the 132 CHARSET option subnegotiation. 134 IAC SB CHARSET REQUEST { ``[TTABLE]'' } IAC SE 137 Char set list: 139 { ... } 141 This message initiates a new CHARSET subnegotiation. It 142 can only be sent by a side that has received a DO CHARSET 143 message and sent a WILL CHARSET message (in either 144 order). 146 The sender requests that all text sent to and by it be 147 encoded in one of the specified character sets. 149 If the string [TTABLE] appears, the sender is willing to 150 accept a mapping (translation table) between any 151 character set listed in and any character 152 set desired by the receiver. 154 is an octet whose binary value is the highest 155 version level of the TTABLE-IS message which can be sent 156 in response. This field must not be zero. See the 157 TTABLE-IS message for the permitted version values. 159 is a sequence of 7-BIT ASCII printable 160 characters. The first octet defines the separator 161 character (which must not appear within any character 162 set). It is terminated by the IAC SE sequence. Case is 163 not significant. It consists of one or more character 164 sets. The character sets should appear in order of 165 preference (most preferred first). 167 is a separator octet, the value of which is chosen 168 by the sender. Examples include a space or a semicolon. 169 Any value other than IAC is allowed. The obvious choice 170 is a space or any other punctuation symbol which does not 171 appear in any of the character set names. 173 is a sequence of 7-BIT ASCII printable 174 characters. Case is not significant. 176 If a requested character set is registered with the 177 Internet Assigned Number Authority (IANA) [2], it is 178 required that the standardized spelling of its name or a 179 registered alias be used. While it is permitted to 180 request non-standard character sets such as those not 181 registered with IANA, this is strongly discouraged, as 182 such character sets are unlikely to be recognized by the 183 receiver of the CHARSET REQUEST message. Even worse, a 184 non-registered character set could have the same name as 185 some other character set which is registered. Each side 186 would then be using a character set different from that 187 expected by the other. 189 The receiver responds in one of four ways: 191 If the receiver is already sending text to and 192 expecting text from the sender to be encoded in one of 193 the specified character sets, it sends a positive 194 acknowledgment (CHARSET ACCEPTED); it MUST NOT ignore 195 the message. (Although ignoring the message is perhaps 196 suggested by some interpretations of the relevant RFCs 197 ([1], [3]), in the interests of determinacy it is not 198 permitted. This ensures that the issuer does not need 199 to time out and infer a response, while avoiding 200 (because there is no response to a positive 201 acknowledgment) the non-terminating subnegotiation 202 which is the rationale in the RFCs for the non-response 203 behavior.) 205 If the receiver is capable of handling at least one of 206 the specified character sets, it can respond with a 207 positive acknowledgment for one of the requested 208 character sets. Normally, it should pick the first set 209 it is capable of handling but may choose one based on 210 its own preferences. After doing so, each side MUST 211 encode subsequent text in the specified character set. 213 If the string [TTABLE] is present, and the receiver 214 prefers to use a character set not included in , and is capable of doing so, it can send a 216 translate table (TTABLE-IS) response. 218 If the receiver is not capable of handling any of the 219 specified character sets, it sends a negative 220 acknowledgment (CHARSET REJECTED). 222 Because it is not valid to reply to a CHARSET REQUEST 223 message with another CHARSET REQUEST message, if a 224 CHARSET REQUEST message is received after sending one, it 225 means that both sides have sent them simultaneously. In 226 this case, the server side MUST issue a negative 227 acknowledgment. The client side MUST respond to the one 228 from the server. 230 IAC SB CHARSET ACCEPTED IAC SE 231 This is a positive acknowledgment response to a CHARSET 232 REQUEST message; the receiver of the CHARSET REQUEST 233 message acknowledges its receipt and accepts the 234 indicated character set. 236 is a character sequence identical to one of the 237 character sets in the CHARSET REQUEST message. It is 238 terminated by the IAC SE sequence. 240 Text messages which follow this response must now be 241 coded in the indicated character set. This message 242 terminates the current CHARSET subnegotiation. 244 IAC SB CHARSET REJECTED IAC SE 245 This is a negative acknowledgment response to a CHARSET 246 REQUEST message; the receiver of the CHARSET REQUEST 247 message acknowledges its receipt but refuses to use any 248 of the requested character sets. Messages can not be 249 sent in any of the indicated character sets. This 250 message can also be sent by the sender of a TTABLE-IS 251 message, if multiple TTABLE-NAK messages were sent in 252 response. This message terminates the current CHARSET 253 subnegotiation. 255 IAC SB CHARSET TTABLE-IS IAC 256 SE 257 In response to a CHARSET REQUEST message in which 258 [TTABLE] was specified, the receiver of the CHARSET 259 REQUEST message acknowledges its receipt and is 260 transmitting a pair of tables which define the mapping 261 between specified character sets. 263 is an octet whose binary value is the version 264 level of this TTABLE-IS message. Different versions have 265 different syntax. The lowest version level is one (zero 266 is not valid). The current highest version level is also 267 one. This field is provided so that future versions of 268 the TTABLE-SEND message can be specified, for example, to 269 handle character sets for which there is no simple one- 270 to-one character-for-character translation. This might 271 include some forms of multi-octet character sets for 272 which translation algorithms or subsets need to be sent. 274 Syntax for Version 1: 276 278 280 is a separator octet, the value of which is chosen 281 by the sender. Examples include a space or a semicolon. 282 Any value other than IAC is allowed. The obvious choice 283 is a space or any other punctuation symbol which does not 284 appear in either of the character set names. 286 and are sequences of 287 7-BIT ASCII printable characters which identify the two 288 character sets for which a mapping is being specified. 289 Each is terminated by . Case is not significant. 290 If a character set is registered with IANA, it is 291 required that the standardized spelling of its name or a 292 registered alias be used. should be 293 chosen from the in the CHARSET REQUEST 294 message. can be arbitrarily chosen. 295 Text on the wire should be encoded using . 298 and are single octets each. 299 The binary value of the octet is the number of bits 300 nominally required for each character in the 301 corresponding table. It should be a multiple of eight. 303 and are each three-octet 304 binary fields in Network Byte Order [6]. Each specifies 305 how many characters (of the maximum 2**) are 306 being transmitted in the corresponding map. 308 and each consist of the corresponding 309 number of characters. These characters form 310 a mapping from all or part of the characters in one of 311 the specified character sets to the correct characters in 312 the other character set. If the indicated 313 is less than 2**, the first 314 characters are being mapped, and the remaining characters 315 are assumed to not be changed (and thus map to 316 themselves). That is, each map contains characters 0 317 through -1. maps from to . maps from to . Translation between 320 the character sets is thus an obvious process of using 321 the binary value of a character as an index into the 322 appropriate map. The character at that index replaces 323 the original character. If the index exceeds the for the map, no translation is performed for the 325 character. 327 [Note to implementers: since TELNET works in octets, it 328 is possible for octets of value 255 to appear 329 ``spontaneously'' when using multi-octet or non-8-bit 330 characters. All octets of value 255 (other than IAC) 331 MUST be quoted to conform with TELNET requirements. This 332 applies even to octets within a table, or text in a 333 multi-octet character set.] 335 IAC SB CHARSET TTABLE-ACK IAC SE 336 The sender acknowledges the successful receipt of the 337 translate table. Text messages which follow this 338 response must now be coded in the character set specified 339 as of the TTABLE-IS message. This 340 message terminates the current CHARSET subnegotiation. 342 IAC SB CHARSET TTABLE-NAK IAC SE 343 The sender reports the unsuccessful receipt of the 344 translate table and requests that it be resent. If 345 subsequent transmission attempts also fail, a TTABLE- 346 REJECTED or CHARSET REJECTED message (depending on which 347 side sends it) should be sent instead of additional 348 futile TTABLE-IS and TTABLE-NAK messages. 350 IAC SB CHARSET TTABLE-REJECTED IAC SE 351 In response to a TTABLE-IS message, the receiver of the 352 TTABLE-IS message acknowledges its receipt and indicates 353 it is unable to handle it. This message terminates the 355 Any system which supports the CHARSET option MUST fully 356 support the CHARSET REQUEST, ACCEPTED, REJECTED, and TTABLE- 357 REJECTED subnegotiation messages. It MAY optionally fully 358 support the TTABLE-IS, TTABLE-ACK, and TTABLE-NAK messages. 359 If it does fully support the TTABLE-IS message, it MUST also 360 fully support the TTABLE-ACK and TTABLE-NAK messages. 362 4. Default 364 WON'T CHARSET 366 DON'T CHARSET 368 5. Motivation for the Option 370 Many TELNET sessions need to transmit data which is not 371 in 7-bit ASCII. This is usually done by negotiating 372 BINARY, and using local conventions (or terminal type 373 kluges) to determine the character set of the data. 374 However, such methods tend not to interoperate well, and 375 have difficulties when multiple character sets need to be 376 supported by different sessions. 378 Many computer systems now utilize a variety of character 379 sets. Increasingly, a server computer needs to document 380 character sets or translate transmissions and receptions 381 using different pairs of character sets on a per- 382 application or per-connection basis. This is becoming 383 more common as client and server computers become more 384 geographically disperse. (And as servers are 385 consolidated into ever-larger hubs, serving ever-wider 386 areas.) In order for files, databases, etc. to contain 387 correct data, the server must determine the character set 388 in which the user is sending, and the character set in 389 which the application expects to receive. 391 In some cases, it is sufficient to determine the 392 character set of the end user (because every application 393 on the server expects to use the same character set, or 394 because applications can handle the user's character 395 set), but in other cases different server applications 396 expect to use different character sets. In the former 397 case, an initial CHARSET subnegotiation suffices. In the 398 latter case, the server may need to initiate additional 399 CHARSET subnegotiations as the user switches between 400 applications. 402 At a minimum, the option described in this memo allows 403 both sides to be clear as to which character set is being 404 used. A minimal implementation would have the server 405 send DO CHARSET, and the client send WILL CHARSET and 406 CHARSET REQUEST. The server could then communicate the 407 client's character set to applications using whatever 408 means are appropriate. Such a server might refuse 409 subsequent CHARSET REQUEST messages from the client (if 410 it lacked the ability to communicate changed character 411 set information to applications, for example). Another 412 system might have a method whereby various applications 413 could communicate to the TELNET server their character 414 set needs and abilities, which the server would handle by 415 initiating new CHARSET REQUEST negotiations as 416 appropriate. 418 In some cases, servers may have a large set of clients 419 which tend to connect often (such as daily) and over a 420 long period of time (such as years). The server 421 administrators may strongly prefer that the servers not 422 do character set translation (to save CPU cycles when 423 serving very large numbers of users). To avoid manually 424 configuring each copy of the user TELNET software, the 425 administrators might prefer that the software supports 426 translate tables. (If the client software received a 427 translate table from the server and stored it, the table 428 would only need to be sent once.) 430 6. Description of the Option 432 When the client TELNET program is able to determine the 433 user's character set it should offer to specify the 434 character set by sending IAC WILL CHARSET. 436 If the server system is able to make use of this 437 information, it replies with IAC DO CHARSET. The client 438 TELNET is then free to request a character set in a 439 subnegotiation at any time. 441 Likewise, when the server is able to determine the 442 expected character set(s) of the user's application(s), 443 it should send IAC DO CHARSET to request that the client 444 system specify the character set it is using. Or the 445 server could send IAC WILL CHARSET to offer to specify 446 the character sets. 448 Once a character set has been determined, the server can 449 either perform the translation between the user and 450 application character sets itself, or request by 451 additional CHARSET subnegotiations that the client system 452 do so. 454 Once it has been established that both sides are capable 455 of character set negotiation (that is, each side has 456 received either a WILL CHARSET or a DO CHARSET message, 457 and has also sent either a DO CHARSET or a WILL CHARSET 458 message), subnegotiations can be requested at any time by 459 whichever side has sent a WILL CHARSET message and also 460 received a DO CHARSET message (this may be either or both 461 sides). Once a CHARSET subnegotiation has started, it 462 must be completed before additional CHARSET 463 subnegotiations can be started (there must never be more 464 than one CHARSET subnegotiation active at any given 465 time). When a subnegotiation has completed, additional 466 subnegotiations can be started at any time. 468 If either side violates this rule and attempts to start a 469 CHARSET subnegotiation while one is already active, the 470 other side MUST reject the new subnegotiation by sending 471 a CHARSET REJECTED message. 473 Receipt of a CHARSET REJECTED or TTABLE-REJECTED message 474 terminates the subnegotiation, leaving the character set 475 unchanged. Receipt of a CHARSET ACCEPTED or TTABLE-ACK 476 message terminates the subnegotiation, with the new 477 character set in force. 479 In some cases, both the server and the client systems are 480 able to perform translations and to send and receive in 481 the character set(s) expected by the other side. In such 482 cases, either side can request that the other use the 483 character set it prefers. When both sides simultaneously 484 make such a request (send CHARSET REQUEST messages), the 485 server MUST reject the client's request by sending a 486 CHARSET REJECTED message. The client system MUST respond 487 to the server's request. (See the CHARSET REQUEST 488 description, above.) 490 When the client system makes the request first, and the 491 server is able to handle the requested character set(s), 492 but prefers that the client system instead use the 493 server's (user application) character set, it may reject 494 the request, and issue a CHARSET REQUEST of its own. If 495 the client system is unable to comply with the server's 496 preference and issues a CHARSET REJECTED message, the 497 server can issue a new CHARSET REQUEST message for one of 498 the previous character sets (one of those which the 499 client system originally requested). The client system 500 would obviously accept this character set. 502 While a CHARSET subnegotiation is in progress, data 503 should be queued. Once the CHARSET subnegotiation has 504 terminated, the data can be sent (in the correct 505 character set). 507 Note that regardless of CHARSET negotiation, translation 508 only applies to text (not commands), and only occurs when 509 in BINARY mode [4]. If not in BINARY mode, all data is 510 assumed to be in NVT ASCII [1]. 512 Also note that the CHARSET option should be used with the 513 END OF RECORD option [5] for block-mode terminals in 514 order to be clear on what character represents the end of 515 each record. 517 As an example of character set negotiation, consider a 518 user on a workstation using TELNET to communicate with a 519 server. In this example, the workstation normally uses 520 the Cyrillic (ASCII) character set [2] but is capable of 521 using EBCDIC-Cyrillic [2], and the server normally uses 522 EBCDIC-Cyrillic. The server could handle the (ASCII) 523 Cyrillic character set, but prefers that instead the 524 client system uses the EBCDIC-Cyrillic character set. 525 (This and the following examples do not show the full 526 syntax of the subnegotiation messages.) 528 CLIENT SERVER 530 WILL CHARSET WILL CHARSET 532 DO CHARSET DO CHARSET 534 CHARSET REQUEST Cyrillic 535 EBCDIC-Cyrillic 537 CHARSET ACCEPTED EBCDIC- 538 Cyrillic 540 Now consider a case where the workstation can't handle 541 EBCDIC-Cyrillic, but can accept a translate table: 543 CLIENT SERVER 545 WILL CHARSET WILL CHARSET 546 DO CHARSET DO CHARSET 548 CHARSET REQUEST [TTABLE] 1 549 Cyrillic 551 CHARSET TTABLE-IS 1 Cyrillic 552 EBCDIC-Cyrillic 554 CHARSET TTABLE-ACK 556 For another example, consider a case similar to the 557 previous case, but now the user switches server 558 applications in the middle of the session (denoted by 559 ellipses), and the new application requires a different 560 character set: 562 CLIENT SERVER 564 WILL CHARSET WILL CHARSET 566 DO CHARSET DO CHARSET 568 CHARSET REQUEST [TTABLE] 1 569 Cyrillic EBCDIC-INT 571 CHARSET TTABLE-IS 1 Cyrillic 572 EBCDIC-Cyrillic 574 CHARSET TTABLE-ACK 576 . . . . . . 578 CHARSET REQUEST EBCDIC-INT 580 CHARSET ACCEPTED EBCDIC-INT 582 7. Security Considerations 584 This document raises no security issues. 586 8. References 588 [1]Postel, J. and Reynolds, J., ``Telnet Protocol 589 Specification'', STD 8, RFC 854, ISI, May 1983 591 [2]Reynolds, J., and Postel, J., ``Assigned Numbers'', 592 STD 2, RFC 1700, ISI, October 1994 594 [3]Postel, J. and Reynolds, J., ``Telnet Option 595 Specifications'', STD 8, RFC 855, ISI, May 1983 597 [4]Postel, J. and Reynolds, J., 11Telnet Binary 598 Transmission'', RFC 856, ISI, May 1983 600 [5]Postel, J., ``Telnet End-Of-Record Option'', RFC 885, 601 ISI, December 1983 603 [6]Postel, J., ``Internet Official Protocol Standards'', 604 STD 1, RFC 1780, IAB, March 1995 606 9. Author's Address 608 Randall C. Gellens 609 Unisys Corporation 610 25725 Jeronimo Road 611 Mail Stop 237 612 Mission Viejo, CA 92691 613 USA 615 Phone: +1.714.380.6350 616 Fax: +1.714.380.5912 618 Randy@MV.Unisys.Com