RFC4238 日本語訳
4238 Voice Message Routing Service. G. Vaudreuil. October 2005. (Format: TXT=18902 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Vaudreuil Request for Comments: 4238 Lucent Technologies Category: Standards Track October 2005
コメントを求めるワーキンググループG.ボードルイの要求をネットワークでつないでください: 4238年のルーセントテクノロジーズカテゴリ: 標準化過程2005年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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)ディレクトリサービスに電話番号でルックアップa VPIM EメールアドレスにVoice Profileを使用して、アドレスがともに有効であり、意図している受取人に関連づけられると確認してください。 しかしながら、このサービスは、近いうちに広く配布されるようになるには時間がかかるでしょう。 また、このドキュメントはENUM電話番号解決サービスと既存のDNSメールルーティング施設だけを使用することでメッセージを発送して、提供する基本的な発信している、祈っているサービスについて説明します。
Vaudreuil Standards Track [Page 1] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[1ページ]。
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
1. 目標を設計してください…2 2. 完全なサービス…3 2.1. 「E2U+VPIM: LDAP」というサービスの仕様…3 2.2. VPIMディレクトリ発見…4 2.3. 質問を扱ってください…4 3. 基本サービス…4 3.1. サービスの仕様、「2U+VPIM: E Mailto:、」 ................5 3.2. 工事を扱ってください…6 3.3. Interdomainメッセージルーティング…6 3.4. Intradomainメッセージルーティング…6 3.4.1. ディレクトリで可能にされたルート設定…6 3.4.2. サービスベースのメールルート設定…7 4. セキュリティ問題…7 4.1. 求められていない大量のメール…7 4.2. DNSベースの攻撃…7 5. IANA問題…8 6. 参照…8 6.1. 標準の参照…8 6.2. 有益な参照…8
1. Design Goals
1. デザイン目標
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つのメカニズムの1つに基づくメッセージルーティングにさまざまな機能的な能力を提供するつもりです。最も完全なサービスは、VPIMディレクトリを決定するのにENUMアドレス解決サービスを使用して、次に、メッセージルーティングに使用されるVPIM特有のEメールアドレスを検索するのに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
基本的機構は最小構成でVPIMメッセージのルーティングを適当な内部の目的地に容易にするはずです。 メッセージとその内部の目的地の自然を決定するためにどんな満足している処理も避けるのは、重要な目標です。 最小限では、それを規則に送る簡単な郵便配達人を設立するのは可能であるべきです。
Vaudreuil Standards Track [Page 2] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[2ページ]。
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.
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時2分第前の応答であるかもしれません。
2. The Complete Service
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メッセージルーティングサービスのために、送付クライアントSHOULDはVPIM特有のEメールアドレスのためのVPIMディレクトリについて質問します。 クライアントSHOULDは、質問するVPIMディレクトリのアイデンティティを検索するのにENUMサービスを利用します。 そして、クライアントはEメールアドレスと追加属性が望んでいたいずれのためにもそのサーバについて質問するべきです。
2.1. Specification of Service "E2U+VPIM:LDAP"
2.1. 「E2U+VPIM: LDAP」というサービスの仕様
* Service Name: E.164 to VPIM LDAP URL
* サービス名: VPIM LDAP URLへのE.164
* URI Type: "LDAP:"
* URIタイプ: 「LDAP:」
* Type: VPIM
* 以下をタイプしてください。 VPIM
* Subtype: LDAP
* Subtype: LDAP
* Functional Specification: See sections 3.2 through 3.3
* 機能的な仕様: セクション3.2〜3.3を見てください。
* Intended Usage: 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.
これなどのどんなサービスにも関連する基本的な危険の1つはクライアントがリゾルバのデータベースにおける悪意があるエントリーで間違ったLDAP URLにE.164に変えるということです。 可能な意図はクライアントが凶暴なLDAPサーバに接続して、詐欺的であるかダメージが大きい情報を含む(または、検索するやり損なう)リソースを検索することを引き起こすことであるかもしれません。
Vaudreuil Standards Track [Page 3] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[3ページ]。
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地図であり悪意がある侵入者がLDAPディレクトリサーバにアクセスするクライアントの能力を移すかもしれないURLを取り除くことによって。
2.2. VPIM Directory Discovery
2.2. VPIMディレクトリ発見
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サービスにENUMプロトコルと質問を使用することによって、見つけられます。
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!" .
以下について質問してください。 2.1.2.1.5.5.5.3.1.6.1. e164.arpa応答: 「$!NAPTR10 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!" .
「$!NAPTR10 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つの記録を与える能力を提供します。 2つのサーバの間のランダム分布に同じ重さを指定できます。 見てください。[NAPTR-1、NAPTR-2、NAPTR-3、NAPTR-4]
2.3. Address Query
2.3. アドレス質問
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ディレクトリがいったん発見されると、クライアントSHOULDは両方のRFC822To:のための値として使用されていた状態でvPIMrFC822MailboxのためのLDAP質問、すなわち、SHOULDがあるアドレスを発行します。 分野とSMTP RCPTは命令します。 [VPIMDIR]を見てください。
3. The Basic Service
3. 基本サービス
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特有のEメールアドレスを構成するためにNAPTR書換規則を当てにします。 受取人のドメインでは、組み立てられたアドレスは、intradomainメールルーティングのテクニックを使用することでさらに発送されるかもしれません。
Vaudreuil Standards Track [Page 4] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[4ページ]。
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.
最大限の範囲のintradomainルーティングオプションを容易にするために、組み立てられたEメールアドレスは、メッセージがVPIMメッセージであることを示します。 受取人のintradomainメールルーティングシステムの処理の容易さ、メッセージがVPIMメッセージであるという指示のために、SHOULDはドメイン名部分のそうです。
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.
組み立てられたアドレスが有効であるという保証が全くなくて、組み立てられたアドレスが意図している受取人に文通されることに注意してください。 受取人に関して能力情報を全く提供しないので、このメカニズムSHOULDにVPIM V2プロフィールのメディアとcontent typeだけを使用させている状態で、メッセージは発信しました。
3.1. Specification of Service "E2U+VPIM:Mailto:"
3.1. サービスの仕様、「2U+VPIM: E Mailto:、」
* Service Name: E.164 to VPIM MailTo: URL
* サービス名: VPIM MailToへのE.164: URL
* URI Type: "Mailto:"
* URIタイプ: 「Mailto:」
* Type: VPIM
* 以下をタイプしてください。 VPIM
* Subtype: MAILTO
* Subtype: MAILTO
* Functional Specification: See sections 4.2 through 4.4
* 機能的な仕様: セクション4.2〜4.4を見てください。
* Intended Usage: 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 付番プランにもかかわらず、URLでないところのE.164番号はその数のために存在しています。
o E2U+VPIM:Mailto Service unavailable
o E2U+VPIM: 入手できないMailto Service
* 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つはクライアントがリゾルバのデータベースにおける悪意があるエントリーで間違ったメールURLにE.164に変えるということです。 可能な意図はクライアントが不正確な目的地に情報を送ることを引き起こすことであるかもしれません。
Vaudreuil Standards Track [Page 5] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[5ページ]。
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サービスによるEメールアドレスの暴露は電話番号だけが以前に知られていた多くのEメールアドレスへの大量の郵送者アクセスを提供します。
3.2. Address Construction
3.2. アドレス工事
Construct a VPIM email address using the address rewrite rules of the NAPTR records associated with the VPIM service.
VPIMサービスに関連しているNAPTR記録のアドレス書換規則を使用して、VPIM Eメールアドレスを構成してください。
3.3. Interdomain Message Routing
3.3. Interdomainメッセージルーティング
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アドレスのinterdomainルーティングは既存のメールルーティングから機械的に区別がつきません。 インフラストラクチャへの変化は全く必要ではありません。 送付システムは、ドメイン名に対応するMX記録のためにドメインネームシステムに相談して、示されたシステムにメッセージを転送します。
3.4. Intradomain Message Routing
3.4. Intradomainメッセージルーティング
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.
以下に注意してください。 このセクションは厳密に情報です。 intradomainルーティングのためのメカニズムは、ドメインへの国内事情であり、プロトコルに影響しません。 NAPTR書換規則で作成されたアドレスが必要であったのが、ドメイン広告にそれらを意味しながら、必要であるだけです。 しかしながら、そのようなアドレスの作成と使用のためのコンベンションは役に立つかもしれません。
3.4.1. Directory-Enabled Routing
3.4.1. ディレクトリで可能にされたルート設定
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アドレスに代入されて、受取人メールボックスにメッセージを提供するのに使用されます。 メールボックスが機械的に組み立てられた電話番号ベースのアドレスに関する少しの知識も必要としないことに注意してください。
Vaudreuil Standards Track [Page 6] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[6ページ]。
Example address: +12145551212@sp.net
例のアドレス: + 12145551212@sp.net
3.4.2. Service-based Mail Routing
3.4.2. サービスベースのメールルート設定
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
4. Security Considerations
4. セキュリティ問題
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.
ほとんど標準のメールプロトコルを使用することで既に明らかにされないメッセージ送信者に明らかにされなかった情報があります。 有効なアドレスのために調べるのにこのプロトコルを使用する能力はテストメッセージと代わりに非配送している通知を待つ発信と同じです。
4.1. Unsolicited Bulk Email
4.1. 迷惑メール
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.
しかしながら、電話番号から発送可能Eメールアドレスを作成するENUM記録の使用は大きいセットの受取人への電話番号だけが知られているか、または電話番号が推測されるメールを送る能力を大量のemailersに供給します。
4.2. DNS-based Attacks
4.2. DNSベースの攻撃
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が感染されるなら、攻撃者は、悪意があるEメールアドレスを提供するか、または悪意があるLDAP URLで凶暴なディレクトリを示すことによって、メッセージを向け直すことができます。 DNS Securityプロトコル[DNSSEC]の使用はハイジャックされるドメインの危険をかなり減少させます。 DNSSECと共にE.164ゾーンを保証するなら、クライアントが、キーが以前はよくゾーンに署名していたと信じることができるなら、攻撃を排除します。 DNSセキュリティは独自に感染されるLDAPサービスから守りません。 このLDAPサービスへのリスクのさらなる議論を[VPIMDIR]に提供します。
Vaudreuil Standards Track [Page 7] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[7ページ]。
5. IANA Considerations
5. IANA問題
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.
RFC3761[ENUM]の仕様とガイドラインと定義に従って、この仕様は本書ではE2U+VPIMとE2U+ボイスサービスを登録します。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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.食事、「Uniform Resource Identifier(URI)ダイナミックな委譲発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、2004年4月。
[NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[NAPTR-1]食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[NAPTR-2]食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、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]食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[NAPTR-4] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)", RFC
3404, October 2002.
[NAPTR-4]食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)」、RFC3404、2002年10月。
[VPIMDIR] Vaudreuil, G., "Voice Messaging Directory Service", RFC
4237, October 2005.
[VPIMDIR] ボードルイ、G.、「声のメッセージングディレクトリサービス」、RFC4237、2005年10月。
6.2. Informative References
6.2. 有益な参照
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
Vaudreuil Standards Track [Page 8] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[8ページ]。
Author's Address
作者のアドレス
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
VPIMワーキンググループへのこのドキュメントのコメントを list <vpim@ietf.org に郵送させてください、gt。
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
9489年のBartgis ctのグレゴリーM.ボードルイルーセントテクノロジーズのフレディリック、MD 21702
EMail: GregV@ieee.org
メール: GregV@ieee.org
Vaudreuil Standards Track [Page 9] RFC 4238 Voice Message Routing Service October 2005
ボードルイ規格は音声メールルート設定サービス2005年10月にRFC4238を追跡します[9ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Vaudreuil Standards Track [Page 10]
ボードルイ標準化過程[10ページ]
一覧
スポンサーリンク
