RFC318 日本語訳
0318 Telnet Protocols. J. Postel. April 1972. (Format: TXT=34928 bytes) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Jon Postel Request for Comments: 318 UCLA-NMC NIC: 9348 April 3, 1972 References: RFC 139, 158, and NIC 7104
コメントを求めるワーキンググループジョンポステルRequestをネットワークでつないでください: 318UCLA-NMC NIC: 9348の1972年4月3日参照箇所: RFC139、158、およびNIC7104
Telnet Protocol
テルネット・プロトコル
At the October 1971 Network Working Group Meeting, I promised to promptly produce a document which clearly and succinctly specified and explained the Official Telnet Protocol. This document fails to meet any part of that promise. This document was not produced promptly. This document is neither clear nor succinct. There is NO Official Telnet Protocol.
1971年10月のNetwork作業部会Meetingでは、私は、即座に、明確に、簡潔にOfficialテルネット・プロトコルが指定して、わかったドキュメントを製作すると約束しました。 このドキュメントはその約束の少しの部分も達成しません。 このドキュメントは即座に製作されませんでした。 このドキュメントは、明確でなくて、また簡潔ではありません。 Officialテルネット・プロトコルが全くありません。
The following pages present my understanding of the ad hoc Telnet protocol. There are some who have serious questions about this protocol. The proposed changes to the protocol are given in Section IV.
以下のページは私の臨時のTelnetプロトコルの理解を提示します。 このプロトコルに関する重大問題を持っている何かがあります。 セクションIVでプロトコルへの変更案を与えます。
Any comments should be promptly directed to me via the Network Information Center (Ident = JBP) or by phone (213) 825-2368 or by mail.
どんなコメントもNetworkインフォメーション・センター(IdentはJBPと等しい)を通して電話(213)825-2368かメールによって即座に私に向けられるべきです。
Jon Postel
SPADE Group
3804 Boelter Hall
UCLA
Los Angeles, California 90024
ジョンポステルすきのグループ3804BoelterホールUCLAロサンゼルス、カリフォルニア 90024
Postel [Page 1] RFC 318 Telnet Protocol April 1972
ポステル[1ページ]RFC318テルネット・プロトコル1972年4月
I. DEFINITION OF THE NETWORK VIRTUAL TERMINAL
I. ネットワーク仮想端末の定義
The Network Virtual Terminal (NVT) is a bi-directional character device. The characters are represented by 8 bit codes. The NVT has no timing characteristics. The character codes 0 through 127 are the USASCII codes. (Note all code values are given in decimal.) The codes 128 through 255 are used for special control signals. The NVT is described as having a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data.
Network Virtual Terminal(NVT)は双方向のキャラクタデバイスです。 キャラクタは8つのビット・コードによって代理をされます。 NVTには、タイミングの特性が全くありません。 キャラクタコード0〜127はUSASCIIコードです。 (すべてのコード値が小数で与えられていることに注意してください。) コード128〜255は特別な制御信号に使用されます。 NVTはプリンタとキーボードを持っているとして記述されています。 プリンタは受信データに応じます、そして、キーボードは発信データを作り出します。
The Printer
プリンタ
The NVT printer has an unspecified carriage width (common values are 40, 72, 80, 120, 128, 132). The printer can produce representations of all 95 USASCII graphics (codes 32 through 126). Of the 33 USASCII control codes (0 through 31 and 127) the following 8 have specific meaning to the NVT printer.
NVTプリンタには、不特定のキャリッジ幅があります(共通の価値観は40、72、80、120、128、132です)。 プリンタはすべての95のUSASCIIグラフィックス(32〜126に、コード化する)の表現を作成できます。 33のUSASCII制御コード(0〜31と127)では、以下の8はNVTプリンタに特定の意味を持っています。
NAME CODE MEANING
ネーム・コード意味
NULL (NUL) 0 A no operation.
NULL(NUL)0Aノー、操作。
BELL (BEL) 7 Produces an audible or visible signal.
ベル(BEL)7Produces、聞きとれるか目に見える信号。
Back Space (BS) 8 Backspaces the printer one character
position.
Space(BS)8Backspacesを支持してください。プリンタ1欄。
Horizontal Tab (HT) 9 Moves the printer to next horizontal
tab stop.
次の水平面へのプリンタがタブを付ける水平なTab(HT)9ムーヴスは止まります。
Line Feed (LF) 10 Moves the printer to next line (keeping
the same horizontal position).
次にへのプリンタが裏打ちするFeed(LF)10ムーヴスを裏打ちしてください(同じ水平な位置を保って)。
Vertical Tab (VT) 11 Moves the printer to the next vertical
tab stop.
次の垂直タブへのプリンタが止める垂直なTab(バーモント)11ムーヴス。
Form Feed (FF) 12 Moves the printer to the top of the
next page.
次の先端へのプリンタが呼び出すFeed(FF)12ムーヴスを形成してください。
Carriage Return (CR) 13 Moves the printer to the left margin
of the current line.
キャリッジReturn(CR)13ムーヴス、現在行の左の橋へのプリンタ。
The remaining USASCII codes (1 through 6, 14 through 31, and 127) do not cause the NVT printer to take any action.
残っているUSASCIIコード(1〜6、14〜31、および127)で、NVTプリンタは少しの行動も取りません。
Postel [Page 2] RFC 318 Telnet Protocol April 1972
ポステル[2ページ]RFC318テルネット・プロトコル1972年4月
The Keyboard
キーボード
The NVT Keyboard has keys or key combinations or key sequences for generating all of the 128 USASCII codes. Note that although there are codes which have no effect on the NVT printer, the NVT Keyboard is capable of generating these codes.
NVT Keyboardには、128のUSASCIIコードのすべてを生成するためのキー、主要な組み合わせまたはキー順があります。 NVTプリンタの上で効き目がないコードがありますが、NVT Keyboardがこれらのコードを生成することができることに注意してください。
The End of the Line Convention
線コンベンションの終わり
The end of a line of text shall be indicated by the character sequence Carriage Return Line Feed (CR, LF). This convention applies to both the sending (Keyboard) and receiving (Printer) (virtual) mechanisms.
テキストの線の端はキャラクタシーケンスCarriage Return線Feed(CR、LF)によって示されるものとします。 このコンベンションは送付(キーボード)と受信(プリンタ)の(仮想)のメカニズムの両方に適用されます。
Break and Reverse Break
中断と逆は壊れます。
The Telnet control signals provide a BREAK signal which can be used to simulate the use of the break or attention or interrupt button found on most terminals. This signal has no effect on the NVT. When the BREAK Telnet control signal is used from server to user it is sometimes called "reverse break". Such a reverse break has no effect on the NVT.
Telnet制御信号はほとんどの端末で見つけられた中断、注意または中断ボタンの使用をシミュレートするのに使用できるBREAK信号を提供します。 この信号はNVTで効き目がありません。 BREAK Telnet制御信号がサーバからユーザまで使用されるとき、それは時々「逆の中断」と呼ばれます。 そのような逆の中断はNVTで効き目がありません。
II. DEFINITION OF TELNET PROTOCOL
II。 テルネット・プロトコルの定義
The purpose of Telnet Protocol is to provide a standard method of interfacing terminals devices at one site to processes at another site.
テルネット・プロトコルの目的は1つのサイトで別のサイトのプロセスに端末デバイスを連結する標準方法を提供することです。
The Telnet Protocol is built up from three major substructures, first the Initial Connection Protocol (ICP), second the Network Virtual Terminal (NVT), and third the Telnet control signals described herein.
テルネット・プロトコルは確立されて、3から、基礎、最初に、Initial Connectionプロトコル(ICP)が専攻していて、秒がNetwork Virtual Terminal(NVT)であるということです、そして、3番目に、Telnetはここに説明された信号を制御します。
Telnet user and server processes follow the ICP to establish connections. The term "Logger" has been associated with the set of processes in the serving system which respond to the ICP and perform the initial interactions e.g. obtain a name and password. The ICP is defined and the initial socket number and byte size parameters are defined in "Current Network Protocols" (NIC #7104).
telnetユーザとサーバプロセスは、関係を樹立するためにICPの後をつけます。 「きこり」という用語は給仕システムのICPに応じて、初期の相互作用を実行するプロセスのセットに関連しています、例えば、名前とパスワードを得てください。 ICPは定義されます、そして、初期のソケット番号とバイトサイズ・パラメータは「現在のネットワーク・プロトコル」(NIC#7104)で定義されます。
The data transmitted between the user and server programs (and vice versa) is treated as a character stream with embedded control signals.
ユーザとサーバプログラムの間に送られたデータは埋め込まれた制御信号で(逆もまた同様に)キャラクタストリームとして扱われます。
Note that all code values are given in decimal.
すべてのコード値が小数で与えられていることに注意してください。
Postel [Page 3] RFC 318 Telnet Protocol April 1972
ポステル[3ページ]RFC318テルネット・プロトコル1972年4月
TELNET CONTROL SIGNALS
telnet制御信号
NAME CODE MEANING
ネーム・コード意味
DATA MARK 128 Used to mark a point in the data stream.
Used in conjunction with INS. See SYNCH.
データでポイントをマークするDATA MARK128Usedは流れます。 INSに関連して、使用されています。 同時性を見てください。
BREAK 129 User-to-Server: Has the same meaning to
the server as the "Break," "Interrupt," or
"Attention" button found on many terminals.
中断129のユーザからサーバ: 「中断してください」と「中断」としてのサーバに意味する同じくらい、または「注意」ボタンに多くの端末で設立させます。
Server-to-User: Has the same meaning to
to use as the "reverse break" used with
some terminals.
サーバからユーザ: 同じくらいが、意味して、いくつかの端末と共に「逆の中断」としての使用に使用されて、持っています。
NOP 130 No Operation.
NOP130いいえ操作。
NO ECHO 131 User-to-Server: Asks the server not to
return Echos of the transmitted data.
エコー131のユーザからサーバがありません: 伝えられたデータのEchosを返さないようにサーバに頼みます。
Server-to-User: States that the server is
not sending echos of the transmitted data.
Sent only as a reply to ECHO or NO ECHO,
or to end the hide your input.
サーバからユーザ: サーバが発信が伝えられたデータをこだまさせるということでないと述べます。 ECHOかNO ECHOへの回答だけか、終わりに獣皮を送る、あなたの入力。
ECHO 132 User-to-Server: Asks the server to send
Echos of the transmitted data.
エコー132のユーザからサーバ: 伝えられたデータのEchosを送るようにサーバに頼みます。
Server-to User: States that the server is
sending echos of the transmitted data.
Sent only as a reply to ECHO or NO ECHO.
サーバ、-、ユーザ: サーバが発信が伝えられたデータをこだまさせるということであると述べます。 単に回答として、ECHOかNO ECHOに発信しました。
Hide your input 133 The intention is that a server will send
this signal to a user system which is
echoing locally (to the user) when the user
is about to type something secret (e.g. a
password). In this case, the user system
is to suppress local echoing or overprint
the input (or something) until the server
sends a NOECHO signal. In situations where
the user system is not echoing locally,
this signal must not be sent by the server.
入力133を隠してください。意志はサーバが局所的(ユーザに)に反映しているユーザシステムへのユーザが秘密の何か(例えば、パスワード)をタイプしようとしているこの信号を送るということです。 この場合、ユーザシステムは、サーバがNOECHO信号を送るまで、ローカル・エコーイングを抑圧するか、または入力を重ね打ちする(例えば)ことです。 ユーザシステムが局所的に鳴り響いていない状況で、サーバはこの信号を送ってはいけません。
INS --- This is the "Interrupt on Send" signal,
defined by the Host-to-Host protocol and
implemented by the Network Control Program
(NCP). See SYNCH.
インス--- 中断してください。これがそうである、「」 Hostからホストへのプロトコルによって定義されて、Network Control Program(NCP)によって実装された信号は発信します。 同時性を見てください。
Postel [Page 4] RFC 318 Telnet Protocol April 1972
ポステル[4ページ]RFC318テルネット・プロトコル1972年4月
SYNCH --- This is a condition indicated by the
combination of the DATA MARK and the INS.
同時性--- これはDATA MARKとINSの組み合わせで示された状態です。
User-to-Server: The Server is to examine
the input data stream looking for a DATA
MARK signal; if a DATA MARK is found, the
server must not process further until an
INS is received. If the server receives an
INS, it is required to examine the data
stream at once, taking any appropriate
action on "break type" characters (e.g.
etx, sub, BREAK), up to a DATA MARK signal
and thereupon continue its normal processing.
The passed over characters may be discarded.
ユーザからサーバ: ServerはDATA MARK信号を探す入力データ・ストリームを調べることになっています。 DATA MARKが見つけられるなら、さらにINSが受け取られているまで、サーバは処理されてはいけません。 サーバがINSを受けるなら、それが、「中断タイプ」キャラクタ(例えば、etx、潜水艦、BREAK)へのどんな適切な行動もDATA MARK信号まで取って、すぐに、データ・ストリームを調べて、正常処理をそれで続けるのに必要です。 通り過ぎられたキャラクタは捨てられるかもしれません。
Server-to-User: If the user finds a DATA
MARK in the data stream, it must wait for
an INS. If the user receives an INS, it
must examine and discard characters up to
and including a DATA MARK.
サーバからユーザ: ユーザがデータ・ストリームでDATA MARKを見つけるなら、それはINSを待たなければなりません。 ユーザがINSを受け取るなら、それは、DATA MARKを含めてキャラクタを調べて、捨てなければなりません。
DATA TYPES
データ型
Telnet normally deals in ASCII characters, but there are provisions for escaping to other code sets. If one of these escapes is used, it is undefined (here) whether or not the Telnet signals still have meaning or even how to return to the ASCII set: The Telnet signals used to indicate a change of code set are:
telnetは通常ASCII文字を扱いますが、他のコードセットに逃げるための条項があります。 これらのエスケープの1つが使用されているなら、Telnet信号に意味がまだあるか否かに関係なく、が(ここで)未定義であるか、またはどうASCIIに戻るかさえセットしました: コードの変化がセットしたのを示すのに使用されるTelnet信号は以下の通りです。
CODE MEANING
コード意味
160 ASCII - Standard Telnet
161 Transparent
162 EBCDIC
160ASCII--標準のtelnet161の透明な162EBCDIC
USER TELNET SIGNALS
ユーザtelnet信号
The following signals are to be available to the human user to cause the user Telnet to take the indicated action.
以下の信号はユーザTelnetが示された行動を取ることを引き起こすために人間のユーザにとって利用可能であることです。
Transmit Now - Transmit all data entered and locally
buffered now. Intended to be used with line
mode.
現在、伝わってください--今、入られて、局所的にバッファリングされたすべてのデータを送ってください。 ライン・モードで使用されるつもりでした。
Suppress end-of-line - Transmit all data entered and locally
buffered now, and do not transmit the
end-of-line immediately following this signal.
行末を抑圧してください--今、入られて、局所的にバッファリングされたすべてのデータを送ってください、そして、すぐにこの信号に従って、行末を伝えないでください。
Postel [Page 5] RFC 318 Telnet Protocol April 1972
ポステル[5ページ]RFC318テルネット・プロトコル1972年4月
STANDARD TELNET IMPLEMENTATION
標準のtelnet実装
Using Site
サイトを使用します。
1) User is able to enter and transmit all ASCII codes
1) ユーザは、すべてのASCIIコードに入って、伝えることができます。
2) User is able to cause the Telnet signals BREAK, SYNCH, ECHO and
NOECHO to be transmitted.
2) ユーザは、Telnet信号のBREAK、SYNCH、ECHO、およびNOECHOが伝えられることを引き起こすことができます。
3) Provides for the User Telnet signals, (e.g. Transmit Now).
3) User Telnet信号、(例えば、現在のTransmit)に備えます。
4) Implements the CR LF end-of-line convention.
4) CR LFが行末規約であると実装します。
5) Provides local echo for local user terminals.
5) 地上受信局のためのローカルエコーを提供します。
6) Correctly processes the Telnet signals BREAK, SYNCH, NOP, ECHO,
NOECHO, and Hide Your Input received from the server.
6) 正確に言えば、TelnetがBREAK、SYNCH、NOP、ECHO、NOECHO、およびHide Your Inputに合図するプロセスはサーバから受信されました。
Serving Site:
給仕サイト:
1) Provides a mapping between ASCII and the local character set.
1) ASCIIとローカルキャラクターセットの間にマッピングを提供します。
2) Correctly processes the Telnet signals BREAK, SYNCH, NOP, NOECHO,
and ECHO.
2) 正しく、Telnet信号のBREAK、SYNCH、NOP、NOECHO、およびECHOを処理します。
3) Implements the CR LF end-of-line convention.
3) CR LFが行末規約であると実装します。
4) Assumes the using site provides echoing. May provide a server
echo mode.
4) 使用サイトが反響を提供すると仮定します。 サーバエコーモードを提供するかもしれません。
MINIMUM TELNET IMPLEMENTATION
最小のtelnet実装
Using Site:
サイトを使用します:
1) User must be able to enter and transmit all ASCII codes.
1) ユーザは、すべてのASCIIコードに入って、伝えることができなければなりません。
2) Ignore and delete all Telnet signals from the serving site.
2) 給仕サイトからすべてのTelnet信号を無視して、削除してください。
3) Provide local echo for local user terminals.
3) 地上受信局のためのローカルエコーを提供してください。
4) Implements CR LF end-of-line convention.
4) CR LFが行末規約であると実装します。
5) Provide for the User Telnet signals.
5) User Telnet信号に備えてください。
Postel [Page 6] RFC 318 Telnet Protocol April 1972
ポステル[6ページ]RFC318テルネット・プロトコル1972年4月
Serving Site:
給仕サイト:
1) Provide a mapping between ASCII and the local character set.
1) ASCIIとローカルキャラクターセットの間にマッピングを提供してください。
2) Ignore and Delete all Telnet signals from the using site.
2) 無視、そして、すべてのTelnetが使用サイトから合図するDelete。
3) Assume the using site provides echoing.
3) 使用サイトが反響を提供すると仮定してください。
4) Implements the CR LF end-of-line convention.
4) CR LFが行末規約であると実装します。
III. DISCUSSION OF TELNET PROTOCOL
III。 テルネット・プロトコルの議論
The use of a standard, network-wide, intermediate representation of terminal code between sites is intended to eliminate the need for using and serving sites to keep information about the characteristics of each other's terminals and terminal handling conventions. This approach can be successful, but only if the user, the using site, and the serving site assume certain responsibilities.
サイトの間の端末のコードの標準的、そして、ネットワーク全体的、そして、中間的な表現の使用が互いの端末と端末の取り扱い規約の特性の情報を保つサイトを使用して、役立つ必要性を排除することを意図します。 ユーザ、使用サイト、および給仕サイトが、ある責任を負う場合にだけ、このアプローチはうまくいっている場合があります。
1. The serving site must specify how the intermediate code will be
mapped by it into the terminal codes that are expected at that
site.
1. 給仕サイトは中間コードがそれによってどうそのサイトで予想される端末のコードに写像されるかを指定しなければなりません。
2. The user must be familiar with that mapping.
2. ユーザはそのマッピングに詳しいに違いありません。
3. The using site must provide some means for the user to enter all
of the intermediate codes, and as a convenience, special Telnet
signals, as well as specify for the user how the signals from the
serving site will be presented at the user terminal.
3. 使用サイトは中間コードのすべてに入るユーザ、および便利としていくつかの手段を提供しなければなりません、と特別なTelnetは給仕サイトからの信号がユーザ端末にどう提示されるかにユーザに指定するのと同じくらいよく合図します。
Other schemes were considered but rejected. For example, a proposal that the using site be responsible for translating to and from the code expected by the serving site was rejected since it required that the using site keep tables of all serving site codes and provide a mapping for each case. The information would require constant maintenance as new hosts were added to the network.
他の体系は、考えられましたが、拒絶されました。 例えば、使用サイトがすべての給仕サイトコードのテーブルを保って、各ケースのためのマッピングを提供するのが必要であったので、使用サイトがコードと、そして、給仕サイトによって予想されたコードから翻訳するのに原因となるという提案は拒絶されました。 新しいホストがネットワークに追加されたように情報は一定のメインテナンスを必要とするでしょう。
Character Set
文字コード
Since it is not known how the current or future sites will specify the mapping between the network-wide standard code (7 bit ASCII in an 8 bit field) and the codes expected from their own terminals, it seems necessary to permit the user to cause transmission of every one of the 128 ASCII codes, plus (for full user power) selected signals (either of a Telnet control nature, or of a special terminal nature such as break or attention).
現在の、または、将来のサイトがどのようにネットワーク全体の標準のコード(8ビットの分野の7ビットのASCII)とそれら自身の端末から予想されたコードの間のマッピングを指定するかが知られていないので、ユーザが128のASCIIコードの皆のトランスミッションを引き起こすことを許可するように必要に思えます、プラス(完全なユーザパワーのための)の選択された信号(Telnetコントロール本質、または中断か注意などの特別な端末の本質について)。
Postel [Page 7] RFC 318 Telnet Protocol April 1972
ポステル[7ページ]RFC318テルネット・プロトコル1972年4月
There was strong feeling about the importance of the user/system interface at the using site, but equally strong feeling that this problem is one of local implementation and should reflect the using site installation philosophy rather than be subject to network-wide standards. Some topics of consideration in this area are:
使用しているサイトインストール哲学は、ネットワーク全体の規格を受けることがあるよりむしろこの問題が1であると感じながらユーザ/システム・インタフェースの重要性に関して使用サイト、しかし、等しく強く感じるのに地方の実装に強く、反射するべきです。 この領域での考慮のいくつかの話題は以下の通りです。
1. How to represent special graphics, not available at the using
site, at the user's terminal.
1. 使用サイト、ユーザの端末に利用可能でない特別なグラフィックスを表す方法。
2. Treatment of upper/lower case problem on upper case only
devices.
2. 上側か下側の処理は大文字の上で問題をケースに入れます。デバイスだけ。
a. Representing lower-case output.
a。 小文字の出力を表します。
b. Providing users with shift and shiftlock signals.
b。 シフトとshiftlockをユーザに提供するのは合図します。
3. Incorporating editing capability in Telnet.
3. 編集能力をTelnetに取り入れます。
4. Extending user options in Network mode not available to local
users, e.g., hold output or kill print.
4. 地元のユーザには、利用可能でないNetworkモードにおけるユーザ・オプションを広げていて、例えば、出力を持っているか、または印刷を殺してください。
5. Permit users to specify how keyboard input is to the
translated, e.g., let a character from the terminal cause a
specified string to be sent by the user's Telnet.
5. ユーザが翻訳にはキーボード入力がどうあるかを指定することを許可してください、そして、例えば、端末からのキャラクタはユーザのTelnetに指定されたストリングを送らせてください。
The proposed solution to the Telnet Protocol problem seems to provide a mechanism for a minimum implementation while providing a basis for developing richer sets or protocol for present and future use in terminal applications, process-process communications, and use by other conventions to pass data or control information.
テルネット・プロトコル問題への提案された解決は展開しているより豊かなセットの基礎を提供している間、最小の実装にメカニズムを提供するか、または端末のアプリケーション、プロセス間通信、および他のコンベンションによる使用における現在の、そして、今後の使用のためにパスデータか制御情報に議定書を作るように思えます。
The understanding that ASCII be used as a network-wide code has been established for some time. Its use in Telnet provided a problem with respect to the limitation of a maximum character set of 128. Some systems provide for more than this number in their operation, and therefore, as serving sites, cannot map on a one-for-one basis.
ASCIIがネットワーク全体のコードとして使用されるという理解はしばらく確立されています。 Telnetにおける使用は128の最大の文字集合の制限に関して問題を提供しました。 サイトに役立つとして、いくつかのシステムは、彼らの操作におけるこの数以上に備えて、したがって、個人的には1つで基礎を写像できません。
Each such serving site could probably provide a reasonably useful character set, including all system control signals, by mapping 128 of its codes and just not provide a network user access to the other codes. However, any character left out might later be used in a major application at that site as a special control signal. This could result in denying network users the facility offered by that application. Serving sites are, therefore, encouraged to provide a full mapping between the ASCII code and the code used on the serving system. This may require that the server specify two character ASCII sequences which map to single characters in the servers character set.
サイトに各役立つのであると、そのようなたぶん128のコードを写像することによってすべてのシステム制御信号を含むかなり役に立つ文字集合を提供して、ただ他のコードへのネットワーク利用者アクセスは提供できませんでした。 しかしながら、省かれたどんなキャラクタも後でそのサイトの特別な制御信号としての主用途で使用されるかもしれません。 これはそのアプリケーションで提供された施設をネットワーク利用者に対して否定するのに結果として生じることができました。 したがって、給仕サイトが給仕システムの上で使用されるASCIIコードとコードの間に完全なマッピングを提供するよう奨励されます。 これは、サーバがサーバ文字集合でキャラクタをシングルに写像する2つのキャラクタASCII系列を指定するのを必要とするかもしれません。
Postel [Page 8] RFC 318 Telnet Protocol April 1972
ポステル[8ページ]RFC318テルネット・プロトコル1972年4月
Notice that there are some ASCII codes which have no effect on the NVT printer. These codes must be transmitted over the network when output by the serving process or by entered by the user.
NVTプリンタの上で効き目がないいくつかのASCIIコードがあるのに注意してください。 給仕プロセスかユーザによって入られることによって出力されると、これらのコードをネットワークの上に伝えなければなりません。
End of Line Convention
行末コンベンション
The representation of the end of a physical line at a terminal is implemented differently on different network hosts. For example, some use a return (or new line) key, the terminal hardware both returns the carriage or printer to start of line and feeds the paper to the next line. In other implementations, the user hits carriage return and the hardware returns carriage while the software sends the terminal a line feed. The network-wide representation is carriage return followed by line feed. It represents the physical formatting that is being attempted, and is to be interpreted and appropriately translated by both using site and serving site.
端末の物理行の端の表現は異なったネットワークホストの上で異なって実装されます。 例えば、或るものがリターン(または、復帰改行)キーを使用して、端末のハードウェアは、キャリッジかプリンタを系列の始まりに返して、次の系列に紙を提供します。 他の実装では、ユーザは復帰を打ちます、そして、ソフトウェアは改行を端末に送りますが、ハードウェアはキャリッジを返します。 ネットワーク全体の表現は改行がいうことになった復帰です。 それは試みられて、解釈されて、両方によってサイトを使用することで適切に翻訳されて、サイトに役立つことになっている物理的な形式を表します。
EXAMPLE: A Multics user is working, through the network, on some
serving site host. In the course of the session the user has
numerous occasions to hit New Line on his Model 37 TTY. Each time
the Multics system is awakened by a New Line interrupt, the line
of buffered characters is passed to Telnet where it is scanned for
special characters. If none is found, carriage return followed by
line feed is inserted where New Line was entered, and the line is
turned over the NCP for transmission. Correspondingly, when the
Multics Telnet finds the carriage return line feed sequence in the
data stream coming from the serving site, the two characters are
replaced with the appropriate New Line code which is sent to the
terminal.
例: Multicsユーザはネットワークを通して給仕のサイトホストに働いています。 セッションの間に、ユーザには、彼のModel37TTYにNew線を打つ多数の時があります。 MulticsシステムがNew線中断で目を覚ます各回、バッファリングされたキャラクタの系列はそれが特殊文字のためにスキャンされるTelnetに通過されます。 なにも見つけられないなら、改行があとに続いた復帰はNew線が入れられたところに挿入されます、そして、系列はトランスミッションのためにNCPの上にターンされます。 Multics Telnetが、給仕サイトから来るデータ・ストリームで復帰改行が系列であることがわかると、2つのキャラクタを端末に送られる適切なNew線コードに対応する、取り替えます。
Telnet defines the end of a line to be indicated by the ASCII character pair CR LR. Several of the real devices in the world have only a single new line (NL) function. Several of the computer systems have in some programs used the CR and LF functions to have semantic meaning larger than the format effect they provide. Further, several computer systems allow the CR and LF functions to be used separately (e.g., such that a line may be overprinted). One problem, for those Telnet (user) programs required to map the NVT into a device which only has a NL function, is how is the CR LF to be dealt with. One solution is to examine the character following the CR. If an LF is found, then perform the NL function; if anything else is found then back space to the beginning of the line. Another problem is the case of a computer system which locally uses period, ".", to cause the new line function and which uses, in some programs, CR and LF for semantically significant operations. Suppose the user Telnet sends the sequence CR LF. Does this mean "new line" or the "CR operation" followed by the "LF operation "? A solution to this problem it to require that Telnet programs send a CR NOT intended to
ASCII文字組CR LRによって示されるように、telnetは線の端を定義します。 世界の実際のデバイスの数個には、ただ一つの復帰改行(NL)機能しかありません。 コンピュータ・システムの数個が、意味意味をそれらが供給する形式効果より大きくするのにいくつかのプログラムでCRとLF機能を使用しました。 さらに、数個のコンピュータ・システムが、CRとLF機能が別々に使用されるのを許容します(例えば、系列を重ね打ちできるように)。 NL機能を持っているだけであるデバイスにNVTを写像するのに必要であるそれらのTelnet(ユーザ)プログラムのために、1つの問題はどのようにが対処されるべきCR LFであるかということです。 1つのソリューションはCRに続いて、キャラクタを調べることです。 LFが見つけられるなら、NL機能を実行してください。 当時の後退が系列の始まりまで他の何かに見つけられるなら。 . 」 意味的に重要な操作のための新しさが裏打ちする機能といくつかのそれの用途がプログラムを作る原因への「別の問題は局所的に期間を費やすコンピュータ・システムに関するケースです」、CR、およびLF。 ユーザTelnetが系列CR LFを送ると仮定してください。 これは「復帰改行」か「CR操作」を意味しますか?、続いて、「LF操作」を意味します。 CR NOTを送ることにおけるこの問題への解決はそうするつもりでした。
Postel [Page 9] RFC 318 Telnet Protocol April 1972
ポステル[9ページ]RFC318テルネット・プロトコル1972年4月
be part of a CR LF pair as a CR NUL pair. Then the receiving program can always hold a CR and examine the next character to determine if a new line function is intended. This solution is strongly recommended.
CR NUL組としての1CR LF組の一部になってください。 次に、受信プログラムは、復帰改行機能が意図するかどうか決定するためにいつもCRを支えて、次のキャラクタを調べることができます。 このソリューションは強く推薦されます。
One other question arises here, "Is it permitted to send the Telnet signal NOP (code 130) between a CR and a LF when these are intended to signify new line?" The answer is "yes, the NOP signal may occur anywhere in the data stream."
他の1つの質問が起こる、ここの、「これらが復帰改行を意味することを意図するとき、Telnet信号NOP(コード130)をCRとLFの間に送ることが許可されていますか?」 答えは「はい、NOP信号はデータ・ストリームでどこでも発生するかもしれません」です。
Echoing
反響します。
The decision to have the assumed condition for echo be that the using site will provide any echo necessary for its terminals was taken because of the difficulties faced by some installations that cannot turn off their echo or that have terminals that print locally as a result of key strokes. Serving sites could take the position "have user turn echo off," but this seems an unnecessary burden on the user. In addition, some serving sites may choose not to supply any echo service, in which case the no echo assumption will supply a network-wide condition, while other assumptions would give a mixed starting condition.
キーストロークの結果、局所的に印刷するそれらのエコーをオフにすることができないか、または端末を持っているいくつかのインストールで直面されていた困難のために、エコーのための想定された状態が使用サイトが端末に必要などんなエコーも供給するということであることを持っているという決定を取りました。 サイトに役立つと、「ユーザ回転エコーを休みにしてください」という立場は取るかもしれませんが、これはユーザの上で不必要な負担に見えます。 追加、供給しないサイトがどんなエコーサービス、その場合ノーも選ぶかもしれない何らかの給仕では、エコー仮定はネットワーク全体の状態を提供するでしょう、他の仮定が複雑な始めの状態を与えるでしょうが。
The convention of using "ECHO," "NO ECHO" signals seems to fill both the requirements for dynamic echo control and for a minimum implementation of Telnet Protocol. Note that when the user request ECHO or NO ECHO the server replies by switching to the desired mode (and possibly returning the signal for the new mode), or by continuing in the current mode and returning the signal for the current mode. The server never spontaneously sends an ECHO or NO ECHO signal. Except that a NOECHO may be used to cancel a HIDE YOUR INPUT.
使用「エコー」のコンベンション、「いいえエコー」信号はダイナミックなエコー制御とテルネット・プロトコルの最小の実装のための両方の要件をいっぱいにするように思えます。 ユーザ要求ECHOかNO ECHOであるときに、サーバが必要なモードに切り替わるか(ことによると新型のための信号を返して)、現在のモードで続いて、または現在のモードのために信号を返すことによって返答することに注意してください。 サーバは自然にECHOかNO ECHO信号を決して送りません。 NOECHOがHIDE YOUR INPUTを取り消すのに使用されるかもしれないのを除いて。
Hide Your Input
入力を隠してください。
The HIDE YOUR INPUT signal presents some difficulty in that it is unclear how much is to be hidden. The server site usually knows how long the secret is but the user Telnet in general does not. Furthermore, if the user site cannot suppress the local echoing, there is a difficult implementation problem. One possibility is for the using site to overprint a full line with a mask, then have the user type his secret on the mask. If the secret were longer than one line, the use of the mask should be repeated.
どのくらいが隠されることになっているかが、不明瞭であるので、HIDE YOUR INPUT信号は困難を提示します。 サーバサイトは、秘密がどれくらい長いかを通常知っていますが、一般に、ユーザTelnetはそのように知りません。 その上、ユーザの現場がローカル・エコーイングを抑圧できないなら、難しい実装問題があります。 1つの可能性は、使用サイトでマスクで実線を重ね打ちして、次に、ユーザがマスクの上に彼の秘密をタイプすることです。 秘密が1つの系列より長いなら、マスクの使用は繰り返されるでしょうに。
The use of HIDE YOUR INPUT can be avoided altogether by having the serving site send a mask (which it knows to be just long enough) on which the user is to type the secret information.
給仕サイトにユーザが秘密の情報をタイプすることになっているマスク(それがただ十分長いのを知っている)を送らせることによって、HIDE YOUR INPUTの使用を全体で避けることができます。
Postel [Page 10] RFC 318 Telnet Protocol April 1972
ポステル[10ページ]RFC318テルネット・プロトコル1972年4月
EXAMPLE:
例:
1. Default assumption is user site is echoing
1. デフォルト仮定はユーザの現場が反映しているということです。
2. Server-to User: Password Please CR LF
2. サーバ、-、ユーザ: お願いします、パスワードCR LF
3. Server-to-User: XXXXCRIIIIICRMMMMCR NUL
3. サーバからユーザ: XXXXCRIIIIICRMMMMCR NUL
4. User-to-Server: "password" CR LF
4. ユーザからサーバ: 「パスワード」CR LF
5. Server-to-User: Ready CR LF
5. サーバからユーザ: 持ち合わせのCR LF
Breaks and Attentions
中断とこころづくし
There is a special control signal on some terminals that has no corresponding bit pattern in ASCII, but is transmitted by a special electrical signal. This control signal is Attn on a 2741 and Break on a Teletype. This signal is represented by the Telnet control signal BREAK. There is a corresponding control signal for use from serving sites to using sites for reverse break. Notice, however, that the NVT is a bi-directional character device, thus there is no need to "turn the line around".
いくつかの端末の上のASCIIではどんな対応するビット・パターンも持っていませんが、特別な電気的信号によって送信される特別な制御信号があります。 この制御信号は、2741のAttnとテレタイプのBreakです。 この信号はTelnetコントロール信号BREAKによって表されます。 逆の中断のサイトに役立つのからサイトを使用するまでの使用のための対応する制御信号があります。 しかしながら、NVTが双方向のキャラクタデバイスであるのに注意してください、そして、その結果、「系列を変える」必要は全くありません。
Some systems treat the Break as an extra code available for use in conjunction with the data stream. For example, one system uses Break as a special editing code meaning "delete the current line to this point." In these cases, the code may simply be inserted in the data stream with no special additional action by the user.
いくつかのシステムがデータ・ストリームに関連して使用に利用可能な付加的なコードとしてBreakを扱います。 例えば、「現在行をこの位まで削除します」と意味しながら、1台のシステムが特別な編集コードとしてBreakを使用します。 これらの場合では、コードはユーザによって特別な追加措置なしで単にデータ・ストリームに挿入されるかもしれません。
Other systems use Break or Attn in special interrupt fashion, to mean stop processing the application and give me the supervisor, or cancel the present job, etc. (Other systems which inspect input on a character at a time basis use normal characters for this purpose, such as <etx>.) In these cases, because of differences in the ways both serving and using sites operate, it is necessary to take a route in addition to the normal Telnet data stream to indicate that the special control signal is embedded in the data stream.
他のシステムは、アプリケーションを処理するのを止めることを意味するのに特別な中断ファッションでBreakかAttnを使用して、監督を私に与えるか、または現在の仕事を中止しますなど。 (時間主義でキャラクタに関する入力を点検する他のシステムがこのために普通のキャラクタを使用します、<etx>などのように。) これらの場合では、ともにサイトに役立って、使用するのが作動する方法の違いのために、特別な制御信号がデータ・ストリームに埋め込まれているのを示すために通常のTelnetデータ・ストリームに加えてルートを取るのが必要です。
Example -- Problem:
例--問題:
The PDP-10 normally will, when it fills its input buffer, continue
to accept characters from a terminal examining each to see if it
is a control character, then act on it if it is or throw it away
if it is not.
入力バッファをいっぱいにするとき、それが続けないと、PDP-10は、それが制御文字であるかどうか確認するためにそれぞれを調べる端末からキャラクタを受け入れるか、次に、それが行動するならそれに行動するか、または通常、それを捨て続けるでしょう。
Since the Telnet server at the serving site is at the mercy of the
NCP with respect to controlling the bunching, and therefore,
arrival at the Telnet of bursts of characters, Telnet
Telnet、以来、給仕サイトのTelnetサーバが束になることを制御することに関するNCP、およびしたがって、キャラクタの炸裂のTelnetへの到着の思うままにあります。
Postel [Page 11] RFC 318 Telnet Protocol April 1972
ポステル[11ページ]RFC318テルネット・プロトコル1972年4月
implementations might be expected to choke off flow to the buffers
until they are ready to accept characters without throwing them
away.
それらが彼らを捨てないでキャラクタを受け入れる準備ができるまで実装がバッファへの流れを止めると予想されるかもしれません。
Under this condition, the serving process might be outputting to
the using terminal, the input buffers at the server fill up, (with
user generated characters) and <etx> get stuck (at the user's
site) in the data stream that has been choked off.
この状態の下では、給仕プロセスは使用端末への出力、サーバにおけるバッファが満たす入力であるかもしれません(ユーザがキャラクタであると生成されている状態で)、そして、<etx>は止められたデータ・ストリームで立ち往生します(ユーザのサイトで)。
A similar problem could occur with Multics or some IBM system as a line at a time server. The user at a using site gets his process at the serving site into an output loop and wants to break the process without having to release his Telnet connection. The buffers clog the connection, transmission is choked off, and the <etx>, Break, or other user control signal gets stuck in the pipeline.
同様の問題は系列としてMulticsか何らかのIBMシステムで時間サーバで起こることができました。彼のTelnet接続を釈放する必要はなくて、使用サイトのユーザは、給仕サイトで彼のプロセスを出力輪に得て、プロセスを壊したがっています。 バッファは接続を妨げます、そして、トランスミッションは止められます、そして、<etx>、Break、または他のユーザ制御信号がパイプラインで立ち往生します。
Example -- Solution:
例--ソリューション:
The user at the using site knows he is entering a special control
signal (Break, Attn, <etx>, etc.) and follows it with a SYNCH.
(The local instructions at using sites for accomplishing this may
differ from site to site.)
使用サイトのユーザは、彼が特別な制御信号(中断、Attn、<etx>など)を入力していて、SYNCHと共にそれの後をつけるのを知っています。 (これを達成するのにサイトを使用するところのローカルの指示はサイトからサイトまで異なるかもしれません。)
User to Using Site Telnet
サイトtelnetを使用することへのユーザ
Send SYNCH.
同時性を送ってください。
Using Site Telnet to Serving Site Telnet:
サイトtelnetに役立つのにサイトtelnetを使用します:
DATA MARK in Data Stream.
データでのデータマークは流れます。
Using Site Telnet to Using Site NCP:
サイトNCPを使用するのにサイトtelnetを使用します:
Send an INS.
インチを送ってください。
Serving Site NCP to Telnet Server:
telnetサーバにサイトNCPに役立ちます:
Interrupt "INS received".
「受け取られたINS」を中断してください。
Serving Site Telnet:
給仕サイトtelnet:
Examines the input data stream (looking for special control
signals) until it sees DATA MARK then resumes normal
handling.
次に、DATA MARKが通常の取り扱いを再開するのがわかるまで、入力データ・ストリーム(特別な制御信号を探す)を調べます。
Thus, depending on the server's local implementation to
provide adequate service, a special handling of the data
stream can be invoked whenever an INS is received in order
したがって、オーダーにINSを受け取るときはいつも、データ・ストリームの特別な取り扱いは呼び出されて、適切なサービスを提供するためにサーバの地方の実装に依存できます。
Postel [Page 12] RFC 318 Telnet Protocol April 1972
ポステル[12ページ]RFC318テルネット・プロトコル1972年4月
to get to the special character. When it sees DATA MARK, it
recognizes it as a synchronization point and knowing that
the special character has been passed on, strips the DATA
MARK from the data stream and returns to normal mode.
特殊文字を始めるために。 DATA MARKを見るとき、同期ポイントであると認めて、特殊文字が持っている知っていることは、伝えられて、データ・ストリームからDATA MARKを剥取って、正規モードに戻ります。
If the DATA MARK arrives before the INS, the serving site
should not process the data stream further until an INS is
received.
DATA MARKがINSの前で到着するなら、さらにINSが受け取られているまで、給仕サイトはデータ・ストリームを処理するべきではありません。
This approach to handling selected special characters or signals relieves the using Telnet processes from having to recognize the special serving site characters, as well as from having to know how the serving site wants to handle them. At the same time, the procedure requires only a minimum level of user understanding of the serving site. This seems appropriate, since the Telnet ASCII conventions are providing a Network Virtual Terminal, not a Network Virtual User.
選択された特殊文字か信号を扱うことへのこのアプローチはTelnetが特別な給仕サイトキャラクタ、およびその方法を知らなければならないのからの給仕サイト必需品を見分けなければならないのでそれらを扱うために処理する使用を救います。 同時に、手順は最低水準の給仕サイトのユーザ理解だけを必要とします。 Telnet ASCIIコンベンションがNetwork Virtual Userではなく、Network Virtual Terminalを提供しているので、これは適切に見えます。
Notice that the correct order is (1) special character or signal (e.g. BREAK or <etx>), then (2) SYNCH.
正しいオーダーが(1)特殊文字か信号(例えば、BREAKか<etx>)であり、その時が(2)SYNCHであるのに注意してください。
User Telnet Signals
ユーザtelnet信号
The ability of the user to cause the using site Telnet to send any combination of ASCII characters in a string, and only that combination, is viewed as important to the user utility of the Telnet ASCII conventions. Because of this, some user sites may find it necessary to provide special local Telnet signals from the human user to the using site Telnet.
使用サイトTelnetを引き起こすユーザの能力は、ストリング、およびその組み合わせだけでASCII文字のどんな組み合わせも送って、Telnet ASCIIコンベンションに関するユーザユーティリティに重要であるとして見なされます。 これのために、いくつかのユーザの現場によって、人間のユーザから使用サイトTelnetまで特別なローカルのTelnet信号を提供するのが必要であることがわかるかもしれません。
Example:
例:
A user on a line at a time system (Multics, System 360, GCOS,
etx.), which require an end of line signal before processing the
user's input, is working through the Network on a serving site
that operates a character at a time. The application is a
debugging aid that permits the user to type in "location=" to
which it will respond with n where n represents the current
contents of that location. The serving site process does not
expect to see the "location=" followed by a carriage return line
feed sequence. The user at the using site should be able to type
in the location, follow it with a signal (to the user Telnet) to
suppress the end of line convention, followed by the end of line
signal, and expect the "location=" to be transmitted immediately
without an end of line sequence being transmitted to the server.
ユーザの入力を処理する前に行末信号を必要とする(Multics、System360、GCOS(etx))が一度にキャラクタを手術する給仕サイトのNetworkを通して扱っている時間システムの系列のユーザ。 アプリケーションはユーザがそれがnがその位置の現在のコンテンツを表すところでnで応じる「位置=」をタイプすることを許可するデバッギング・エイドです。 給仕サイトプロセスは、復帰改行系列が「位置=」のあとに続くのを見ると予想しません。 使用サイトのユーザは、位置をタイプして、行末コンベンションを抑圧するために信号(ユーザTelnetへの)でそれに続いて、行末信号で続いて、「位置=」がすぐサーバに伝えられる行末系列なしで伝えられると予想できるべきです。
Postel [Page 13] RFC 318 Telnet Protocol April 1972
ポステル[13ページ]RFC318テルネット・プロトコル1972年4月
Example:
例:
In another case, a using site has decided that it is convenient to
accumulate four characters at a time and transmit them to the
serving site, unless an end of line signal is observed, in which
case the end of line sequence is sent preceded by whatever number
of characters have been accumulated (presumably three or less).
In the same debugging application, the address is such that the
end does not correspond with the four character buffer
demarcation. The user should have the ability to enter a code for
"transmit immediately" in place of the end of line signal in order
to preserve neat formatting, and expect the address to be sent to
the serving site.
別の場合では、使用サイトは、一度に4つのキャラクタを蓄積して、給仕サイトに彼らを送るのが便利であると決めました、行末信号が観察されない場合数の何でもキャラクタが蓄積されたかによって(おそらく3以下)どの場合に行末系列を送るかは先行しました。 同じデバッグアプリケーションでは、アドレスがそのようなものであるので、終わりは4文字バッファ画定に対応していません。 ユーザは、きちんとした形式を保存して、「至急、伝わってください」のために行末信号に代わってコードを入れる能力を持って、アドレスが給仕サイトに送られると予想するべきです。
Telnet Signals have been discussed and those introduced to date are probably sufficient for an implementation of Telnet ASCII convention.
telnet Signalsについて議論しました、そして、これまで導入されたものはたぶんTelnet ASCIIコンベンションの実装に十分です。
Terminology
用語
ASCII - The USASCII character set as defined in NIC # 7104.
In Telnet Protocol, where eight bit codes are used
the lower half of the code set is defined to be
ASCII.
ASCII--7104年にNIC#定義されるUSASCII文字集合。 テルネット・プロトコルでは、コードセットの下半分は、ASCIIになるように定義されます。そこでは、8つのビット・コードが使用されています。
echoing - The display of a character entered is called echoing.
There are two modes in which this happens. If
the device used to enter characters displays the
character before (or as) it transmits the character
to the computer the echoing mode is called "local
echo." If, on the other hand, the device transmits
the entered character to the computer without
displaying it and the computer then transmits a
character to the device for the echo display, this
echoing mode is called "remote echo."
反響--入られたキャラクタのディスプレイは反響と呼ばれます。 これが起こる2つのモードがあります。 キャラクタに入るのが使用されるデバイスが(or as)の前にキャラクタを見せるなら、それはキャラクタをコンピュータに伝えます。反響モードは「ローカルエコー」と呼ばれます。 他方では、デバイスがそれを表示しないで入られたキャラクタをコンピュータに伝えて、次に、コンピュータがエコーディスプレイのためのデバイスにキャラクタを伝えるなら、この反響モードは「リモートエコー」と呼ばれます。
character mode - In this mode of operation Telnet transmits each
character as soon as possible. Generally speaking,
character mode is used when all of the using terminal,
using system, and serving system are operating
in a remote echo mode. The echos to the user
entered characters are transmitted from the serving
system (i.e., over the network).
キャラクタ・モード--この運転モードで、Telnetはできるだけ早く、各キャラクタを伝えます。 概して、キャラクタ・モードは使用端末のすべてであるときに、使用されて、システムを使用して、システムに役立つのがリモートエコーモードで作動しているということです。 やまびこ、ユーザに、入られたキャラクタは給仕システム(すなわち、ネットワークの上の)から伝えられます。
line mode - In this mode of operation Telnet transmits groups
of characters which constitute lines. Generally
speaking, this mode is used when one or more of
the using terminal, using system, or serving
ライン・モード--この運転モードで、Telnetは系列を構成するキャラクタのグループを伝えます。 概して、このモードは、使用端末の1つ以上であるときに、使用されるか、システムを使用するか、または役立っています。
Postel [Page 14] RFC 318 Telnet Protocol April 1972
ポステル[14ページ]RFC318テルネット・プロトコル1972年4月
system is operating in a local echo mode. The
echos to the user entered characters are not
transmitted over the network).
システムはローカルエコーモードで作動しています。 やまびこ、ユーザに入られて、キャラクタがネットワークの上に伝えられない、)
full duplex - This term indicates a transmission procedure using
a four wire connection, which permits simultaneous
transmission in both directions.
全二重--今期は、4線式接続(両方の方向に両方向同時伝送を可能にする)を使用することでトランスミッション手順を示します。
half duplex - This term indicates a transmission procedure using
a two wire connection, which requires that data be
transmitted in only one direction at at time.
半二重--時に今期にふたり結線を使用するトランスミッション手順を示します。その結線は、データが一方向だけに送られるのを必要とします。
Note that half duplex devices usually are also local echo but that full duplex devices may be either local echo or remote echo.
全二重デバイスがまた、半二重デバイスが通常ローカルエコーですが、ローカルエコーかリモートエコーのどちらかであるかもしれないことに注意してください。
IV. PROPOSED CHANGES TO TELNET PROTOCOL
IV。 テルネット・プロトコルへの変更案
The changes suggested here are not my ideas, thus the presentation may be faulty. I welcome RFC or other communication suggesting other changes or better arguments for and against these changes.
変化は、私の考えがここにないのを示しました、その結果、プレゼンテーションは不完全であるかもしれません。 私は変化を支持したこれらの変化に対する他の変化か、より良い議論を勧めるRFCか他のコミュニケーションを歓迎します。
Echoing
反響します。
It is proposed to delete from Telnet the control signals ECHO, NOECHO, and HIDE YOUR INPUT. For Server systems which do not provide echoing, these commands are useless. For server systems which do provide echoing experience has shown that the control is most effectively provided by server system commands.
それは、Telnetから制御信号のECHO、NOECHO、およびHIDE YOUR INPUTを削除するために提案されます。 反響を提供しないServerシステムにおいて、これらのコマンドは役に立ちません。 サーバシステムのために、どれが経験をまねながら提供されるかがコントロールがサーバシステム・コマンドで最も効果的に提供されるのを示しました。
Data Types
データ型
It is proposed to delete all mention of data types from Telnet. Either the character stream is ASCII or its not a Telnet communication. If it is really necessary to change the data type, a command in ASCII could be sent in the data stream.
それは、Telnetからデータ型のすべての言及を削除するために提案されます。 キャラクタストリームはASCIIであるかそれがTelnetコミュニケーションではありません。 データ型を変えるのが本当に必要であるなら、データ・ストリームでASCIIにおけるコマンドを送るかもしれません。
Minimum Implementation
最小の実装
It is proposed that the minimum implementation require the user Telnet to allow the user to send and the server Telnet to correctly process all the Telnet control signals.
最小の実装が、ユーザTelnetが送るユーザとサーバTelnetにすべてのTelnet制御信号を正しく処理させるのを必要とするよう提案されます。
Postel [Page 15] RFC 318 Telnet Protocol April 1972
ポステル[15ページ]RFC318テルネット・プロトコル1972年4月
The work on Telnet Protocol has involved many people. This document is taken from RFC's #139 and #158 by Tom O'Sullivan. Others who have served on committees are:
テルネット・プロトコルに対する仕事は多くの人々にかかわりました。 このドキュメントはトム・オサリヴァンによってRFCの#139、と#158、から取られます。 委員会の委員となった他のものは以下の通りです。
Bob Bressler MIT-DMCG
ボブBressler MIT-DMCG
Will Crowther BBN
ウィルクラウザーBBN
Bob Long SDC
ボブの長いSDC
Alex McKenzie BBN
アレックスマッケンジーBBN
John Melvin SRI-ARC
ジョンメルビン様アーク
Bob Metcalfe MIT-DMCG
ボブメトカルフェMIT-DMCG
Ed Meyer MIT-Multics
エドマイヤーMIT-Multics
Tol O'Sullivan Raytheon
トウルオサリヴァンレイセオン
Mike Padlipsky Mit-Multics
マイクPadlipsky Mit-Multics
Jon Postel UCLA-NMC
ジョンポステルUCLA-NMC
Bob Sundberg Harvard
ボブSundbergハーバード
Joel Winett LL
ジョエルWinett LL
Steve Wolfe UCLA-CCN
スティーブウルフUCLA-CCN
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Kelly Tardif, Viaginie 10/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ケリーTardifによるオンラインRFCアーカイブへのViaginie10/99]
Postel [Page 16]
ポステル[16ページ]
一覧
スポンサーリンク
