RFC468 日本語訳

Network Working Group                                         R.  Braden
Request for Comment: 468                                        UCLA/CCN
NIC: 14742                                                 March 8, 1973

コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 468UCLA/CCN NIC: 14742 1973年3月8日

                          FTP DATA COMPRESSION

FTPデータ圧縮

I.  INTRODUCTION

I. 序論

APOLOGIA

正当化

   Major design objectives of the proposed File Transfer Protocol (FTP)
   are reliability and efficiency for transmission of large files.
   Efficiency has two faces: efficiency of the host CPU's, and efficient
   use of the Network bandwidth.  Block mode is intended to minimize CPU
   overhead for bandwidth efficiency, there is a mode called "HASP" in
   RFC 454.  The "HASP" mode of FTP is really transmission with data
   compression, i.e., an encoding scheme to reduce the information
   redundancy in the messages.

提案されたFile Transferプロトコル(FTP)の主要な設計目標は、大きいファイルの伝達のための信頼性と効率です。 効率には、2つの顔があります: CPUのホストものの効率、およびNetwork帯域幅の効率的な使用。 ブロックモードが帯域幅効率のためにCPUオーバーヘッドを最小にすることを意図して、「掛け金」と呼ばれるモードがRFC454にあります。 FTPの「掛け金」モードは本当にデータ圧縮(すなわち、メッセージの情報の冗長を減らすコード化体系)があるトランスミッションです。

   RFC 454 contains no explicit definition of the "HASP" or compressed
   mode, but instead notes that a future RFC by yours truly will define
   the mode.  Students of FTP may find this scarcely credible, but you
   are now reading the promised RFC.  It turned out to be much farther
   in the future than any of us expected.  Mea Culpa.

RFC454は、「掛け金」か圧縮されたモードのどんな明白な定義も含んでいませんが、代わりに本当に、あなたのものによる将来のRFCがモードを定義することに注意します。 FTPの学生は、これがほとんど確かでないことがわかるかもしれませんが、あなたは現在、約束のRFCを読んでいます。 それは、私たちのどれかより未来にはるかに遠くに予想されるために判明しました。 自己の過失の肯定。

GENERAL CONSIDERATIONS

一般的な問題

   In the early years of the Network, its major uses have been remote
   terminal interactions and the small-to-medium-sized file transmission
   typical of remote job entry.  As facilities such as the Illiac IV and
   the Data Machine become operational on the Network, and the Network
   community begins to include users with heavy data transmission
   requirements, large file transmission will become a major mode of
   Network use.  For example, one user of CCN expects to send 2 x 10**8
   bits of data _each_ _day_ over the Network.

Networkの下積み時代に、主要な用途は、遠隔端末相互作用とリモートジョブエントリの典型の中型に小さいファイルトランスミッションです。 Illiac IVやData Machineなどの施設がNetworkで操作上になって、Network共同体が重いデータ伝送要件でユーザを含み始めるのに従って、大きいファイルトランスミッションはNetwork使用の長音階になるでしょう。 例えば、CCNの1人のユーザが、2x10をNetworkの上にデータ_の_ _毎日_あたり**8ビット送ると予想します。

   Local byte compression of the type proposed here is particular
   effective for reducing the size of "printer" files such as those
   transmitted under the Network RJE protocol.  Experience with CCN's
   RJS service has shown a typical compression of print files by a
   factor of between two and three.  Since FTP was intended to contain
   the data transfer part of Network RJE protocol as a subset, it is
   appropriate to include a print file compression mechanism in FTP.
   These considerations led the FTP committee to include a compressed
   mode within FTP.

ここで提案されたタイプの地方のバイト要約はNetwork RJEプロトコルの下で伝えられたものなどの「プリンタ」ファイルのサイズを減少させるのに有効な状態で特定です。 CCNのRJSサービスの経験は2〜3の要素による印刷ファイルの典型的な要約を示しました。 FTPが部分集合としてNetwork RJEプロトコルのデータ転送部分を含むことを意図したので、FTPに印刷ファイル圧縮機構を含んでいるのは適切です。 これらの問題は、FTP委員会がFTPの中で圧縮されたモードを入れるように導きました。

Braden                                                          [Page 1]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[1ページ]RFC468FTPデータ圧縮行進

   The two main arguments for data compression are economics and
   convenience (usability).  Consider first economics, which is
   essentially a trade-off between CPU time and transmission costs.  Of
   course, as long as Network use is a free commodity, the economics of
   data compression are all bad.  That happy state won't last forever.
   What does data compression cost?

データ圧縮のための2つの主な議論が、経済学と便利(ユーザビリティ)です。 最初の経済学を考えてください。(それは、本質的にはCPU時間とトランスミッションコストの間のトレードオフです)。 もちろん、Network使用が無料の商品である限り、データ圧縮の経済学はすべて悪いです。 その満足な状態はいつまでも続かないでしょう。データ圧縮は何を要しますか?

   Let us consider only simple linear compression schemes, such as the
   one proposed here.  By linear, I mean that the CPU time to examine a
   source record is proportional to number of bytes in the record.  A
   simple linear scheme could detect repeated single characters, for
   example.  One could imagine quadratic schemes, which detected
   repeated substrings; but except for possible special circumstance
   where the source stings have some structure known to the compression
   algorithm, the CPU economics don't favor quadratic compression.

ここで提案されたものなどの簡単な直線的な圧縮技術だけを考えましょう。 直線的で、私は、ソース記録を調べるCPU時間が記録のバイト数に比例していると言っています。 簡単な直線的な体系は例えば繰り返された単独のキャラクタを検出するかもしれません。 人は二次の体系を想像できました。(検出されて、体系はサブストリングを繰り返しました)。 しかし、ソース刺し傷で圧縮アルゴリズム、CPU経済学に何らかの構造を知っている可能な特別な状況以外に、二次の圧縮を支持しないでください。

   Assuming a reasonable figure for large-scale CPU costs in the
   generation of CCN's 360/91, we concluded that an upper bound on CPU
   costs for total compression and decompression would be 5 cents per
   megabit; this is based on very loose coding of a simple linear
   algorithm.  This may be compared with the projected Network
   transmission costs of over 30 cents per megabit (possibly a lot
   over).

大規模なCPUコストでCCNの360/91人の世代で妥当な数字を仮定して、私たちは、総圧縮と減圧のためのCPUコストに関する上限が1メガビットあたり5セントであると結論を下しました。 これは簡単な直線的なアルゴリズムの非常にゆるいコード化に基づいています。 これはメガビット(ことによると多くの)あたり30セント以上の予測されたNetworkトランスミッションコストと比較されるかもしれません。

   Thus, the CPU time to conserve bandwidth costs significantly less
   than the bandwidth saved.  Both CPU costs and bandwidth costs are
   trending downward, but it seems exceedingly unlikely that the ratio
   of CPU cost to bandwidth cost for linear compression will reverse in
   the next few years.  On the other hand, this calculation clearly
   discourages one from using quadratic compression.

したがって、帯域幅よりかなり帯域幅コストを保存しないCPU時間は節約されました。 CPUコストと帯域幅コストの両方が下向きに傾いていますが、CPU費用対直線的な圧縮のための帯域幅費用の比率がこの数年間で逆になるのはきわめてありそうもなく見えます。 他方では、この計算は、1つが二次の圧縮を使用するのを明確に思いとどまります。

WHY HASP

なぜ掛け金で締めますか?

   CCN's batch remote job entry protocol NETRJS (see RFC #189, July 15,
   1971) was designed to include two data transfer modes, truncated and
   compressed.  The NETRJS truncated mode is essentially identical to
   current FTP block mode record structure (except for minor bit format
   differences).  The compressed mode of NETRJS uses an adaptation of
   the particular compression scheme which is incorporated in the
   "Multileaving protocol" of the binary synchronous rje support in
   IBM's HASP system.

CCNのバッチリモートジョブエントリプロトコルNETRJS(1971年7月15日にRFC#189を見る)は2つのデータ転送モードを含むように設計されて、先端を切られて、圧縮されました。 NETRJSの端が欠けているモードは本質的にはモードの現在のFTPブロック記録構造(小さい方の噛み付いている形式差を除いた)と同じです。 NETRJSの圧縮されたモードはIBMのHASPシステムで2進の同期rjeサポートの「マルチリービングプロトコル」に法人組織であることの特定の圧縮技術の適合を使用します。

   Although it isn't really necessary for the purpose of defining a
   compression scheme in FTP, I have included an appendix summarizing
   very briefly the nature of HASP and its rje package.  That appendix
   may be considered cultural enrichment for those in the Network
   Community who have been denied the privilege of being an IBM
   customer.  After all, I know a lot of HASP experts who never heard of

それは本当にFTPで圧縮技術を定義する目的に必要ではありませんが、私は非常に簡潔にHASPの自然とそのrjeパッケージをまとめる付録を入れました。 その付録はNetwork CommunityのIBMの顧客である特権が否定されたそれらのための文化的な裕福であると考えられるかもしれません。 結局、Iは決して聞かなかった多くのHASP専門家を知っています。

Braden                                                          [Page 2]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[2ページ]RFC468FTPデータ圧縮行進

   TENEX! More seriously, because HASP is widely used on IBM machines,
   the HASP compression scheme is also widely used.  In designing
   NETRJS, we chose the HASP scheme of compression because of its
   ubiquity and plausibility.

TENEX! より真剣に、また、HASPがIBMマシンの上で広く使用されるので、HASP圧縮技術は広く使用されます。 NETRJSを設計する際に、私たちはその偏在ともっともらしさのために圧縮のHASP体系を選びました。

   However, certain details of the HASP bit formats are inappropriate or
   sub-optimal for FTP.  Therefore, our proposal for compressed mode of
   FTP is only an adaptation of the HASP compression scheme.

しかしながら、FTPに、HASPビット形式のある詳細は、不適当であるか、またはサブ最適です。 したがって、FTPの圧縮されたモードのための私たちの提案はHASP圧縮技術の適合にすぎません。

   It should be clear from Appendix A that the compression scheme of
   HASP, even if used literally, is a very minor and incidental part of
   that system.  Although we ought to properly credit the intellectual
   origin of FTP's compressed mode, it seems a little strange to call
   the compressed mode in FTP the "HASP mode".  I trust this will be
   rectified by the forthcoming FTP meeting.

文字通り使用されてもHASPの圧縮技術がそのシステムの非常に小さい方の、そして、付帯的な部分であることはAppendix Aから明確であるはずです。 私たちは適切にFTPの圧縮されたモードの知的な発生源を掛けるべきですが、FTPにおける圧縮されたモードを「HASPモード」と呼ぶように少し奇妙に思えます。 私は、これが今度のFTPミーティングで正されると信じます。

II.  PROPOSED FTP COMPRESSED DATA MODE

II。 提案されたFTP圧縮されたデータモード

   Byte size is B bits.  Figures above boxes are field lengths in bits.

バイトサイズはBビットです。 箱の上の数字はビットのフィールド長です。

                                  n bytes of data
                               /--------/\--------\
              1    B-1        /   B              B \
             +---+------+    +--------+     +--------+
Byte String: | 0 |  n   |    |   d    |. . .|   d    |
             |   |      |    |    1   |     |    n   |
             +---+------+    +--------+     +--------+
                  String of n data bytes d(1),...,d(n)
                  Count n must be positive

nバイトのデータ/--------/\--------1円のB-1/B B\+---+------+ +--------+ +--------+ バイトストリング: | 0 | n| | d|. . . | d| | | | | 1 | | n| +---+------+ +--------+ +--------+ nデータ・バイトのd(1)のストリング…d(n)カウントnは積極的であるに違いありません。

                     2     B-2            B
                   +----+------+    +---------+
Replicated Byte:   | 1 0|   n  |    |    d    |
                   +----+------+    +---------+
                 String consisting of n replications of the data byte d

2 B-2B+----+------+ +---------+ 模写されたバイト: | 1 0| n| | d| +----+------+ +---------+ データ・バイトdのn模写のストリングの成ること

                     2    B-2
                  +----+------+
Filler String:    | 1 1|   n  |
                  +----+------+
                 String of n filler bytes.  The filler byte is a "space"
                 character for ASCII or EBCDIC type, or a binary zero
                 byte for Image or Local Byte Type.

2 B-2+----+------+ フィラーストリング: | 1 1| n| +----+------+ nフィラーバイトのストリング。 フィラーバイトは、ASCIIのための「スペース」キャラクタかEBCDICタイプであるかバイナリーはImageかLocal Byte Typeのためのバイトではありません。

                                B            B
                          +----------+ +----------+
Control Escape Sequence:  | 0......0 | |      C   |    (see below)
                          +----------+ +----------+

B B+----------+ +----------+ コントロールエスケープシーケンス: | 0......0 | | C| (以下を見ます) +----------+ +----------+

Braden                                                          [Page 3]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[3ページ]RFC468FTPデータ圧縮行進

   The control byte "C" which is the second byte of a control escape
   sequence is to have the same coding as the descriptor byte in Block
   Mode.  This includes end-of-file and end-of-record indications.  I
   will not specify this further because there is some question at
   present about the exact coding of the Block Mode descriptor byte.

コントロールエスケープシーケンスの2番目のバイトであるコントロールバイト「C」はブロックモードによる記述子バイトと同じコード化を持つことです。 これはファイルの終りと記録の終わりの指摘を含んでいます。 さらに現在のところ、Block Mode記述子バイトの正確なコード化に関して何らかの質問があるので、私はこれを指定するつもりではありません。

   Following the example of APL*, we have let the meaning of the filler
   (blank or 0) be determined by the type: character (ASCII|EBCDIC) vs.
   binary (Image|Local Byte).  If byte size is equal to the word size of
   the transmitting host, the compressed mode allows one to send sparse
   notices with reasonable efficiency.

APL*に関する例に倣っていて、私たちはタイプにフィラー(空白か0)の意味を決定させました: キャラクタ(ASCII| EBCDIC)対バイナリー(イメージ| 地方のByte) バイトサイズが伝わっているホストの語長と等しいなら、圧縮されたモードで、1つは妥当な効率と共にまばらな通知を送ることができます。

   * Compare 1 (take) 0 1\`A' with 1 (take) 0 1\2

* 1(取る)0 1円の'A'を2 1(取る)0 1円と比較してください。

Braden                                                          [Page 4]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[4ページ]RFC468FTPデータ圧縮行進

APPENDIX A: HASP MULTILEAVING

付録A: 掛け金のマルチリービング

   HASP (Houston Automatic Spooling Program) is a subsystem which
   essentially runs within OS/360 as a job but takes over the batch
   processing management functions from the operating system.  That is,
   HASP handles spooling of card input and printer and punch output,
   queueing and scheduling of job execution, and the operator control
   interface.  It is a tightly-written and efficient system for running
   a large and varied job load through a large-scale machine.  The name
   results from the historical fact that HASP was originally by a local
   IBM group for one particular customer, NASA Houston.

HASP(ヒューストンAutomatic Spooling Program)は仕事としてOS/360の中を本質的には動きますが、オペレーティングシステムから一括演算処理管理機能を引き継ぐサブシステムです。 すなわち、HASPはカード入力、プリンタ、およびパンチ出力のスプール、仕事の実行の待ち行列とスケジューリング、および操作員制御インタフェースを扱います。 それは大規模なマシンを通して大きくて様々な仕事の荷を動かすしっかり書かれて効率的なシステムです。 史実からのHASPが元々地方のIBMであったという名前結果は1人のうるさい顧客、NASAヒューストンに分類されます。

   HASP has always been an anomaly in the IBM scheme of things.  The
   system was written around 1965 by two programmers; the HASP group has
   probably averaged three programmers during most of its life.  The
   leader of the group has been "Mr. HASP", Tom Simpson.  The HASP
   system spread rapidly through (more or less) underground channels to
   many of the medium and large scale 360's.  At least once, only
   intense customer pressure prevented IBM from killing the HASP effort.
   HASP generated an astonishing emotional mystique among its users.
   The HASP sessions at SHARE Meetings were reminiscent of revival
   meetings.  For years every SHARE Meeting has included HASP song
   sessions around the piano during the nightly open bar.  HASP forms a
   fascinating chapter in the history of IBM's large machine business.

いつもHASPはもののIBM体系で異常です。 システムはおよそ1965×2人のプログラマに書かれました。 HASPグループはたぶん寿命の大部分3人のプログラマを平均しています。 グループのリーダーは「HASPさん」、トム・シンプソンです。 (多少)地下を通って急速に広げられたHASPシステムは媒体と大規模の多くに360を向けます。 激しい顧客圧だけが、IBMがHASP取り組みを殺すのを防ぎました。 HASPはユーザの中で驚異的な感情的な神秘性を生成しました。 SHARE MeetingsのHASPセッションは伝道集会のなごりでした。 長年、あらゆるSHARE Meetingが連夜の開いているバーの間、ピアノの周りにHASP歌のセッションを含んでいました。 HASPはIBMの大きいマシンビジネスの歴史で魅惑的な章を形成します。

   The core concepts in HASP are pseudo-devices, and the general
   technique of intercepting supervisor calls to augment operating
   system functions without changing the operating system itself.  A
   generation of OS/360 system programmers learned these techniques from
   HASP.  (These important techniques are hardly ever described in the
   literature, and "practical" programmers don't read the literature
   anyway).

HASPのコア概念は、疑似デバイスと、オペレーティングシステム自体を変えないでオペレーティングシステム機能を増大させるためにスーパーバイザコールを妨害する一般的なテクニックです。 OS/360人のシステム・プログラマの1世代はHASPからこれらのテクニックを学びました。 (これらの重要なテクニックは文学でほとんど決して説明されません、そして、「実用的な」プログラマはとにかく文学を読みません。)

   When HASP starts up (in supervisor state), it overlays an instruction
   in the I/O Supervisor with a branch to its own code.  A user program
   is written as if it were doing real I/O to card readers and printers.
   HASP intercepts and interprets these I/O operations to handle job I/O
   in a manner transparent to OS/360.  It similarly intercepts and
   interprets operator console I/O.

HASPが始動すると(スーパバイザ状態で)、それはブランチと共に入出力Supervisorにおける指示をそれ自身のコードにかぶせます。 まるでカードリーダとプリンタに本当の入出力をしているかのようにユーザ・プログラムは書かれています。 HASPは、OS/360に見え透いた方法で仕事の入出力を扱うためにこれらの入出力操作を妨害して、解釈します。 それは、同様にオペレータコンソール入出力を妨害して、解釈します。

   HASP includes batch remote job entry using binary synchronous
   communication.  The HASP communication protocol and message formats
   use a scheme developed by Simpson's group called "Multileaving
   Protocol".  The HASP rje system, by far the best rje package IBM has
   produced, finally replaced two competitive IBM packages and has
   effectively become the IBM standard for rje.  CCN's RJS system not
   only adopted the Multileaving Protocol but essentially copied its
   binary synchronous communication line handler directly form HASP.

HASPは、2進データ同期通信を使用することでバッチリモートジョブエントリを含んでいます。 HASP通信プロトコルとメッセージ・フォーマットは「マルチリービングプロトコル」と呼ばれるシンプソンのグループによって開発された体系を使用します。 HASP rjeシステム、断然最も良いrjeパッケージIBMは、生産して、最終的に2個の競争力があるIBMパッケージを置き換えて、事実上、rjeのIBM規格になりました。 CCNのRJSシステムはMultileavingプロトコルを採用しただけではありませんが、本質的にはコピーされて、2進データ同期通信系列操作者は直接HASPを形成します。

Braden                                                          [Page 5]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[5ページ]RFC468FTPデータ圧縮行進

   The Multileaving Protocol is described in the HASP manual(1) as the
   "fully synchronized, pseudo-simultaneous, bidirectional transmission
   of a variable number of data streams between two or more computers
   using binary synchronous communications facilities".  It allows a
   remote batch terminal to operate a variable number of card readers
   and printers simultaneously at different speeds over one
   communication line.  It is not surprising that HASP Multileaving
   contains in miniature many of the features of IMP-IMP Protocol and a
   little host-host protocol.  Specifically, Multileaving includes the
   following general features:

MultileavingプロトコルはHASPマニュアル(1)で「2進データ同期通信施設を使用する2台以上のコンピュータの間の可変数のデータ・ストリームの完全に連動して、疑似同時の、そして、双方向のトランスミッション」と説明されます。 それで、リモートバッチ端末は同時に、1つの通信回線の上で異なった速度で可変数のカードリーダとプリンタを操作できます。 HASP MultileavingがミニチュアにIMP-IMPプロトコルの特徴と小さいホスト兼ホストプロトコルの多くを含むのは、驚くべきものではありません。 明確に、Multileavingは以下の一般的な特徴を含んでいます:

      (1) "Conversational" transmission line protocol using transparency
          (DLE STX, etc.).

(1) 透明(DLE STXなど)を使用する「会話」の伝送路プロトコル。

      (2) "Strong" error control and retransmission using a 16-bit CRC
          and a modulo-16 block sequence number.

(2) 「強い」誤り制御と16ビットのCRCと法-16ブロック法番号を使用する「再-トランスミッション」。

      (3) Flow control for multiple streams in both directions.  This
          includes the interchanging of matching control records
          ("RFC's") to open a stream, and a set of flow control bits in
          each block.  Each flow control bit is logically equivalent to
          an ALLOcate command for one "message" (buffer) for a
          particular stream.

(3) 倍数のためのフロー制御は両方の方向に流れます。 これは、各ブロックでストリーム、および1セットのフロー制御ビットを開けるために合っているコントロール記録(「RFCのもの」)の交換を含んでいます。 それぞれのフロー制御ビットは特定のストリームへの1「メッセージ」(バッファ)のためのALLOcateコマンドに論理的に同等です。

      (4) Optional Special Control Information for remote devices.  This
          includes printer carriage control, switching card reader
          hoppers, etc.

(4) 遠隔装置のための任意のSpecial Control情報。 カードリーダホッパーなどを切り換えて、これはプリンタ改行制御を含んでいます。

      (5) Multiplexing ("multileaving") multiple streams into a single
          block for transmission.

(5) マルチプレクシング(「マルチリービング」)倍数はトランスミッションのための単滑車に流れます。

      (6) Marking end of file and ends of records within each stream.

(6) それぞれ中の記録のファイルの終りをマークして、終わりは流れます。

      (7) Compressing transmitted text by encoding repeated blanks and
          repeated single characters.

(7) 圧縮は、繰り返された空白をコード化することによってテキストを伝えて、単独のキャラクタを繰り返しました。

Braden                                                          [Page 6]

RFC 468                   FTP Data Compression                March 1973

1973年のブレーデン[6ページ]RFC468FTPデータ圧縮行進

   Finally, we have reached the (only) aspect of HASP relevant to FTP:
   its compression scheme.  HASP uses the following encoding:

最終的に、私たちはFTPに関連しているHASPの(唯一)の局面に着きました: その圧縮技術。 HASPは以下のコード化を使用します:

                       8
                  +---------+
   End of Record: | 0 ... 0 |
                  +---------+
                    2     6             8              8
                  +---+---------+   +-------+     +--------+
   Data String:   |1 1|     N   |   |    d  | ... |   d    |
                  |   |         |   |     1 |     |    N   |
                  +---+---------+   +-------+     +--------+
                         3      5
                       +---+--------+
   N Duplicate Blanks  |100|     N  |
                       +---+--------+
                               3       5           8
                             +---+---------+  +---------+
   N Replicated Characters D |101|    N    |  |    D    |
                             +---+---------+  +---------+

8 +---------+記録の終わり: | 0 ... 0 | +---------+ 2 6 8 8 +---+---------+ +-------+ +--------+ データ列: |1 1| N| | d| ... | d| | | | | 1 | | N| +---+---------+ +-------+ +--------+ 3 5 +---+--------+ N写し空白|100| N| +---+--------+ 3 5 8 +---+---------+ +---------+ N模写されたキャラクターD|101| N| | D| +---+---------+ +---------+

   HASP is concerned only with 8-bit bytes.  However, there is a
   provision (which was never implemented) in the Multileaving Protocol
   to set the unit of the counts N as 1 byte, 2 bytes, or 4 bytes.

HASPは8ビットのバイトだけに関係があります。 しかしながら、カウントNのユニットを設定するために、Multileavingプロトコルへの支給(決して実装されなかった)が1同じくらいバイト、2同じくらいバイト、または4同じくらいバイトあります。

   Reference:

参照:

   (1) HASP II System Manual, IBM Corporation (February 26, 1971)

(1) II組織便覧、IBM社を掛け金で締めてください。(1971年2月26日)

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Via Genie         4/00]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via Genie4/00によるオンラインRFCアーカイブへの]

Braden                                                          [Page 7]

ブレーデン[7ページ]