RFC3051 日本語訳

Network Working Group                                           J. Heath
Request for Comments: 3051                                     J. Border
Category: Informational                           Hughes Network Systems
                                                            January 2001

コメントを求めるワーキンググループJ.ヒース要求をネットワークでつないでください: 3051年のJ.境界カテゴリ: 情報のヒューズネットワーク・システム2001年1月

         IP Payload Compression Using ITU-T V.44 Packet Method

ITU-T V.44パケット方法を使用するIP有効搭載量圧縮

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   This document describes a compression method based on the data
   compression algorithm described in International Telecommunication
   Union (ITU-T) Recommendation V.44.  Recommendation V.44 is a modem
   standard but Annex B, Clause B.1, of the recommendation describes the
   implementation of V.44 in packet networks (e.g., V.44 Packet Method).
   This document defines the application of V.44 Packet Method to the
   Internet Protocol (IP) Payload Compression Protocol (RFC 2393).  RFC
   2393 defines a method for applying lossless compression to the
   payload portion of IP datagrams.

このドキュメントは国際電気通信連合(ITU-T)推薦V.44で説明されたデータ圧縮アルゴリズムに基づく圧縮方法を説明します。 推薦V.44はモデム規格ですが、Annex B、推薦のClause B.1はパケット網(例えば、V.44 Packet Method)における、V.44の実現について説明します。 このドキュメントはインターネットプロトコル(IP)有効搭載量Compressionプロトコル(RFC2393)とV.44 Packet Methodのアプリケーションを定義します。 RFC2393はIPデータグラムのペイロード部分に可逆圧縮を適用するための方法を定義します。

   V.44 Packet Method is based upon the LZJH data compression algorithm.
   Throughout the remainder of this document the terms V.44 Packet
   Method and LZJH are synonymous.

V.44パケットMethodはLZJHデータ圧縮アルゴリズムに基づいています。 このドキュメントの残り中では、用語のV.44 Packet MethodとLZJHは同義です。

Heath & Border               Informational                      [Page 1]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[1ページ]のRFC3051IP有効搭載量圧縮

Table of Contents

目次

    1. Introduction...................................................2
       1.1 General....................................................2
       1.2 Background of LZJH Data Compression........................2
       1.3 Intellectual Property Rights...............................3
       1.4 Specification of Requirements..............................4
    2. Compression Process............................................4
       2.1 Encoder Dictionary.........................................4
       2.2 Encoder Output.............................................4
       2.3 Padding....................................................4
    3. Decompression Process..........................................5
       3.1 Compressed Datagram........................................5
       3.2 Original Uncompressed Datagram.............................5
    4. IPComp Association (IPCA) Parameters...........................5
       4.1 Transform ID...............................................5
       4.2 Security Association Attributes............................5
       4.3 Manual configuration.......................................5
       4.4 Minimum packet size threshold..............................6
       4.5 Compressibility test.......................................6
    5. Security Considerations........................................6
    6. IANA Considerations............................................6
    7. Acknowledgements...............................................6
    8. References.....................................................6
    9. Authors' Addresses.............................................7
   10. Full Copyright Statement.......................................8

1. 序論…2 1.1一般…2 1.2 LZJHデータ圧縮のバックグラウンド…2 1.3知的所有権はまっすぐになります…3 1.4 要件の仕様…4 2. 圧縮の過程…4 2.1エンコーダ辞書…4 2.2 エンコーダ出力…4 2.3 そっと歩きます…4 3. 減圧の過程…5 3.1 データグラムを圧縮します…5 3.2オリジナルはデータグラムを解凍しました…5 4. IPComp協会(IPCA)パラメタ…5 4.1 IDを変えてください…5 4.2 セキュリティ協会属性…5 4.3の手動の構成…5 4.4の最小のパケットサイズ敷居…6 4.5 圧縮性テスト…6 5. セキュリティ問題…6 6. IANA問題…6 7. 承認…6 8. 参照…6 9. 作者のアドレス…7 10. 完全な著作権宣言文…8

1. Introduction

1. 序論

1.1 General

1.1 一般

   This document specifies the application of LZJH data compression, a
   lossless data compression algorithm, to IP datagram payloads.  LZJH
   data compression is to be used in conjunction with the IP Payload
   Compression Protocol (IPComp) [RFC2393].  This document is written
   with the assumption that the reader has an understanding of the
   IPComp protocol.

このドキュメントはLZJHデータ圧縮、歪みを許さない圧縮アルゴリズムの適用をIPデータグラムペイロードまで指定します。 LZJHデータ圧縮はIP有効搭載量Compressionプロトコル(IPComp)[RFC2393]に関連して使用されることです。 このドキュメントは読者にはIPCompプロトコルの理解があるという仮定で書かれています。

1.2 Background of LZJH Data Compression

1.2 LZJHデータ圧縮のバックグラウンド

   LZJH is similar to the algorithm described in [LZ78] although it also
   has aspects which are similar to the algorithm described in [LZ77].
   As such, it provides the execution speed and low memory requirements
   of [LZ78] with compression ratios that are better than [LZ77].
   Originally developed for the satellite industry to compress IP
   datagrams independently, it is ideal for the IPComp application.  The
   LZJH algorithm was modified to compress a continuous stream of data
   for a modem environment and this modified version is the basis for

LZJHはまた、それには[LZ77]で説明されたアルゴリズムと同様の局面がありますが、[LZ78]で説明されたアルゴリズムと同様です。 そういうものとして、それは[LZ78]の実行速度と少ないメモリ要件を[LZ77]より良い圧縮比に提供します。 衛星産業が独自にIPデータグラムを圧縮するように元々開発されていて、IPCompアプリケーションに、それは理想的です。 LZJHアルゴリズムはモデム環境のためのデータの連続したストリームを圧縮するように変更されました、そして、この変更されたバージョンは基礎です。

Heath & Border               Informational                      [Page 2]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[2ページ]のRFC3051IP有効搭載量圧縮

   Recommendation V.44.  LZJH is an adaptive, general purpose, lossless
   data compression algorithm.  It was selected by the ITU-T as the
   basis for Recommendation V.44 based on its performance across a wide
   variety of data types, particularly web HTML's, and based on its
   compression ratio characteristics, per MIP and memory utilized (as
   compared to other candidate algorithms).  Its encoder is extremely
   efficient and can encode a two character string with 3 bits the
   second time that string is encountered in the data.

推薦V.44。 LZJHは適応型の、そして、汎用の歪みを許さない圧縮アルゴリズムです。 それは、さまざまなデータ型、特にHTMLのウェブところの向こう側に性能に基づくRecommendation V.44の基礎としてITU-Tによって選択されて、1MIPあたりの圧縮比の特性とメモリに基づいて利用されました(他の候補アルゴリズムと比べて)。 エンコーダは、非常に効率的であり、ストリングがデータで遭遇する2回目に3ビットで2文字列をコード化できます。

   A typical [LZ78] compression algorithm, such as V.42bis, is not
   suitable for an IPComp application since it takes too long to build
   up its dictionary, resulting in poor compression ratios on IP
   datagrams that are compressed independently.  It also requires too
   many cycles to reset an [LZ78] dictionary between datagrams which
   adversely affects execution times.

辞書を確立するためにまた、時間がかかるので、V.42bisなどの典型的な[LZ78]圧縮アルゴリズムはIPCompアプリケーションに適していません、独自に圧縮されるIPデータグラムで圧縮不良比をもたらして。 また、データグラムの間の実行時間に悪影響を与える[LZ78]辞書をリセットするのがあまりに何サイクルも必要とします。

   Similarly, a typical [LZ77] compression algorithm suffers in the
   IPComp application due to poor execution times.  Hash tables, that
   help improve execution times when compressing continuous data, may
   cause deterioration of execution times in an IPComp application since
   they must be reset to an initial state between each datagram.

同様に、典型的な[LZ77]圧縮アルゴリズムに貧しい実行時間によるIPCompアプリケーションで苦しみます。 連続したデータを圧縮するとき、ハッシュ表、その助けは実行時間を改良して、各データグラムの間の初期状態にそれらをリセットしなければならないので、IPCompアプリケーションの、実行時間の劣化を引き起こすかもしれません。

   LZJH not only has superior execution times when encoding or decoding
   packet data, but the reset of the dictionary between IP datagrams is
   trivial.  The encoder requires only the initialization of a 256 word
   array and a handful of variables while the decoder requires only the
   initialization of a handful of variables.

パケットデータをコード化するか、または解読するとき、LZJHは優れた実行時間を過すだけではありませんが、IPデータグラムの間の辞書のリセットは些細です。 デコーダは一握りの変数の初期化だけを必要としますが、エンコーダは256単語アレイと一握りの変数の初期化だけを必要とします。

   The LZJH algorithm uses a dictionary of 1525 entries, a total of only
   16K of dictionary memory, for the IPComp application.  During the
   encode process unmatched characters are encoded as ordinals and
   matched redundant strings of characters are encoded as codewords or
   string-extension lengths that represent the redundant strings.
   During the decode process the ordinals, codewords, and string-
   extension lengths are interpreted to re-create exactly the original
   datagram payload.

LZJHアルゴリズムは1525のエントリーの辞書を使用します、16Kの辞書メモリだけの合計、IPCompアプリケーションのために。 コード化の過程の間、キャラクタの序数と取り組んでいる余分なストリングが符号語か余分なストリングを表すストリング拡大の長さとしてコード化されるとき、優れたキャラクタはコード化されます。 解読の過程の間、序数、符号語、およびストリング拡大の長さは、ちょうど元のデータグラムペイロードを作り直すために解釈されます。

   The details of LZJH data compression can be found in [V44].

[V44]でLZJHデータ圧縮の詳細を見つけることができます。

1.3 Intellectual Property Rights

1.3 知的所有権

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specifications contained in this
   document.  For more information, consult the online list of claimed
   rights.

IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しくは、要求された権利のオンラインリストに相談してください。

Heath & Border               Informational                      [Page 3]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[3ページ]のRFC3051IP有効搭載量圧縮

1.4 Specification of Requirements

1.4 要件の仕様

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2. Compression Process

2. 圧縮の過程

   The compression of datagrams is performed by a function called the
   Encoder.

データグラムの圧縮はEncoderと呼ばれる機能によって実行されます。

2.1 Encoder Dictionary

2.1 エンコーダ辞書

   The transmitting entity MUST reset the encoder dictionary prior to
   processing each datagram's payload, as specified in clause 7.5.1 of
   [V44].  This ensures that each datagram's payload can be correctly
   decompressed independently of any other, as is required in an
   environment where datagrams may be lost or received out of order.

各データグラムのペイロードを処理する前に伝える実体はエンコーダ辞書をリセットしなければなりません、節で指定されるように7.5、.1、[V44]について。 これは、いかなる他のもの如何にかかわらず正しく各データグラムのペイロードを減圧できるのを確実にします、データグラムがなくされているか、または故障していた状態で受け取られるかもしれない環境で必要であるように。

   The transmitting entity MUST flush unprocessed encoder data after the
   last byte of the datagram has been passed into the encoder such that
   the compressed datagram can be transmitted as a unit.  The flush
   ensures that all data is processed and included in the output, i.e.,
   the compressed datagram is complete and no data from the current
   datagram will be processed with the next datagram.

データグラムの最後のバイトが圧縮されたデータグラムを一体にして送ることができるようにエンコーダに通過された後に伝える実体は未加工のエンコーダデータを洗い流さなければなりません。 水洗は、すべてのデータが出力に処理されて、含まれていて、すなわち、圧縮されたデータグラムが完全であり、現在のデータグラムからのデータが全く次のデータグラムで処理されないのを確実にします。

2.2 Encoder Output

2.2 エンコーダ出力

   The input to the payload compression algorithm is an IP datagram
   payload.  The output of the algorithm is a new (and hopefully
   smaller) payload.  The output payload contains the input payload's
   data in either compressed or uncompressed format.  The input and
   output payloads are each an integral number of bytes in length.

ペイロード圧縮アルゴリズムへの入力はIPデータグラムペイロードです。 アルゴリズムの出力は新しくて(願わくはより小さい)のペイロードです。 出力ペイロードは圧縮されたか解凍された形式に入力ペイロードのデータを含んでいます。 入出力ペイロードは全体が付番する長さにおけるバイトのそれぞれです。

   If the uncompressed form is used, the output payload is identical to
   the input payload and the IPComp header is omitted.  If the
   compressed form is used, the output payload is prepended with the
   IPComp header and encoded as defined in clause 6.3 of [V44].

解凍されたフォームが使用されているなら、出力ペイロードは入力ペイロードと同じです、そして、IPCompヘッダーは省略されます。 圧縮形が使用されているなら、出力ペイロードは、[V44]の6.3番目の節で定義されるようにIPCompヘッダーと共にprependedされて、コード化されます。

2.3 Padding

2.3 詰め物

   A datagram payload compressed using LZJH always ends with a FLUSH
   codeword in the last one or two compressed data bytes.  The FLUSH
   codeword may start in the 2nd to the last compressed data byte and
   end in the last compressed data byte or be totally within the last
   data byte.  The FLUSH codeword is used to signal the end of the

LZJHを使用することで圧縮されたデータグラムペイロードはいつもFLUSH符号語で最後の1か2圧縮されたデータ・バイトに終わります。 FLUSH符号語は、2番目で最後に圧縮されたデータ・バイトへの最後に圧縮されたデータ・バイトと終わりに始まるか、または最後のデータ・バイトの完全に中にあるかもしれません。 FLUSH符号語は、終わりに合図するのに使用されます。

Heath & Border               Informational                      [Page 4]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[4ページ]のRFC3051IP有効搭載量圧縮

   compressed data and differentiate compressed data from padding.  Any
   bits or bytes beyond the FLUSH codeword within the compressed payload
   are to be considered padding.

データを圧縮して、詰め物と圧縮されたデータを区別します。 圧縮されたペイロードの中のFLUSH符号語を超えたどんなビットやバイトも詰め物であると考えられることです。

   The size of a compressed payload MUST be in whole octet units.

圧縮されたペイロードのサイズは全部、そうであるに違いありません。八重奏ユニット。

3. Decompression Process

3. 減圧の過程

   The decompression of datagrams is performed by a function called the
   Decoder.

データグラムの減圧はDecoderと呼ばれる機能によって実行されます。

3.1 Compressed Datagram

3.1 圧縮されたデータグラム

   If the received datagram is compressed, the receiver MUST reset the
   decoder dictionary prior to processing the datagram.  This ensures
   that each datagram can be decoded independently of any other datagram
   in the event datagrams are lost or received out of order.  Beginning
   with the decoder dictionary in the initial state, as specified in
   clause 7.5.2 of [V44], the receiver decodes the payload data field of
   the datagram according to the procedure specified in clause 6.4 of
   [V44].

容認されたデータグラムが圧縮されるなら、データグラムを処理する前に、受信機はデコーダ辞書をリセットしなければなりません。 これは、各データグラムをなくされたイベントデータグラムのいかなる他のデータグラムの如何にかかわらず解読するか、または故障していた状態で受け取ることができるのを確実にします。 デコーダ辞書が初期状態にある状態で節で指定されるように始まる、7.5、.2、[V44]では、[V44]の6.4番目の節で指定された手順に従って、受信機はデータグラムのペイロードデータ・フィールドを解読します。

3.2 Original Uncompressed Datagram

3.2 オリジナルの解凍されたデータグラム

   If the received datagram is not compressed, the receiver does not
   perform compression decoding and passes the payload data field of the
   datagram unaltered to the next protocol layer.

容認されたデータグラムが圧縮されないなら、受信機は、圧縮解読を実行しないで、次のプロトコル層に非変更されたデータグラムのペイロードデータ・フィールドを通り過ぎます。

4. IPComp Association (IPCA) Parameters

4. IPComp協会(IPCA)パラメタ

   IKE [RFC2409] MAY be used to negotiate the use of the LZJH
   compression algorithm to establish an IPCA, as defined in [RFC2393].

IKE[RFC2409]はIPCAを証明するためにLZJH圧縮アルゴリズムの使用を交渉するのに使用されるかもしれません、[RFC2393]で定義されるように。

4.1 Transform ID

4.1 Transform ID

   The value of the LZJH Transform ID is IPCOMP_LZJH.  This value is
   used to negotiate the use of the LZJH data compression algorithm
   using IKE.

LZJH Transform IDの値はIPCOMP_LZJHです。 この値は、IKEを使用することでLZJHデータ圧縮アルゴリズムの使用を交渉するのに使用されます。

4.2 Security Association Attributes

4.2 セキュリティ協会属性

   There are no other parameters required for the negotiation of the
   LZJH compression algorithm using IKE.

LZJH圧縮アルゴリズムの交渉にIKEを使用することで必要である他のパラメタが全くありません。

4.3 Manual configuration

4.3 手動の構成

   The CPI value IPCOMP_LZJH is used for manually configured IPComp
   Compression Associations.

CPI価値のIPCOMP_LZJHは手動で構成されたIPComp Compression Associationsに使用されます。

Heath & Border               Informational                      [Page 5]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[5ページ]のRFC3051IP有効搭載量圧縮

4.4 Minimum packet size threshold

4.4 最小のパケットサイズ敷居

   As stated in [RFC2393], small packets may not compress well.
   Informal tests using the LZJH algorithm on internet web pages and e-
   mail files show that the average payload size that typically produces
   expanded data is approximately 50 bytes.  Thus, implementations may
   prefer not to attempt to compress payloads of approximately 50 bytes
   or smaller.

[RFC2393]に述べられているように、小型小包は井戸を圧縮しないかもしれません。 インターネットウェブページでLZJHアルゴリズムを使用する非公式のテストと電子メールファイルは、拡張データを通常作り出す平均したペイロードサイズがおよそ50バイトであることを示します。 したがって、実現は、およそ50バイト以下のペイロードを圧縮するのを試みないのを好むかもしれません。

4.5 Compressibility test

4.5 圧縮性テスト

   The LZJH algorithm, as described in [V44], is easily modified to
   incorporate an adaptive compressibility test, as referenced in
   [RFC2393].  Annex B of [V44] specifies the mechanism for including
   such a test in LZJH.

[V44]で説明されるLZJHアルゴリズムは、適応型の圧縮性テストを取り入れるように[RFC2393]で参照をつけられるように容易に変更されます。 [V44]の別館BはLZJHでのそのようなテストを含んでいるのにメカニズムを指定します。

5. Security Considerations

5. セキュリティ問題

   This document does not add any further security considerations to
   those discussed in [RFC2393].

このドキュメントは[RFC2393]で議論したものにどんなさらなるセキュリティ問題も加えません。

6. IANA Considerations

6. IANA問題

   This document does not introduce any new name spaces.  The value of
   IPCOMP_LZJH is assigned from the IPsec IPCOMP transform identifier
   space defined in [RFC2407].  IANA has assigned a value of 4 for this
   purpose.

このドキュメントは少しの新しい名前空間も導入しません。 IPCOMP_LZJHの値は[RFC2407]で定義されたIPsec IPCOMP変換識別子スペースから割り当てられます。 IANAはこのために4の値を割り当てました。

7. Acknowledgements

7. 承認

   This document is modeled upon [RFC2395].

このドキュメントは[RFC2395]に倣われます。

8. References

8. 参照

   [LZ77]    Lempel, A., and Ziv, J., "A Universal Algorithm for
             Sequential Data Compression", IEEE Transactions On
             Information Theory, Vol. IT-23, No. 3, May 1977.

情報理論における[LZ77]Lempel、A.とZiv、J.、「連続したデータ圧縮のための普遍的なアルゴリズム」IEEE取引、Vol.IT-23(No.3)は1977がそうするかもしれません。

   [LZ78]    Lempel, A., and Ziv, J., "Compression of Individual
             Sequences via Variable Rate Coding", IEEE Transactions On
             Information Theory, Vol. IT-24, No. 5, Sep 1978.

[LZ78]Lempel、A.とZiv、J.、「Variable Rate Codingを通したIndividual Sequencesの圧縮」IEEE Transactions On情報Theory、Vol.IT-24、No.5(1978年9月)。

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2393] Shacham, A., "IP Payload Compression Protocol (IPComp)",
             RFC 2393, December 1998.

A.、「IP有効搭載量圧縮プロトコル(IPComp)」、RFC2393 1998年12月の[RFC2393]Shacham。

Heath & Border               Informational                      [Page 6]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[6ページ]のRFC3051IP有効搭載量圧縮

   [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
             LZS", RFC 2395, December 1998.

[RFC2395] 友人とR.とR.Monsour、「LZSを使用するIP有効搭載量圧縮」、RFC2395、1998年12月。

   [RFC2407] Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November, 1998.

[RFC2407] パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。

   [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC
             2409, November 1998.

[RFC2409] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ」、RFC2409、1998年11月。

   [V44]     ITU Telecommunication Standardization Sector (ITU-T)
             Recommendation V.44 "Data Compression Procedures", November
             2000.

2000年11月の[V44]ITU電気通信標準化セクター(ITU-T)推薦V.44「データ圧縮手順。」

9. Authors' Addresses

9. 作者のアドレス

   Jeff Heath
   Hughes Network Systems
   10450 Pacific Center Ct.
   San Diego, CA  92121

ジェフヒースヒューズネットワーク・システム太平洋の10450センターct。 サンディエゴ、カリフォルニア 92121

   Phone: 858-452-4826
   Fax:   858-597-8979
   EMail: jheath@hns.com

以下に電話をしてください。 858-452-4826 Fax: 858-597-8979 メールしてください: jheath@hns.com

   John Border
   Hughes Network Systems
   11717 Exploration Lane
   Germantown, MD  20876

Laneジャーマンタウン、ジョン境界ヒューズネットワーク・システム11717Exploration MD 20876

   Phone: 301-601-4099
   Fax:   301-601-4275
   EMail: border@hns.com

以下に電話をしてください。 301-601-4099 Fax: 301-601-4275 メールしてください: border@hns.com

Heath & Border               Informational                      [Page 7]

RFC 3051        IP Payload Compression Using ITU-T V.44     January 2001

V.44 2001年1月にITU-Tを使用するヒースと境界の情報[7ページ]のRFC3051IP有効搭載量圧縮

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Heath & Border               Informational                      [Page 8]

ヒースと境界情報です。[8ページ]