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).
著作権（C）インターネット協会（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）ディレクトリサービス用の音声プロファイルを使用しています。しかし、このサービスは広く、短期的に展開になるには時間がかかります。この文書はまた、唯一のENUM電話番号解決サービスと既存の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.
このプロファイルは、二つの機構のいずれかに基づいてメッセージをルーティングするための機能的能力の範囲を提供することを目的とします。最も完全なサービスは、VPIMディレクトリを決定するためにENUMのアドレス解決サービスを使用し、メッセージのルーティングに使用されますVPIM-特定の電子メールアドレスを取得するためにLDAPを使用する必要があります。
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メッセージのルーティングを容易にするはずです。メッセージの性質とその内部の送信先を決定するために任意のコンテンツ処理を回避するための重要な目標です。最低でも、他の潜在的に異なるシステムにFAX、SMS、または他の電話宛のメッセージのルーティングを容易にしつつ、指定のシステムにすべての着信VPIMメッセージを送信し、簡単なメール転送ルールを確立することが可能でなければなりません。
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.
これは、VPIMディレクトリの発見とVPIMディレクトリクエリの手順はPSTNネットワークにおけるユーザインタフェースのためのタイミング制約内で発生する目標です。時間の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ディレクトリを照会する必要があります。クライアントが照会するVPIMディレクトリのIDを取得するために、ENUMサービスを使用すべきです。次に、クライアントは、メールアドレスと任意の所望の追加属性のために、そのサーバーに照会する必要があります。
* Service Name: E.164 to VPIM LDAP URL
*サービス名：VPIM LDAP URLにE.164
* URI Type: "LDAP:"
*タイプAT： "LDAP"
* Type: VPIM
*タイプ：VPIM
* Subtype: LDAP
*サブタイプ：LDAP
* Functional Specification: See sections 3.2 through 3.3
*機能仕様：参照セクション3.2〜3.3
* Intended Usage: COMMON
*使用目的：COMMON
* Author: Greg Vaudreuil (gregv@ieee.org)
*著者：グレッグボードルイ（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.
このような任意のサービスに関連する基本的な危険性の一つは、リゾルバのデータベースに悪質なエントリは、クライアントが間違ったLDAPのURLにE.164を解決するようになりますということです。可能な目的は、クライアントが不正な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ディレクトリ・サーバーは、ENUMプロトコルを使用し、受信者の電話番号に関連付けられ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.
[ENUM]によって記載されているようにDNSクエリ名が作成されます。ディレクトリの場所に使用される電話番号は、追加の数字のような追加のサブアドレス情報を含むことができます。
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!" .
IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \ "!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=\1!" .
NAPTR 10 20 "U" "E2U + VPIM：LDAP" \ "^ * $のldap：！。！！//vdir2.Zcorp.com/telephoneNumber= \ 1" 。
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つのサーバー間のランダム分布のために指定することができます。 [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].
フィールドとSMTP RCPTコマンド：VPIMディレクトリが発見されると、クライアントは、つまり、RFC 822に両方の値として使用されるべきアドレスをvPIMrFC822MailboxためのLDAPクエリを発行する必要があります。 [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.
基本的なサービスは、機械的に有効なVPIM-特定の電子メールアドレスを構築するためにNAPTR書き換えルールに依存しています。受信者のドメインでは、構築されたアドレスは、さらにドメイン内のメールルーティング技術を使用してルーティングすることができます。
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はのMailToをVPIMする：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
*使用目的：COMMON
* Author: Greg Vaudreuil (gregv@ieee.org)
*著者：グレッグボードルイ（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.
このような任意のサービスに関連する基本的な危険性の一つは、リゾルバのデータベースに悪質なエントリは、クライアントが間違った電子メールのURLにE.164を解決するようになりますということです。可能な意図は、クライアントが間違った宛先に情報を送信させるかもしれません。
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サービスを介して電子メールアドレスの露出は電話番号だけが以前に知られていた電子メールアドレスの多数のバルクメーラのアクセスを提供します。
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.
受信者のドメイン内では、メッセージはさらに、適切なメッセージングシステムにルーティングすることができます。二つの一般的なメカニズムは、ネットワーク内の目的のシステムへのさらなる経路メッセージに使用されてもよいです。
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
例アドレス：+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」をチェックします。
Example address: +12145551212@VPIM.sp.net
例アドレス：+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レコードの使用は、電話番号のみが知られているか、電話番号が推測されている場合、受信者の大規模なセットに電子メールを送信するためにバルクemailersに機能を提供します。
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ので不正なディレクトリを示すことによって、メッセージをリダイレクトすることができます。 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 [ENUM]のガイドラインと定義に従って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.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[NAPTR-1] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合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月。
[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）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[VPIMDIR] Vaudreuil, G., "Voice Messaging Directory Service", RFC 4237, October 2005.
[VPIMDIR]ヴォードルイユ、G.、 "ボイスメールディレクトリサービス"、RFC 4237、2005年10月。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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
グレゴリーM.ヴォードルイユルーセント・テクノロジーズ9489 BartgisのCtフレデリック、MD 21702
EMail: GregV@ieee.org
メールアドレス：GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎と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機能のための基金は現在、インターネット協会によって提供されます。