RFC3764 日本語訳

Network Working Group                                        J. Peterson
Request for Comments: 3764                                       NeuStar
Category: Standards Track                                     April 2004

コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3764年のNeuStarカテゴリ: 標準化過程2004年4月

     enumservice registration for Session Initiation Protocol (SIP)
                          Addresses-of-Record

記録のSession Initiationプロトコル(SIP)アドレスのためのenumservice登録

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   This document registers an Electronic Number (ENUM) service for the
   Session Initiation Protocol (SIP), pursuant to the guidelines in RFC
   3761.  Specifically, this document focuses on provisioning SIP
   addresses-of-record in ENUM.

このドキュメントはSession Initiationプロトコル(SIP)のためのElectronic Number(ENUM)サービスを登録します、RFC3761のガイドラインによると。 明確に、このドキュメントは、ENUMの記録のSIPアドレスに食糧を供給するのは焦点を合わせます。

Table of Contents

目次

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  ENUM Service Registration . . . . . . . . . . . . . . . . . . . 2
   3.  Addresses-of-record in SIP. . . . . . . . . . . . . . . . . . . 3
   4.  The 'E2U+SIP' enumservice . . . . . . . . . . . . . . . . . . . 5
   5.  Example of E2U+SIP enumservice. . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       8.1.  Normative References. . . . . . . . . . . . . . . . . . . 6
       8.2.  Informative References. . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 7
   10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
   11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8

1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. ENUMは登録. . . . . . . . . . . . . . . . . . . 2 3を修理します。 一口における、記録のアドレス。 . . . . . . . . . . . . . . . . . . 3 4. 'E2U+SIP'enumservice. . . . . . . . . . . . . . . . . . . 5 5。 E2U+SIP enumserviceに関する例。 . . . . . . . . . . . . . . . . 5 6. セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 6 8。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. 引用規格。 . . . . . . . . . . . . . . . . . . 6 8.2. 有益な参照。 . . . . . . . . . . . . . . . . . 7 9. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 7 10. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . 7 11. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . 8

Peterson                    Standards Track                     [Page 1]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[1ページ]RFC3764SIP enumservice2004年4月

1.  Introduction

1. 序論

   ENUM (E.164 Number Mapping, RFC 2916 [6]) is a system that uses DNS
   (Domain Name Service, STD 13, RFC 1034 [3]) to translate telephone
   numbers, like '+12025332600', into URIs (Uniform Resource
   Identifiers, RFC 2396 [4]), like 'sip:egar@example.com'.  ENUM exists
   primarily to facilitate the interconnection of systems that rely on
   telephone numbers with those that use URIs to route transactions.
   This document applies to the revised version of ENUM described in RFC
   3761.

ドメインName Service(STD13、電話番号を翻訳するRFC1034[3]))は'+12025332600'がURIに好きです。ENUM、(E.164 Number Mapping、RFC2916[6])がDNSを使用するシステムである、((Uniform Resource Identifier(RFC2396[4]))は'一口: egar@example.com 'が好きです。 ENUMは、主としてトランザクションを発送するのにURIを使用するもので電話番号を当てにするシステムのインタコネクトを容易にするために存在しています。 このドキュメントはRFC3761で説明されたENUMの改訂版に適用されます。

   SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based
   application protocol that allows endpoints on the Internet to
   discover one another in order to exchange context information about a
   session they would like to share.  Common forms of communication that
   are set up by 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 is a protocol that finds the best way for parties to communicate.

SIP、(セッションInitiationプロトコル、RFC3261[2])はインターネットの終点がそれらが共有したがっているセッション頃に文脈情報を交換するためにお互いを発見できるテキストベースのアプリケーション・プロトコルです。 SIPによってセットアップされるコミュニケーションの一般的なフォームはインターネット電話を含んでいます、インスタントメッセージング、ビデオ、インターネットの勝負事をしていて他のフォームに関する瞬時通信。 SIPは同時に異なったフォームに関する瞬時通信にかかわるセッションを開始できるマルチサービスプロトコルです。 SIPはパーティーが交信する最も良い方法を見つけるプロトコルです。

2.  ENUM Service Registration

2. ENUMサービス登録

   As defined in [1], the following is a template covering information
   needed for the registration of the enumservice specified in this
   document.

[1]で定義されるように、↓これは本書では指定されたenumserviceの登録に必要である情報をカバーするテンプレートです。

      Enumservice Name: "E2U+SIP"

Enumserviceは以下を命名します。 「E2U+一口」

      Type(s): "SIP"

タイプ: 「一口」

      Subtype(s): N/A

Subtype(s): なし

      URI Scheme(s): "sip:", "sips:"

URI体系: 「以下をちびちび飲ん」で、「以下をちびちび飲みます」。

      Functional Specification: see Section 4

機能的な仕様: セクション4を見てください。

      Security considerations: see Section 6

セキュリティ問題: セクション6を見てください。

      Intended usage: COMMON

意図している用法: 一般的

      Author: Jon Peterson (jon.peterson@neustar.biz)

以下を書いてください。 ジョン・ピーターソン( jon.peterson@neustar.biz )

      Any other information that the author deems interesting: See
      Section 3

作者がおもしろいと考えるいかなる他の情報も: セクション3を見てください。

Peterson                    Standards Track                     [Page 2]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[2ページ]RFC3764SIP enumservice2004年4月

3.  Addresses-of-record in SIP

3. 一口における、記録のアドレス

   This document specifies an enumservice field that is appropriate for
   SIP addresses-of-record URIs.  Various other types of URIs can be
   present in SIP requests.  A URI that is associated with a particular
   SIP user agent (for example, a SIP phone) is commonly known as a SIP
   contact address.

このドキュメントはSIP記録のアドレスURIに、適切なenumservice分野を指定します。 他の様々なタイプのURIはSIP要求に存在している場合があります。 特定のSIPユーザエージェント(例えば、SIP電話)に関連しているURIはSIP連絡先として一般的に知られています。

   The difference between a contact address and an address-of-record is
   like the difference between a device and its user.  While there is no
   formal distinction in the syntax of these two forms of addresses,
   contact addresses are associated with a particular device, and may
   have a very device-specific form (like sip:10.0.0.1, or
   sip:edgar@ua21.example.com).  An address-of-record, however,
   represents an identity of the user, generally a long-term identity,
   and it does not have a dependency on any device; users can move
   between devices or even be associated with multiple devices at one
   time while retaining the same address-of-record.  A simple URI,
   generally of the form 'sip:egdar@example.com', is used for an
   address-of-record.

連絡先と記録されている住所の違いはデバイスとそのユーザの違いに似ています。 これらの2つのフォームのアドレスの構文にはどんな正式な区別もない間、連絡先は、特定のデバイスに関連していて、デバイス非常に特有のフォームを持っているかもしれません。(同類が10.0に以下をちびちび飲む、.0、一口: .1、または edgar@ua21.example.com 、) しかしながら、記録されている住所はユーザのアイデンティティを表します、一般に長期のアイデンティティ、そして、それには、依存がどんなデバイスでもありません。 ユーザは、デバイスの間で移行するか、またはひところ、同じ記録されている住所を保有している間、複数のデバイスに関連づけることさえできます。 簡単なURIは記録されている住所に一般にフォーム'一口: egdar@example.com 'について使用されます。

   When a SIP request is created by a user agent, it populates the
   address-of-record of its target in its To header field and
   (generally) Request-URI.  The address-of-record of the user that is
   sending the request populates the From header field of the message;
   the contact address of the device from which the request is sent is
   listed in the Contact header field.

SIP要求がユーザエージェントによって作成されるとき、それはToヘッダーフィールドと(一般に)要求URIで目標の記録されている住所に居住します。 要求を送るユーザの記録されている住所はメッセージのFromヘッダーフィールドに居住します。 要求が送られるデバイスの連絡先はContactヘッダーフィールドで記載されています。

   By sending a registration to a registrar on behalf of its user, a SIP
   device (i.e., a user agent) can temporarily associate its own contact
   address with the user's address-of-record.  In so doing, the device
   becomes eligible to receive requests that are sent to the address-
   of-record.  Upon receiving the registration request, the registrar
   modifies the provisioning data in a SIP location service to create a
   mapping between the address-of-record for the user and the device
   where the user can currently be reached.  When future requests arrive
   at the administrative domain of this location service for the user in
   question, proxy servers ask the location service where to find the
   user, and will in turn discover the registered contact address(es).
   A SIP-based follow-me telephony service, for example, would rely on
   this real-time availability data in order to find the best place to
   reach the end user without having to cycle through numerous devices
   from which the user is not currently registered.  Note that
   addresses-of-record can be registered with other addresses-of-record;
   for example, while at home, a user might elect to register the
   address-of-record they use as their personal identity under their

ユーザを代表して登録を記録係に送ることによって、SIPデバイス(すなわち、ユーザエージェント)はそれ自身の連絡先を一時ユーザの記録されている住所に関連づけることができます。 そうする際に、デバイスは記録のアドレスに送られる要求を受け取る資格があるようになります。 登録要求を受け取ると、記録係は、ユーザのための記録されている住所と現在ユーザに連絡できるデバイスの間でマッピングを作成するようにSIP位置のサービスにおける食糧を供給するデータを変更します。 今後の要求が問題のユーザのためにこの位置のサービスの管理ドメインに到着すると、プロキシサーバは、どこでユーザを見つけるかを位置のサービスに尋ねて、順番に、登録された連絡先(es)を発見するでしょう。 例えば、私に続いているSIPベースの電話サービスは、ユーザが現在登録されない多数のデバイスを通して循環する必要はなくてエンドユーザに届く最も良い場所を見つけるためにこのリアルタイムの有用性データを当てにするでしょう。 記録の他のアドレスに記録のアドレスを登録できることに注意してください。 例えば、ホーム、登録するためには次期のユーザ力で彼らが自分達の個人的なアイデンティティ下として使用する記録されている住所をゆったり過ごしてください、それら

Peterson                    Standards Track                     [Page 3]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[3ページ]RFC3764SIP enumservice2004年4月

   work address-of-record in order to direct requests for their work
   identity to whatever devices they might have associated with their
   home address-of-record.

記録のアドレスを扱ってください。いかなるデバイスへの彼らの仕事のアイデンティティを求める要求も指示するために、それらは自己の記録に関するホームアドレスと交際したかもしれません。

   When a SIP entity (be it a user agent or proxy server) needs to make
   a forwarding decision for a Request-URI containing an address-of-
   record, it uses the mechanisms described in the SIP specification
   (RFC 3263) to locate the proper resource in the network.  Ordinarily,
   this entails resolving the domain portion of the URI (example.com in
   the example above) in order to route the call to a proxy server that
   is responsible for that domain.

SIP実体(ユーザエージェントかプロキシサーバであることにかかわらず)が、ネットワークで適切なリソースの場所を見つけるのにRequest-URIのための-アドレスを含んでいて、SIP仕様で説明されて、記録に、メカニズムを使用するという推進決定(RFC3263)をする必要があると。 通常、これは、そのドメインに原因となるプロキシサーバに呼び出しを発送するためにURI(上記の例のexample.com)のドメイン部分を決議するのを伴います。

   SIP user agents have specific communications capabilities (such as
   the ability to initiate voice communications with particular codecs,
   or support for particular SIP protocol extensions).  Because an
   address-of-record does not represent any particular device or set of
   devices, an address-of-record does not have capabilities as such.
   When a SIP user agent sends a request to an address-of-record, it
   begins a phase of capability negotiation that will eventually
   discover the best way for the originator to communicate with the
   target.  The originating user agent first expresses capabilities of
   its own in the request it sends (and preferences for the type of
   session it would like to initiate).  The expression of these
   capabilities may entail the usage of SDP [8] to list acceptable types
   of media supported and favored by the client, the inclusion of
   Required/Supported headers to negotiate compatibility of extensions,
   and possibly the usage of optional SIP extensions, for example using
   callee capabilities [7] to communicate request handling dispositions.
   Proxy servers or endpoints subsequently return responses that allow a
   rich bidirectional capability negotiation process.

SIPユーザエージェントには、特定のコミュニケーション能力(特定のコーデックとの声のコミュニケーション、または特定のSIPプロトコル拡張子のサポートを開始する能力などの)があります。 記録されている住所がどんな特定のデバイスやセットのデバイスも表さないので、記録されている住所には、そういうものの能力がありません。 SIPユーザエージェントが要求を記録されている住所に送るとき、それは結局創始者が目標で交信する最も良い方法を発見する能力交渉のフェーズを始めます。 起因しているユーザエージェントは最初に、それが送る要求(そして、それが開始したがっているセッションのタイプのための好み)でそれ自身の能力を言い表します。 これらの能力の式はクライアントによってサポートされて、好かれた許容タイプのメディアを記載するためにSDP[8]の使用法を伴うかもしれません、拡大の互換性、およびことによると任意のSIP拡張子の用法を交渉するRequired/サポートしているヘッダーの包含、例えば、要求取り扱い気質を伝える訪問される人能力[7]を使用して。 Proxyサーバか終点が次に、豊かな双方向の能力交渉プロセスを許容する応答を返します。

   The process by which SIP endpoints negotiate capabilities can overlap
   with the primary service provided by NAPTR records: permitting the
   originating client to select a particular URI for communications
   based on an ordered list of enumservices.  However, ENUM's capability
   management mechanism is decidedly one-way - the administrator of the
   telephone number expresses capabilities (in the form of protocol
   names) and preferences that the client must evaluate without
   negotiation.  Moreover, listing available protocols is not comparable
   to agreement on session media (down to the codec/interval level) and
   protocol extension support - it would be difficult to express, in the
   level of detail necessary to arrange a desired session, the
   capabilities of a SIP device within a NAPTR service field.
   Provisioning contact addresses in ENUM rather than addresses-of-
   record would compromise the SIP capability negotiation and discovery
   process.  Much of the benefit of using a URI comes from the fact that

SIP終点が能力を交渉するプロセスはNAPTR記録で提供する一次業務に重なることができます: 起因しているクライアントがenumservicesの規則正しいリストに基づくコミュニケーションのために特定のURIを選択することを許可します。 しかしながら、ENUMの能力管理メカニズムは明らかに一方向です--電話番号の管理者は能力(プロトコル名の形の)とクライアントが交渉なしで評価しなければならない好みを言い表します。 そのうえ、利用可能なプロトコルを記載するのはセッションメディア(コーデック/間隔レベルまでの)の協定とプロトコル拡大サポートに匹敵していません--言い表すのは難しいでしょう、必要なセッションをセッティングするのに必要な詳細のレベルで、NAPTRサービス分野の中のSIPデバイスの能力。 アドレスよりむしろENUMの連絡先に食糧を供給する、-、-記録はSIP能力交渉と発見プロセスに感染するでしょう。 URIを使用する利益の多くが事実から来る、それ

Peterson                    Standards Track                     [Page 4]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[4ページ]RFC3764SIP enumservice2004年4月

   it represents a logical service associated with a user, rather than a
   device - indeed, if ENUM wished to target particular devices,
   'E2IPv4' would be a more appropriate resolution service to define
   than 'E2U'.

それはデバイスよりむしろユーザに関連している論理的なサービスを表します--本当に、ENUMが特定のデバイスを狙いたいなら、'E2IPv4'は'E2U'より定義する適切な解決サービスでしょうに。

   SIP addresses-of-record may use the SIP URI scheme or the SIPS URI
   scheme.  The SIPS URI scheme, when used in an address-of-record,
   indicates that the user it represents can only be reached over a
   secure connection (using TLS).

記録のSIPアドレスはSIP URI体系かSIPS URI体系を使用するかもしれません。 記録されている住所で使用されると、SIPS URI体系は、安全な接続の上でそれが代理をするユーザに連絡できるだけであるのを示します(TLSを使用して)。

4.  The 'E2U+SIP' enumservice

4. 'E2U+SIP'enumservice

   Traditionally, the services field of a NAPTR record (as defined in
   [5]) contains a string that is composed of two subfields: a
   'protocol' subfield and a 'resolution service' subfield.  ENUM in
   particular defines an 'E2U' (E.164 to URI) resolution service.  This
   document defines an 'E2U+SIP' enumservice for SIP.

伝統的に、NAPTRのサービス分野は記録します。(中で定義されるように、[5])は2つの部分体で構成されるストリングを含んでいます: 'プロトコル'部分体と'解決サービス'部分体。 ENUMは'E2U'(URIへのE.164)解決サービスを特に定義します。 このドキュメントはSIPのために'E2U+SIP'enumserviceを定義します。

   The scheme of the URI that will appear in the regexp field of a NAPTR
   record using the 'E2U+SIP' enumservice may either be 'SIP' or 'SIPS'.
   This enumservice is best suited to SIP addresses-of-record.

NAPTR記録のregexp分野に'E2U+SIP'enumserviceを使用することで現れるURIの体系は、'SIP'か'SIPS'のどちらかであるかもしれません。 記録のSIPアドレスにこのenumserviceを合わせるのは最も良いです。

   When a SIP address-of-record appears in the regexp field of a NAPTR
   record, there is no need to further qualify the enumservice field
   with any capability data, since addresses-of-record do not have
   capabilities.

SIP記録されている住所がNAPTR記録のregexp分野に現れるとき、どんな能力データでもさらにenumservice野原に資格を与える必要は全くありません、記録のアドレスには能力がないので。

   There is also generally no need to have more than one NAPTR record
   under a single telephone number that points to a SIP address-of-
   record.

一般にも必要であるのは1NAPTRにSIPアドレスを示すただ一つの電話番号の下で記録させるために全くない、-、記録について。

   Note that the user portion of a SIP URI may contain a telephone
   number (e.g., 'sip:+1442079460148@example.com').  Clients should be
   careful to avoid infinite loops when recursively performing ENUM
   queries on URIs that result from an ENUM lookup.

SIP URIのユーザ部分が電話番号(例えば、'一口: + 1442079460148@example.com ')を含むかもしれないことに注意してください。 クライアントは再帰的に働いているENUMがURIでENUMルックアップからその結果について質問するとき、無限ループを避けるのに慎重であるはずです。

5.  Example of E2U+SIP enumservice

5. E2U+SIP enumserviceに関する例

   The following is an example of the use of the enumservice registered
   by this document in a NAPTR resource record.

↓これはNAPTRリソース記録にこのドキュメントによって登録されたenumserviceの使用に関する例です。

$ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
   IN NAPTR 10 100 "u" "E2U+sip"    "!^.*$!sip:edgar@example.com!"     .

$発生源8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+一口!」」 ^* edgar@example.com! 」 .

Peterson                    Standards Track                     [Page 5]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[5ページ]RFC3764SIP enumservice2004年4月

6.  Security Considerations

6. セキュリティ問題

   A SIP address-of-record is a canonical address by which a user is
   known - placing this address in ENUM is comparable to placing an
   email address or a similar URI in the DNS.

SIP記録されている住所はユーザが知られている正準なアドレスです--ENUMのこのアドレスを置くのはEメールアドレスか同様のURIをDNSに置くのに匹敵しています。

   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の中で提供された情報--いくつかのプライバシー問題の原因である。

   Unlike a traditional telephone number, the resource identified by 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.  An analysis of
   threats specific to the dependence of ENUM on the DNS, and the
   applicability of DNSSEC [9] to these, is provided in [1].

伝統的な電話番号と異なって、SIP URIによって特定されたリソースは、ユーザが警告される前に訪問者が暗号の資格証明書を認証と承認に提供するのを必要とするかもしれません。 この点で、SIPと協力してENUMは実際に既存のPSTNより求められていない訪問者からはるかに大きい保護を提供できます、ENUM記録の公共の有用性にもかかわらず。 DNSへのENUMの依存、およびDNSSEC[9]のこれらへの適用性への脅威詳細の分析を[1]に提供します。

7.  IANA Considerations

7. IANA問題

   This document registers the 'E2U+SIP' enumservice under the
   enumservice registry described in the IANA considerations in RFC
   3761.  Details of the registration are given in Section 2.

このドキュメントはRFC3761のIANA問題で説明されたenumservice登録の下の'E2U+SIP'enumserviceを登録します。 登録の詳細はセクション2で明らかにされます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [1]  Faltstrom, P. and M. Mealling, "The 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]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, November 1987.

[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [4]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[4]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。

   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403, October
        2002.

[5] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。

Peterson                    Standards Track                     [Page 6]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[6ページ]RFC3764SIP enumservice2004年4月

8.2.  Informative References

8.2. 有益な参照

   [6]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

[6]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日

   [7]  Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        Work in Progress.

[7] 「セッション開始プロトコル(一口)のユーザエージェント能力を示し」て、ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzviatは進行中で働いています。

   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

[8] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

   [9]  R. Arends, et al., "Protocol Modifications for the DNS Security
        Extensions", Work in Progress.

[9] R.Arends、他、「DNSセキュリティ拡張子のためのプロトコル変更」、ProgressのWork。

9.  Acknowledgements

9. 承認

   Thanks to Richard Shockey for comments on the initial draft of this
   document, and to Allison Mankin for valuable review comments.

このドキュメントの初期の草稿のコメントのためのリチャード・ショッキーと、そして、貴重なレビューコメントのためのアリソン・マンキンをありがとうございます。

10.  Author's Address

10. 作者のアドレス

   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/

Peterson                    Standards Track                     [Page 7]

RFC 3764                    SIP enumservice                   April 2004

ピーターソンStandards Track[7ページ]RFC3764SIP enumservice2004年4月

11.  Full Copyright Statement

11. 完全な著作権宣言文

   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                    Standards Track                     [Page 8]

ピーターソン標準化過程[8ページ]