📄 rfc854.2up.ps
字号:
/d_output_w 547 def/d_output_h 779 def/cols 1 def%%EndSetup%%Page: (1-2) 1%%BeginPageSetup_S90 rotate24 -24 translate%Page: (1) 1%BeginPageSetup_S% N-up sub-page 1/20 -547 translate0.688917 dup scale/pagenum 1 def/fname (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/rfc854.txt) def/fdir (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/) def/ftail (rfc854.txt) def% User defined strings:/fmodstr (Fri Oct 05 00:00:00 1990) def/pagenumstr (1) def/user_header_p true def/user_header_left_str (RFC854) def/user_header_center_str (RFC.net) def/user_header_right_str (Page 1 of 16) def%%EndPageSetupdo_header5 751 M(Network Working Group J. Postel) s5 738 M(Request for Comments: 854 J. Reynolds) s5 725 M( ISI) s5 712 M(Obsoletes: NIC 18639 May 1983) s5 686 M( TELNET PROTOCOL SPECIFICATION) s5 647 M(This RFC specifies a standard for the ARPA Internet community. Hosts on) s5 634 M(the ARPA Internet are expected to adopt and implement this standard.) s5 608 M(INTRODUCTION) s5 582 M( The purpose of the TELNET Protocol is to provide a fairly general,) s5 569 M( bi-directional, eight-bit byte oriented communications facility. Its) s5 556 M( primary goal is to allow a standard method of interfacing terminal) s5 543 M( devices and terminal-oriented processes to each other. It is) s5 530 M( envisioned that the protocol may also be used for terminal-terminal) s5 517 M( communication \("linking"\) and process-process communication) s5 504 M( \(distributed computation\).) s5 478 M(GENERAL CONSIDERATIONS) s5 452 M( A TELNET connection is a Transmission Control Protocol \(TCP\)) s5 439 M( connection used to transmit data with interspersed TELNET control) s5 426 M( information.) s5 400 M( The TELNET Protocol is built upon three main ideas: first, the) s5 387 M( concept of a "Network Virtual Terminal"; second, the principle of) s5 374 M( negotiated options; and third, a symmetric view of terminals and) s5 361 M( processes.) s5 335 M( 1. When a TELNET connection is first established, each end is) s5 322 M( assumed to originate and terminate at a "Network Virtual Terminal",) s5 309 M( or NVT. An NVT is an imaginary device which provides a standard,) s5 296 M( network-wide, intermediate representation of a canonical terminal.) s5 283 M( This eliminates the need for "server" and "user" hosts to keep) s5 270 M( information about the characteristics of each other's terminals and) s5 257 M( terminal handling conventions. All hosts, both user and server, map) s5 244 M( their local device characteristics and conventions so as to appear to) s5 231 M( be dealing with an NVT over the network, and each can assume a) s5 218 M( similar mapping by the other party. The NVT is intended to strike a) s5 205 M( balance between being overly restricted \(not providing hosts a rich) s5 192 M( enough vocabulary for mapping into their local character sets\), and) s5 179 M( being overly inclusive \(penalizing users with modest terminals\).) s5 153 M( NOTE: The "user" host is the host to which the physical terminal) s5 140 M( is normally attached, and the "server" host is the host which is) s5 127 M( normally providing some service. As an alternate point of view,) s5 62 M(Postel & Reynolds [Page 1]) s_R%Page: (2) 2%BeginPageSetup_S% N-up sub-page 2/2402 -547 translate0.688917 dup scale/pagenum 2 def/fname (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/rfc854.txt) def/fdir (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/) def/ftail (rfc854.txt) def% User defined strings:/fmodstr (Fri Oct 05 00:00:00 1990) def/pagenumstr (2) def/user_header_p true def/user_header_left_str (RFC854) def/user_header_center_str (RFC.net) def/user_header_right_str (Page 2 of 16) def%%EndPageSetupdo_header5 725 M(RFC 854 May 1983) s5 686 M( applicable even in terminal-to-terminal or process-to-process) s5 673 M( communications, the "user" host is the host which initiated the) s5 660 M( communication.) s5 634 M( 2. The principle of negotiated options takes cognizance of the fact) s5 621 M( that many hosts will wish to provide additional services over and) s5 608 M( above those available within an NVT, and many users will have) s5 595 M( sophisticated terminals and would like to have elegant, rather than) s5 582 M( minimal, services. Independent of, but structured within the TELNET) s5 569 M( Protocol are various "options" that will be sanctioned and may be) s5 556 M( used with the "DO, DON'T, WILL, WON'T" structure \(discussed below\) to) s5 543 M( allow a user and server to agree to use a more elaborate \(or perhaps) s5 530 M( just different\) set of conventions for their TELNET connection. Such) s5 517 M( options could include changing the character set, the echo mode, etc.) s5 491 M( The basic strategy for setting up the use of options is to have) s5 478 M( either party \(or both\) initiate a request that some option take) s5 465 M( effect. The other party may then either accept or reject the) s5 452 M( request. If the request is accepted the option immediately takes) s5 439 M( effect; if it is rejected the associated aspect of the connection) s5 426 M( remains as specified for an NVT. Clearly, a party may always refuse) s5 413 M( a request to enable, and must never refuse a request to disable some) s5 400 M( option since all parties must be prepared to support the NVT.) s5 374 M( The syntax of option negotiation has been set up so that if both) s5 361 M( parties request an option simultaneously, each will see the other's) s5 348 M( request as the positive acknowledgment of its own.) s5 322 M( 3. The symmetry of the negotiation syntax can potentially lead to) s5 309 M( nonterminating acknowledgment loops -- each party seeing the incoming) s5 296 M( commands not as acknowledgments but as new requests which must be) s5 283 M( acknowledged. To prevent such loops, the following rules prevail:) s5 257 M( a. Parties may only request a change in option status; i.e., a) s5 244 M( party may not send out a "request" merely to announce what mode it) s5 231 M( is in.) s5 205 M( b. If a party receives what appears to be a request to enter some) s5 192 M( mode it is already in, the request should not be acknowledged.) s5 179 M( This non-response is essential to prevent endless loops in the) s5 166 M( negotiation. It is required that a response be sent to requests) s5 153 M( for a change of mode -- even if the mode is not changed.) s5 127 M( c. Whenever one party sends an option command to a second party,) s5 114 M( whether as a request or an acknowledgment, and use of the option) s5 101 M( will have any effect on the processing of the data being sent from) s5 88 M( the first party to the second, then the command must be inserted) s5 75 M( in the data stream at the point where it is desired that it take) s5 36 M(Postel & Reynolds [Page 2]) s_R_RS%%Page: (3-4) 2%%BeginPageSetup_S90 rotate24 -24 translate%Page: (3) 3%BeginPageSetup_S% N-up sub-page 1/20 -547 translate0.688917 dup scale/pagenum 3 def/fname (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/rfc854.txt) def/fdir (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/) def/ftail (rfc854.txt) def% User defined strings:/fmodstr (Fri Oct 05 00:00:00 1990) def/pagenumstr (3) def/user_header_p true def/user_header_left_str (RFC854) def/user_header_center_str (RFC.net) def/user_header_right_str (Page 3 of 16) def%%EndPageSetupdo_header5 725 M(RFC 854 May 1983) s5 686 M( effect. \(It should be noted that some time will elapse between) s5 673 M( the transmission of a request and the receipt of an) s5 660 M( acknowledgment, which may be negative. Thus, a host may wish to) s5 647 M( buffer data, after requesting an option, until it learns whether) s5 634 M( the request is accepted or rejected, in order to hide the) s5 621 M( "uncertainty period" from the user.\)) s5 595 M( Option requests are likely to flurry back and forth when a TELNET) s5 582 M( connection is first established, as each party attempts to get the) s5 569 M( best possible service from the other party. Beyond that, however,) s5 556 M( options can be used to dynamically modify the characteristics of the) s5 543 M( connection to suit changing local conditions. For example, the NVT,) s5 530 M( as will be explained later, uses a transmission discipline well) s5 517 M( suited to the many "line at a time" applications such as BASIC, but) s5 504 M( poorly suited to the many "character at a time" applications such as) s5 491 M( NLS. A server might elect to devote the extra processor overhead) s5 478 M( required for a "character at a time" discipline when it was suitable) s5 465 M( for the local process and would negotiate an appropriate option.) s5 452 M( However, rather than then being permanently burdened with the extra) s5 439 M( processing overhead, it could switch \(i.e., negotiate\) back to NVT) s5 426 M( when the detailed control was no longer necessary.) s5 400 M( It is possible for requests initiated by processes to stimulate a) s5 387 M( nonterminating request loop if the process responds to a rejection by) s5 374 M( merely re-requesting the option. To prevent such loops from) s5 361 M( occurring, rejected requests should not be repeated until something) s5 348 M( changes. Operationally, this can mean the process is running a) s5 335 M( different program, or the user has given another command, or whatever) s5 322 M( makes sense in the context of the given process and the given option.) s5 309 M( A good rule of thumb is that a re-request should only occur as a) s5 296 M( result of subsequent information from the other end of the connection) s5 283 M( or when demanded by local human intervention.) s5 257 M( Option designers should not feel constrained by the somewhat limited) s5 244 M( syntax available for option negotiation. The intent of the simple) s5 231 M( syntax is to make it easy to have options -- since it is) s5 218 M( correspondingly easy to profess ignorance about them. If some) s5 205 M( particular option requires a richer negotiation structure than) s5 192 M( possible within "DO, DON'T, WILL, WON'T", the proper tack is to use) s5 179 M( "DO, DON'T, WILL, WON'T" to establish that both parties understand) s5 166 M( the option, and once this is accomplished a more exotic syntax can be) s5 153 M( used freely. For example, a party might send a request to alter) s5 140 M( \(establish\) line length. If it is accepted, then a different syntax) s5 127 M( can be used for actually negotiating the line length -- such a) s5 114 M( "sub-negotiation" might include fields for minimum allowable, maximum) s5 101 M( allowable and desired line lengths. The important concept is that) s5 36 M(Postel & Reynolds [Page 3]) s_R%Page: (4) 4%BeginPageSetup_S% N-up sub-page 2/2402 -547 translate0.688917 dup scale/pagenum 4 def/fname (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/rfc854.txt) def/fdir (/usr/local/share/doc/rfc/Mirrors/ftp.isi.edu/in-notes/) def/ftail (rfc854.txt) def% User defined strings:/fmodstr (Fri Oct 05 00:00:00 1990) def/pagenumstr (4) def/user_header_p true def/user_header_left_str (RFC854) def/user_header_center_str (RFC.net) def/user_header_right_str (Page 4 of 16) def%%EndPageSetupdo_header5 725 M(RFC 854 May 1983) s5 686 M( such expanded negotiations should never begin until some prior) s5 673 M( \(standard\) negotiation has established that both parties are capable) s5 660 M( of parsing the expanded syntax.) s5 634 M( In summary, WILL XXX is sent, by either party, to indicate that) s5 621 M( party's desire \(offer\) to begin performing option XXX, DO XXX and) s5 608 M( DON'T XXX being its positive and negative acknowledgments; similarly,) s5 595 M( DO XXX is sent to indicate a desire \(request\) that the other party) s5 582 M( \(i.e., the recipient of the DO\) begin performing option XXX, WILL XXX) s5 569 M( and WON'T XXX being the positive and negative acknowledgments. Since) s5 556 M( the NVT is what is left when no options are enabled, the DON'T and) s5 543 M( WON'T responses are guaranteed to leave the connection in a state) s5 530 M( which both ends can handle. Thus, all hosts may implement their) s5 517 M( TELNET processes to be totally unaware of options that are not) s5 504 M( supported, simply returning a rejection to \(i.e., refusing\) any) s5 491 M( option request that cannot be understood.) s5 465 M( As much as possible, the TELNET protocol has been made server-user) s5 452 M( symmetrical so that it easily and naturally covers the user-user) s5 439 M( \(linking\) and server-server \(cooperating processes\) cases. It is) s5 426 M( hoped, but not absolutely required, that options will further this) s5 413 M( intent. In any case, it is explicitly acknowledged that symmetry is) s5 400 M( an operating principle rather than an ironclad rule.) s5 374 M⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -