RFC3824 日本語訳
3824 Using E.164 numbers with the Session Initiation Protocol (SIP).J. Peterson, H. Liu, J. Yu, B. Campbell. June 2004. (Format: TXT=36535 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson
Request for Comments: 3824 H. Liu
Category: Informational J. Yu
NeuStar
B. Campbell
dynamicsoft
June 2004
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3824時間リュウCategory: 情報のJ.のユーNeuStar B.キャンベルdynamicsoft2004年6月
Using E.164 numbers with the Session Initiation Protocol (SIP)
Session InitiationプロトコルがあるE.164番号を使用します。(一口)
Status of this Memo
この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).
Copyright(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がそれの多くを記述できるSession Initiationプロトコル(SIP)アプリケーションで使われる多くの文脈があります。 SIPはENUMが作成された第一のアプリケーションの1つでしたが、それにもかかわらず、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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 一口. . . . . . . . . . . . . . 3 4における電話番号を扱います。 プリンシプルズ. . . . . . . . . . . . . . . . . . . . . . 5 5を設計してください。 書いているNAPTRは一口. . . . . . . . . . . . . . . 6 5.1のために記録します。 サービス分野. . . . . . . . . . . . . . . . . . . 6 5.2。 正規表現を作成します: .65.3を合わせます。 正規表現を作成します: URI. . . . . . . . 7 5.4。 記録. . . . . . 8 5.5の中に注文と好みを設定します。 よく形成されたENUM NAPTR記録に関する例は一口のためにセットしました。 8 6. ENUM記録. . . . . . . . . . . . . . . . . . . 8 6.1を処理します。 Multiple SIP記録. . . . . . . . . . 8を競争します。
Peterson, et al. Informational [Page 1] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[1ページ]のRFC3824
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
6.2. 選択されたNAPTR記録. . . . . . . . . . 9 7を処理します。 RFC3761との互換性。 . . . . . . . . . . . . . . . . . 10 8. セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1。 引用規格. . . . . . . . . . . . . . . . . . 11 9.2。 有益な参照. . . . . . . . . . . . . . . . . 12A.承認. . . . . . . . . . . . . . . . . . . . . . . 14作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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.
[4]) ある電話番号を翻訳して、好きである'+12025332600'、URIに。ENUM、(E.164 Number Mapping、RFC3761[1])がDNSを使用するシステムである、(ドメインName Service、RFC1034、(Uniform Resource Identifier(RFC2396[9]))は'一口: 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、(セッションInitiationプロトコル、RFC3261[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のために標準化された伝統的な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
ガイドラインは本書では特にSIPアプリケーションのためのオーサリングと処理ENUM記録に向かって適応します。 これらのガイドラインが、読者がNaming Authority Pointer(NAPTR)記録に詳しいと仮定する、(RFC3403[6])とENUM、(RFC3761[1])。 NAPTRのそれらの局面だけがそうしたオーサリングと処理を記録します。
Peterson, et al. Informational [Page 2] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[2ページ]のRFC3824
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か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仕様がRFC2915[12]で仕様のDynamic DelegationディスカバリーSystem(DDDS)家に説明されたNAPTRシステムのアップデートによる駆動(RFC3403を含んでいる)のこのドキュメントの公表のすぐ前に改正を受けたことに注意してください。 したがって、このドキュメントはオリジナルのRFC2916[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でそれぞれ説明されます。 セクション7でRFC2916の改正に関連しているいくつかの問題を与えます。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[3]について説明して、対応する一口実現のために要件レベルを示すとき解釈されることであるべきですか?
3. Handling Telephone Numbers in SIP
3. 一口における取り扱い電話番号
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からPSTN-SIPゲートウェイまで電話をしているということです。 通常、そのようなゲートウェイはPSTNからのルーティング情報を直接SIPシグナリングに写像します。 または、ネイティブのSIPユーザが故意に利用対象者が恐らくその数によって正準に知られているのでE.164番号まで記述されたセッションを開始するかもしれませんか、または創始者の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
URIと異なって、電話番号は1つがインターネットの電話番号を狙う要求を提供するかもしれないところに関してホスト名、またはどんなヒントも含んでいません。 特定の電話番号か電話番号に対応する目的地に関するマッピングで静的にSIPユーザエージェントかプロキシサーバに食糧を供給することができましたが
Peterson, et al. Informational [Page 3] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[3ページ]のRFC3824
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.
範囲、完全なマッピングのサイズと複雑さを考える場合、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.
そのような場合ユーザエージェントはE.164番号に関連しているURIを発見するのにENUMを使用するかもしれません--SIP URIを含んでいます。 そして、通常、SIP要求をそれらの目的地に発送するのにENUMを通して発見されたURIは使用できます。 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 Request-URIを作成できます。 SIPの最も一般的なアプリケーションの1つが電話であるので、既にSIPの電話番号の表現に大きな注意をささげてあります。 運ぶ方法がSIPの中でルーティング情報に電話をするとき、特に、tel URL RFC2806[8]は特定されました。 通常、tel URLはプラスサインが例えば先行したE.164形式における数から成ります: tel: +12025332600。 この形式はそれが法人組織であるほど基線SIP仕様の役に立ちます。 SIP URIのユーザ部分はtel URLを含むことができます(一口のような計画ストリングなしで: + 12025332600@carrier.com;user は電話と等しいです)。 したがって、SIPプロキシサーバはtel URLでユーザエージェントからRequest-URIで要求を受け取るかもしれません。 プロキシサーバがこの種類の要求を扱うことができた1つの方法はENUM質問自体、および返されたENUM記録によると、SIPが要求するproxyingに着手することです。
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ユーザエージェントは、ENUMと共に電話番号をURIに翻訳するのを試みるべきです、実行されるなら、SIPプロキシサーバにtel URLを作成して、この要求のルーティングを延期する前に。
Peterson, et al. Informational [Page 4] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[4ページ]のRFC3824
4. Design Principles
4. 設計原理
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の適用性はいつも明確ですが、2が協力するべきである正確な方法は何らかの論争の対象です。 NAPTR記録の「サービス」分野は能力情報を含むべきです--多数の質問がオーサリングの周りに起こったか否かに関係なく、いくつのSIP URIがENUM、どんな種類の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要求のFrom分野では、現れます。 連絡先は装置のURIです。 例えば、SIP(REGISTER方法を使用する)の登録の過程は一時ユーザの記録されている住所に装置の連絡先を縛ります。 DNS記録には、SIP登録証明書の時間枠と比べると、生きる長い時間があります。 また、記録されている住所の有用性はどんな単一の装置の有用性も超えています。 ENUMはユーザが一時関連しているどんな装置のURIよりも長期のアイデンティティを表すのに適当です。 ENUMが特定の装置への地図に目標とされるなら、IPv4アドレスに電話番号を翻訳するのはURI(より豊かな何かを言い表す)より良いでしょうに。
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]、RFC3261で拡大を交渉するために支持されたRequire/の使用、および訪問される人能力[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.
1SIP URIだけが電話番号に関してENUMレコードセットに理想的に現れます。 ENUMの中で同じユーザに届く複数のSIP URIを提供するのが初めは魅力的に思えるかもしれない間、ユーザに連絡されることができる複数のアドレスがあれば、ENUMでのただ一つの記録によって特定されるSIP位置のサービスによって複数のURIを管理するなら、かなり大きい柔軟性を提供します。 例えば、SIPでの平行で連続した分岐のための振舞いはENUM記録のセットよりSIPで管理されるほうがよいです。
Peterson, et al. Informational [Page 5] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[5ページ]のRFC3824
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を知っていそうにはありません。
5. Authoring NAPTR Records for SIP
5. 一口のための書いているNAPTR記録
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記録のオーサリングに適切ないくつかの一般的ガイドラインがあります。 最も重要であるのは、SHOULDが保つ作者が比較的小さくセットを記録するということです--DNSは大きいファイルの移転のために最適化されません。 5か6つのNAPTR記録を持っているのはかなり妥当ですが、何百ものNAPTR記録の記録セットを奨励する方針は適切ではありません。 また、DNS記録も比較的永久的です。 ENUM NAPTRがE.164番号の間の関係を言い表すために記録するSHOULD NOT使用と短い間だけ潜在的に存在するURIを書きます。 妥当な長さの時(少なくとも数時間)に記録が有効になると仮定できるとき、DNSは最もスケーラブルです。
5.1. The Service Field
5.1. サービス分野
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記録(RFC3403あたりの)の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ワーキンググループで開発されました。([7]) どれがSIP記録されている住所にそれを指定するのに形式'E2U+一口'を使用するかがNAPTR記録のURI分野に現れるのを確実にしてください。 regexpがSIP記録されている住所URIを含んでいるときはいつも、強く、NAPTRの作者が記録するRECOMMENDEDが'E2U+一口'サービス分野を使用するということです。
5.2. Creating the Regular Expression: Matching
5.2. 正規表現を作成します: マッチング
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
使用のためにENUMによって意図されたNAPTR記録における正規表現(今後は、regexpする)の著述業が代替における、前例の欠如で広大に簡素化される、(すなわち、セクション
Peterson, et al. Informational [Page 6] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[6ページ]のRFC3824
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.
最初の2つのデリミタ) 実現がデリミタとして感嘆符を使用するのは、RECOMMENDEDです、これが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アプリケーションでは、通常、クライアント側における始めのストリングのさらなる分析は不要になるでしょう。 '一般的に''--regexpを使用する'という貪欲な^*$'がそのような場合、正規表現に関する前例にあって、どのマッチがあらゆる始めのストリングであるか。 ENUMレコードセットの何人かの作者が、regexpsの全出力を使用して、非貪欲な前例を作成したがっているかもしれません。 DDDS規格は、彼らが存在しているとき、ENUMレゾルバがこれらのregexpsを支持するのを必要とします。 電話番号からSIP URIまで些細なマッピングを提供するために、通常、貪欲なregexpの使用は十分です。
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.
regexpの前例が貪欲であるときに、これが、NAPTR記録の交換分野がオーサリングへの実行可能な代案にregexpを提供することを意味しないことに注意してください。 ENUM MUST NOTのためのNAPTR記録の作者は記録で'E2U+一口'サービス分野で交換分野を使用します。
5.3. Creating the Regular Expression: The URI
5.3. 正規表現を作成します: URI
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を含んでいます。 開始(SIP電話を含んでいる)SHOULDがSIP URIを使用するセッションに使用されることを意図するNAPTR記録。 これは初めに聞きながら、特に論議を呼ぶように聞こえないかもしれませんが、SIPアプリケーションに適切であると考えられるかもしれない他の種類のURIがあります: 'tel'URI、'不-''pres'URI、またはSIPを通して呼び出されるかもしれない特定のサービスについて説明する他のものが皆潜在的に候補です。 これらのURIの使用はいくつかの状況で妥当に思えるかもしれませんが、SIP URIよりむしろNAPTR記録にこれらを含んでいると、適切なサービスの構成と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.
サービス分野が'E2U+一口'であるときに、ENUM記録の作者がいつもSIPかSIPS URI計画を使用するべきであり、問題のURIが記録のアドレスであるに違いないことはRECOMMENDEDです、とアドレスが連絡しません。
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
要求が登録するとき、SIPのユーザは管理ドメインのプロキシインフラストラクチャによって相談される、エンドユーザに連絡するSIP記録係に1つ以上の連絡先を登録できます。
Peterson, et al. Informational [Page 7] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[7ページ]のRFC3824
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.
それらの記録されている住所のために、受信しました。 URIを使用する利益の多くが装置よりむしろユーザに関連している論理的なサービスを表すという事実から来ます--本当に、ENUMが、URIよりむしろ特定の装置を狙う必要があるなら、仮定している'E2IPv4+一口'enumserviceは、より適切でしょう。
5.4. Setting Order and Preference amongst Records
5.4. 記録の中に注文と好みを設定します。
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.
ENUMの最大限度の互換性作者に関しては、SIP SHOULDのための記録はENUMレコードセットにおけるすべてのNAPTR記録にいつも同じオーダー値を使用します。 NAPTR記録の中の相対的選好が望ましいなら、それは唯一選択領域で言い表されるべきです。
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP
5.5. よく形成されたENUM 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!" .
$起源0.0.6.2.3.3.5.2.0.2.1.e164.arpa。 「$!一口: NAPTR100 10「u」「E2U+一口!」」 ^* user@example.com! 」 . 「$!mailto: NAPTR100 20「u」「E2U+mailto!」」 ^* info@example.com! 」 .
6. Processing ENUM Records
6. 処理ENUM記録
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記録の処理について徹底的に決して説明しません。 このセクションを見直す前に、implementersは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.
シングルだけ'E2U+一口'はいくつかのケース、セットが成るというENUM記録に記録しますが、このセクションは、ENUMとSIPのインテグレーターが、より複雑なシナリオのために用意ができていなければならないと仮定します--ただ、私たちがクライアントが彼らが受けるもので寛大であるべきであることを推薦して、NAPTR記録を潜在的に混乱させるのを理解できようとするので、しかしながら、それは、私たちがこの寛大さを必要にする潜在的に厄介な書いている習慣のどれかを推薦することを意味しません。
6.1. Contending with Multiple SIP records
6.1. Multiple SIP記録を競争します。
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質問が'E2U+一口'のサービス分野、またはそうするかもしれない他のサービス分野を持っている記録を複数のNAPTRに返すなら、SIPによって使用されてください。('E2U+pres'としてあれほどです、[17]) ENUMクライアントが、最初にそれが、複数の記録を利用するか、またはただ一つのものを選択するのを試みるべきであるかどうかと決心しなければならないのを確実にしてください。 故意に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
ENUMクライアントがユーザエージェントであるなら、何らかのポイントでは、必要なSIP要求のRequest-URIとして機能するのをただ一つのNAPTR記録を選択しなければなりません。 与えられたNAPTR記録に好み、異なった最も都合のよい記録的なSHOULDがあるなら、使用されてください。 2以上が記録するなら
Peterson, et al. Informational [Page 8] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[8ページ]のRFC3824
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.
最も都合のよい状態(SHOULDが手当たりしだいに決定するそれの記録が使用されていて、ローカルの方針に従うかもしれませんが、それが記録を選択するある他の手段を使うということである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記録に対応する1つ以上のContactヘッダーフィールドがある3xx応答が設定するSHOULDリターンです。 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レコードセットで複数の適切なNAPTR記録を受け取るとき、さもなければ、ENUMクライアントがプロキシサーバとして務めることができるSIP仲介者であるなら、それは要求を分岐させるかもしれません。 NAPTR記録の相対的な先行値によって、プロキシは連続するか平行で分岐したがっているかもしれません。 しかしながら、プロキシはこれらのNAPTR記録からのSIPかSIPSから排他的に成るルートセットに他のURI計画ではなく、URIを築き上げなければなりません。 あるいはまた、一方SIPかSIPS URIを含む記録を選択しなければなりませんが、Request-URIがこのURI分野に対応であっている中の要求NAPTRが記録するNAPTR選択領域(いいえときに、手当たりしだいに、指定されるか、またはローカルの方針によると、好みがある)とプロキシによると、プロキシサーバはただ一つの記録を選択するかもしれません。 プロキシサーバがユーザエージェントの代わりにENUMレコードセットを処理するなら起こる重要な制限があって、したがって、ENUM質問を実行した後にSIPネットワーク要素がプロキシサーバよりむしろ再直接のサーバとして作用するのが、RECOMMENDEDであることに注意してください。
6.2. Processing the Selected NAPTR Record
6.2. 選択されたNAPTR記録を処理します。
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分野から抽出されるべきです。 ストリングにおける2番目と3番目の感嘆符の間には、URIがあります。 かつて、URIはNAPTR記録から抽出されて、それはSHOULDです。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にいくつかの健全度チェックを実行するべきです。 クライアントは、Request-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
一度、記録されている住所は選択されたNAPTR記録から抜粋されたことがあって、クライアントは標準のSIPメカニズムに従います。(要求を転送する方法を決定するための[14])を見てください。 これは、その方法を最も決定するためにその後のNAPTRかSRV質問に着手することを伴うかもしれません。
Peterson, et al. Informational [Page 9] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[9ページ]のRFC3824
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]).
記録されている住所によって特定されたドメインへのルート。 しかしながら、クライアントは同じ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記録で彼らの要求を試みるかもしれません。
7. Compatibility with RFC 2916
7. RFC2916との互換性
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で改正を受けることです。 新しい仕様(RFC3761[1])はRFC2915[12]で指定されたNAPTRリソース記録へのDynamic DelegationディスカバリーSystem[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.
RFC3761で最も重要な改正はenumservicesの概念です。 当初のENUM仕様(RFC2916)はENUMに使用できた多くの「サービス」値を指定しました、「一口+E2U」サービス分野を含んでいて。 RFC3761は新指導要綱がある必ずもう慎重な「サービス」と「プロトコル」分野に分割されるというわけではなくて、より複雑な構造を認めるenumservicesの登録のIANA登録制を紹介します。 RFC2916でそれらとRFC3761のenumservicesを区別するために、ストリング「E2U」はenumservice分野の主な要素ですが、RFC2916で、それは引きずっている要素でした。
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 MUSTのためのENUM記録のRFC3761年の対応することの作者は「一口+E2U」分野の代わりに「E2U+一口」enumservice分野を使用します。 しかしながら、'一口+E2U'がSHOULDをさばくという既存の遺産記録との遅れている互換性には、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の用語がRFC2916の初期のNAPTR用語と多くの点において異なることに注意してください。 DDDSはApplication、Application Specific String、First Well Known Ruleなどの概念を紹介します。 本書では使用される用語は少しゆるいです(例えば、それは'アプリケーションSpecific String'がDDDSに使用されるところに'始めのストリング'について言及します)。 新しい用語はRFC3761に反映されます。
Peterson, et al. Informational [Page 10] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[10ページ]のRFC3824
8. Security Considerations
8. セキュリティ問題
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は実際に既存のPSTNより求められていない訪問者からはるかに大きい保護を提供できます、ENUM記録の公共の有用性にもかかわらず。
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のユーザは'一口: anonymous00045@example.com 'や'一口: anonymous00045@anonymous-redirector.example.org 'さえのような順番にそれらの内部のURIを示すことができたそれほど顕でないSIP 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]に提供します。
9. References
9. 参照
9.1. Normative References
9.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.食事、「Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーション(ENUM)へのE.164」、RFC3761、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」(RFC3261)は2002がそうするかもしれません。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Peterson, et al. Informational [Page 11] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[11ページ]のRFC3824
[4] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD13, RFC 1034, November 1987.
[4]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[6] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。
[7] Peterson, J., "enumservice registration for SIP Addresses-of-
Record", RFC 3764, April 2004.
[7] ピーターソン、J.、「SIP Addressesのためのenumservice登録、-、記録、」、RFC3764、4月2004日
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[8]Vaha-Sipila、A.、「通話のためのURL」、RFC2806、2000年4月。
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
9.2. Informative References
9.2. 有益な参照
[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は進行中(2003年6月)で働いています。
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[12] 食事とM.とR.ダニエル、「命名権威ポインタ(NAPTR)DNSリソース記録」、RFC2915、2000年9月。
[13] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[13] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol:
Locating SIP Servers", RFC 3263, June 2002.
[14] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は議定書を作ります」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing
over IP (TRIP)", RFC 3219, August 2001.
[15] ローゼンバーグ、J.、郷士、M.、およびH.サラマ、「IP(旅行)の上の電話ルート設定」、RFC3219、2001年8月。
[16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[16]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日
Peterson, et al. Informational [Page 12] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[12ページ]のRFC3824
[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]Arends、R.、他、「DNSセキュリティ拡張子のためのプロトコル変更」、Progress、2004年5月のWork。
Peterson, et al. Informational [Page 13] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[13ページ]のRFC3824
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.
プライバシーの問題に関する彼の意見についてリチャード・ショッキーに感謝します、そして、作者は、総合的なコメントと分析のためにトムMcGarryとRohanマーイに感謝したいです。 また、ホアンHeinanenとローレンス・E.コンロイにとって、感謝はRFC3761をよりよく反映するというこのドキュメントをアップデートすることに関するアドバイスを求めて当然です。 RFC2916のきつくてよく指定された後継者を生産することによってこのドキュメントのサイズをかなり減少させるためにパトリクFaltstromとマイケルMeallingに特別な感謝を与えます。 また、リチャードStastnyとパトリクFaltstromは非貪欲なregexp前例の有効な用法に関する貴重な注を提供しました。
Peterson, et al. Informational [Page 14] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[14ページ]のRFC3824
Authors' Addresses
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Hong Liu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
商館リュウNeuStar Inc.46000センターオーク広場英貨、ヴァージニア20166米国
EMail: hong.liu@neustar.biz URI: http://www.neustar.biz/
メール: hong.liu@neustar.biz ユリ: http://www.neustar.biz/
James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
ジェームスユーNeuStar Inc.46000センターオーク広場英貨、ヴァージニア20166米国
Phone: +1 571/434-5572 EMail: james.yu@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 571/434-5572 メールしてください: james.yu@neustar.biz ユリ: http://www.neustar.biz/
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
プラノ、ベンキャンベルdynamicsoft5100テニソンパークウェイSuite1200テキサス75024米国
EMail: bcampbell@dynamicsoft.com URI: http://www.dynamicsoft.com/
メール: bcampbell@dynamicsoft.com ユリ: http://www.dynamicsoft.com/
Peterson, et al. Informational [Page 15] RFC 3824 SIPPING E.164 June 2004
ピーターソン、他 E.164 2004年6月にちびちび飲む情報[15ページ]のRFC3824
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Peterson, et al. Informational [Page 16]
ピーターソン、他 情報[16ページ]
一覧
スポンサーリンク
