RFC3749 日本語訳
3749 Transport Layer Security Protocol Compression Methods. S.Hollenbeck. May 2004. (Format: TXT=16411 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 3749 VeriSign, Inc. Category: Standards Track May 2004
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3749年のベリサインInc.カテゴリ: 標準化過程2004年5月
Transport Layer Security Protocol Compression Methods
トランスポート層セキュリティプロトコル圧縮方法
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
Transport Layer Security(TLS)プロトコル(RFC2246)はTLS Handshakeプロトコルの一部として歪みを許さない圧縮メソッドの選択を交渉して、次にTLS Recordプロトコルの一部として選択されたメソッドに関連しているアルゴリズムを適用する特徴を含んでいます。 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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 圧縮方法. . . . . . . . . . . . . . . . . . . . . 2 2.1。 圧縮に空気を抜かせてください。 . . . . . . . . . . . . . . . . . . 3 3. 圧縮歴史とパケット処理. . . . . . . . . . 4 4。 国際化問題. . . . . . . . . . . . . 4 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 5 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1。 引用規格. . . . . . . . . . . . . . . . . . 6 8.2。 有益な参照. . . . . . . . . . . . . . . . . 6作者のアドレスの.7の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8
Hollenbeck Standards Track [Page 1] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[1ページ]。
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.
Transport Layer Security(TLS)は議定書を作ります。(RFC2246、[2])はTLS Handshakeプロトコルの一部として歪みを許さない圧縮メソッドの選択を交渉して、TLS Recordプロトコルの一部として選択されたメソッドに関連しているアルゴリズムがその時適用される特徴を含んでいます。 TLSは1つの標準の圧縮方法、CompressionMethod.nullを定義します。(CompressionMethod.nullは、記録的なプロトコルで交換されたデータが圧縮されないと指定します)。 このただ一つの圧縮方法は、TLS実装が共同利用できるのを確実にするのを助けますが、追加標準の圧縮方法の不足はimplementersがデータ圧縮を含んでいる共同利用できる実装を開発する能力を制限しました。
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は、WWWでクライアント/サーバ接続を保証するのに手広く使用されます。 また、これらの接続がしばしば短命であるとして特徴付けられて、比較的少な量のデータを交換できる間、TLSは長い間接続を送ることができて、交換されたデータ量が数千か何百万もの八重奏に広がることができる環境で使用されています。 例えばXML[4]はますますデータ表現メソッドとしてインターネットで使用されています、そして、XMLは冗長である傾向があります。 TLSによって提供されたセキュリティー・サービスを保持している間、多量のデータを交換すると関連している帯域幅と潜在要件を減らすのを助けることにおいてTLSの中の圧縮は一方通行です。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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とAppendix部のA.4.1とA.6の以下の圧縮方法構造を含んでいます:
enum { null(0), (255) } CompressionMethod;
ヌル(0)、(255)をenumする、CompressionMethod。
Hollenbeck Standards Track [Page 2] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[2ページ]。
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 Standards Trackプロトコルのために予約されます。
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
are reserved for assignment for non-Standards Track methods.
2. 64小数(0×40)から223小数(0xDF)まで包括的な値は非規格Trackメソッドのための課題のために予約されます。
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
inclusive are reserved for private use.
3. 224小数(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:
さらに、DEFLATE圧縮方法のための識別子の課題を含むようにこの定義をアップデートします:
enum { null(0), DEFLATE(1), (255) } CompressionMethod;
ヌル(0)、DEFLATE(1)、(255)をenumする、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.
RFC2246[2]のセクション6で説明されるように、TLSはstatefulプロトコルです。 TLSと共に使用される圧縮方法は、statefulであるか(コンプレッサーはすべての圧縮された記録を通して状態を維持します)、または状態がない場合がありますが(コンプレッサーは独自に各記録を圧縮します)、ほとんど知られていない利益は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.
本書では説明されたDEFLATE圧縮方法はstatefulです。 また、将来標準化されるかもしれない他の圧縮方法もstatefulであることは、RECOMMENDEDです。
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.
圧縮アルゴリズムは時折圧縮するよりむしろ入力データを広くすることができます。 TLSと共に.2セクション6.2RFC2246[2]で説明された拡張限界を超えている圧縮方法を使用してはいけません。
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].
DEFLATE圧縮方法とコード化形式はRFC1951[5]で説明されます。 RFC1979[6]、RFC2394[7]、およびRFC3274[8]でIETFプロトコルにおけるDEFLATE使用に関する例を見つけることができます。
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,
DEFLATEは、圧縮比、処理速度、およびメモリ要件を変えながら、いくつかのオプションの中で選び抜く送付コンプレッサーを提供させます。 受信減圧装置は自動的に送付者によって選択されたパラメタに適応しなければなりません。 圧縮された出力に圧縮のために提出されたすべてのデータを含まなければなりません。
Hollenbeck Standards Track [Page 3] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[3ページ]。
with no data retained to be included in a later output payload. Flushing ensures that each compressed packet payload can be decompressed completely.
後の出力ペイロードに含まれるように保有されたデータなしで。 洗い流すのは、それぞれの圧縮されたパケットペイロードを完全に減圧できるのを確実にします。
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.
いくつかの圧縮方法には、パケットペイロードを圧縮して、減圧するとき状態/履歴情報を維持する能力があります。 圧縮歴史は、1パケットあたりの圧縮と比較されますが、パケットの向こう側の歴史が、パケットが異なったパケットに含まれたデータを完全に減圧するのに必要であるデータを含むかもしれないのを含意すると主張するとして、より高い圧縮比がストリームで達成されるのを許容します。 その結果、歴史メインテナンスは信頼できるリンクと配列されたパケット配信の両方を必要とします。 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:
RFC2246[2]のセクション7で説明されるように、TLSは、複数の接続が例示されるのをTLS Handshakeプロトコルの再開機能を通した同じセッションを使用することで許容します。 複数の圧縮方法がセッション中に使用に利用可能であるときに、セッション再開には、操作上の意味があります。 例えば、セッションが再開されるとき、圧縮状態がきれいにされないと、負荷分散装置は、追加州の情報を保守する必要があるでしょう。 セッションを再開するとき、その結果、以下の制限を観測しなければなりません:
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)
このドキュメントのセクション2はIANAによって維持される圧縮方法識別子の登録について説明します、DEFLATE圧縮方法のための識別子の課題を含んでいて。 範囲0-63(小数)から包括的な識別子値はRFC2434Standards Action[3]を通して割り当てられます。 範囲64-223からの値(小数)
Hollenbeck Standards Track [Page 4] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[4ページ]。
inclusive are assigned via RFC 2434 Specification Required [3]. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use [3].
包括的である、RFC2434Specification Required[3]を通して、割り当てられます。 224-255(小数)から包括的な識別子値はRFC2434兵士のUse[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によって宛てられた脅威モデルを変更するどんな話題も紹介しません。 また、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 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は全く対称的に暗号化されたデータの長さを隠しません。 他のものは、それをある程度隠しますが、まだ完全にそれは隠すというわけではありません。 例えば、詰め物なしでストリーム暗号暗号化を使用するciphersuitesが全く長さを隠しません。 詰め物によるCipher Block Chaining(CBC)暗号化を使用するciphersuitesが詰め物の量がどう選ばれているかによって、隠れる何らかの長さを提供します。 TLS圧縮SHOULDの使用は、圧縮されたデータの長さがオリジナルの解凍されたデータの長さより多くの情報を漏らすかもしれないのを考慮に入れます。
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で説明されるように、圧縮アルゴリズムは時折圧縮するよりむしろ入力データを広くすることができます。 この特徴は圧縮されるか、または減圧されると何らかの莫大なサイズに拡大する凶暴なデータを構成する能力を導入します。 RFC2246はこの種類の攻撃を改善するいくつかのメソッドを説明します。 まず最初に、圧縮はlosslessでなければなりません。 2番目に、限界(1,024バイト)は許容できる圧縮コンテンツの長さ増加の量に置かれます。 最終的に、限界(2^14バイト)は総コンテンツの長さに置かれます。 きわめて詳細な情報のための.2セクション6.2RFC2246[2]を見てください。
Hollenbeck Standards Track [Page 5] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[5ページ]。
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ワーキンググループメーリングリストで本書では説明された概念について議論しました。 作者はジェフリー・アルトマン、エリック・レスコラ、およびマークヴァンHeyningenによって提供されたその議論への貢献を承諾します。 このドキュメントに組み入れられた後の提案はティムDierks、パシEronen、ピーター・ガットマン、エルジンリー、ニコスMavroyanopoulos、Alexeyメリニコフ、ボーデメラー、Win Treese、および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] ブラドナー、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] 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問題部に書くためのガイドライン」BCP26、RFC2434(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]ロバの鳴き声、T.、パオリ、J.、Sperberg-マックィーン、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] ドイツ語、P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[6] Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
[6] ウッズ、J.、「pppはプロトコルに空気を抜く」RFC1979、1996年8月。
[7] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
December 1998.
[7] ペレイラ、R.、「IP有効搭載量圧縮使用は空気を抜く」RFC2394、1998年12月。
[8] Gutmann, P., "Compressed Data Content Type for Cryptographic
Message Syntax (CMS)", RFC 3274, June 2002.
[8] ガットマン、P.、「暗号のメッセージ構文(cm)のための圧縮されたデータcontent type」、RFC3274、2002年6月。
Hollenbeck Standards Track [Page 6] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[6ページ]。
Author's Address
作者のアドレス
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
スコットHollenbeckベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Hollenbeck Standards Track [Page 7] RFC 3749 TLS Compression Methods May 2004
Hollenbeck規格はTLS圧縮方法2004年5月にRFC3749を追跡します[7ページ]。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Standards Track [Page 8]
Hollenbeck標準化過程[8ページ]
一覧
スポンサーリンク
