RFC854 日本語訳
0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May 1983. (Format: TXT=39371 bytes) (Obsoletes RFC0764) (Updated by RFC5198) (Also STD0008) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel
Request for Comments: 854 J. Reynolds
ISI
Obsoletes: NIC 18639 May 1983
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 854 J.レイノルズISIは以下を時代遅れにします。 NIC18639 1983年5月
TELNET PROTOCOL SPECIFICATION
テルネット・プロトコル仕様
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard.
このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。
INTRODUCTION
序論
The purpose of the TELNET Protocol is to provide a fairly general,
bi-directional, eight-bit byte oriented communications facility. Its
primary goal is to allow a standard method of interfacing terminal
devices and terminal-oriented processes to each other. It is
envisioned that the protocol may also be used for terminal-terminal
communication ("linking") and process-process communication
(distributed computation).
TELNETプロトコルの目的はかなり一般的で、双方向の、そして、8ビットのバイト指向のコミュニケーション施設を提供することです。 プライマリ目標は端末装置と端末指向のプロセスを互いに連結する標準方法を許容することです。 それは思い描かれます。また、プロトコルは端末間通信(「リンク」)とプロセス間通信(分散型計算方式)に使用されるかもしれません。
GENERAL CONSIDERATIONS
一般的な問題
A TELNET connection is a Transmission Control Protocol (TCP) connection used to transmit data with interspersed TELNET control information.
TELNET接続は点在しているTELNET制御情報でデータを送るのに使用される通信制御プロトコル(TCP)接続です。
The TELNET Protocol is built upon three main ideas: first, the concept of a "Network Virtual Terminal"; second, the principle of negotiated options; and third, a symmetric view of terminals and processes.
TELNETプロトコルは3つの本旨で築き上げられます: 最初に、「ネットワーク仮想端末」の概念。 2番目、交渉されたオプションの原理。 3番目、端末とプロセスの左右対称の視点。
1. When a TELNET connection is first established, each end is assumed to originate and terminate at a "Network Virtual Terminal", or NVT. An NVT is an imaginary device which provides a standard, network-wide, intermediate representation of a canonical terminal. This eliminates the need for "server" and "user" hosts to keep information about the characteristics of each other's terminals and terminal handling conventions. All hosts, both user and server, map their local device characteristics and conventions so as to appear to be dealing with an NVT over the network, and each can assume a similar mapping by the other party. The NVT is intended to strike a balance between being overly restricted (not providing hosts a rich enough vocabulary for mapping into their local character sets), and being overly inclusive (penalizing users with modest terminals).
1. TELNET接続が最初に確立されるとき、「ネットワーク仮想端末」、またはNVTで起因して、各端が終わると思われます。 NVTは標準端末の標準的、そして、ネットワーク全体的、そして、中間的な表現を提供する想像上の装置です。 これは「サーバ」と「ユーザ」ホストが互いの端末と端末の取り扱い規約の特性の情報を保つ必要性を排除します。 すべてのホスト(ユーザとサーバの両方)がネットワークの上でNVTに対処しているように見えるために彼らのローカル装置の特性とコンベンションを写像します、そして、それぞれが相手で同様のマッピングを仮定できます。 NVTがひどく制限されて(彼らのローカルキャラクターセットへのマッピングのために十分豊かなボキャブラリーをホストに提供しません)、ひどく包括的であることの間のバランスをとることを意図します(こじんまりの端末でユーザを罰して)。
NOTE: The "user" host is the host to which the physical terminal
is normally attached, and the "server" host is the host which is
normally providing some service. As an alternate point of view,
以下に注意してください。 「ユーザ」ホストは通常、物理端末が愛着しているホストです、そして、「サーバ」ホストはホストです(通常、何らかのサービスを提供しています)。 代替の観点として
Postel & Reynolds [Page 1]
ポステルとレイノルズ[1ページ]
RFC 854 May 1983
RFC854 1983年5月
applicable even in terminal-to-terminal or process-to-process
communications, the "user" host is the host which initiated the
communication.
プロセスから端末から端末かプロセスへのコミュニケーションでさえ適切であることで、「ユーザ」ホストはホストです(コミュニケーションを開始しました)。
2. The principle of negotiated options takes cognizance of the fact that many hosts will wish to provide additional services over and above those available within an NVT, and many users will have sophisticated terminals and would like to have elegant, rather than minimal, services. Independent of, but structured within the TELNET Protocol are various "options" that will be sanctioned and may be used with the "DO, DON'T, WILL, WON'T" structure (discussed below) to allow a user and server to agree to use a more elaborate (or perhaps just different) set of conventions for their TELNET connection. Such options could include changing the character set, the echo mode, etc.
2. 交渉されたオプションの原理は多くのホストが高性能のユーザが持っているNVT、および多くの中の追加サービスと上の利用可能なそれら端末を提供することを願って、最小量であるというよりむしろ上品に欲しい事実に気が付きます、サービス。 の如何にかかわらず、TELNETプロトコルの中で構造化されているのが、それが認可されて、使用されるかもしれないということであるために望んでいる様々な「オプション」である、「してください、そして、しないでください、ウィル、」 ユーザとサーバが、彼らのtelnet接続により多くの入念で(恐らくちょうど異なる)のセットのコンベンションを使用するのに同意するのを許容するために構造化するでしょう(以下では、議論します)。 そのようなオプションは、文字集合、エコーモードなどを変えるのを含むかもしれません。
The basic strategy for setting up the use of options is to have either party (or both) initiate a request that some option take effect. The other party may then either accept or reject the request. If the request is accepted the option immediately takes effect; if it is rejected the associated aspect of the connection remains as specified for an NVT. Clearly, a party may always refuse a request to enable, and must never refuse a request to disable some option since all parties must be prepared to support the NVT.
オプションの使用をセットアップするための基本戦略は何れの当事者(ともに)に何らかのオプションが実施するという要求を開始させることです。 そして、相手は、要求を受け入れるか、または拒絶するかもしれません。 要求を受け入れるなら、オプションはすぐに、実施します。 それが拒絶されるなら、接続の関連局面はNVTに指定されるように残っています。 明確に、パーティーは、いつも可能にする要求を拒否するかもしれなくて、すべてのパーティーがNVTをサポートする用意ができていなければならないので何らかのオプションを無効にするという要求は決して、拒否してはいけません。
The syntax of option negotiation has been set up so that if both parties request an option simultaneously, each will see the other's request as the positive acknowledgment of its own.
オプション交渉の構文は、双方が同時にオプションを要求するなら、それぞれがもう片方の要求をそれ自身の肯定応答であるとみなすように、セットアップされました。
3. The symmetry of the negotiation syntax can potentially lead to nonterminating acknowledgment loops -- each party seeing the incoming commands not as acknowledgments but as new requests which must be acknowledged. To prevent such loops, the following rules prevail:
3. 交渉構文の対称は、承認輪を「非-終え」るのに潜在的に通じることができます--承認と考えるのではなく、受信コマンドを承諾しなければならない新しい要求と考える各当事者。 そのような輪を防ぐために、以下の規則は広がっています:
a. Parties may only request a change in option status; i.e., a
party may not send out a "request" merely to announce what mode it
is in.
a。 党はオプション状態の変化を要求するだけであるかもしれません。 すなわち、パーティーは単にそれがあるすべてのモードを発表するという「要求」を出さないかもしれません。
b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the
negotiation. It is required that a response be sent to requests
for a change of mode -- even if the mode is not changed.
b。 パーティーが既に何らかのモードを記録するという要求であるように見えるものを受けるなら、要求を承諾するべきではありません。 この非応答は、交渉における永久ループを防ぐのに不可欠です。 モードが変えられないでも、応答がモードの変化を求める要求に送られるのが必要です。
c. Whenever one party sends an option command to a second party,
whether as a request or an acknowledgment, and use of the option
will have any effect on the processing of the data being sent from
the first party to the second, then the command must be inserted
in the data stream at the point where it is desired that it take
c。 そして、1回のパーティーが要求か承認にかかわらず2番目のパーティーにオプション命令を送って、オプションの使用が最初のパーティーから2番目に送られるデータの処理にどんな影響も与えるときはいつも、それが取ることが望まれているポイントでのデータ・ストリームにコマンドを挿入しなければなりません。
Postel & Reynolds [Page 2]
ポステルとレイノルズ[2ページ]
RFC 854 May 1983
RFC854 1983年5月
effect. (It should be noted that some time will elapse between
the transmission of a request and the receipt of an
acknowledgment, which may be negative. Thus, a host may wish to
buffer data, after requesting an option, until it learns whether
the request is accepted or rejected, in order to hide the
"uncertainty period" from the user.)
効果。 (いくらかの時間が要求の伝達と承認の受領の間で経過することに注意されるべきです。承認は否定的であるかもしれません。 したがって、ホストはデータをバッファリングしたがっているかもしれません、オプションを要求した後に、要求を受け入れるか、または拒絶するかを学ぶまで、「不確定の期間」をユーザから隠すために。)
Option requests are likely to flurry back and forth when a TELNET connection is first established, as each party attempts to get the best possible service from the other party. Beyond that, however, options can be used to dynamically modify the characteristics of the connection to suit changing local conditions. For example, the NVT, as will be explained later, uses a transmission discipline well suited to the many "line at a time" applications such as BASIC, but poorly suited to the many "character at a time" applications such as NLS. A server might elect to devote the extra processor overhead required for a "character at a time" discipline when it was suitable for the local process and would negotiate an appropriate option. However, rather than then being permanently burdened with the extra processing overhead, it could switch (i.e., negotiate) back to NVT when the detailed control was no longer necessary.
TELNET接続が最初に確立されるとき、オプション要求は前後に動揺しそうです、各当事者が、相手からできるだけよいサービスを得るのを試みるとき。 しかしながら、それを超えて、現地の状況を変えながら適合するようにダイナミックに接続の特性を変更するのにオプションを使用できます。 例えば、NVT、後で説明されるように、送信規律が多くによく合った用途はBASICなどの応用を「一度に、裏打ちします」が、NLSなどの「一度にキャラクタ」アプリケーションに多くに不十分に合いました。 サーバは、それが地方のプロセスに適当であったときに「一度にキャラクタ」規律に必要である付加的なプロセッサ・オーバヘッドを注ぐのを選ぶかもしれなくて、適切なオプションを交渉するでしょう。 そしてというよりむしろしかしながら、詳細なコントロールはもう必要でなかったときに、永久に付加的な処理オーバヘッドで負担されて、それがNVTに切り替わって戻ることができました(すなわち、交渉します)。
It is possible for requests initiated by processes to stimulate a nonterminating request loop if the process responds to a rejection by merely re-requesting the option. To prevent such loops from occurring, rejected requests should not be repeated until something changes. Operationally, this can mean the process is running a different program, or the user has given another command, or whatever makes sense in the context of the given process and the given option. A good rule of thumb is that a re-request should only occur as a result of subsequent information from the other end of the connection or when demanded by local human intervention.
プロセスが単にオプションを再要求することによって拒絶に応じるなら、プロセスによって開始された要求に、非終了の要求輪を刺激するのは可能です。 そのような輪が現れるのを防ぐために、何かが変化するまで、拒絶された要求を繰り返すべきではありません。 操作上、これが、プロセスが異なったプログラムを動かしていることを意味できますか、ユーザが別のコマンドを与えたか、または何でも与えられたプロセスと与えられたオプションの文脈で理解できます。 良い経験則は再要求が接続のもう一方の端か地方の人間の介入で要求されるという場合にその後の情報の結果、現れるだけであるべきであるということです。
Option designers should not feel constrained by the somewhat limited syntax available for option negotiation. The intent of the simple syntax is to make it easy to have options -- since it is correspondingly easy to profess ignorance about them. If some particular option requires a richer negotiation structure than possible within "DO, DON'T, WILL, WON'T", the proper tack is to use "DO, DON'T, WILL, WON'T" to establish that both parties understand the option, and once this is accomplished a more exotic syntax can be used freely. For example, a party might send a request to alter (establish) line length. If it is accepted, then a different syntax can be used for actually negotiating the line length -- such a "sub-negotiation" might include fields for minimum allowable, maximum allowable and desired line lengths. The important concept is that
オプションデザイナーはオプション交渉に利用可能ないくらか限られた構文でやむを得ないと思うべきではありません。 簡単な構文の意図はそれらに関して無知について自供するのが対応する簡単であるのでオプションを持っているのを簡単にすることです。 何らかの特定のオプションが中で可能であるより豊かな交渉構造を必要とする、「してください、そして、しないでください、ウィル、」、使用には適切なびょうがある、「してください、そして、しないでください、ウィル、」 双方がオプションを理解していて、かつて、これが優れていると証明するには、自由によりエキゾチックな構文を使用できるでしょう。 例えば、パーティーは行長を変更するという(設立します)要求を送るかもしれません。 それを受け入れるなら、実際に行長を交渉するのに異なった構文を使用できます--そのような「サブ交渉」は最小の許容できて、最大の許容できて必要な行長のための分野を含むかもしれません。 重要な概念はそれです。
Postel & Reynolds [Page 3]
ポステルとレイノルズ[3ページ]
RFC 854 May 1983
RFC854 1983年5月
such expanded negotiations should never begin until some prior (standard) negotiation has established that both parties are capable of parsing the expanded syntax.
何らかの先(標準の)の交渉が、双方が拡張構文を分析できるのを確証するまで、そのような拡張交渉は決して始まるべきではありません。
In summary, WILL XXX is sent, by either party, to indicate that party's desire (offer) to begin performing option XXX, DO XXX and DON'T XXX being its positive and negative acknowledgments; similarly, DO XXX is sent to indicate a desire (request) that the other party (i.e., the recipient of the DO) begin performing option XXX, WILL XXX and WON'T XXX being the positive and negative acknowledgments. Since the NVT is what is left when no options are enabled, the DON'T and WON'T responses are guaranteed to leave the connection in a state which both ends can handle. Thus, all hosts may implement their TELNET processes to be totally unaware of options that are not supported, simply returning a rejection to (i.e., refusing) any option request that cannot be understood.
概要では、WILL XXXはその肯定的・否定的な承認であるオプションXXX、DO XXX、およびDON'T XXXを実行し始めるそのパーティーの願望(提供する)を示すために何れの当事者によって送られます。 同様に、もう片方がパーティーへ行くという願望(要求する)を示すためにDO XXXを送る、(すなわち、受取人、する、)、肯定的・否定的な承認であるオプションXXX、WILL XXX、およびWON'T XXXを実行し始めてください。 そして、NVTがいつに残されるものであるので、オプションが全く可能にされない、応答は両端が扱うことができる状態に接続を残すために保証されるでしょう。 したがって、すべてのホストがサポートされないオプションに全く気づかないプロセスを彼らのTELNETに実装するかもしれません、単に理解できないどんな(すなわち、拒否)オプション要求にも拒絶を返して。
As much as possible, the TELNET protocol has been made server-user symmetrical so that it easily and naturally covers the user-user (linking) and server-server (cooperating processes) cases. It is hoped, but not absolutely required, that options will further this intent. In any case, it is explicitly acknowledged that symmetry is an operating principle rather than an ironclad rule.
簡単に自然にユーザユーザ(リンク)とサーバサーバ(協調処理)ケースをカバーするように、TELNETプロトコルをサーバユーザ対称にできるだけ、しました。 それは、望まれていますが、絶対に必要でなく、そのオプションはこの意図を促進するでしょう。 どのような場合でも、対称が鉄則よりむしろ操作原則であると明らかに認められます。
A companion document, "TELNET Option Specifications," should be consulted for information about the procedure for establishing new options.
「telnetオプション仕様」という仲間ドキュメントは新しいオプションを確立するための手順の情報のために参照されるべきです。
THE NETWORK VIRTUAL TERMINAL
ネットワーク仮想端末
The Network Virtual Terminal (NVT) is a bi-directional character device. The NVT has a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data which is sent over the TELNET connection and, if "echoes" are desired, to the NVT's printer as well. "Echoes" will not be expected to traverse the network (although options exist to enable a "remote" echoing mode of operation, no host is required to implement this option). The code set is seven-bit USASCII in an eight-bit field, except as modified herein. Any code conversion and timing considerations are local problems and do not affect the NVT.
Network Virtual Terminal(NVT)は双方向のキャラクタデバイスです。 NVTには、プリンタとキーボードがあります。 そして、プリンタが受信データに応じて、キーボードがTELNET接続の上に送られる発信データを作り出す、「エコー」がまた、NVTのプリンタに望まれているなら。 「エコーズ」がネットワークを横断しないと予想されるでしょう(オプションは「リモートな」反響運転モードを可能にするために存在していますが、ホストは全くこのオプションを実装する必要はありません)。 コードセットはここに変更されるのを除いた8ビットの分野の7ビットのUSASCIIです。 どんなコード変換とタイミング問題も、地方の問題であり、NVTに影響しません。
TRANSMISSION OF DATA
データの伝達
Although a TELNET connection through the network is intrinsically
full duplex, the NVT is to be viewed as a half-duplex device
operating in a line-buffered mode. That is, unless and until
ネットワークを通したTELNET接続は本質的に、全二重、NVTが半二重デバイスとして見なされることになっているということですが、中で作動して、aはモードを系列でバッファリングしました。 すなわち
Postel & Reynolds [Page 4]
ポステルとレイノルズ[4ページ]
RFC 854 May 1983
RFC854 1983年5月
options are negotiated to the contrary, the following default
conditions pertain to the transmission of data over the TELNET
connection:
オプションはそれと反対に交渉されて、以下のデフォルト条件はTELNET接続の上でデータの伝達に関係します:
1) Insofar as the availability of local buffer space permits,
data should be accumulated in the host where it is generated
until a complete line of data is ready for transmission, or
until some locally-defined explicit signal to transmit occurs.
This signal could be generated either by a process or by a
human user.
1) ローカルバッファベースの有用性が可能にする限り、それが発生しているところにデータの完全な系列がトランスミッションの準備ができているか、または送信する何らかの局所的に定義された明白な信号が発生するまで、データはホストに蓄積されるべきです。 プロセスか人間のユーザがこの信号を生成することができました。
The motivation for this rule is the high cost, to some hosts,
of processing network input interrupts, coupled with the
default NVT specification that "echoes" do not traverse the
network. Thus, it is reasonable to buffer some amount of data
at its source. Many systems take some processing action at the
end of each input line (even line printers or card punches
frequently tend to work this way), so the transmission should
be triggered at the end of a line. On the other hand, a user
or process may sometimes find it necessary or desirable to
provide data which does not terminate at the end of a line;
therefore implementers are cautioned to provide methods of
locally signaling that all buffered data should be transmitted
immediately.
処理ネットワーク入力割込みの何人かのホストへの「エコー」が横断しないデフォルトに結びつけられたNVT仕様は、この規則が高値であるので、ネットワークを動機に費やしました。 したがって、ソースにおけるいくらかのデータ量をバッファリングするのは妥当です。 多くのシステムがそれぞれの入力行の端で何らかの処理行動を取るので(ラインプリンタかカードパンチさえ、頻繁にこのように働く傾向があります)、トランスミッションは線の端に引き起こされるべきです。 他方では、ユーザかプロセスが、時々線の端に終わらないデータを提供するのが必要であるか、または望ましいのがわかるかもしれません。 したがって、implementersがすべてのバッファリングされたデータがすぐに送られるべきであると局所的に合図するメソッドを提供すると警告されます。
2) When a process has completed sending data to an NVT printer
and has no queued input from the NVT keyboard for further
processing (i.e., when a process at one end of a TELNET
connection cannot proceed without input from the other end),
the process must transmit the TELNET Go Ahead (GA) command.
2) プロセスがNVTプリンタにデータを送るのを完了して、さらなる処理のためのNVTキーボードからの列に並ばせられた入力を全く持っていないとき(すなわち、TELNET接続の片端のプロセスはいつもう一方の端から入力なしで続くことができませんか)、プロセスはTELNET Go Ahead(ジョージア)コマンドを伝えなければなりません。
This rule is not intended to require that the TELNET GA command
be sent from a terminal at the end of each line, since server
hosts do not normally require a special signal (in addition to
end-of-line or other locally-defined characters) in order to
commence processing. Rather, the TELNET GA is designed to help
a user's local host operate a physically half duplex terminal
which has a "lockable" keyboard such as the IBM 2741. A
description of this type of terminal may help to explain the
proper use of the GA command.
この規則が、TELNET GAコマンドがそれぞれの行の終わりの端末から送られるのを必要とすることを意図しません、サーバー・ホストが処理し始めるために、通常、特別な信号(行末か他の局所的に定義されたキャラクタに加えた)を必要としないので。 TELNET GAによるユーザのローカル・ホストが物理的にaを操作するのを助けるように設計されていて、「ロックできること」にaを持っている半二重端末がIBM2741などのようにキーボードを操作するというむしろ、ことです。 このタイプの端末の記述は、ジョージアコマンドの適切な使用について説明するのを助けるかもしれません。
The terminal-computer connection is always under control of
either the user or the computer. Neither can unilaterally
seize control from the other; rather the controlling end must
relinguish its control explicitly. At the terminal end, the
hardware is constructed so as to relinquish control each time
that a "line" is terminated (i.e., when the "New Line" key is
typed by the user). When this occurs, the attached (local)
端末のコンピュータ接続はユーザかコンピュータのどちらかでいつも制御されています。 どちらももう片方からコントロールを一方的に捕らえることができません。 むしろ制御側終端は明らかにコントロールをrelinguishしなければなりません。 端末側終端に、ハードウェアは、「系列」が終えられることの(すなわち、「復帰改行」キーはいつユーザがタイプされますか)時間それぞれコントロールを放棄するために構成されます。 これが起こると付属(地方)です。
Postel & Reynolds [Page 5]
ポステルとレイノルズ[5ページ]
RFC 854 May 1983
RFC854 1983年5月
computer processes the input data, decides if output should be
generated, and if not returns control to the terminal. If
output should be generated, control is retained by the computer
until all output has been transmitted.
コンピュータは、入力データを処理して、出力が生成されるべきであるかどうか決めます、そして、そうでなければ、リターンは端末まで制御されます。 出力がそうするなら、生成されてください、そして、すべての出力が伝えられるまで、コントロールはコンピュータによって保有されます。
The difficulties of using this type of terminal through the
network should be obvious. The "local" computer is no longer
able to decide whether to retain control after seeing an
end-of-line signal or not; this decision can only be made by
the "remote" computer which is processing the data. Therefore,
the TELNET GA command provides a mechanism whereby the "remote"
(server) computer can signal the "local" (user) computer that
it is time to pass control to the user of the terminal. It
should be transmitted at those times, and only at those times,
when the user should be given control of the terminal. Note
that premature transmission of the GA command may result in the
blocking of output, since the user is likely to assume that the
transmitting system has paused, and therefore he will fail to
turn the line around manually.
ネットワークを通してこのタイプの端末を使用するという困難は明白であるべきです。 「地方」のコンピュータは、もう行末信号を見た後にコントロールを保有するかどうか決めることができません。 「リモートな」コンピュータはどれがデータを処理しているかというこの決定をすることができるだけです。 したがって、TELNET GAコマンドは「リモートである」(サーバ)コンピュータがもう端末のユーザにコントロールを渡すべき時間であると「地方」の(ユーザ)コンピュータに合図できるメカニズムを提供します。 それはそれらの時代、および単にそれらの時代に伝えられるべきです。(その時、端末の支配力はユーザに与えられるべきです)。 ジョージアコマンドの時期尚早な送信が出力のブロッキングをもたらすかもしれないことに注意してください、ユーザが伝えるシステムが止まって、したがって、彼が手動で系列を変えないと仮定しそうであるので。
The foregoing, of course, does not apply to the user-to-server
direction of communication. In this direction, GAs may be sent at
any time, but need not ever be sent. Also, if the TELNET
connection is being used for process-to-process communication, GAs
need not be sent in either direction. Finally, for
terminal-to-terminal communication, GAs may be required in
neither, one, or both directions. If a host plans to support
terminal-to-terminal communication it is suggested that the host
provide the user with a means of manually signaling that it is
time for a GA to be sent over the TELNET connection; this,
however, is not a requirement on the implementer of a TELNET
process.
上記はもちろんユーザからサーバへのコミュニケーションの方向に適用されません。 この方向には、GAsはいつでも送るかもしれませんが、かつて、送る必要はありません。 また、プロセス間通信にTELNET接続を使用しているなら、どちらの方向にもGAsを送る必要はありません。 最終的に、端末間通信に関して、GAsがどちらも、1、または方向の両方に必要であるかもしれません。 ホストが、端末間通信をサポートするのを計画しているなら、ホストがジョージアがもうTELNET接続の上に送られるべき時間であると手動で合図する手段をユーザに提供することが提案されます。 しかしながら、これはTELNETプロセスのimplementerに関する要件ではありません。
Note that the symmetry of the TELNET model requires that there is
an NVT at each end of the TELNET connection, at least
conceptually.
TELNETモデルの対称が、NVTがTELNET接続の各端のときに少なくとも概念的にあるのを必要とすることに注意してください。
STANDARD REPRESENTATION OF CONTROL FUNCTIONS
コントロール機能の標準の表現
As stated in the Introduction to this document, the primary goal
of the TELNET protocol is the provision of a standard interfacing
of terminal devices and terminal-oriented processes through the
network. Early experiences with this type of interconnection have
shown that certain functions are implemented by most servers, but
that the methods of invoking these functions differ widely. For a
human user who interacts with several server systems, these
differences are highly frustrating. TELNET, therefore, defines a
standard representation for five of these functions, as described
Introductionにこのドキュメントに述べられているように、TELNETプロトコルのプライマリ目標はネットワークを通した端末装置と端末指向のプロセスの標準の連結の支給です。 このタイプのインタコネクトの早めの経験は、ある機能がほとんどのサーバによって実装されますが、これらの機能を呼び出すメソッドがはなはだしく異なるのを示しました。 数個のサーバシステムと対話する人間のユーザにとって、これらの違いは非常にいらだたしいです。 したがって、TELNETは説明されるようにこれらの5つの機能の標準の表現を定義します。
Postel & Reynolds [Page 6]
ポステルとレイノルズ[6ページ]
RFC 854 May 1983
RFC854 1983年5月
below. These standard representations have standard, but not
required, meanings (with the exception that the Interrupt Process
(IP) function may be required by other protocols which use
TELNET); that is, a system which does not provide the function to
local users need not provide it to network users and may treat the
standard representation for the function as a No-operation. On
the other hand, a system which does provide the function to a
local user is obliged to provide the same function to a network
user who transmits the standard representation for the function.
以下に これらの標準の表現には、標準の、しかし、必要でない意味があります(例外で、Interrupt Process(IP)が機能するのはTELNETを使用する他のプロトコルによって必要とされるかもしれません)。 すなわち、地元のユーザに機能を提供しないシステムは、それをネットワーク利用者に提供する必要はなくて、機能の標準の表現をどんな操作としても扱わないかもしれません。 他方では、地元のユーザに機能を提供するシステムが機能の標準の表現を伝えるネットワーク利用者に同じ機能を提供するのが強いられます。
Interrupt Process (IP)
中断プロセス(IP)
Many systems provide a function which suspends, interrupts,
aborts, or terminates the operation of a user process. This
function is frequently used when a user believes his process is
in an unending loop, or when an unwanted process has been
inadvertently activated. IP is the standard representation for
invoking this function. It should be noted by implementers
that IP may be required by other protocols which use TELNET,
and therefore should be implemented if these other protocols
are to be supported.
多くのシステムがユーザ・プロセスの操作を中断するか、中断するか、中止になるか、または終える機能を提供します。 ユーザが、彼のプロセスが果てしない輪にあると信じているか、または求められていないプロセスがうっかり動かされたとき、この機能は頻繁に使用されます。 IPはこの機能を呼び出す標準の表現です。 これらの他のプロトコルがサポートされることであるならIPがTELNETを使用する他のプロトコルが必要であるかもしれなく、したがって、実装されるべきであることにimplementersによって注意されるはずです。
Abort Output (AO)
出力を中止してください。(AO)
Many systems provide a function which allows a process, which
is generating output, to run to completion (or to reach the
same stopping point it would reach if running to completion)
but without sending the output to the user's terminal.
Further, this function typically clears any output already
produced but not yet actually printed (or displayed) on the
user's terminal. AO is the standard representation for
invoking this function. For example, some subsystem might
normally accept a user's command, send a long text string to
the user's terminal in response, and finally signal readiness
to accept the next command by sending a "prompt" character
(preceded by <CR><LF>) to the user's terminal. If the AO were
received during the transmission of the text string, a
reasonable implementation would be to suppress the remainder of
the text string, but transmit the prompt character and the
preceding <CR><LF>. (This is possibly in distinction to the
action which might be taken if an IP were received; the IP
might cause suppression of the text string and an exit from the
subsystem.)
多くのシステムがプロセスが完成(同じ停止ポイントに達するように、完成に稼働しているなら、それに達する)にもかかわらず、送付のない出力にユーザの端末に駆けつけることができる機能を提供します。プロセスは出力を生成しています。 さらに、この機能はユーザの端末で既に生産されましたが、実際にまだ印刷されていなかった少しの出力も通常クリアします(または、表示します)。 AOはこの機能を呼び出す標準の表現です。 例えば、何らかのサブシステムが、通常、ユーザのコマンドを受け入れて、応答で長いテキスト文字列をユーザの端末に送って、「迅速な」キャラクタ(<CR><LF>によって先行されている)をユーザの端末に送ることによって、最終的に次のコマンドを受け入れる準備を示唆するかもしれません。 テキスト文字列のトランスミッションの間、AOを受け取るなら、妥当な実装がテキスト文字列の残りを抑圧することですが、プロンプト文字と前の<CR><LF>を伝えてください。 (これはことによると区別IPを受け取るなら取る行動に中です; IPはサブシステムからテキスト文字列と出口の抑圧を引き起こすかもしれません。)
It should be noted, by server systems which provide this
function, that there may be buffers external to the system (in
中この機能を提供するサーバシステムによってシステムへの外部のバッファがあるかもしれないことに注意されるべきである、(。
Postel & Reynolds [Page 7]
ポステルとレイノルズ[7ページ]
RFC 854 May 1983
RFC854 1983年5月
the network and the user's local host) which should be cleared;
the appropriate way to do this is to transmit the "Synch"
signal (described below) to the user system.
ユーザのローカル・ホスト) ネットワークときれいにされるべきであるもの。 これをする適切な方法は「同時性」信号(以下で、説明される)をユーザシステムに送信することです。
Are You There (AYT)
あなたはそこにいますか?(AYT)
Many systems provide a function which provides the user with
some visible (e.g., printable) evidence that the system is
still up and running. This function may be invoked by the user
when the system is unexpectedly "silent" for a long time,
because of the unanticipated (by the user) length of a
computation, an unusually heavy system load, etc. AYT is the
standard representation for invoking this function.
多くのシステムがいくつかをユーザに目に見えた状態で提供する機能を提供する、(例えば、印刷可能である、)、システムがまだ活動しているという証拠。 システムが長い間不意に「静かである」ときに、この機能はユーザによって呼び出されるかもしれません、計算、思いがけない(ユーザによる)長さの異常に重いシステム・ロードなどのために AYTはこの機能を呼び出す標準の表現です。
Erase Character (EC)
消去文字(EC)
Many systems provide a function which deletes the last
preceding undeleted character or "print position"* from the
stream of data being supplied by the user. This function is
typically used to edit keyboard input when typing mistakes are
made. EC is the standard representation for invoking this
function.
多くのシステムがユーザによって提供されるデータのストリームから非削除されたキャラクタか「印刷位置」*に先行する最終を削除する機能を提供します。 ミスタイプをするとき、キーボード入力を編集するのにこの機能を通常使用します。 ECはこの機能を呼び出す標準の表現です。
*NOTE: A "print position" may contain several characters
which are the result of overstrikes, or of sequences such as
<char1> BS <char2>...
*以下に注意してください。 「印刷位置」はいくつかのキャラクタを含むかもしれません(重ね打ち、または<char1>BS<char2>などの系列の結果です)…
Erase Line (EL)
抹消線(高架鉄道)
Many systems provide a function which deletes all the data in
the current "line" of input. This function is typically used
to edit keyboard input. EL is the standard representation for
invoking this function.
多くのシステムが入力の現在の「系列」にすべてのデータを削除する機能を提供します。 この機能は、キーボード入力を編集するのに通常使用されます。 ELはこの機能を呼び出す標準の表現です。
THE TELNET "SYNCH" SIGNAL
telnet「同時性」信号
Most time-sharing systems provide mechanisms which allow a
terminal user to regain control of a "runaway" process; the IP and
AO functions described above are examples of these mechanisms.
Such systems, when used locally, have access to all of the signals
supplied by the user, whether these are normal characters or
special "out of band" signals such as those supplied by the
teletype "BREAK" key or the IBM 2741 "ATTN" key. This is not
necessarily true when terminals are connected to the system
through the network; the network's flow control mechanisms may
cause such a signal to be buffered elsewhere, for example in the
user's host.
ほとんどの時分割システムが端末ユーザが「暴走」プロセスのコントロールを取り戻すことができるメカニズムを提供します。 機能が上で説明したIPとAOはこれらのメカニズムに関する例です。局所的に使用されると、そのようなシステムはこれらが普通のキャラクタであるかテレタイプによって供給されたものなどの「バンド」特別な信号が主要に「壊れること」にかかわらずユーザによって提供された信号のすべてかIBM2741"ATTN"キーに近づく手段を持っています。 端末がネットワークを通してシステムにつなげられるとき、これは必ず本当であるというわけではありません。 ネットワークのフロー制御メカニズムで、ほかの場所と、例えば、ユーザのホストでそのような信号をバッファリングするかもしれません。
Postel & Reynolds [Page 8]
ポステルとレイノルズ[8ページ]
RFC 854 May 1983
RFC854 1983年5月
To counter this problem, the TELNET "Synch" mechanism is
introduced. A Synch signal consists of a TCP Urgent notification,
coupled with the TELNET command DATA MARK. The Urgent
notification, which is not subject to the flow control pertaining
to the TELNET connection, is used to invoke special handling of
the data stream by the process which receives it. In this mode,
the data stream is immediately scanned for "interesting" signals
as defined below, discarding intervening data. The TELNET command
DATA MARK (DM) is the synchronizing mark in the data stream which
indicates that any special signal has already occurred and the
recipient can return to normal processing of the data stream.
この問題を打ち返すために、TELNET「同時性」メカニズムは紹介されます。 Synch信号はTELNETコマンドDATA MARKに結びつけられたTCP Urgent通知から成ります。 Urgent通知(TELNET接続に関係するフロー制御を受けることがない)は、それを受けるプロセスでデータ・ストリームの特別な取り扱いを呼び出すのに使用されます。 このモードで、介入しているデータを捨てて、データ・ストリームはすぐに、「おもしろい」信号のために以下で定義されるようにスキャンされます。 TELNETコマンドDATA MARK(DM)はどんな特別な信号も既に発生して、受取人がデータ・ストリームの正常処理に戻ることができるのを示すデータ・ストリームにおいて連動マークです。
The Synch is sent via the TCP send operation with the Urgent
flag set and the DM as the last (or only) data octet.
TCPを通してSynchを送ります。最後の(単に)データ八重奏としてUrgent旗のセットとDMとの操作を送ってください。
When several Synchs are sent in rapid succession, the Urgent
notifications may be merged. It is not possible to count Urgents
since the number received will be less than or equal the number
sent. When in normal mode, a DM is a no operation; when in urgent
mode, it signals the end of the urgent processing.
数個のSynchsを矢つぎばやに送るとき、Urgent通知を合併するかもしれません。 受け取られた数が以下か等しくなるのでUrgentsを数えるために、数が発信したのは、可能ではありません。 正規モードでは、DMがノーである、操作。 緊急のモードで緊急処理の終わりに合図するとき。
If TCP indicates the end of Urgent data before the DM is found,
TELNET should continue the special handling of the data stream
until the DM is found.
DMが見つけられる前にTCPがUrgentデータの終わりを示すなら、DMが見つけられるまで、TELNETはデータ・ストリームの特別な取り扱いを続けているはずです。
If TCP indicates more Urgent data after the DM is found, it can
only be because of a subsequent Synch. TELNET should continue
the special handling of the data stream until another DM is
found.
DMが見つけられた後にTCPが、より多くのUrgentデータを示すなら、それはその後のSynchのためにあることができるだけです。 別のDMが見つけられるまで、TELNETはデータ・ストリームの特別な取り扱いを続けているはずです。
"Interesting" signals are defined to be: the TELNET standard
representations of IP, AO, and AYT (but not EC or EL); the local
analogs of these standard representations (if any); all other
TELNET commands; other site-defined signals which can be acted on
without delaying the scan of the data stream.
「おもしろい」信号は、である:なるように定義されます。 IP、AO、およびAYT(しかし、ECでないELでない)のTELNETの標準の表現。 これらの標準の表現(もしあれば)の地方のアナログ。 他のすべてのTELNETが命令します。 データのスキャンを遅らせないで影響できる他のサイトで定義された信号は流れます。
Since one effect of the SYNCH mechanism is the discarding of
essentially all characters (except TELNET commands) between the
sender of the Synch and its recipient, this mechanism is specified
as the standard way to clear the data path when that is desired.
For example, if a user at a terminal causes an AO to be
transmitted, the server which receives the AO (if it provides that
function at all) should return a Synch to the user.
SYNCHメカニズムの1つの効果がSynchの送付者とその受取人の間の本質的にはすべてのキャラクタ(TELNETコマンドを除いた)を捨てることであるので、このメカニズムはそれが望まれているときデータ経路をクリアする標準の方法として指定されます。 例えば、端末のユーザがAOを伝えさせるなら、AO(全くその機能を提供するなら)を受けるサーバはSynchをユーザに返すべきです。
Finally, just as the TCP Urgent notification is needed at the
TELNET level as an out-of-band signal, so other protocols which
make use of TELNET may require a TELNET command which can be
viewed as an out-of-band signal at a different level.
最終的に、ちょうどTCP Urgent通知がバンドで出ている信号としてTELNETレベルで必要であるように、TELNETを利用する他のプロトコルはバンドで出ている信号として異なったレベルで見なすことができるTELNETコマンドを必要とするかもしれません。
Postel & Reynolds [Page 9]
ポステルとレイノルズ[9ページ]
RFC 854 May 1983
RFC854 1983年5月
By convention the sequence [IP, Synch] is to be used as such a
signal. For example, suppose that some other protocol, which uses
TELNET, defines the character string STOP analogously to the
TELNET command AO. Imagine that a user of this protocol wishes a
server to process the STOP string, but the connection is blocked
because the server is processing other commands. The user should
instruct his system to:
系列[IP、Synch]はそのような信号として使用されるコンベンションによる、ことです。 例えば、ある他のプロトコル(TELNETを使用する)が類似してTELNETコマンドAOと文字列STOPを定義すると仮定してください。 サーバが他のコマンドを処理しているので、このプロトコルのユーザがSTOPストリングを処理するためにサーバを願っていますが、接続が妨げられると想像してください。 ユーザは、以下のことよう彼のシステムに命令するべきです。
1. Send the TELNET IP character;
1. TELNET IPキャラクタを送ってください。
2. Send the TELNET SYNC sequence, that is:
2. すなわち、TELNET SYNC系列を送ってください:
Send the Data Mark (DM) as the only character
in a TCP urgent mode send operation.
TCPの緊急のモードにおける唯一のキャラクタとしての(DM)が送るDataマークに操作を送ってください。
3. Send the character string STOP; and
3. 文字列STOPを送ってください。 そして
4. Send the other protocol's analog of the TELNET DM, if any.
4. もしあればもう片方のプロトコルのTELNET DMのアナログを送ってください。
The user (or process acting on his behalf) must transmit the
TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
gets through to the server's TELNET interpreter.
ユーザ(彼の代理に影響しながら、処理する)はTELNET IPがサーバのTELNETインタプリタに通じるのを保証するためには上のステップ2のTELNET SYNCH系列を伝えなければなりません。
The Urgent should wake up the TELNET process; the IP should
wake up the next higher level process.
UrgentはTELNETプロセスで目覚めるはずです。 IPは次の高レベル処理で目覚めるべきです。
THE NVT PRINTER AND KEYBOARD
NVTプリンタとキーボード
The NVT printer has an unspecified carriage width and page length
and can produce representations of all 95 USASCII graphics (codes
32 through 126). Of the 33 USASCII control codes (0 through 31
and 127), and the 128 uncovered codes (128 through 255), the
following have specified meaning to the NVT printer:
NVTプリンタは、不特定のキャリッジ幅とページ長を持って、すべての95のUSASCIIグラフィックス(32〜126に、コード化する)の表現を作成できます。 33のUSASCII制御コード(0〜31と127)、および128のむき出しのコード(128〜255)では、以下はNVTプリンタに意味を指定しました:
NAME CODE MEANING
ネーム・コード意味
NULL (NUL) 0 No Operation
Line Feed (LF) 10 Moves the printer to the
next print line, keeping the
same horizontal position.
Carriage Return (CR) 13 Moves the printer to the left
margin of the current line.
NULL(NUL)0ノーOperation線Feed(LF)10ムーヴスは次の印刷系列(保っている同じくらい水平な位置)へのプリンタです。 キャリッジReturn(CR)13ムーヴス、現在行の左の橋へのプリンタ。
Postel & Reynolds [Page 10]
ポステルとレイノルズ[10ページ]
RFC 854 May 1983
RFC854 1983年5月
In addition, the following codes shall have defined, but not
required, effects on the NVT printer. Neither end of a TELNET
connection may assume that the other party will take, or will
have taken, any particular action upon receipt or transmission
of these:
さらに、以下のコードは、NVTプリンタへの効果を定義されますが、必要としないものとします。 TELNET接続の終わりが、相手が取ると仮定するかもしれませんか、または取ってしまうでしょう、これらの領収書かトランスミッションへのどんな特定の動作:
BELL (BEL) 7 Produces an audible or
visible signal (which does
NOT move the print head).
Back Space (BS) 8 Moves the print head one
character position towards
the left margin.
Horizontal Tab (HT) 9 Moves the printer to the
next horizontal tab stop.
It remains unspecified how
either party determines or
establishes where such tab
stops are located.
Vertical Tab (VT) 11 Moves the printer to the
next vertical tab stop. It
remains unspecified how
either party determines or
establishes where such tab
stops are located.
Form Feed (FF) 12 Moves the printer to the top
of the next page, keeping
the same horizontal position.
ベル(BEL)7Produces、聞きとれるか目に見える信号(印字ヘッドを動かしません)。 印刷が、ある欄的に左のマージンに向かって上に立つSpace(BS)8ムーヴスを支持してください。 次の水平面へのプリンタがタブを付ける水平なTab(HT)9ムーヴスは止まります。 不特定のままで、そのようなタブが止まるところにパーティーが決定するか、または設立するどちらかがどのように位置しているかは残っています。 次の垂直タブへのプリンタが止める垂直なTab(バーモント)11ムーヴス。 不特定のままで、そのようなタブが止まるところにパーティーが決定するか、または設立するどちらかがどのように位置しているかは残っています。 Feed(FF)12ムーヴスを形成してください。次のページの上部、同じ保っている水平な位置へのプリンタ。
All remaining codes do not cause the NVT printer to take any
action.
すべての残っているコードで、NVTプリンタは少しの行動も取りません。
The sequence "CR LF", as defined, will cause the NVT to be
positioned at the left margin of the next print line (as would,
for example, the sequence "LF CR"). However, many systems and
terminals do not treat CR and LF independently, and will have to
go to some effort to simulate their effect. (For example, some
terminals do not have a CR independent of the LF, but on such
terminals it may be possible to simulate a CR by backspacing.)
Therefore, the sequence "CR LF" must be treated as a single "new
line" character and used whenever their combined action is
intended; the sequence "CR NUL" must be used where a carriage
return alone is actually desired; and the CR character must be
avoided in other contexts. This rule gives assurance to systems
which must decide whether to perform a "new line" function or a
multiple-backspace that the TELNET stream contains a character
following a CR that will allow a rational decision.
定義される系列"CR LF"は次の印刷系列(例えば、系列"LF CR"であるだろうことのような)の左のマージンでNVTを置かせるでしょう。 しかしながら、多くのシステムと端末は、独自にCRとLFを扱わないで、それらの効果をシミュレートするために何らかの取り組みに動かなければならないでしょう。 (例えば、LFの如何にかかわらずいくつかの端末にはCRがありませんが、そのような端末で、バックスペースキーを押して印字位置を一字分戻ることによってCRをシミュレートするのは可能であるかもしれません。) したがって、彼らの共同作戦が意図するときはいつも、系列"CR LF"を単独の「復帰改行」キャラクタとして扱われて、使用しなければなりません。 復帰だけが実際に望まれているところで系列"CR NUL"を使用しなければなりません。 そして、他の文脈でCRキャラクタを避けなければなりません。 この規則は倍数バックスペースキーを押して印字位置を一字分戻った状態で「復帰改行」機能かaを実行するかどうか決めなければならないシステムへのTELNETストリームが含む保証を与えます。合理的な決定を許容するCRの後をつけるキャラクタ。
Note that "CR LF" or "CR NUL" is required in both directions
"CR LF"か"CR NUL"が両方の方向に必要であることに注意してください。
Postel & Reynolds [Page 11]
ポステルとレイノルズ[11ページ]
RFC 854 May 1983
RFC854 1983年5月
(in the default ASCII mode), to preserve the symmetry of the
NVT model. Even though it may be known in some situations
(e.g., with remote echo and suppress go ahead options in
effect) that characters are not being sent to an actual
printer, nonetheless, for the sake of consistency, the protocol
requires that a NUL be inserted following a CR not followed by
a LF in the data stream. The converse of this is that a NUL
received in the data stream after a CR (in the absence of
options negotiations which explicitly specify otherwise) should
be stripped out prior to applying the NVT to local character
set mapping.
(デフォルトASCIIモードによる)、NVTの対称を保存するには、モデル化してください。 それがいくつかの状況で知られているかもしれない、(例えば、リモートエコー、抑圧、事実上、オプションに前方に行ってください、)、LFでデータ・ストリームでキャラクタが一貫性のためにそれにもかかわらず、実際のプリンタに送られないで、プロトコルが、CRに続いて、NULが挿入されるのを必要とするということになりませんでした。 この逆はローカルキャラクターセットマッピングにNVTを適用する前にCR(別の方法で明らかに指定するオプション交渉がないとき)が取り除かれたべきであった後に、NULがデータ・ストリームで受信したということです。
The NVT keyboard has keys, or key combinations, or key sequences,
for generating all 128 USASCII codes. Note that although many
have no effect on the NVT printer, the NVT keyboard is capable of
generating them.
NVTキーボードには、すべての128のUSASCIIコードを生成するためのキー、主要な組み合わせ、またはキー順があります。 多くがNVTプリンタの上で効き目がありませんが、NVTキーボードがそれらを生成することができることに注意してください。
In addition to these codes, the NVT keyboard shall be capable of
generating the following additional codes which, except as noted,
have defined, but not reguired, meanings. The actual code
assignments for these "characters" are in the TELNET Command
section, because they are viewed as being, in some sense, generic
and should be available even when the data stream is interpreted
as being some other character set.
これらのコードに加えて、NVTキーボードは、↓これが注意される以外に、定義されますが、reguiredされていない追加コードであると生成することができるでしょう、意味。 これらの「キャラクタ」のための実際のコード職場はTELNET Command部です、彼らが何らかの意味におけるジェネリックであるとして見なされて、データ・ストリームがある他の文字集合であるので解釈さえされるとき利用可能であるべきであるので。
Synch
同時性
This key allows the user to clear his data path to the other
party. The activation of this key causes a DM (see command
section) to be sent in the data stream and a TCP Urgent
notification is associated with it. The pair DM-Urgent is to
have required meaning as defined previously.
このキーで、ユーザは彼のデータ経路を相手にクリアすることができます。 このキーの起動で、データ・ストリームでDM(指揮班を見る)を送ります、そして、TCP Urgent通知はそれに関連しています。 DM緊急でないことは以前に定義されるように意味するのが必要であることです。
Break (BRK)
中断(BRK)
This code is provided because it is a signal outside the
USASCII set which is currently given local meaning within many
systems. It is intended to indicate that the Break Key or the
Attention Key was hit. Note, however, that this is intended to
provide a 129th code for systems which require it, not as a
synonym for the IP standard representation.
それが特定の意味が現在与えられるUSASCIIセットの外で多くのシステムの中の信号であるので、このコードを提供します。Break KeyかAttention Keyが打たれたのを示すのは意図しています。 しかしながら、これがIPの標準の表現のための同義語ではなく、それを必要とするシステムに129番目のコードを供給することを意図することに注意してください。
Interrupt Process (IP)
中断プロセス(IP)
Suspend, interrupt, abort or terminate the process to which the
NVT is connected. Also, part of the out-of-band signal for
other protocols which use TELNET.
NVTが接続されているプロセスを中断するか、中断するか、中止になるか、または終えてください。 TELNETを使用する他のプロトコルのためのバンドで出ている信号の一部も。
Postel & Reynolds [Page 12]
ポステルとレイノルズ[12ページ]
RFC 854 May 1983
RFC854 1983年5月
Abort Output (AO)
出力を中止してください。(AO)
Allow the current process to (appear to) run to completion, but
do not send its output to the user. Also, send a Synch to the
user.
現在のプロセスを許容する、(現れる、)、完成に駆けつけなさい、ただし、出力をユーザに送らないでください。 また、Synchをユーザに送ってください。
Are You There (AYT)
あなたはそこにいますか?(AYT)
Send back to the NVT some visible (i.e., printable) evidence
that the AYT was received.
AYTを受け取ったという何らかの目に見える(すなわち、印刷可能な)証拠をNVTに送り返してください。
Erase Character (EC)
消去文字(EC)
The recipient should delete the last preceding undeleted
character or "print position" from the data stream.
受取人はデータ・ストリームからの最後に非削除されたキャラクタに先行するか、「印刷位置」を削除するべきです。
Erase Line (EL)
抹消線(高架鉄道)
The recipient should delete characters from the data stream
back to, but not including, the last "CR LF" sequence sent over
the TELNET connection.
受取人はデータ・ストリームから戻っていて、しかし、含んでいないキャラクタを削除するべきです、telnet接続の上に送られた最後の"CR LF"系列。
The spirit of these "extra" keys, and also the printer format
effectors, is that they should represent a natural extension of
the mapping that already must be done from "NVT" into "local".
Just as the NVT data byte 68 (104 octal) should be mapped into
whatever the local code for "uppercase D" is, so the EC character
should be mapped into whatever the local "Erase Character"
function is. Further, just as the mapping for 124 (174 octal) is
somewhat arbitrary in an environment that has no "vertical bar"
character, the EL character may have a somewhat arbitrary mapping
(or none at all) if there is no local "Erase Line" facility.
Similarly for format effectors: if the terminal actually does
have a "Vertical Tab", then the mapping for VT is obvious, and
only when the terminal does not have a vertical tab should the
effect of VT be unpredictable.
これらの「付加的な」キーの精神、およびプリンタ書式制御文字がも彼らが"NVT"から「地方」に既にしなければならないマッピングの自然な拡大を表すべきであるということです。 ちょうどNVTデータ・バイト68(104 8進)が「大文字D」のためのローカルのコードがことなら何でもであるかに写像されるべきであるように、ECキャラクタは地方の「消去文字」機能がことなら何でもであるかに写像されるべきです。 ちょうど124(174 8進)のためのマッピングがいくらか任意であるので、さらに、どんな地方の「抹消線」施設もなければ、「縦棒」キャラクタが全くない環境にはいくらか任意のマッピング(または、全くなにも)がELキャラクタにあるかもしれません。 同様である、書式制御文字のために: 端末に「垂直タブ」が実際にあるなら、バーモントのためのマッピングは明白です、そして、端末に垂直タブがないときだけ、バーモントの効果は予測できるべきではありません。
TELNET COMMAND STRUCTURE
telnet命令系統
All TELNET commands consist of at least a two byte sequence: the "Interpret as Command" (IAC) escape character followed by the code for the command. The commands dealing with option negotiation are three byte sequences, the third byte being the code for the option referenced. This format was chosen so that as more comprehensive use of the "data space" is made -- by negotiations from the basic NVT, of course -- collisions of data bytes with reserved command values will be minimized, all such collisions requiring the inconvenience, and
すべてのTELNETコマンドが少なくとも2バイト列から成ります: 「解釈コマンド」(IAC)拡張文字はコマンドのためにコードで従いました。 3番目のバイトが参照をつけられるオプションのためのコードでありオプション交渉に対処するコマンドは3つのバイト列です。 そしてこの形式はもちろん--基本的なNVTからの「データ領域」の、より包括的な使用をする交渉で予約されたコマンド値に従ったデータの衝突バイトが最小にされるように、選ばれました、そのようなすべての衝突が不便を必要として。
Postel & Reynolds [Page 13]
ポステルとレイノルズ[13ページ]
RFC 854 May 1983
RFC854 1983年5月
inefficiency, of "escaping" the data bytes into the stream. With the current set-up, only the IAC need be doubled to be sent as data, and the other 255 codes may be passed transparently.
データ・バイトのストリームに「エスケープ」である非能率。 現在のセットアップで、IACだけがデータとして送るために倍にされなければなりません、そして、他の255のコードが透過的に通過されるかもしれません。
The following are the defined TELNET commands. Note that these codes and code sequences have the indicated meaning only when immediately preceded by an IAC.
↓これは定義されたTELNETコマンドです。 すぐにIACによって先行されている場合にだけこれらのコードとコード系列には示された意味があることに注意してください。
NAME CODE MEANING
ネーム・コード意味
SE 240 End of subnegotiation parameters.
NOP 241 No operation.
Data Mark 242 The data stream portion of a Synch.
This should always be accompanied
by a TCP Urgent notification.
Break 243 NVT character BRK.
Interrupt Process 244 The function IP.
Abort output 245 The function AO.
Are You There 246 The function AYT.
Erase character 247 The function EC.
Erase Line 248 The function EL.
Go ahead 249 The GA signal.
SB 250 Indicates that what follows is
subnegotiation of the indicated
option.
WILL (option code) 251 Indicates the desire to begin
performing, or confirmation that
you are now performing, the
indicated option.
WON'T (option code) 252 Indicates the refusal to perform,
or continue performing, the
indicated option.
DO (option code) 253 Indicates the request that the
other party perform, or
confirmation that you are expecting
the other party to perform, the
indicated option.
DON'T (option code) 254 Indicates the demand that the
other party stop performing,
or confirmation that you are no
longer expecting the other party
to perform, the indicated option.
IAC 255 Data Byte 255.
副交渉パラメタのSE240End。 NOP241いいえ操作。 データ、データが流すマーク242はSynchを分配します。 TCP Urgent通知でこれはいつも伴われるべきです。 243NVTキャラクタBRKを壊してください。 Process244機能IPを中断してください。 出力245を中止してください。機能AO。 あなたはThere246機能AYTですか? キャラクタ247機能ECを消してください。 線248を消してください。機能EL。 前に進んでください。249 ジョージア信号。 SB250Indicates、続くことは示されたオプションの副交渉です。 ウィル(オプションコード)251Indicates、働き始める願望、またはあなたが現在実行している確認、示されたオプション。 (オプションコード)252Indicates、実行、示されたオプションを実行するか、または続けていることへの拒否であるだろう。 もう片方のパーティーが働くという要求、またはあなたが、相手が実行すると予想している確認を(オプションコード)253Indicatesにしてください、示されたオプション。 (オプションコード)254Indicates、もう片方のパーティーが、働くのを止めるという要求、またはあなたが、もう相手が実行すると予想していない確認、示されたオプション。 IAC255データ・バイト255。
Postel & Reynolds [Page 14]
ポステルとレイノルズ[14ページ]
RFC 854 May 1983
RFC854 1983年5月
CONNECTION ESTABLISHMENT
コネクション確立
The TELNET TCP connection is established between the user's port U and the server's port L. The server listens on its well known port L for such connections. Since a TCP connection is full duplex and identified by the pair of ports, the server can engage in many simultaneous connections involving its port L and different user ports U.
TELNET TCP接続はサーバがそのような接続のためによく知られているポートLの上で聴くユーザのポートUとサーバのポートL.の間で確立されます。 以来、TCP接続が全二重であり、ポートの組によって特定されて、サーバはポートLにかかわる多くの同時接続に従事できます、そして、異なったユーザはUを移植します。
Port Assignment
ポート課題
When used for remote user access to service hosts (i.e., remote
terminal access) this protocol is assigned server port 23
(27 octal). That is L=23.
サービス・ホスト(すなわち、遠隔端末アクセス)へのリモート・ユーザーアクセスに使用されると、サーバポート23(27 8進)はこのプロトコルに割り当てられます。 それはL=23です。
Postel & Reynolds [Page 15]
ポステルとレイノルズ[15ページ]
一覧
スポンサーリンク
