RFC3943 日本語訳

Network Working Group                                          R. Friend
Request for Comments: 3943                                          Hifn
Category: Informational                                    November 2004

コメントを求めるワーキンググループR.友人要求をネットワークでつないでください: 3943年のHifnカテゴリ: 情報の2004年11月

       Transport Layer Security (TLS) Protocol Compression Using
                         Lempel-Ziv-Stac (LZS)

Lempel-Ziv-Stacを使用するトランスポート層セキュリティ(TLS)プロトコル圧縮(LZS)

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 (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   The Transport Layer Security (TLS) protocol (RFC 2246) includes
   features to negotiate selection of a lossless data compression method
   as part of the TLS Handshake Protocol and then to apply the algorithm
   associated with the selected method as part of the TLS Record
   Protocol.  TLS defines one standard compression method, which
   specifies that data exchanged via the record protocol will not be
   compressed.  This document describes an additional compression method
   associated with the Lempel-Ziv-Stac (LZS) lossless data compression
   algorithm for use with TLS.  This document also defines the
   application of the LZS algorithm to the TLS Record Protocol.

Transport Layer Security(TLS)プロトコル(RFC2246)はTLS Handshakeプロトコルの一部として歪みを許さない圧縮方法の選択を交渉して、そして、TLS Recordプロトコルの一部として選択された方法に関連しているアルゴリズムを適用する特徴を含んでいます。 TLSは1つの標準の圧縮方法を定義します。(それは、記録的なプロトコルで交換されたデータが圧縮されないと指定します)。 このドキュメントはTLSと共に使用のためのLempel-Ziv-Stac(LZS)歪みを許さない圧縮アルゴリズムに関連している追加圧縮方法を説明します。 また、このドキュメントはLZSアルゴリズムの適用をTLS Recordプロトコルと定義します。

Friend                       Informational                      [Page 1]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[1ページ]のRFC3943TLS圧縮

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  General. . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.2.  Specification of Requirements. . . . . . . . . . . . . .  3
   2.  Compression Methods. . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  LZS CompresionMethod . . . . . . . . . . . . . . . . . .  4
       2.2.  Security Issues with Single History Compression. . . . .  4
   3.  LZS Compression. . . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.  Background of LZS Compression  . . . . . . . . . . . . .  4
       3.2.  LZS Compression History and Record Processing  . . . . .  5
       3.3.  LZS Compressed Record Format . . . . . . . . . . . . . .  6
       3.4.  TLSComp Header Format  . . . . . . . . . . . . . . . . .  6
             3.4.1.  Flags. . . . . . . . . . . . . . . . . . . . . .  6
       3.5.  LZS Compression Encoding Format  . . . . . . . . . . . .  7
       3.6.  Padding  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Sending Compressed Records . . . . . . . . . . . . . . . . . .  8
       4.1.  Transmitter Process. . . . . . . . . . . . . . . . . . .  9
       4.2.  Receiver Process . . . . . . . . . . . . . . . . . . . .  9
       4.3.  Anti-expansion Mechanism . . . . . . . . . . . . . . . . 10
   5.  Internationalization Considerations .  . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       9.1.  Normative References . . . . . . . . . . . . . . . . . . 12
       9.2.  Informative References . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 一般。 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. 要件の仕様。 . . . . . . . . . . . . . 3 2. 圧縮方法。 . . . . . . . . . . . . . . . . . . . . . 3 2.1. LZS CompresionMethod. . . . . . . . . . . . . . . . . . 4 2.2。 セキュリティはただ一つの歴史で圧縮を発行します。 . . . . 4 3. LZS圧縮。 . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. LZS圧縮. . . . . . . . . . . . . 4 3.2のバックグラウンド。 LZS圧縮歴史と記録的な処理. . . . . 5 3.3。 LZSはレコード形式. . . . . . . . . . . . . . 6 3.4を圧縮しました。 TLSCompヘッダー形式. . . . . . . . . . . . . . . . . 6 3.4.1。 旗。 . . . . . . . . . . . . . . . . . . . . . 6 3.5. LZS圧縮コード化形式. . . . . . . . . . . . 7 3.6。 .8 4を水増しします。 発信は記録. . . . . . . . . . . . . . . . . . 8 4.1を圧縮しました。 送信機の過程。 . . . . . . . . . . . . . . . . . . 9 4.2. 受信機の過程. . . . . . . . . . . . . . . . . . . . 9 4.3。 反拡大メカニズム. . . . . . . . . . . . . . . . 10 5。 国際化問題. . . . . . . . . . . . . 10 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 10 7。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 11 8. 承認. . . . . . . . . . . . . . . . . . . . . . . 11 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1。 引用規格. . . . . . . . . . . . . . . . . . 12 9.2。 有益な参照. . . . . . . . . . . . . . . . . 12作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 13

1. Introduction

1. 序論

1.1.  General

1.1. 一般

   The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
   features to negotiate selection of a lossless data compression method
   as part of the TLS Handshake Protocol and then to apply the algorithm
   associated with the selected method as part of the TLS Record
   Protocol.  TLS defines one standard compression method,
   CompressionMethod.null, which specifies that data exchanged via the
   record protocol will not be compressed.  Although this single
   compression method helps ensure that TLS implementations are
   interoperable, the lack of additional standard compression methods
   has limited the ability to develop interoperative implementations
   that include data compression.

Transport Layer Security(TLS)は議定書を作ります。(RFC2246、[2])はTLS Handshakeプロトコルの一部として歪みを許さない圧縮方法の選択を交渉して、そして、TLS Recordプロトコルの一部として選択された方法に関連しているアルゴリズムを適用する特徴を含んでいます。 TLSは1つの標準の圧縮方法、CompressionMethod.nullを定義します。(CompressionMethod.nullは、記録的なプロトコルで交換されたデータが圧縮されないと指定します)。 このただ一つの圧縮方法は、TLS実現が共同利用できるのを確実にするのを助けますが、追加標準の圧縮方法の不足はデータ圧縮を含んでいるinteroperative実現を開発する能力を制限しました。

Friend                       Informational                      [Page 2]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[2ページ]のRFC3943TLS圧縮

   TLS is used extensively to secure client-server connections on the
   World Wide Web.  Although these connections can often be
   characterized as short-lived and exchanging relatively small amounts
   of data, TLS is also being used in environments where connections can
   be long-lived and the amount of data exchanged can extend into
   thousands or millions of octets.  For example, TLS is now
   increasingly being used as an alternative Virtual Private Network
   (VPN) connection.  Compression services have long been associated
   with IPSec and PPTP VPN connections, so extending compression
   services to TLS VPN connections preserves the user experience for any
   VPN connection.  Compression within TLS is one way to help reduce the
   bandwidth and latency requirements associated with exchanging large
   amounts of data while preserving the security services provided by
   TLS.

TLSは、WWWでクライアント/サーバ接続を保証するのに手広く使用されます。 これらの接続は、しばしば短命であるとして特徴付けられて、比較的少な量のデータを交換できますが、また、TLSは接続が長命である場合がある環境で使用されています、そして、交換されたデータ量は数千か何百万もの八重奏に広がることができます。 例えば、TLSは現在、ますます代替のVirtual兵士のNetwork(VPN)接続として使用されています。 圧縮サービスが長い間IPSecとPPTP VPN接続に関連しているので、TLS VPN接続に対する圧縮サービスを広げていると、ユーザー・エクスペリエンスはどんなVPN接続のためにも保存されます。 TLSによって提供されたセキュリティー・サービスを保持している間、多量のデータを交換すると関連している帯域幅と潜在要件を減らすのを助けることにおいてTLSの中の圧縮は一方通行です。

   This document describes an additional compression method associated
   with a lossless data compression algorithm for use with TLS.  This
   document specifies the application of Lempel-Ziv-Stac (LZS)
   compression, a lossless compression algorithm, to TLS record
   payloads.  This specification also assumes a thorough understanding
   of the TLS protocol [2].

このドキュメントはTLSと共に使用のための歪みを許さない圧縮アルゴリズムに関連している追加圧縮方法を説明します。 このドキュメントはLempel-Ziv-Stac(LZS)圧縮の応用、可逆圧縮アルゴリズムをTLSの記録的なペイロードまで指定します。 また、この仕様はTLSプロトコル[2]の徹底的な理解を仮定します。

1.2.  Specification of Requirements

1.2. 要件の仕様

   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 BCP 14, RFC 2119 [1].

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

2.  Compression Methods

2. 圧縮方法

   As described in section 6 of RFC 2246 [2], TLS is a stateful
   protocol.  Compression methods used with TLS can be either stateful
   (the compressor maintains its state through all compressed records)
   or stateless (the compressor compresses each record independently),
   but there seems to be little known benefit in using a stateless
   compression method within TLS.  The LZS compression method described
   in this document is stateful.

RFC2246[2]のセクション6で説明されるように、TLSはstatefulプロトコルです。 TLSと共に使用される圧縮方法は、statefulであるか(コンプレッサーはすべての圧縮された記録を通して状態を維持します)、または国がない場合がありますが(コンプレッサーは独自に各記録を圧縮します)、ほとんど知られていない利益はTLSの中で国がない圧縮方法を使用する際にあるように思えます。 本書では説明されたLZS圧縮方法はstatefulです。

   Compression algorithms can occasionally expand, rather than compress,
   input data.  The worst-case expansion factor of the LZS compression
   method is only 12.5%.  Thus, TLS records of 15K bytes can never
   exceed the expansion limits described in section 6.2.2 of RFC 2246
   [2].  If TLS records of 16K bytes expand to an amount greater than
   17K bytes, then the uncompressed version of the TLS record must be
   transmitted, as described below.

圧縮アルゴリズムは時折圧縮するよりむしろ入力データを広くすることができます。 LZS圧縮方法に関する最悪の場合膨張係数は12.5%にすぎません。 したがって、15Kのバイトに関するTLS記録は.2セクション6.2RFC2246[2]で説明された拡大限界を決して超えることができません。 16Kのバイトに関するTLS記録が17Kバイト以上の量に広がるなら、TLS記録の解凍されたバージョンを伝えなければなりません、以下で説明されるように。

Friend                       Informational                      [Page 3]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[3ページ]のRFC3943TLS圧縮

2.1.  LZS CompressionMethod

2.1. LZS CompressionMethod

   The LZS CompressionMethod is a 16-bit index and is negotiated as
   described in RFC 2246 [2] and RFC 3749 [3].  The LZS
   CompressionMethod is stored in the TLS Record Layer connection state
   as described in RFC 2246 [2].

LZS CompressionMethodは16ビットのインデックスであり、RFC2246[2]とRFC3749[3]で説明されるように交渉されます。 LZS CompressionMethodはRFC2246[2]で説明されるようにTLS Record Layer接続状態に格納されます。

   IANA has assigned 64 as compression method identifier for applying
   LZS compression to TLS record payloads.

IANAはTLSの記録的なペイロードにLZS圧縮を適用するための圧縮方法識別子として64を割り当てました。

2.2.  Security Issues with Compression Histories

2.2. 圧縮歴史の安全保障問題

   Sharing compression histories between or among more than one TLS
   session may potentially cause information leakage between the TLS
   sessions, as pathological compressed data can potentially reference
   data prior to the beginning of the current record.  LZS
   implementations guard against this situation.  However, to avoid this
   potential threat, implementations supporting TLS compression MUST use
   separate compression histories for each TLS session.  This is not a
   limitation of LZS compression but is an artifact for any compression
   algorithm.

セッションか1つ以上のTLSセッションの圧縮歴史が病理学的な圧縮されたデータとして潜在的にTLSセッションの間の情報漏出をもたらすかもしれない共有は潜在的に現在の記録の始まりの前の参考資料をそうすることができます。 LZS実現はこの状況に用心します。 しかしながら、この潜在的な脅威を避けるために、TLS圧縮を支持する実現はそれぞれのTLSセッションのために別々の圧縮歴史を費やさなければなりません。 これは、LZS圧縮の制限ではありませんが、どんな圧縮アルゴリズムのための人工物です。

   Furthermore, the LZS compression history (as well as any compression
   history) contains plaintext.  Specifically, the LZS history contains
   the last 2K bytes of plaintext of the TLS session.  Thus, when the
   TLS session terminates, the implementation SHOULD treat the history
   as it does any plaintext (e.g., free memory, overwrite contents).

その上、LZS圧縮歴史(どんな圧縮歴史と同様に)は平文を含んでいます。 明確に、LZS歴史はTLSセッションの平文の最後の2Kのバイトを含んでいます。 したがって、TLSセッションが終わると、どんな平文もするとき(例えば、メモリを解放してください、重ね書きコンテンツ)、実現SHOULDは歴史を扱います。

3.  LZS Compression

3. LZS圧縮

3.1.  Background of LZS Compression

3.1. LZS圧縮のバックグラウンド

   Starting with a sliding window compression history, similar to LZ1
   [8], a new, enhanced compression algorithm identified as LZS was
   developed.  The LZS algorithm is a general-purpose lossless
   compression algorithm for use with a wide variety of data types. Its
   encoding method is very efficient, providing compression for strings
   as short as two octets in length.

引窓圧縮歴史からの始め、LZ1[8]と同様です、LZSとして特定された新しくて、高められた圧縮アルゴリズムは開発されました。 LZSアルゴリズムはさまざまなデータ型がある使用のための汎用可逆圧縮アルゴリズムです。 2つの八重奏と同じくらい急にストリングのための圧縮を長さに提供して、方法をコード化するのは、非常に効率的です。

   The LZS algorithm uses a sliding window of 2,048 bytes.  During
   compression, redundant sequences of data are replaced with tokens
   that represent those sequences.  During decompression, the original
   sequences are substituted for the tokens in such a way that the
   original data is exactly recovered.  LZS differs from lossy
   compression algorithms, such as those often used for video
   compression, that do not exactly reproduce the original data.  The
   details of LZS compression can be found in section 3.5 below.

LZSアルゴリズムは2,048バイトの引窓を使用します。 圧縮の間、データの余分な系列をそれらの系列を表す象徴に取り替えます。 減圧の間、オリジナルのデータがまさに回復されるような方法で象徴に元の系列を代入します。 LZSはまさにオリジナルのデータを再生させない画像圧縮にしばしば使用されるものなどの非可逆圧縮アルゴリズムと異なっています。 下のセクション3.5でLZS圧縮の詳細を見つけることができます。

Friend                       Informational                      [Page 4]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[4ページ]のRFC3943TLS圧縮

3.2.  LZS Compression History and Record Processing

3.2. LZS圧縮歴史と記録的な処理

   This standard specifies "stateful" compression -- that is,
   maintaining the compression history between records within a
   particular TLS compression session.  Within each separate compression
   history, the LZS CompressionMethod can maintain compression history
   information when compressing and decompressing record payloads.
   Stateful compression provides a higher compression ratio to be
   achieved on the data stream, as compared to stateless compression
   (resetting the compression history between every record),
   particularly for small records.

この規格は"stateful"圧縮を指定します--すなわち、特定のTLS圧縮セッション以内の記録の間の圧縮歴史を維持します。 記録的なペイロードを圧縮して、減圧するとき、それぞれの別々の圧縮歴史の中では、LZS CompressionMethodは圧縮履歴情報を維持できます。 Stateful圧縮はデータ・ストリームのときに達成されるべきより高い圧縮比を提供します、国がない圧縮(あらゆる記録の間の圧縮歴史をリセットする)と比べて、特に小さい記録のために。

   Stateful compression requires both a reliable link and sequenced
   record delivery to ensure that all records can be decompressed in the
   same order they were compressed.  Since TLS and lower-layer protocols
   provide reliable, sequenced record delivery, compression history
   information MAY be maintained and exploited when the LZS
   CompressionMethod is used.

Stateful圧縮は、すべての記録が同次で減圧されて、それらが圧縮されたということであるかもしれないことを保証するために信頼できるリンクと配列された記録的な配送の両方を必要とします。 TLSと下位層プロトコルが信頼できて、配列された記録的な配送を提供するので、LZS CompressionMethodが使用されているとき、圧縮履歴情報は、維持されて、利用されるかもしれません。

   Furthermore, there MUST be a separate LZS compression history
   associated with each open TLS session.  This not only provides
   enhanced security (no potential information leakage between sessions
   via a shared compression history), but also enables superior
   compression ratio (bit bandwidth on the connection) across all open
   TLS sessions with compression.  A shared history would require
   resetting the compression (and decompression) history when switching
   between TLS sessions, and a single history implementation would
   require resetting the compression (and decompression) history between
   each record.

その上、それぞれの開いているTLSセッションに関連している別々のLZS圧縮歴史があるに違いありません。 これは警備の強化(共有された圧縮歴史を通したセッションの間の潜在的情報漏出がない)を提供するだけではなく、圧縮とのすべての開いているTLSセッションの向こう側に優れた圧縮比(接続における帯域幅に噛み付く)を可能にもします。 TLSセッションを切り換えるとき、共有する歴史は、圧縮(そして、減圧)歴史をリセットするのを必要とするでしょう、そして、ただ一つの歴史実現は圧縮(そして、減圧)歴史をリセットするのをそれぞれ記録的に必要とするでしょう。

   The sender MUST reset the compression history prior to compressing
   the first TLS record of a TLS session after TLS handshake completes.
   It is advantageous for the sender to maintain the compression history
   for all subsequent records processed during the TLS session.  This
   results in the greatest compression ratio for a given data set.  In
   either case, this compression history MUST NOT be used for any other
   open TLS session, to ensure privacy between TLS sessions.

握手が完成するTLSの後にTLSセッションの最初のTLS記録を圧縮する前に、送付者は圧縮歴史をリセットしなければなりません。 送付者がTLSセッションの間に処理されたすべてのその後の記録のための圧縮歴史を維持するのは、有利です。 これは与えられたデータセットのための最大級の圧縮比をもたらします。 どちらかのケース、歴史を費やしてはいけないこの圧縮では、いかなる他のも、TLSセッションの間で秘密を守るためにTLSセッションを開きます。

   The sender MUST "flush" the compressor each time it transmits a
   compressed record.  Flushing means that all data going into the
   compressor is included in the output, i.e., no data is retained in
   the hope of achieving better compression.  Flushing ensures that each
   compressed record payload can be decompressed completely. Flushing is
   necessary to prevent a record's data from spilling over into a later
   record.  This is important for synchronizing compressed data with the
   authenticated and encrypted data in a TLS record.  Flushing is
   handled automatically in most LZS implementations.

送付者はそれが圧縮された記録を伝える各回にコンプレッサーを「洗い流さなければなりません」。 洗い流すのは、コンプレッサーに入るすべてのデータが出力に含まれていて、すなわち、より良い圧縮を達成することを希望してデータが全く保有されないことを意味します。 洗い流すのは、それぞれの圧縮された記録的なペイロードを完全に減圧できるのを確実にします。 洗い流すのが、記録のデータが後の記録にあふれ出るのを防ぐのに必要です。 TLSレコードの認証されてコード化されたデータと圧縮されたデータを同期させるのに、これは重要です。 洗い流すことはほとんどのLZS実現で自動的に扱われます。

Friend                       Informational                      [Page 5]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[5ページ]のRFC3943TLS圧縮

   When the TLS session terminates, the implementation SHOULD dispose of
   the memory resources associated with the related TLS compression
   history.  That is, the compression history SHOULD be handled as the
   TLS key material is handled.

TLSセッションが終わると、実現SHOULDは関連するTLS圧縮歴史に関連しているメモリリソースを処分します。 それはそうであり、圧縮歴史はSHOULDです。TLS主要な材料が扱われるので、扱われてください。

   The LZS CompressionMethod also features "decompressing" uncompressed
   data in order to maintain the history if the "compressed" data
   actually expanded.  The LZS CompressionMethod record format
   facilitates identifying whether records contain compressed or
   uncompressed data.  The LZS decoding process accommodates
   decompressing either compressed or uncompressed data.

また、LZS CompressionMethodは、「圧縮された」データが実際に広がったなら歴史を維持するために「減圧」の解凍されたデータを特徴とします。 LZS CompressionMethodレコード形式は、記録が圧縮されたか解凍されたデータを含むかどうか特定するのを容易にします。 減圧する解読過程が収容するLZSはデータを圧縮したか、または解凍しました。

3.3.  LZS Compressed Record Format

3.3. LZSはレコード形式を圧縮しました。

   Prior to compression, the uncompressed data (TLSPlaintext.fragment)
   is composed of a plaintext TLS record.  After compression, the
   compressed data (TLSCompressed.fragment) is composed of an 8-bit
   TLSComp header followed by the compressed (or uncompressed) data.

圧縮の前に、解凍されたデータ(TLSPlaintext.fragment)は平文TLS記録で構成されます。 圧縮の後に、圧縮されたデータ(TLSCompressed.fragment)は圧縮された(または、解凍される)データがあとに続いた8ビットのTLSCompヘッダーで構成されます。

3.4.  TLSComp Header Format

3.4. TLSCompヘッダー形式

   The one-octet header has the following structure:

1八重奏のヘッダーには、以下の構造があります:

      0

0

      0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |     Flags     |
      |               |
      +-+-+-+-+-+-+-+-+

0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 旗| | | +-+-+-+-+-+-+-+-+

3.4.1.  Flags

3.4.1. 旗

   The format of the 8-bit Flags TLSComp field is as follows:

8ビットのFlags TLSComp分野の形式は以下の通りです:

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      | Res | Res | Res | Res | Res | Res | RST | C/U |
      +-----+-----+-----+-----+-----+-----+-----+-----+

0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Res| Res| Res| Res| Res| Res| RST| C/U| +-----+-----+-----+-----+-----+-----+-----+-----+

   Res-Reserved

Resによって予約されています。

      Reserved for future use.  MUST be set to zero.  MUST be ignored by
      the receiving node.

今後の使用のために、予約されます。 ゼロに設定しなければなりません。 受信ノードで無視しなければなりません。

Friend                       Informational                      [Page 6]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[6ページ]のRFC3943TLS圧縮

   RST-Reset Compression History

RST-リセット圧縮歴史

      The RST bit is used to inform the decompressing peer that the
      compression history in this TLS session was reset prior to the
      data contained in this TLS record being compressed.  When the RST
      bit is set to "1", a compression history reset is performed; when
      RST is set to "0", a compression history reset is not performed.

RSTビットは、このTLSセッションにおける圧縮歴史が圧縮されていて、このTLS記録に含まれたデータの前にリセットされたことを減圧している同輩に知らせるのに使用されます。 RSTがいつ噛み付いたかは「何1インチも、圧縮歴史リセットは実行されること」に設定されます。 RSTが「何0インチも、圧縮歴史リセットは実行されないこと」に用意ができているとき。

      This bit MUST be set to a value of "1" for the first compressed
      TLS transmitted record of a TLS session.  This bit may also be
      used by the transmitter for other exception cases when the
      compression history must be reset.

「最初の圧縮されたTLSのための1インチはTLSセッションに関する記録を伝えた」値にこのビットを設定しなければなりません。 また、圧縮歴史をリセットしなければならないとき、このビットは他の例外ケースに送信機によって使用されるかもしれません。

   C/U-Compressed/Uncompressed Bit

C/Uで圧縮されたか解凍されたビット

      The C/U indicates whether the data field contains compressed or
      uncompressed data.  A value of 1 indicates compressed data (often
      referred to as a compressed record), and a value of 0 indicates
      uncompressed data (or an uncompressed record).

C/Uは、データ・フィールドが圧縮されたか解凍されたデータを含むかどうかを示します。 1の値は圧縮されたデータ(しばしば圧縮された記録と呼ばれる)を示します、そして、0の値は解凍されたデータ(または、解凍された記録)を示します。

3.5.  LZS Compression Encoding Format

3.5. LZS圧縮コード化形式

   The LZS compression method, encoding format, and application examples
   are described in RFC 1967 [6], RFC 1974 [5], and RFC 2395 [4].

LZS圧縮方法、コード化形式、およびアプリケーションの例はRFC1967[6]、RFC1974[5]、およびRFC2395[4]で説明されます。

   Some implementations of LZS allow the sending compressor to select
   from among several options to provide varying compression ratios,
   processing speeds, and memory requirements.  Other implementations of
   LZS provide optimal compression ratio at byte-per-clock speeds.

LZSのいくつかの実現で、いくつかのオプションの中で選び抜く送付コンプレッサーは、圧縮比、処理速度、およびメモリ要件を変えながら、提供されます。 LZSの他の実現は1クロックスピードあたりのバイトで最適の圧縮比を提供します。

   The receiving LZS decompressor automatically adjusts to the settings
   selected by the sender.  Also, receiving LZS decompressors will
   update the decompression history with uncompressed data.  This
   facilitates never obtaining less than a 1:1 compression ratio in the
   session and never transmitting with expanded data.

受信LZS減圧装置は自動的に送付者によって選択された設定に適応します。 また、LZS減圧装置を受けると、減圧歴史は解凍されたデータでアップデートされるでしょう。 これは、拡張データで伝わりながら、1:1圧縮比以下を決して得るのを容易にしません。

   The input to the payload compression algorithm is TLSPlaintext data
   destined to an active TLS session with compression negotiated.  The
   output of the algorithm is a new (and hopefully smaller)
   TLSCompressed record.  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.

ペイロード圧縮アルゴリズムへの入力は交渉される圧縮との活発なTLSセッションまで運命づけられたTLSPlaintextデータです。 アルゴリズムの出力は新しくて(願わくはより小さい)のTLSCompressed記録です。 出力ペイロードは圧縮されたか解凍された形式に入力ペイロードのデータを含んでいます。 入出力ペイロードは全体が付番する長さにおけるバイトのそれぞれです。

   The output payload is always prepended with the TLSComp header.  If
   the uncompressed form is used, the output payload is identical to the
   input payload, and the TLSComp header reflects uncompressed data.

出力ペイロードはTLSCompヘッダーと共にいつもprependedされます。 解凍されたフォームが使用されているなら、出力ペイロードは入力ペイロードと同じです、そして、TLSCompヘッダーは解凍されたデータを反映します。

Friend                       Informational                      [Page 7]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[7ページ]のRFC3943TLS圧縮

   If the compressed form is used, encoded as defined in ANSI X3.241
   [7], and the TLSComp header reflects compressed data.  The LZS
   encoded format is repeated here for informational purposes ONLY.

圧縮形がANSI X3.241[7]で定義されるように中古で、コード化されていて、TLSCompヘッダーが圧縮されたデータを反映するなら。 LZSは形式をコード化しました。ここで、情報の目的だけのために、繰り返されます。

   <Compressed Stream> := [<Compressed String>*] <End Marker>
   <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>

<圧縮された流れの>:=[<はストリング>*を圧縮した]<エンドマーカー><はストリング>:=生の0<バイト>を圧縮しました。| 1 <はバイト>を圧縮しました。

   <Raw Byte> := <b><b><b><b><b><b><b><b>          (8-bit byte)
   <Compressed Bytes> := <Offset> <Length>

生の<の<b><b Byte>:=<b><b><b><b><b><b>>(8ビットのバイト)<Compressed Bytes>:=<Offset><Length>。

   <Offset> := 1 <b><b><b><b><b><b><b> |           (7-bit offset)
               0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
   <End Marker> := 110000000
   <b> := 1 | 0

<は1<bの>:=><b><b><b><b><b><b>を相殺しました。| (7ビットのオフセット) 0 <b><b><b><b><b><b><b><b><b><b><b>(11ビットのオフセット)<End Marker>:=110000000<b>:=1| 0

   <Length> :=
   00        = 2     1111 0110      = 14
   01        = 3     1111 0111      = 15
   10        = 4     1111 1000      = 16
   1100      = 5     1111 1001      = 17
   1101      = 6     1111 1010      = 18
   1110      = 7     1111 1011      = 19
   1111 0000 = 8     1111 1100      = 20
   1111 0001 = 9     1111 1101      = 21
   1111 0010 = 10    1111 1110      = 22
   1111 0011 = 11    1111 1111 0000 = 23
   1111 0100 = 12    1111 1111 0001 = 24
   1111 0101 = 13     ...

<長さの>:=00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13…

3.6.  Padding

3.6. 詰め物

   A datagram payload compressed with LZS always ends with the last
   compressed data byte (also known as the <end marker>), which is used
   to disambiguate padding.  This allows trailing bits, as well as
   bytes, to be considered padding.

LZSと共に圧縮されたデータグラムペイロードはいつも最後に圧縮されたデータ・バイト(また、<エンドマーカー>として、知られている)で終わります。(それは、詰め物のあいまいさを除くのに使用されます)。 これは、引きずっているバイトと同じくらい良いビットが詰め物であると考えられるのを許容します。

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

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

4.  Sending Compressed Datagrams

4. 送付の圧縮されたデータグラム

   All TLS records processed with a TLS session state that includes LZS
   compression are processed as follows.  The reliable and efficient
   transport of LZS compressed records in the TLS session depends on the
   following processes.

TLSセッション州がLZS圧縮を含んでいて処理されたすべてのTLS記録が以下の通り処理されます。 LZSの信頼できて効率的な輸送はセッションを以下の過程に依存するというTLSでの記録を圧縮しました。

Friend                       Informational                      [Page 8]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[8ページ]のRFC3943TLS圧縮

4.1.  Transmitter Process

4.1. 送信機の過程

   The compression operation results in either compressed or
   uncompressed data.  When a TLS record is received, it is assigned to
   a particular TLS context that includes the LZS compression history
   buffer.  It is processed according to ANSI X3.241-1994 to form
   compressed data or used as is to form uncompressed data.  For the
   first record of the session, or for exception conditions, the
   compression history MUST be cleared.  In performing the compression
   operation, the compression history MUST be updated when either a
   compressed record or an uncompressed record is produced.
   Uncompressed TLS records MAY be sent at any time. Uncompressed TLS
   records MUST be sent if compression causes enough expansion to make
   the data compression TLS record size exceed the MTU defined in
   section 6.2.2 in RFC 2246.  The output of the compression operation
   is placed in the fragment field of the TLSCompressed structure
   (TLSCompressed.fragment).

操作がもたらす圧縮は、データを圧縮したか、または解凍しました。 TLS記録が受信されているとき、それはLZS圧縮歴史バッファを含んでいる特定のTLS文脈に割り当てられます。 それは、ANSI X3.241-1994によると、圧縮されたデータを形成するために処理されるか、または解凍されたデータを形成するのにそのままで使用されます。 セッションの最初の記録、または例外条件に関しては、圧縮歴史をクリアしなければなりません。 圧縮操作を実行する際に、圧縮された記録か解凍された記録のどちらかを作り出すとき、圧縮歴史をアップデートしなければなりません。 いつでも、解凍されたTLS記録を送るかもしれません。 データ圧縮TLSレコード・サイズがRFC2246で拡大でセクション6.2.2で定義されたMTUを十分超えているなら、圧縮で解凍されたTLS記録を送らなければなりません。 圧縮操作の出力はTLSCompressed構造(TLSCompressed.fragment)の断片分野に置かれます。

   The TLSComp header byte is located just prior to the first byte of
   the compressed TLS record in TLSCompressed.fragment.  The C/U bit in
   the TLSComp header is set according to whether the data field
   contains compressed or uncompressed data.  The RST bit in the TLSComp
   header is set to "1" if the compression history was reset prior to
   compressing the TLSplaintext.fragment that is composed of a
   TLSCompressed.fragment.  Uncompressed data MUST be transmitted (and
   the C/U bit set to 0) if the "compressed" (expanded) data exceeded
   17K bytes.

TLSCompヘッダーバイトはTLSCompressed.fragmentにおける、圧縮されたTLS記録の最初のバイトのすぐ前に見つけられています。 データ・フィールドが圧縮されたか解凍されたデータを含んでいるかどうかに従って、TLSCompヘッダーのC/Uビットは設定されます。 TLSCompヘッダーのRSTビットは「何1インチも、それは圧縮歴史がTLSplaintext.fragmentを圧縮する前のリセットであったならTLSCompressed.fragmentで構成されること」に設定されます。 「圧縮された」(広げられる)データが17Kのバイトを超えていたなら、解凍されたデータを送らなければなりません(C/Uビットは0にセットしました)。

4.2.  Receiver Process

4.2. 受信機の過程

   Prior to decompressing the first compressed TLS record in the TLS
   session, the receiver MUST reset the decompression history.
   Subsequent records are decompressed in the order received.  The
   receiver decompresses the Payload Data field according to the
   encoding specified in section 3.5 above.

TLSセッションにおける最初の圧縮されたTLS記録を減圧する前に、受信機は減圧歴史をリセットしなければなりません。 その後の記録は受注で減圧されます。 上のセクション3.5で指定されたコード化に従って、受信機は有効搭載量Data分野を減圧します。

   If the received datagram is not compressed, the receiver does not
   need to perform decompression processing, and the Payload Data field
   of the datagram is ready for processing by the next protocol layer.

容認されたデータグラムが圧縮されないなら、受信機は減圧処理を実行する必要はありません、そして、データグラムの有効搭載量Data分野は処理の次のプロトコル層のそばで準備ができています。

   After a TLS record is received from the peer and decrypted, the RST
   and C/U bits MUST be checked.

TLS記録が同輩から受け取られて、解読された後に、RSTとC/Uビットをチェックしなければなりません。

   If the C/U bit is set to "1", the resulting compressed data block
   MUST be decompressed according to section 3.5 above.

C/Uビットが「1インチ、上のセクション3.5によると、結果として起こる圧縮されたデータ・ブロックを減圧しなければならないこと」に設定されるなら。

   If the C/U bit is set to "0", the specified decompression history
   MUST be updated with the received uncompressed data.

C/Uビットが「何0インチも、受信された解凍されたデータで指定された減圧歴史をアップデートしなければならないこと」に設定されるなら。

Friend                       Informational                      [Page 9]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[9ページ]のRFC3943TLS圧縮

   If the RST bit is set to "1", the receiving decompression history MAY
   be reset to an initial state prior to decompressing the TLS record.
   (However, due to the characteristics of the Hifn LZS algorithm, a
   decompression history reset is not required).  After reset, any
   compressed or uncompressed data contained in the record is processed.

RSTビットが「1インチ、TLS記録を減圧する前に、受信減圧歴史は初期状態にリセットされるかもしれないこと」に設定されるなら。 (しかしながら、Hifn LZSアルゴリズムの特性のため、減圧歴史リセットは必要ではありません。) リセットされた後に、記録に含まれたどんな圧縮されたか解凍されたデータも処理されます。

4.3.  Anti-expansion Mechanism

4.3. 反拡大メカニズム

   During compression, there are two workable options for handling
   records that expand:

圧縮の間、広がる取り扱い記録のための2つの実行可能なオプションがあります:

   1) Send the expanded data (as long as TLSCompressed.length is 17K or
      less) and maintain the history, thus allowing loss of current
      bandwidth but preserving future bandwidth on the link.

1) 拡張データを送ってください、そして、(TLSCompressed.lengthが17K以下である限り)歴史を維持してください、その結果、現在の帯域幅の損失を許容しますが、リンクにおける将来の帯域幅を保持して。

   2) Send the uncompressed data and do not clear the compression
      history; the decompressor will update its history, thus conserving
      the current bandwidth and future bandwidth on the link.

2) 解凍されたデータを送ってください、そして、圧縮歴史をクリアしないでください。 減圧装置は歴史をアップデートして、その結果、リンクにおける現在の帯域幅と将来の帯域幅を保存するでしょう。

   The second option is the preferred option and SHOULD be implemented.

オプションが都合のよいオプションとSHOULDである秒に、実行されてください。

   There is a third option:

3番目のオプションがあります:

   3) Send the uncompressed data and clear the history, thus conserving
      current bandwidth but allowing possible loss of future bandwidth
      on the link.

3) 解凍されたデータを送ってください、そして、歴史をクリアしてください、その結果、現在の帯域幅を保存しますが、リンクにおける将来の帯域幅の可能な損失を許容して。

   This option SHOULD NOT be implemented.

これはSHOULD NOTにゆだねます。実行されます。

5.  Internationalization Considerations

5. 国際化問題

   The compression method identifiers specified in this document are
   machine-readable numbers.  As such, issues of human
   internationalization and localization are not introduced.

本書では指定された圧縮方法識別子は機械可読な数です。 そういうものとして、人間の国際化とローカライズの問題は紹介されません。

6.  IANA Considerations

6. IANA問題

   Section 2 of RFC 3749 [3] describes a registry of compression method
   identifiers to be maintained by the IANA and to be assigned within
   three zones.

RFC3749[3]のセクション2はIANAによって維持されて、3つのゾーンの中で割り当てられる圧縮方法識別子の登録について説明します。

   IANA has assigned an identifier for the LZS compression method from
   the RFC 2434 Specification Required IANA pool, as described in
   sections 2 and 5 of RFC 3749 [3].

IANAはRFC2434Specification Required IANAプールからLZS圧縮方法のための識別子を割り当てました、RFC3749[3]のセクション2と5で説明されるように。

   The IANA-assigned compression method identifier for LZS is 64 decimal
   (0x40).

LZSのためのIANAによって割り当てられた圧縮方法識別子は64小数(0×40)です。

Friend                       Informational                     [Page 10]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[10ページ]のRFC3943TLS圧縮

7.  Security Considerations

7. セキュリティ問題

   This document does not introduce any topics that alter the threat
   model addressed by TLS.  The security considerations described
   throughout RFC 2246 [2] apply here as well.

このドキュメントはTLSによって宛てられた脅威モデルを変更するどんな話題も紹介しません。 また、RFC2246[2]中で説明されたセキュリティ問題はここに適用されます。

   However, combining compression with encryption can sometimes reveal
   information that would not have been revealed without compression.
   Data that is the same length before compression might be a different
   length after compression, so adversaries that observe the length of
   the compressed data might be able to derive information about the
   corresponding uncompressed data.  Some symmetric encryption
   ciphersuites do not hide the length of symmetrically encrypted data
   at all.  Others hide it to some extent but not fully.  For example,
   ciphersuites that use stream cipher encryption without padding do not
   hide length at all; ciphersuites that use Cipher Block Chaining (CBC)
   encryption with padding provide some length hiding, depending on how
   the amount of padding is chosen.  Use of TLS compression SHOULD take
   into account that the length of compressed data may leak more
   information than the length of the original uncompressed data.

しかしながら、圧縮を暗号化に結合すると、時々圧縮なしで明らかにされていない情報は明らかにすることができます。 圧縮が圧縮の後の異なった長さであるかもしれない前に同じ長さであるデータによって、圧縮されたデータの長さが対応の情報を引き出すことができるかもしれないのを観測する敵がデータを解凍しました。 何らかの左右対称の暗号化ciphersuitesは全く対称的にコード化されたデータの長さを隠しません。 他のものは、それをある程度隠しますが、完全に隠すというわけではありません。 例えば、詰め物なしでストリーム暗号暗号化を使用するciphersuitesが全く長さを隠しません。 詰め物によるCipher Block Chaining(CBC)暗号化を使用するciphersuitesが詰め物の量がどう選ばれているかによって、隠れる何らかの長さを提供します。 TLS圧縮SHOULDの使用は、圧縮されたデータの長さがオリジナルの解凍されたデータの長さより多くの情報を漏らすかもしれないのを考慮に入れます。

   Another security issue to be aware of is that the LZS compression
   history contains plaintext.  In order to prevent any kind of
   information leakage outside the system, when a TLS session with
   compression terminates, the implementation SHOULD treat the
   compression history as it does plaintext -- that is, care should be
   taken not to reveal the compression history in any form or to use it
   again.  This is described in sections 2.2 and 3.2 above.

意識しているのが、LZS圧縮歴史が平文を含んでいるということであるということである別の安全保障問題。 圧縮とのTLSセッションが終わるとシステムの外でどんな種類の情報漏出も防ぐために、平文をするとき、実現SHOULDは圧縮歴史を扱います--すなわち、注意はどんなフォームでも圧縮歴史を明らかにしないか、または再びそれを使用するために払われるべきです。 これは上のセクション2.2と3.2で説明されます。

   This information leakage concept can be extended to the situation of
   sharing a single compression history across more than one TLS
   session, as addressed in section 2.2 above.

1つ以上のTLSセッションの向こう側にただ一つの圧縮歴史を共有する状況にこの情報漏出概念について敷衍できます、上のセクション2.2で記述されるように。

   Other security issues are discussed in RFC 3749 [3].

RFC3749[3]で他の安全保障問題について議論します。

8.  Acknowledgements

8. 承認

   The concepts described in this document were derived from RFC 1967
   [6], RFC 1974 [5], RFC 2395 [4], and RFC 3749 [3].  The author
   acknowledges the contributions of Scott Hollenbeck, Douglas Whiting,
   and Russell Dietz, and help from Steve Bellovin, Russ Housley, and
   Eric Rescorla.

RFC1967[6]、RFC1974[5]、RFC2395[4]、およびRFC3749[3]から本書では説明された概念を得ました。 作者はスティーブBellovin、ラスHousley、およびエリック・レスコラからスコットHollenbeck、ダグラス・ホワイティングの貢献、ラッセル・ディーツ、および助けを承諾します。

Friend                       Informational                     [Page 11]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[11ページ]のRFC3943TLS圧縮

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

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

   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [3]  Hollenbeck, S. "Transport Layer Security Protocol Compression
        Methods", RFC 3749, May 2004.

[3] Hollenbeck(S.「トランスポート層セキュリティプロトコル圧縮方法」、RFC3749)は2004がそうするかもしれません。

9.2.  Informative References

9.2. 有益な参照

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

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

   [5]  Friend, R. and W. Simpson, "PPP Stac LZS Compression Protocol",
        RFC 1974, August 1996.

[5] 友人とR.とW.シンプソン、「ppp Stac LZS圧縮プロトコル」、RFC1974、1996年8月。

   [6]  Schneider, K. and R. Friend, "PPP LZS-DCP Compression Protocol
        (LZS-DCP)", RFC 1967, August 1996.

[6]シュナイダーとK.とR.友人、「ppp LZS-DCP圧縮プロトコル(LZS-DCP)」、RFC1967、1996年8月。

   [7]  American National Standards Institute, Inc., "Data Compression
        Method for Information Systems," ANSI X3.241-1994, August 1994.

[7] American National Standards Institut Inc.、「情報システムのためのデータ圧縮方法」、ANSI X3.241-1994、1994年8月。

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

情報理論、Vol.IT-23、No.3(1977年9月)における[8]LempelとA.とJ.Ziv、「連続したデータ圧縮のための普遍的なアルゴリズム」、IEEE取引。

Author's Address

作者のアドレス

   Robert Friend
   Hifn
   5973 Avenida Encinas
   Carlsbad, CA 92008
   US

ロバート友人Hifn5973アヴェニダEncinasカリフォルニア92008カールスバッド(米国)

   EMail: rfriend@hifn.com

メール: rfriend@hifn.com

Friend                       Informational                     [Page 12]

RFC 3943               TLS Compression Using LZS           November 2004

2004年11月にLZSを使用する友人の情報[12ページ]のRFC3943TLS圧縮

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and at www.rfc-editor.org, and except as set
   forth therein, the authors retain all their rights.

このドキュメントはBCP78と、www.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

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

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

Friend                       Informational                     [Page 13]

友人情報です。[13ページ]