[要約] RFC 3824は、SIPでE.164番号を使用するためのガイドラインです。その目的は、SIPベースの通信システムでE.164番号を効果的に利用するための標準化と一貫性を提供することです。
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)
セッション開始プロトコル（SIP）でE.164番号を使用する
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）The Internet Society（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.
セッション開始プロトコル（SIP）アプリケーションで電話番号が採用されるコンテキストはいくつかあり、その多くは列挙で対処できます。SIPは列挙が作成された主要なアプリケーションの1つでしたが、それでも列挙とSIP実装を統合するための手順を定義する必要があります。このドキュメントは、2つのプロトコルがどのようにコンサートで機能するかを示し、SIPアプリケーションの列挙レコードの作成と処理を明確にします。また、何らかの理由で、列挙が電話番号を解決するために使用できない例のガイドラインも提供します。
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]）は、「12025332600」などの特定の電話番号をuris（均一なリソース識別子に翻訳するために、DNS（ドメイン名サービス、RFC 1034 [4]）を使用するシステムです。、RFC 2396 [9]）、「sip：user@sipcarrier.com」のような。列挙は、主に電話番号に依存するシステムの相互接続を促進するために存在します。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の最も広範なアプリケーションは、Voice-Over-IP（VOIP）です。そのため、SIPアプリケーションが電話番号との闘いを余儀なくされる多くのケースがあります。残念ながら、SIP URISに依存するSIP（[14]を参照）に標準化された従来のDNS解像度の手順に従って電話番号をルーティングすることはできません。Enumは、潜在的にSIP URIを含むE.164番号をURIに変換する方法を提供します。したがって、このドキュメントは、SIPが列挙を使用して電話番号を処理する方法の説明を提供します。ガイドラインは、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アプリケーション専用の列挙記録を作成および処理することに向けられています。これらのガイドラインは、読者が命名権限ポインター（NAPTR）レコード（RFC 3403 [6]）および列挙（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].
列挙仕様は、RFC 2915 [12]に記載されているNAPTRシステムの更新によって、仕様の動的委任ディスカバリーシステム（DDDS）ファミリー（RFC 3403を含む）に駆動される、このドキュメントの公開の直前に改訂を受けたことに注意してください。したがって、このドキュメントは、元の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のコンテキストでの記録作成と処理の列挙記録の規範的ガイドラインの提案は、それぞれセクション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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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リクエストを開始したい理由はいくつかあります。一般的な理由の1つは、ユーザーがPSTN-SIPゲートウェイを介してPSTNから呼び出していることです。このようなゲートウェイは、通常、PSTNからのルーティング情報を直接SIP信号にマッピングします。または、ネイティブSIPユーザーは、ターゲットユーザーがその番号で標準的に知られているか、オリジネーターのSIPユーザーエージェントが従来の数値電話キーパッドのみをサポートしているため、ターゲットユーザーが標準的に知られているためです。最初に従来の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とは異なり、電話番号にはホスト名、またはインターネット上の電話番号をターゲットとするリクエストを配信できる場所に関するヒントは含まれていません。SIPユーザーエージェントまたはプロキシサーバーは、完全なマッピングのサイズと複雑さを考慮して、特定の電話番号または電話番号の範囲に対応する目的地のマッピングで静的にプロビジョニングできますが、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を介して発見されたURIは、通常、SIPリクエストを目的地にルーティングするために使用できます。NAPTR DNSリソースレコード形式のサポートは、[14]の通常のSIP URI処理に指定されているため、列挙のサポートはベースライン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.
このドキュメントの残りの部分のほとんどは、列挙の使用に関する手順を提供しますが、何らかの理由で、列挙が使用されない場合については、このセクションの残りの部分でいくつかのガイドラインが示されています。
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.
ユーザーエージェントがE.164番号を列挙で翻訳できない場合、電話番号を含むSIPリクエスト-URIの種類を作成できます。SIPの最も一般的なアプリケーションの1つはテレフォニーであるため、SIPの電話番号の表現にはすでに多くの注意が払われています。特に、Tel URL RFC 2806 [8]は、SIP内で電話ルーティング情報を運ぶ方法として特定されています。通常、Tel URLは、プラス記号（例えば：Tel：12025332600）の前にあるE.164形式の数字で構成されています。この形式は非常に便利であるため、ベースラインSIP仕様に組み込まれています。SIP URIのユーザー部分には、Tel URLを含めることができます（SIP：12025332600@carrier.com; user =電話など、スキーム文字列なし）。したがって、SIPプロキシサーバーは、リクエスト-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のサポートがない場合、または列挙リクエストが電話番号に対応するレコードを返さない場合、ローカルポリシーを使用して、Request-URIのE.164番号でSIPリクエストを転送する方法を決定できます。多くの場合、そのような呼び出しは、PSTNとSIPネットワークを相互接続するゲートウェイにルーティングされます。これらのプロキシサーバーポリシーは、旅行ごとに電話番号のルーティング情報を使用して動的にプロビジョニングされる場合があります[15]。優先事項として、SIPユーザーエージェントは、テルURLを作成する前に、実装された場合、実装された場合、およびこのリクエストのルーティングをSIPプロキシサーバーに繰り延べることを列挙して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への列挙の適用性は常に明確でしたが、2つの協力する必要がある正確な方法は、いくつかの論争の対象となっています。NAPTRレコードの「サービス」フィールドが能力情報を含める必要があるかどうかにかかわらず、EnumにSIP URIが表示される必要があるSIP URIの数、彼らがどのようなURISであるか、どんな種類のURIがありますか？以下は、この文書の推奨事項を動機付けた特定の哲学の声明です。
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 urisは、連絡先アドレスurisではなく列挙に表示されます。大まかに言えば、録音住所はSIPユーザーの標準的なアイデンティティです。通常、そのユーザーが送信したSIPリクエストのFromフィールドに表示されます。連絡先アドレスは、デバイスのURIです。たとえば、SIPでの登録プロセス（レジスタメソッドを使用）は、デバイスの連絡先アドレスをユーザーの録音アドレスに一時的にバインドします。DNSレコードは、SIP登録の時間枠と比較すると、長い時間がかかります。録音アドレスの可用性は、単一のデバイスの可用性も超越します。Enumは、ユーザーが一時的に関連付けられているデバイスのURIよりも、長期的なアイデンティティを表現するためにより適しています。列挙が特定のデバイスにマッピングされることを目的とした場合、URIS（より豊富なものを表現する）よりも電話番号を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 urisは、機能情報を伝えません。SIPには、ユーザーエージェント間で機能情報を交渉する独自の方法があります（SDP [13]、RFC 3261の拡張機能を交渉するための要求/サポートの使用、およびCallee機能[11]を参照）。列挙内でより限定的な機能情報を提供することは、せいぜい冗長であり、最悪の場合、SIPの交渉システムに誤解を招く可能性があります。また、record of-recordには機能がありません（レコードアドレスの下に登録されているデバイスのみが実際の機能を備えています）、列挙に連絡先アドレスを置くことは推奨されません。
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.
理想的には、1つのSIP URIのみが、電話番号の列挙記録セットに表示されます。最初は列挙内の同じユーザーに届く複数のSIP URIを提供することは魅力的に思えるかもしれませんが、ユーザーに連絡できる複数のアドレスがある場合、複数のURIが特定されたSIPロケーションサービスによって管理されている場合、かなり柔軟性が与えられます。Enumの単一のレコードによって。たとえば、SIPでの並列および連続的なフォーキングの動作は、列挙レコードのセットよりも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レコードの処理の根底にある仮定は、列挙クライアントが通信しようとしているエンティティによってサポートされているエンムサービスのセットを知っていることを示しています。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サーバーにアップロードされるメカニズムについても、誰がWHOのNAPTRレコード（サービスプロバイダーまたはエンドユーザー）について仮定しません。この文書の文脈における著者は、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は、大きなファイルの転移に対して最適化されていないことです。5つまたは6つのNAPTRレコードを持つことは非常に合理的ですが、数百のNAPTRレコードのレコードセットを奨励するポリシーは適切ではありません。また、DNSレコードは比較的永続的です。著者は、Enum Naptrレコードを使用して、E.164数と潜在的に存在する潜在的なURIの間の関係を表現すべきではありません。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".
NAPTRレコード（RFC 3403ごと）のサービスフィールドには、特定のレコードに関連付けられたプロトコルまたはサービスを指定する文字列トークンが含まれています（レコードの使用から生じる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は、「E2U SIP」という形式を使用して、SIPアドレスオブレコードがNAPTRレコードのURIフィールドに表示されることを指定するEnumワーキンググループ（[7]を参照）で開発されています。NAPTRレコードの著者は、regexpに録音アドレスのURIが含まれている場合はいつでも「E2U SIP」サービスフィールドを使用することを強くお勧めします。
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.
列挙の使用を目的としたNAPTRレコードにおける正規表現の著者（今後は、regexp）は、置換に前件が存在しないことにより大きく単純化されます（つまり、最初の2人の区切り文字の間のセクション）。これは、Enum Core仕様全体で使用される唯一の区切り文字であるため、実装は区切り文字として感嘆符を使用することをお勧めします。
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ドメインの逆解像度を介して配置されているため、クライアント側の開始文字列のさらなる分析は通常不要です。そのような場合、正規表現の前件は一般に「貪欲」です - それは、regexp '^。*$'を使用します。Enum Recordセットの一部の著者は、Regexpsの全力を使用し、非greedyの前件を作成したい場合があります。DDDS標準では、列挙型リゾルバーが存在するときにこれらの正規表現をサポートする必要があります。電話番号からSIP URIへの些細なマッピングを提供するには、通常、貪欲なregexpの使用で十分です。
Example: "!^.*$!sip: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.
regexpの前件が貪欲である場合、これはNaptrレコードの交換場がRegexpを使用して作成するための実行可能な代替手段を提供することを意味しないことに注意してください。EnumのNAPTRレコードの著者は、「E2U SIP」サービスフィールドを使用してレコードの交換フィールドを使用してはなりません。
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.
regexpの結果の側面にはURIが含まれています。セッション開始に使用することを目的としたNAPTRレコード（SIPテレフォニーを含む）は、SIP URIを使用する必要があります。これは最初の聴聞会では特に物議を醸すことはないかもしれませんが、SIPアプリケーションに適していると考えられる他の種類のURIがあります：「Tel 'Uris、「im」または「pres」URI、または呼び出される可能性のある特定のサービスを説明する他のものがありますSIPを介してすべてが潜在的に候補者です。これらのURIの使用は、SIP URIではなくNAPTRレコードのこれらを含む、SIPの適切な構成と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 Recordsの著者は、サービスフィールドが「E2U SIP」の場合、常にSIPまたはSIPS URIスキームを使用する必要があり、問題のURIは連絡先アドレスではなく、記録アドレスでなければなりません。
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のユーザーは、1つ以上の連絡先住所をSIPレジストラに登録できます。これは、管理ドメインのプロキシインフラストラクチャから相談して、レコードアドレスのリクエストを受信したときにエンドユーザーに連絡することができます。URIを使用することの利点の多くは、デバイスではなくユーザーに関連付けられた論理サービスを表しているという事実に由来しています。実際、Enumがurisではなく特定のデバイスをターゲットにする必要がある場合、仮想的な「e2ipv4 sip」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 Recordsの最大互換性の著者は、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.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！"。
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アルゴリズムと列挙に慣れる必要があります。
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 Recordセットは単一の「E2U SIP」レコードのみで構成されますが、このセクションでは、列挙と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.
列挙クエリが「E2U SIP」のサービスフィールドを持つ複数のNAPTRレコード、またはSIPが使用できる他のサービスフィールド（「e2u pres」などの他のサービスフィールドを返す場合、[17]を参照）enumクライアントは最初に決定する必要があるかどうかを判断する必要があります。複数のレコードを使用したり、1つのレコードを選択したりする必要はありません。SIPの複数のNAPTRレコードを使用して、意図的にenumレコードセットの意図的に作成された落とし穴については、セクション4で詳しく説明しています。
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クライアントがユーザーエージェントである場合、ある時点で、目的のSIPリクエストのリクエスト-uriとして機能するように、単一のNAPTRレコードを選択する必要があります。指定されたNAPTRレコードに異なる設定がある場合、最も優先されるレコードを使用する必要があります。2つ以上のレコードが最も優先されるステータスを共有する場合、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仲介者である場合、列挙レコードセットの複数の選択されたNAPTRレコードに対応する複数のコンタクトヘッダーフィールドで3xx応答を返す必要があります。NAPTRレコードに異なる設定がある場合、これらの設定に対応するために、コンタクトヘッダーフィールドで「Q」値を使用できます。あるいは、Redirect Serverは、NAPTR選好フィールド（または設定が指定されていない場合はランダムに）に従って単一のレコードを選択し、3XX応答のコンタクトヘッダーフィールドにこの結果の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クライアントがプロキシサーバーとして機能できるSIP仲介者である場合、列挙レコードセットで複数の適切なNAPTRレコードを受信すると、リクエストをフォークする場合があります。NAPTRレコードの相対的な優先値の値に応じて、プロキシは順次または並行してフォークを希望する場合があります。ただし、プロキシは、他のURIスキームではなく、SIPまたはSIP URIのみで構成されるこれらのNAPTRレコードからルートセットを構築する必要があります。あるいは、プロキシサーバーは、NAPTR選好フィールド（または設定が指定されていない場合、またはローカルポリシーに従ってランダムに）に従って単一のレコードを選択し、このNAPTRのURIフィールドに対応するリクエスト-URIでリクエストをプロキシをプロキシできます。記録 - 再び、SIPまたはSIPS URIを含むレコードを選択する必要があります。プロキシサーバーがユーザーエージェントの代わりに列挙レコードセットを処理する場合に発生する大きな制限があり、したがって、SIPネットワーク要素が列挙クエリを実行した後にプロキシサーバーではなくリダイレクトサーバーとして機能することをお勧めします。
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はRegexpフィールドから抽出する必要があります。URIは、文字列の2番目と3番目の感嘆符の間にあります。URIがNAPTRレコードから抽出されると、列挙クエリが起動されたSIP要求のリクエスト-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レコードから録音アドレスが抽出されると、クライアントはリクエストを転送する方法を決定するために標準のSIPメカニズム（[14]を参照）に従います（[14]を参照）。これには、レコードのアドレスによって識別されるドメインへの配線が最適な方法を決定するために、後続のNAPTRまたはSRVクエリを起動することが含まれます。ただし、クライアントは同じEnumクエリを再帰的に作成してはなりません（Enumで返されたURIが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リクエストは、何らかの理由で失敗する可能性があることに注意してください。Enumレコードセットに存在するSIPに関連する複数のNAPTRレコードがある場合、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 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」サービスフィールドを含む列挙に使用できる多くの「サービス」値を指定しました。RFC 3761は、Enumservicesの登録に関する新しいガイドラインを備えたIANA登録システムを導入します。これは、必ずしも控えめな「サービス」および「プロトコル」フィールドに分割されておらず、より複雑な構造を認めています。RFC 3761のエンムサービスをRFC 2916のエンガーサービスと区別するために、文字列「E2U」はEnumserviceフィールドの主要な要素ですが、RFC 2916では、それは後続の要素でした。
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アドレスのレコードのencresviceは[7]で説明されています。このEnumserviceは、Enumserviceフィールド「E2U SIP」を使用します。したがって、SIPのEnum RecordsのRFC 3761準拠の著者は、「SIP E2U」フィールドの代わりに「E2U SIP」Enumserviceフィールドを使用する必要があります。ただし、既存のレガシー記録との逆方向の互換性については、「SIP E2U」フィールドは、SIPをサポートする列挙クライアントによってサポートされる必要があります。
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は、アプリケーションの概念、アプリケーション固有の文字列、最初の知られているルールなどを導入します。このドキュメントで使用されている用語は少しゆるいです（たとえば、「アプリケーション固有の文字列」がDDDに使用される場合、「起動文字列」を指します）。新しい用語は、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は、Inquirerと共有する記録について政策決定を下しません。すべての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と協調して、列挙記録が公開されているにもかかわらず、実際には既存の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.
それにもかかわらず、自分の名前を明らかにするのに不快なenumのユーザーは、インターネット上のアイデンティティが正確にプレミアムではないため、「sip：anonymous00045@example.com」または「sip：anonymous00045@anonymous」など、あまり顕著ではないsip uriを公開する可能性があります。-redirector.example.org '。
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への酵素の依存性に特有の脅威の分析、およびこれらへの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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的な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。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[7] Peterson, J., "enumservice registration for SIP Addresses-of-Record", RFC 3764, April 2004.
[7] Peterson、J。、「recordのSIPアドレスのEnumservice登録」、RFC 3764、2004年4月。
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[8] Vaha-Sipila、A。、「電話のためのURL」、RFC 2806、2000年4月。
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Rosenberg、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。and R. Daniel、「The Naming Authority Pointer（NAPTR）DNSリソースレコード」、RFC 2915、2000年9月。
[13] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[13] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol: Locating SIP Servers", RFC 3263, June 2002.
[14] Rosenberg、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] Rosenberg、J.、Squire、M。、およびH. Salama、「Thelephony Routing over 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] Peterson、J。、「プレゼンスサービスのEnumservice登録」、2003年2月、進行中の作業。
[18] Arends, R., et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[18] Arends、R.、et al。、「DNSセキュリティ拡張のプロトコル変更」、2004年5月、進行中の作業。
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.
著者は、プライバシーの問題に関する意見についてリチャード・ショッケーに感謝し、トム・マクガリーとロハン・マヒーが全体的なコメントと分析をしたいと思います。Juan HeinanenとLawrence E. Conroyにも感謝します。このドキュメントを更新することについてのアドバイスを提供してくれました。RFC3761をよりよく反映しています。RFC 2916の後継者が指定しました。リチャード・スタストニーとパトリック・ファルトストロームは、非グリーディのregexp前件の有効な使用に関する貴重なメモも提供しました。
Authors' Addresses
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Hong Liu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
Hong Liu Neustar、Inc。46000 Center Oak Plaza Sterling、VA 20166 USA
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
James Yu Neustar、Inc。46000 Center Oak Plaza Sterling、VA 20166 USA
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
Ben Campbell Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024 USA
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://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エディター機能の資金は現在、インターネット協会によって提供されています。