RFC735 日本語訳

0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. November 1977. (Format: TXT=10585 bytes) (Obsoletes RFC0729) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

RFC 735                                          DHC RHG  3 Nov 77 42083
Telnet Byte Macro Option

42083telnetバイトマクロがゆだねるRFC735DHC RHG1977年11月3日

Network Working Group                                   David H. Crocker
RFC: #735                                                       Rand-ISD
NIC: #42083                                      (Dcrocker at Rand-Unix)
                                                     Richard H. Gumpertz
                                              Carnegie-Mellon University
                                                   (Gumpertz at CMU-10A)

ワーキンググループデヴィッドH.医者RFCをネットワークでつないでください: #735 底ならし革-ISD NIC: #42083 (底ならし革unixにおけるDcrocker) リチャードH.Gumpertzカーネギーメロン大学(米カーネギーメロン大学-10A)のGumpertz

Obsoletes: RFC #729 (NIC #40306)                         3 November 1977

時代遅れにします: RFC#729(NIC#40306)1977年11月3日

                    Revised TELNET Byte Macro Option

改訂されたtelnetバイトマクロオプション

1. Command name and code:

1. コマンド名とコード:

   BM 19

BM19

2. Command Meanings:

2. 意味を命令してください:

   IAC WILL BM

IACウィルBM

      The sender of this command REQUESTS or AGREES to use the BM
      option, and will send single data characters which are to be
      interpreted as if replacement data strings had been sent.

この送付者は、REQUESTSかAGREESがBMオプションを使用すると命令して、まるで交換データ列を送ったかのように解釈されることになっている単独のデータキャラクタを送るでしょう。

   IAC WON'T BM

IACがそうしない、BM

      The sender of this option REFUSES to send single data characters
      which are to be interpreted as if replacement data strings had
      been sent. Any existing BM <macro byte> definitions are discarded
      (i.e., reset to their original data interpretations).

まるで交換データ列を送ったかのように解釈されることになっている単独のデータキャラクタを送るこのオプションREFUSESの送付者。 どんな既存のBM<マクロバイト>定義も捨てられます(すなわち、それらのオリジナルのデータに解釈をリセットしてください)。

   IAC DO BM

IACはBMをします。

      The sender REQUESTS or AGREES to have the other side (sender of
      WILL BM) send single data characters which are to be interpreted
      as if replacement data strings had been sent.

反対側(WILL BMの送付者)を持つ送付者REQUESTSかAGREESがまるで交換データ列を送ったかのように解釈されることになっている単独のデータキャラクタを送ります。

   IAC DON'T BM

IACがそうしない、BM

      The sender REFUSES to allow the other side to send single data
      characters which are to be interpreted as if replacement data
      strings had been sent. Any existing BM <macro byte> definitions
      are to be discarded.

反対側が発信するのを許容する送付者REFUSESはまるで交換データ列を送ったかのように解釈されることになっているデータキャラクタを選抜します。 どんな既存のBM<マクロバイト>定義も捨てられることです。

                                   1

1

RFC 735                                          DHC RHG  3 Nov 77 42083
Telnet Byte Macro Option

42083telnetバイトマクロがゆだねるRFC735DHC RHG1977年11月3日

   IAC SB BM <DEFINE> <macro byte> <count>
                                             <replacement string> IAC SE

IAC SB BM<DEFINE><マクロバイト><カウント><交換ストリング>IAC SE

      where:

どこ:

         <macro byte> is the data byte actually to be sent across the
         network; it may NOT be Telnet IAC (decimal 255, but may be any
         other 8-bit character.

<マクロバイト>は実際にネットワークの向こう側に送られるデータ・バイトです。 それはTelnet IACでないかもしれません。(いかなる他の8ビットのキャラクタであるかもしれないこと以外の10進255。

         <count> is one 8-bit byte binary number, indicating how many
         <replacement string> characters follow, up to the ending IAC
         SE, but not including it. Note that doubled IACs in the
         definition should only be counted as one character per pair.

<カウント>は1つの8ビットのバイト2進の番号です、何人の<交換ストリング>キャラクタが終わりのIAC SEまで続くかを示しますが、それを含んでいなくて。 定義における倍増しているIACsが1組あたり1つのキャラクタにしかみなされるべきでないことに注意してください。

         <replacement string> is a string of zero or more Telnet ASCII
         characters and/or commands, which the <macro byte> is to
         represent; any character may occur within a <replacement
         string>. Note, however, that an IAC in the string must be
         doubled, to be interpreted later as an IAC; to be interpreted
         later as data byte 255, it must be quadrupled in the original
         <replacement string> specification.

<交換ストリング>が一連のゼロであるか、より多くのTelnetがASCII文字、そして/または、コマンドです。(<マクロバイト>はコマンドを表すことになっています)。 どんなキャラクタも<交換ストリング>の中に起こるかもしれません。 しかしながら、後でIACとして解釈されるためにストリングのIACを倍にしなければならないことに注意してください。 後でデータ・バイト255として解釈されるために、当初の<交換ストリング>仕様でそれを4倍にしなければなりません。

      The indicated <macro byte> will be sent instead of the indicated
      <replacement string>. The receiver of the <macro byte> (the sender
      of the DO BM) is to behave EXACTLY as if the <replacement string>
      string of bytes had instead been received from the network. This
      interpretation is to occur before any other Telnet
      interpretations, unless the <macro byte> occurs as part of a
      Telnet command; in this case no special interpretation is to be
      made. In particular, an entire Telnet subnegotiation (i.e. from
      IAC SB through IAC SE) is to be considered a Telnet command in
      which NO replacement should be done.

示された<交換ストリング>の代わりに示された<マクロバイト>を送るでしょう。 <マクロバイト>(DO BMの送付者)の受信機はまるで代わりにネットワークからバイトの<交換ストリング>ストリングを受け取ったかのようにEXACTLYを反応させることになっています。 この解釈はいかなる他のTelnet解釈の前にも起こることになっています、<マクロバイト>がTelnetコマンドの一部として現れない場合。 この場合、どんな特別な解釈も作られていないことです。 特に、全体のTelnet subnegotiation(すなわち、IAC SBからIAC SEの)は交換を全くするべきでないTelnetコマンドであると考えられることになっています。

      The effect of a particular <macro byte> may be negated by reseting
      it to "expand" into itself.

>がそれ自体に「広がる」ようにそれをresetingすることによって否定されるかもしれないという特定の<マクロバイトの効果。

      IAC SB BM <DEFINE> X <0> IAC SE may be used to cause X to be
      ignored in the data stream.

IAC SB BM<DEFINE>X<0>IAC SEは、Xがデータ・ストリームで無視されることを引き起こすのに使用されるかもしれません。

      <DEFINE> is decimal 1.

<DEFINE>は10進1です。

   IAC SB BM <ACCEPT> <macro byte> IAC SE

IAC SB BM<ACCEPT><マクロバイト>IAC SE

      The receiver of the <DEFINE> for <macro byte> accepts the
      requested definition and will perform the indicated replacement
      whenever a <macro byte> is received and is not part of any IAC
      Telnet command sequence.

<マクロバイト><DEFINE>の受信機は、>が<マクロバイト、受け取られていて、どんなIAC Telnetコマンド・シーケンスの一部でないときはいつも、要求された定義を受け入れて、示された交換を実行するでしょう。

                                   2

2

RFC 735                                          DHC RHG  3 Nov 77 42083
Telnet Byte Macro Option

42083telnetバイトマクロがゆだねるRFC735DHC RHG1977年11月3日

      <ACCEPT> is decimal 2.

<ACCEPT>は10進2です。

   IAC SB BM <REFUSE> <macro byte> <REASON> IAC SE

IAC SB BM<REFUSE><マクロバイト><REASON>IAC SE

      The receiver of the <DEFINE> for <macro byte> refuses to perform
      the indicated translation from <macro byte> to <replacement
      string> because the particular <macro byte> is not an acceptable
      choice, the length of the <replacement string> exceeds available
      storage, the length of the actual <replacement string> did not
      match the length predicted in the <count>, or for some unspecified
      reason.

<マクロバイト><DEFINE>の受信機は、特定の<マクロバイト>が許容できる選択でないので示された<マクロバイト>から<交換ストリング>までの翻訳を実行するのを拒否して、<交換ストリング>の長さは有効な格納(長さが<カウント>、または何らかの不特定の理由で予測したマッチではなく、>がした実際の<交換ストリングの長さ)を超えています。

      <REFUSE> is decimal 3.

<REFUSE>は10進3です。

      <REASON> may be

<REASON>はそうです。

         <BAD-CHOICE>        which is decimal 1;

10進1である<BAD-CHOICE>。

         <TOO-LONG>          (for receiver's storage) which is decimal
                             2;

<、も-、10進2であるLONG>(受信機の格納への)。

         <WRONG-LENGTH>      (of actual string compared with promised
                             length in <count>) which is decimal 3; or

10進3である<WRONG-LENGTH>(<カウント>の約束の長さと比べた実際のストリングの)。 または

         <OTHER-REASON>      (intended for use only until this document
                             can be updated to include reasons not
                             anticipated by the authors) which is
                             decimal zero (0).

10進である<OTHER-REASON>(どんなこのドキュメントをアップデートできるまでのしか使用のためにも、作者によって予期されなかった理由を含まないつもりである)は(0)のゼロに合っています。

   IAC SB BM <LITERAL> <macro byte> IAC SE

IAC SB BM<LITERAL><マクロバイト>IAC SE

      The <macro byte> is to be treated as real data, rather than as
      representative of the <replacement string>

<マクロバイト>はむしろ<交換ストリング>の代表より本当のデータとして扱われることになっています。

      Note that this subcommand cannot be used during Telnet
      subcommands, since subcommands are defined to end with the next
      occurrence of "IAC SE". Including this BM subcommand within any
      Telnet subcommand would therefore prematurely terminate the
      containing subcommand.

Telnetサブコマンドの間このサブコマンドを使用できないことに注意してください、サブコマンドが"IAC SE"の次の発生と共に終わるために定義されるので。 したがって、どんなTelnetサブコマンドの中にもこのBMサブコマンドを含んでいると、含んでいるサブコマンドは早まって、終えられるでしょう。

      <LITERAL> is decimal 4.

<LITERAL>は10進4です。

   IAC SB BM <PLEASE CANCEL> <macro byte> <REASON> IAC SE

IAC SB BM<、キャンセル><マクロバイト><REASON>IAC SEをお願いします

      The RECEIVER of the defined <macro byte> (i.e., the sender of IAC
      DO BM) requests the sender of <macro byte> to cancel its
      definition. <REASON> is the same as for the <REFUSE> subcommand.

定義された<マクロバイト>(すなわち、IAC DO BMの送付者)のRECEIVERは、定義を中止するよう<マクロバイト>の送付者に要求します。 <REASON>は<REFUSE>サブコマンドのように同じです。

                                   3

3

RFC 735                                          DHC RHG  3 Nov 77 42083
Telnet Byte Macro Option

42083telnetバイトマクロがゆだねるRFC735DHC RHG1977年11月3日

      The <macro byte> sender should (but is not required to) respond by
      resetting <macro byte> (i.e., sending an IAC SB BM <DEFINE> <macro
      byte> <1> <macro byte> IAC SE).

<マクロバイト>送付者は、<マクロバイト>(すなわち、IAC SB BM<DEFINE><マクロバイト1>の><<マクロバイト>IAC SEを送る)をリセットすることによって、応じるべきです(しかし、必要ではありません)。

      If the receiver absolutely insists on cancelling a given macro,
      the best it can do is to turn off the entire option, with IAC DONT
      BM, wait for an acknowledging IAC WONT BM and then restart the
      option, with IAC DO BM. This will reset all other macroes as well
      but it will allow the receiver to REFUSE with code BAD CHOICE
      if/when the foreign site attempts to redefine the macro in
      question.

受信機が絶対に主張するなら、オプションは、与えられたマクロ、それがそうすることができるベストがそうする取り消しのときにIAC DONT BMと共に全体のオプションをオフにして、承認IAC WONT BMを待って、再開していることです、IAC DO BMと共に。 これはまた、他のすべてのmacroesをリセットするでしょうが、海外サイトが、問題のマクロを再定義するのを試みるとき、それは/であるならコードBAD CHOICEと共にREFUSEに受信機を許容するでしょう。

3. Default:

3. デフォルト:

   WON'T BM -- DON'T BM

BM--しないでください、BMであるだろう

      No reinterpretation of data bytes is done.

データ・バイトの「再-解釈」は全く完了していません。

4. Motivation for the option:

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

   Subcommands for Telnet options currently require a minimum of five
   characters to be sent over the network (i.e., IAC SB <Option name>
   IAC SE). For subcommands which are employed infrequently, in absolute
   numbers and in relation to normal data, this overhead is tolerable.
   In other cases, however, it is not. For example, data which is sent
   in a block- oriented fashion may need a "block separator" mark. If
   blocks are commonly as small as five or ten bytes, then most of the
   cross-net data will be control information. The BM option is intended
   as a simple data compression technique, to remove this overhead from
   the communication channel.

Telnetオプションのためのサブコマンドは、現在、最低5つのキャラクタがネットワーク(すなわち、IAC SB<Option名前>IAC SE)の上に送られるのを必要とします。 無名数と正常なデータと関連してまれに使われるサブコマンドにおいて、このオーバーヘッドは許容できます。 しかしながら、他の場合では、それはそうではありません。 例えば、ブロックの指向のファッションで送られるデータは「ブロック区切り文字」マークを必要とするかもしれません。 ブロックが5バイトか10バイトと一般的に同じくらいわずかであるなら、十字ネットのデータの大部分は制御情報になるでしょう。 簡単なデータ圧縮のテクニックとして、BMオプションが通信チャネルからこのオーバーヘッドを取り除くことを意図します。

5. Description of the option

5. オプションの記述

   The option is enabled through the standard Telnet Option negotiation
   process. Afterwards, the SENDER of data (the side which sends the IAC
   WILL BM) is free to define and use mappings between single and
   replacement NVT characters. Except for the ability to refuse
   particular definitions, the receiver of data has no control over the
   definition and use of mappings.

オプションは標準のTelnet Option交渉の過程で可能にされます。 その後、シングルと交換NVTキャラクタの間のマッピングを定義して、データ(IAC WILL BMを送る側)のSENDERは自由に使用できます。 特定の定義を拒否する能力以外に、データの受信機はマッピングの定義と使用を管理しません。

   The sender (of the WILL BM) is prohibited from using or redefining a
   <macro byte> until it has received an <ACCEPT> <REFUSE>, or DONT BM,
   in reply to a <DEFINE>.

<ACCEPT><REFUSE>、またはDONT BMを受けるまで、送付者(WILL BMの)は<マクロバイトを使用するか、または再定義するのから禁じられた>です、<DEFINE>に対して。

   NOTE: The Telnet command character IAC (decimal 255) may be a member
   of a <replacement string> but is the ONLY character which may NOT be
   defined as a <macro byte>.

以下に注意してください。 Telnetは<交換のメンバーがストリング>であったかもしれないならキャラクタIAC(10進255)を命令しますが、<マクロバイトと定義されないかもしれない唯一のキャラクタが>ですか?

                                   4

4

RFC 735                                          DHC RHG  3 Nov 77 42083
Telnet Byte Macro Option

42083telnetバイトマクロがゆだねるRFC735DHC RHG1977年11月3日

   Within any Telnet command (i.e., any sequence beginning with IAC)
   macro replacement may NOT take place. Data are to be interpreted only
   as their normal character values. This avoids the problem of
   distinguishing between a character which is to be taken as a <macro
   byte>, and interpreted as its corresponding <replacement string>, and
   one which is to be taken as its usual Telnet NVT value. In all other
   cases, however, <macro byte>s are to be interpreted immediately, as
   if their corresponding <replacement string>s had actually been sent
   across the network. Expanded strings are not subject to
   reinterpretation, so that recursive definitions cannot be made.
   Telnet commands may be included in <replacement strings>; however,
   they must be totally contained within the macro or must begin within
   the macro and terminate outside of it. In particular, they may NOT
   begin outside a macro and continue or terminate inside one, since no
   macro replacement takes place while processing any Telnet command.

中では、少しのTelnetコマンド(IACと共に始まるすなわちどんな系列も)マクロ交換も行われないかもしれません。 データは単にそれらの正常な文字値として解釈されることです。 これは>であって、対応する<交換ストリング>として解釈された<マクロバイトとしてみなされることになっているキャラクタ、および普通のTelnet NVTが評価するように取られることになっているものを見分けるという問題を避けます。 しかしながら、他のすべての場合では、<マクロバイト>sはすぐに解釈されることになっています、まるで実際にネットワークの向こう側に彼らの対応する<交換ストリング>sを送ったかのように。 拡張ストリングは、回帰的定義をすることができないように「再-解釈」をなることがありません。 含まれていて、コマンドがそうするかもしれないtelnetは<交換で>を結びます。 しかしながら、彼らは、マクロの中に完全に含まなければならないか、マクロの中で始まって、またはそれの外で終わらなければなりません。 彼らは、1で特に、マクロの外で始まって、続かないか、終わらないかもしれません、マクロ交換が全くどんなTelnetコマンドも処理している間、行われないので。

   Note that when skipping data due to Telnet SYNCH (INS/DM) processing,
   BM macro replacement should still take place, since (for example)
   "IAC DM" would be a valid <replacement string>.

(例えば、)"IAC DM"は有効な<交換でしょう、Telnet SYNCH(INS/DM)処理のためデータをスキップするとき、BMマクロ交換がまだ行われているべきであることに注意してください、そして、したがって、>を結んでください。

   The <count> in the <DEFINE> subcommand is intended to allow the
   receiver to allocate storage. IAC interpretation is not over-ridden
   during BM subcommands so that IAC SE will continue to safely
   terminate malformed subcommands.

<DEFINE>サブコマンドによる<カウント>が、受信機が格納を割り当てるのを許容することを意図します。 IAC解釈は、IAC SEが、安全に奇形のサブコマンドを終え続けるように、BMサブコマンドの間、くつがえされません。

   The BM option is notably inefficient with regard to problems during
   <macro byte> definition and use of <macro byte>s as real data. It is
   expected that relatively few <macro byte>s will be defined and that
   they will represent relatively short strings. Since the Telnet data
   space between decimal 128 and decimal 254 is not normally used,
   except by implementations employing the original (obsolete) Telnet
   protocol, it is recommended that <macro byte>s normally be drawn from
   that pool.

BMオプションは<マクロバイト>sの<マクロバイト>定義と使用の間、本当のデータとして問題に関して著しく効率が悪いです。 <マクロ比較的数バイト>sが定義されて、彼らが比較的脆いストリングを表すと予想されます。 オリジナル(時代遅れの)のtelnetプロトコルを使う実現以外に、10進128と10進254の間のTelnetデータ領域が通常使用されないので、通常、そのプールから<マクロバイト>sを得るのはお勧めです。

                                   5

5

一覧

 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 

スポンサーリンク

phpMyAdminでログイン画面を出さずにデータベースに接続する方法

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

上に戻る