RFC856 日本語訳

0856 Telnet Binary Transmission. J. Postel, J. Reynolds. May 1983. (Format: TXT=8965 bytes) (Obsoletes NIC 15389) (Also STD0027) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          J. Postel
Request for Comments: 856                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 15389                                            May 1983

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 856 J.レイノルズISIは以下を時代遅れにします。 NIC15389 1983年5月

                       TELNET BINARY TRANSMISSION

telnetバイナリー送信

This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実装すると予想されます。

1.  Command Name and Code

1. コマンド名とコード

   TRANSMIT-BINARY      0

バイナリーを伝えている0

2.  Command Meanings

2. コマンド意味

   IAC WILL TRANSMIT-BINARY

IACウィル、バイナリーを伝えます。

      The sender of this command REQUESTS permission to begin
      transmitting, or confirms that it will now begin transmitting
      characters which are to be interpreted as 8 bits of binary data by
      the receiver of the data.

この送付者は、伝わり始めるREQUESTS許可を命令するか、または現在バイナリ・データの8ビットとしてデータの受信機によって解釈されることになっているキャラクタを伝え始めると確認します。

   IAC WON'T TRANSMIT-BINARY

IACが伝えない、バイナリーを伝えます。

      If the connection is already being operated in binary transmission
      mode, the sender of this command DEMANDS to begin transmitting
      data characters which are to be interpreted as standard NVT ASCII
      characters by the receiver of the data.  If the connection is not
      already being operated in binary transmission mode, the sender of
      this command REFUSES to begin transmitting characters which are to
      be interpreted as binary characters by the receiver of the data
      (i.e., the sender of the data demands to continue transmitting
      characters in its present mode).

接続が2進の転送方式で既に手術されているなら、標準のNVT ASCII文字としてデータの受信機によって解釈されることになっているデータキャラクタを伝え始めるこのコマンドDEMANDSの送付者です。 接続が2進の転送方式で既に手術されていないなら、データ(すなわち、現在のモードでキャラクタを伝え続けているというデータ要求の送付者)の受信機で2進のキャラクタとして解釈されることになっているキャラクタを伝え始めるこのコマンドREFUSESの送付者です。

      A connection is being operated in binary transmission mode only
      when one party has requested it and the other has acknowledged it.

1回のパーティーがそれを要求して、もう片方がそれを承認したときだけ、接続は2進の転送方式で手術されています。

   IAC DO TRANSMIT-BINARY

IACはバイナリーを伝えてします。

      The sender of this command REQUESTS that the sender of the data
      start transmitting, or confirms that the sender of data is
      expected to transmit, characters which are to be interpreted as 8
      bits of binary data (i.e., by the party sending this command).

この送付者は、データの送付者が伝え始めるREQUESTSを命令するか、またはデータの送付者が伝わると予想されると確認します、バイナリ・データ(すなわち、このコマンドを送るパーティーによる)の8ビットとして解釈されることになっているキャラクタ。

   IAC DON'T TRANSMIT-BINARY

IACはバイナリーを伝えてしません。

      If the connection is already being operated in binary transmission
      mode, the sender of this command DEMANDS that the sender of the
      data start transmitting characters which are to be interpreted as

接続であるなら、2進の転送方式で既に操作されるデータの送付者が始動するこのコマンドDEMANDSの送付者は解釈されることになっているキャラクタを伝えていますか?

Postel & Reynolds                                               [Page 1]

ポステルとレイノルズ[1ページ]

RFC 856                                                         May 1983

RFC856 1983年5月

      standard NVT ASCII characters by the receiver of the data (i.e.,
      the party sending this command).  If the connection is not already
      being operated in binary transmission mode, the sender of this
      command DEMANDS that the sender of data continue transmitting
      characters which are to be interpreted in the present mode.

データ(すなわち、このコマンドを送るパーティー)の受信機による標準のNVT ASCII文字。 接続が2進の転送方式で既に手術されていないなら、現在のモードで解釈されることになっているキャラクタを伝えるデータの送付者が続けているこのコマンドDEMANDSの送付者です。

      A connection is being operated in binary transmission mode only
      when one party has requested it and the other has acknowledged it.

1回のパーティーがそれを要求して、もう片方がそれを承認したときだけ、接続は2進の転送方式で手術されています。

3.  Default

3. デフォルト

   WON'T TRANSMIT-BINARY

バイナリーを伝えるでしょう。

   DON'T TRANSMIT-BINARY

バイナリーを伝えて、しないでください。

      The connection is not operated in binary mode.

接続はバイナリ・モードで手術されません。

4.  Motivation for the Option

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

   It is sometimes useful to have available a binary transmission path
   within TELNET without having to utilize one of the more efficient,
   higher level protocols providing binary transmission (such as the
   File Transfer Protocol).  The use of the IAC prefix within the basic
   TELNET protocol provides the option of binary transmission in a
   natural way, requiring only the addition of a mechanism by which the
   parties involved can agree to INTERPRET the characters transmitted
   over a TELNET connection as binary data.

TELNETの中に2進のトランスミッション(File Transferプロトコルなどの)を提供しながら、より効率的で、より高い平らなプロトコルの1つを利用する必要はなくて利用可能な2進のトランスミッション経路を持っているのは時々役に立ちます。 基本的なTELNETプロトコルの中のIAC接頭語の使用は自然な道における、2進のトランスミッションのオプションを提供します、かかわったパーティーが、キャラクタがバイナリ・データとしてTELNET接続の上を伝わったのにINTERPRETに同意できるメカニズムの追加だけを必要として。

5.  Description of the Option

5. オプションの記述

   With the binary transmission option in effect, the receiver should
   interpret characters received from the transmitter which are not
   preceded with IAC as 8 bit binary data, with the exception of IAC
   followed by IAC which stands for the 8 bit binary data with the
   decimal value 255.  IAC followed by an effective TELNET command (plus
   any additional characters required to complete the command) is still
   the command even with the binary transmission option in effect.  IAC
   followed by a character which is not a defined TELNET command has the
   same meaning as IAC followed by NOP, although an IAC followed by an
   undefined command should not normally be sent in this mode.

2進のトランスミッションオプションが有効である場合、受信機は送信機から受け取られたキャラクタを解釈するはずです(デシマル値255で8ビットのバイナリ・データを表すIACによって続かれたIACを除いて、8がバイナリ・データに噛み付いたので、IACと共に先行されていません)。 それでも、有効なTELNETコマンド(どんな添字もコマンドを終了するのが必要である)があとに続いたIACは2進のトランスミッションオプションさえ有効のコマンドです。 定義されたTELNETコマンドでないキャラクタによって後をつけられたIACはNOPをIACと同じ意味に従わせています、未定義のコマンドがあとに続いたIACがこのモードで通常送られるはずがありませんが。

6.  Implementation Suggestions

6. 実装提案

   It is foreseen that implementations of the binary transmission option
   will choose to refuse some other options (such as the EBCDIC
   transmission option) while the binary transmission option is in

2進のトランスミッションオプションの実装が、中に2進のトランスミッションオプションがある間、ある他のオプション(EBCDICトランスミッションオプションなどの)を拒否するのを選ぶのが見通されます。

Postel & Reynolds                                               [Page 2]

ポステルとレイノルズ[2ページ]

RFC 856                                                         May 1983

RFC856 1983年5月

   effect.  However, if a pair of hosts can understand being in binary
   transmission mode simultaneous with being in, for example, echo mode,
   then it is all right if they negotiate that combination.

効果。 しかしながら、1組のホストが、例えば、エコーモードであるのに同時の2進の転送方式でいるのを理解できるなら、彼らがその組み合わせを交渉するなら、問題ありません。

   It should be mentioned that the meanings of WON'T and DON'T are
   dependent upon whether the connection is presently being operated in
   binary mode or not.  Consider a connection operating in, say, EBCDIC
   mode which involves a system which has chosen not to implement any
   knowledge of the binary command.  If this system were to receive a DO
   TRANSMIT-BINARY, it would not recognize the TRANSMIT-BINARY option
   and therefore would return a WON'T TRANSMIT-BINARY.  If the default
   for the WON'T TRANSMIT-BINARY were always NVT ASCII, the sender of
   the DO TRANSMIT-BINARY would expect the recipient to have switched to
   NVT ASCII, whereas the receiver of the DO TRANSMIT-BINARY would not
   make this interpretation.

そして、それが言及されるべきである、それ、意味、接続が現在バイナリ・モードで手術されているかどうかときの扶養家族はそうでしょう。 中と、たとえば、接続操作を考えてください、2進のコマンドに関する少しの知識も実装しないのを選んだシステムを伴うEBCDICモード。 このシステムがDO TRANSMIT-BINARYを受け取ることであるなら、それは、TRANSMIT-BINARYオプションを認識しないで、したがって、WON'T TRANSMIT-BINARYを返します。 いつもWON'T TRANSMIT-BINARYのためのデフォルトがNVT ASCIIであるなら、DO TRANSMIT-BINARYの送付者は、受取人がNVT ASCIIに切り替わったと予想するでしょうにが、DO TRANSMIT-BINARYの受信機はこの解釈をしないでしょう。

   Thus, we have the rule that when a connection is not presently
   operating in binary mode, the default (i.e., the interpretation of
   WON'T and DON'T) is to continue operating in the current mode,
   whether that is NVT ASCII, EBCDIC, or some other mode.  This rule,
   however, is not applied once a connection is operating in a binary
   mode (as agreed to by both ends); this would require each end of the
   connection to maintain a stack, containing all of the encoding-method
   transitions which had previously occurred on the connection, in order
   to properly interpret a WON'T or DON'T.  Thus, a WON'T or DON'T
   received after the connection is operating in binary mode causes the
   encoding method to revert to NVT ASCII.

そして、私たちには、その結果、現在接続であるときにバイナリ・モードで作動しないことである規則があります、デフォルト、(すなわち、解釈、)、それがNVT ASCII、EBCDIC、またはある他のモードであることにかかわらず現在のモードで作動し続けることになっているでしょう。 しかしながら、接続がバイナリ・モードでいったん働いていると(両端によって同意されるように)、この規則は適用されていません。 またはこれはスタックを維持するために接続の各端を必要とするでしょう、接続のときに以前に適切にaを解釈するために起こった変遷がそうしないコード化しているメソッドのすべてを含んでいて。 または、その結果、aがそうしない、接続がバイナリ・モード原因でNVT ASCIIに戻るコード化メソッドを操作した後に受け取って、そうしません。

   It should be remembered that a TELNET connection is a two way
   communication channel.  The binary transmission mode must be
   negotiated separately for each direction of data flow, if that is
   desired.

TELNET接続が双方向通信チャンネルであることが覚えていられるべきです。 それが望まれているなら、別々にデータフローの各方向と2進の転送方式を交渉しなければなりません。

   Implementation of the binary transmission option, as is the case with
   implementations of all other TELNET options, must follow the loop
   preventing rules given in the General Considerations section of the
   TELNET Protocol Specification.

他のすべてのTELNETオプションの実装があるケースのように、2進のトランスミッションオプションの実装は、TELNETプロトコルSpecificationの一般Considerations部で与えられた規則を防ぎながら、輪に従わなければなりません。

   Consider now some issues of binary transmission both to and from
   both a process and a terminal:

今、両方とプロセスと端末の両方から2進のトランスミッションのいくつかの問題を考えてください:

      a. Binary transmission from a terminal.

a。 端末からの2進のトランスミッション。

         The implementer of the binary transmission option should
         consider how (or whether) a terminal transmitting over a TELNET
         connection with binary transmission in effect is allowed to
         generate all eight bit characters, ignoring parity
         considerations, etc., on input from the terminal.

2進のトランスミッションオプションのimplementerは、2進の有効なトランスミッションとのTELNET関係の上の端末の伝えるのがすべての8を生成することができる(or whether)がどのようにキャラクタに噛み付いたかを考えるはずです、パリティ問題などを無視して、端末からの入力に関して。

Postel & Reynolds                                               [Page 3]

ポステルとレイノルズ[3ページ]

RFC 856                                                         May 1983

RFC856 1983年5月

      b. Binary transmission to a process.

b。 プロセスへの2進のトランスミッション。

         The implementer of the binary transmission option should
         consider how (or whether) all characters are passed to a
         process receiving over a connection with binary transmission in
         effect.  As an example of the possible problem, TOPS-20
         intercepts certain characters (e.g., ETX, the terminal
         control-C) at monitor level and does not pass them to the
         process.

2進のトランスミッションオプションのimplementerは、どのようにがすべてのキャラクタが通過される(or whether)であるかと2進の有効なトランスミッションとの関係の上で受信されるプロセスと考えるはずです。 起こりうる問題に関する例として、TOPS-20はモニターレベルで確信しているキャラクタ(例えば、ETX、端末のコントロールC)を途中で捕らえて、彼らをプロセスに通過しません。

      c. Binary transmission from a process.

c。 プロセスからの2進のトランスミッション。

         The implementer of the binary transmission option should
         consider how (or whether) a process transmitting over a
         connection with binary transmission in effect is allowed to
         send all eight bit characters with no characters intercepted by
         the monitor and changed to other characters.  An example of
         such a conversion may be found in the TOPS-20 system where
         certain non-printing characters are normally converted to a
         Circumflex (up-arrow) followed by a printing character.

2進のトランスミッションオプションのimplementerは、2進の有効なトランスミッションとの関係の上を伝わるプロセスがすべての8を送ることができる(or whether)がモニターによって途中で捕らえられて、他のキャラクタに変わるキャラクタなしでキャラクタにどのように噛み付いたかを考えるはずです。 そのような変換に関する例は通常、非表示文字が表示文字によって後をつけられたCircumflex(上がっている矢の)に変換されるのを確信しているところでTOPS-20システムで見つけられるかもしれません。

      d. Binary transmission to a terminal.

d。 端末への2進のトランスミッション。

         The implementer of the binary transmission option should
         consider how (or whether) all characters received over a
         connection with binary transmission in effect are sent to a
         local terminal.  At issue may be the addition of timing
         characters normally inserted locally, parity calculations, and
         any normal code conversion.

2進のトランスミッションオプションのimplementerは、すべてのキャラクタが2進の有効なトランスミッションとの関係の上に受け取った(or whether)がどのようにローカル・ターミナルに送られるかを考えるはずです。 問題には、通常、局所的に挿入されたタイミングキャラクタ、パリティ計算、およびどんな正常なコード変換の追加もあるかもしれません。

Postel & Reynolds                                               [Page 4]

ポステルとレイノルズ[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 

スポンサーリンク

navigator.userLanguage

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

上に戻る