RFC 3764 - enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3764
タイトル : RFC 3764 - セッション開始プロトコル（SIP）アドレスの登録
翻訳編集 : 自動生成

[要約] RFC 3764は、SIPのアドレスレコードのためのenumservice登録に関する仕様です。その目的は、SIPアドレスを電話番号やその他の識別子に関連付けるための標準化と一貫性を提供することです。

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

セッション開始プロトコル（SIP）アドレスの登録

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

概要

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）の電子番号（列挙）サービスを登録します。具体的には、このドキュメントは、列挙の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

1. Introduction

1. はじめに

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]）を使用して、「12025332600」などの電話番号をuris（均一なリソース識別子に翻訳するシステムです。、RFC 2396 [4]）、「sip：egar@example.com」のような。列挙は、主に電話番号に依存するシステムの相互接続を促進するために存在します。このドキュメントは、RFC 3761で説明されている列挙の改訂版に適用されます。

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は、パーティーが通信するための最良の方法を見つけるプロトコルです。

2. ENUM Service Registration

2. 列挙サービス登録

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"

タイプ：「SIP」

Subtype(s): N/A

サブタイプ：n/a

      URI Scheme(s): "sip:", "sips:"

Functional Specification: see Section 4

機能仕様：セクション4を参照してください

Security considerations: see Section 6

セキュリティ上の考慮事項：セクション6を参照してください

Intended usage: COMMON

意図された使用法：共通

Author: Jon Peterson (jon.peterson@neustar.biz)

著者：Jon Peterson（jon.peterson@neustar.biz）

Any other information that the author deems interesting: See Section 3

著者が興味深いと思うその他の情報：セクション3を参照してください

3. Addresses-of-record in SIP

3. SIPのアドレスのレコード

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に適したEnumserviceフィールドを指定します。SIPリクエストには、他のさまざまな種類のURIが存在する可能性があります。特定のSIPユーザーエージェント（たとえば、SIP電話）に関連付けられているURIは、一般的に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.

連絡先アドレスとレコードアドレスの違いは、デバイスとそのユーザーの違いのようなものです。これらの2つのアドレスの構文に正式な区別はありませんが、連絡先アドレスは特定のデバイスに関連付けられており、非常にデバイス固有のフォームがある場合があります（SIP：10.0.0.1、またはSIP：edgar@ua21.exampleなど.com）。ただし、住所はユーザーのアイデンティティ、一般に長期的なアイデンティティを表し、どのデバイスにも依存していません。ユーザーは、同じ記録アドレスを保持しながら、デバイス間を移動したり、一度に複数のデバイスに関連付けたりすることもできます。一般的に「sip：egdar@example.com」という形式の単純なURIが、録音アドレスに使用されます。

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リクエストがユーザーエージェントによって作成されると、ヘッダーフィールドへのターゲットの録音アドレスと（一般的に）リクエスト-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ロケーションサービスのプロビジョニングデータを変更して、ユーザーとユーザーに現在到達できるデバイスのレコードアドレスのマッピングを作成します。将来のリクエストが問題のユーザーのためにこのロケーションサービスの管理ドメインに到着すると、プロキシサーバーはロケーションサービスにユーザーを見つける場所を尋ね、登録された連絡先アドレス（ES）を発見します。たとえば、SIPベースのFollow-MEテレフォニーサービスは、このリアルタイムの可用性データに依存して、ユーザーが現在登録されていない多数のデバイスをサイクリングすることなく、エンドユーザーに到達するのに最適な場所を見つけます。アドレスは、他のrecordアドレスに登録できることに注意してください。たとえば、自宅にいる間、ユーザーは、作業のアイデンティティのリクエストを、関連するデバイスに要求するために、作業住所の下で個人のアイデンティティとして使用する記録アドレスを登録することを選択する場合があります。彼らの家の住所。

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エンティティ（ユーザーエージェントまたはプロキシサーバーであるか）が、レコードアドレスを含むリクエストURIの転送決定を行う必要がある場合、SIP仕様（RFC 3263）で説明されているメカニズムを使用して適切なものを見つけます。ネットワーク内のリソース。通常、これには、そのドメインを担当するプロキシサーバーにコールをルーティングするために、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プロトコル拡張のサポートなど）。録音アドレスは特定のデバイスまたはデバイスのセットを表していないため、recordのアドレスには機能がありません。SIPユーザーエージェントがリクエストをレコードアドレスに送信すると、最終的にオリジネーターがターゲットと通信するための最良の方法を発見する能力交渉の段階を開始します。発信元のユーザーエージェントは、最初に送信するリクエスト（および開始したいセッションの種類に対する設定）で独自の機能を表現します。これらの機能の表現は、SDP [8]の使用を必要とする可能性があります。クライアントがサポートおよび支持する許容可能なタイプのメディア、拡張の互換性を交渉するために必要/サポートされているヘッダーを含めること、および場合によってはオプションのSIP拡張機能の使用が必要です。Callee機能[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'.

SIPエンドポイントが機能をネゴシエートするプロセスは、NAPTRレコードが提供するプライマリサービスと重複することができます。エナムサービスの順序付けられたリストに基づいて、発信元のクライアントが特定のURIを選択することを許可します。ただし、Enumの能力管理メカニズムは明らかに一方通行です - 電話番号の管理者は、クライアントが交渉なしで評価しなければならない機能（プロトコル名の形式）と好みを表します。さらに、利用可能なプロトコルのリストは、セッションメディア（コーデック/インターバルレベルまで）およびプロトコル拡張サポートの合意に匹敵しません。目的のセッションを手配するために必要な詳細レベルで、NAPTRサービスフィールド内のSIPデバイス。レコードアドレスではなく、列挙の連絡先アドレスをプロビジョニングすると、SIP機能の交渉と発見プロセスが損なわれます。URIを使用することの利点の多くは、デバイスではなくユーザーに関連付けられた論理サービスを表しているという事実に由来しています。実際、酵素が特定のデバイスをターゲットにしたい場合、「E2IPV4」はより適切な解像度サービスになります。「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アドレス-of-Recordは、SIP URIスキームまたはSIPS URIスキームを使用する場合があります。SIPS URIスキームは、録音アドレスで使用される場合、それが表すユーザーが安全な接続（TLSを使用）でのみ到達できることを示します。

4. The 'E2U+SIP' enumservice

4. 「E2U SIP」Enumservice

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つのサブフィールドで構成される文字列が含まれています：「プロトコル」サブフィールドと「解像度サービス」サブフィールド。特に列挙は、「E2U」（E.164からURI）解像度サービスを定義します。このドキュメントでは、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レコードのRegexpフィールドに表示されるURIのスキームは、「SIP」または「SIP」のいずれかです。このEnumserviceは、Resordes of-Recordを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.

NAPTRレコードのREGEXPフィールドにSIPアドレスが表示される場合、recordのアドレスには機能がないため、任意の機能データをさらに適格にする必要はありません。

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.

また、通常、単一の電話番号の下に複数の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のユーザー部分には、電話番号（ 'SIP：1442079460148@example.com'）が含まれている場合があることに注意してください。クライアントは、Enumの検索に起因するURIで列挙クエリを再帰的に実行する場合、無限ループを避けるように注意する必要があります。

5. Example of E2U+SIP enumservice

5. E2U SIP Enumserviceの例

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.4.9.7.0.2.4.4.E164.Arpa。in naptr 10 100 "u" "e2u sip" "！^。*$！sip：edgar@example.com！"。

6. Security Considerations

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

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.

SIPアドレスの録音は、ユーザーが既知の標準的なアドレスです。このアドレスを列挙に配置することは、DNSに電子メールアドレスまたは同様のURIを配置することに匹敵します。

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は、Inquirerと共有する記録について政策決定を下しません。すべての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と協調して、列挙記録が公開されているにもかかわらず、実際には既存のPSTNよりも不要な発信者からはるかに大きな保護を提供できます。DNSへの酵素の依存性に固有の脅威の分析、およびこれらへのDNSSEC [9]の適用可能性は[1]に提供されています。

7. IANA Considerations

7. IANAの考慮事項

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.

このドキュメントは、RFC 3761のIANAに関する考慮事項で説明されているEnumserviceレジストリの下で「E2U SIP」Enumserviceを登録します。登録の詳細はセクション2に記載されています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[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。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。

8.2. Informative References

8.2. 参考引用

[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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzviat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、進行中の作業。

[8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[8] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。

[9] R. Arends, et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress.

[9] R. Arends、et al。、「DNSセキュリティエクステンションのプロトコル変更」、進行中の作業。

9. Acknowledgements

9. 謝辞

Thanks to Richard Shockey for comments on the initial draft of this document, and to Allison Mankin for valuable review comments.

この文書の最初のドラフトに関するコメントをくれたリチャード・ショッケー、そして貴重なレビューコメントについてはアリソン・マンキンに感謝します。

10. Author's Address

10. 著者の連絡先

Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA

Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 USA

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

11. Full Copyright Statement

11. 完全な著作権声明

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