Network Working Group P. Faltstrom
Request for Comments: 2916 Cisco Systems Inc.
Category: Standards Track September 2000
E.164 number and DNS
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed.
この文書では、E.164番号の記憶のためのドメインネームシステム（DNS）の使用について説明します。より具体的には、どのようにDNSは、一つE.164番号に接続された利用可能なサービスを識別するために使用することができます。これらの方法を用いて選択されたサービスを使用して、実際の接続のルーティングは議論されません。
Through transformation of E.164 numbers into DNS names and the use of existing DNS services like delegation through NS records, and use of NAPTR [1] records in DNS [2] [3], one can look up what services are available for a specific domain name in a decentralized way with distributed management of the different levels in the lookup process.
DNSのレコード[1] DNS名とNSレコードによる委任のような既存のDNSサービスの利用にE.164番号の変換、およびNAPTRを使用することにより、[2] [3]、1サービスはのために利用可能であるか調べることができます検索プロセスにおけるさまざまなレベルの分散管理と分散型の方法で、特定のドメイン名。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC2119 [4].
キーワード「MUST」、「REQUIRED」は、「推奨」、「SHOULD」、および本書ではRFC2119に記載されているように解釈される「場合がある」[4]。
The domain "e164.arpa" is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into subdomains. Holders of E.164 numbers which want to be listed in DNS should contact the appropriate zone administrator in order to be listed, by examining the SOA resource record associated with the zone, just like in normal DNS operations.
ドメイン「e164.arpa」はE.164番号の保存のためのDNSのインフラを提供するために移入されています。分散操作を容易にするために、このドメインはサブドメインに分割されます。 DNSに記載されていることがしたいE.164番号の保有者は、通常のDNS操作のように、ゾーンに関連付けられているSOAリソースレコードを調べることによって、リストするために、適切なゾーン管理者に連絡してください。
Of course, as with other domains, policies for such listings will be controlled on a subdomain basis and may differ in different parts of the world.
もちろん、他のドメインと同様に、そのようなリストのポリシーは、サブドメインに基づいて制御され、世界のさまざまな部分で異なる場合があります。
To find the DNS names for a specific E.164 number, the following procedure is to be followed:
特定のE.164番号のDNS名を検索するには、以下の手順に従うことです。
1. See that the E.164 number is written in its full form, including the countrycode IDDD. Example: +46-8-9761234
1. E.164番号は国番号IDDD含め、その完全な形で書かれていることを参照してください。例：+ 46-8-9761234
2. Remove all non-digit characters with the exception of the leading '+'. Example: +4689761234
2.リードする「+」を除いて、すべての数字以外の文字を削除します。例：+4689761234
3. Remove all characters with the exception of the digits. Example: 4689761234
3桁を除いてすべての文字を削除します。例：4689761234
6. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa
6.最後に文字列「.e164.arpa」を追加します。例：4.3.2.1.6.7.9.8.6.4.e164.arpa
The '+' is kept in stage 2 in section 2 to flag that the number which the regular expression is operating on is a E.164 number. Future work will be needed to determine how other numbering plans (such as closed ones) might be identified. It is possible, but not definite, that they would use a similar mechanism as the one described in this document.
「+」は、正規表現で動作している番号がE.164番号であるフラグをセクション2にステージ2に保持されています。今後の作業が識別される可能性がありますどのように他の（例えば、閉じたものなど）番号計画を決定するために必要とされるであろう。それは彼らがこの文書で説明したものと同様のメカニズムを使用することを、可能性はなく、明確ではありません。
For a record in DNS, the NAPTR record is used for identifying available ways of contacting a specific node identified by that name. Specifically, it can be used for knowing what services exists for a specific domain name, including phone numbers by the use of the e164.arpa domain as described above.
DNSレコードのために、NAPTRレコードは、その名前によって識別される特定のノードに接触する利用可能な方法を識別するために使用されます。具体的には、上記のようにe164.arpaドメインを使用することにより、電話番号など、特定のドメイン名のために存在するもののサービスを知るために使用することができます。
The identification is using the NAPTR resource record defined for use in the URN resolution process, but it can be generalized in a way that suits the needs specified in this document.
識別はURN解決プロセスで使用するために定義されたNAPTRリソースレコードを使用しているが、それは、この文書で指定されたニーズに合った方法で一般化することができます。
It is the string which is the result of step 2 in section 2 above which is input to the NAPTR algorithm.
これは、NAPTRアルゴリズムに入力される上記のセクション2におけるステップ2の結果である文字列です。
The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement. For a detailed description, see:
NAPTR RR内のキーフィールドが順番、嗜好、サービス、フラグ、正規表現、および置換されています。詳細については、以下を参照してください。
o The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query.
Oオーダーフィールドは、複数のNAPTRレコードが単一のクエリに応答して返されたときにレコードが処理されなければならない順序を指定します。
o The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order".
優先フィールドO複数のNAPTRレコードが「注文」の同じ値を有する場合、レコードが処理されるべき順序を指定します。
o The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied.
Oサービスフィールドは、解像度プロトコル及び正規表現または置換フィールドによって指定されたリライトが適用された場合に利用できるようになります解決サービス（複数可）を指定します。
o The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process.
フラグフィールドoを通常のプロセスを最適化するために、次のDNSルックアップで何が起こるかに影響修飾子が含まれています。
o The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record.
O正規表現フィールドが書き換えルールに使用される2つの分野の一つである、とNAPTRレコードの中核概念です。
o The replacement field is the other field that may be used for the rewrite rule.
O置換フィールドは、書き換え規則のために使用することができる他のフィールドがあります。
Note that the client applies all the substitutions and performs all lookups, they are not performed in the DNS servers. Note that URIs are stored in the regexp field.
これらはDNSサーバで実行されていない、クライアントはすべての置換を適用し、すべてのルックアップを実行することに注意してください。 URIは正規表現、フィールドに格納されていることに注意してください。
The input is an E.164 encoded telephone number. The output is a Uniform Resource Identifier in its absolute form according to the 'absoluteURI' production in the Collected ABNF found in RFC2396 [5]
入力は、E.164符号化された電話番号です。出力は、RFC2396に見出さ収集ABNFの「absoluteURIでの生産に応じてその絶対形式に統一リソース識別子である[5]
An E.164 number, without any characters but leading '+' and digits, (result of step 2 in section 2 above) is the input to the NAPTR algorithm.
E.164番号は、任意の文字を含まないが、「+」と数字をリードし、（上記のセクション2におけるステップ2の結果）NAPTRアルゴリズムに入力されます。
The service supported for a call is E2U.
コールに対してサポートサービスがE2Uです。
* Name: E.164 to URI * Mnemonic: E2U * Number of Operands: 1 * Type of Each Operand: First operand is an E.164 number. * Format of Each Operand: First operand is the E.164 number in the form as specified in step 2 in section 2 in this document. * Algorithm: Opaque * Output: One or more URIs * Error Conditions: o E.164 number not in the numbering plan o E.164 number in the numbering plan, but no URIs exist for that number o Service unavailable
*名前：URI *ニーモニックへのE.164：オペランドのE2U *数：それぞれのオペランドの1 *タイプ：最初のオペランドがE.164番号です。 *各オペランドの形式：この文書のセクション2のステップ2で指定されるように第1オペランドは、フォーム内のE.164番号です。 *アルゴリズム：不透明*出力：1つ以上のURI *エラー条件：E.164番号Oない番号計画でE.164番号O番号計画中に、ないURIが利用できないサービスoをその数のために存在しません
* Security Considerations: o Malicious Redirection 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 URI. The possible intent may be to cause the client to retrieve a resource containing fraudulent or damaging material. o Denial of Service By removing the URI to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource.
*セキュリティの考慮：悪意のあるリダイレクションoをこのような任意のサービスに関連する基本的な危険性の一つは、リゾルバのデータベースに悪質なエントリは、クライアントが間違ったURIにE.164を解決するようになりますということです。可能な意図は、クライアントが不正または有害物質を含むリソースを取得させるかもしれません。 E.164マップ先のURIを除去することにより、サービス拒否O、悪意のある侵入者がリソースにアクセスするためのクライアントの機能を削除することができます。
This operation is used to map a one E.164 number to a list of URIs. The first well-known step in the resolution process is to remove all non-digits apart from the leading '+' from the E.164 number as described in step 1 and 2 in section 2 of this document.
この操作は、URIのリストに1つのE.164番号をマップするために使用されます。解決プロセスの最初のよく知られたステップは、このドキュメントのセクション2のステップ1及び2に記載されているようにE.164番号から先頭の「+」から離れ、すべての非数字を除去することです。
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:info@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:info@tele2.se!" .
$ ORIGINの4.3.2.1.6.7.9.8.6.4.e164.arpa。 NAPTR 100 10に "U" は "" E2U +一口 "^ * $一口：！。！info@tele2.se！" 。 NAPTR 102 10 "U" "のmailto + E2U" IN "！。^ * $のmailto：！info@tele2.se！" 。
This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is preferably contacted by SIP, and secondly by SMTP.
これは、ドメイン4.3.2.1.6.7.9.8.6.4.e164.arpaは好ましくはSIPにより接触させ、第二にSMTPによってすることが記載されています。
In both cases, the next step in the resolution process is to use the resolution mechanism for each of the protocols, (SIP and SMTP) to know what node to contact for each.
両方の場合において、解決プロセスの次のステップは、それぞれのために連絡するかを知っているノードプロトコル（SIPおよびSMTP）のそれぞれについて解決メカニズムを使用することです。
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+4689761234!" .
$ ORIGINの4.3.2.1.6.7.9.8.6.4.e164.arpa。 10 NAPTR 10に "U" "SIP + E2U" "^ * $一口：！。！paf@swip.net！" 。 NAPTR 102 10 "U" "のmailto + E2U" IN "！^ * $のmailto：。！paf@swip.net！" 。 NAPTR 102 10に "U" "TEL + E2U" "^ * $ TEL：！。！4689761234！" 。
Note that the preferred method is to use the SIP protocol, but the result of the rewrite of the NAPTR record is a URI (the "u" flag in the NAPTR record). In the case of the protocol SIP, the URI might be a SIP URI, which is resolved as described in RFC 2543 [6]. In the case of the "tel" URI scheme [7], the procedure is restarted with this new E.164 number. The client is responsible for loop detection.
好ましい方法は、SIPプロトコルを使用することであることに留意されたいが、NAPTRレコードの書換えの結果は、URI（NAPTRレコードの「U」フラグ）です。プロトコルSIPの場合には、URIは、RFC 2543に記載されるように解決されるSIP URI、かもしれない[6]。 「TEL」URIスキーム[7]の場合には、手順はこの新しいE.164番号で再開されます。クライアントは、ループ検出のために責任があります。
The rest of the resolution of the routing is done as described above.
ルーティングの解像度の残りは上記のように行われます。
$ORIGIN 6.4.e164.arpa. * IN NAPTR 100 10 "u" "ldap+E2U" "!^+46(.*)$!ldap://ldap.se/cn=01!" .
$ ORIGINの6.4.e164.arpa。 * "NAPTR 100 10 "U"" LDAP + E2U IN "^ + 46 $ LDAP！（*）：！//ldap.se/cn=01！" 。
We see in this example that information about all E.164 numbers in the 46 countrycode (for Sweden) exists in an LDAP server, and the search to do is specified by the LDAP URI [8].
私たちは、この例では（スウェーデン）46国番号のすべてのE.164番号についての情報を参照してくださいには、LDAPサーバに存在し、かつ実行する検索はLDAP URIで指定されている[8]。
This memo requests that the IANA delegate the E164.ARPA domain following instructions to be provided by the IAB. Names within this zone are to be delegated to parties according to the ITU recommendation E.164. The names allocated should be hierarchic in accordance with ITU Recommendation E.164, and the codes should assigned in accordance with that Recommendation.
IANAは、IABによって提供される指示に従ってE164.ARPAドメインを委任するこのメモ依頼。このゾーン内の名前は、ITU勧告E.164に応じて関係者に委任することになっています。割り当てられた名前は、ITU勧告E.164に応じて階層的であるべきであり、コードがその勧告に応じて割り当てられなければなりません。
Delegations in the zone e164.arpa (not delegations in delegated domains of e164.arpa) should be done after Expert Review, and the IESG will appoint a designated expert.
ゾーンe164.arpa（e164.arpaの委任ドメインではない代表団）での代表団は専門家レビューの後に行われるべきである、とIESGは、指定された専門家を任命します。
As this system is built on top of DNS, one can not be sure that the information one get back from DNS is more secure than any DNS query. To solve that, the use of DNSSEC [9] for securing and verifying zones is to be recommended.
このシステムは、DNSの上に構築されたように、一は1つがDNSから戻った情報は、任意のDNSクエリーよりも安全であることを確認することはできません。それを解決するために、固定およびゾーンを検証する[9] DNSSECの使用が推奨されます。
The caching in DNS can make the propagation time for a change take the same amount of time as the time to live for the NAPTR records in the zone that is changed. The use of this in an environment where IP-addresses are for hire (for example, when using DHCP [11]) must therefore be done very carefully.
DNSでのキャッシングは、変更のための伝搬時間が変更されたゾーンのNAPTRレコードの生存時間と同じ時間を取ることができます。 （DHCPを使用した場合、たとえば、[11]）は、IP-アドレスはレンタル用である環境でこのの使用は極めて慎重に行わなければなりません。
There are a number of countries (and other numbering environments) in which there are multiple providers of call routing and number/name-translation services. In these areas, any system that permits users, or putative agents for users, to change routing or supplier information may provide incentives for changes that are actually unauthorized (and, in some cases, for denial of legitimate change requests). Such environments should be designed with adequate mechanisms for identification and authentication of those requesting changes and for authorization of those changes.
コールルーティングおよび番号/名前-翻訳サービスの複数のプロバイダがされた国（および他の番号の環境）の数があります。これらの領域では、ユーザーのためのユーザー、または推定剤を可能にする任意のシステムは、実際に不正な（および、いくつかのケースでは、正規変更要求の拒否のため）が変化するためのインセンティブを提供することができるルーティングサプライヤー情報を変更します。このような環境は、これらの要求の変更の識別及び認証のため、これらの変更の許可のための適切な機構を用いて設計されるべきです。
Support and ideas have come from people at Ericsson, Bjorn Larsson and the group which implemented this scheme in their lab to see that it worked. Input has also come from ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and Service Definition), the ENUM working group in the IETF, John Klensin and Leif Sunnegardh.
サポートやアイデアはエリクソン、ビョルン・ラーションと、それが働いたことを確認するために自分の研究室でこのスキームを実装グループで人々から来ています。入力はまた、ITU-T SG2、作業部会1/2（番号、ルーティング、グローバルモビリティおよびサービス定義）、IETF、ジョン・クレンシンとレイフSunnegardhにおけるENUMワーキンググループから来ています。
References
リファレンス
[1] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[1] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年9月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5]バーナーズ - リー、T.、フィールディング、R.T.そして、L. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[6]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[7] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[7] Vaha-Sipilaは、A.、RFC 2806、2000年4月、 "電話のURLコール"。
[8] Howes, T. and M. Smith, "An LDAP URL Format", RFC 1959, June 1996.
[8]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 1959、1996年6月。
[9] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[9]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[10] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[10] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[11] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[11] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
Author's Address
著者のアドレス
Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA
パトリックFaltstromシスコシステムズ株式会社170 WタスマンドライブSJ-2分の13サンノゼCA 95134 USA
EMail: paf@cisco.com URI: http://www.cisco.com
電子メール：paf@cisco.com URI：http://www.cisco.com
Appendix A. Scenario
付録A.シナリオ
Say that the content of the e164.arpa zone is the following:
e164.arpaゾーンの内容は以下の通りであることを言います：
$ORIGIN e164.arpa. 6.4 IN NS ns.regulator-e164.example.se.
$ ORIGINのe164.arpa。 6.4 NS ns.regulator-e164.example.se。
The regulator has in turn given a series of 10000 numbers to the telco with the name Telco-A. The regulator because of that has in his DNS.
レギュレータは、順番に名前のTelco-Aとの電話会社に10000の一連の番号を与えています。そのためのレギュレータは、彼のDNSにあります。
$ORIGIN 6.4.e164.arpa. 6.7.9.8 IN NS ns.telco-a.example.se.
$ ORIGINの6.4.e164.arpa。 NSのns.telco-a.example.se、IN 6.7.9.8。
A user named Sven Svensson has from Telco A got the phone number +46-8-9761234. The user gets the service of running DNS from the company Redirection Service. Sven Svensson has asked Telco A to point out Redirection Service as the authoritative source for information about the number +46-8-9761234. Telco A because of this puts in his DNS the following.
スヴェン・スベンソンという名前のユーザが電話会社Aから+ 46-8-9761234電話番号を持っています。ユーザーは、会社のリダイレクトサービスからDNSを実行しているのサービスを取得します。スヴェン・スベンソンは数+ 46-8-9761234に関する情報の信頼できるソースとしてリダイレクトサービスを指摘する電話会社Aを求めています。このための電話会社のAは、彼のDNSに次のようになります。
$ORIGIN 6.7.9.8.6.4.e164.arpa. 4.3.2.1 IN NS ns.redirection-service.example.se.
$ ORIGINの6.7.9.8.6.4.e164.arpa。 NSのns.redirection-service.example.se、IN 4.3.2.1。
Sven Svensson has already plain telephony from Telco A, but also a SIP service from the company Sip Service which provides Sven with the SIP URI "sip:sven@sips.se". The ISP with the name ISP A runs email and webpages for Sven, under the email address sven@ispa.se, and URI http://svensson.ispa.se.
スヴェン・スベンソンはすでに平野電話会社Aからの電話が、また、SIP URI「：sven@sips.se SIP」とスヴェンを提供する企業SIPサービスからのSIPサービスを提供しています。名前ISP AとISPは、電子メールアドレスsven@ispa.seの下で、スヴェンのための電子メールやWebページを実行し、URI http://svensson.ispa.se。
The DNS for the redirection service because of this contains the following.
このためのリダイレクトサービスのDNSには、次が含まれています。
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:sven@sips.se!" . IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:sven@ispa.se!" . IN NAPTR 10 10 "u" "http+E2U" "!^.*$!http://svensson.ispa.se!" . IN NAPTR 10 10 "u" "tel+E2U" "!^.*$!tel:+46-8-9761234!" .
$ ORIGINの4.3.2.1.6.7.9.8.6.4.e164.arpa。 10 NAPTR 10に "U" "SIP + E2U" "^ * $一口：！。！sven@sips.se！" 。 NAPTR 10 10 "U" "のmailto + E2U" IN "！^ * $のmailto：。！sven@ispa.se！" 。 "U" "HTTP + E2U" 10 NAPTR 10 IN "^ * $のhttp：！。！//svensson.ispa.se！" 。 NAPTR 10 10 "U" "TEL + E2U" "！。！^ * $ TEL：+ 46-8-9761234！" 。
A user, John Smith, want to contact Sven Svensson, he to start with only has the E.164 number of Sven, i.e. +46-8-9761234. He takes the number, and enters the number in his communication client, which happen to know how to handle the SIP protocol. The client removes the dashes, and ends up with the E.164 number +4689761234. That is what is used in the algorithm for NAPTR records, which is as follows.
ユーザー、ジョン・スミスは、唯一のスヴェンのE.164番号、すなわち+ 46-8-9761234を持っていると彼が開始する、スヴェン・スベンソンに連絡したいと思います。彼は数を取り、SIPプロトコルを処理する方法を知っているために起こる彼の通信クライアントで番号を入力します。クライアントは、ダッシュを削除し、E.164番号4689761234で終わります。それは次のようであるNAPTRレコードのアルゴリズムで使用されているものです。
The client converts the E.164 number into the domain name 4.3.2.1.6.7.9.8.6.4.e164.arpa., and queries for NAPTR records for this domainname. Using DNS mechanisms which includes following the NS record referrals, the following records are returned:
クライアントが。ドメイン名4.3.2.1.6.7.9.8.6.4.e164.arpaにE.164番号に変換し、このドメイン名のためのNAPTRレコードのクエリ。 NSレコードの参照を含む、以下のDNSメカニズムを使用して、次のレコードが返されます。
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:sven@sips.se" . IN NAPTR 10 10 "u" "mailto+E2U" "!^.*$!mailto:sven@ispa.se" . IN NAPTR 10 10 "u" "http+E2U" "!^.*$!http://svensson.ispa.se" . IN NAPTR 10 10 "u" "tel+E2U" "!^.*$!tel:+46-8-9761234" .
$ ORIGINの4.3.2.1.6.7.9.8.6.4.e164.arpa。 "！。！^ * $一口：sven@sips.se" NAPTR 10 10 "U" "SIP + E2U" IN。 NAPTR 10 10 "U" "のmailto + E2U" "^ * $のmailto：！。！sven@ispa.se"。 NAPTR 10 10 "U" "のhttp + E2U" "！。！^ * $のhttp：//svensson.ispa.se"。 10 NAPTR 10に "U" "TEL + E2U" "！。！^ * $ TEL：+ 46-8-9761234"。
Because the client knows sip, the first record above is selected, and the regular expression "!^.*$!sip:sven@sips.se" is applied to the original string, "+4689761234". The output is "sip:sven@sips.se" which is used according to SIP resolution.
クライアントは、SIPを知っているので、上記の最初のレコードが選択され、正規表現「^ * $一口：！。！sven@sips.se」を元の文字列、「4689761234」に適用されます。 SIPの解像度に応じて使用される：「sven@sips.se SIP」が出力されます。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。