RFC1041 日本語訳

1041 Telnet 3270 regime option. Y. Rekhter. January 1988. (Format: TXT=11608 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         J. Rekhter
Request For Comments:  1041             T.J. Watson Research Center, IBM
                                                            January 1988

Rekhterがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1041 T.J.ワトソン研究所、IBM1988年1月

                       Telnet 3270 Regime Option

telnet3270政権オプション

STATUS OF THIS MEMO

このメモの状態

   This RFC specifies a proposed standard for the Internet community.
   Hosts on the Internet, that want to support 3270 data stream within
   the Telnet protocol, are expected to adopt and implement this
   standard.  Distribution of this memo is unlimited.

このRFCはインターネットコミュニティの提案された標準を指定します。 インターネットのホストであり、それは、Telnetプロトコルの中で3270年のデータ・ストリームをサポートしたくて、この規格を採用して、実装すると予想されます。 このメモの分配は無制限です。

1.  Command Name and Code

1. コマンド名とコード

   3270-REGIME     29

3270政権の29

2.  Command Meaning

2. コマンド意味

   IAC WILL 3270-REGIME

IAC、3270意志の政権

      Sender is willing to send list of supported 3270 Regimes in
      a subsequent sub-negotiation.

送付者は、その後のサブ交渉で3270サポートしているRegimesのリストを送っても構わないと思っています。

   IAC WON'T 3270-REGIME

IACがそうしない、3270政権

      Sender refuses to send the list of supported 3270 Regimes.

送付者は、3270サポートしているRegimesのリストを送るのを拒否します。

   IAC DO 3270-REGIME

IACは3270政権をします。

      Sender is willing to receive a list of supported 3270 Regimes in a
      subsequent sub-negotiation.

送付者は、その後のサブ交渉で3270サポートしているRegimesのリストを受け取っても構わないと思っています。

   IAC DON'T 3270-REGIME

IACは3270政権でしません。

      Sender refuses to accept the list of supported 3270 Regimes.

送付者は、3270サポートしているRegimesのリストを受け入れるのを拒否します。

   IAC SB 3270-REGIME ARE REGIME-LIST IAC SE

IAC SB、3270政権であることが、政権リストIAC SEです。

      Sender sends the list of all possible 3270 Regimes it is able to
      support.  The code for ARE is 1.

送付者はそれがサポートすることができる可能なすべての3270Regimesのリストを送ります。 コード、1です。

      REGIME-LIST is an ASCII string which has meaning to both sides of
      the negotiation.  This string may be composed of different
      terminal type names (as specified in the "Assigned Numbers") which
      are separated by space character.  Terminal type names which have

REGIME-LISTは交渉の両側に意味を持っているASCIIストリングです。 このストリングは間隔文字によって切り離される異なった端末の型名(「規定番号」で指定されるように)で構成されるかもしれません。 端末のそうした型名

Rekhter                                                         [Page 1]

RFC 1041               Telnet 3270 Regime Option            January 1988

Rekhter[1ページ]RFC1041telnet3270政権オプション1988年1月

      imbedded spaces should escape it with backslash character ('\').
      Backslash character imbedded into terminal type name should be
      escaped with another backslash character.

埋め込まれた空間はバックスラッシュキャラクタ('\')と共にそれから逃げるべきです。 端末の型名に埋め込まれたバックスラッシュキャラクタ別のバックスラッシュキャラクタと共に逃げられるべきです。

      Empty REGIME-LIST means, that sender is able to support only NVT
      ASCII terminal as defined in [4].

REGIME-LIST手段を空にしてください、そして、その送付者は、[4]で定義されるように唯一のNVTがASCII端末であるとサポートすることができます。

   IAC SB 3270-REGIME IS REGIME IAC SE

IAC SB、3270政権が政権IAC SEです。

      Sender is stating the name of the terminal it is willing to
      support.  The code for IS is 0.

送付者はそれが支えても構わないと思っている端末の名前を述べています。 コード、0です。

      REGIME is an ASCII string (possibly empty) which is substring of
      the received REGIME-LIST string.  Empty string means that the
      sender is willing to support only NVT ASCII terminal as defined in
      [4].

REGIMEは容認されたREGIME-LISTストリングに関するサブストリングであるASCIIストリング(ことによると空の)です。 空のストリングは、送付者が、[4]で定義されるように唯一のNVTがASCII端末であるとサポートしても構わないと思っていることを意味します。

3.  Default

3. デフォルト

   WON'T 3270-REGIME

3270政権であるだろう

      3270 Regime will not be established.

3270政権は確立されないでしょう。

   DON'T 3270-REGIME

3270政権で、しないでください。

      3270 Regime will not be established.

3270政権は確立されないでしょう。

4.  Motivation for the option

4. オプションに関する動機

   This option allows a telnet server running VM or MVS to negotiate
   with the telnet client on the type of data stream (3270 or NVT ASCII)
   which both sides are willing support.

このオプションで、VMかMVSを実行するtelnetサーバはそれの両側が望んでいるサポートであるデータ・ストリーム(3270かNVT ASCII)のタイプの上のtelnetクライアントと交渉されます。

   The main reason for this option is to allow simple and efficient way
   to:

このオプションの主な理由は以下への簡単で効率的な道を許容することです。

      o state, that both client and server want to exchange 3270 data
        stream,

o クライアントとサーバの両方が3270のデータを交換したがっているのが流れると述べてください。

      o switch from 3270 Regime into NVT ASCII Regime and back into 3270
        Regime,

o 3270Regimeから切り替わって、NVT ASCII Regimeに3270Regimeに戻ります。

      o dynamically renegotiate 3270 Regime parameters (like terminal
        type).

o ダイナミックに、3270のRegimeパラメタ(端末のタイプのような)を再交渉してください。

Rekhter                                                         [Page 2]

RFC 1041               Telnet 3270 Regime Option            January 1988

Rekhter[2ページ]RFC1041telnet3270政権オプション1988年1月

   Support for 3270 data stream requires that both sides:

3270年のデータ・ストリームのサポートはその両側を必要とします:

      o be able to exchange binary data,

o バイナリ・データを交換できてください。

      o be able to put well defined delimiters into inbound/outbound
        data stream,

o アウトバウンドデータが流す本国行きの/によく定義されたデリミタは入れることができてください。

      o be able to establish the agreement between client and server on
        what type of terminal will be used.

o クライアントとサーバとのどんなタイプの端末が使用されるかに関する協定を確立できてください。

   Current implementations requires 3 different options, TERMINALTYPE
   [1], BINARY [2] and EOR [3], to be successfully negotiated between
   client and server prior to establishing 3270 Regime.  Moreover, it is
   unclear at what point in this negotiation process, 3270 regime is
   actually established (whether after TERMINALTYPE or after BINARY or
   after EOR).  Also, order for these negotiations was never specified.

現在の実装は、3270Regimeを設立する前にクライアントとサーバの間で首尾よく交渉されるために3つの異なったオプション、TERMINALTYPE[1]、BINARY[2]、およびEOR[3]を必要とします。 そのうえ、この交渉プロセスに、3270政権が実際にどんなポイントで確立されるかは(TERMINALTYPEかBINARYかEORにかかわらず後)、不明瞭です。 また、これらの交渉の注文を決して指定しませんでした。

   Subnegotiation for the TERMINALTYPE is possible with only single
   terminal type at a time.

TERMINALTYPEのためのSubnegotiationは一度に、単独の端末のタイプだけで可能です。

   Once 3270 Regime is established, there is no standard of how to get
   out of this regime back into NVT ASCII mode.

3270Regimeがいったん設立されると、どうこの政権をNVT ASCIIモードに出て戻すかに関する規格が全くありません。

   Based on the 3270 Regime requirements, which stated above, we feel
   that separate negotiation for EOR and BINARY should not be done.
   Rather, 3270 Regime establishment should imply that:

3270のRegime要件に基づいて、EORとBINARYのために交渉するべきではありません。要件は、上では、私たちがそんなに別々であると感じると述べました。 むしろ、3270年のRegime設立は、以下のことを含意するべきです。

      o each character in the Telnet data stream should be interpreted
        as 8 bits of binary data,

o Telnetデータ・ストリームにおける各キャラクタはバイナリ・データの8ビットとして解釈されるべきです。

      o both sides agreed to use a certain character sequence(Telnet IAC
        EOR) as a delimiter in inbound/outbound Telnet data stream,

o 両側は、デリミタとして本国行きの、または、外国行きのTelnetデータ・ストリームで、あるキャラクタシーケンス(telnet IAC EOR)を使用するのに同意しました。

      o both sides agreed on the type of the terminal they are willing
        to support.

o 両側は彼らが支えても構わないと思っている端末のタイプに同意しました。

   By providing the list of possible terminals which Telnet client can
   support, telnet server could select the type of the terminal it can
   support and pass it back to the Telnet client, thus eliminating
   multiple TERMINALTYPE negotiations.

Telnetクライアントが支えることができる可能な端末のリストを提供することによって、telnetサーバは、それが支えることができる端末のタイプを選んで、Telnetクライアントにそれを戻すかもしれません、その結果、複数のTERMINALTYPE交渉を排除します。

   As stated in [5], "The purpose of the Telnet Protocol is to provide a
   fairly general, bi-directional, eight-bit byte oriented communication
   facility."  Therefore we feel that such issues as color support,
   graphics support, extended data streams mapping, etc., do not belong
   logically to the Telnet protocol, but rather should be considered as
   a part of a separate protocol which defines 3270 inbound/outbound
   data stream (see [5], [6], [7], [8]).  The purpose of this memo is

[5]に述べられているように「テルネット・プロトコルの目的はかなり一般的で、双方向の、そして、8ビットのバイト指向の通信機器を提供することです」。 したがって、私たちは、色のサポート、グラフィックスサポート、拡張データ・ストリームマッピングなどがするような問題がTelnetプロトコルに論理的に属さないと感じますが、3270年の本国行きの/アウトバウンドデータストリームを定義する別々のプロトコルの一部であるとむしろみなされるべきです。([5]を見てください、[6]、[7]、[8])。 このメモの目的はそうです。

Rekhter                                                         [Page 3]

RFC 1041               Telnet 3270 Regime Option            January 1988

Rekhter[3ページ]RFC1041telnet3270政権オプション1988年1月

   not to describe (or define) protocols which are used in 3270 Regime,
   but rather define a new option for the Telnet Protocol, which would
   allow both sides to negotiate for the 3270 Regime establishment over
   the telnet connection.

説明しない、(定義、)、使用されたプロトコルはテルネット・プロトコルのために3270Regime、しかし、むしろ新しいオプションを定義します。(両側はそれでtelnet接続の上の3270年のRegime設立を交渉できるでしょう)。

   While this options does not include direct negotiation for such
   things as colors, graphics, structured fields, etc., certain features
   (like the ability to support colors) may be negotiated indirectly by
   using certain terminal type names specified in 3270-REGIME
   subnegotiation.

これである間、色(グラフィックス)が分野などを構造化したので、オプションはそのようなもののための直談を含んでいません、特徴(色をサポートする能力のような)が間接的に3270-REGIME subnegotiationで指定されたある端末の型名を使用することによって交渉されるかもしれないのを確信しています。

   We also feel that such issues as keyboard mapping, whether to have
   one telnet for both ASCII and 3270 mode or two separate programs, one
   for ASCII and another for 3270 mode, are implementation dependent and
   should be considered as a local matter.

私たちは、また、キー割当一覧のような問題(ASCIIと3270年のモードか2つの別々のプログラムの両方のための1つのtelnetを持っているか、そして、ASCIIのためのものと3270年のモードのための別のもの)が実装に依存していると感じて、地域にかかわる事柄であるとみなされるべきです。

5.  Description of the Option

5. オプションの記述

   WILL and DO commands are used to obtain and grant permission for the
   subsequent subnegotiation.  Both sides must exchange WILL 3270-REGIME
   and DO 3270-REGIME prior to subnegotiation.  The actual exchange of
   information is done within the option subcommand (IAC SB
   3270-REGIME).

ウィルとするコマンドは、その後の副交渉のために許可を得て、与えるのに使用されます。 両側は、ウィル3270-REGIMEを交換して、副交渉の前で3270-REGIMEをしなければなりません。 オプションサブコマンド(IAC SB 3270-REGIME)の中で実際の情報交換をします。

   Either Telnet client or Telnet server can initialize 3270-REGIME
   negotiation.  However, in order to simplify negotiation, only Telnet
   client is allowed to send IAC SB 3270-REGIME ARE... IAC SE command,
   and only Telnet server is allowed to reply with IAC SB 3270-REGIME
   IS... IAC SE command.

TelnetクライアントかTelnetサーバのどちらかが3270-REGIME交渉を初期化できます。 しかしながら、交渉を簡素化するために、TelnetクライアントだけがIAC SB 3270-REGIME AREを送ることができます… IAC SEは命令します、そして、TelnetサーバだけがIAC SB 3270-REGIME ISと共に返答できます… IAC SEは命令します。

   Since this negotiation is asymmetric, each time Telnet client/server
   decide to negotiate/renegotiate this option they have to perform
   complete negotiation process (DO...  WILL... SB 3270-REGIME...).

この交渉が非対称であるので、それぞれの時間Telnetクライアント/サーバは、彼らが完全な交渉プロセスを実行するために持っているこのオプションを交渉するか、または再交渉すると決めます(…ウィル…SB 3270-REGIMEを…してください)。

   The following is an example of use of the option:

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

      1.  Host A: IAC DO 3270-REGIME

1. ホストA: IACは3270政権をします。

      2.  Host B: IAC WILL 3270-REGIME

2. ホストB: IAC、3270意志の政権

      3.  Host B: IAC DO 3270-REGIME

3. ホストB: IACは3270政権をします。

      4.  Host A: IAC WILL 3270-REGIME

4. ホストA: IAC、3270意志の政権

      5.  (At this point side which runs Telnet client can start
          subnegotiation.)

5. (ここに、Telnetクライアントを車で送る側は副交渉を始動できます。)

Rekhter                                                         [Page 4]

RFC 1041               Telnet 3270 Regime Option            January 1988

Rekhter[4ページ]RFC1041telnet3270政権オプション1988年1月

      6.  Host A: IAC SB 3270-REGIME ARE 'ibm3279-3 ibm3279-2 ibm3278-3'
          IAC SE

6. ホストA: IAC SB 3270-REGIME ARE'ibm3279-3 ibm3279-2 ibm3278-3'IAC SE

      7.  Host B: IAC SB 3270-REGIME IS 'ibm3279-2' IAC SE

7. ホストB: IAC SB、3270政権が'ibm3279-2'IAC SEです。

6.  Implementation Suggestions

6. 実装提案

   If the side is able to support more that one terminal type, then
   terminal type names are listed in REGIME-LIST from most desirable to
   least desirable.  Other side upon receive of the REGIME-LIST scans it
   from left to right and finds the first terminal type which it is able
   to support returns it in REGIME part of the 3270-REGIME IS
   subnegotiation.

側が、それが1つの端末のタイプであるとさらにサポートすることができるなら、端末の型名はREGIME-LISTに大部分から最も望ましくなく望ましい状態で記載されます。 REGIME-LISTは、左から右までそれをスキャンして、それがサポートすることができる最初の端末タイプがREGIMEでそれを返すのがわかります。反対側が受信する、3270-REGIMEの一部は副交渉です。

   The side which wants to switch into NVT ASCII mode should send empty
   REGIME-LIST.  Since empty string is a subset of empty string, the
   side which receives empty REGIME-LIST should reply with empty REGIME.
   At that point both sides are switched to NVT ASCII mode.

NVT ASCIIモードへのスイッチへの必需品が送るはずである側はREGIME-LISTを空にします。空のストリングが空のストリングの部分集合であるので、空のREGIME-LISTを受ける側は空のREGIMEと共に返答するはずです。 その時、両側はNVT ASCIIモードに切り換えられます。

   It is possible to renegotiate 3270 Regime parameters (like terminal
   type).  Certain precaution should be taken to insure that such
   renegotiation would not cause switch into NVT ASCII mode.  As a
   possible measure, the side which wants to renegotiate for another
   terminal should include both the current and the new terminal type
   names into REGIME-LIST.  This way, if the other side is unable to
   change 3270 Regime terminal type, it will continue to use current
   terminal type.

3270のRegimeパラメタ(端末のタイプのような)を再交渉するのは可能です。 ある注意は、そのような再交渉がNVT ASCIIモードにスイッチを引き起こさないのを保障するために払われるべきです。 可能な測定、別の端末に再交渉するどの必需品がそうするべきである側として、電流と新しい端末の型名の両方をREGIME-LISTに含めてください。この道、反対側が3270年のRegimeの端末のタイプを変えることができないと、それは現在の端末のタイプを使用し続けるでしょう。

   Since IAC character (255 decimal) is used as a delimiter (together
   with EOR) in inbound/outbound data stream, care must be taken to
   escape IAC characters which are part of data stream itself with
   another IAC character.

IACキャラクタ(255小数)がデリミタ(EORに伴う)としてアウトバウンドデータが流す本国行きの/で使用されるので、別のIACキャラクタを伴うデータ・ストリーム自体の一部であるIACキャラクタから逃げるために注意しなければなりません。

   To prevent ambiguity in interpreting inbound/outbound data stream
   during negotiation process the following rules should be observed:

アウトバウンドデータが交渉プロセスの間に流す本国行きの/を解釈する際にあいまいさを防ぐために、以下の規則は守られるべきです:

      1.  Telnet client should not accept any data from the user as soon
          as it enters 3270 Regime negotiation.

1. 3270年のRegime交渉に入るとすぐに、telnetクライアントはユーザから少しのデータも受け入れるべきではありません。

      2.  Telnet client should not send any data to the Telnet server
          after it sends "3270-REGIME ARE....".

2. telnetクライアントはTelnetサーバへの発信した後に「3270政権がそうです」という少しのデータも送るべきではありません…

      3.  Telnet server should try not to send any data to the telnet
          client while negotiation is in progress.

3. 交渉が進行している間、telnetサーバは少しのデータもtelnetクライアントに送ろうとするべきではありません。

      4.  Telnet server may reply with "3270-REGIME IS..." to the telnet
          client only after all outstanding data have been already sent

4. telnetサーバは「3270政権がそうです」で返答するかもしれません… 既にすべての傑出しているデータの後のだけtelnetクライアントに送ってください、そうした。

Rekhter                                                         [Page 5]

RFC 1041               Telnet 3270 Regime Option            January 1988

Rekhter[5ページ]RFC1041telnet3270政権オプション1988年1月

          to the Telnet client.

Telnetクライアントに。

      5.  Telnet server can switch from its previous regime to the new
          regime only after it sends "IAC SB 3270-REGIME IS 'regime' IAC
          SE" to the telnet client.

5. 発信した後にだけtelnetサーバが前の政権から新政体に切り替わることができる、「IAC SB、telnetクライアントにとって3270政権が'政権'IAC SE」です。

      6.  Telnet client can switch from its previous regime to the new
          regime only after it receives "IAC SB 3270-REGIME IS 'regime'
          IAC SE".

6. 受信した後にだけtelnetクライアントが前の政権から新政体に切り替わることができる、「IAC SB、3270政権が'政権'IAC SE」です。

      7.  Switch from one regime to another may require flushing of all
          outstanding data in both telnet client and telnet server.

7. 1つの政権から別の政権までのスイッチは、telnetクライアントとtelnetサーバの両方のすべての傑出しているデータを洗い流すのを必要とするかもしれません。

7.  References

7. 参照

   [1] RFC-854, Telnet Terminal Type Option.

[1]RFC-854、telnet端末タイプオプション。

   [2] RFC-856, Telnet Binary Transmission.

[2]RFC-856、telnetバイナリー送信。

   [3] RFC-885, Telnet End Of Record Option.

[3]RFC-885、記録的なオプションのtelnet終わり。

   [4] RFC-854, Telnet Protocol Specification.

[4]RFC-854、telnetプロトコル仕様。

   [5] IBM 3270 Information Display System.  3274 Control Unit
       Description and Programmer's Guide.  GA23-0061-1.

[5] IBM3270情報ディスプレイ・システム。 3274はユニット記述とプログラマーズガイドを制御します。 GA23-0061-1。

   [6] IBM 3279 Information Display System: Color and Programmed
       Symbols.  GA33-3056-1.

[6] IBM3279情報ディスプレイ・システム: 色とプログラムされたシンボル。 GA33-3056-1。

   [7] IBM 3270 Information Display System. Data Stream Programmer's
       Reference. GA23-0059-1.

[7] IBM3270情報ディスプレイ・システム。 データはプログラマの参照を流します。 GA23-0059-1。

   [8] IBM 3270 Information Display System.  Description and
       Configuration: APL/Text Feature.  GA18-2044-0.

[8] IBM3270情報ディスプレイ・システム。 記述と構成: APL/テキスト機能。 GA18-2044-0。

Rekhter                                                         [Page 6]

Rekhter[6ページ]

一覧

 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 

スポンサーリンク

String.match

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

上に戻る