Network Working Group J. Peterson
Request for Comments: 3824 H. Liu
Category: Informational J. Yu
NeuStar
B. Campbell
dynamicsoft
June 2004
Using E.164 numbers with the Session Initiation Protocol (SIP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number.
電話番号はENUMによって対処することができますそれらの多くは、セッション開始プロトコル（SIP）アプリケーションで採用されているコンテキストの数があります。 SIPは、ENUMが作成されたプライマリアプリケーションの一つであったが、SIP実装でENUMを統合するための手順を定義する必要があるにもかかわらず存在します。この文書では、2つのプロトコルは、コンサートで働くかもしれない方法を示し、およびSIPアプリケーション用のオーサリングとENUMレコードの処理を明確にしています。また、ENUMは、何らかの理由で、電話番号を解決するために使用することができないのインスタンスのためのガイドラインを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 6
5.1. The Service Field . . . . . . . . . . . . . . . . . . . 6
5.2. Creating the Regular Expression: Matching . . . . . . . 6
5.3. Creating the Regular Expression: The URI . . . . . . . . 7
5.4. Setting Order and Preference amongst Records . . . . . . 8
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP. 8
6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 8
6.1. Contending with Multiple SIP records . . . . . . . . . . 8
6.2. Processing the Selected NAPTR Record . . . . . . . . . . 9
7. Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [4]) in order to translate certain telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC 2396 [9]), like 'sip:user@sipcarrier.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. E.164 [10] is the ITU-T standard international numbering plan, under which all globally-reachable telephone numbers are organized.
ENUM（E.164番号マッピングは、RFC 3761 [1]）、DNS（ドメインネームサービス、RFC 1034 [4]）のURIに、「12025332600」のように、特定の電話番号を変換するために、（ユニフォーム・リソースを使用するシステムであります識別子、RFC 2396 [9]）、 'SIP：user@sipcarrier.com' のような。 ENUMは、ルート取引にURIを使用するものとの電話番号に依存しているシステムの相互接続を容易にするために、主に存在しています。 E.164 [10]は、すべてのグローバルに到達可能な電話番号が編成され、その下ITU-T標準の国際番号計画、です。
SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based application protocol that allows two endpoints in the Internet to discover one another in order to exchange context information about a session they would like to share. Common applications for SIP include Internet telephony, instant messaging, video, Internet gaming, and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously.
SIP（セッション開始プロトコル、RFC 3261 [2]）は、インターネットにおける2つのエンドポイントは、それらが共有したいセッションに関するコンテキスト情報を交換するために互いを発見することを可能にするテキストベースのアプリケーションプロトコルです。 SIPのための一般的なアプリケーションは、インターネット電話、インスタントメッセージング、ビデオ、インターネットゲーム、およびリアルタイムコミュニケーションの他の形態を含みます。 SIPは、同時にリアルタイム通信の異なる形態を含むセッションを開始することができるマルチサービスプロトコルです。
The most widespread application for SIP today is Voice-over-IP (VoIP). As such, there are a number of cases in which SIP applications are forced to contend with telephone numbers. Unfortunately, telephone numbers cannot be routing in accordance with the traditional DNS resolution procedures standardized for SIP (see [14]), which rely on SIP URIs. ENUM provides a method for translating E.164 numbers into URIs, including potentially SIP URIs. This document therefore provides an account of how SIP can handle telephone numbers by making use of ENUM. Guidelines are proposed for the authoring of the DNS records used by ENUM, and for client-side processing once these DNS records have been received.
SIPのための最も普及しているアプリケーションは、今日は、ボイスオーバーIP（VoIP）です。このように、SIPアプリケーションは電話番号と競合することを余儀なくされる場合の数があります。残念ながら、電話番号をSIPのために標準化伝統的なDNS解決の手順に従ってルーティングすることができない（参照[14]）、SIPのURIに依存しています。 ENUMは、潜在的にSIP URIを含むURIを、にE.164番号を変換するための方法を提供します。この文書では、したがって、SIPは、ENUMを利用して電話番号を扱うことができるかのアカウントを提供します。ガイドラインは、ENUMで使用されるDNSレコードの作成のために提案されており、クライアント側の処理のためにこれらのDNSレコードが受信された後。
The guidelines in this document are oriented towards authoring and processing ENUM records specifically for SIP applications. These guidelines assume that the reader is familiar with Naming Authority Pointer (NAPTR) records (RFC 3403 [6]) and ENUM (RFC 3761 [1]). Only those aspects of NAPTR record authoring and processing that have special bearing on SIP, or that require general clarification, are covered in this document; these procedures do not update or override the NAPTR or ENUM core documents.
この文書のガイドラインは、特にSIPアプリケーションのためのオーサリングと処理ENUMレコードの方に向いています。これらのガイドラインは、読者が権限ポインタ（NAPTR）レコードを（RFC 3403 [6]）とENUMネーミングに精通していると仮定する（RFC 3761 [1]）。のみがSIPに特別なベアリングを持っているNAPTRレコードのオーサリングと処理の側面、または一般的な明確化を要求し、この文書で覆われています。これらの手順は、NAPTRやENUMコアドキュメントを更新するか、または無効にしません。
Note that the ENUM specification has undergone a revision shortly before the publication of this document, driven by the update of the NAPTR system described in RFC 2915 [12] to the Dynamic Delegation Discovery System (DDDS) family of specifications (including RFC 3403). This document therefore provides some guidance for handling records designed for the original RFC 2916 [16].
ENUM仕様は、すぐにこの文書の出版前にリビジョンを受け（RFC 3403を含む）仕様のダイナミックな委譲発見システム（DDDS）ファミリーにRFC 2915 [12]に記載のNAPTRシステムの更新によって駆動していることに留意されたいです。従って、この文書は、元のRFC 2916 [16]のために設計されたレコードを処理するためのいくつかのガイダンスを提供します。
The remainder of this document is organized as follows: Section 3 suggests general behavior for SIP user agents that encounter telephone numbers; Section 4 provides an overview of the intersection of SIP and ENUM; proposed normative guidelines for ENUM record authoring and processing in the context of SIP are described in Section 5, and Section 6 respectively; some considerations relevant to the revision of RFC 2916 are given in Section 7.
次のように、この文書の残りの部分は構成されています第3の電話番号に遭遇するSIPユーザエージェントのための一般的な挙動を示唆しています。セクション4は、SIPとENUMの交点の概要を提供します。 SIPのコンテキストにおけるENUMレコードオーサリング及び処理のために提案された規範ガイドラインは、それぞれ第5、及び第6節に記載されています。 RFC 2916の改定に関連するいくつかの考慮事項は、セクション7に与えられています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、及び「OPTIONAL」は、RFC 2119 [3]に記載のコンプライアントSIP実装の要求レベルを示すものとして解釈されるべきです。
There are a number of reasons why a user might want to initiate a SIP request that targets an E.164 number. One common reason is that the user is calling from the PSTN through a PSTN-SIP gateway; such gateways usually map routing information from the PSTN directly on to SIP signaling. Or a native SIP user might intentionally initiate a session addressed to an E.164 number - perhaps because the target user is canonically known by that number, or the originator's SIP user agent only supports a traditional numeric telephone keypad. A request initially targeting a conventional SIP URI might also be redirected to an E.164 number. In most cases, these are requests for a telephony session (voice communication), though numerous other services are also reached through telephone numbers (including instant messaging services).
ユーザーがE.164番号を対象SIP要求を開始することをお勧めします理由はたくさんあります。一つの一般的な理由は、ユーザがPSTNからPSTN-SIPゲートウェイを介して呼び出していることです。そのようなゲートウェイは、通常、SIPシグナリング上に直接PSTNからのルーティング情報をマッピングします。ターゲットユーザーは、標準的にその数で知られているかもしれないので、または発信者のSIPユーザエージェントは、伝統的な数字の電話機のキーパッドをサポートしています - または意図的にセッションを開始する可能性があるネイティブSIPユーザーはE.164番号に対処しました。最初に、従来のSIP URIを標的とする要求は、E.164番号にリダイレクトされるかもしれません。数多くの他のサービスでも（インスタント・メッセージング・サービスを含む）の電話番号を介して到達しているが、ほとんどの場合、これらは、電話セッション（音声通信）のための要求です。
Unlike a URI, a telephone number does not contain a host name, or any hints as to where one might deliver a request targeting a telephone number on the Internet. While SIP user agents or proxy servers could be statically provisioned with a mapping of destinations corresponding to particular telephone numbers or telephone number ranges, considering the size and complexity of a complete mapping, it would be preferable for SIP user agents to be able to query as needed for a destination appropriate for a particular telephone number.
URIとは異なり、電話番号は1つが、インターネット上の電話番号をターゲットに要求を配信する可能性がある場所に、ホスト名、または任意のヒントが含まれていません。 SIPユーザエージェントまたはプロキシサーバは、静的に特定の電話番号に対応する宛先のマッピングまたは電話番号をプロビジョニングすることができるが、完全なマッピングの大きさと複雑さを考慮すると、範囲SIPユーザエージェントとして照会できるようにするために、それは好ましいであろう特定の電話番号のための適切な宛先のために必要。
In such cases a user agent might use ENUM to discover a URI associated with the E.164 number - including a SIP URI. URIs discovered through ENUM can then be used normally to route SIP requests to their destination. Note that support for the NAPTR DNS resource record format is specified for ordinary SIP URI processing in [14], and thus support for ENUM is not a significant departure from baseline SIP DNS routing.
SIP URIを含む - そのような場合、ユーザエージェントは、E.164番号に関連付けられたURIを発見するためにENUMを使用するかもしれません。その後、彼らの目的地までの経路SIPリクエストに、通常使用することができURIはENUMで発見しました。 NAPTR DNSリソースレコードフォーマットのそのサポートは[14]に通常SIP URI処理のために指定され、従って、ENUMベースラインSIPのDNSルーティングから有意の逸脱ではないためにサポートされます。
Most of the remainder of this document provides procedures for the use of ENUM, but a few guidelines are given in the remainder of this section for cases in which ENUM is not used, for whatever reason.
この文書の残りの大部分は、ENUMを使用するための手順を提供しますが、いくつかのガイドラインは、ENUMが何らかの理由で、使用されていない場合は、このセクションの残りの部分に記載されています。
If a user agent is unable to translate an E.164 number with ENUM, it can create a type of SIP Request-URI that contains a telephone number. Since one of the most common applications of SIP is telephony, a great deal of attention has already been devoted to the representation of telephone numbers in SIP. In particular, the tel URL RFC 2806 [8] has been identified as a way of carrying telephone routing information within SIP. A tel URL usually consists of the number in E.164 format preceded by a plus sign, e.g.,: tel:+12025332600. This format is so useful that it has been incorporated into the baseline SIP specification; the user portion of a SIP URI can contain a tel URL (without the scheme string, like sip:+12025332600@carrier.com;user=phone). A SIP proxy server might therefore receive a request from a user agent with a tel URL in the Request-URI; one way in which the proxy server could handle this sort of request is by launching an ENUM query itself, and proxying the SIP request in accordance with the returned ENUM records.
ユーザーエージェントは、ENUMとE.164番号を変換することができない場合は、電話番号が含まれているSIPリクエスト-URIのタイプを作成することができます。 SIPの最も一般的な用途の一つは、電話であるので、大きな注目はすでにSIPの電話番号の表現に専念してきました。特に、TEL用URLのRFC 2806 [8] SIP内の電話ルーティング情報を運ぶ方法として同定されています。 TEL URLは通常、プラス記号、例えばが先行E.164形式の番号で構成され、：。TEL：12025332600。このフォーマットは、それがベースラインSIP仕様に組み込まれているように有用です。 SIP URIのユーザ部分（：、ユーザー=電話+12025332600@carrier.com SIPのようなスキーム列せず）TEL URLを含むことができます。 SIPプロキシサーバは、そのためのRequest-URI中のtel URLとユーザーエージェントからの要求を受け取ることがあります。プロキシサーバーは、要求のこの種を扱うことができる1つの方法は、ENUMクエリー自体を起動すると、返されたENUMレコードに従い、SIPリクエストをプロキシです。
In the absence of support for ENUM, or if ENUM requests return no records corresponding to a telephone number, local policy can be used to determine how to forward SIP requests with an E.164 number in the Request-URI. Frequently, such calls are routed to gateways that interconnect SIP networks with the PSTN. These proxy server policies might be provisioned dynamically with routing information for telephone numbers by TRIP [15]. As a matter of precedence, SIP user agents should attempt to translate telephone numbers to URIs with ENUM, if implemented, before creating a tel URL, and deferring the routing of this request to a SIP proxy server.
ENUMのためのサポートがない場合、またはENUM要求が電話番号に対応するレコードを返さない場合、ローカルポリシーがRequest-URIにE.164番号をSIPリクエストを転送する方法を決定するために使用することができます。しばしば、このような呼び出しは、PSTNとのその相互接続SIPネットワークをゲートウェイにルーティングされます。これらのプロキシサーバーのポリシーはTRIP [15]によって、電話番号のルーティング情報を動的にプロビジョニングすることがあります。優先度の高い問題として、SIPユーザエージェントは、TELのURLを作成し、SIPプロキシサーバにこの要求のルーティングを延期する前に、実装されている場合、ENUMとURIに電話番号を変換しようとしなければなりません。
Although the applicability of ENUM to SIP has always been clear, the exact way in which the two should cooperate has been a subject of some controversy. How many SIP URIs should appear in ENUM, what kind of URIs they are, whether or not the "service" field of NAPTR records should contain capability information - numerous questions have arisen around the authoring, and interpretation of ENUM records for SIP consumers. The following, then, is a statement of the particular philosophy that has motivated the recommendations in this document:
SIPへのENUMの適用性が必ずしも明確であったが、両者が協力するべき正確な方法は、いくつかの論争の対象となっています。どのように多くのSIP URIは、ENUMに表示され、彼らはNAPTRレコードの「サービス」フィールドには、機能情報が含まれているかどうか、URIのどのような種類がある - 数多くの質問は、オーサリングの周りに生じ、およびSIPの消費者のためのENUMレコードの解釈しています。以下は、それから、このドキュメントの推奨事項を動機としている特定の哲学の声明であります：
Address-of-record SIP URIs appear in ENUM, not contact address URIs. Roughly speaking, an address-of-record is the canonical identity of a SIP user - it usually appears in the From field of SIP requests sent by that user; a contact address is the URI of a device. The process of registration in SIP (using the REGISTER method), for example, temporarily binds the contact address of a device to the address-of-record of a user. A DNS record has a long time-to-live when compared with the timeframe of SIP registrations. The availability of an address-of-record also transcends the availability of any single device. ENUM is more suitable for representing an long-term identity than the URI of any device with which a user is temporarily associated. If ENUM were purposed to map to specific devices, it would be better to translate telephone numbers to IPv4 addresses than to URIs (which express something richer).
アドレスのレコードSIP URIはアドレスURIを連絡していない、ENUMに表示されます。大雑把に言えば、アドレス・オブ・レコードはSIPユーザの正規のアイデンティティである - それは通常、そのユーザによって送信されたSIPリクエストのからフィールドに表示されます。連絡先アドレスは、デバイスのURIです。 SIPの登録処理（REGISTERメソッドを使用して）、例えば、一時的にユーザのアドレス・オブ・レコードにデバイスの連絡先と結合します。 DNSレコードは、長い生存時間SIP登録の期限と比較しています。アドレス・オブ・レコードの利用可能性はまた、任意の単一デバイスの可用性を超越します。 ENUMは、ユーザが一時的に関連付けられている任意のデバイスのURIより長期のアイデンティティを表現するため、より好適です。 ENUMは、特定のデバイスにマップすることを目的していた場合、（何か、より豊かな表現）のURIよりもIPv4アドレスに電話番号を変換する方が良いだろう。
SIP URIs in ENUM do not convey capability information. SIP has its own methods for negotiating capability information between user agents (see SDP [13], the use of Require/Supported to negotiate extensions in RFC 3261, and callee capabilities [11]); providing more limited capability information within ENUM is at best redundant and at worst potentially misleading to SIP's negotiation system. Also, addresses-of-record do not have capabilities (only devices registered under an address-of-record have actual capabilities), and putting contact addresses in ENUM is not recommended.
ENUMでのSIP URIは、能力情報を伝えていません。 SIPは、（SDP [13]、要求/ RFC 3261に拡張機能を交渉するサポートの使用、呼び出し機能[11]を参照）、ユーザエージェント間の能力情報を交渉するための独自の方法を有します。 ENUM内のより限定された能力情報を提供することで、最高の冗長と、最悪の場合SIPの交渉システムに潜在的に誤解を招く恐れがあります。また、アドレス・オブ・レコードが（アドレスのレコードの下で登録されたデバイスのみが実際の能力を持っている）の機能を持っていない、とENUMのコンタクトアドレスを置くことはお勧めしません。
Only one SIP URI, ideally, appears in an ENUM record set for a telephone number. While it may initially seem attractive to provide multiple SIP URIs that reach the same user within ENUM, if there are multiple addresses at which a user can be contacted, considerably greater flexibility is afforded if multiple URIs are managed by a SIP location service that is identified by a single record in ENUM. Behavior for parallel and sequential forking in SIP, for example, is better managed in SIP than in a set of ENUM records.
唯一のSIP URIは、理想的には、電話番号に設定されたENUMレコードに表示されます。それは最初に、ユーザーが連絡可能な複数のアドレスがある場合は、ENUM内の同じユーザに達する複数のSIP URIを提供するために、魅力的に見えるかもしれませんが、複数のURIが識別されたSIPロケーションサービスによって管理されている場合は、かなり大きな柔軟性がもたらされますENUMでの単一のレコードによります。 SIPにおける並列とシーケンシャルフォークのための行動は、例えば、より良いENUMレコードのセットよりもSIPで管理されています。
User agents, rather than proxy servers, should process ENUM records. The assumptions underlying the processing of NAPTR records dictate that the ENUM client knows the set of enumservices supported by the entity that is attempting to communicate. A SIP proxy server is unlikely to know the enumservices supported by the originator of a SIP request.
ユーザーエージェントではなく、プロキシサーバは、ENUMレコードを処理する必要があります。 NAPTRレコードの処理の基礎となる仮定は、ENUMクライアントが通信しようとしているエンティティによってサポートenumservicesのセットを知っていることを指示します。 SIPプロキシサーバは、SIP要求の発信元でサポートされているenumservicesを知っていることはほとんどありません。
This document makes no assumptions about who authors NAPTR records (service providers or end users), nor about any mechanisms by which a record, once it is authored, may be uploaded to the appropriate DNS servers. Authorship in the context of this document concerns only the processes by which the NAPTR records themselves are constructed.
この文書では、著者のNAPTRレコード（サービスプロバイダまたはエンドユーザー）に関する仮定をしない、また任意のメカニズムについてどのレコードで、それが執筆された後、適切なDNSサーバにアップロードすることができます。 NAPTRが自分自身を記録することにより、プロセスだけが構築されている。この文書の懸念の文脈で著者。
There are a few general guidelines which are applicable to the authoring of DNS records that should be considered by the authors of ENUM NAPTR record sets. The most important is that authors SHOULD keep record sets relatively small - DNS is not optimized for the transference of large files. Having five or six NAPTR records is quite reasonable, but policies that encourage records sets of hundreds of NAPTR records are not appropriate. Also, DNS records are relatively permanent; authors SHOULD NOT use ENUM NAPTR records to express relationships between E.164 numbers and URIs that potentially exist for only a short time. DNS is most scalable when it can assume records will be valid for a reasonable length of time (at least several hours).
ENUM NAPTRレコードセットの作成者によって考慮されるべきであるDNSレコードの作成に適用されるいくつかの一般的なガイドラインがあります。 DNSは、大きなファイルの転移のために最適化されていない - 最も重要なのは、著者は、比較的小さなレコードセットを保つべきであるということです。五枚の、六NAPTRレコードを持つことは非常に合理的ですが、NAPTRレコードの数百のレコードのセットを奨励する政策は適切ではありません。また、DNSレコードが比較的永続的です。著者は、潜在的に短時間しか存在してE.164番号とURIの間の関係を表現するためにENUM NAPTRレコードを使用しないでください。それはレコードは時間の合理的な長さ（少なくとも数時間）のために有効であると仮定することができたときにDNSが最もスケーラブルです。
The Service field of a NAPTR record (per RFC 3403) contains a string token that designates the protocol or service associated with a particular record (and which imparts some inkling of the sort of URI that will result from the use of the record). ENUM [1] requires the IANA registration of service fields known as "enumservices".
（RFC 3403あたり）NAPTRレコードのServiceフィールドには、特定のレコード（およびそのレコードの使用からもたらされるURIの種類のいくつかの暗示を与える）に関連付けられたプロトコルまたはサービスを指定する文字列トークンを含みます。 ENUMは、[1]「enumservices」として知られるサービスフィールドのIANA登録を必要とします。
An enumservice for SIP has been developed in the ENUM working group (see [7]) which uses the format 'E2U+sip' to designate that a SIP address-of-record appears in the URI field of a NAPTR record. It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip' service field whenever the regexp contains a SIP address-of-record URI.
SIPのためenumserviceはENUMワーキンググループで開発された形式「E2U +一口」を使用するSIPアドレスのレコードがNAPTRレコードのURIフィールドに表示されることを指定する（[7]を参照）。ことを強く正規表現は、SIPアドレス・オブ・レコードのURIが含まれている時はいつでもNAPTRレコードの著者は「E2U +一口」サービスフィールドを使用することをお勧めします。
The authorship of the regular expression (henceforth regexp) in a NAPTR record intended for use by ENUM is vastly simplified by the absence of an antecedent in the substitution (i.e., the section between the first two delimiters). It is RECOMMENDED that implementations use an exclamation point as a delimiter, since this is the only delimiter used throughout the ENUM core specification.
ENUMが使用するためのものNAPTRレコードの正規表現（以下、正規表現）の原作者は、非常に置換における先行の欠如によって単純化される（すなわち、最初の二つのデリミタの間の区間）。 ENUMコア明細書を通して使用される唯一の区切り文字であるため実装が、区切り文字として感嘆符を使用することをお勧めします。
When a NAPTR record is processed, the expression in the antecedent is matched against the starting string (for ENUM, the telephone number) to assist in locating the proper record in a set; however, in ENUM applications, since the desired record set is located through a reverse resolution in the e164.arpa domain that is based on the starting string, further analysis of the starting string on the client side will usually be unnecessary. In such cases, the antecedent of the regular expression is commonly 'greedy' - it uses the regexp '^.*$', which matches any starting string. Some authors of ENUM record sets may want to use the full power of regexps, and create non-greedy antecedents; the DDDS standard requires that ENUM resolvers support these regexps when they are present. For providing a trivial mapping from a telephone number to a SIP URI, the use of a greedy regexp usually suffices.
NAPTRレコードが処理されるときに、先行詞で式（ENUM電話番号用）セット内の適切なレコードを配置するのを助けるために、開始列と照合されます。所望のレコードセットが開始文字列に基づいてe164.arpaドメインに逆解像度を介して配置されているので、ENUMアプリケーションで、クライアント側で開始文字列のさらなる分析は、通常は不要であろう。このような場合には、正規表現の先行詞は、一般に「貪欲」である - それは、任意の開始文字列にマッチする正規表現「^ * $」を使用しています。 ENUMレコードセットの一部の著者は、正規表現のフルパワーを使用し、非貪欲先例を作成することもできます。 DDDS標準は、それらが存在するとき、ENUMリゾルバは、これらの正規表現をサポートする必要があります。 SIP URIに電話番号からの些細なマッピングを提供するため、貪欲正規表現の使用は、通常十分です。
Example: "!^.*$!sip:user@example.com!"
例： "！。！^ * $一口：user@example.com！"
Note that when the antecedent of the regexp is greedy, this does not mean that the replacement field in NAPTR records provides a viable alternative to authoring with a regexp. Authors of NAPTR records for ENUM MUST NOT use the replacement field in records with an 'E2U+sip' service field.
正規表現の先行詞は貪欲であるとき、これはNAPTRレコードで置換フィールドは、正規表現でオーサリングするための実行可能な代替手段を提供することを意味しないことに注意してください。 ENUMのためのNAPTRレコードの著者は、「E2U +一口」サービスフィールドを持つレコードに置換フィールドを使用してはなりません。
The consequent side of a regexp contains a URI; NAPTR records that are intended to be used for session initiation (including SIP telephony) SHOULD use a SIP URI. While this may not sound especially controversial at first hearing, there are other sorts of URIs that might be considered appropriate for SIP applications: 'tel' URIs, 'im' or 'pres' URIs, or others that describe specific services that might be invoked through SIP are all potentially candidates. While the use of these URIs might seem reasonable under some circumstances, including these in NAPTR records rather than SIP URIs could weaken the proper composition of services and negotiation of capabilities in SIP.
正規表現の結果として側はURIを含みます。 （SIPテレフォニーを含む）のセッション開始のために使用されることを意図しているNAPTRレコードは、SIP URIを使用すべきです。 「TEL」のURI「イム」または「PRES」のURI、または他呼び出される可能性がある特定のサービスについて説明します。これは最初の公聴会で、特に物議鳴らないかもしれないが、SIPアプリケーションのために適切な考えられるかもしれないURIの他の種類がありますSIPを介してすべての潜在的な候補です。これらのURIの使用を含む、いくつかの状況下で合理的に見えるかもしれませんがNAPTRレコードではなく、SIP URIの中にこれらは、SIPにおける能力の適切なサービスの組成と交渉を弱めることができます。
It is RECOMMENDED that authors of ENUM records should always use the SIP or SIPS URI scheme when the service field is 'E2U+sip', and the URIs in question MUST be addresses-of-record, not contact addresses.
ENUMレコードの作成者は常にSIPを使用するか、サービス分野は「E2U +一口」であり、かつ当該のURIはアドレス-のレコードでなければならない、アドレスを連絡していないとき、URIスキームをSIPSことをお勧めします。
Users of SIP can register one or more contact addresses with a SIP registrar that will be consulted by the proxy infrastructure of an administrative domain to contact the end user when requests are received for their address-of-record. Much of the benefit of using a URI comes from the fact that it represents a logical service associated with a user rather than a device - indeed, if ENUM needs to target specific devices rather than URIs, then a hypothetical 'E2IPv4+sip' enumservice would be more appropriate.
SIPのユーザーは、要求がそのアドレスのレコードのために受信された場合、エンドユーザーに連絡する管理ドメインのプロキシインフラストラクチャによって相談されるSIPレジストラで一個の以上のコンタクトアドレスを登録することができます。 URIを使用する利点の多くは、それがユーザーに関連付けられた論理サービスではなく、デバイスを表しているという事実から来ている - 確かに、ENUMはむしろURIのより特定のデバイスをターゲットにする必要がある場合は、仮想的な「E2IPv4 +一口」enumserviceだろうより適切な。
For maximal compatibility authors of ENUM records for SIP SHOULD always use the same order value for all NAPTR records in an ENUM record set. If relative preference among NAPTR records is desirable, it should be expressed solely with the preference field.
最大の互換性のためにSIPのためのENUMレコードの作成者は、常にENUMレコードセット内のすべてのNAPTRレコードの同じ順序の値を使用する必要があります。 NAPTRレコードのうち相対的嗜好が望ましい場合には、優先フィールドでのみ発現されるべきです。
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" .
$ ORIGINの0.0.6.2.3.3.5.2.0.2.1.e164.arpa。 10 NAPTR 100内の "U" "E2U +一口" "^ * $一口：！。！user@example.com！" 。 20 NAPTR 100内の "U" "E2U +のmailto" "^ * $のmailto：！。！！info@example.com" 。
These guidelines do not by any means exhaustively describe the NAPTR algorithm or the processing of NAPTR records; implementers should familiarize themselves with the DDDS algorithm and ENUM before reviewing this section.
これらのガイドラインは、任意の手段によって徹底的NAPTRアルゴリズムまたはNAPTRレコードの処理を記述していません。実装者は、このセクションを検討する前にDDDSアルゴリズムとENUMに慣れる必要があります。
Although in some cases, ENUM record sets will consist only a single 'E2U+sip' record, this section assumes that integrators of ENUM and SIP must be prepared for more complicated scenarios - however, just because we recommend that clients should be generous in what they receive, and try to make sense of potentially confusing NAPTR records, that does not mean that we recommend any of the potentially troublesome authoring practices that make this generosity necessary.
しかし、私たちは、クライアントが何に寛大でなければならないことをお勧めしますという理由だけで - いくつかのケースでは、ENUMレコードセットのみシングル「E2U +一口」レコードで構成されますが、このセクションでは、ENUMとSIPのインテグレータは、より複雑なシナリオのために準備しなければならないことを前提としてい彼らは我々がこの寛大さが必要で行い、潜在的に厄介なオーサリング慣行のいずれかをお勧めすることを意味するものではありませんので、受信、および潜在的に混乱NAPTRレコードの意味を理解してみてください。
If an ENUM query returns multiple NAPTR records that have a service field of 'E2U+sip', or other service field that may be used by SIP (such as 'E2U+pres', see [17]) the ENUM client must first determine whether or not it should attempt to make use of multiple records or select a single one. The pitfalls of intentionally authoring ENUM record sets with multiple NAPTR records for SIP are detailed above in Section 4.
ENUMクエリーは、SIPが使用することができる「E2U +一口」、または他のサービスフィールドのサービスフィールドを持つ複数のNAPTRレコードを返す場合ENUMクライアントが最初に決定しなければならない（例えば「E2U + PRES」として、[17]参照）かどうか、それは、複数のレコードを利用したり、単一のものを選択するように試みるべきです。意図的にSIPのための複数のNAPTRレコードは、セクション4で上に詳述されているとENUMレコードセットをオーサリングの落とし穴。
If the ENUM client is a user agent, then at some point a single NAPTR record must be selected to serve as the Request-URI of the desired SIP request. If the given NAPTR records have different preferences, the most preferred record SHOULD be used. If two or more records share most preferred status, the ENUM client SHOULD randomly determine which record will be used, though it MAY defer to a local policy that employs some other means to select a record.
ENUMクライアントはユーザ・エージェントである場合、ある時点で単一のNAPTRレコードは、所望のSIP要求の要求URIとして機能するように選択されなければなりません。与えられたNAPTRレコードが異なる嗜好を持っている場合は、最も好ましいのレコードを使用する必要があります。二つ以上のレコードが最も好ましい状況を共有している場合、ENUMクライアントは、ランダムにそれがレコードを選択するために、いくつかの他の手段を採用して、ローカルポリシーに延期するかもしれませんが、使用されるレコードを決定する必要があります。
If the ENUM client is a SIP intermediary that can act a redirect server, then it SHOULD return a 3xx response with more than one Contact header field corresponding to the multiple selected NAPTR records in an ENUM record set. If the NAPTR records have different preferences, then 'q' values may be used in the Contact header fields to correspond to these preferences. Alternatively, the redirect server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified) and send this resulting URI in a Contact header field in a 3xx response.
ENUMクライアントは、リダイレクトサーバとして作用することができるSIP仲介であれば、それはENUMレコードセット内の複数の選択されたNAPTRレコードに対応する複数のContactヘッダーフィールドとの3xx応答を返すべきです。 NAPTRレコードが異なる嗜好を持っている場合、「Q」の値は、これらの設定に対応するようにContactヘッダフィールドに使用することができます。代替的に、リダイレクトサーバは、（プリファレンスが指定されていない場合、ランダムに又は）NAPTR選好フィールドに応じて、単一のレコードを選択し、3xx応答のContactヘッダフィールドに、この得られたURIを送信してもよいです。
Otherwise, if the ENUM client is a SIP intermediary that can act as a proxy server, then it MAY fork the request when it receives multiple appropriate NAPTR records in an ENUM record set. Depending on the relative precedence values of the NAPTR records the proxy may wish to fork sequentially or in parallel. However, the proxy MUST build a route set from these NAPTR records that consists exclusively of SIP or SIPS URIs, not other URI schemes. Alternatively, the proxy server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified, or in accordance with local policy) and proxy the request with a Request-URI corresponding to the URI field of this NAPTR record - though again, it MUST select a record that contains a SIP or SIPS URI. Note that there are significant limitations that arise if a proxy server processes ENUM record sets instead of a user agent, and that therefore it is RECOMMENDED that SIP network elements act as redirect servers rather than proxy servers after performing an ENUM query.
それ以外の場合は、ENUMクライアントは、プロキシサーバとして機能することができ、それはENUMレコードセット内の複数の適切なNAPTRレコードを受信したとき、それは、要求をforkするかもしれSIP仲介である場合。 NAPTRの相対優先順位値に応じて、プロキシが、順次または並列にフォークすることを望むかもしれない記録します。しかし、プロキシは、排他的にSIPまたはSIPS URIの構成され、これらのNAPTRレコードではなく、他のURIスキームから設定した経路を構築する必要があります。あるいは、プロキシサーバは、Request-URIこのNAPTRのURIフィールドに対応するNAPTR選好フィールド（またはランダムにプリファレンスが指定されていない場合、またはローカルポリシーに従って）およびプロキシに応じて要求を単一のレコードを選択することができます。レコードは - 再びかかわらず、それはSIPが含まれているか、URIをSIPSレコードを選択する必要があります。プロキシサーバは、ENUMレコードではなく、ユーザーエージェントのセット、したがってSIPネットワーク要素は、ENUMクエリーを実行した後ではなくプロキシサーバよりのようなリダイレクトサーバとして作用することが推奨されていることを処理する場合に生じる重大な制限があることに注意してください。
Obviously, when an appropriate NAPTR record has been selected, the URI should be extracted from the regexp field. The URI is between the second and third exclamation points in the string. Once a URI has been extracted from the NAPTR record, it SHOULD be used as the Request-URI of the SIP request for which the ENUM query was launched.
適切なNAPTRレコードが選択されているとき明らかに、URIは正規表現、フィールドから抽出されなければなりません。 URIは、文字列内の第二及び第三の感嘆符の間です。 URIがNAPTRレコードから抽出された後、それがENUMクエリーが起動されたためのSIPリクエストのRequest-URIとして使用する必要があります。
SIP clients should perform some sanity checks on the URI, primarily to ensure that they support the scheme of the URI, but also to verify that the URI is well-formed. Clients MUST at least verify that the Request-URI does not target themselves.
SIPクライアントは主に、彼らはURIのスキームをサポートすることを保証するために、だけでなく、URIは、よく形成されていることを確認するために、URIにいくつかの健全性チェックを実行する必要があります。クライアントは、少なくとも要求URIが自分自身をターゲットにしないことを確かめなければなりません。
Once an address-of-record has been extracted from the selected NAPTR record, clients follow the standard SIP mechanisms (see [14]) for determining how to forward the request. This may involve launching subsequent NAPTR or SRV queries in order to determine how best to route to the domain identified by an address-of-record; clients however MUST NOT make the same ENUM query recursively (if the URI returned by ENUM is or contains a tel URL, see [8]).
アドレスのレコードが選択されたNAPTRレコードから抽出された後、クライアントは要求を転送する方法を決定するために（[14]参照）、標準的なSIPメカニズムに従います。これはどのように最善のルートへのアドレス・オブ・レコードによって識別されたドメインに決定するために、後続のNAPTRまたはSRVクエリーを起動伴うこと。クライアントがしかし、再帰的に同じENUMクエリーを作成してはならない（URIは、ENUMによって返された場合であるかのtel URLが含まれている、[8]を参照）。
Note that SIP requests based on the use of NAPTR records may fail for any number of reasons. If there are multiple NAPTR records relevant to SIP present in an ENUM record set, then after a failure has occurred on an initial attempt with one NAPTR record, SIP user agents MAY try their request again with a different NAPTR record from the ENUM record set.
NAPTRレコードの使用に基づいたSIPリクエストは任意の数の理由のために失敗する可能性があります。複数のNAPTRレコードがENUMレコードセットに存在SIPに関連がある場合は、障害が1枚のNAPTRレコードとの最初の試行で発生した後、その後、SIPユーザエージェントは、ENUMレコードセットとは異なるNAPTRレコードで再び彼らの要求をしようとします。
The ENUM specification is currently undergoing a revision in the ENUM WG. The new specification, RFC 3761 [1], is based on the Dynamic Delegation Discovery System [5] revision to the NAPTR resource record specified in RFC 2915 [12]. For the most part, DDDS is an organizational revision that makes the algorithmic aspects of record processing separable from any underlying database format (such as the NAPTR DNS resource record).
ENUMの仕様は、現在、ENUM WGでの改正を受けています。新しい仕様、RFC 3761 [1]、RFC 2915 [12]で指定されたNAPTRリソースレコードにダイナミックな委譲発見システム[5]リビジョンに基づいています。ほとんどの部分について、DDDSは、（NAPTR DNSリソースレコードなど）の任意の基礎となるデータベースのフォーマットから記録処理のアルゴリズムの態様が分離可能になり、組織改正です。
The most important revision in RFC 3761 is the concept of enumservices. The original ENUM specification, RFC 2916, specified a number of "service" values that could be used for ENUM, including the "sip+E2U" service field. RFC 3761 introduces an IANA registration system with new guidelines for the registration of enumservices, which are no longer necessarily divided into discreet "service" and "protocol" fields, and which admit of more complex structures. In order to differentiate enumservices in RFC 3761 from those in RFC 2916, the string "E2U" is the leading element in an enumservice field, whereas by RFC 2916 it was the trailing element.
RFC 3761の中で最も重要な改正はenumservicesの概念です。オリジナルENUM仕様RFC 2916は、「SIP + E2U」サービスフィールドを含むENUMを使用することができる「サービス」値の数を、指定されました。 RFC 3761は、もはや必ずしも控えめな「サービス」および「プロトコル」フィールドに分割され、より複雑な構造を認めるenumservicesの登録のための新しいガイドライン、とIANA登録システムを導入しています。 RFC 2916によってそれがトレーリング要素であったのに対し、RFC 2916のものとRFC 3761でenumservicesを区別するために、文字列「E2U」は、enumserviceフィールドの先頭要素です。
An enumservice for SIP addresses-of-record is described in [7]. This enumservice uses the enumservice field "E2U+sip". RFC 3761-compliant authors of ENUM records for SIP MUST therefore use the "E2U+sip" enumservice field instead of the "sip+E2U" field. For backwards compatibility with existing legacy records, however, the 'sip+E2U' field SHOULD be supported by an ENUM client that support SIP.
SIPアドレス・オブ・レコードのenumserviceは、[7]に記載されています。このenumserviceはenumserviceフィールド「E2U +一口」を使用しています。 SIPのためのENUMレコードのRFC 3761に準拠した著者は、したがって、代わりに「SIP + E2U」フィールドの「E2U +一口」enumserviceフィールドを使用しなければなりません。既存のレガシーレコードとの後方互換性のために、しかし、「SIP + E2U」フィールドは、SIPをサポートするENUMクライアントによってサポートされる必要があります。
Also note that the terminology of DDDS differs in a number of respects from the initial NAPTR terminology in RFC 2916. DDDS introduces the concept of an Application, an Application Specific String, a First Well Known Rule, and so on. The terminology used in this document is a little looser (it refers to a 'starting string', for example, where 'Application Specific String' would be used for DDDS). The new terminology is reflected in RFC 3761.
また、DDDSの用語はRFC 2916で初期NAPTR用語から多くの点で異なってDDDSはそうでアプリケーション、アプリケーション固有の文字列、まずよく知られているルールの概念を導入し、ことに注意してください。本書で使用される用語は、少し緩い（それはアプリケーション固有の文字列は、 'DDDSのために使用される例えば「開始文字列」を意味する）です。新しい用語は、RFC 3761に反映されています。
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public - which is a cause for some privacy considerations.
DNSは、それは質問者と共有するレコードに関する政策決定を下すことはありません。すべてのDNSレコードはすべての回で、すべての照会者に利用可能であると想定しなければなりません。いくつかのプライバシーの配慮のための原因である - ENUMレコードセット内で提供される情報は、したがって、一般に公開することを考慮しなければなりません。
Ordinarily, when you give someone your telephone number, you don't expect that they will be able to trivially determine your full name and place of employment. If, however, you create a NAPTR record for use with ENUM that maps your telephone number to a SIP URI like 'julia.roberts@example.com', expect to get a lot of calls from excited fans.
あなたが誰か自分の電話番号を与えたときに通常、あなたは彼らが自明雇用のあなたの完全な名前と場所を決定することができるであろうことを期待していません。しかし、あなたは「julia.roberts@example.com」のようなSIP URIに、あなたの電話番号をマップするENUMで使用するためにNAPTRレコードを作成する場合は、興奮のファンからの呼び出しの多くを得ることを期待しています。
Unlike a traditional telephone number, the target of a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records.
従来の電話番号とは異なり、SIP URIの目標は、ユーザーが警告される前に、発信者が認証および承認のための暗号資格情報を提供することを必要とするかもしれません。この点で、SIPと協力してENUMは実際にENUMレコードの公共利用できるにもかかわらず、既存のPSTNよりも、不要な発信者からはるかに大きい保護を提供することができます。
Users of ENUM who are nevertheless uncomfortable with revealing their names may, since identities on the Internet are not exactly at a premium, publish a less revealing SIP URI, like 'sip:anonymous00045@example.com' or even 'sip:anonymous00045@anonymous-redirector.example.org', which could in turn point to their internal URI.
あるいは「SIP：anonymous00045匿名@：インターネット上のアイデンティティが貴重ではない正確にしているので、それにもかかわらず、自分の名前を明らかにして不快であるENUMのユーザーは、「anonymous00045@example.com一口」のような小さい暴露のSIP URIを、公開すること-redirector.example.org」、その可能性のターンポイントで、内部URIに。
An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [18] to these, is provided in [1].
DNSにENUMの依存性特定の脅威の分析、及びこれらにDNSSEC [18]の適用は、[1]に提供されます。
[1] Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom、P.とM. Meallingを、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164を"。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, November 1987.
[4] Mockapetris、P.、 "ドメイン名 - 概念と施設"、STD13、RFC 1034、1987年11月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[6] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[7] Peterson, J., "enumservice registration for SIP Addresses-of-Record", RFC 3764, April 2004.
[7]ピーターソン、J.は、 "SIPアドレス・オブ・レコードのenumservice登録"、RFC 3764、2004年4月。
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[8] Vaha-Sipilaは、A.、RFC 2806、2000年4月、 "電話のURLコール"。
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[10] International Telecommunications Union, "Recommendation E.164: The international public telecommunication numbering plan", May 1997, <http://www.itu.int>.
[10]国際電気通信連合、 "勧告E.164：国際公共通信番号計画"、1997年5月、<http://www.itu.int>。
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Work in Progress, June 2003.
[11]ローゼンバーグ、J.、Schulzrinneと、H.及びP. Kyzviat、 "セッション開始プロトコル（SIP）に示すユーザエージェント機能"、進歩、2003年6月に働いています。
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[12] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年9月。
[13] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[13]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol: Locating SIP Servers", RFC 3263, June 2002.
[14]ローゼンバーグ、J.とH. Schulzrinneと、 "セッション開始プロトコル：SIPサーバの検索"、RFC 3263、2002年6月を。
[15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing over IP (TRIP)", RFC 3219, August 2001.
[15]ローゼンバーグ、J.、スクワイア、M.、およびH.サラマ、 "オーバーIPテレフォニールーティング（TRIP）"、RFC 3219、2001年8月。
[16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[16] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[17] Peterson, J., "Enumservice Registration for Presence Services", Work in Progress, February 2003.
[17]ピーターソン、J.、 "プレゼンスサービスのEnumservice登録"、進歩、2003年2月での作業。
[18] Arends, R., et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[18]アレンズ、R.、ら、「DNSセキュリティ拡張のためのプロトコル変更」、進歩、2004年5月での作業。
Appendix A. Acknowledgments
付録A.謝辞
The authors would like to thank Richard Shockey for his input on privacy issues, and Tom McGarry and Rohan Mahy for overall comments and analysis. Thanks are due as well to Juan Heinanen and Lawrence E. Conroy for advice on updating this document to better reflect RFC 3761. Special thanks are given to Patrik Faltstrom and Michael Mealling for significantly reducing the size of this document by producing a tight and well-specified successor to RFC 2916. Richard Stastny and Patrik Faltstrom also provided valuable notes on the valid usage of non-greedy regexp antecedents.
著者は、全体的なコメントや分析のためのプライバシーの問題についての彼の入力のためのリチャードショッキー、そしてトム・マクギャリー、ローハンマーイに感謝したいと思います。おかげで原因にもフアンHeinanen、ローレンスE.コンロイに優れた3761感謝を大幅にタイトとよくを製造することにより、この文書のサイズを減少させるためのパトリックFaltstromとマイケル・メオーリングに与えられているRFCを反映するために、このドキュメントの更新についてアドバイスをしていますRFC 2916リチャードStastnyとパトリックFaltstromに指定された後継者はまた、非貪欲正規表現前例の有効な使用上の貴重なノートを提供します。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520 USA
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電話：+1 925/363から8720 Eメール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
Hong Liu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
香港劉NeuStar、Inc.の46000センターオークプラザスターリング、VA 20166 USA
EMail: hong.liu@neustar.biz URI: http://www.neustar.biz/
電子メール：hong.liu@neustar.biz URI：http://www.neustar.biz/
James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
ジェームズ・ゆうNeuStar、Inc.の46000センターオークプラザスターリング、VA 20166 USA
Phone: +1 571/434-5572 EMail: james.yu@neustar.biz URI: http://www.neustar.biz/
電話：+1 571/434から5572 Eメール：james.yu@neustar.biz URI：http://www.neustar.biz/
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
ベン・キャンベルdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024 USA
EMail: bcampbell@dynamicsoft.com URI: http://www.dynamicsoft.com/
電子メール：bcampbell@dynamicsoft.com URI：http://www.dynamicsoft.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎と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機能のための基金は現在、インターネット協会によって提供されます。