RFC 3749 - Transport Layer Security Protocol Compression Methods 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3749
タイトル : RFC 3749 - 輸送層セキュリティプロトコル圧縮方法
翻訳編集 : 自動生成

[要約] RFC 3749は、Transport Layer Security (TLS) プロトコルのための圧縮方法に関する仕様を定義しています。この文書の主な目的は、TLSプロトコルでのデータ伝送効率を向上させるために、圧縮機能を導入することです。これにより、ネットワークの帯域幅を節約し、特に大量のデータを扱う場面でのパフォーマンスを改善することができます。関連するRFCには、TLSプロトコルを定義するRFC 5246（TLS 1.2）や、その後継であるRFC 8446（TLS 1.3）などがあります。RFC 3749は、セキュリティと効率のバランスを取りながら、TLSを通じたデータ伝送を最適化するための重要なステップを提供します。

Network Working Group                                      S. Hollenbeck
Request for Comments: 3749                                VeriSign, Inc.
Category: Standards Track                                       May 2004

Transport Layer Security Protocol Compression Methods

輸送層セキュリティプロトコル圧縮方法

Status of this Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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 to then 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 a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods.

トランスポートレイヤーセキュリティ（TLS）プロトコル（RFC 2246）には、TLSハンドシェイクプロトコルの一部としてロスレスデータ圧縮法の選択を交渉し、選択したメソッドに関連付けられたTLSレコードプロトコルの一部として関連するアルゴリズムを適用する機能が含まれています。TLSは、レコードプロトコルを介して交換されたデータが圧縮されないことを指定する1つの標準圧縮方法を定義します。このドキュメントは、TLSで使用するためのロスレスデータ圧縮アルゴリズムに関連付けられた追加の圧縮方法について説明し、追加のTLS圧縮方法の仕様の方法を説明します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Compression Methods  . . . . . . . . . . . . . . . . . . . . .  2
       2.1.  DEFLATE Compression. . . . . . . . . . . . . . . . . . .  3
   3.  Compression History and Packet Processing  . . . . . . . . . .  4
   4.  Internationalization Considerations  . . . . . . . . . . . . .  4
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       8.1.  Normative References . . . . . . . . . . . . . . . . . .  6
       8.2.  Informative References . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8

1. Introduction

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 to then 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. While this single compression method helps ensure that TLS implementations are interoperable, the lack of additional standard compression methods has limited the ability of implementers to develop interoperable implementations that include data compression.

トランスポートレイヤーセキュリティ（TLS）プロトコル（RFC 2246、[2]）には、TLSハンドシェイクプロトコルの一部としてロスレスデータ圧縮法の選択を交渉し、TLSの一部として選択した方法に関連付けられたアルゴリズムを適用する機能が含まれています。レコードプロトコル。TLSは、1つの標準圧縮法であるCompressionMethod.Nullを定義します。これは、レコードプロトコルを介して交換されたデータが圧縮されないことを指定します。この単一の圧縮方法は、TLS実装が相互運用可能であることを保証するのに役立ちますが、追加の標準圧縮方法がないため、データ圧縮を含む相互運用可能な実装を開発する能力が制限されています。

TLS is used extensively to secure client-server connections on the World Wide Web. While 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. XML [4], for example, is increasingly being used as a data representation method on the Internet, and XML tends to be verbose. 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は、World Wide Webでクライアントサーバー接続を保護するために広く使用されています。これらの接続は、多くの場合、短命で比較的少量のデータを交換するものとして特徴付けますが、TLSは接続が長期に寿命にされ、交換されるデータの量が数千または数百万のオクテットに拡張できる環境でも使用されています。たとえば、XML [4]は、インターネット上のデータ表現方法としてますます使用されており、XMLは冗長である傾向があります。TLS内の圧縮は、TLSが提供するセキュリティサービスを維持しながら、大量のデータを交換することに関連する帯域幅と潜時要件を減らすのに役立つ1つの方法です。

This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS. Standardization of the compressed data formats and compression algorithms associated with this compression method is beyond the scope of this document.

このドキュメントでは、TLSで使用するためのロスレスデータ圧縮アルゴリズムに関連付けられた追加の圧縮方法について説明します。この圧縮方法に関連付けられた圧縮データ形式と圧縮アルゴリズムの標準化は、このドキュメントの範囲を超えています。

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

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。

2. Compression Methods

2. 圧縮方法

TLS [2] includes the following compression method structure in sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:

TLS [2]には、セクション6.1および7.4.1.2および付録セクションA.4.1とA.6の次の圧縮方法構造が含まれています。

   enum { null(0), (255) } CompressionMethod;

which allows for later specification of up to 256 different compression methods. This definition is updated to segregate the range of allowable values into three zones:

これにより、最大256の異なる圧縮方法を後で指定できます。この定義は、許容値の範囲を3つのゾーンに分離するために更新されます。

1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols.

1. 0（ゼロ）から63小数（0x3F）を含む値は、IETF標準トラックプロトコル用に予約されています。

2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods.

2. 64 10進数（0x40）から223小数（0xDF）包括的値は、非標準の追跡方法の割り当てのために予約されています。

3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use.

3. 224 10進数（0xe0）から255小数（0xff）包括的値は、私的使用のために予約されています。

Additional information describing the role of the IANA in the allocation of compression method identifiers is described in Section 5.

圧縮法識別子の割り当てにおけるIANAの役割を説明する追加情報については、セクション5で説明します。

In addition, this definition is updated to include assignment of an identifier for the DEFLATE compression method:

さらに、この定義は、デフレート圧縮法の識別子の割り当てを含めるように更新されます。

   enum { null(0), DEFLATE(1), (255) } CompressionMethod;

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.

RFC 2246 [2]のセクション6で説明されているように、TLSはステートフルプロトコルです。TLSで使用される圧縮方法は、ステートフル（コンプレッサーはすべての圧縮レコードを介して状態を維持します）またはステートレス（コンプレッサーは各レコードを個別に圧縮します）のいずれかですが、TLS内でステートレス圧縮法を使用することではほとんど知られていないようです。

The DEFLATE compression method described in this document is stateful. It is RECOMMENDED that other compression methods that might be standardized in the future be stateful as well.

このドキュメントで説明されているデフレート圧縮法はステートフルです。将来標準化される可能性のある他の圧縮方法も同様にステートフルであることをお勧めします。

Compression algorithms can occasionally expand, rather than compress, input data. A compression method that exceeds the expansion limits described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.

圧縮アルゴリズムは、入力データを圧縮するのではなく、時々拡張できます。RFC 2246 [2]のセクション6.2.2で説明されている拡張制限を超える圧縮方法は、TLSで使用してはなりません。

2.1. DEFLATE Compression

2.1. 圧縮をデフレートします

The DEFLATE compression method and encoding format is described in RFC 1951 [5]. Examples of DEFLATE use in IETF protocols can be found in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8].

デフレート圧縮法とエンコード形式は、RFC 1951 [5]で説明されています。IETFプロトコルでのデフレート使用の例は、RFC 1979 [6]、RFC 2394 [7]、およびRFC 3274 [8]に記載されています。

DEFLATE allows the sending compressor to select from among several options to provide varying compression ratios, processing speeds, and memory requirements. The receiving decompressor MUST automatically adjust to the parameters selected by the sender. All data that was submitted for compression MUST be included in the compressed output, with no data retained to be included in a later output payload. Flushing ensures that each compressed packet payload can be decompressed completely.

DEFLATEにより、送信コンプレッサーはいくつかのオプションの中から選択して、さまざまな圧縮比、処理速度、およびメモリ要件を提供できます。受信回転剤は、送信者が選択したパラメーターに自動的に調整する必要があります。圧縮用に送信されたすべてのデータは、圧縮出力に含める必要があり、後の出力ペイロードに含まれるデータは保持されません。フラッシングにより、各圧縮パケットペイロードを完全に解凍できるようになります。

3. Compression History and Packet Processing

3. 圧縮履歴とパケット処理

Some compression methods have the ability to maintain state/history information when compressing and decompressing packet payloads. The compression history allows a higher compression ratio to be achieved on a stream as compared to per-packet compression, but maintaining a history across packets implies that a packet might contain data needed to completely decompress data contained in a different packet. History maintenance thus requires both a reliable link and sequenced packet delivery. Since TLS and lower-layer protocols provide reliable, sequenced packet delivery, compression history information MAY be maintained and exploited if supported by the compression method.

一部の圧縮方法には、パケットペイロードを圧縮および減圧するときに状態/履歴情報を維持する機能があります。圧縮履歴により、パケットあたりの圧縮と比較して、ストリーム上でより高い圧縮比を達成できますが、パケット間の履歴を維持することは、パケットに別のパケットに含まれるデータを完全に解凍するために必要なデータが含まれる可能性があることを意味します。したがって、履歴のメンテナンスには、信頼できるリンクとシーケンスのパケット配信の両方が必要です。TLSおよび低層プロトコルは信頼できるシーケンスのパケット配信を提供するため、圧縮法でサポートされている場合、圧縮履歴情報が維持および悪用される場合があります。

As described in section 7 of RFC 2246 [2], TLS allows multiple connections to be instantiated using the same session through the resumption feature of the TLS Handshake Protocol. Session resumption has operational implications when multiple compression methods are available for use within the session. For example, load balancers will need to maintain additional state information if the compression state is not cleared when a session is resumed. As a result, the following restrictions MUST be observed when resuming a session:

RFC 2246 [2]のセクション7で説明されているように、TLSにより、TLSハンドシェイクプロトコルの再開機能を介して同じセッションを使用して複数の接続をインスタンス化できます。セッション再開には、セッション内で複数の圧縮方法が使用できる場合、運用上の意味があります。たとえば、セッションが再開されたときに圧縮状態がクリアされていない場合、ロードバランサーは追加の状態情報を維持する必要があります。その結果、セッションを再開するときは、次の制限を観察する必要があります。

1. The compression algorithm MUST be retained when resuming a session.

1. セッションを再開するときは、圧縮アルゴリズムを保持する必要があります。

2. The compression state/history MUST be cleared when resuming a session.

2. セッションを再開するときは、圧縮状態/履歴をクリアする必要があります。

4. Internationalization Considerations

4. 国際化の考慮事項

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

このドキュメントで指定されている圧縮法識別子は、機械可読番号です。そのため、人間の国際化とローカリゼーションの問題は導入されていません。

5. IANA Considerations

5. IANAの考慮事項

Section 2 of this document describes a registry of compression method identifiers to be maintained by the IANA, including assignment of an identifier for the DEFLATE compression method. Identifier values from the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action [3]. Values from the range 64-223 (decimal) inclusive are assigned via RFC 2434 Specification Required [3]. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use [3].

このドキュメントのセクション2では、デフレート圧縮法の識別子の割り当てを含む、IANAによって維持される圧縮法識別子のレジストリについて説明します。範囲0-63（小数）包括的範囲の識別子値は、RFC 2434標準アクション[3]を介して割り当てられます。範囲64-223（小数）包括的値からの値は、必要なRFC 2434仕様を介して割り当てられます[3]。224-255（小数）の識別子値は、RFC 2434私的使用に予約されています[3]。

6. Security Considerations

6. セキュリティに関する考慮事項

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が扱う脅威モデルを変更するトピックは紹介されていません。RFC 2246 [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 still do not hide it 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は、長さをまったく非表示にしません。パディングを使用した暗号ブロックチェーン（CBC）暗号化を使用する暗号網は、パディングの量に応じて、長さの隠れを提供します。TLS圧縮の使用は、圧縮データの長さが元の非圧縮データの長さよりも多くの情報を漏らす可能性があることを考慮に入れる必要があります。

Compression algorithms tend to be mathematically complex and prone to implementation errors. An implementation error that can produce a buffer overrun introduces a potential security risk for programming languages and operating systems that do not provide buffer overrun protections. Careful consideration should thus be given to protections against implementation errors that introduce security risks.

圧縮アルゴリズムは数学的に複雑で、実装エラーが発生しやすい傾向があります。バッファオーバーランを生成できる実装エラーは、バッファオーバーラン保護を提供しない言語とオペレーティングシステムのプログラミングに潜在的なセキュリティリスクを導入します。したがって、セキュリティリスクを導入する実装エラーに対する保護には、慎重に検討する必要があります。

As described in Section 2, compression algorithms can occasionally expand, rather than compress, input data. This feature introduces the ability to construct rogue data that expands to some enormous size when compressed or decompressed. RFC 2246 describes several methods to ameliorate this kind of attack. First, compression has to be lossless. Second, a limit (1,024 bytes) is placed on the amount of allowable compression content length increase. Finally, a limit (2^14 bytes) is placed on the total content length. See section 6.2.2 of RFC 2246 [2] for complete details.

セクション2で説明されているように、圧縮アルゴリズムは、入力データを圧縮するのではなく、時々拡張できます。この機能は、圧縮または減圧されたときにいくつかの巨大なサイズに拡大する不正データを構築する機能を紹介します。RFC 2246は、この種の攻撃を改善するいくつかの方法について説明しています。まず、圧縮はロスレスでなければなりません。第二に、制限（1,024バイト）が許容圧縮コンテンツの長さの増加の量に配置されます。最後に、総コンテンツの長さに制限（2^14バイト）が配置されます。詳細については、RFC 2246 [2]のセクション6.2.2を参照してください。

7. Acknowledgements

7. 謝辞

The concepts described in this document were originally discussed on the IETF TLS working group mailing list in December, 2000. The author acknowledges the contributions to that discussion provided by Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen. Later suggestions that have been incorporated into this document were provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the IESG.

このドキュメントで説明されている概念は、2000年12月のIETF TLSワーキンググループメーリングリストで最初に議論されました。著者は、ジェフリーアルトマン、エリックレスコルラ、およびマークヴァンヘインニンンが提供する議論への貢献を認めています。この文書に組み込まれたその後の提案は、ティムディーアークス、パシエロネン、ピーターガットマン、エルギンリー、ニコスマブロヤノプウロス、アレクセイメルニコフ、ボドーモーラー、ウィントリーゼ、およびIESGによって提供されました。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

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

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[2] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。

[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[3] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

8.2. Informative References

8.2. 参考引用

[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.

[4] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（第2版）」、W3C Rec-XML、2000年10月、<http：// www。w3.org/tr/rec-xml>。

[5] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

[5] Deutsch、P。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、1996年5月。

[6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.

[6] Woods、J。、「PPP Deflate Protocol」、RFC 1979、1996年8月。

[7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998.

[7] ペレイラ、R。、「DEFLATEを使用したIPペイロード圧縮」、RFC 2394、1998年12月。

[8] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

[8] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。

Author's Address

著者の連絡先

Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US

Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US

   EMail: shollenbeck@verisign.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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エディター機能の資金は現在、インターネット協会によって提供されています。