Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: ()
Translation time: 2001-10-23
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but must
Keep the translation and copyright information of this document.
Network Working Group J. Postel
Request for Comments: 855 J. Reynolds
ISI
Obsoletes: NIC 18640 May 1983
Telnet option specification
(RFC855 - Telnet Option Specifications)
This RFC specifies the standard of an ARPA Internet community. Host on the ARPA Internet should adopt
This standard is now.
The purpose of providing some options to the Telnet protocol is to make the host communication between different devices to solve the pass between different devices.
The letter is better than the possible framework than the network virtual terminal (NVT). It allows the host freely
Create, test, or discard some options. Of course, you can imagine, those generally useful options, most hosts
It should be supported. Therefore, the documentation of these options should be carefully designed, and they should be published as much as possible. In addition, make sure not
It is also necessary to use the same option code in different options.
This document specifies a method of document standard for the allocation of option code and options. When testing, it is possible
Only the option code allocation is required without a complete document, but in general, one needs one to assign an option code.
Documentation. We publish this option by putting a document of an option as an RFC document. Of course, choose
The creator of the item can also publish options in other ways.
Option code is assigned by the personnel:
Jonathan B. Postel
University of Southern California
Information Sciences Institute (USC-ISI)
4676 Admirarthy Way
Marina Del Rey, California 90291
(213) 822-1511
Mailbox = Postel @ USC-ISIF
Options to include at least the following sections:
Section 1 - - The name of the command and the code for the option
Section 2 - - Command meaning
The meaning of each telnet command related to this option should be described. It should be noted that for complex selection
Item, "sub-negotiation" is required, so there may be many related orders. The principle of "sub-negotiation" is more detailed below
description.
Section 3 - Default specification
For those hosts that are not implemented or not using this option, these options must be described by default in these hosts.
Pseudo.
Section 4 - Motivation
For a detailed description of the motivation that creates a special option, or select a special format, select a special format.
For those problems that have not been encountered (or although already touched, but not realized) this option is designed to solve
People are very useful.
Section 5 - Description (or Implementation Rules) To ensure that two different implementations of a command can communicate with each other, only the meaning of the command is defined and the meaning of the command
The figure will be described so far is not enough. Therefore, in many cases, we need to give an order to provide a complete
description of. This description can be represented by text, or an exemplary implementation, or a realized clue, or the like.
Interpretation of "sub-negotiation"
When the option is passed between the host, you may need more information in addition to an option code. For example, ask a party
Number of options belong to this situation. The policy that passes additional information outside the option code between the host includes two
Steps: Both parties agree to "discuss" this parameter, second, "discuss" to the parameters.
In the first step, it is consent to discussing the parameters in an ordinary way. One party sends a piece of option with options
The DO (or Will) command is recommended to use the option and the other party sends a DO (or Will) command with option code.
Show this suggestion. Once both parties agree to use this option, keep up with the corresponding option code after the SB command.
The parameters and command se are start sub-negotiations. Each party is assumed to be able to resolve this parameter. Because in the original exchange
Will and DO commands, both sides indicate that you can support this option. In addition, even if the recipient cannot resolve the parameter, receive
The party can also locate the end position of the parameter string by searching the SE command (such as a string IAC SE). Of course,
At any time, any party can send Won't or don't to the other party to refuse to continue further
Judgment.
Therefore, the Telnet has the format of Telnet for the option "ABC" that needs to be subjected to child negotiation.
IAC Will ABC
Propose to use an option ABC (or agree with the other party using this option)
Iac Do ABC
Require another party to use the option ABC (or agree with the other party using this option)
Iac Sb ABC IAC SE
One step in the sub-negotiation, both sides must use
Designers designed to make "sub-negotiations" must be careful to avoid the infinite in the process of negotiations.
cycle. such as,
If each party can accept any value of a parameter, each party gives this parameter a different value, then
One party may enter the endless "response" process (because each recipient thinks as long as the other party is a proposal).
Finally, if the parameters in a "sub-negotiation" include a value of 255, corresponds to the general purpose of Telnet
The rule must double the value.
RFC855 - Telnet Option Specifications Telnet Option Specification
3
RFC Document Chinese Translation Program
