RFC1572 日本語訳

Network Working Group                               S. Alexander, Editor
Request for Comments: 1572                      Lachman Technology, Inc.
Category: Standards Track                                   January 1994

ワーキンググループのS.アレクサンダー、コメントを求めるエディタ要求をネットワークでつないでください: 1572年のラックマン技術Inc.カテゴリ: 標準化過程1994年1月

                       Telnet Environment Option

telnet環境オプション

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document specifies a mechanism for passing environment
   information between a telnet client and server.  Use of this
   mechanism enables a telnet user to propagate configuration
   information to a remote host when connecting.

このドキュメントはtelnetクライアントとサーバの間で環境資料を通過するのにメカニズムを指定します。接続するとき、このメカニズムの使用は、telnetユーザがリモートホストに設定情報を伝播するのを可能にします。

   This document corrects some errors in [1].

このドキュメントは[1]のいくつかの誤りを修正します。

1.  Command Names and Codes

1. コマンド名とコード

      NEW-ENVIRON     39
          IS               0
          SEND             1
          INFO             2

-新しく、取り巻いてください、39は0が1つのインフォメーションに2を送るということです。

          VAR              0
          VALUE            1
          ESC              2
          USERVAR          3

VAR0価値1のESC2USERVAR3

2.  Command Meanings

2. コマンド意味

   IAC WILL NEW-ENVIRON

IACウィル、-新しく、取り巻いてください。

      The sender of this command is willing to send environment
      variables.

このコマンドの送付者は、環境変数を送っても構わないと思っています。

   IAC WONT NEW-ENVIRON

IAC習慣、-新しく、取り巻いてください。

      The sender of this command refuses to send environment variables.

このコマンドの送付者は、環境変数を送るのを拒否します。

Telnet Working Group                                            [Page 1]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[1ページ]RFC1572telnet環境オプション1994年1月

   IAC DO NEW-ENVIRON

IACがする、-新しく、取り巻いてください。

      The sender of this command is willing to receive environment
      variables.

このコマンドの送付者は、環境変数を受け取っても構わないと思っています。

   IAC DONT NEW-ENVIRON

IACドント、-新しく、取り巻いてください。

      The sender of this command refuses to accept environment
      variables.

このコマンドの送付者は、環境変数を受け入れるのを拒否します。

   IAC SB NEW-ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE

IAC SB NEW-ENVIRON SEND[タイプしてください… [タイプしてください… […]]]IAC SE

      The sender of this command requests that the remote side send its
      environment variables.  The "type" may be either VAR or USERVAR,
      to indicate either well known or user variable names.  Only the
      side that is DO NEW-ENVIRON may initiate a SEND command.  If a
      list of variables is specified, then only those variables should
      be sent.  If no list is specified, then the default environment,
      of both well known and user defined variables, should be sent.  If
      one of the variables has no name, then all the variables of that
      type (well known or user defined)  in the default environment
      should be sent.

このコマンドの送付者は、遠隔地側が環境変数を送るよう要求します。 「タイプ」は、よく知られるかユーザ変数名を示すためにはVARかUSERVARのどちらかであるかもしれません。 DO NEW-ENVIRONである唯一側はSENDコマンドを開始するかもしれません。 変数のリストを指定するなら、それらの変数だけを送るべきです。 リストを全く指定しないなら、よく知られている両方とユーザ被定義変数についてデフォルト環境を送るべきです。 変数の1つに名前が全くないなら、デフォルト環境における、そのタイプ(知られている井戸か定義されたユーザ)のすべての変数を送るべきです。

   IAC SB NEW-ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ]
   [ ... ] ] IAC SE

IAC SB NEW-ENVIRON ISはタイプします… [値] [タイプ[VALUE…][…]…]IAC SE

      The sender of this command is sending environment variables.  This
      command is sent in response to a SEND request.  Only the side that
      is WILL NEW-ENVIRON may send an IS command.  The "type"/VALUE
      pairs must be returned in the same order as the SEND request
      specified them, and there must be a response for each "type ..."
      explicitly requested.  The "type" will be VAR or USERVAR.
      Multiple environment variables may be sent.  The characters
      following a "type" up to the next "type" or VALUE specify the
      variable name.  The characters following a VALUE up to the next
      "type" specify the value of the variable.  If a "type" is not
      followed by a VALUE (e.g., by another VAR, USERVAR, or IAC SE)
      then that variable is undefined.  If a VALUE is immediately
      followed by a "type" or IAC, then the variable is defined, but has
      no value.  If an IAC is contained between the IS and the IAC SE,
      it must be sent as IAC IAC.  If a variable or a value contains a
      VAR, it must be sent as ESC VAR.  If a variable or a value
      contains a USERVAR, it must be sent as ESC USERVAR.  If a variable
      or a value contains a VALUE, it must be sent as ESC VALUE.  If a
      variable or a value contains an ESC, it must be sent as ESC ESC.

このコマンドの送付者は環境変数を送ります。 SEND要求に対応してこのコマンドを送ります。 WILL NEW-ENVIRONである唯一側が発信するかもしれない、命令してください。 SEND要求が彼らを指定して、明らかに要求された各「タイプ」のための…応答があるに違いないので、同次で「タイプ」/VALUE組を返さなければなりません。 「タイプ」は、VARかUSERVARになるでしょう。 複数の環境変数を送るかもしれません。 「タイプ」の次の「タイプ」かVALUEまで後をつけるキャラクタは変数名を指定します。 VALUEの次の「タイプ」まで後をつけるキャラクタは変数の値を指定します。 「タイプ」がVALUE(例えば、別のVAR(USERVAR)かIAC SEによる)によって続かれていないなら、その変数は未定義です。 VALUEがすぐに「タイプ」かIACによって続かれているなら、変数には、定義されますが、値が全くありません。 そして、IACが間に含まれている、IAC SEであり、IAC IACとしてそれを送らなければなりません。 変数か値がVARを含むなら、ESC VARとしてそれを送らなければなりません。 変数か値がUSERVARを含んでいるなら、ESC USERVARとしてそれを送らなければなりません。 変数か値がVALUEを含んでいるなら、ESC VALUEとしてそれを送らなければなりません。 変数か値がESCを含んでいるなら、ESC ESCとしてそれを送らなければなりません。

Telnet Working Group                                            [Page 2]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[2ページ]RFC1572telnet環境オプション1994年1月

   IAC SB NEW-ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ...
   ] [ ... ] ] IAC SE

IAC SB NEW-ENVIRON INFOはタイプします… [値] [タイプ[VALUE…][…]…]IAC SE

      The sender of this command is sending information about
      environment variables that have changed.  It is identical to the
      IS command, except that the command is INFO instead of IS.  Only
      the side that is WILL NEW-ENVIRON may send an INFO command.  The
      INFO command is not to be used to send initial information; the
      SEND/IS sequence is to be used for that.  The INFO command is to
      be used to propagate changes in environment variables, and may be
      spontaneously generated.

このコマンドの送付者は変化した環境変数の情報を送ります。 の代わりにする、それが同じである、コマンドがINFOであること以外のコマンドである、あります。 WILL NEW-ENVIRONである唯一側はINFOコマンドを送るかもしれません。 INFOコマンドは初期の情報を送るのに使用されないことです。 SEND/による系列がそれに使用されることであるということです。 INFOコマンドが環境変数における変化を伝播するのに使用されることであり、自然に生成されるかもしれません。

3.  Default Specification

3. デフォルト仕様

   The default specification for this option is

このオプションのためのデフォルト仕様はそうです。

      WONT NEW-ENVIRON
      DONT NEW-ENVIRON

習慣、-新しく、取り巻いてください、ドント、-新しく、取り巻いてください。

   meaning there will not be any exchange of environment information.

そこでの意味は環境資料のどんな交換にもならないでしょう。

4.  Motivation

4. 動機

   Many operating systems have startup information and environment
   variables that contain information that should be propagated to
   remote machines when Telnet connections are established.  Rather than
   create a new Telnet option each time someone comes up with some new
   information that they need propagated through a Telnet session, but
   that the Telnet session itself doesn't really need to know about,
   this generic information option can be used.

多くのオペレーティングシステムには、Telnet接続が確立されるときリモートマシンに伝播されるべきである情報を含む始動情報と環境変数があります。 むしろ、だれかが彼らがTelnetセッションで伝播する必要がありますが、Telnetセッション自体が本当に知る必要はない何らかの新情報を思いつくたびに新しいTelnetオプションを作成するよりこのジェネリック情報オプションを使用できます。

5.  Well Known Variables

5. よく知られている変数

   USER        This variable is used to transmit the user or account
               name that the client wishes to log into on the remote
               system.  The format of the value the USER variable is
               system dependent, as determined by the remote system.

USER This変数は、クライアントがリモートシステムの上でログインしたがっているユーザかアカウント名を伝えるのに使用されます。 形式、価値では、USER変数は依存して、リモートシステムで決定しているシステムです。

   JOB         This variable is used to transmit the job ID that the
               client wishes to use when logging into the remote system.
               The format of the value the JOB variable is system
               dependent, as determined by the remote system.

JOB This変数は、リモートシステムにログインするときクライアントが使用したがっている仕事のIDを伝えるのに使用されます。 形式、価値では、JOB変数は依存して、リモートシステムで決定しているシステムです。

   ACCT        This variable is used to transmit the account ID that the
               client wishes to use when logging into the remote system.
               The format of the value the ACCT variable is system
               dependent, as determined by the remote system.

ACCT This変数は、リモートシステムにログインするときクライアントが使用したがっているアカウントIDを伝えるのに使用されます。 形式、価値では、ACCT変数は依存して、リモートシステムで決定しているシステムです。

Telnet Working Group                                            [Page 3]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[3ページ]RFC1572telnet環境オプション1994年1月

   PRINTER     This variable is used to identify the default location
               for printer output.  Because there does not currently
               exist a standard way of naming a printer on a network,
               the format of this variable is currently undefined.

PRINTER This変数は、プリンタ出力のためにデフォルト位置を特定するのに使用されます。 ネットワークでプリンタを命名する標準の方法が現在存在しないので、この変数の形式は現在、未定義です。

   SYSTEMTYPE  This is used to transmit the type of operating system on
               the system that sends this variable.  It value is
               identical to the value of the SYSTEM (SYST) command in
               FTP [4].  The format of the value shall have as its first
               word one of the system names listed in the current
               version of the Assigned Numbers document [5].

SYSTEMTYPE Thisは、この変数を送るシステムでオペレーティングシステムのタイプを伝えるのに使用されます。 それ、値はFTP[4]における、SYSTEM(SYST)コマンドの値と同じです。 価値の形式には、最初の単語としてAssigned民数記ドキュメント[5]の最新版で記載されたシステム名の1つがあるものとします。

   DISPLAY     This variable is used to transmit the X display location
               of the client.  The format for the value of the DISPLAY
               variable is:

DISPLAY This変数は、クライアントのXディスプレイ位置を伝えるのに使用されます。 DISPLAY変数の値のための形式は以下の通りです。

                  <host>:<dispnum>[.<screennum>]

<ホスト>: <dispnum>。[. <screennum>]

               This information is identical to the information passed
               using the Telnet X-DISPLAY-LOCATION option.  If both the
               DISPLAY environment variable, and the X-DISPLAY-LOCATION
               option [6] are received, and they contain conflicting
               information, the most recently received information
               received should be used.

この情報はTelnet X-DISPLAY-LOCATIONオプションを使用することで通過された情報と同じです。 DISPLAY環境変数とX-DISPLAY-LOCATIONオプション[6]の両方が受け取られていて、闘争情報を含んでいるなら、受け取られた最も最近受信された情報は使用されるべきです。

   Because it is impossible to anticipate all variables that users may
   wish to exchange, the USERVAR type is provided to allow users to
   transmit arbitrary variable/value pairs.  The use of an additional
   type allows implementations to distinguish between values derived by
   the remote host software and values supplied by the user.  Paranoid
   implementations will most likely treat both types with an equal level
   of distrust.  The results of a name-space collision between a well-
   known and a user variable are implementation specific.

ユーザが交換したがっているかもしれないすべての変数を予期するのが不可能であるので、ユーザが任意の変数/値の組を伝えるのを許容するためにUSERVARタイプを提供します。 追加タイプの使用で、実装はリモートホストソフトウェアによって引き出された値とユーザによって供給された値を見分けることができます。 パラノイアの実装はたぶん等しいレベルの不信用がある両方のタイプを扱うでしょう。 知られている井戸とユーザ変数との名前空間衝突の結果は実装特有です。

6.  Implementation Rules

6. 実装規則

   WILL and DO are used only at the beginning of the connection to
   obtain and grant permission for future negotiations.

してください。そして、単に得る接続と交付金許可の始めに今後の交渉に使用されるでしょう。

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO NEW-ENVIRON is free to request that environment variables be sent.
   Only the sender of the DO may send requests (IAC SB NEW-ENVIRON SEND
   IAC SE) and only the sender of the WILL may transmit actual
   environment information (via the IAC SB NEW-ENVIRON IS ... IAC SE
   command).  Though this option may be used at any time throughout the
   life of the telnet connection, the exchange of environment
   information will usually happen at the startup of the connection.
   This is because many operating systems only have mechanisms for

2人のホストがいったんウィルとaがするaを交換すると、DO NEW-ENVIRONの送付者は、環境変数が送られるよう自由に要求できます。 してください。送付者だけ、ウィルの送付者だけが、要求(IAC SB NEW-ENVIRON SEND IAC SE)を送るかもしれなくて、実際の環境資料(IAC SB NEW-ENVIRON IS…IAC SEコマンドを通した)を伝えてもよいです。 このオプションはtelnet接続の寿命の間中ときのいつでも使用されるかもしれませんが、通常、環境資料の交換は接続の始動のときに起こるでしょう。 これは多くのオペレーティングシステムにはメカニズムがあるだけであるからです

Telnet Working Group                                            [Page 4]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[4ページ]RFC1572telnet環境オプション1994年1月

   propagating environment information at process creation, so the
   information is needed before the user logs in.

プロセス作成で環境資料を伝播して、したがって、ユーザがログインする前に情報が必要です。

   The receiving host is not required to put all variables that it
   receives into the environment.  For example, if the client should
   send across USERVAR "TERM" VALUE "xterm" as an environment variable,
   and the TERMINAL-TYPE [3] option has already been used to determine
   the terminal type, the server may safely ignore the TERM variable.
   Also, some startup information may be used in other ways; for
   example, the values for "USER", "ACCT" and "PROJ" values might be
   used to decide which account to log into, and might never be put into
   the users environment.  In general, if the server has already
   determined the value of an environment variable by some more accurate
   means, or if it does not understand a variable name, it may ignore
   the value sent in the NEW-ENVIRON option.  The server may also prefer
   to just put all unknown information into the users environment.  This
   is the suggested method of implementation, because it allows the user
   the most flexibility.

受信ホストはそれが受け取るすべての変数を環境に入れる必要はありません。 例えば、クライアントが環境変数としてUSERVAR「用語」価値の"xterm"の向こう側に発信するべきであり、端末のタイプ[3]オプションが端末のタイプを決定するのに既に使用されたなら、サーバは安全に可変であるという用語を無視するかもしれません。 また、何らかの始動情報が他の方法で使用されるかもしれません。 例えば、「ユーザ」、"ACCT"、および"PROJ"値のための値をどのアカウントにログインしたらよいかを決めるのに使用して、ユーザ環境に決して入れないかもしれません。 一般に、変数名を理解していないならサーバがそれ以上の正確な手段で既に環境変数の値を決定したなら、それはNEW-ENVIRONオプションで送られた値を無視するかもしれません。 また、サーバは、ただユーザ環境にすべての未知情報を入れるのを好むかもしれません。 最も多くの柔軟性をユーザに許容するので、これは実装の提案されたメソッドです。

   The following is an example of use of the option:

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

       Host1                            Host2
       IAC DO NEW-ENVIRON
                                        IAC WILL NEW-ENVIRON
       [ Host1 is now free to request environment information ]
       IAC SB NEW-ENVIRON SEND VAR
       "USER" VAR "ACCT" VAR USERVAR
       IAC SE
       [ The server has now explicitly asked for the USER and ACCT
         variables, the default set of well known environment variables,
         and the default set of user defined variables.  Note that the
         client includes the USER information twice; once because it was
         explicitly asked for, and once because it is part of the
         default environment.  ]
                                        IAC SB NEW-ENVIRON IS VAR "USER"
                                        VALUE "joe" VAR "ACCT" VALUE
                                        "kernel" VAR "USER" VALUE "joe"
                                        VAR "DISPLAY" VALUE "foo:0.0"
                                        USERVAR "SHELL" VALUE "/bin/csh"
                                        IAC SE

Host1 Host2 IACはNEW-ENVIRON IACウィルNEW-ENVIRON[Host1は現在、自由に環境資料を要求できる]IAC SB NEW-ENVIRON SEND VAR「ユーザ」VAR"ACCT"VAR USERVAR IAC SEをします。[ サーバは現在、明らかに変数、よく知られている環境変数のデフォルトセット、およびデフォルトが設定するユーザ被定義変数のUSERとACCTを求めました。 クライアントが二度USER情報を入れることに注意してください。 明らかにそれを求めた一度と、それがデフォルト環境の一部であるところで一度。 ] IAC SB、-新しく、取り巻いてください、VAR「ユーザ」値の"joe"VAR"ACCT"値の「カーネル」VAR「ユーザ」値の"joe"はVAR「ディスプレイ」値の「foo: 0インチUSERVAR「シェル」値の"/bin/csh"IAC SE」です。

   It is legal for a client to respond with an empty environment (no
   data between the IAC SB and IAC SE) when no well-defined or user
   variables are currently defined.  For example:

明確でないかユーザ変数が現在定義されるとき、クライアントが空の環境(IAC SBとIAC SEの間のデータがない)で応じるのは、法的です。 例えば:

      IAC SB NEW-ENVIRON IS IAC SE

IAC SB、-新しく、取り巻いてください、IAC SEです。

   is a valid response to any of the following:

以下のどれかに、有効回答です:

Telnet Working Group                                            [Page 5]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[5ページ]RFC1572telnet環境オプション1994年1月

      IAC SB NEW-ENVIRON SEND IAC SE
      IAC SB NEW-ENVIRON SEND VAR IAC SE
      IAC SB NEW-ENVIRON SEND USERVAR IAC SE
      IAC SB NEW-ENVIRON SEND VAR USERVAR IAC SE

IAC SB、-新しく、取り巻いてください、IAC SE IAC SBを送ってください、-新しく、取り巻いてください、VAR IAC SE IAC SBを送ってください、-新しく、取り巻いてください、USERVAR IAC SE IAC SBを送ってください、-新しく、取り巻いてください、VAR USERVAR IAC SEを送ってください。

   (The last example is equivalent to the first...)

(最後の例は1日に同等です…)

   The earlier version of this specification [1] incorrectly reversed
   the values for VAR and VALUE,  which put the specification at odds
   with existing implementations.  In order to resolve that problem, as
   well as other minor problems, a new option number has been assigned
   to the NEW-ENVIRON option.  This allows implementations of this memo
   to interoperate with no ambiguity.

この仕様[1]の以前のバージョンはVARとVALUEのために不当に値を逆にしました。(VALUEは既存の実装と仲たがいして仕様を置きます)。 その問題、および他の小さな問題を解決するために、新しいオプション番号をNEW-ENVIRONオプションに割り当ててあります。 これで、このメモの実装はあいまいさなしで共同利用します。

   For a discussion on how to implement to interoperate with the various
   implementations that pre-date this memo, see [2].

このメモより前に起こる様々な実装で共同利用する道具へのどのようにについての議論に関しては、[2]を見てくださいか。

   It is expected that any implementation that supports the Telnet NEW-
   ENVIRON option will support all of this specification.

Telnet NEW- ENVIRONがオプションであるとサポートするどんな実装もこの仕様のすべてをサポートすると予想されます。

7.  Security Concerns

7. 安全上の配慮

   It is important for an implementor of the NEW-ENVIRON option to
   understand the interaction of setting options and the
   login/authentication process. Specifically careful analysis should be
   done to determine which variables are "safe" to set prior to having
   the client login.  An example of a bad choice would be permitting a
   variable to be changed that allows an intruder to circumvent or
   compromise the login/authentication program itself.

NEW-ENVIRONオプションの作成者がオプションとログイン/認証過程を設定する相互作用を理解しているのは、重要です。 どの変数がクライアントをログインさせる前にセットするために「安全であるか」を決定するために明確に慎重な分析をするべきです。 下手な選択に関する例は出し抜く侵入者か感染を許容する変えられるべき変数にログイン/認証プログラム自体を可能にしているでしょう。

8.  References

8. 参照

   [1] Borman, D., Editor, "Telnet Environment Option", RFC 1408, Cray
       Research, Inc., January 1993.

[1] ボーマン、D.、エディタ、「telnet環境オプション」、RFC1408、クレイ・リサーチ、1993年1月。

   [2] Borman, D., "Telnet Environment Option Interoperability Issues",
       RFC 1571, Cray Research, Inc., January 1994.

[2] ボーマン、D.、「telnet環境オプション相互運用性問題」、RFC1571、クレイ・リサーチ、1994年1月。

   [3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
       Software, Inc., February 1989.

[3]VanBokkelen、J.、「telnet端末のタイプオプション」、RFC1091、FTPソフトウェアInc.、1989年2月。

   [4] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD
       9, RFC 959, USC/Information Sciences Institute, October 1985.

[4] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、科学が1985年10月に設けるUSC/情報。

   [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

[5] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。

Telnet Working Group                                            [Page 6]

RFC 1572               Telnet Environment Option            January 1994

telnetワーキンググループ[6ページ]RFC1572telnet環境オプション1994年1月

   [6] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
       Mellon University, March 1989.

[6] マーシー、G.、「telnet Xディスプレイ位置のオプション」、RFC1096、カーネギメロン大学、1989年3月。

Acknowledgements

承認

   The original version of this document was written by Dave Borman of
   Cray Research, Inc.  In addition, the comments of the Telnet Working
   Group of the IETF are gratefully acknowledged.

このドキュメントのオリジナルバージョンはクレイ・リサーチIn追加のデーヴ・ボーマンによって書かれて、IETFのTelnet作業部会のコメントは感謝して承諾されます。

Security Considerations

セキュリティ問題

   Security issues are discussed in Section 7.

セクション7で安全保障問題について議論します。

Editor's Address

エディタのアドレス

   Steve Alexander
   Lachman Technology, Inc.
   1901 North Naper Boulevard
   Naperville, IL 60563-8895

北のNaper Boulevardナパービル、スティーブアレクサンダーラックマン技術Inc.1901IL60563-8895

   Phone: (708) 505-9555 x256
   EMail: stevea@lachman.com

以下に電話をしてください。 (708) 505-9555x256 EMail: stevea@lachman.com

Telnet Working Group                                            [Page 7]

telnetワーキンググループ[7ページ]