[要約] RFC 4238は、音声メッセージのルーティングサービスに関する仕様書であり、音声メッセージの送信元と宛先の間の通信を効率的に処理するためのガイドラインを提供しています。このRFCの目的は、音声メッセージの効果的なルーティングと配信を実現するための標準化とベストプラクティスの確立です。
Network Working Group G. Vaudreuil
Request for Comments: 4238 Lucent Technologies
Category: Standards Track October 2005
Voice Message Routing Service
音声メッセージルーティングサービス
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities.
音声メッセージは、従来、電話番号のアドレス指定を使用して対処されています。このドキュメントでは、電話番号に基づいて音声メッセージをルーティングするための2つの手法について説明します。完全なサービスでは、インターネットメール（VPIM）ディレクトリサービスの音声プロファイルを使用して、電話番号を使用してVPIMメールアドレスを検索し、アドレスが有効であり、意図した受信者に関連付けられていることを確認します。ただし、このサービスには、短期的に広く展開されるまでに時間がかかります。このドキュメントでは、列挙電話番号解像度サービスと既存のDNSメールルーティング機能のみを使用してメッセージをルーティングおよび配信する基本的な送信および弾丸サービスについても説明しています。
Table of Contents
目次
1. Design Goals ....................................................2
2. The Complete Service ............................................3
2.1. Specification of Service "E2U+VPIM:LDAP" ...................3
2.2. VPIM Directory Discovery ...................................4
2.3. Address Query ..............................................4
3. The Basic Service ...............................................4
3.1. Specification of Service "E2U+VPIM:Mailto:" ................5
3.2. Address Construction .......................................6
3.3. Interdomain Message Routing ................................6
3.4. Intradomain Message Routing ................................6
3.4.1. Directory-Enabled Routing ...........................6
3.4.2. Service-based Mail Routing ..........................7
4. Security Considerations .........................................7
4.1. Unsolicited Bulk Email .....................................7
4.2. DNS-based Attacks ..........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
This profile is intended to provide a range of functional capabilities for message routing based on one of two mechanisms. The most complete service should use the ENUM address resolution service to determine the VPIM directory, and then use LDAP to retrieve the VPIM-specific email address that will be used for message routing.
このプロファイルは、2つのメカニズムのいずれかに基づいて、メッセージルーティングにさまざまな機能機能を提供することを目的としています。最も完全なサービスでは、Enumアドレス解像度サービスを使用してVPIMディレクトリを決定し、LDAPを使用してメッセージルーティングに使用されるVPIM固有の電子メールアドレスを取得する必要があります。
The more basic send-and-pray message service uses only the ENUM service and MX records to route the message to the intended recipient's domain. The intelligence to further route the message to the intended recipient is placed within the message routing system of the recipient's domain.
より基本的なセンドアンドプレイメッセージサービスは、EnumサービスとMXレコードのみを使用して、意図した受信者のドメインにメッセージをルーティングします。意図した受信者にメッセージをさらにルーティングするインテリジェンスは、受信者のドメインのメッセージルーティングシステム内に配置されます。
The basic mechanism may be used even when there is a VPIM directory service available. The basic service is useful when LDAP queries are not available, such as may be the case for disconnected mobile terminals or because of firewall or information security policies.
VPIMディレクトリサービスが利用可能であっても、基本的なメカニズムを使用できます。基本的なサービスは、LDAPクエリが利用できない場合に役立ちます。たとえば、モバイル端子が切断されている場合や、ファイアウォールまたは情報セキュリティポリシーの場合です。
The basic mechanism should facilitate the routing of VPIM messages to a suitable internal destination with a minimum of configuration. It is an important goal to avoid any content-processing to determine the nature of the message and its internal destination. At a minimum, it should be possible to establish a simple mail forwarding rule that sends all inbound VPIM messages to a designated system, while facilitating the routing of FAX, SMS, or other telephone-addressed messages to other potentially different systems.
基本的なメカニズムは、最小限の構成で適切な内部宛先へのVPIMメッセージのルーティングを容易にする必要があります。コンテンツ処理を避けてメッセージの性質とその内部目的地を決定することは重要な目標です。少なくとも、すべてのインバウンドVPIMメッセージを指定されたシステムに送信する単純なメール転送ルールを確立し、FAX、SMS、または他の電話留められたメッセージのルーティングを他の潜在的に異なるシステムに促進することができるはずです。
It is a goal that the mechanisms outlined in this document be extensible for all store-and-forward, telephone-number addressed messaging services.
このドキュメントで概説されているメカニズムが、すべての店舗と電話番号アドレス指定されたメッセージングサービスに対して拡張可能であることが目標です。
It is a goal that the VPIM directory discovery and VPIM directory query steps occur within the timing constraints for user interfaces in PSTN networks. 95% of the time, that constraint can be a two-second response.
PSTNネットワークのユーザーインターフェイスのタイミング制約内でVPIMディレクトリの発見とVPIMディレクトリクエリステップが発生することが目標です。95％の時間、その制約は2秒の応答になる可能性があります。
For the complete VPIM message routing service, the sending client SHOULD query the VPIM directory for the VPIM-specific email address. The client SHOULD use the ENUM service to retrieve the identity of the VPIM Directory to query. The client should then query that server for the email address and any additional attributes desired.
完全なVPIMメッセージルーティングサービスの場合、送信クライアントはVPIM固有の電子メールアドレスのVPIMディレクトリを照会する必要があります。クライアントは、enumサービスを使用してVPIMディレクトリのIDを取得してクエリする必要があります。その後、クライアントは、そのサーバーをメールアドレスと必要な追加属性を照会する必要があります。
* Service Name: E.164 to VPIM LDAP URL
* サービス名：E.164からVPIM LDAP URLへ
* URI Type: "LDAP:"
* URIタイプ：「LDAP：」
* Type: VPIM
* タイプ：VPIM
* Subtype: LDAP
* サブタイプ：LDAP
* Functional Specification: See sections 3.2 through 3.3
* 機能仕様：セクション3.2から3.3を参照してください
* Intended Usage: COMMON
* 意図された使用法：共通
* Author: Greg Vaudreuil (gregv@ieee.org)
* 著者：greg vaudreuil（gregv@ieee.org）
* Security Considerations:
* セキュリティ上の考慮事項：
o Malicious Redirection
o 悪意のあるリダイレクト
One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong LDAP URL. The possible intent may be to cause the client to connect to a rogue LDAP server and retrieve (or fail to retrieve) a resource containing fraudulent or damaging information.
このようなサービスに関連する基本的な危険の1つは、Resolverのデータベースに悪意のあるエントリにより、クライアントがE.164を間違ったLDAP URLに解決することです。考えられる意図は、クライアントにRogue LDAPサーバーに接続し、不正または損害情報を含むリソースを取得（または取得できない）することです。
o Denial of Service
o サービス拒否
By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the LDAP directory server.
E.164マップをマップするURLを削除することにより、悪意のある侵入者は、LDAPディレクトリサーバーにアクセスするクライアントの機能を削除する場合があります。
The VPIM directory server is found by using the ENUM protocol and querying for the VPIMDIR service associated with the telephone number of the recipient.
VPIMディレクトリサーバーは、受信者の電話番号に関連付けられたvPIMDIRサービスの列挙プロトコルとクエリを使用して見つかります。
The DNS query name is created as described by [ENUM]. The telephone number used for the directory location MAY contain additional sub-address information as additional digits.
DNSクエリ名は、[enum]で説明されているように作成されます。ディレクトリの場所に使用される電話番号には、追加の桁として追加のサブアドレス情報が含まれる場合があります。
Example:
例：
Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa Responses: IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ "!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .
クエリ：2.1.2.1.5.5.5.5.5.5.1.6.1.e164.Arpa応答：Naptr 10 "U" "e2u vpim：ldap" \ "！^。。
IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \ "!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=\1!" .
in naptr 10 20 "u" "e2u vpim：ldap" \ "！^。。
It is recommended that VPIMDIR servers be deployed in a redundant configuration. NAPTR weight fields provide the ability to give two records indicating the same service and preference a different weight. The same weight can be specified for random distribution between the two servers. See [NAPTR-1, NAPTR-2, NAPTR-3, NAPTR-4]
VPIMDIRサーバーを冗長構成で展開することをお勧めします。NAPTR重量フィールドは、同じサービスを示す2つのレコードを提供し、異なる重量を好む機能を提供します。2つのサーバー間のランダム分布には、同じ重みを指定できます。[naptr-1、naptr-2、naptr-3、naptr-4]を参照してください
Once the VPIM directory is discovered, the client SHOULD issue an LDAP query for the vPIMrFC822Mailbox, that is, the address that SHOULD be used as the value for both the RFC 822 To: field and the SMTP RCPT command. See [VPIMDIR].
VPIMディレクトリが発見されると、クライアントはVPIMRFC822MAILBOXのLDAPクエリ、つまりRFC 822の両方の値として使用されるべきアドレスとSMTP RCPTコマンドを発行する必要があります。[vpimdir]を参照してください。
The basic service relies upon NAPTR rewrite rules to mechanically construct a valid VPIM-specific email address. In the recipient's domain, the constructed address may be further routed using intradomain mail routing techniques.
基本サービスは、NAPTRの書き換えルールに依存して、有効なVPIM固有の電子メールアドレスを機械的に構築します。受信者のドメインでは、構築されたアドレスは、イントーマインメールルーティング手法を使用してさらにルーティングできます。
To facilitate a full range of intradomain routing options, the constructed email address indicates that the message is a VPIM message. For ease of processing in the recipient's intradomain mail routing system, the indication that the message is a VPIM message SHOULD be in the domain name portion.
あらゆる範囲のドメイン内ルーティングオプションを容易にするために、構築された電子メールアドレスは、メッセージがVPIMメッセージであることを示します。受信者のイントマン内メールルーティングシステムでの処理を容易にするために、メッセージがVPIMメッセージであることを示していることは、ドメイン名の部分にある必要があります。
Note that there is no assurance the constructed address is valid, nor that the constructed address corresponds to the intended recipient. Because no capabilities information is provided about the recipient, messages sent with this mechanism SHOULD be sent using only the media and content types of the VPIM V2 profile.
構築されたアドレスが有効であることも、構築されたアドレスが意図した受信者に対応していることも保証されていないことに注意してください。受信者に関する機能情報は提供されていないため、このメカニズムで送信されたメッセージは、VPIM V2プロファイルのメディアとコンテンツタイプのみを使用して送信する必要があります。
* Service Name: E.164 to VPIM MailTo: URL
* サービス名：E.164からVPIM Mailto：url
* URI Type: "Mailto:"
* URIタイプ：「Mailto：」
* Type: VPIM
* タイプ：VPIM
* Subtype: MAILTO
* サブタイプ：mailto
* Functional Specification: See sections 4.2 through 4.4
* 機能仕様：セクション4.2から4.4を参照してください
* Intended Usage: COMMON
* 意図された使用法：共通
* Author: Greg Vaudreuil (gregv@ieee.org)
* 著者：greg vaudreuil（gregv@ieee.org）
* Error Conditions:
* エラー条件：
o E.164 number not in the numbering plan
o e.164番号は、番号付け計画ではありません
o E.164 number in the numbering plan, but no URLs exist for that number
o e.164番号付け計画には数字がありますが、その番号にはURLが存在しません
o E2U+VPIM:Mailto Service unavailable
o E2U VPIM：MailToサービスは利用できません
* Security Considerations:
* セキュリティ上の考慮事項：
o Malicious Redirection
o 悪意のあるリダイレクト
One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong email URL. The possible intent may be to cause the client to send the information to an incorrect destination.
このようなサービスに関連する基本的な危険の1つは、Resolverのデータベースに悪意のあるエントリにより、クライアントがE.164を間違った電子メールURLに解決することです。考えられる意図は、クライアントに情報を誤った宛先に送信させることです。
o Denial of Service
o サービス拒否
By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource.
E.164マップをマップするURLを削除することにより、悪意のある侵入者は、クライアントのリソースにアクセスする能力を削除する場合があります。
o Unsolicited Bulk Email
o 未承諾のバルクメール
The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known.
Enum Serviceを介した電子メールアドレスの露出は、電話番号のみが以前に既知であった多数の電子メールアドレスへの大量のメーラーアクセスを提供します。
Construct a VPIM email address using the address rewrite rules of the NAPTR records associated with the VPIM service.
VPIMサービスに関連付けられたNAPTRレコードのルールを書き換えるアドレスを使用して、VPIMメールアドレスを作成します。
The interdomain routing of a constructed VPIM address is mechanically indistinguishable from existing email routing. No changes to the infrastructure are required. The sending system consults the Domain Name System for an MX record corresponding to the domain name and forwards the message to the indicated system.
構築されたVPIMアドレスのドメイン間ルーティングは、既存の電子メールルーティングと機械的に区別できません。インフラストラクチャの変更は必要ありません。送信システムは、ドメイン名に対応するMXレコードについてドメイン名システムに相談し、指定されたシステムにメッセージを転送します。
Within the recipient's domain, the message may be further routed to the appropriate messaging system. Two general mechanisms may be used to further route the message to the intended system within a network.
受信者のドメイン内で、メッセージはさらに適切なメッセージングシステムにルーティングされる場合があります。2つの一般的なメカニズムを使用して、メッセージをネットワーク内の意図したシステムにさらにルーティングすることができます。
Note: This section is strictly informational. The mechanisms for intradomain routing are an internal matter for the domain and do not affect the protocol. It is only necessary that the addresses created by the NAPTR rewrite rules have meaning to the domain advertising them. However, a convention for the creation and use of such addresses may be useful.
注：このセクションは厳密に情報を提供しています。イントマンルーティングのメカニズムはドメインの内部問題であり、プロトコルに影響しません。NAPTRの書き換えルールによって作成されたアドレスが、それらを宣伝するドメインに意味を持つことのみが必要です。ただし、このような住所の作成と使用に関する慣習は有用かもしれません。
Various proprietary directory mechanisms provide a means for an inbound mail router of the recipient's domain to send a message to the appropriate internal mail host. In many cases, the local part of the address is used to query for an internal mail address. That internal mail address is substituted for the SMTP RCPT address and used to deliver the message to the recipient mailbox. Note that the mailbox does not need to have any knowledge of the mechanically-constructed telephone number-based address.
さまざまな独自のディレクトリメカニズムは、受信者のドメインのインバウンドメールルーターが適切な内部メールホストにメッセージを送信する手段を提供します。多くの場合、アドレスのローカル部分は、内部メールアドレスをクエリするために使用されます。その内部メールアドレスは、SMTP RCPTアドレスに置き換えられ、受信者のメールボックスにメッセージを配信するために使用されます。メールボックスは、機械的に構築された電話番号ベースの住所について知識が必要ではないことに注意してください。
Example address: +12145551212@sp.net
Alternately, a mail gateway may simply send all voice messages into a separate messaging system. That system may be a single voice messaging server or a service-specific gateway into a larger telephone number-based voice-messaging network.
あるいは、メールゲートウェイは、すべての音声メッセージを別のメッセージングシステムに送信するだけです。そのシステムは、単一の音声メッセージングサーバーまたは、より大きな電話番号ベースの音声測定ネットワークへのサービス固有のゲートウェイである場合があります。
Such a mail gateway may be provisioned with a simple rule or small set of rules to forward all messages of a given service type to a pre-defined server. This rule would check for the service name "VPIM" as a prefix to the constructed domain name to reroute messages.
このようなメールゲートウェイには、特定のサービスタイプのすべてのメッセージを事前に定義されたサーバーに転送するための単純なルールまたは小さなルールセットをプロビジョニングする場合があります。このルールは、[vpim]を[VPIM]に確認して、構成されたドメイン名の接頭辞としてチェックして、メッセージを表示します。
Example address: +12145551212@VPIM.sp.net
There is little information disclosed to the sender of the message that is not already disclosed using standard email protocols. The ability to use this protocol to probe for valid addresses is identical to the sending of test messages and waiting for a non-delivery notification in return.
標準の電子メールプロトコルを使用してまだ開示されていないメッセージの送信者に開示された情報はほとんどありません。このプロトコルを使用して有効なアドレスのプローブを使用する機能は、テストメッセージの送信と、見返りの非配信通知を待つことと同じです。
However, the use of ENUM records to create routable email addresses from telephone numbers provides bulk-emailers the capabilities to send email to a large set of recipients where only the telephone number is known or where telephone numbers are guessed.
ただし、電話番号からルーティング可能な電子メールアドレスを作成するためにenumレコードを使用すると、バルクエマイラーは、電話番号のみが既知または電話番号が推測される大規模な受信者にメールを送信する機能を提供します。
Both the complete and basic services rely upon the DNS to provide the information necessary to validate a recipient or send a message. The message sender is a casual, unauthenticated use of the indicated servers, and relies upon the DNS for accurate information. If the DNS is compromised, an attacker can redirect messages by providing a malicious email address or indicating a rogue directory with malicious LDAP URL's. Use of DNS Security protocols [DNSSEC] substantially reduces the risk of a domain being hijacked. If the E.164 zone is secured with DNSSEC, then the attack is precluded if the client can trust the key used to sign the zone. DNS security does not protect against the LDAP service being independently compromised. Further discussion on the risk to this LDAP service is provided in [VPIMDIR].
完全なサービスと基本サービスの両方がDNSに依存して、受信者を検証したりメッセージを送信したりするのに必要な情報を提供します。メッセージ送信者は、指定されたサーバーのカジュアルで無慈悲な使用であり、正確な情報のためにDNSに依存しています。DNSが侵害されている場合、攻撃者は悪意のある電子メールアドレスを提供したり、悪意のあるLDAP URLを使用したRogueディレクトリを示すことにより、メッセージをリダイレクトできます。DNSセキュリティプロトコル[DNSSEC]を使用すると、ドメインがハイジャックされるリスクが大幅に減少します。E.164ゾーンがDNSSECで固定されている場合、クライアントがゾーンに署名するために使用されるキーを信頼できる場合、攻撃は排除されます。DNSセキュリティは、LDAPサービスが独立して侵害されていることから保護しません。このLDAPサービスのリスクに関するさらなる議論は、[vpimdir]で提供されています。
This specification registers the E2U+VPIM and E2U+Voice services according to the specifications and guidelines in RFC 3761 [ENUM] and the definitions in this document.
この仕様は、RFC 3761 [列挙]の仕様とガイドラインとこのドキュメントの定義に従って、E2U VPIMおよびE2U音声サービスを登録します。
[ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[Enum] Faltstrom、P。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[Naptr-1] Mealling、M。、「動的委任ディスカバリーシステム（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[NAPTR-2] Mealling、M。、「動的委任発見システム（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[NAPTR-3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[Naptr-3] Mealling、M。、「動的委任発見システム（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[NAPTR-4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[Naptr-4] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）」、RFC 3404、2002年10月。
[VPIMDIR] Vaudreuil, G., "Voice Messaging Directory Service", RFC 4237, October 2005.
[Vpimdir] Vaudreuil、G。、「Voice Messaging Directory Service」、RFC 4237、2005年10月。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル -バージョン2（VPIMV2）」、RFC 3801、2004年6月。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[DNSSEC] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
Author's Address
著者の連絡先
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
このドキュメントに関するコメントをVPIMワーキンググループメーリングリスト<vpim@ietf.org>に送信してください。
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis CT Frederick、MD 21702
EMail: GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。