RFC930 日本語訳

0930 Telnet terminal type option. M. Solomon, E. Wimmers. January 1985. (Format: TXT=6583 bytes) (Obsoletes RFC0884) (Obsoleted by RFC1091) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                     Marvin Solomon
Request for Comments: 930                                 Edward Wimmers
Supersedes: RFC 884                    University of Wisconsin - Madison
                                                            January 1985

コメントを求めるワーキンググループマーヴィンソロモンRequestをネットワークでつないでください: 930 エドワードWimmers Supersedes: RFC884ウィスコンシン大学--マディソン1985年1月

                      TELNET TERMINAL TYPE OPTION

telnet端末タイプオプション

Status of This Memo

このメモの状態

   This RFC specifies a standard for the ARPA Internet community.  Hosts
   on the ARPA Internet that exchange terminal type information within
   the Telnet protocol are expected to adopt and implement this
   standard.  Distribution of this memo is unlimited.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのTelnetプロトコルの中で端末のタイプ情報を交換するホストは、この規格を採用して、実装すると予想されます。 このメモの分配は無制限です。

   This standard supersedes RFC 884.  The only change is to specify that
   the TERMINAL-TYPE IS sub-negotiation should be sent only in response
   to the TERMINAL-TYPE SEND sub-negotiation.  See below for further
   explanation.

この規格はRFC884に取って代わります。 唯一の変化が、TERMINAL-TYPE ISサブ交渉が単にTERMINAL-TYPE SENDサブ交渉に対応して送られるべきであると指定することになっています。 詳細な説明に関して以下を見てください。

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

送付者は、端末のタイプ情報を受け入れるのを拒否します。

   IAC SB TERMINAL-TYPE SEND IAC SE

IAC SBの端末のタイプはIAC SEを送ります。

      Sender requests receiver to transmit his (the receiver's) terminal
      type. The code for SEND is 1. (See below.)

送付者は、彼の(受信機のもの)端末のタイプを伝えるよう受信機に要求します。 SENDのためのコードは1です。 (以下を見てください。)

Solomon & Wimmers                                               [Page 1]

ソロモンとWimmers[1ページ]

RFC 930                                                     January 1985
Telnet Terminal Type Option

RFC930 1985年1月のtelnet端末タイプオプション

   IAC SB TERMINAL-TYPE IS ... IAC SE

IAC SBの端末のタイプはそうです… IAC SE

      Sender is stating the name of his 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. オプションに関する動機

   This option allows a telnet server to determine the type of terminal
   connected to a user telnet program.  The transmission of such
   information does not immediately imply any 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 such special functions as cursor
   addressing, multiple colors, etc., not included in the Network
   Virtual Terminal specification.  This option fits into the normal
   structure of TELNET options by deferring the actual transfer of
   status information to the SB command.

このオプションで、telnetサーバはユーザtelnetプログラムにつなげられた端末のタイプを決定できます。 そのような情報の伝達はすぐに、処理の少しの変化も含意しません。 しかしながら、情報はプロセスに通過されるかもしれません。(それは、それが端末の特定の特性に合うように送るデータを変更するかもしれません)。 例えば、いくつかのオペレーティングシステムで、コードを受け入れる端末のドライバーは運転される端末のタイプを示します。 TERMINAL TYPEとBINARYオプションを使用して、そのようなシステムの上のtelnetサーバプログラムは、まるでそれらが直接接続されるかのように端末を運転させるように手配するかもしれません、カーソルアドレシング、複数の色などがNetwork Virtual Terminal仕様に含んでいなかったような特別な機能を含んでいて。 状態情報の実際の転送をSBコマンドに延期することによって、このオプションはTELNETオプションの正常な構造に収まります。

5. Description of the Option

5. オプションの記述

   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...).

してください。そして、使用されますが、未来の議論のために許可を得て、与えます。 状態情報の実際の交換はオプションサブコマンド(IAC SB TERMINAL-TYPE…)の中に起こります。

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO TERMINAL-TYPE is free to request type information.  Only the
   sender of the DO may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
   and only the sender of the WILL 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

端末のタイプ情報はNVT ASCIIストリングです。 これの中で

Solomon & Wimmers                                               [Page 2]

ソロモンとWimmers[2ページ]

RFC 930                                                     January 1985
Telnet Terminal Type Option

RFC930 1985年1月のtelnet端末タイプオプション

   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.

ストリング、大文字と小文字は同等であると考えられます。 最新の「規定番号」RFCで有効な端末の型名に関する全リストを見つけることができます。

   The following is an example of use of the option:

↓これはオプションで役に立つ例です:

      Host1: IAC DO TERMINAL-TYPE

Host1: IACは端末でタイプします。

      Host2: IAC WILL TERMINAL-TYPE

Host2: IACは端末でタイプするでしょう。

         (Host1 is now free to request status information at any time.)

(Host1はいつでも、現在、自由に状態情報を要求できます。)

      Host1: IAC SB TERMINAL-TYPE SEND IAC SE

Host1: IAC SBの端末のタイプはIAC SEを送ります。

      Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE

Host2: IAC SBの端末のタイプはIBM-3278-2IAC SEです。

6.  Implementation Suggestions

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
   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.  In
   some cases, a particular terminal may be known by more than one name,
   for example a specific type and a more generic type.  In such cases,
   the sender of the TERMINAL-TYPE IS command should reply to successive
   TERMINAL-TYPE SEND commands with the various names, from most to
   least specific.  In this way, a telnet server that does not
   understand the first response can prompt for alternatives.  However,
   it should cease sending TERMINAL-TYPE SEND commands after receiving
   the same response two consecutive times.  Similarly, a sender should
   indicate it has sent all available names by repeating the last one
   sent.  Note that TERMINAL-TYPE IS must only be sent in response to a
   request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-TYPE
   IS and then received TERMINAL-TYPE SEND couldn't determine whether
   the other host was requesting a second option or the TERMINAL-TYPE
   SEND and the TERMINAL-TYPE IS crossed in midstream.

「端末のタイプ」情報は交渉の両端に重要などんなNVT ASCIIストリングであるかもしれません。 「規定番号」における端末の型名のリストが端末のタイプの代替の「スペル」によって引き起こされた混乱を最小にすることを意図します。 例えば、1回のパーティーが端末を呼ぶなら混乱が起こる、「IBM3278-2インチがゆったり過ごす、もう片方が、それを「IBM-3278/2インチ」と呼びました。 どんな理解されていない端末のタイプに、否定的な承認もありませんが、有効な端末の型名が指定されていないなら、ある別の選択肢(BINARYモードに切り替わることなどの)は拒否されるかもしれません。 いくつかの場合、特定の端末が1つ以上の名前によって知られているかもしれなくて、例えば、詳細は、より多くのジェネリックがタイプするタイプとaです。 そのような場合、TERMINAL-TYPE ISコマンドの送付者は様々な名前で連続したTERMINAL-TYPE SENDコマンドに答えるべきです、大部分から最も特有にならないまで。 この道、最初の応答が代替手段のためにうながすことができるのを理解していないtelnetサーバで。 しかしながら、それは、連続した2回同じ応答を受けた後にコマンドをTERMINAL-TYPE SENDに送るのをやめるべきです。 同様に、送付者は、1つが送った最終を繰り返すことによってすべての利用可能な名前を送ったのを示すべきです。 要求(TERMINAL-TYPE SEND)に対応してTERMINAL-TYPE ISを送るだけでよいことに注意してください、TERMINAL-TYPE ISを送って、次にTERMINAL-TYPE SENDを受け取ったホストが、もう片方のホストが、2番目のオプションかTERMINAL-TYPE SENDとTERMINAL-TYPE ISが中流の中で交差したよう要求していたかどうかと決心できなかったので。

   The type "UNKNOWN" should be used if the type of the terminal is
   unknown or unlikely to be recognized by the other party.

端末のタイプによって未知か相手によって認識されそうにないなら、タイプ「未知」は使用されるべきです。

Solomon & Wimmers                                               [Page 3]

ソロモンとWimmers[3ページ]

RFC 930                                                     January 1985
Telnet Terminal Type Option

RFC930 1985年1月のtelnet端末タイプオプション

   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のキャラクタです。

Solomon & Wimmers                                               [Page 4]

ソロモンとWimmers[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

画像アンカーのボーダーを消去できない

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る