この文書はRFC854の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。
Network Working Group J. Postel
Request for Comments: 854 J. Reynolds
ISI
Obsoletes: NIC 18639 May 1983
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.
このＲＦＣはＡＲＰＡインターネット共同体の標準を指定します。ＡＲＰＡイン
ターネット上のホストがこの標準を取り入れ実装することを期待されます。
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).
ＴＥＬＮＥＴプロトコルの目的はかなり一般的な、双方向性の、８ビットバ
イト指向の通信機能を供給することです。その主なゴールはお互いに端末装
置の接続標準方法と端末志向のプロセスを許すことです。プロトコルは端末
−端末通知（「リンク」）とプロセス−プロセス通信（分散計算）に使われ
るかもしれないことが心に描かれます。
GENERAL CONSIDERATIONS
一般的な考察
A TELNET connection is a Transmission Control Protocol (TCP)
connection used to transmit data with interspersed TELNET control
information.
ＴＥＬＮＥＴ接続は、点在したＴＥＬＮＥＴ制御情報と共にデータを伝達す
るために使われる伝送制御プロトコル（ＴＣＰ）接続です。
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.
ＴＥＬＮＥＴプロトコルは３つの主な考えの上に構築されます：最初の考え
は「ネットワーク仮想端末」；２番目はオプション交渉；３番目は端末とプ
ロセスの対称な観点。
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. ＴＥＬＮＥＴ接続が最初に確立される時、各終端が「ネットワーク仮想
端末」あるいはＮＶＴの始点と終点と考えられます。ＮＶＴは標準を供給す
る仮想の装置、標準的端末のネットワーク規模の中間の表現です。これは
「サーバ」ホストと「ユーザ」ホストがお互いに他の端末の特徴と、端末処
理規約を記憶する必要をなくします。すべてのホスト、ユーザとサーバの両
方は、ネットワーク上でＮＶＴを扱っているように思われるように、ローカ
ル装置の特徴と規約を変換し、そしてそれぞれが他者も類似の変換をしてい
ると仮定します。ＮＶＴは過度な限定（ローカルな文字セットへの変換のた
めの十分豊かな語彙を用意しない）と、過度の包含（質素な端末のユーザに
ペナルティーを課す）の間のバランスを得るように意図されます。
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,
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. オプション交渉の原則は多くのホストがＮＶＴで利用可能なサービスに
追加のサービスを供給するのを望み、多くのユーザーは精巧な端末を持ち、
最小であるより簡潔なサービスを望むであろうという事実です。独立に、し
かし構造化して、ＴＥＬＮＥＴプロトコルに様々な「オプション」があり、
それらは認可され、（後で述べる）"DO, DON'T, WILL, WON'T"構造体で、ユー
ザとサーバがより巧妙な（あるいは異なった）協定を使うのを許すのに、使
われます。このようなオプションは文字セットはエコーモードなどの変更を
含みます。
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.
オプションの使用を設定する基本的な戦略はいずれか（あるいは両方）が何
かのオプションが効力を発するという要請を始める事です。他方は要請を受
け入れるか、拒絶するかもしれません。もし要請が受け入れられるなら、オ
プションはすぐに効力を発します；もし拒絶されるなら、接続の関連機能は
ＮＶＴで指定たままです。明らかに、一方が機能を利用可能にする要請を断
るかもしれなくて、そして全ユーザとサーバがＮＶＴをサポートする用意が
できているに違いないので、オプショの利用停止要請を断ってはなりません。
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
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.)
c. 一方が他方にオプションコマンドを送る時はいつでも、要請か確認か
によらず、送ってるデータにデータ処理へのオプション使用の影響に関わ
らず、コマンドが効力を発する事が切望される要点のデータ流に挿入され
なくてはなりません。（要請を転送してから、否定的なのを含む、確認ま
で時間が経過することが指摘されます。それで、ホストは要請を送った後
要請が確認されたか拒否されたか知るまで、ユーザに「不確定期間」を隠
すために、データをバッファに入れることを望むかもしれません）。
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.
オプション要請は、ＴＥＬＮＥＴ接続が最初に確立される時に、各パーティ
が他パーティから最良の可能なサービスを得ようと試みるため、行われる可
能性が高いです。それ以降も、しかしながら、オプションがダイナミックに
接続の特徴を修正するために、ローカル状態の変更を要求するため、使うこ
とができます。例えば、ＮＶＴは、後に説明するように、ＢＡＳＩＣのよう
な多くの「１度に１行」アプリケーションで適切な送信規則を使いますが、
ＮＬＳのような多くの「１度に１文字」アプリケーションに不完全です。サー
バは「１度に１文字」規則のために捧げる余分のプロセッサオーバーヘッド
を選ぶかも知れず、適切なオプション交渉を要求します。しかしながら、永
久に余分の処理オーバーヘッドで悩ませられるより、詳細な制御がもう必要
でない時ＮＶＴに切り替えることができます（すなわち、交渉します）。
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
such expanded negotiations should never begin until some prior
(standard) negotiation has established that both parties are capable
of parsing the expanded syntax.
オプションデザイナーがオプション交渉で可能な幾分限定された文法によっ
て制約を受けているように感じるべきではありません。単純な文法の意図は
オプションを持つことを容易にする事です−それらを無視することが比較的
容易である時からです。もしある特定のオプションが「DO, DON'T, WILL,
WON'T」で可能なのより豊かな交渉構造体を必要とするなら、適切な方針は
「DO, DON'T, WILL, WON'T」を使って両者がオプションを理解することを確
認し、これが達成されてからよりエキゾチックな文法を自由に使います。例
えば、（確定した）行長を変える要請を送るかもしれません。もしこれが受
け入れられるなら、異なった文法が実際に行長を交渉するのに使うことがで
きます−このような「副交渉」は最小許容、最大許容、望ましい行長のフィー
ルドを含むかもしれません。重要な概念はこのような拡大された交渉が決し
て、ある事前の（標準）交渉で両者が文法解析を確認するまで、始まるべき
ではないということです。
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.
まとめると、オプションXXXをはじめたい側が要望（提案）を示すためWILL
XXXを送り、DO XXXとDON'T XXXがその肯定応答と否定応答です；同様に他者
（受信側）のオプションXXXを実行を要望（提案）するためDO XXXを送り、
WILL XXX and WON'T XXXがその肯定応答と否定応答です。オプションが使用
可能ではない時、ＮＶＴが残るものなので、DON'TとWON'T応答は接続を両端
が扱うことができる状態を残すことを保証します。それで、すべてのホスト
は理解できないオプションの要請に単純に拒否（すなわち、拒否する）を返
して、サポートされないオプションにまったく気が付かないＴＥＬＮＥＴプ
ロセスを実装してもよいです。
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.
可能な限り、ＴＥＬＮＥＴプロトコルは、容易にユーザ−ユーザ（リンク）
やサーバ−サーバ（プロセス協調）に対応するように、ツーザ−サーバを対
称的に作りました。将来のオプションがこの意志を継ぐことは望まれますが、
絶対的に必要ではありません。どんなケースででも、対称が厳しい規則と言
うより、運営上原則で、明示的応答確認が出されます。
A companion document, "TELNET Option Specifications," should be
consulted for information about the procedure for establishing new
options.
関連文書、「ＴＥＬＮＥＴオプション仕様」、が新しいオプションを確立す
る手続きについての情報のために調べられるべきです。
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.
ネットワーク仮想端末（ＮＶＴ）は双方向性が特徴の装置です。ＮＶＴはプ
リンターとキーボードを持っています。プリンタは入力データに応答し、
キーボードはＴＥＬＮＥＴ接続上で送られるデータを生成し、もし「エコー」
が要請されたら、同様に、ＮＶＴのプリンターに、切望されるなら送られる
外向的なデータを引き起こします。「エコー」はネットワークを通過しない
ことが期待されます（「遠隔」エコーモードを可能にするためのオプション
があるが、ホストがこのオプションを実装するように要求されません）。
コードセットは、ここで修正される以外は、８ビットフィールドで７ビット
のUSASCIIです。コード変換とタイミングの考慮がローカルな問題であり、
ＮＶＴに影響を与えません。
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
options are negotiated to the contrary, the following default
conditions pertain to the transmission of data over the TELNET
connection:
ネットワークを通してのＴＥＬＮＥＴ接続が本質的に全二重であるが、
ＮＶＴ行バッファモードで運用する半二重の装置だと見なされるはずで
す。すなわち、オプションが反対に交渉されるまで、次のデフォルト条
件がＴＥＬＮＥＴ接続上のデータの送信に関係します：
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.
この規則の動機は、あるホストにとって、ネットワーク入力割込み処
理の高コストと、「エコー」がネットワークを通らないというデフォ
ルトＮＶＴ仕様からです。それで、情報がでデータの量をバッファす
ることが合理的です。多くのシステムが入力行の終わりで何かの処理
をします（ラインプリンタやカードパンチさえしばしばこのように作
動する傾向があります）、それで行の終わりで送信が起るべきです。
他方、ユーザーあるいはプロセスが時々行の終わりで終わらないデー
タを供給する必要があるか、あるいは望ましいことを見いだすかもし
れません；それ故に実装者がローカルにすべてのバッファに入れられ
たデータがすぐに伝達されるべきと合図する方法を供給するように注
意されます。
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) プロセスがＮＶＴプリンターにデータを送り終わり、ＮＶＴキー
ボードから待ち行列に入れられた入力なしに、これ以上の処理がない
時（すなわち、ＴＥＬＮＥＴ接続の一方のプロセスが他から入力無し
で先に進めない時）、プロセスはＴＥＬＮＥＴ Go Ahead（GA）コマン
ドを送信しなくてはなりません。
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はユーザーのローカルホ
ストがIBM 2741のような「ロック可能」キーボードを持つ物理的に半
二重の端末を操作するのを手伝うよう意図されます。このタイプの端
末の記述がGAコマンドの適切な使用を説明するのを手伝うかもしれま
せん。
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)
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コマン
ドを供給します。これはこの時に、そしてこの時にだけ伝達されるべ
きで、その時ユーザに端末制御を与えられるべきです。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.
前述は、もちろん、ユーザーからサーバーへの方向の通信には適用しませ
ん。この方向で、GAがいつでも送られるかもしれませんが、送る必要があ
りません。同じく、もしＴＥＬＮＥＴ接続がプロセスからプロセスへの通
信に使われるなら、GAはいずれかの方向ででも送る必要がありません。最
後に、端末から端末への通信のために、一方向にも双方向にも、GAが必要
ありません。もしホストが端末から端末への通信をサポートすることを計
画するなら、ホストが手作業でＴＥＬＮＥＴ接続上でGAを送る時間である
と合図する手段をユーザーに提供することが提案されます、これは、しか
しながら、ＴＥＬＮＥＴプロセスの実装上の必要条件ではありません。
Note that the symmetry of the TELNET model requires that there is
an NVT at each end of the TELNET connection, at least
conceptually.
ＴＥＬＮＥＴモデルの対称が、少なくとも概念的に、それぞれのＴＥＬＮ
ＥＴ接続の終わりにＮＶＴがあることを要求することを注意を払ってくだ
さい。
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
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)
割り込みプロセス（ＩＰ）
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.
多くのシステムがユーザープロセスの処理の中断や割込みや中止や停
止機能を供給します。この機能は、ユーザが自分のプロセスが無限ルー
プになったり、意図しないプロセスが活性化されたと信じる時に、頻
繁に使われます。ＩＰはこの機能を呼び出す標準表現です。ＩＰがＴ
ＥＬＮＥＴを使う他のプロトコルに必要かもしれなくて、従ってこれ
らの他のプロトコルがサポートされるなら実装されるべきである事を、
実装者に指摘します。
Abort Output (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.)
多くのシステムが、プロセスが出力を生成し実行が完了する（あるい
はある停止ポイントに達する）が、ユーザ端末に出力しないままでい
る機能を供給します。さらに、この機能は一般に、生成されたがまだ
ユーザ端末上に印刷（又は表示）されていない出力をクリアします。
ＡＯはこの機能を呼び出す標準表現です。例えば、いずれかのサブシ
ステムが通常ユーザーのコマンドを受け入れて、応答でユーザ端末に
長いテキスト文字列を送って、そして、ユーザ端末に（<CR><LF>で始
まる）「プロンプト」文字を送ることにで、次のコマンドを受け入れ
る用意を示すかもしれません。ＡＯをテキスト文字列の送信の間に受
信すると、合理的な実装がテキスト文字列の残りを抑制しますが、
<CR><LF>とプロンプト文字を送ります。（これは、もしＩＰを受信し
た場合にとるかもしれない行動と多分異なります；ＩＰはテキスト文
字列の抑圧とサブシステムからの退場を起こすかもしれません）。
It should be noted, by server systems which provide this
function, that there may be buffers external to the system (in
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.
この機能を供給するサーバーシステムは、システムの外部にバッファ
があるかもしれなくて（ネットワークとユーザローカルホストに）、
これをクリアするべきです；これをする適切な方法はユーザーシステ
ムに（下に記述された）「Synch」シグナルを伝達することです。
Are You There (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.
多くのシステムが、システムがまだ起きていて動作しているのを示す、
目に見える証拠（つまり印刷可能な）をユーザに供給する機能を供給
します。この機能は、（ユーザが）予期しない計算時間や、異常に重
いシステム負荷などによって、システムが長時間予期せぬ「無言」で
あるときに、ユーザーによって呼び出されるかもしれません。ＡＹＴ
はこの機能を呼び出す標準表現です。
Erase Character (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.
多くのシステムがユーザが供給したデータストリームから最後の前に
削除されていない文字を削除する機能あるいは「印刷位置」*機能を供
給します。この機能は、典型的にタイピングミスをした時、編集キー
ボード入力で使われます。ＥＣはこの機能を呼び出す標準表現です。
*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.
多くのシステムが現在の入力「行」のすべてのデータを削除する機
能を供給します。この機能は典型的に編集キーボード入力で使われ
ます。ＥＬはこの機能を呼び出す標準表現です。
THE TELNET "SYNCH" SIGNAL
ＴＥＬＮＥＴ同期信号
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.
たいていのタイムシェアリングシステムが端末ユーザに「暴走」プロセス
の制御を取り戻すことを可能にするメカニズムを供給します；上に記述さ
れたＩＰとＡＯ機能はこれらのメカニズムの例です。このようなシステム
は、ローカルに使われる時、ユーザによって供給されたシグナルのすべて
にアクセスを持ちます、これらが標準的な文字であったり、テレタイプ
「ブレーク」キーやＩＢＭ２７４１の「ＡＴＴＮ」のキーのように特別な
「アウトバンド」あったりします。これは、端末がネットワークを通して
システムに接続している時、必ずしも真ではありません；ネットワークの
フロー制御装置メカニズムはこのようなシグナルを、例えばユーザホスト
で、バッファするかもしれません。
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.
この問題に対処するために、ＴＥＬＮＥＴ「Synch」メカニズムが導入さ
れます。Synch信号がＴＥＬＮＥＴコマンドDATA MARKと結び付けられた
ＴＣＰ緊急通知から成り立ちます。ＴＥＬＮＥＴ接続に関してフロー制
御の適用を受けていない緊急通知は、それを受け取るプロセスにデータ
流の特別扱いを呼び出すために使われます。このモードで、間のデータ
を捨て、下に定義される「面白い」シグナルに対するデータ流がすぐに
走査されます。ＴＥＬＮＥＴコマンド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.
SynchはＴＣＰ送信オペレーションで緊急フラグ設定で送られ、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.
いくつかのSynchが連続して送られる時、緊急通知は統合されるかもしれ
ません。緊急通知の受信数は送信数以下なので、緊急通知の数を数える事
はできません。標準モードで、DMは何もしません；緊急モードで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.
もしTCPが、DMが見つかる前に、緊急データの終わりを示すなら、ＴＥ
ＬＮＥＴが、DMが見つかるまでデータ流の特別扱いを続けるべきです。
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が見つかった後も、緊急データを示すなら、それは
次のSynchのためです。ＴＥＬＮＥＴが、もう１つのDMが見つかるまで、
データ流の特別扱いを続けるべきです。
"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.
「面白い」シグナルが以下に定義されます：ＩＰとＡＯとＡＹＴのＴＥＬ
ＮＥＴ標準表現（ＥＣとＥＬは含まない）；これらの標準表現のローカル
な類似物；すべての他のＴＥＬＮＥＴコマンド；データ流走査を遅らせず
に作用する他のサイトで定義した信号。
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メカニズムの１つの効果がSynch送信者と受信者間で（ＴＥＬＮＥＴ
コマンド以外）本質的にすべて文字を捨てることであるので、このメカニ
ズムはデータパスをきれいにする標準的方法として明示されます。例えば、
もし端末のユーザーがＡＯを送るなら、ＡＯを受け取るサーバは（もしそ
の機能を供給するなら）、ユーザに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.
最後に、ＴＣＰ緊急の通知がＴＥＬＮＥＴレベルでアウトバンド信号とし
て必要なので、ＴＥＬＮＥＴを利用する他のプロトコルが異なるレベルの
アウトバンド信号と見なせるＴＥＬＮＥＴコマンドを明示的に必要とする
かもしれません。
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:
取り決めをする事で、［ＩＰ、Synch］の連続がこのようなシグナルとし
て用れるはずです。例えば、ＴＥＬＮＥＴを使う何か他のプロトコルが文
字列ＳＴＯＰをＴＥＬＮＥＴコマンドＡＯに同様に定義すると考えてくだ
さい。このプロトコルのユーザがサーバがＳＴＯＰ文字列を処理すること
を望むが、接続が、サーバが他のコマンドを処理しているから、阻止され
ると想像してください。ユーザはシステムに以下に指示するべきです：
1. Send the TELNET IP character;
1. ＴＥＬＮＥＴ ＩＰ文字を送信；
2. Send the TELNET SYNC sequence, that is:
2. 以下のＴＥＬＮＥＴ ＳＹＮＣの連続を送信：
Send the Data Mark (DM) as the only character
in a TCP urgent mode send operation.
ＴＣＰ緊急のモード送信オペレーションで唯一の文字とし
てデータマーク（DM）を送信
3. Send the character string STOP; and
3. 文字列STOPを送信；そして
4. Send the other protocol's analog of the TELNET DM, if any.
4. もしあれば、他のプロトコルのＴＥＬＮＥＴ 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.
ユーザ（あるいは彼の代理として動くプロセス）はサーバのＴＥＬＮＥ
ＴインタプリタがＴＥＬＮＥＴ ＩＰを得ることを保証するため、ステッ
プ２のＴＥＬＮＥＴ ＳＹＮＣＨの連続を送信しなくてはなりません。
The Urgent should wake up the TELNET process; the IP should
wake up the next higher level process.
緊急通知はＴＥＬＮＥＴプロセスを目ざめさせるべきです；ＩＰは次
の上位レベルのプロセスを目ざめさせるべきです。
THE NVT PRINTER AND KEYBOARD
ＮＶＴプリンターとキーボード
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:
ＮＶＴプリンタは特定されていない幅とページ長さを持ち、そしてすべて
の９５のUSASCII図形（コード３２から１２６まで）の表示を作り出すこ
とができます。３３のUSASCII制御コード（０から３１までと１２７）と
１２８の対応していないコード（１２８から２５５まで）について、次の
様にＮＶＴプリンターでの意味を指定します：
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.
現在の行の左にプリンタを動かしま
す。
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:
さらに、ＮＶＴプリンターに対する以下のコードが、必須ではないが、
定義さます。どちらのＴＥＬＮＥＴ接続端も、これらを受信した相手
が特定の動作をすると考えるべきです：
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.
同じ水平な位置を保持して、次の
ページの最上部にプリンターを動
かします。
All remaining codes do not cause the NVT printer to take any
action.
すべての残りのコードはＮＶＴプリンターに行動をとらせません。
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」連続と同様）。しかしながら、多く
のシステムとターミナルが独立してCRとLFを扱わず、それらの効果をシ
ミュレートするある努力が必要でしょう。（例えば、ある端末がLFなし
のCRを持たず、このような端末上ではバックスペースによってCRをシミュ
レートすることは可能かもしれません。）それ故に、「CR LF」連続はひ
とつの「改行」文字と取り扱われて、それらの結合行動を意図する時は
いつでも使なくてはなりません；「CR NUL」連続が単独のキャリッジ・
リターンだけが実際に望ましい所に使いいます；CR文字はは他の文脈で
避けなくてはなりません。この規則は、「改行」か複数のバックスペー
スかを決定しなければいけないシステムに、ＴＥＬＮＥＴ流がCRの後の
１文字で合理的な決定を許す保証を与えます。
Note that "CR LF" or "CR NUL" is required in both directions
(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.
ＮＶＴモデルの対称を維持するため、「CR LF」あるいは「CR NUL」が
両方向で（デフォルトASCIIモードで）、要求されることに注意を払っ
てください。文字が実際のプリンターに送られていないある状態があ
りますが（例えば、遠隔エコーと、送信抑圧モード）、にもかかわら
ず、一貫性のために、プロトコルが後にLFが続かないCRでNULをデータ
流に入れる事を要求します。逆に言うと（さもなければ明示的に指定
するオプション交渉なしで）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.
ＮＶＴキーボードはすべての１２８のUSASCII コードを生成する、キーか、
キーの組合せか、キー連続を持ちます。多くがＮＶＴプリンターに対する
効果を持っていないけれども、ＮＶＴキーボードがそれらを生み出すこと
ができることに注意を払ってください。
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.
これらのコードのほかに、ＮＶＴキーボードは以下の定義された追加コー
ドを生成できますが、記載している以外は、意味はないべきです。これ
らの「文字」のための実際のコード割当てはＴＥＬＮＥＴコマンド章に
あります、なぜならそれらは、ある意味、一般的なコマンドで、データ
流が何か他の文字セットであるとして解釈される時さえ、利用可能であ
るからです。
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を（コマンド章参照）送ります、そしてＴ
ＣＰ緊急の通知がそれと結び付けられます。DM-緊急対が前に定義され
る意味を必要とします。
Break (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外の、多くのシステムでローカルな意味を与え
られたシグナルであるから、供給されます。ブレークキーあるいは注
意キーが打たれたことを示すことことを意図します。しかしながら、
これがＩＰ標準表現と同義語ではなく、これを必要とするシステムに
第１２９番目のコードを提供するように意図されることを注意を払っ
てください。
Interrupt Process (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.
ＮＶＴが接続してるプロセスを中断か割込みか中止か停止します。同
じく、ＴＥＬＮＥＴを使う他のプロトコルの、アウトバンド信号の一
部です。
Abort Output (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)
Send back to the NVT some visible (i.e., printable) evidence
that the AYT was received.
ＮＶＴに、ＡＹＴを受信した証拠の、目に見えるなにか（すなわち、
印刷可能）を送る。
Erase Character (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.
受取人はＴＥＬＮＥＴ接続を通して送ったデータストリームから「CR
LF」まで（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」から「ローカル」へのマッピングの自然な拡張を表
すべきということです。ちょうどＮＶＴデータバイト６８（８進数で１０
４）がローカルコードの「大文字Ｄ」にマップされるべきであるように、
ＥＣ文字はローカルな「消去文字」機能にマップされるべきです。さらに、
１２４（８進数１７４）のマッピングが「直立バー」文字を持っていない
環境で幾分任意であるから、ＥＬ文字は、もしローカルな「行消去」機能
がないなら、幾分任意のマッピング（あるいはマッッピングなし）かもし
れません。同様にフォーマット効果：もし端末が実際に「縦のタブ」を持っ
ているなら、ＶＴのマッピングは明白で、そしてただ端末が縦タブを持っ
ていない時だけＶＴの効果が予想できないべきです。
TELNET COMMAND STRUCTURE
ＴＥＬＮＥＴコマンド構造体
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
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.
すべてのＴＥＬＮＥＴコマンドは少なくとも２バイトの連続から成り立ちま
す：「コマンドとして翻訳」（ＩＡＣ）文字と続くコマンドのコード。オプ
ション交渉を扱っているコマンドは３バイトの連続で、３番目のバイトが参
照されるオプションのコードです。このフォーマットは、「データ空間」の
いっそう包括的な使用は−もちろん基本的なＮＶＴ交渉によって−されるか
ら、ストリームの中にデータバイトを「エスケープ」する不都合や非能率を
必要とするので、予約コマンド値のデータバイトの衝突が最小化されるよう
に選択されました。現在の設定で、ただＩＡＣをデータそして送る場合だけ
が２倍にされる必要があり、他の２５５のコードが透過的に送られるために
ます。
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.
次は定義されたＴＥＬＮＥＴコマンドです。これらのコードとコードの連続
が、前にＩＡＣがある時だけ、示された意味を持つことに注意を払ってくだ
さい。
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.
Synchのデータ流部。これは常にＴＣＰ
緊急通知に伴うべきです。
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.
データバイト２５５。
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.
ＴＥＬＮＥＴ ＴＣＰ接続はユーザーのポートＵとサーバポートＬ間に確立さ
れます。サーバはこのような接続のために、よく知られているポートＬの上
で聞きます。ＴＣＰ接続が全二重で、１対のポートによって識別されるので、
サーバはそのポートＬと異なったユーザポートＵの多くの同時の接続に従事
できます。
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.
遠隔ユーザがサービスホストにアクセスする時（すなわち、遠隔端末アク
セス）、このプロトコルはサーバーポート２３（８進数の２７）を割り当
てられます。Ｌ ＝ ２３です。