?? 00000016.htm
字號:
a. Parties may only request a change in option status; i.e., a <br /> party may not send out a "request" merely to announce what mode it <br /> is in. <br /> b. If a party receives what appears to be a request to enter some <br /> mode it is already in, the request should not be acknowledged. <br /> This non-response is essential to prevent endless loops in the <br /> negotiation. It is required that a response be sent to requests <br /> for a change of mode -- even if the mode is not changed. <br /> c. Whenever one party sends an option command to a second party, <br /> whether as a request or an acknowledgment, and use of the option <br /> will have any effect on the processing of the data being sent from <br /> the first party to the second, then the command must be inserted <br /> in the data stream at the point where it is desired that it take <br />Postel & Reynolds [Page 2] <br /> <br />RFC 854 May 1983 <br /> effect. (It should be noted that some time will elapse between <br /> the transmission of a request and the receipt of an <br /> acknowledgment, which may be negative. Thus, a host may wish to <br /> buffer data, after requesting an option, until it learns whether <br /> the request is accepted or rejected, in order to hide the <br /> "uncertainty period" from the user.) <br /> Option requests are likely to flurry back and forth when a TELNET <br /> connection is first established, as each party attempts to get the <br /> best possible service from the other party. Beyond that, however, <br /> options can be used to dynamically modify the characteristics of the <br /> connection to suit changing local conditions. For example, the NVT, <br /> as will be explained later, uses a transmission discipline well <br /> suited to the many "line at a time" applications such as BASIC, but <br /> poorly suited to the many "character at a time" applications such as <br /> NLS. A server might elect to devote the extra processor overhead <br /> required for a "character at a time" discipline when it was suitable <br /> for the local process and would negotiate an appropriate option. <br /> However, rather than then being permanently burdened with the extra <br /> processing overhead, it could switch (i.e., negotiate) back to NVT <br /> when the detailed control was no longer necessary. <br /> It is possible for requests initiated by processes to stimulate a <br /> nonterminating request loop if the process responds to a rejection by <br /> merely re-requesting the option. To prevent such loops from <br /> occurring, rejected requests should not be repeated until something <br /> changes. Operationally, this can mean the process is running a <br /> different program, or the user has given another command, or whatever <br /> makes sense in the context of the given process and the given option. <br /> A good rule of thumb is that a re-request should only occur as a <br /> result of subsequent information from the other end of the connection <br /> or when demanded by local human intervention. <br /> Option designers should not feel constrained by the somewhat limited <br /> syntax available for option negotiation. The intent of the simple <br /> syntax is to make it easy to have options -- since it is <br /> correspondingly easy to profess ignorance about them. If some <br /> particular option requires a richer negotiation structure than <br /> possible within "DO, DON'T, WILL, WON'T", the proper tack is to use <br /> "DO, DON'T, WILL, WON'T" to establish that both parties understand <br /> the option, and once this is accomplished a more exotic syntax can be <br /> used freely. For example, a party might send a request to alter <br /> (establish) line length. If it is accepted, then a different syntax <br /> can be used for actually negotiating the line length -- such a <br /> "sub-negotiation" might include fields for minimum allowable, maximum <br /> allowable and desired line lengths. The important concept is that <br />Postel & Reynolds [Page 3] <br /> <br />RFC 854 May 1983 <br /> such expanded negotiations should never begin until some prior <br /> (standard) negotiation has established that both parties are capable <br /> of parsing the expanded syntax. <br /> In summary, WILL XXX is sent, by either party, to indicate that <br /> party's desire (offer) to begin performing option XXX, DO XXX and <br /> DON'T XXX being its positive and negative acknowledgments; similarly, <br /> DO XXX is sent to indicate a desire (request) that the other party <br /> (i.e., the recipient of the DO) begin performing option XXX, WILL XXX <br /> and WON'T XXX being the positive and negative acknowledgments. Since <br /> the NVT is what is left when no options are enabled, the DON'T and <br /> WON'T responses are guaranteed to leave the connection in a state <br /> which both ends can handle. Thus, all hosts may implement their <br /> TELNET processes to be totally unaware of options that are not <br /> supported, simply returning a rejection to (i.e., refusing) any <br /> option request that cannot be understood. <br /> As much as possible, the TELNET protocol has been made server-user <br /> symmetrical so that it easily and naturally covers the user-user <br /> (linking) and server-server (cooperating processes) cases. It is <br /> hoped, but not absolutely required, that options will further this <br /> intent. In any case, it is explicitly acknowledged that symmetry is <br /> an operating principle rather than an ironclad rule. <br /> A companion document, "TELNET Option Specifications," should be <br />
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -