RFC1091 日本語訳
1091 Telnet terminal-type option. J. VanBokkelen. February 1989. (Format: TXT=13439 bytes) (Obsoletes RFC0930) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. VanBokkelen Request for Comments: 1091 FTP Software, Inc. Obsoletes: RFC 930 February 1989
VanBokkelenがコメントのために要求するワーキンググループJ.をネットワークでつないでください: ソフトウェアInc.が時代遅れにする1091年のFTP: RFC930 1989年2月
Telnet Terminal-Type Option
telnet端末のタイプオプション
Status of This Memo
このメモの状態
This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard.
このRFCはインターネットコミュニティの規格を指定します。 インターネットのTelnetプロトコルの中で端末のタイプ情報を交換するホストは、この規格を採用して、実装すると予想されます。
This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate.
この規格はRFC930に取って代わります。 変更が可能な端末のタイプのリストを通して循環して、最も好個を選択するのを許容すると行われます。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
1. Command Name and Code
1. コマンド名とコード
TERMINAL-TYPE 24
端末のタイプ24
2. Command Meanings
2. コマンド意味
IAC WILL TERMINAL-TYPE
IACは端末でタイプするでしょう。
Sender is willing to send terminal type information in a
subsequent sub-negotiation.
送付者は、その後のサブ交渉における端末のタイプ情報を送っても構わないと思っています。
IAC WON'T TERMINAL-TYPE
IACは端末でタイプしないでしょう。
Sender refuses to send terminal type information.
送付者は、端末のタイプ情報を送るのを拒否します。
IAC DO TERMINAL-TYPE
IACは端末でタイプします。
Sender is willing to receive terminal type information in a
subsequent sub-negotiation.
送付者は、その後のサブ交渉における端末のタイプ情報を受け取っても構わないと思っています。
IAC DON'T TERMINAL-TYPE
IACは端末でタイプしません。
Sender refuses to accept terminal type information.
送付者は、端末のタイプ情報を受け入れるのを拒否します。
VanBokkelen [Page 1] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[1ページ]RFC1091telnet
IAC SB TERMINAL-TYPE SEND IAC SE
IAC SBの端末のタイプはIAC SEを送ります。
Server requests client to transmit his (the client's) next
terminal type, and switch emulation modes (if more than one
terminal type is supported). The code for SEND is 1. (See
below.)
サーバは、彼の次の(クライアントのもの)端末のタイプ、およびスイッチエミュレーション・モードを伝えるようクライアントに要求します(1台以上の端末のタイプがサポートされるなら)。 SENDのためのコードは1です。 (以下を見てください。)
IAC SB TERMINAL-TYPE IS ... IAC SE
IAC SBの端末のタイプはそうです… IAC SE
Client is stating the name of his current (or only) terminal
type. The code for IS is 0. (See below.)
クライアントは彼の現在(単に)の端末のタイプの名前を述べています。 コード、0です。 (以下を見てください。)
3. Default
3. デフォルト
WON'T TERMINAL-TYPE
端末でタイプしないでしょう。
Terminal type information will not be exchanged.
端末のタイプ情報は交換されないでしょう。
DON'T TERMINAL-TYPE
端末でタイプしないでください。
Terminal type information will not be exchanged.
端末のタイプ情報は交換されないでしょう。
4. Motivation for the Option
4. オプションに関する動機
On most machines with bit-mapped displays (e.g., PCs and graphics workstations) a client terminal emulation program is used to simulate a conventional ASCII terminal. Most of these programs have multiple emulation modes, frequently with widely varying characteristics. Likewise, modern host system software and applications can deal with a variety of terminal types. What is needed is a means for the client to present a list of available terminal emulation modes to the server, from which the server can select the one it prefers (for arbitrary reasons). There is also need for a mechanism to change emulation modes during the course of a session, perhaps according to the needs of applications programs.
ビットマップディスプレイ(例えば、PCとグラフィックスワークステーション)があるほとんどのマシンの上では、クライアントターミナルエミュレーションプログラムは、従来のASCII端末をシミュレートするのに使用されます。 これらのプログラムの大部分には、頻繁に広く特性を変える複数のエミュレーション・モードがあります。 同様に、現代のホストシステムソフトとアプリケーションはさまざまな端末のタイプに対処できます。 必要であるものはクライアントが利用可能なターミナルエミュレーションモードのリストをサーバに提示する手段です。(サーバはサーバからそれが好む(任意の理由で)ものを選択できます)。 メカニズムがセッションのコースの間にエミュレーション・モードを変える必要もあります、恐らくアプリケーションプログラムの必要性に従って。
Existing terminal-type passing mechanisms within Telnet were not designed with multiple emulation modes in mind. While multiple names are allowed, they are assumed to be synonyms. Emulation mode changes are not defined, and the list of modes can only be scanned once.
Telnetの中でメカニズムを追い抜く既存の端末のタイプが複数のエミュレーション・モードで念頭に設計されませんでした。 複数の名前が許容されていますが、それらは同義語であると思われます。Emulationモード変更を定義しません、そして、一度モードのリストをスキャンできるだけです。
This document defines a simple extension to the existing mechanisms, which meets both of the above criteria. It makes one assumption about the behaviour of implementations coded to the previous standard in order to obtain full backwards-compatibility.
このドキュメントは既存のメカニズムへの単純拡大を定義します。(それは、上の評価基準の両方に会います)。 それは完全な遅れている互換性を得るために前の規格にコード化された実装のふるまいに関する、ある仮定をします。
VanBokkelen [Page 2] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[2ページ]RFC1091telnet
5. Description of the Option
5. オプションの記述
Willingness to exchange terminal-type information is agreed upon via conventional Telnet option negotiation. WILL and DO are used only to obtain and grant permission for future discussion. The actual exchange of status information occurs within option subcommands (IAC SB TERMINAL-TYPE...).
従来のTelnetオプション交渉で端末のタイプ情報を交換する意欲は同意されます。 してください。そして、使用されますが、未来の議論のために許可を得て、与えます。 状態情報の実際の交換はオプションサブコマンド(IAC SB TERMINAL-TYPE…)の中に起こります。
Once the two hosts have exchanged a WILL and a DO, the sender of the DO TERMINAL-TYPE (the server) is free to request type information. Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE) and only the client may transmit actual type information (within an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type information may not be sent spontaneously, but only in response to a request.
2人のホストがいったんウィルとaがするaを交換すると、DO TERMINAL-TYPE(サーバ)の送付者は自由にタイプ情報を要求できます。 サーバだけが要求(IAC SB TERMINAL-TYPE SEND IAC SE)を送るかもしれません、そして、クライアントだけが実際のタイプ情報(IAC SB TERMINAL-TYPE IS…IAC SEコマンドの中の)を伝えるかもしれません。 端末のタイプ情報は自然に、しかし、単に要求に対応して送られないかもしれません。
The terminal type information is an NVT ASCII string. Within this string, upper and lower case are considered equivalent. The complete list of valid terminal type names can be found in the latest "Assigned Numbers" RFC [4].
端末のタイプ情報はNVT ASCIIストリングです。 このストリングの中では、上側の、そして、より低いケースは同等であると考えられます。 最新の「規定番号」RFC[4]で有効な端末の型名に関する全リストを見つけることができます。
The transmission of terminal type information by the Telnet client in response to a query from the Telnet server implies that the client must simultaneously change emulation mode, unless the terminal type sent is a synonym of the preceding terminal type, or there are other prerequisites for entering the new regime (e.g., having agreed upon the Telnet binary option). The receipt of such information by the Telnet server does not imply any immediate change of processing. However, the information may be passed to a process, which may alter the data it sends to suit the particular characteristics of the terminal. For example, some operating systems have a terminal driver that accepts a code indicating the type of terminal being driven. Using the TERMINAL TYPE and BINARY options, a telnet server program on such a system could arrange to have terminals driven as if they were directly connected, including special functions not available to a standard Network Virtual Terminal.
Telnetサーバからの質問に対応したTelnetクライアントによる端末のタイプ情報の伝達が、クライアントが同時にエミュレーション・モードを変えなければならないのを含意するか、端末がタイプされないなら送るのが、前の端末のタイプの同義語である、または新政体(例えば、Telnetの2進のオプションに同意した)に入るための他の前提条件があります。 Telnetサーバによるそのような情報の領収書は処理の少しの急激な変化も含意しません。 しかしながら、情報はプロセスに通過されるかもしれません。(それは、それが端末の特定の特性に合うように送るデータを変更するかもしれません)。 例えば、いくつかのオペレーティングシステムで、コードを受け入れる端末のドライバーは運転される端末のタイプを示します。 TERMINAL TYPEとBINARYオプションを使用して、そのようなシステムの上のtelnetサーバプログラムは、まるでそれらが直接接続されるかのように端末を運転させるように手配するかもしれません、標準のNetwork Virtual Terminalに利用可能でない特別な機能を含んでいて。
Note that this specification is deliberately asymmetric. It is assumed that server operating systems and applications in general cannot change terminal types at arbitrary points in a session. Thus, the client may only send a new type (and potentially change emulation modes) when the server requests that it do so.
この仕様が故意に非対称であることに注意してください。 サーバオペレーティングシステムと一般に、アプリケーションがセッションのときに任意点で端末のタイプを変えることができないと思われます。 サーバが、それがそうするよう要求するときだけ、したがって、クライアントは新しいタイプ(潜在的にエミュレーション・モードを変える)を送るかもしれません。
6. Implementation Issues
6. 導入問題
The "terminal type" information may be any NVT ASCII string meaningful to both ends of the negotiation. The list of terminal type names in "Assigned Numbers" is intended to minimize confusion
「端末のタイプ」情報は交渉の両端に重要などんなNVT ASCIIストリングであるかもしれません。 「規定番号」における端末の型名のリストが混乱を最小にすることを意図します。
VanBokkelen [Page 3] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[3ページ]RFC1091telnet
caused by alternative "spellings" of the terminal type. For example, confusion would arise if one party were to call a terminal "IBM3278- 2" while the other called it "IBM-3278/2". There is no negative acknowledgement for a terminal type that is not understood, but certain other options (such as switching to BINARY mode) may be refused if a valid terminal type name has not been specified.
端末のタイプの代替の「スペル」で、引き起こされます。 例えば、1回のパーティーが端末を呼ぶなら混乱が起こる、「もう片方が、それを「IBM-3278/2インチ」と呼んだ間のIBM32782インチ どんな理解されていない端末のタイプに、否定的な承認もありませんが、有効な端末の型名が指定されていないなら、ある別の選択肢(BINARYモードに切り替わることなどの)は拒否されるかもしれません。
In some cases, either a particular terminal may be known by more than one name, for example a specific type and a more generic type, or the client may be a workstation with integrated display capable of emulating more than one kind of terminal. In such cases, the sender of the TERMINAL-TYPE IS command should reply to successive TERMINAL- TYPE SEND commands with the various names. In this way, a telnet server that does not understand the first response can prompt for alternatives. If different terminal emulations are supported by the client, the mode of the emulator must be changed to match the last type sent, unless the particular emulation has other Telnet options (e.g., BINARY) as prerequisites (in which case, the emulation will switch to the last type sent when the prerequisite is fulfilled). When types are synonyms, they should be sent in order from most to least specific.
いくつかの場合、特定の端末は1つ以上の名前によって知られているかもしれません、例えば、より多くのジェネリックタイプ、またはクライアントの特定のタイプとaは1種類以上の端末を見習うことができる統合ディスプレイがあるワークステーションであるかもしれません。 そのような場合、TERMINAL-TYPE ISコマンドの送付者は様々な名前で連続したTERMINAL- TYPE SENDコマンドに答えるべきです。 この道、最初の応答が代替手段のためにうながすことができるのを理解していないtelnetサーバで。 クライアントが異なったターミナルエミュレーションをサポートするなら、特定のエミュレーションに前提条件として他のTelnetオプション(例えば、BINARY)がない場合(その場合、エミュレーションは前提条件が実現しているとき送られた最後のタイプに切り替わるでしょう)送られた最後のタイプを合わせるためにエミュレータのモードを変えなければなりません。 タイプが同義語であるときに、大部分から最も特有にならないまで整然とした状態でそれらを送るべきです。
When the server (the receiver of the TERMINAL-TYPE IS) receives the same response two consecutive times, this indicates the end of the list of available types. Similarly, the client should indicate it has sent all available names by repeating the last one sent. If an additional request is received, this indicates that the server (the sender of the IS) wishes to return to the top of the list of available types (probably to select the least of N evils).
サーバ(TERMINAL-TYPE ISの受信機)が連続した2回同じ応答を受けるとき、これは手があいているタイプのリストの終わりを示します。 同様に、クライアントは、1つが送った最終を繰り返すことによってすべての利用可能な名前を送ったのを示すべきです。 追加要求が受信されているなら、これがそれを示す、サーバ、(送付者、)、手があいているタイプ(たぶんN弊害の最少を選択する)のリストの冒頭に戻るという願望。
Server implementations conforming to the previous standard will cease sending TERMINAL-TYPE SEND commands after receiving the same response two consecutive times, which will work according to the old standard. It is assumed that client implementations conforming to the previous standard will send the last type on the list in response to a third query (as well as the second). New-style servers must recognize this and not send more queries.
前の規格に従うサーバ実装は、連続した2回同じ応答を受けた後のコマンドをTERMINAL-TYPE SENDに送るのをやめるでしょう。(古い規格に従って、コマンドは働くでしょう)。 前の規格に従うクライアント実装が3番目の質問(2番目と同様に)に対応してリストの最後のタイプを送ると思われます。 新式サーバは、これを認識して、より多くの質問を送ってはいけません。
The type "UNKNOWN" should be used if the type of the terminal is unknown or unlikely to be recognized by the other party.
端末のタイプによって未知か相手によって認識されそうにないなら、タイプ「未知」は使用されるべきです。
The complete and up-to-date list of terminal type names will be maintained in the "Assigned Numbers". The maximum length of a terminal type name is 40 characters.
端末の型名の完全で最新のリストは「規定番号」で維持されるでしょう。 端末の型名の最大の長さは40のキャラクタです。
7. User Interfaces
7. ユーザインタフェース
Telnet clients and servers conforming to this specification should
この仕様に従うtelnetクライアントとサーバはそうするべきです。
VanBokkelen [Page 4] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[4ページ]RFC1091telnet
provide the following functions in their user interfaces:
それらのユーザインタフェースに以下の機能を提供してください:
Clients supporting multiple emulation modes should allow the user to specify which of the modes is preferred (which name is sent first), prior to connection establishment. The order of the names sent cannot be changed after the negotiation has begun. This initial mode will also become the default with servers which do not support TERMINAL TYPE.
複数のエミュレーションがモードであるとサポートするクライアントはユーザを指定させるべきです(モードについて好まれます)(名前が最初に送られる)、コネクション確立の前に。 交渉が始まった後に送られた名前の注文を変えることができません。 また、この初期のモードはTERMINAL TYPEをサポートしないサーバでデフォルトになるでしょう。
Servers should store the current terminal type name and the list of available names in a manner such that they are accessible to both the user (via a keyboard command) and any applications which need the information. In addition, there should be a corresponding mechanism to request a change of terminal types, by initiating a series of SEND/IS sub-negotiations.
サーバが方法で現在の端末の型名と利用可能な名前のリストを保存するべきであるので、それらはユーザ(キーボードのコマンドを通した)と情報を必要とするどんなアプリケーションの両方にもアクセスしやすいです。 さらに、端末のタイプの変化を要求する対応するメカニズムがあるはずであり、SENDのシリーズを開始することによって、/はサブ交渉です。
8. Examples
8. 例
In this example, the server finds the first type acceptable.
この例では、サーバは、最初のタイプが許容しているのがわかります。
Server: IAC DO TERMINAL-TYPE
サーバ: IACは端末でタイプします。
Client: IAC WILL TERMINAL-TYPE
クライアント: IACは端末でタイプするでしょう。
(Server may now request a terminal type at any time.)
(サーバはいつでも、現在、端末のタイプを要求するかもしれません。)
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
クライアント: IAC SBの端末のタイプはIBM-3278-2IAC SEです。
In this example, the server requests additional terminal types, and accepts the second (and last on the client's list) type sent (RFC 930 compatible):
この例では、サーバは、追加端末のタイプを要求して、2(そして、クライアントのリストでは、持続する)番目のタイプが送られると(RFC930コンパチブル)受け入れます:
Server: IAC DO TERMINAL-TYPE
サーバ: IACは端末でタイプします。
Client: IAC WILL TERMINAL-TYPE
クライアント: IACは端末でタイプするでしょう。
(Server may now request a terminal type at any time.)
(サーバはいつでも、現在、端末のタイプを要求するかもしれません。)
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS ZENITH-H19 IAC SE
クライアント: IAC SBの端末のタイプは天頂-H19 IAC SEです。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
クライアント: IAC SBの端末のタイプは未知のIAC SEです。
VanBokkelen [Page 5] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[5ページ]RFC1091telnet
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
クライアント: IAC SBの端末のタイプは未知のIAC SEです。
In this example, the server requests additional terminal types, and proceeds beyond the end-of-list, to select the first type offered by the client (new-type client and server):
この例では、サーバは、クライアント(新しいタイプクライアントとサーバ)によって提供された最初のタイプを選ぶために追加端末のタイプを要求して、リストの終わりに続きます:
Server: IAC DO TERMINAL-TYPE
サーバ: IACは端末でタイプします。
Client: IAC WILL TERMINAL-TYPE
クライアント: IACは端末でタイプするでしょう。
(Server may now request a terminal type at any time.)
(サーバはいつでも、現在、端末のタイプを要求するかもしれません。)
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
クライアント: IAC SBの端末のタイプは12月-VT220 IAC SEです。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS DEC-VT100 IAC SE
クライアント: IAC SBの端末のタイプは12月-VT100 IAC SEです。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
クライアント: IAC SBの端末のタイプは12月-VT52 IAC SEです。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
クライアント: IAC SBの端末のタイプは12月-VT52 IAC SEです。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
クライアント: IAC SBの端末のタイプは12月-VT220 IAC SEです。
9. References:
9. 参照:
[1] Postel, J., and J. Reynolds, "Telnet Protocol Specification",
RFC 854, USC Information Sciences Institute, May 1983.
[1] RFC854、科学が設けるUSC情報がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。
[2] Postel, J., and J. Reynolds, "Telnet Option Specification",
RFC 855, USC Information Sciences Institute, May 1983.
[2] RFC855、科学が設けるUSC情報がそうするポステル、J.とJ.レイノルズ、「telnetオプション仕様」1983。
[3] Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
RFC 930, University of Wisconsin - Madison, January 1985.
[3] ソロモン、M.とE.Wimmers、「telnet端末タイプオプション」RFC930、マディソン、1月1985日ウィスコンシン大学--
[4] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1010,
USC Information Sciences Institute, May 1987.
[4] USC情報科学が設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1010は1987がそうするかもしれません。
VanBokkelen [Page 6] RFC 1091 Telnet Terminal-Type Option February 1989
オプション1989年2月の端末のタイプのVanBokkelen[6ページ]RFC1091telnet
Reviser's note:
校訂者の注意:
I owe much of this text to RFCs 884 and 930, by Marvin Solomon and Edward Wimmers of the University of Wisconsin - Madison, and I owe the idea of the extension to discussions on the "tn3270" mailing list in the Summer of 1987.
私はRFCs884と930から本稿の多くを借りています、ウィスコンシン大学のマーヴィン・ソロモンとエドワードWimmers--マディソン、およびIは1987年のSummerの"tn3270"メーリングリストについての議論から拡大の考えを借りています。
Author's Address
作者のアドレス
James VanBokkelen FTP Software, Inc. 26 Princess Street Wakefield, MA 01880-3004
通りウェークフィールド、ジェームスVanBokkelen FTPソフトウェアInc.26姫MA01880-3004
Phone: (617) 246-0900
以下に電話をしてください。 (617) 246-0900
Email: jbvb@ftp.com
メール: jbvb@ftp.com
VanBokkelen [Page 7]
VanBokkelen[7ページ]
一覧
スポンサーリンク
