RFC3761 日本語訳

Network Working Group                                       P. Faltstrom
Request for Comments: 3761                           Cisco Systems, Inc.
Obsoletes: 2916                                              M. Mealling
Category: Standards Track                                       VeriSign
                                                              April 2004

Faltstromがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3761 シスコシステムズInc.は以下を時代遅れにします。 2916年のM.食事カテゴリ: 標準化過程ベリサイン2004年4月

            The E.164 to Uniform Resource Identifiers (URI)
     Dynamic Delegation Discovery System (DDDS) Application (ENUM)

Uniform Resource Identifier(URI)ダイナミックな代表団発見システム(DDDS)アプリケーションへのE.164(ENUM)

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 discusses the use of the Domain Name System (DNS) for
   storage of E.164 numbers.  More specifically, how DNS can be used for
   identifying available services connected to one E.164 number.  It
   specifically obsoletes RFC 2916 to bring it in line with the Dynamic
   Delegation Discovery System (DDDS) Application specification found in
   the document series specified in RFC 3401.  It is very important to
   note that it is impossible to read and understand this document
   without reading the documents discussed in RFC 3401.

このドキュメントはドメインネームシステム(DNS)のE.164番号の格納の使用について議論します。 より明確に、1つのE.164番号に関連づけられた営業品目を特定するのにどのようにDNSを使用できるか。 それは、RFC3401で指定されたドキュメントシリーズで見つけられたDynamic DelegationディスカバリーSystem(DDDS)アプリケーション仕様に沿ってそれを持って来るために明確にRFC2916を時代遅れにします。 RFC3401で議論したドキュメントを読まないでこのドキュメントを読んで、理解しているのが不可能であることに注意するのは非常に重要です。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2. Use for these mechanisms for private dialing plans. . . .  3
       1.3. Application of local policy . . . . . . . . . . . . . . .  3
   2.  The ENUM Application Specifications .  . . . . . . . . . . . .  4
       2.1. Application Unique String . . . . . . . . . . . . . . . .  5
       2.2. First Well Known Rule . . . . . . . . . . . . . . . . . .  5
       2.3. Expected Output . . . . . . . . . . . . . . . . . . . . .  5
       2.4. Valid Databases . . . . . . . . . . . . . . . . . . . . .  5
            2.4.1. Flags. . . . . . . . . . . . . . . . . . . . . . .  6
            2.4.2. Services Parameters. . . . . . . . . . . . . . . .  7
       2.5. What constitutes an 'Enum Resolver'?. . . . . . . . . . .  8
   3.  Registration mechanism for Enumservices .  . . . . . . . . . .  8

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 個人的なダイヤルするこれらのメカニズムの使用は計画されています。 . . . 3 1.3. ローカルの方針. . . . . . . . . . . . . . . 3 2の適用。 ENUMアプリケーション仕様. . . . . . . . . . . . . 4 2.1。 アプリケーションのユニークなストリング. . . . . . . . . . . . . . . . 5 2.2。 最初に、よく知られている規則. . . . . . . . . . . . . . . . . . 5 2.3。 出力. . . . . . . . . . . . . . . . . . . . . 5 2.4を予想しました。 有効なデータベース. . . . . . . . . . . . . . . . . . . . . 5 2.4.1。 旗。 . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2. サービスパラメタ。 . . . . . . . . . . . . . . . 7 2.5. 'Enum Resolver'を構成すること--.8 3。 Enumservices. . . . . . . . . . . 8のための登録メカニズム

Faltstrom & Mealling        Standards Track                     [Page 1]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[1ページ]RFC3761を荒びきにすること。

       3.1. Registration Requirements . . . . . . . . . . . . . . . .  8
            3.1.1. Functionality Requirement. . . . . . . . . . . . .  8
            3.1.2. Naming requirement . . . . . . . . . . . . . . . .  9
            3.1.3. Security requirement . . . . . . . . . . . . . . .  9
            3.1.4. Publication Requirements . . . . . . . . . . . . . 10
       3.2. Registration procedure. . . . . . . . . . . . . . . . . . 10
            3.2.1. IANA Registration. . . . . . . . . . . . . . . . . 10
            3.2.2. Registration Template. . . . . . . . . . . . . . . 11
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
       6.1. DNS Security. . . . . . . . . . . . . . . . . . . . . . . 12
       6.2. Caching Security. . . . . . . . . . . . . . . . . . . . . 14
       6.3. Call Routing Security . . . . . . . . . . . . . . . . . . 14
       6.4. URI Resolution Security . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       9.1. Normative References. . . . . . . . . . . . . . . . . . . 16
       9.2. Informative References. . . . . . . . . . . . . . . . . . 16
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

3.1. 登録要件. . . . . . . . . . . . . . . . 8 3.1.1。 機能性要件。 . . . . . . . . . . . . 8 3.1.2. 要件. . . . . . . . . . . . . . . . 9 3.1.3を命名します。 セキュリティ要件. . . . . . . . . . . . . . . 9 3.1.4。 公表要件. . . . . . . . . . . . . 10 3.2。 登録手順。 . . . . . . . . . . . . . . . . . 10 3.2.1. IANA登録。 . . . . . . . . . . . . . . . . 10 3.2.2. 登録テンプレート。 . . . . . . . . . . . . . . 11 4. 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1。 例. . . . . . . . . . . . . . . . . . . . . . . . . 11 5。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 12 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 6.1. DNSセキュリティ。 . . . . . . . . . . . . . . . . . . . . . . 12 6.2. セキュリティをキャッシュします。 . . . . . . . . . . . . . . . . . . . . 14 6.3. セキュリティ. . . . . . . . . . . . . . . . . . 14 6.4にルート設定に電話をしてください。 URI解決セキュリティ. . . . . . . . . . . . . . . . . 15 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 8。 RFC2916.159以来の変化。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1。 引用規格。 . . . . . . . . . . . . . . . . . . 16 9.2. 有益な参照。 . . . . . . . . . . . . . . . . . 16 10. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 17 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 18

1.  Introduction

1. 序論

   This document discusses the use of the Domain Name System (DNS) for
   storage of E.164 numbers.  More specifically, how DNS can be used for
   identifying available services connected to one E.164 number.  It
   specifically obsoletes RFC 2916 to bring it in line with the Dynamic
   Delegation Discovery System (DDDS) Application specification found in
   the document series specified in RFC 3401 [6].  It is very important
   to note that it is impossible to read and understand this document
   without reading the documents discussed in RFC 3401 [6].

このドキュメントはドメインネームシステム(DNS)のE.164番号の格納の使用について議論します。 より明確に、1つのE.164番号に関連づけられた営業品目を特定するのにどのようにDNSを使用できるか。 それは、RFC3401[6]で指定されたドキュメントシリーズで見つけられたDynamic DelegationディスカバリーSystem(DDDS)アプリケーション仕様に沿ってそれを持って来るために明確にRFC2916を時代遅れにします。 RFC3401[6]で議論したドキュメントを読まないでこのドキュメントを読んで、理解しているのが不可能であることに注意するのは非常に重要です。

   Through transformation of International Public  Telecommunication
   Numbers in the international format [5], called within this document
   E.164 numbers, into DNS names and the use of existing DNS services
   like delegation through NS records and NAPTR records, one can look up
   what services are available for a specific E.164 in a decentralized
   way with distributed management of the different levels in the lookup
   process.

このドキュメントの中に呼ばれた国際的な形式[5]の、国際Public Telecommunication民数記の変化で、NS記録を通した代表団とNAPTR記録のような既存のDNSサービスのDNS名と使用へのE.164番号であり、人はどんなサービスがルックアップの過程による異なったレベルの分散管理で分散方法で特定のE.164に利用可能であるか見えることができます。

   The domain "e164.arpa" is being populated in order to provide the
   infrastructure in DNS for storage of E.164 numbers.  In order to
   facilitate distributed operations, this domain is divided into
   subdomains.  Holders of E.164 numbers which want to be listed in DNS
   should contact the appropriate zone administrator according to the

ドメイン"e164.arpa"は、E.164番号の格納にDNSのインフラストラクチャを提供するために居住されています。 分配された操作を容易にするために、このドメインはサブドメインに分割されます。 E.164の所有者は記載されたコネになりたがっているべきDNSが適切なゾーンの管理者に連絡するはずであるものに付番します。

Faltstrom & Mealling        Standards Track                     [Page 2]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[2ページ]RFC3761を荒びきにすること。

   policy which is attached to the zone.  One should start looking for
   this information by examining the SOA resource record associated with
   the zone, just like in normal DNS operations.

ゾーンに付けられている方針。 ゾーンに関連しているSOAリソース記録を調べることによってこの情報を探し始めるべきです、まさしく通常のDNS操作などのように。

   Of course, as with other domains, policies for such listings will be
   controlled on a subdomain basis and may differ in different parts of
   the world.

もちろん、他のドメインなら、そのようなリストのための方針は、サブドメインベースで制御されて、世界のいろいろな地方で異なるかもしれません。

1.1.  Terminology

1.1. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。

   All other capitalized terms are taken from the vocabulary found in
   the DDDS algorithm specification found in RFC 3403 [2].

他のすべての大文字で書かれた用語がRFC3403[2]で見つけられたDDDSアルゴリズム仕様で見つけられたボキャブラリーからかかります。

1.2.  Use for these mechanisms for private dialing plans

1.2. 個人的なダイヤルするこれらのメカニズムの使用は計画されています。

   This document describes the operation of these mechanisms in the
   context of numbers allocated according to the ITU-T recommendation
   E.164.  The same mechanisms might be used for private dialing plans.
   If these mechanisms are re-used, the suffix used for the private
   dialing plan MUST NOT be e164.arpa, to avoid conflict with this
   specification.  Parties to the private dialing plan will need to know
   the suffix used by their private dialing plan for correct operation
   of these mechanisms.  Further, the application unique string used
   SHOULD be the full number as specified, but without the leading '+',
   and such private use MUST NOT be called "ENUM".

このドキュメントはITU-T推薦E.164に応じて割り当てられた数の文脈における、これらのメカニズムの操作について説明します。 同じメカニズムは個人的なダイヤルするプランに使用されるかもしれません。 これらのメカニズムが再使用されているなら、個人的なダイヤルするプランに使用される接尾語は、この仕様との闘争を避けるためにはe164.arpaであるはずがありません。 個人的なダイヤルするプランへの党は、これらのメカニズムの正しい操作にそれらの個人的なダイヤルするプランによって使用される接尾語を知る必要があるでしょう。アプリケーションのユニークなストリングの中古のSHOULDはさらに、指定されるとしての定員ですが、主な'+'、およびそのような私用なしで"ENUM"と呼ばれてはいけません。

1.3.  Application of local policy

1.3. ローカルの方針の適用

   The Order field in the NAPTR record specifies in what order the DNS
   records are to be interpreted.  This is because DNS does not
   guarantee the order of records returned in the answer section of a
   DNS packet.  In most ENUM cases this isn't an issue because the
   typical regular expression will be '!^.*$!' since the first query
   often results in a terminal Rule.

NAPTR記録のOrder分野は、DNS記録がどんなオーダーで解釈されるかことであると指定します。 これはDNSがDNSパケットの答え部で返された記録の注文を保証しないからです。 '典型的な正規表現がこと'^*$!'であるので、最初の質問がしばしば端末のRuleをもたらすとき、ほとんどのENUM場合では、これは問題ではありません。

   But there are other cases (non-terminal Rules) where two different
   Rules both match the given Application Unique String.  As each Rule
   is evaluated within the algorithm, one may match a more significant
   piece of the AUS than the other.  For example, by using a non-
   terminal NAPTR a given set of numbers is sent to some private-
   dialing-plan-specific zone.  Within that zone there are two Rules
   that state that if a match is for the entire exchange and the service
   is SIP related then the first, SIP-specific rule is used.  But the
   other Rule matches a longer piece of the AUS, specifying that for

しかし、他のケース(非端末Rules)が2異なったRulesがともに与えられたApplication Unique Stringに合っているところにあります。 各Ruleがアルゴリズムの中で評価されるとき、AUSのもう片方より重要な断片に合うかもしれません。 例えば、一連の数字を考えて、非端末のNAPTR aを使用するのを何らかの個人的なプラン詳細にダイヤルしているゾーンに送ります。 そのゾーンの中に、それがマッチが全体の交換のためのものであり、サービスがSIPであるならその時1番目を関係づけて、SIP特有の規則が使用されていると述べる2Rulesがあります。 しかし、Ruleがそれを指定するAUSの、より長い断片に合っているもう片方

Faltstrom & Mealling        Standards Track                     [Page 3]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[3ページ]RFC3761を荒びきにすること。

   some other service (instant messaging) that the Rule denotes a
   departmental level service.  If the shorter matching Rule comes
   before the longer match, it can 'mask' the other rules.  Thus, the
   order in which each Rule is tested against the AUS is an important
   corner case that many DDDS applications take advantage of.

(インスタントメッセージング)を修理してください。ある他のRuleは部門のレベルサービスを指示します。 より短い合っているRuleが、より長いマッチに優先するなら、それは他の規則に'マスクをかけることができます'。 したがって、各RuleがAUSに対してテストされるオーダーは多くのDDDSアプリケーションが利用する重要な角のケースです。

   In the case where the zone authority wishes to state that two Rules
   have the same effect or are identical in usage, then the Order for
   those records is set to the same value.  In that case, the Preference
   is used to specify a locally over-ridable suggestion by the zone
   authority that one Rule might simply be better than another for some
   reason.

そして、その2Rulesを述べるというゾーン権威願望は同じ効果を持っているか、または用法が同じである場合では、それらの記録のためのOrderが同じ値に用意ができています。 その場合、Preferenceは、1Ruleが別のものより単にある理由で良いかもしれないというゾーン権威による局所的に過剰乗ることができる提案を指定するのに使用されます。

   For ENUM this specifies where a client is allowed to apply local
   policy and where it is not.  The Order field in the NAPTR is a
   request from the holder of the E.164 number that the records be
   handled in a specific way.  The Preference field is merely a
   suggestion from that E.164 holder that one record might be better
   than another.  A client implementing ENUM MUST adhere to the Order
   field but can simply take the Preference value "on advisement" as
   part of a client context specific selection method.

ENUMとして、クライアントがローカルの方針を適用できて、それが指定しないところでこれは指定します。 NAPTRのOrder分野はE.164番号の所有者からの記録が特定の方法で扱われるという要求です。 Preference分野は単にそのE.164所有者からの1つの記録が別のものより良いかもしれないという提案です。 さばきますが、実行ENUM MUSTがOrderに付着させるクライアントは単に「熟考」のクライアントの文脈の特定の選択方法の一部としてのPreference値を取ることができます。

2.  The ENUM Application Specifications

2. ENUMアプリケーション仕様

   This template defines the ENUM DDDS Application according to the
   rules and requirements found in [7].  The DDDS database used by this
   Application is found in [2] which is the document that defines the
   NAPTR DNS Resource Record type.

[7]で見つけられた規則と要件に従って、このテンプレートはENUM DDDS Applicationを定義します。 このApplicationによって使用されたDDDSデータベースはNAPTR DNS Resource Recordタイプを定義するドキュメントである[2]で見つけられます。

   ENUM is only applicable for E.164 numbers.  ENUM compliant
   applications MUST only query DNS for what it believes is an E.164
   number.  Since there are numerous dialing plans which can change over
   time, it is probably impossible for a client application to have
   perfect knowledge about every valid and dialable E.164 number.
   Therefore a client application, doing everything within its power,
   can end up with what it thinks is a syntactically correct E.164
   number which in reality is not actually valid or dialable.  This
   implies that applications MAY send DNS queries when, for example, a
   user mistypes a number in a user interface.  Because of this, there
   is the risk that collisions between E.164 numbers and non-E.164
   numbers can occur.  To mitigate this risk, the E2U portion of the
   service field MUST NOT be used for non-E.164 numbers.

E.164番号だけに、ENUMは適切です。 ENUM対応することのアプリケーションはそれがE.164番号であると信じていることのためにDNSについて質問するだけでよいです。 時間がたつにつれて変化できる多数のダイヤルするプランがあるので、クライアントアプリケーションにはあらゆる有効、そして、dialable E.164番号に関する完全な知識があるのは、たぶん不可能です。 したがって、パワーの中ですべてをして、クライアントアプリケーションは、それが実際にほんとうは有効でないシンタクス上適度のE.164番号であると考えることで終わるか、または「ダイヤル-可能」されることができます。 これは、例えば、アプリケーションがDNS質問にいつを送るかもしれないかを含意して、ユーザmistypesはユーザーインタフェースの数です。 これのために、E.164番号と非E.164番号との衝突が起こることができるというリスクがあります。 この危険を緩和するために、非E.164番号にサービス分野のE2U部分を使用してはいけません。

Faltstrom & Mealling        Standards Track                     [Page 4]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[4ページ]RFC3761を荒びきにすること。

2.1.  Application Unique String

2.1. アプリケーションのユニークなストリング

   The Application Unique String is a fully qualified E.164 number minus
   any non-digit characters except for the '+' character which appears
   at the beginning of the number.  The "+" is kept to provide a well
   understood anchor for the AUS in order to distinguish it from other
   telephone numbers that are not part of the E.164 namespace.

Application Unique Stringは数の始めに現れる'+'キャラクタ以外のどんな非ケタキャラクタを引いた完全に適切なE.164番号です。 「+」は、E.164名前空間の一部でない他の電話番号とそれを区別するためによく理解されているアンカーをAUSに供給するために保たれます。

   For example, the E.164 number could start out as "+44-116-496-0348".
   To ensure that no syntactic sugar is allowed into the AUS, all non-
   digits except for "+" are removed, yielding "+441164960348".

例えば、E.164番号は「+44-116-496-0348」として始めることができました。 シンタックスシュガーが全くAUSに許容されていないのを保証するために、「+」を除いたすべての非ケタを取り除きます、「+441164960348」をもたらして。

2.2.  First Well Known Rule

2.2. 最初のよく知られている規則

   The First Well Known Rule for this Application is the identity rule.
   The output of this rule is the same as the input.  This is because
   the E.164 namespace and this Applications databases are organized in
   such a way that it is possible to go directly from the name to the
   smallest granularity of the namespace directly from the name itself.

このApplicationのためのFirst Well Known Ruleはアイデンティティ規則です。 この規則の出力は入力と同じです。 これはE.164名前空間とこのApplicationsデータベースが直接名前自体から直接名前から最も小さい名前空間の粒状まで行くのが可能であるような方法で組織化されるからです。

   Take the previous example, the AUS is "+441164960348".  Applying the
   First Well Known Rule produces the exact same string,
   "+441164960348".

前の例を取ってください、そして、AUSによる「+441164960348」ということです。 First Well Known Ruleを適用すると、全く同じストリング、「+441164960348」は生産されます。

2.3.  Expected Output

2.3. 予想された出力

   The output of the last DDDS loop is a Uniform Resource Identifier in
   its absolute form according to the 'absoluteURI' production in the
   Collected ABNF found in RFC2396 [4].

最後のDDDS輪の出力はRFC2396[4]で見つけられたCollected ABNFでの'absoluteURI'生産に従って絶対フォームでのUniform Resource Identifierです。

2.4.  Valid Databases

2.4. 有効なデータベース

   At present only one DDDS Database is specified for this Application.
   "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
   Database" (RFC 3403) [2] specifies a DDDS Database that uses the
   NAPTR DNS resource record to contain the rewrite rules.  The Keys for
   this database are encoded as domain-names.

現在のところ、1DDDS DatabaseだけがこのApplicationに指定されます。 「ダイナミックな代表団発見システム(DDDS)パートThree:」 「DNS Database」(RFC3403)[2]は書換規則を含むのにNAPTR DNSリソース記録を使用するDDDS Databaseを指定します。 このデータベースのためのキーズはドメイン名としてコード化されます。

   The output of the First Well Known Rule for the ENUM Application is
   the E.164 number minus all non-digit characters except for the +.  In
   order to convert this to a unique key in this Database the string is
   converted into a domain-name according to this algorithm:

ENUM ApplicationのためのFirst Well Known Ruleの出力は+を除いたすべての非ケタキャラクタを引いたE.164番号です。このDatabaseのユニークキーにこれを変換するために、このアルゴリズムによると、ストリングはドメイン名に変換されます:

   1. Remove all characters with the exception of the digits.  For
      example, the First Well Known Rule produced the Key
      "+442079460148".  This step would simply remove the leading "+",
      producing "442079460148".

1. ケタ以外のすべてのキャラクタを外してください。 例えば、First Well Known RuleはKey「+442079460148」を生産しました。 「442079460148」を生産して、このステップは単に主な「+」を取り除くでしょう。

Faltstrom & Mealling        Standards Track                     [Page 5]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[5ページ]RFC3761を荒びきにすること。

   2. Put dots (".") between each digit.  Example:
      4.4.2.0.7.9.4.6.0.1.4.8

2. ドットを置いてください、(「」、)、各ケタの間で。 例: 4.4.2.0.7.9.4.6.0.1.4.8

   3. Reverse the order of the digits.  Example:
      8.4.1.0.6.4.9.7.0.2.4.4

3. ケタの注文を逆にしてください。 例: 8.4.1.0.6.4.9.7.0.2.4.4

   4. Append the string ".e164.arpa" to the end.  Example:
      8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa

4. ストリング".e164.arpa"を終わりに追加してください。 例: 8.4.1.0.6.4.9.7.0.2.4.4. e164.arpa

   This domain-name is used to request NAPTR records which may contain
   the end result or, if the flags field is blank, produces new keys in
   the form of domain-names from the DNS.

このドメイン名が結末を含むかもしれないNAPTR記録を要求するのに使用されるか、旗であるなら、分野は、空白であり、ドメイン名の形でDNSから新しいキーを生産します。

   Some nameserver implementations attempt to be intelligent about items
   that are inserted into the additional information section of a given
   DNS response.  For example, BIND will attempt to determine if it is
   authoritative for a domain whenever it encodes one into a packet.  If
   it is, then it will insert any A records it finds for that domain
   into the additional information section of the answer until the
   packet reaches the maximum length allowed.  It is therefore
   potentially useful for a client to check for this additional
   information.  It is also easy to contemplate an ENUM enhanced
   nameserver that understand the actual contents of the NAPTR records
   it is serving and inserts more appropriate information into the
   additional information section of the response.  Thus, DNS servers
   MAY interpret Flag values and use that information to include
   appropriate resource records in the Additional Information portion of
   the DNS packet.  Clients are encouraged to check for additional
   information but are not required to do so.  See the Additional
   Information Processing section of RFC 3403 [2], Section 4.2 for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

いくつかのネームサーバ実現が、与えられたDNS応答の追加情報部に挿入される商品に関して知的であることを試みます。 例えば、BINDは、ドメインに、1つをパケットにコード化するときはいつも、それが正式であるかどうか決定するのを試みるでしょう。 あると、それは最大の長さの範囲が許容したパケットまでそのドメインに見つけるどんなA記録も答えの追加情報部に挿入するでしょう。 したがって、クライアントがこの追加情報がないかどうかチェックするのは、潜在的に役に立ちます。 ENUMを熟考するのがたやすくも、NAPTR記録の実際のコンテンツが役立つのを理解しているネームサーバを高めて、応答の追加情報部により適切な情報を挿入するということです。 したがって、DNSサーバは、DNSパケットのAdditional情報部分に適切なリソース記録を含むのにFlag値を解釈して、その情報を使用するかもしれません。 クライアントは、追加情報がないかどうかチェックするよう奨励されますが、そうする必要はありません。 RFC3403[2]のAdditional情報Processing部、NAPTR記録に関する詳しい情報のためのセクション4.2、およびDNS応答パケットのAdditional情報部を見てください。

   The character set used to encode the substitution expression is UTF-
   8.  The allowed input characters are all those characters that are
   allowed anywhere in an E.164 number.  The characters allowed to be in
   a Key are those that are currently defined for DNS domain-names.

代替表現をコード化するのに使用される文字の組はUTF8です。 許容入力キャラクタは皆E.164番号でどこでも許容されているそれらのキャラクタです。 Keyにあることができたキャラクタは現在DNSドメイン名のために定義されるものです。

2.4.1.  Flags

2.4.1. 旗

   This Database contains a field that contains flags that signal when
   the DDDS algorithm has finished.  At this time only one flag, "U", is
   defined.  This means that this Rule is the last one and that the
   output of the Rule is a URI [4].  See RFC 3404 [3].

このDatabaseはDDDSアルゴリズムが終わったとき合図する旗を含む分野を含んでいます。 このとき、「U」という1個の旗だけが定義されます。 これはこのRuleが最後のものであり、Ruleの出力がURI[4]であることを意味します。 RFC3404[3]を見てください。

   If a client encounters a record with an unknown flag, it MUST ignore
   it and move to the next Rule.  This test takes precedence over any
   ordering since flags can control the interpretation placed on fields.

未知の旗でクライアントが記録に遭遇するなら、それは、それを無視して、次のRuleに動かなければなりません。 旗がフィールドに置かれた解釈を制御できるので、このテストはどんな注文の上でも優先します。

Faltstrom & Mealling        Standards Track                     [Page 6]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[6ページ]RFC3761を荒びきにすること。

   A novel flag might change the interpretation of the regexp and/or
   replacement fields such that it is impossible to determine if a
   record matched a given target.

目新しい旗がregexp、そして/または、交換分野の解釈を変えるかもしれないので、記録が与えられた目標に合っていたかどうか決定するのは不可能です。

   If this flag is not present then this rule is non-terminal.  If a
   Rule is non-terminal then clients MUST use the Key produced by this
   Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
   client to query for new NAPTR records at the domain-name that is the
   result of this Rule).

この旗が存在していないなら、この規則は非端末です。 Ruleが非端末であるなら、クライアントはDDDSの新しいKeyが輪にするので(すなわち、クライアントが新しいNAPTRのためにこのRuleの結果であるドメイン名で記録について質問することを引き起こします)このRewrite Ruleによって生産されたKeyを使用しなければなりません。

2.4.2.  Services Parameters

2.4.2. サービスパラメタ

   Service Parameters for this Application take the following form and
   are found in the Service field of the NAPTR record.

このApplicationのためのサービスParametersは以下の形を取って、NAPTR記録のService野原で発見されます。

               service-field = "E2U" 1*(servicespec)
               servicespec   = "+" enumservice
               enumservice   = type 0*(subtypespec)
               subtypespec   = ":" subtype
               type          = 1*32(ALPHA / DIGIT)
               subtype       = 1*32(ALPHA / DIGIT)

「サービス分野=「E2U」1*(servicespec)servicespecは「タイプ0*(subtypespec)+ 」 enumservice enumservice=subtypespec=」と等しいです」 「副-タイプ」タイプ=1*32(アルファー/DIGIT)「副-タイプ」=1*32(アルファー/ケタ)

   In other words, a non-optional "E2U" (used to denote ENUM only
   Rewrite Rules in order to mitigate record collisions) followed by 1
   or more or more Enumservices which indicate what class of
   functionality a given end point offers.  Each Enumservice is
   indicated by an initial '+' character.

言い換えれば、非任意の「E2U」(以前は、よく書き直しだけが記録的な衝突を緩和するために統治するENUMを指示していた)は与えられたエンドポイントがどんなクラスの機能性を提供するかを示す1Enumservicesで続きました。 各Enumserviceは初期の'+'キャラクタによって示されます。

2.4.2.1.  ENUM Services

2.4.2.1. ENUMサービス

   Enumservice specifications contain the functional specification
   (i.e., what it can be used for), the valid protocols, and the URI
   schemes that may be returned.  Note that there is no implicit mapping
   between the textual string "type" or "subtype" in the grammar for the
   Enumservice and URI schemes or protocols.  The mapping, if any, must
   be made explicit in the specification for the Enumservice itself.  A
   registration of a specific Type also has to specify the Subtypes
   allowed.

Enumservice仕様は機能的な仕様(すなわち、それを使用できる何)、有効なプロトコル、および返されるかもしれないURI計画を含んでいるか。 原文のストリングの「タイプ」か"「副-タイプ」"の間には、EnumserviceとURI計画かプロトコルのための文法にどんな暗黙のマッピングもないことに注意してください。 もしあればマッピングをEnumservice自身のための仕様で明白にしなければなりません。 特定のTypeの登録も許容されたSubtypesを指定しなければなりません。

   The only exception to the registration rule is for Types and Subtypes
   used for experimental purposes, and those are to start with the facet
   "X-".  These elements are unregistered, experimental, and should be
   used only with the active agreement of the parties exchanging them.

登録規則への唯一の例外が実験目的に使用されるTypesとSubtypesのためのものです、そして、それらはまず第一に一面「X」です。 これらの要素は、登録されていなくて、実験的であり、彼らを交換するパーティーの活発な協定だけと共に使用されるべきです。

   The registration mechanism is specified in Section 3.

登録メカニズムはセクション3で指定されます。

Faltstrom & Mealling        Standards Track                     [Page 7]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[7ページ]RFC3761を荒びきにすること。

2.5.  What constitutes an 'Enum Resolver'?

2.5. 何が'Enum Resolver'を構成しますか?

   There has been some confusion over what exactly an ENUM Resolver
   returns and what relation that has to the 'Note 1' section in RFC
   3402.  On first reading it seems as though it might be possible for
   an ENUM Resolver to return two Rules.

ENUM Resolverがいったい何を返すか、そして、それがRFC3402の'注意1'セクションにどんな関係を持っているかの上に何らかの混乱がありました。 最初に読書すると、まるでENUM Resolverが2Rulesを返すのが、可能であるかもしれないかのように見えます。

   The ENUM algorithm always returns a single rule.  Specific
   applications may have application-specific knowledge or facilities
   that allow them to present multiple results or speed selection, but
   these should never change the operation of the algorithm.

ENUMアルゴリズムはいつもただ一つの規則を返します。 特定のアプリケーションはアプリケーション特有の知識かそれらが複数個の答か速度選択を提示できる施設を持っているかもしれませんが、これらはアルゴリズムの操作を決して変えるべきではありません。

3.  Registration mechanism for Enumservices

3. Enumservicesのための登録メカニズム

   As specified in the ABNF found in Section 2.4.2, an 'enumservice' is
   made up of 'types' and 'subtypes'.  For any given 'type', the
   allowable 'subtypes' must be specified in the registration.  There is
   currently no concept of a registered 'subtype' outside the scope of a
   given 'type'.  Thus the registration process uses the 'type' as its
   main key within the IANA Registry.  While the combination of each
   type and all of its subtypes constitutes the allowed values for the
   'enumservice' field, it is not sufficient to simply document those
   values.  A complete registration will also include the allowed URI
   schemes, a functional specification, security considerations,
   intended usage, and any other information needed to allow for
   interoperability within ENUM.  In order to be a registered ENUM
   Service, the entire specification, including the template, requires
   approval by the IESG and publication of the Enumservice registration
   specification as an RFC.

セクション2.4.2で見つけられたABNFで指定されるように、'enumservice'は'タイプ'と'血液型亜型'で作られます。 どんな与えられた'タイプ'としても、登録で許容できる'血液型亜型'を指定しなければなりません。 与えられた'タイプ'の範囲の外に登録された'「副-タイプ」'の概念が全く現在、ありません。 したがって、登録手続はメインキーとしてIANA Registryの中で'タイプ'を使用します。 それぞれのタイプの組み合わせと血液型亜型のすべてが'enumservice'分野に許容値を構成しますが、単にそれらの値を記録するのは十分ではありません。 また、完全な登録はENUMの中で相互運用性を考慮するのに必要である許容URI計画、機能的な仕様、セキュリティ問題、意図している用法、およびいかなる他の情報も含むでしょう。 登録されたENUM Serviceになるように、テンプレートを含む全体の仕様で、RFCとしてEnumservice登録仕様のIESGと公表の承認を要します。

3.1.  Registration Requirements

3.1. 登録要件

   Service registration proposals are all expected to conform to various
   requirements laid out in the following sections.

サービス登録提案が以下のセクションで広げられた様々な要件に従うとすべて予想されます。

3.1.1.  Functionality Requirement

3.1.1. 機能性要件

   A registered Enumservice must be able to function as a selection
   mechanism when choosing one NAPTR resource record from another.  That
   means that the registration MUST specify what is expected when using
   that very NAPTR record, and the URI which is the outcome of the use
   of it.

別のものからの1つのNAPTRリソース記録を選ぶとき、登録されたEnumserviceは選択メカニズムとして機能できなければなりません。 それは、登録が、まさしくそのNAPTR記録、およびそれの使用の結果であるURIを使用するとき、何が予想されるかを指定しなければならないことを意味します。

   Specifically, a registered Enumservice MUST specify the URI scheme(s)
   that may be used for the Enumservice, and, when needed, other
   information which will have to be transferred into the URI resolution
   process itself (LDAP Distinguished Names, transferring of the AUS
   into the resulting URI, etc).

明確に、登録されたEnumserviceはEnumserviceに使用されるかもしれないURI計画、および必要でありURI解決の過程自体に移されなければならない他の情報(LDAP Distinguished Names、結果として起こるURIにAUSを移しますなど)を指定しなければなりません。

Faltstrom & Mealling        Standards Track                     [Page 8]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[8ページ]RFC3761を荒びきにすること。

3.1.2.  Naming requirement

3.1.2. 要件を命名します。

   An Enumservice MUST be unique in order to be useful as a selection
   criteria.  Since an Enumservice is made up of a type and a type-
   dependent subtype, it is sufficient to require that the 'type' itself
   be unique.  The 'type' MUST be unique, conform to the ABNF specified
   in Section 2.4.2, and MUST NOT start with the facet "X-" which is
   reserved for experimental, private use.

Enumserviceは、選択評価基準として役に立つようにユニークでなければなりません。 Enumserviceがタイプとタイプの依存する「副-タイプ」で作られるので、'タイプ'自体がユニークであることが必要であるのは十分です。 'タイプ'は、ユニークでなければならなく、セクション2.4.2で指定されたABNFに従って、実験私用のために予約される一面「X」から始めてはいけません。

   The subtype, being dependent on the type, MUST be unique within a
   given 'type'.  It must conform to the ABNF specified in Section
   2.4.2, and MUST NOT start with the facet "X-" which is reserved for
   experimental, private use.  The subtype for one type MAY be the same
   as a subtype for a different registered type but it is not sufficient
   to simply reference another type's subtype.  The function of each
   subtype must be specified in the context of the type being
   registered.

タイプに依存していて、「副-タイプ」は与えられた'タイプ'の中でユニークであるに違いありません。 それは、セクション2.4.2で指定されたABNFに従わなければならなくて、実験私用のために予約される一面「X」から始めてはいけません。 1つのタイプのための「副-タイプ」は異なった登録されたタイプのための「副-タイプ」と同じであるかもしれませんが、それは別のタイプの単に参照「副-タイプ」に十分ではありません。 登録されていて、タイプの文脈でそれぞれの「副-タイプ」の機能を指定しなければなりません。

3.1.3.  Security requirement

3.1.3. セキュリティ要件

   An analysis of security issues is required for all registered
   Enumservices.  (This is in accordance with the basic requirements for
   all IETF protocols.)

安全保障問題の分析がすべての登録されたEnumservicesに必要です。 (すべてのIETFプロトコルのための基本的な要件に従って、これはあります。)

   All descriptions of security issues must be as accurate as possible
   regardless of registration tree.  In particular, a statement that
   there are "no security issues associated with this Enumservice" must
   not be confused with "the security issues associated with this
   Enumservice have not been assessed".

安全保障問題のすべての記述が登録木にかかわらずできるだけ正確でなければなりません。 特に、「このEnumserviceに関連している安全保障問題がありません」があるという声明は「このEnumserviceに関連している安全保障問題は評価されていないこと」に混乱してはいけません。

   There is no requirement that an Enumservice must be secure or
   completely free from risks.  Nevertheless, all known security risks
   must be identified in the registration of an Enumservice.

Enumserviceが安全であるか、または完全に無料でなければならないという要件は全くリスクから来ていません。 それにもかかわらず、Enumserviceの登録ですべての知られているセキュリティ危険を特定しなければなりません。

   The security considerations section of all registrations is subject
   to continuing evaluation and modification.

すべての登録証明書のセキュリティ問題部は継続する評価と変更を受けることがあります。

   Some of the issues that should be looked at in a security analysis of
   an Enumservice are:

それがEnumserviceの証券分析で見られるべきである問題のいくつかは以下の通りです。

   1. Complex Enumservices may include provisions for directives that
      institute actions on a user's resources.  In many cases provision
      can be made to specify arbitrary actions in an unrestricted
      fashion which may then have devastating results.  Especially if
      there is a risk for a new ENUM lookup, and because of that an
      infinite loop in the overall resolution process of the E.164.

1. 複雑なEnumservicesはユーザのリソースへの動作を設ける指示のための条項を含むかもしれません。 多くの場合、次に破壊的な結果を持っているかもしれない無制限なファッションで勝手な行動を指定するのを設備をすることができます。 特に無限が輪にされるという新しいENUMルックアップ、およびそれによるリスクがE.164の総合的な解決の過程にあれば。

Faltstrom & Mealling        Standards Track                     [Page 9]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[9ページ]RFC3761を荒びきにすること。

   2. Complex Enumservices may include provisions for directives that
      institute actions which, while not directly harmful, may result in
      disclosure of information that either facilitates a subsequent
      attack or else violates the users privacy in some way.

2. 複雑なEnumservicesは直接有害でない間にどちらかがその後の攻撃を容易にするか、または何らかの方法でユーザプライバシーに違反するという情報の公開をもたらすかもしれない動作を設ける指示のための条項を含むかもしれません。

   3. An Enumservice might be targeted for applications that require
      some sort of security assurance but do not provide the necessary
      security mechanisms themselves.  For example, an Enumservice could
      be defined for storage of confidential security services
      information such as alarm systems or message service passcodes,
      which in turn require an external confidentiality service.

3. Enumserviceはある種の安全保証を必要としますが、必要なセキュリティー対策自体を提供しないアプリケーションのために狙うかもしれません。 例えば、システムを驚かせるような秘密のセキュリティー・サービス情報かメッセージサービスpasscodesの格納とEnumserviceを定義できました。(順番に、passcodesは外部の秘密性サービスを必要とします)。

3.1.4.  Publication Requirements

3.1.4. 公表要件

   Proposals for Enumservices registrations MUST be published as one of
   the following documents; RFC on the Standards Track, Experimental
   RFC, or as a BCP.

以下のドキュメントの1つとしてEnumservices登録証明書のための提案を発行しなければなりません。 標準化過程と、実験的RFCか、BCPとしたRFC。

   IANA will retain copies of all Enumservice registration proposals and
   "publish" them as part of the Enumservice Registration tree itself.

IANAはすべてのEnumservice登録提案のコピーを保有して、Enumservice Registration木自体の一部としてそれらを「発行するでしょう」。

3.2.  Registration procedure

3.2. 登録手順

3.2.1.  IANA Registration

3.2.1. IANA登録

   Provided that the Enumservice has obtained the necessary approval,
   and the RFC is published, IANA will register the Enumservice and make
   the Enumservice registration available to the community in addition
   to the RFC publication itself.

Enumserviceが必要な承認を得て、RFCが発行されると、IANAはEnumserviceを登録して、RFC公表自体に加えてEnumservice登録を共同体に利用可能にするでしょう。

3.2.1.1.  Location of Enumservice Registrations

3.2.1.1. Enumservice登録証明書の位置

   Enumservice registrations will be published in the IANA repository
   and made available via anonymous FTP at the following URI:
   "ftp://ftp.iana.org/assignments/enum-services/".

Enumservice登録証明書をIANA倉庫で発行して、以下のURIにおける公開FTPで利用可能にするでしょう: " ftp://ftp.iana.org/assignments/enum-services/ "。

3.2.1.2.  Change Control

3.2.1.2. 変化コントロール

   Change control of Enumservices stay with the IETF via the RFC
   publication process.  Especially, Enumservice registrations may not
   be deleted; Enumservices which are no longer believed appropriate for
   use can be declared OBSOLETE by publication of a new RFC and a change
   to their "intended use" field; such Enumservice will be clearly
   marked in the lists published by IANA.

RFC公表プロセスを通したIETFと共にEnumservices滞在のコントロールを変えてください。 特に、Enumservice登録証明書は削除されないかもしれません。 もう使用に適切であることは信じられていないEnumservicesが新しいRFCの公表による宣言しているOBSOLETEであるかもしれなく、それらの「意図している使用」への変化は分野です。 そのようなEnumserviceはIANAによって発表されたリストで明確にマークされるでしょう。

Faltstrom & Mealling        Standards Track                    [Page 10]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[10ページ]RFC3761を荒びきにすること。

3.2.2.  Registration Template

3.2.2. 登録テンプレート

   Enumservice Type:

Enumserviceはタイプします:

   Enumservice Subtype(s):

Enumservice Subtype(s):

   URI Scheme(s):

URI体系:

   Functional Specification:

機能的な仕様:

   Security considerations:

セキュリティ問題:

   Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)

意図している用法: (1つ、コモン使用か時代遅れで制限されて、

   Author:

以下を書いてください。

   Any other information that the author deems interesting:

作者がおもしろいと考えるいかなる他の情報も:

   Note: In the case where a particular field has no value, that field
   is left completely blank, especially in the case where a given type
   has no subtypes.

以下に注意してください。 特定の分野が値を全く持っていない場合では、その野原は完全に空白のままにされます、特に与えられたタイプが血液型亜型を全く持っていない場合で。

4.  Examples

4. 例

   The examples below use theoretical services that contain Enumservices
   which might not make sense, but that are still used for educational
   purposes.  For example, the protocol used is in some cases exactly
   the same string as the URI scheme.  That was the specification in RFC
   2916, but this 'default' specification of an Enumservice is no longer
   allowed.  All Enumservices need to be registered explicitly by the
   procedure specified in section Section 3.

以下の例は理解できないかもしれないEnumservicesを含みますが、まだ教育の目的上利用されている理論上のサービスを利用します。 例えば、使用されるプロトコルはいくつかの場合まさにURI体系と同じストリングです。 それはRFC2916の仕様でしたが、Enumserviceのこの'デフォルト'仕様はもう許容されていません。 すべてのEnumservicesが、セクションセクション3で指定された手順で明らかに登録される必要があります。

4.1.  Example

4.1. 例

   $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
      NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
      NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

$発生源3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa。 「$!一口: NAPTR10 100「u」「E2U+一口!」」 ^* info@example.com! 」 . 「$!h323: NAPTR10 101「u」「E2U+h323!」」 ^* info@example.com! 」 . 「$!mailto: NAPTR10 102「u」「E2U+msg!」」 ^* info@example.com! 」 .

   This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
   preferably contacted by SIP, secondly via H.323 for voice, and
   thirdly by SMTP for messaging.  Note that the tokens "sip", "h323",
   and "msg" are Types registered with IANA, and they have no implicit
   connection with the protocols or URI schemes with the same names.

これがそれについて説明する、ドメイン3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa望ましくは、三番目に、メッセージングのために第二に声のためのH.323を通してSMTPによってSIPによって連絡されます。 トークン「一口」、"h323"、および"msg"がIANAに登録されたTypesであり、彼らにはプロトコルかURI体系との暗黙接続が全く同じ名前と共にいないことに注意してください。

Faltstrom & Mealling        Standards Track                    [Page 11]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[11ページ]RFC3761を荒びきにすること。

   In all cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (specified by the URI
   schemes sip, h323 and mailto) to know what node to contact for each.

すべての場合では、解決プロセスの次のステップはそれぞれのそれぞれのためにどんなノードに連絡したらよいかを知るためには(体系がちびちび飲むURI、h323によって指定されmailto)のプロトコルに解決メカニズムを使用することです。

5.  IANA Considerations

5. IANA問題

   RFC 2916 (which this document replaces) requested IANA to delegate
   the E164.ARPA domain following instructions to be provided by the
   IAB.  The domain was delegated according to those instructions.
   Names within this zone are to be delegated to parties according to
   the ITU-T Recommendation E.164.  The names allocated should be
   hierarchic in accordance with ITU-T Recommendation E.164, and the
   codes should be assigned in accordance with that Recommendation.

RFC2916(このドキュメントが取り替える)は、指示に従うE164.ARPAドメインがIABによって提供されるのを代表として派遣するようIANAに要求しました。 それらの指示に応じて、ドメインを代表として派遣しました。 このゾーンの中の名前はITU-T Recommendation E.164に応じてパーティーへ代表として派遣することです。 ITU-T Recommendation E.164によると、割り当てられた名前は階層的であるべきです、そして、そのRecommendationによると、コードは割り当てられるべきです。

   IAB is to coordinate with ITU-T TSB if the technical contact for the
   domain e164.arpa is to change, as ITU-T TSB has an operational
   working relationship with this technical contact which needs to be
   reestablished.

ドメインe164.arpaの技術連絡担当者が変化するつもりであるなら、IABはITU-T TSBと共に調整することになっています、ITU-T TSBにこの技術連絡担当者との復職する必要がある操作上の仕事上のお付き合いがあるとき。

   Delegations in the zone e164.arpa (not delegations in delegated
   domains of e164.arpa) should be done after Expert Review, and the
   IESG will appoint a designated expert.

Expert Reviewの後にゾーンe164.arpa(e164.arpaの代表として派遣されたドメインの委譲でない)の委譲をするべきです、そして、IESGは指定された専門家を任命するでしょう。

   IANA has created a registry for Enumservices as specified in Section
   3.  Whenever a new Enumservice is registered by the RFC process in
   the IETF, IANA is at the time of publication of the RFC to register
   the Enumservice and add a pointer to the RFC itself.

IANAはセクション3における指定されるとしてのEnumservicesのための登録を作成しました。 新しいEnumserviceがIETFのRFCプロセスによって登録されるときはいつも、RFCの公表時点で、RFC自身にEnumserviceを登録して、指針を加えるために、IANAはあります。

6.  Security Considerations

6. セキュリティ問題

6.1.  DNS Security

6.1. DNSセキュリティ

   As ENUM uses DNS, which in its current form is an insecure protocol,
   there is no mechanism for ensuring that the data one gets back is
   authentic.  As ENUM is deployed on the global Internet, it is
   expected to be a popular target for various kind of attacks, and
   attacking the underlying DNS infrastructure is one way of attacking
   the ENUM service itself.

ENUMがDNS(現在のフォームでは、不安定なプロトコルである)を使用するとき、1つが取り戻すデータが確実に正統になるようにするためのメカニズムが全くありません。 ENUMが世界的なインターネットで配布されて、それが様々な種類の攻撃のための人気のターゲットであると予想されて、基本的なDNSインフラストラクチャを攻撃するのがENUMサービス自体を攻撃することにおいて一方通行であるときに。

   There are multiple types of attacks that can happen against DNS that
   ENUM implementations should be aware of.  The following threats are
   taken from Threat Analysis Of The Domain Name System [10]:

ENUM実装が意識しているべきであるDNSに対して起こることができる複数のタイプの攻撃があります。 Threat Analysis Ofドメインネームシステム[10]から以下の脅威を取ります:

   Packet Interception
      Some of the simplest threats against DNS are various forms of
      packet interception: monkey-in-the-middle attacks, eavesdropping
      on requests combined with spoofed responses that beat the real
      response back to the resolver, and so forth.  In any of these

DNSに対する最も簡単な脅威のパケットInterception Someは様々な形式のパケット妨害です: 中央の猿攻撃、要求を立ち聞きするのはレゾルバへの本当の応答後部などを打つ偽造している応答に結合しました。 これらのいずれでも

Faltstrom & Mealling        Standards Track                    [Page 12]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[12ページ]RFC3761を荒びきにすること。

      scenarios, the attacker can simply tell either party (usually the
      resolver) whatever it wants that party to believe.  While packet
      interception attacks are far from unique to DNS, DNS's usual
      behavior of sending an entire query or response in a single
      unsigned, unencrypted UDP packet makes these attacks particularly
      easy for any bad guy with the ability to intercept packets on a
      shared or transit network.

シナリオであり、攻撃者は、そのパーティーに何でも信じて欲しくてもパーティーへ行く(通常レゾルバ)ように単に言うことができます。 パケット妨害攻撃はDNSに全くユニークではありませんが、DNSの未署名の単一のunencrypted UDPパケットで全体の質問か応答を送る普通の振舞いで、これらの攻撃は共有されるかトランジットネットワークでパケットを妨害する能力があるどんな悪者にも特に簡単になります。

   ID Guessing and Query Prediction
      Since the ID field in the DNS header is only a 16-bit field and
      the server UDP port associated with DNS is a well-known value,
      there are only 2**32 possible combinations of ID and client UDP
      port for a given client and server.  Thus it is possible for a
      reasonable brute force attack to allow an attacker to masquerade
      as a trusted server.  In most respects, this attack is similar to
      a packet interception attack except that it does not require the
      attacker to be on a transit or shared network.

GuessingとQuery Prediction Since IDがDNSヘッダーでさばくIDは16ビットの分野にすぎません、そして、DNSに関連しているサーバUDPポートがよく知られる値である、与えられたクライアントとサーバのためのIDとクライアントUDPポートの2**32可能な組み合わせしかありません; したがって、攻撃者が妥当なブルートフォースアタックで信じられたサーバのふりをすることができるのは、可能です。ほとんどの点で、トランジットか共用回線網にあるのが攻撃者を必要としないのを除いて、この攻撃はパケット妨害攻撃と同様です。

   Name-based Attacks
      Name-based attacks use the actual DNS caching behavior as a tool
      to insert bad data into a victim's cache, thus potentially
      subverting subsequent decisions based on DNS names.  Most examples
      occur with CNAME, NS and DNAME Resource Records as they redirect a
      victim's query to another location.  The common thread in all of
      these attacks is that response messages allow the attacker to
      introduce arbitrary DNS names of the attacker's choosing and
      provide further information that the attacker claims is associated
      with those names; unless the victim has better knowledge of the
      data associated with those names, the victim is going to have a
      hard time defending against this class of attacks.

名前ベースのAttacks Nameベースの攻撃は悪いデータを犠牲者のキャッシュに挿入するためにツールとして振舞いをキャッシュする実際のDNSを使用します、その結果、潜在的に、DNS名に基づくその後の決定を打倒します。 彼らがもう1つの位置に犠牲者の質問を向け直すとき、ほとんどの例がCNAME、NS、およびDNAME Resource Recordsと共に現れます。 これらの攻撃のすべての一般的なスレッドは攻撃者が応答メッセージで攻撃者の選ぶことの任意のDNS名を紹介して、攻撃者がそれらの名前に関連していると主張する詳細を提供するということです。 犠牲者にそれらの名前に関連しているデータに関する、より良い知識がない場合、犠牲者は、このクラスの攻撃に対して防御するのに苦労するでしょう。

   Betrayal By A Trusted Server
      Another variation on the packet interception attack is the trusted
      server that turns out not to be so trustworthy, whether by
      accident or by intent.  Many client machines are only configured
      with stub resolvers, and use trusted servers to perform all of
      their DNS queries on their behalf.  In many cases the trusted
      server is furnished by the user's ISP and advertised to the client
      via DHCP or PPP options.  Besides accidental betrayal of this
      trust relationship (via server bugs, successful server break-ins,
      etc), the server itself may be configured to give back answers
      that are not what the user would expect (whether in an honest
      attempt to help the user or to further some other goal such as
      furthering a business partnership between the ISP and some third
      party).

パケット妨害攻撃の裏切りBy A Trusted Server Another変化はそれほど信頼できないと判明する信じられたサーバです、偶然にか故意にであることにかかわらず。 多くのクライアントマシンが、彼らのDNS質問のすべてをそれらの利益に実行するのにスタッブレゾルバによって構成されるだけであり、信じられたサーバを使用します。 多くの場合、信じられたサーバをユーザのISPで提供して、DHCPかPPPオプションでクライアントに広告を出します。 この信頼関係(サーババグ、うまくいっているサーバ不法侵入などを通した)の偶然の裏切り以外に、サーバ自体は、ユーザが予想することでない答えを返すために構成されるかもしれません(ユーザを助けるか、またはISPと第三者との事業提携を促進などなどのある他の目標を促進する正直な試みでか否かに関係なく)。

Faltstrom & Mealling        Standards Track                    [Page 13]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[13ページ]RFC3761を荒びきにすること。

   Denial of Service
      As with any network service (or, indeed, almost any service of any
      kind in any domain of discourse), DNS is vulnerable to denial of
      service attacks.  DNS servers are also at risk of being used as
      denial of service amplifiers, since DNS response packets tend to
      be significantly longer than DNS query packets.

どんなネットワーク・サービス(本当に会話のどんなドメインでのどんな種類のほとんどどんなサービス)があるサービス妨害As、DNSはサービス不能攻撃に被害を受け易いです。 DNSサーバはまた、サービスアンプの否定として危険な状態に使用されるものです、DNS応答パケットが、DNS質問パケットよりかなり長い傾向があるので。

   Authenticated Denial of Domain Names
      The existence of RR types whose absence causes an action other
      than immediate failure (such as missing MX and SRV RRs, which fail
      over to A RRs) constitutes a real threat.  In the specific case of
      ENUM, even the immediate failure of a missing RR can be considered
      a problem as a method for changing call routing policy.

不在が即座の失敗(MXとSRV RRsがいなくて寂しいA RRsへのどのフェイルオーバーなどの)以外の動作を引き起こすRRの存在がタイプするDomain Namesの認証されたDenialは本当の脅威を構成します。 ENUMの特定の場合では、呼び出しルーティング方針を変えるためのメソッドとしての問題であるとなくなったRRの即座の失敗をさえ考えることができます。

   Because of these threats, a deployed ENUM service SHOULD include
   mechanisms which ameliorate these threats.  Most of these threats can
   be solved by verifying the authenticity of the data via mechanisms
   such as DNSSEC [8] once it is deployed.  Others, such and Denial Of
   Service attacks, cannot be solved by data authentication.  It is
   important to remember that these threats include not only the NAPTR
   lookups themselves, but also the various records needed for the
   services to be useful (for example NS, MX, SRV and A records).

脅威、これらによる配布しているENUMサービスSHOULDはこれらの脅威を改善するメカニズムを含んでいます。 [8] それがいったん配布されるとDNSSECなどのメカニズムでデータの信憑性について確かめることによって、これらの脅威の大部分を解決できます。 データ認証で他のもの(そのようなものとDenial Of Service攻撃)を解決できません。 これらの脅威がNAPTRルックアップ自体だけではなく、サービスが役に立つのに必要である様々な記録(例えば、NS、MX、SRV、およびA記録)も含んでいるのを覚えているのは重要です。

   Even if DNSSEC is deployed, a service that uses ENUM for address
   translation should not blindly trust that the peer is the intended
   party as all kind of attacks against DNS can not be protected against
   with DNSSEC.  A service should always authenticate the peers as part
   of the setup process for the service itself and never blindly trust
   any kind of addressing mechanism.

DNSSECが配布されても、アドレス変換にENUMを使用するサービスは、同輩がDNSSECと共にDNSに対するすべての種類の攻撃から守ることができないので通話相手であると盲目的に信じるべきではありません。 サービスは、サービス自体のためにセットアッププロセスの一部としていつも同輩を認証して、盲目的にどんな種類のアドレシングメカニズムも決して信じるべきではありません。

   Finally, as an ENUM service will be implementing some type of
   security mechanism, software which implements ENUM MUST be prepared
   to receive DNSSEC and other standardized DNS security responses,
   including large responses, EDNS0 signaling, unknown RRs, etc.

ENUMサービスがDNSSECと大きい応答を含む他の標準化されたDNSセキュリティ応答を受け取るために最終的にタイプのセキュリティー対策、準備されていて、ENUM MUSTを実装するソフトウェアを実装することであるので、EDNS0シグナリング、RRsですなど未知の。

6.2.  Caching Security

6.2. セキュリティをキャッシュします。

   The caching in DNS can make the propagation time for a change take
   the same amount of time as the time to live for the NAPTR records in
   the zone that is changed.  The use of this in an environment where
   IP-addresses are for hire (for example, when using DHCP [9]) must
   therefore be done very carefully.

DNSでのキャッシュで、伝播時間は珍しく変えられるゾーンでNAPTR記録を生きがいとする時間と同じ時間がかかることができます。 IP-アドレスは賃貸のためのものです。環境におけるこれの使用、どこ、(例えば、したがって、DHCPを使用するとき、非常に慎重に[9])をしなければならないか。

6.3.  Call Routing Security

6.3. セキュリティにルート設定に電話をしてください。

   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,

呼び出しルーティングと数/名前翻訳、通訳のサービスの複数のプロバイダーがある多くの国(そして、他の付番環境)があります。 これらの領域、ユーザを可能にするどんなシステムでも

Faltstrom & Mealling        Standards Track                    [Page 14]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[14ページ]RFC3761を荒びきにすること。

   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

または、ユーザのための推定のエージェント、ルーティングか供給者情報を変えるのは実際に権限がない(そして正統の変更要求の否定のためのいくつかの場合で)変化のために動機を与えるかもしれません。 そのような環境はそれらの識別と認証のための変化を要求する適切なメカニズムとそれらの変化の承認のために設計されるべきです。

6.4.  URI Resolution Security

6.4. URI解決セキュリティ

   A large amount of Security Issues have to do with the resolution
   process itself, and use of the URIs produced by the DDDS mechanism.
   Those have to be specified in the registration of the Enumservice
   used, as specified in Section 3.1.3.

多量のSecurity Issuesは解決プロセス自体と関係があります、そして、URIの使用はDDDSメカニズムによって生産されました。 それらはセクション3.1.3で指定されるように使用されるEnumserviceの登録で指定されなければなりません。

7.  Acknowledgements

7. 承認

   Support and ideas leading to RFC 2916 have come from people at
   Ericsson, Bjorn Larsson and the group which implemented this scheme
   in their lab to see that it worked.  Input has also arrived from
   ITU-T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and
   Enumservice Definition), the ENUM working group in the IETF, John
   Klensin and Leif Sunnegardh.

RFC2916に通じるサポートと考えが人々からそれが働いたことを確認するために彼らの研究室でこの体系を実装したエリクソン、ビヨン・ラーソン、およびグループで来ました。 また、入力はITU-T SG2、Workingパーティ1/2(付番、ルート設定、Global Mobility、およびEnumservice Definition)、IETF、ジョンKlensin、およびリーフSunnegardhのENUMワーキンググループから到着しました。

   This update of RFC 2916 is created with specific input from: Randy
   Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim
   Stralmark, Robert Walter and James Yu.

RFC2916のこのアップデートは特定の入力で以下から作成されます。 ランディ・ブッシュ、デヴィッド・コンラッド、リチャード・ヒル、ジョン・ピーターソン、ジム・リード、Joakim Stralmark、ロバート・ウォルター、およびジェームス・ユー。

8.  Changes since RFC 2916

8. RFC2916以来の変化

   Part from clarifications in the text in this document, the major
   changes are two:

テキストにおける明確化と本書では別れてください、そして、大きな変化は2です:

   The document uses an explicit DDDS algorithm, and not only NAPTR
   resource records in an "ad-hoc" mode.  In reality this doesn't imply
   any changes in deployed base of applications, as the algorithm used
   for ENUM resolution is exactly the same.

ドキュメントはNAPTRリソース記録だけではなく、「臨時」のモードによる明白なDDDSアルゴリズムを使用します。 ほんとうは、これはアプリケーションの配布しているベースにおける少しの変化も含意しません、ENUM解決に使用されるアルゴリズムがまさに同じであるときに。

   The format of the service field has changed.  The old format was of
   the form "example+E2U", while the new format is "E2U+example".
   Reason for this change have to with the added subtypes in the
   enumservice, the ability to support more than one enumservice per
   NAPTR RR, and a general agreement in the IETF that the main selector
   between different NAPTR with the same owner (E2U in this case) should
   be first.

サービス分野の形式は変化しました。 古い方式はフォーム「例+E2U」のものでしたが、新しい形式は「Eの2U+例」です。 この変化の理由は中に加えられた血液型亜型があるenumserviceにそうしました、最初に1NAPTR RRあたり1enumservice、およびIETFの同じ所有者(この場合、E2U)がいる異なったNAPTRの間のメインセレクタがそうであるべきである一般協定をサポートする能力。

Faltstrom & Mealling        Standards Track                    [Page 15]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[15ページ]RFC3761を荒びきにすること。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

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

   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Four: The Uniform Resource Identifiers (URI) Resolution
        Application", RFC 3404, October 2002.

[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、2002年10月。

   [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]  ITU-T, "The International Public Telecommunication Number Plan",
        Recommendation E.164, May 1997.

[5] ITU-T(「国際公共の電気通信数のプラン」、推薦E.164)は1997がそうするかもしれません。

   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

[6] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。

   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Two: The Algorithm", RFC 3402, October 2002.

[7] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。

9.2.  Informative References

9.2. 有益な参照

   [8]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

[8] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。

   [9]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

[9]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。

   [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
        System", Work in Progress, April 2004.

[10] 「ドメインネームシステムの脅威分析」というアトキンス、D.、およびR.Austeinは進歩、2004年4月に働いています。

Faltstrom & Mealling        Standards Track                    [Page 16]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[16ページ]RFC3761を荒びきにすること。

10.  Authors' Addresses

10. 作者のアドレス

   Patrik Faltstrom
   Cisco Systems Inc
   Ledasa
   273 71 Lovestad
   Sweden

パトリク・FaltstromシスコシステムズInc Ledasa273 71Lovestadスウェーデン

   EMail: paf@cisco.com
   URI:   http://www.cisco.com

メール: paf@cisco.com ユリ: http://www.cisco.com

   Michael Mealling
   VeriSign
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル

   Email: michael@verisignlabs.com
   URI:   http://www.verisignlabs.com

メール: michael@verisignlabs.com ユリ: http://www.verisignlabs.com

Faltstrom & Mealling        Standards Track                    [Page 17]

RFC 3761                          ENUM                        April 2004

FaltstromとENUM2004年4月に標準化過程[17ページ]RFC3761を荒びきにすること。

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機能のための基金は現在、インターネット協会によって提供されます。

Faltstrom & Mealling        Standards Track                    [Page 18]

Faltstromと標準化過程を荒びきにすること。[18ページ]