Network Working Group J. Peterson
Request for Comments: 3764 NeuStar
Category: Standards Track April 2004
enumservice registration for Session Initiation Protocol (SIP)
Addresses-of-Record
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM.
この文書は、RFC 3761のガイドラインに基づき、セッション開始プロトコル（SIP）のための電子数（ENUM）サービスを登録する具体的には、この文書では、ENUMにSIPアドレス・オブ・レコードをプロビジョニングに焦点を当てています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ENUM Service Registration . . . . . . . . . . . . . . . . . . . 2
3. Addresses-of-record in SIP. . . . . . . . . . . . . . . . . . . 3
4. The 'E2U+SIP' enumservice . . . . . . . . . . . . . . . . . . . 5
5. Example of E2U+SIP enumservice. . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References. . . . . . . . . . . . . . . . . . . 6
8.2. Informative References. . . . . . . . . . . . . . . . . . 7
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 7
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
ENUM (E.164 Number Mapping, RFC 2916 [6]) is a system that uses DNS (Domain Name Service, STD 13, RFC 1034 [3]) to translate telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC 2396 [4]), like 'sip:egar@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. This document applies to the revised version of ENUM described in RFC 3761.
ENUM（E.164番号マッピングは、RFC 2916 [6]）DNS（ドメインネームサービス、STD 13、RFC 1034 [3]）のURIに、 '12025332600' のように、電話番号を変換する（ユニフォーム・リソースを使用するシステムであります識別子、RFC 2396 [4]）、 'SIP：egar@example.com' など。 ENUMは、ルート取引にURIを使用するものとの電話番号に依存しているシステムの相互接続を容易にするために、主に存在しています。この文書は、RFC 3761に記述さENUMの改訂版に適用されます。
SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based application protocol that allows endpoints on the Internet to discover one another in order to exchange context information about a session they would like to share. Common forms of communication that are set up by SIP include Internet telephony, instant messaging, video, Internet gaming and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously. SIP is a protocol that finds the best way for parties to communicate.
SIP（セッション開始プロトコル、RFC 3261 [2]）は、インターネット上のエンドポイントは、それらが共有したいセッションに関するコンテキスト情報を交換するために互いに発見することを可能にするテキストベースのアプリケーションプロトコルです。 SIPによって設定された通信の一般的な形態は、インターネット電話、インスタントメッセージング、ビデオ、インターネットゲームとリアルタイムコミュニケーションの他の形態を含みます。 SIPは、同時にリアルタイム通信の異なる形態を含むセッションを開始することができるマルチサービスプロトコルです。 SIPは、当事者が通信するための最善の方法を見つけるのプロトコルです。
As defined in [1], the following is a template covering information needed for the registration of the enumservice specified in this document.
[1]で定義されるように、以下では、この文書で指定enumserviceの登録に必要な情報を覆うテンプレートです。
Enumservice Name: "E2U+SIP"
Enumservice名： "E2U + SIP"
Type(s): "SIP"
タイプ（S）： "SIP"
Subtype(s): N/A
サブタイプ（複数可）：N / A
URI Scheme(s): "sip:", "sips:"
URIスキーム（S）： "SIP：" は、 "すすります"
Functional Specification: see Section 4
機能仕様：第4章を参照してください
Security considerations: see Section 6
セキュリティの考慮事項：第6節を参照してください
Intended usage: COMMON
意図している用法：COMMON
Author: Jon Peterson (jon.peterson@neustar.biz)
著者：ジョン・ピーターソン（jon.peterson@neustar.biz）
Any other information that the author deems interesting: See Section 3
著者は面白いと考えるその他の情報：第3節を参照してください。
This document specifies an enumservice field that is appropriate for SIP addresses-of-record URIs. Various other types of URIs can be present in SIP requests. A URI that is associated with a particular SIP user agent (for example, a SIP phone) is commonly known as a SIP contact address.
この文書では、SIPアドレス・オブ・レコードのURIのために適切であるenumserviceフィールドを指定します。 URIの様々な他のタイプは、SIP要求中に存在することができます。特定のSIPユーザエージェントに関連付けられているURI（例えば、SIP電話機）は、一般的に、SIP連絡先アドレスとして知られています。
The difference between a contact address and an address-of-record is like the difference between a device and its user. While there is no formal distinction in the syntax of these two forms of addresses, contact addresses are associated with a particular device, and may have a very device-specific form (like sip:10.0.0.1, or sip:edgar@ua21.example.com). An address-of-record, however, represents an identity of the user, generally a long-term identity, and it does not have a dependency on any device; users can move between devices or even be associated with multiple devices at one time while retaining the same address-of-record. A simple URI, generally of the form 'sip:egdar@example.com', is used for an address-of-record.
連絡先アドレスとアドレスのレコードとの間の差は、デバイスとそのユーザとの間の差のようなものです。アドレスのこれら二つの形態のシンタックスには、正式な区別はないが、連絡先は、特定のデバイスに関連付けられており、SIPのような（非常にデバイス固有の形状を有することができる：10.0.0.1、またはSIP：edgar@ua21.exampleを.COM）。アドレス・オブ・レコードは、しかし、長期的なアイデンティティ、一般的に、ユーザーのIDを表し、それは任意のデバイス上の依存関係を持っていません。ユーザーがデバイス間で移動することができ、または同じアドレスのレコードを保持したままでも、一度に複数のデバイスに関連付けられていること。シンプルなURIは、一般的にフォームの一口：egdar@example.com 'は、アドレス・オブ・レコードのために使用されています。
When a SIP request is created by a user agent, it populates the address-of-record of its target in its To header field and (generally) Request-URI. The address-of-record of the user that is sending the request populates the From header field of the message; the contact address of the device from which the request is sent is listed in the Contact header field.
SIP要求は、ユーザエージェントによって作成されたとき、それはアドレスのレコードのフィールドをヘッダと（通常）のRequest-URIにその標的のを移入します。アドレス・オブ・レコード要求を送信しているユーザのメッセージのヘッダフィールドから移入します。要求が送信されたデバイスの連絡先は、連絡先ヘッダフィールドに記載されています。
By sending a registration to a registrar on behalf of its user, a SIP device (i.e., a user agent) can temporarily associate its own contact address with the user's address-of-record. In so doing, the device becomes eligible to receive requests that are sent to the address-of-record. Upon receiving the registration request, the registrar modifies the provisioning data in a SIP location service to create a mapping between the address-of-record for the user and the device where the user can currently be reached. When future requests arrive at the administrative domain of this location service for the user in question, proxy servers ask the location service where to find the user, and will in turn discover the registered contact address(es). A SIP-based follow-me telephony service, for example, would rely on this real-time availability data in order to find the best place to reach the end user without having to cycle through numerous devices from which the user is not currently registered. Note that addresses-of-record can be registered with other addresses-of-record; for example, while at home, a user might elect to register the address-of-record they use as their personal identity under their work address-of-record in order to direct requests for their work identity to whatever devices they might have associated with their home address-of-record.
そのユーザのためにレジストラへの登録を送信することによって、SIPデバイス（すなわち、ユーザエージェント）は、一時的にユーザのアドレス・オブ・レコードと、自身のコンタクトアドレスを関連付けることができます。そうすることで、デバイスは、アドレスのレコードに送信されたリクエストを受けることになります。登録要求を受信すると、レジストラは、ユーザが現在到達可能なユーザ及びデバイスのアドレス・オブ・レコードとの間のマッピングを作成するために、SIPロケーション・サービスでプロビジョニングデータを修正します。今後の要求が問題のユーザーのために、この場所のサービスの管理ドメインに到着すると、プロキシサーバはどこのユーザーを見つけるためにロケーションサービスを依頼し、順番に登録した連絡先アドレスを発見するでしょう。 SIPベースのフォローミー電話サービスは、例えば、ユーザが現在登録されていないから、多数のデバイスを循環することなく、エンドユーザーに到達するのに最適な場所を見つけるために、このリアルタイムの利用可能性データに依存しています。アドレス・オブ・レコードの注意は他のアドレス・オブ・レコードに登録することができます。例えば、自宅でいる間、ユーザーは、彼らが関連しているかもしれないどんなデバイスに自分の仕事のアイデンティティのために直接リクエストするために、自分の仕事のアドレスのレコードの下で彼らの個人的なIDとして使用し、アドレスのレコードを登録することを選ぶかもしれません自宅の住所-のレコード。
When a SIP entity (be it a user agent or proxy server) needs to make a forwarding decision for a Request-URI containing an address-of-record, it uses the mechanisms described in the SIP specification (RFC 3263) to locate the proper resource in the network. Ordinarily, this entails resolving the domain portion of the URI (example.com in the example above) in order to route the call to a proxy server that is responsible for that domain.
SIPエンティティは（そのユーザエージェントまたはプロキシ・サーバである）のRequest-URIアドレスのレコードを収容するための転送決定を行う必要がある場合、それは適切に配置するためにSIP仕様（RFC 3263）に記載されたメカニズムを使用しネットワーク内のリソース。通常、これは、そのドメインの原因であるプロキシサーバにコールをルーティングするために、（上記の例ではexample.com）URIのドメイン部分を解決することを伴います。
SIP user agents have specific communications capabilities (such as the ability to initiate voice communications with particular codecs, or support for particular SIP protocol extensions). Because an address-of-record does not represent any particular device or set of devices, an address-of-record does not have capabilities as such. When a SIP user agent sends a request to an address-of-record, it begins a phase of capability negotiation that will eventually discover the best way for the originator to communicate with the target. The originating user agent first expresses capabilities of its own in the request it sends (and preferences for the type of session it would like to initiate). The expression of these capabilities may entail the usage of SDP [8] to list acceptable types of media supported and favored by the client, the inclusion of Required/Supported headers to negotiate compatibility of extensions, and possibly the usage of optional SIP extensions, for example using callee capabilities [7] to communicate request handling dispositions. Proxy servers or endpoints subsequently return responses that allow a rich bidirectional capability negotiation process.
SIPユーザエージェントは、（例えば、特定のコーデックで音声通信を開始する能力、または特定のSIPプロトコル拡張のサポートなど）は、特定の通信機能を有しています。アドレス・オブ・レコードは、任意の特定のデバイスを表すか、デバイスの設定されないので、アドレス・オブ・レコードは、次のような機能を持っていません。 SIPユーザエージェントは、アドレス・オブ・レコードにリクエストを送信すると、それは最終的に発信元がターゲットと通信するための最良の方法を発見する能力交渉のフェーズを開始します。発信ユーザエージェントは、まず、送信するリクエスト（およびそれを開始したいセッションのタイプの環境）で、独自の能力を表現します。これらの機能の発現SDPの使用を伴うことができる[8]メディアの許容されるタイプをリストするがために、拡張機能の互換性、および任意のSIP拡張の可能性の使用を交渉するために必要な/サポートされているヘッダを含めることをサポートし、クライアントによって好ま[7]要求処理処分を通信する着信機能を用いた例。プロキシサーバーまたはエンドポイントはその後、豊かな双方向機能ネゴシエーションプロセスを許可する応答を返します。
The process by which SIP endpoints negotiate capabilities can overlap with the primary service provided by NAPTR records: permitting the originating client to select a particular URI for communications based on an ordered list of enumservices. However, ENUM's capability management mechanism is decidedly one-way - the administrator of the telephone number expresses capabilities (in the form of protocol names) and preferences that the client must evaluate without negotiation. Moreover, listing available protocols is not comparable to agreement on session media (down to the codec/interval level) and protocol extension support - it would be difficult to express, in the level of detail necessary to arrange a desired session, the capabilities of a SIP device within a NAPTR service field. Provisioning contact addresses in ENUM rather than addresses-of-record would compromise the SIP capability negotiation and discovery process. Much of the benefit of using a URI comes from the fact that it represents a logical service associated with a user, rather than a device - indeed, if ENUM wished to target particular devices, 'E2IPv4' would be a more appropriate resolution service to define than 'E2U'.
enumservicesの順序付けられたリストに基づいて、通信のために特定のURIを選択するために、元のクライアントを許可する：SIPエンドポイントは、機能がNAPTRレコードによって提供されるプライマリサービスと重複することができる交渉するプロセス。しかし、ENUMの能力管理メカニズムは明らかに一方通行である - 電話番号の管理者は、クライアントは交渉せずに評価しなければならない（プロトコル名の形で）能力や好みを表現しています。また、利用可能なプロトコルのリスト、セッションメディア（コーデック/インターバルレベルまで）およびプロトコル拡張のサポートに契約と同等ではない - 所望のセッションを配置する必要が詳細レベルでの機能を発現することが困難ですNAPTRサービスフィールド内のSIPデバイス。 ENUMに連絡先をプロビジョニングするのではなくアドレス・オブ・レコードはSIP機能ネゴシエーションおよび検出プロセスを危うくします。 ENUMは、特定のデバイスをターゲットにすることを望んだ場合には確かに、「E2IPv4は」を定義するために、より適切な解決サービスだろう - URIを使用する利点の多くは、それがユーザーに関連付けられた論理サービスではなく、デバイスを表しているという事実から来ています'E2U' より。
SIP addresses-of-record may use the SIP URI scheme or the SIPS URI scheme. The SIPS URI scheme, when used in an address-of-record, indicates that the user it represents can only be reached over a secure connection (using TLS).
SIPアドレス・オブ・レコードはSIP URIスキームまたはSIPS URIスキームを使用することができます。 SIPS URIスキームは、アドレスのレコードで使用される場合、それが表すユーザのみ（TLSを使用して）セキュア接続を介して到達することができることを示しています。
Traditionally, the services field of a NAPTR record (as defined in [5]) contains a string that is composed of two subfields: a 'protocol' subfield and a 'resolution service' subfield. ENUM in particular defines an 'E2U' (E.164 to URI) resolution service. This document defines an 'E2U+SIP' enumservice for SIP.
「プロトコル」サブフィールドと「解決サービス」サブフィールド：伝統的に、NAPTRレコードのサービスフィールド（[5]で定義されるように）2つのサブフィールドで構成されている文字列を含みます。特にENUMは解決サービス「E2U」（URIにE.164）を定義します。この文書では、SIPのための 'E2U + SIP' enumserviceを定義します。
The scheme of the URI that will appear in the regexp field of a NAPTR record using the 'E2U+SIP' enumservice may either be 'SIP' or 'SIPS'. This enumservice is best suited to SIP addresses-of-record.
「E2U + SIP」enumserviceを使用NAPTRレコードの正規表現のフィールドに表示されるURIのスキームは、いずれかの「SIP」または「SIPS」であってもよいです。このenumserviceは、SIPアドレス・オブ・レコードに最適です。
When a SIP address-of-record appears in the regexp field of a NAPTR record, there is no need to further qualify the enumservice field with any capability data, since addresses-of-record do not have capabilities.
SIPアドレス・オブ・レコードがNAPTRレコードの正規表現]フィールドに表示された場合のアドレス・オブ・レコードは能力を持っていないので、さらに任意の能力データでenumserviceフィールドを修飾する必要は、ありません。
There is also generally no need to have more than one NAPTR record under a single telephone number that points to a SIP address-of-record.
SIPアドレスのレコードを指す単一の電話番号で複数のNAPTRレコードを持ってする必要は一般的にもありません。
Note that the user portion of a SIP URI may contain a telephone number (e.g., 'sip:+1442079460148@example.com'). Clients should be careful to avoid infinite loops when recursively performing ENUM queries on URIs that result from an ENUM lookup.
SIP URIのユーザ部分は、電話番号（例えば、「：+1442079460148@example.com SIP」）を含んでいてもよいことに留意されたいです。クライアントは、再帰的にENUMの検索に起因するURIのENUMクエリーを実行するときに無限ループを避けるために注意しなければなりません。
The following is an example of the use of the enumservice registered by this document in a NAPTR resource record.
以下は、NAPTRリソースレコードにこの文書によって登録enumserviceの使用例です。
$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:edgar@example.com!" .
$ ORIGINの8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa。 100 NAPTR 10に "U" "E2U +一口" "^ * $一口：！。！edgar@example.com！" 。
A SIP address-of-record is a canonical address by which a user is known - placing this address in ENUM is comparable to placing an email address or a similar URI in the DNS.
ENUMにこのアドレスがDNSに電子メールアドレスまたは類似のURIを置くことに匹敵する確定 - SIPアドレスのレコードは、ユーザを認識するための正規のアドレスです。
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public - which is a cause for some privacy considerations.
DNSは、それは質問者と共有するレコードに関する政策決定を下すことはありません。すべてのDNSレコードはすべての回で、すべての照会者に利用可能であると想定しなければなりません。いくつかのプライバシーの配慮のための原因である - ENUMレコードセット内で提供される情報は、したがって、一般に公開することを考慮しなければなりません。
Unlike a traditional telephone number, the resource identified by a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records. An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [9] to these, is provided in [1].
従来の電話番号とは異なり、SIP URIで識別されるリソースは、ユーザーが警告される前に、発信者が認証および承認のための暗号資格情報を提供することを必要とするかもしれません。この点で、SIPと協力してENUMは実際にENUMレコードの公共利用できるにもかかわらず、既存のPSTNよりも、不要な発信者からはるかに大きい保護を提供することができます。これらのDNSにENUMの依存性特定の脅威の分析、およびDNSSECの利用可能性[9]は、[1]に提供されます。
This document registers the 'E2U+SIP' enumservice under the enumservice registry described in the IANA considerations in RFC 3761. Details of the registration are given in Section 2.
このドキュメントは、登録の3761詳細は、セクション2に記載されているRFCでIANA問題で説明enumserviceレジストリの下にある「E2U + SIP」enumserviceを登録します。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom、P.及びM. Mealling、 "ユニフォームリソース識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、RFC 3761、2004年4月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年5月。
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[3] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[6] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[6] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[7] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Work in Progress.
[7]ローゼンバーグ、J.、Schulzrinneと、H.及びP. Kyzviatを、進行中の作業 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[8]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[9] R. Arends, et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress.
[9] R.アレンズ、ら、「DNSセキュリティ拡張のためのプロトコル変更」が進行中で働いています。
Thanks to Richard Shockey for comments on the initial draft of this document, and to Allison Mankin for valuable review comments.
貴重なレビューコメントについては、このドキュメントの最初の草案に対するコメントのためのリチャード・ショッキーのおかげで、とアリソンマンキンへ。
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
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）インターネット協会（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.
この文書とここに含まれている情報は、基礎と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 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.
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機能のための基金は現在、インターネット協会によって提供されます。