Network Working Group G. Camarillo
Request for Comments: 3968 Ericsson
Updates: 3427 December 2004
BCP: 98
Category: Best Current Practice
The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for
the Session Initiation Protocol (SIP)
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry.
この文書では、セッション開始プロトコル（SIP）ヘッダフィールドパラメータおよびパラメータ値の番号機関（IANA）レジストリを割り当て、インターネットを作成します。また、このレジストリの初期エントリとして使用する既存のパラメータとパラメータ値を示します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4.1. Header Field Parameters Sub-Registry . . . . . . . . . . 3
4.2. Registration Policy for SIP Header Field Parameters. . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
RFC 3261 [3] allows new header field parameters and new parameter values to be defined. However, RFC 3261 omitted an IANA registry for them. This document creates such a registry.
RFC 3261 [3]新しいヘッダフィールドパラメータと新しいパラメータ値が定義されることを可能にします。ただし、RFC 3261には、彼らのためにIANAレジストリを省略しました。この文書では、このようなレジストリを作成します。
RFC 3427 [4] documents the process to extend SIP. This document updates RFC 3427 by specifying how to define and register new SIP header field parameters and parameter values.
RFC 3427 [4]はSIPを拡張するプロセスを文書化。新しいSIPヘッダフィールドパラメータとパラメータ値を定義し、登録する方法を指定することで、この文書の更新RFC 3427。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[1] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
SIP header field parameters and parameter values MUST be documented in an RFC in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter or parameter value. The intent of this requirement is to assure interoperability between independent implementations, and to prevent accidental namespace collisions between implementations of dissimilar features.
SIPヘッダフィールドパラメータおよびパラメータ値は、IANAによって登録されるためにRFCに文書化されなければなりません。このドキュメントは、完全な構文、使用目的、およびパラメータまたはパラメータ値の意味を説明しなければなりません。この要件の目的は、独立した実装間の相互運用性を確保するために、そして、異なる機能の実装間の偶発名前空間の衝突を防ぐためです。
Note that this registry, unlike other protocol registries, only deals with parameters and parameter values defined in RFCs (i.e., it lacks a vendor-extension tree). RFC 3427 [4] documents concerns with regards to new SIP extensions which may damage security, greatly increase the complexity of the protocol, or both. New parameters and parameter values need to be documented in RFCs as a result of these concerns.
このレジストリは、他のプロトコルレジストリとは異なり、唯一のRFC（すなわち、それはベンダ拡張ツリーを欠く）で定義されたパラメータとパラメータ値を扱うことに留意されたいです。 RFC 3427 [4]セキュリティを破損する恐れがあり、新たなSIPの拡張に関して持つドキュメントの問題が、大幅プロトコルの複雑さを増加させる、またはその両方。新しいパラメータおよびパラメータ値は、これらの懸念の結果としてRFCで文書化する必要があります。
RFCs defining SIP header field parameters or parameter values MUST register them with IANA as described below.
以下に説明するようにSIPヘッダフィールドパラメータまたはパラメータ値を規定するRFCはIANAに登録しなければなりません。
Registered SIP header field parameters and parameter values are to be considered "reserved words". In order to preserve interoperability, registered parameters and parameter values MUST be used in a manner consistent with that described in their defining RFC. Implementations MUST NOT utilize "private" or "locally defined" SIP header field parameters or parameter values that conflict with registered parameters.
登録されたSIPヘッダフィールドパラメータおよびパラメータ値は「予約語」と考えられるべきです。相互運用性を維持するために、登録されたパラメータおよびパラメータ値は、それらの定義RFCに記載されたものと一致した方法で使用されなければなりません。実装は、「プライベート」又は登録されたパラメータと競合する「局所的に定義された」SIPヘッダフィールドパラメータまたはパラメータ値を利用してはいけません。
Note that although unregistered SIP header field parameters and parameter values may be used in implementations, developers are cautioned that usage of such parameters is risky. New SIP header field parameters and parameter values may be registered at any time, and there is no assurance that these new registered parameters or parameter values will not conflict with unregistered parameters currently in use.
未登録のSIPヘッダフィールドパラメータおよびパラメータ値は実装に使用することができるが、開発者はそのようなパラメーターの使用が危険であることを警告されることに留意されたいです。新しいSIPヘッダフィールドパラメータおよびパラメータ値はいつでも登録することができ、これらの新規登録されたパラメータまたはパラメータ値は現在使用されている未登録のパラメータと競合しないという保証はありません。
Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry.
いくつかのSIPヘッダフィールドパラメータは、事前に定義されたパラメータ値のセットを受け入れます。例えば、使用中のトランスポートプロトコルを示すパラメータは、唯一の有効な値としてあらかじめ定義されたトークンのTCP、UDP、およびSCTPを受け入れることができます。このタイプのすべてのSIPヘッダフィールドパラメータのすべてのパラメータ値を登録するsubregistriesの多数を必要とするであろう。代わりに、我々は、参照することにより、パラメータ値を登録することを選択しました。つまり、所定のヘッダフィールドパラメータのパラメータレジストリ内のエントリは、パラメータの新しい値を定義するRFCへの参照を含みます。パラメータ値を定義するRFCへの参照は、レジストリ内の二重括弧内に表示されます。
So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references.
だから、ヘッダフィールドパラメータレジストリは、各パラメータのみ定義済みの値のセットを受け入れるか否かを示す列を含みます。その列の「はい」とパラメータの実装は、リファレンスとして提供するRFCのすべての有効なパラメータ値を見つける必要があります。
Section 27 of RFC 3261 [3] creates an IANA registry for method names, header field names, warning codes, status codes, and option tags. This specification creates a new sub-registry for header field parameters under the SIP Parameters registry.
RFC 3261のセクション27 [3]メソッド名、ヘッダフィールド名、警告コード、ステータスコード、およびオプションタグのIANAレジストリを作成します。この仕様は、SIPパラメータレジストリ下ヘッダフィールドパラメータの新しいサブレジストリを作成します。
The majority of the SIP header fields can be extended by defining new parameters. New SIP header field parameters are registered by the IANA. When registering a new parameter for a header field or a new value for a parameter, the following information MUST be provided.
SIPヘッダフィールドの大部分は、新しいパラメータを定義することによって拡張することができます。新しいSIPヘッダフィールドパラメータは、IANAによって登録されています。ヘッダーフィールドのための新しいパラメータまたはパラメータの新しい値を登録する場合、次の情報が提供されなければなりません。
o Header field in which the parameter can appear.
Oヘッダフィールドとは、パラメータが表示されます。
o Name of the header field parameter being registered.
Oヘッダフィールドパラメータの名前が登録されています。
o Whether the parameter only accepts a set of predefined values.
パラメータは事前に定義された値のセットを受け入れるかどうか、O。
o A reference to the RFC where the parameter is defined and to any RFC that defines new values for the parameter. References to RFCs defining parameter values appear in double brackets in the registry.
パラメータが定義されているRFCに、パラメータの新しい値を定義する任意のRFCを参照O。パラメータ値を定義するRFCへの参照は、レジストリ内の二重括弧内に表示されます。
Parameters that can appear in different header fields MAY have the same name. However, parameters that can appear in the same header field MUST have different names.
別のヘッダフィールドに現れることができるパラメータは、同じ名前を持っているかもしれません。しかし、同じヘッダフィールドに現れることができるパラメータは、異なる名前を持たなければなりません。
The following are the initial values for this sub-registry.
以下は、このサブレジストリの初期値です。
Header Field Parameter Name Predefined Reference
Values
_____________________________________________________________________
Accept q No [RFC 3261]
Accept-Encoding q No [RFC 3261]
Accept-Language q No [RFC 3261]
Authorization algorithm Yes [RFC 3261]
[[RFC 3310]]
Authorization auts No [RFC 3310]
Authorization cnonce No [RFC 3261]
Authorization nc No [RFC 3261]
Authorization nonce No [RFC 3261]
Authorization opaque No [RFC 3261]
Authorization qop Yes [RFC 3261]
Authorization realm No [RFC 3261]
Authorization response No [RFC 3261]
Authorization uri No [RFC 3261]
Authorization username No [RFC 3261]
Authentication-Info cnonce No [RFC 3261]
Authentication-Info nc No [RFC 3261]
Authentication-Info nextnonce No [RFC 3261]
Authentication-Info qop Yes [RFC 3261]
Authentication-Info rspauth No [RFC 3261]
Call-Info purpose Yes [RFC 3261]
Contact expires No [RFC 3261]
Contact q No [RFC 3261]
Content-Disposition handling Yes [RFC 3261]
Event id No [RFC 3265]
From tag No [RFC 3261]
P-Access-Network-Info cgi-3gpp No [RFC 3455]
P-Access-Network-Info utran-cell-id-3gpp No [RFC 3455]
P-Charging-Function-Addresses ccf No [RFC 3455]
P-Charging-Function-Addresses ecf No [RFC 3455]
P-Charging-Vector icid-value No [RFC 3455]
P-Charging-Vector icid-generated-at No [RFC 3455]
P-Charging-Vector orig-ioi No [RFC 3455]
P-Charging-Vector term-ioi No [RFC 3455]
P-DCS-Billing-Info called No [RFC 3603] P-DCS-Billing-Info calling No [RFC 3603] P-DCS-Billing-Info charge No [RFC 3603] P-DCS-Billing-Info locroute No [RFC 3603] P-DCS-Billing-Info rksgroup No [RFC 3603] P-DCS-Billing-Info routing No [RFC 3603] P-DCS-LAES content No [RFC 3603] P-DCS-LAES key No [RFC 3603] P-DCS-Redirect count No [RFC 3603] P-DCS-Redirect redirector-uri No [RFC 3603] Proxy-Authenticate algorithm Yes [RFC 3261] [[RFC 3310]] Proxy-Authenticate domain No [RFC 3261] Proxy-Authenticate nonce No [RFC 3261] Proxy-Authenticate opaque No [RFC 3261] Proxy-Authenticate qop Yes [RFC 3261] Proxy-Authenticate realm No [RFC 3261] Proxy-Authenticate stale Yes [RFC 3261] Proxy-Authorization algorithm Yes [RFC 3261] [[RFC 3310]] Proxy-Authorization auts No [RFC 3310] Proxy-Authorization cnonce No [RFC 3261] Proxy-Authorization nc No [RFC 3261] Proxy-Authorization nonce No [RFC 3261] Proxy-Authorization opaque No [RFC 3261] Proxy-Authorization qop Yes [RFC 3261] Proxy-Authorization realm No [RFC 3261] Proxy-Authorization response No [RFC 3261] Proxy-Authorization uri No [RFC 3261] Proxy-Authorization username No [RFC 3261] Reason cause Yes [RFC 3326] Reason text No [RFC 3326] Retry-After duration No [RFC 3261] Security-Client alg Yes [RFC 3329] Security-Client ealg Yes [RFC 3329] Security-Client d-alg Yes [RFC 3329] Security-Client d-qop Yes [RFC 3329] Security-Client d-ver No [RFC 3329] Security-Client mod Yes [RFC 3329] Security-Client port1 No [RFC 3329] Security-Client port2 No [RFC 3329] Security-Client prot Yes [RFC 3329] Security-Client q No [RFC 3329] Security-Client spi No [RFC 3329] Security-Server alg Yes [RFC 3329] Security-Server ealg Yes [RFC 3329] Security-Server d-alg Yes [RFC 3329] Security-Server d-qop Yes [RFC 3329]
P-DCS-課金-情報なし[RFC 3603] P-DCS-課金-情報はありませんを呼び出し、[RFC 3603] P-DCS-課金-情報はありません[RFC 3603] P-DCS-課金-情報はなし[RFCをlocrouteない充電しないと呼ばれます3603 NO [RFC 3603] P-DCS-LAESコンテンツなし[RFC 3603] P-DCS-LAESキーなし[RFC 3603]をルーティングしない] P-DCS-BILLING-INFO rksgroupなし[RFC 3603] P-DCS-BILLING-INFO P-DCS-リダイレクトなし[RFC 3603] P-DCS-リダイレクトリダイレクタ-URIません[RFC 3603]プロキシ認証アルゴリズムはい[RFC 3261] [[RFC 3310]プロキシ認証ドメインはありません[RFC 3261] Proxy-をカウントしませんナンスなし[RFC 3261]プロキシ認証不透明なし[RFC 3261]プロキシ認証QOPはい[RFC 3261]プロキシ認証レルムなし[RFC 3261]プロキシ認証失効はい[RFC 3261]プロキシ認証アルゴリズムはい[RFCを認証3261] [RFC 3310]プロキシ認証AUTSなし[RFC 3310]プロキシ認証cnonceなし[RFC 3261]プロキシ認証NCなし[RFC 3261]プロキシ認証ナンスなし[RFC 3261]プロキシ許可[いいえ不透明RFC 3261]プロキシ認証QOPはい[RFC 3261]プロキシ認証レルムいいえ[RFC 3261]プロキシ認証応答なし[RFC 3261]プロキシ認証URIません[RFC 3261]プロキシ認証のユーザ名はありません[RFC 3261]理由原因はい[RFC 3326]理由テキストはありません[RFCない3326]リトライした後の期間いいえ[RFC 3261]セキュリティクライアントALGはい[RFC 3329]セキュリティクライアントealgはい[RFC 3329]セキュリティクライアントD-ALGはい[RFC 3329]セキュリティクライアントD-QOPはい[RFC 3329]セキュリティクライアントなかっD-ノー版[RFC 3329]セキュリティクライアントMODはい[RFC 3329]セキュリティクライアントなし[RFC 3329]セキュリティクライアントのポート2はありません[RFC 3329]セキュリティクライアントのprotはい[RFC 3329]セキュリティクライアントのQません[RFC 3329をPORT1ありません]セキュリティクライアントのSPIはありません[RFC 3329]セキュリティ、サーバはいALG [RFC 3329]セキュリティ、サーバealgはい[RFC 3329]セキュリティ・サーバD-ALGはい[RFC 3329]セキュリティ・サーバD-QOPはい[RFC 3329]
Security-Server d-ver No [RFC 3329] Security-Server mod Yes [RFC 3329] Security-Server port1 No [RFC 3329] Security-Server port2 No [RFC 3329] Security-Server prot Yes [RFC 3329] Security-Server q No [RFC 3329] Security-Server spi No [RFC 3329] Security-Verify alg Yes [RFC 3329] Security-Verify ealg Yes [RFC 3329] Security-Verify d-alg Yes [RFC 3329] Security-Verify d-qop Yes [RFC 3329] Security-Verify d-ver No [RFC 3329] Security-Verify mod Yes [RFC 3329] Security-Verify port1 No [RFC 3329] Security-Verify port2 No [RFC 3329] Security-Verify prot Yes [RFC 3329] Security-Verify q No [RFC 3329] Security-Verify spi No [RFC 3329] Subscription-State expires No [RFC 3265] Subscription-State reason Yes [RFC 3265] Subscription-State retry-after No [RFC 3265] To tag No [RFC 3261] Via branch No [RFC 3261] Via comp Yes [RFC 3486] Via maddr No [RFC 3261] Via received No [RFC 3261] Via rport No [RFC 3581] Via ttl No [RFC 3261] WWW-Authenticate algorithm Yes [RFC 3261] [[RFC 3310]] WWW-Authenticate domain Yes [RFC 3261] WWW-Authenticate nonce No [RFC 3261] WWW-Authenticate opaque No [RFC 3261] WWW-Authenticate qop Yes [RFC 3261] WWW-Authenticate realm No [RFC 3261] WWW-Authenticate stale Yes [RFC 3261]
セキュリティ・サーバD-VERません[RFC 3329]セキュリティ、サーバーMODはい[RFC 3329]セキュリティ、サーバポート1はありません[RFC 3329]セキュリティ、サーバポート2なし[RFC 3329]セキュリティ・サーバPROTはい[RFC 3329]セキュリティ、サーバQません[RFC 3329]セキュリティ・サーバのSPIはありません[RFC 3329]セキュリティ-確認しALGはい[RFC 3329]セキュリティ-確認しealgはい[RFC 3329]セキュリティを確認し、D-ALGはい[RFC 3329]セキュリティを確認し、D-QOPはい[RFC 3329]セキュリティを確認D-VERません[RFC 3329]セキュリティ-確認しモッズはい[RFC 3329]セキュリティ-確認しポート1はありません[RFC 3329]セキュリティ-確認しport2の番号[RFC 3329]セキュリティ-確認しPROTはい[RFC 3329]セキュリティを確認Qません[RFC 3329]セキュリティを確認し、SPIはありません[RFC 3329]サブスクリ-状態なし[RFC 3265]のサブスクリプション・ステートの理由はい[RFC 3265]のサブスクリプション・ステートリトライ-後にありません[RFC 3265]には有効期限が切れていませんコンプ経由枝ません[RFC 3261]のViaタグはありません[RFC 3261]ははい、[RFC 3486] MADDRません経由[RFC 3261] VIAはTTLません[RFC 3261] WWW-経由ません[RFC 3581] RPORT経由ん[RFC 3261]を受信していませんアルゴリズムはい[RFC 3261] [[RFC 3310]] WWW認証を認証ドメインはい[RFC 3261] WWW認証ナンスません[RFC 3261] WWW認証不透明ません[RFC 3261] WWW認証QOPはい[RFC 3261] WWW認証分野ません[RFC 3261] WWW認証古いはい[RFC 3261 ]
As per the terminology in RFC 2434 [2], the registration policy for SIP header field parameters and parameter values shall be "IETF Consensus."
RFC 2434における用語に従って、[2]、SIPヘッダフィールドパラメータおよびパラメータ値の登録ポリシーが「IETFコンセンサス」でなければなりません
For the purposes of this registry, the parameter or the parameter value for which IANA registration is requested MUST be defined by an RFC. There is no requirement that this RFC be standards-track.
このレジストリの目的のために、パラメータまたはIANA登録が要求されたパラメータ値は、RFCによって定義されなければなりません。このRFCは標準トラックである必要はありません。
The registry in this document does not in itself have security considerations. However, as mentioned in RFC 3427, an important reason for the IETF to manage the extensions of SIP is to ensure that all extensions and parameters are able to provide secure usage. The supporting RFC publications for parameter registrations described this specification MUST provide detailed security considerations for them.
この文書に記載されているレジストリは、それ自体ではセキュリティ上の配慮を持っていません。 RFC 3427で述べたようにしかし、IETFはSIPの拡張を管理するための重要な理由は、すべての拡張機能やパラメータは、安全な使用方法を提供することが可能であることを確認することです。パラメータの登録のためのサポートRFCの出版物は、この仕様は、彼らのために、詳細なセキュリティ上の考慮事項を提供しなければならない説明しました。
Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule, and Allison Mankin provided useful comments on this document.
ジョナサン・ローゼンバーグ、ヘニングSchulzrinneと、ローハンマーイ、ディーンウィリス、アキニエミ、ビル・マーシャル、ミゲルA.ガルシア・マーティン、ジャン・フランソワラバ、およびアリソンマンキンはこのドキュメントの役に立つコメントを提供しました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[4]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
Author's Address
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。