Network Working Group L. Conroy
Request for Comments: 5483 RMRL
Category: Informational K. Fujiwara
JPRS
March 2009
ENUM Implementation Issues and Experiences
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents.
この文書では、ENUMプロトコルおよび他のユーザーによって作成されたENUMデータの経験に基づいてシステムを実装して経験をキャプチャします。このように、それはENUMとダイナミックな委譲発見システムの基準を明確にしています。その目的は、ENUMプロトコルを指定するドキュメントのセットを解釈する際にどのような「そこ」で、潜在的な落とし穴の両方を報告することで他の人を助けることです。これは、基準を改訂しませんが、それらの文書の将来の改訂に技術的な入力を提供することを意図しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Goal ..............................................3
1.2. Terminology ................................................3
2. Character Sets and ENUM .........................................4
2.1. Character Sets - Non-ASCII Considered Harmful ..............4
2.1.1. Non-ASCII in the Regular Expression Field ...........5
2.1.2. Non-ASCII Support - Conclusions .....................6
2.2. Case Sensitivity ...........................................7
2.3. Regexp Field Delimiter .....................................7
2.4. Regexp Meta-Character Issue ................................8
3. Unsupported NAPTRs ..............................................8
3.1. Non-Compliant Client Behaviour .............................9
4. ENUM NAPTR Processing ..........................................10
4.1. Common Non-Compliant Client Behaviour .....................11
4.1.1. Example ............................................11
4.2. Order/Priority Values - Processing Sequence ...............12
4.3. Use of Order and Preference Fields ........................13
4.4. NAPTRs with Identical ORDER/PRIORITY Values ...............14
4.4.1. Compound NAPTRs and Implicit
ORDER/REFERENCE Values .............................14
4.5. Processing Order Value across Domains .....................15
5. Non-Terminal NAPTR Processing ..................................16
5.1. Non-Terminal NAPTRs - Necessity ...........................16
5.2. Non-Terminal NAPTRs - Considerations ......................17
5.2.1. Non-Terminal NAPTRs - General ......................17
5.2.2. Non-Terminal NAPTRs - Loop Detection and Response ..17
5.2.3. Field Content in Non-Terminal NAPTRs ...............17
6. Backwards Compatibility ........................................20
6.1. Services Field Syntax .....................................20
7. Collected Implications for ENUM Provisioning ...................21
8. Collected Implications for ENUM Clients ........................23
8.1. Non-Terminal NAPTR Processing .............................25
9. Security Considerations ........................................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................29
The goal of this document is to clarify the ENUM and Dynamic Delegation Discovery System (DDDS) standards. It does not itself revise ENUM or DDDS standards but is intended to provide technical input to future revisions of those documents. It also serves to advise implementers on the pitfalls that they may find. It highlights areas where ENUM implementations have differed over interpretation of the standards documents or have outright failed to implement some features as specified.
このドキュメントの目標は、ENUMとダイナミックな委譲発見システム（DDDS）の基準を明確にすることです。それ自体は、ENUMやDDDS基準を改訂しませんが、それらの文書の将来の改訂に技術的な入力を提供することを意図しています。それはまた、彼らは見つけることが落とし穴に実装を助言するのに役立ちます。これは、ENUMの実装は規格文書の解釈の上に異なっているか、完全に指定されているいくつかの機能を実装するために失敗している領域を強調しています。
As well as providing clarifications to standards text, this document also mentions potential choices that can be made, in an attempt to help foster interworking between components that use this protocol. The reader is reminded that others may make different choices.
同様の標準テキストに明確化を提供するなど、この文書では、このプロトコルを使用するコンポーネント間の相互動作を育成を支援する試みで、行うことができる潜在的な選択肢に言及しています。読者は、他の人が別の選択を行うことが思い出されます。
The core specifications for the E.164 Number Mapping (ENUM) protocol [RFC3761] and the Dynamic Delegation Discovery System (DDDS) [RFC3403] [RFC3401] [RFC3402] [RFC3404] [RFC3405] are defined elsewhere. Unfortunately, this document cannot provide an overview of the specifications, so the reader is assumed to have read and understood the complete set of ENUM normative documents.
E.164番号マッピング（ENUM）プロトコル[RFC3761]とダイナミックな委譲発見システム（DDDS）[RFC3403]、[RFC3401]、[RFC3402]、[RFC3404]、[RFC3405]のコア仕様は他の場所で定義されています。残念ながら、この文書では、仕様の概要を提供することはできませんので、読者は読んだことがあると仮定し、ENUM規範文書の完全なセットを理解されています。
The Domain Name System (DNS) is ENUM's database. ENUM uses the NAPTR (Naming Authority Pointer) resource record type to store its DDDS rules into DNS domains. ENUM relies on DNS services. Thus, it is also important for ENUM implementers to carry out a thorough analysis of all of the existing DNS standard documents to understand what services are provided to ENUM and what load ENUM provisioning and queries will place on the DNS.
ドメインネームシステム（DNS）は、ENUMのデータベースです。 ENUMは、DNSドメインにそのDDDS規則を格納するNAPTR（権限ポインタを命名）リソースレコードタイプを使用します。 ENUMは、DNSサービスに依存しています。 ENUMの実装は、サービスがDNSに配置しますENUMとどのような負荷ENUMのプロビジョニングおよびクエリに提供されているかを理解するために、既存のDNS標準文書のすべての徹底的な分析を行うためにのためにこのように、それはまた重要です。
A great deal of the rationale for making the choices listed in this document is available to those who explore the standards. The trick of course is in understanding those standards and the subtle implications that are involved in some of their features. In almost all cases, the choices presented here are merely selections from values that are permissible within the standards.
この文書に記載されている選択肢を作るための理論的根拠の多大な基準を探求する人に提供されています。当然のトリックは、これらの基準とそれらの機能のいくつかに関与している微妙な意味合いを理解することです。ほとんどの場合、ここで紹介する選択肢は、単に規格内で許容される値から選択されています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
[RFC3403] and [RFC3761] specify respectively that NAPTR resource records and ENUM support Unicode using the UTF-8 encoding defined in [RFC3629]. This raises an issue when implementations use "single byte" string-processing routines. If there are multi-byte characters within an ENUM NAPTR, incorrect processing may well result from these UTF-8-unaware systems.
[RFC3403]及び[RFC3761]、[RFC3629]で定義されたUTF-8エンコーディングを使用して、それぞれ、そのNAPTRリソースレコードとENUMサポートUnicodeを指定します。実装は、「単一バイト」文字列処理ルーチンを使用するとき、これは問題を提起します。 ENUM NAPTR内のマルチバイト文字がある場合、不正な処理は同様にこれらのUTF-8非対応のシステムに起因する可能性があります。
The UTF-8 encoding has a US-ASCII equivalent range, so that all characters in US-ASCII [ASCII] from 0x00 to 0x7F hexadecimal have an identity map to the UTF-8 encoding; the encodings are the same. In UTF-8, characters with Unicode code points above this range will be encoded using more than one byte, all of which will be in the range 0x80 to 0xFF hexadecimal. Thus, it is important to consider the different fields of a NAPTR and whether or not multi-byte characters can or should appear in them.
US-ASCII [ASCII]は0x00から0x7Fの16進のすべての文字がUTF-8エンコーディングにアイデンティティ・マップを有するようにUTF-8エンコーディングは、US-ASCII同等の範囲を有します。エンコーディングは同じです。 UTF-8で、この範囲を超えるUnicodeコードポイントを持つ文字が0xFFの16進数の範囲は0x80であろうすべてが複数のバイトを使用してエンコードされます。したがって、NAPTRの異なるフィールドを考慮することが重要であるとか、マルチバイト文字は、またはそれらに表示されますすることができます。
In addition, characters in the non-printable portion of US-ASCII (0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) are "difficult". Although NAPTRs are processed by machine, they may sometimes need to be written in a human-readable form. Specifically, if NAPTR content is shown to an end user so that he or she may choose, it is imperative that the content is human-readable. Thus, it is unwise to use non-printable characters even if they lie within the US-ASCII range; the ENUM client may have good reason to reject NAPTRs that include these characters as they cannot readily be presented to an end user.
また、US-ASCII（0x1Fの16進数の0x00で、プラス0x7Fの16進数）の印刷不可能な部分の文字は、「難しい」です。 NAPTRsは、機械によって処理されているが、それらは時として人間が読める形式で書かれる必要があるかもしれません。彼または彼女が選ぶことができるようにNAPTRコンテンツがエンドユーザーに表示された場合に具体的には、コンテンツは、人間が読み取り可能であることが不可欠です。このように、彼らがUS-ASCIIの範囲内にある場合でもない文字を使用するのは賢明ではありません。 ENUMクライアントは、彼らが容易にエンドユーザーに提示することができないとして、これらの文字を含めるNAPTRsを拒否する正当な理由を有することができます。
There are two numeric fields in a NAPTR: the ORDER and PREFERENCE/ PRIORITY fields. As these contain binary values, no risk is involved because string processing should not be applied to them. The string-based fields are the Flags, Services, and Regexp fields. The Replacement field holds an uncompressed domain name, encoded according to the standard DNS mechanism [RFC1034][RFC1035]. The Internationalised Domain Name (IDN) can be supported (as specified in [RFC3490], [RFC3491], and [RFC3492]). Any such IDN MUST be further encoded using Punycode [RFC3492]. As the Replacement field holds a domain name that is not subject to replacement or modification (other than Punycode processing), it is not of concern here.
ORDERと優先/ PRIORITYフィールド：NAPTRで2つの数値のフィールドがあります。これらは、バイナリ値が含まれているとして、文字列処理がそれらに適用されるべきではないので、何のリスクが関与していません。文字列ベースのフィールドはフラグ、サービス、および正規表現フィールドです。置換フィールドは、標準のDNSメカニズム[RFC1034]、[RFC1035]に従って符号化され、圧縮されていないドメイン名を保持します。 （[RFC3490]、[RFC3491]及び[RFC3492]で指定されるように）国際化ドメイン名（IDN）をサポートすることができます。任意のこのようなIDNはさらにピュニコード[RFC3492]を使用して符号化されなければなりません。交換用フィールドは、交換または修正（ピュニコード処理以外）の対象ではありませんドメイン名を保持しているとして、それはここで懸念さではありません。
Taking the string fields in turn, the Flags field contains characters that indicate the disposition of the NAPTR. This may be empty, in which case the NAPTR is "non-terminal", or it may include a flag character as specified in [RFC3761]. These characters all fall into the printable US-ASCII equivalent range, so multi-byte characters cannot occur.
今度は文字列フィールドを取って、Flagsフィールドは、NAPTRの配置を示す文字が含まれています。これは、NAPTRが「非末端」であるか、[RFC3761]で指定されるように、それはフラグ文字を含むことができる場合には、空であってもよいです。これらの文字はすべて、そのマルチバイト文字が発生しないことができ、印刷可能なUS-ASCII同等の範囲に入ります。
The Services field includes the DDDS Application identifier ("E2U") used for ENUM, a set of Enumservice identifiers, any of which may embed the ':' separator character, together with the '+' character used to separate Enumservices from one another and from this DDDS Application identifier. In Section 2.4.2 of [RFC3761], Enumservice identifier tokens are specified as 1*32 ALPHA/DIGIT, so there is no possibility of non-ASCII characters in the Services field.
一緒に互いからEnumservicesを分離するために使用される「+」文字で、区切り文字： 'サービスフィールドはDDDSアプリケーション識別子ENUM、埋め込むことができる任意のそれらのEnumservice識別子のセットのために使用される（「E2U」）を含みますこのDDDSアプリケーション識別子から。 [RFC3761]のセクション2.4.2において、Enumservice識別子トークンは1×32 ALPHA / DIGITとして指定するので、サービスの分野における非ASCII文字の可能性はないれています。
The Regexp field is more complex. It forms a sed-like substitution expression, defined in [RFC3402], and consists of two sub-fields:
正規表現の場はより複雑です。これは[RFC3402]で定義されたsedのような置換表現を形成し、2つのサブフィールドで構成されています。
o a POSIX Extended Regular Expression (ERE) sub-field [IEEE.1003-2.1992]
POSIX拡張正規表現（ERE）サブフィールド[IEEE.1003-2.1992] O
o a replacement (Repl) sub-field [RFC3402].
置換（REPL）サブフィールド[RFC3402] O。
Additionally, [RFC3402] specifies that a flag character may be appended, but the only flag currently defined there (the 'i' case-insensitivity flag) is not appropriate for ENUM -- see Section 2.2.
また、[RFC3402]は、フラグ文字が付加されてもよいことを指定するが、現在が定義されている唯一のフラグ（「I」ケース鈍感フラグ）ENUMには適していない - セクション2.2を参照してください。
The ERE sub-field matches against the "Application Unique String"; for ENUM, this is defined in [RFC3761] to consist of digit characters, with an initial '+' character. It is similar to a global-number-digits production of a tel: URI, as specified in [RFC3966], but with visual-separators removed. In short, it is a telephone number (see [E.164]) in restricted format. All of these characters fall into the US-ASCII equivalent range of UTF-8 encoding, as do the characters significant to the ERE processing.
EREサブフィールドは、「アプリケーション固有文字列」にマッチ。 ENUMのために、これは最初の「+」文字で、数字文字で構成する[RFC3761]で定義されています。 [RFC3966]で指定されるように、URIが、視覚セパレータを除去した：これは、TELのグローバル数桁製造に類似しています。要するに、それは、制限形式の電話番号は、（[E.164]参照します）。 ERE処理に大きな文字がそうであるようにこれらの文字はすべて、UTF-8エンコーディングのUS-ASCII同等の範囲に入ります。
Strictly, the ERE might include other characters. The ERE could include choice elements matching against different items, some of which might not be an ENUM Application Unique String. Those alternative matching elements might conceivably include non-ASCII characters. As an operational issue, it is not reasonable to include such constructs, as ENUM NAPTRs match against telephone numbers.
厳密には、EREは、他の文字が含まれる場合があります。 EREは、ENUMアプリケーション固有文字列ではないかもしれないそのうちのいくつかの異なるアイテム、に対してマッチング選択肢の要素を含めることができます。これらの代替のマッチング要素が考えられる非ASCII文字が含まれる場合があります。運用の問題として、電話番号に対してENUM NAPTRsの試合として、このような構築物を含めることが合理的ではありません。
In the normal situation in which E2U NAPTRs are provisioned in ENUM domains, there will be no multi-byte characters within this sub-field, as the ERE will be intended to match against telephone numbers. ENUM clients must be able to handle NAPTRs that do contain such multi-byte characters (as the standard does not preclude them), but there is no operational reason for these ever being provisioned in ENUM domains. If NAPTRs provisioned in ENUM domains are encountered containing such multi-byte characters, these could reasonably be discarded.
E2UのNAPTRsはENUMドメインにプロビジョニングされている通常の状況では、何のマルチバイト文字は、EREは、電話番号と照合するためのものであろうと、このサブフィールド内ではありません。 ENUMクライアントは、（標準はそれらを妨げないよう）などのマルチバイト文字が含まれていないNAPTRsを処理できなければならないが、これらのこれまでのENUMドメインにプロビジョニングされているための運用理由はありません。 ENUMドメインにプロビジョニングさNAPTRsは、このようなマルチバイト文字を含む発生した場合、これらは合理的に破棄することができます。
The Repl sub-field can include a mixture of explicit text used to construct a URI and characters significant to the substitution expression, as defined in [RFC3403]. Whilst the latter set all fall into the US-ASCII equivalent range of UTF-8 encoding, this might not be the case for all conceivable text used to construct a URI. Presence of multi-byte characters could complicate URI generation and processing routines.
[RFC3403]で定義されるようにREPLサブフィールドは、URIおよび置換発現に有意な文字を構築するために使用される明示的なテキストの混合物を含むことができます。すべてがUTF-8エンコーディングのUS-ASCII同等の範囲に該当し、後者のセット一方で、これはURIを構築するために使用されるすべての考えられるテキストの場合ではないかもしれません。マルチバイト文字の存在は、URIの生成と処理ルーチンを複雑にし得ます。
URI generic syntax is defined in [RFC3986] as a sequence of characters chosen from a limited subset of the repertoire of US-ASCII characters. The current URIs use the standard URI character escaping rules specified in the URI generic syntax, and so any multi-byte character will be pre-processed; they will not occur in the explicit text used to construct a URI within the Repl sub-field.
URIの一般的な構文はUS-ASCII文字のレパートリーの限定されたサブセットから選択された文字列として、[RFC3986]で定義されています。現在のURIはURI一般的な構文で指定された標準URI文字エスケープルールを使用し、そのいずれかのマルチバイト文字は、事前に処理されます。彼らは、REPLのサブフィールド内でURIを構築するために使用される明示的なテキストでは発生しません。
As currently specified, ENUM only permits URIs to be generated in the Regexp field. However, even if this were to be extended in future revisions of the ENUM specification to allow the use of Internationalised Resource Identifiers (IRIs), defined in [RFC3987], further support for non-ASCII characters may be avoided. IRIs are defined as extending the syntax of URIs, and RFC 3987 specifies a mapping from IRIs to URIs. IRI syntax allows characters with multi-byte UTF-8 encoding.
現在指定され、ENUMは正規表現の場で生成されるURIを許可します。しかし、これは国際化リソース識別子（のIRI）の使用を可能にするためにENUM仕様の将来の改訂に拡張することがあったとしても、[RFC3987]で定義され、非ASCII文字のためのさらなる支持を回避することができます。アイリスURIの構文を拡張として定義され、RFC 3987は、URIの虹彩からのマッピングを指定します。 IRIの構文は、マルチバイトUTF-8エンコーディングで文字を可能にします。
Given that this is the only place within an ENUM NAPTR where such multi-byte encodings might reasonably be found, a simple solution is to use the mapping method specified in Section 3.1 of [RFC3987] to convert any IRI into its equivalent URI.
このようなマルチバイトエンコーディングが合理的に見出されるかもしれないENUM NAPTR内の唯一の場所であることを考えると、単純な解決策は、それに相当するURIに任意IRIを変換するために、[RFC3987]のセクション3.1で指定されたマッピング方法を使用することです。
This process consists of two elements; the domain part of an IRI MUST be processed using Punycode if it has a non-ASCII domain name, and the remainder MUST be processed using the extended escaping rules specified in [RFC3987] if it contains characters outside the normal URI repertoire. Using this process, there will be no non-ASCII characters in any part of any URI, even if it has been converted from an IRI that contains such characters.
このプロセスは、2つの要素から構成します。 IRIのドメイン部分は、非ASCIIドメイン名を持っている場合ピュニコードを使用して処理しなければなりません、そして残りは、それが通常のURIレパートリー外の文字が含まれている場合、[RFC3987]で指定された拡張エスケープルールを使用して処理されなければなりません。このプロセスを使用すると、それはそのような文字が含まれているIRIから変換された場合でも、任意のURIのいずれかの部分には非ASCII文字は存在しません。
From the analysis just given, the only place within an ENUM NAPTR where non-ASCII characters might be found is the Regexp field. It is possible to remove any requirement to process characters outside the
ただ与えられた分析から、非ASCII文字が発見される可能性がありますENUM NAPTR内の唯一の場所は、正規表現のフィールドです。外の文字を処理するためにどのような要件を除去することが可能です
US-ASCII equivalent range by adding very few operational restrictions. There is no obvious benefit in providing characters outside this range. Handling multi-byte characters complicates development and operation of client programs, and many existing programs do not include such support.
非常に少数の運用制限を追加することにより、US-ASCII同等の範囲。この範囲外の文字を提供するには明らかな利点がありません。マルチバイト文字を処理するクライアントプログラムの開発と運用を複雑にし、多くの既存のプログラムには、このようなサポートが含まれていません。
As the gain from permitting characters outside the US-ASCII equivalent range is unclear, and the costs of multi-byte character processing are very clear, ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range.
US-ASCIIと同等の範囲外の文字を許可するからゲインが不明である、とマルチバイト文字処理のコストは非常に明確であるため、ENUM NAPTRsは、印刷可能なUS-ASCIIと同等の範囲外の文字を含めないでください。
The only place where NAPTR field content is case sensitive is in any static text in the Repl sub-field of the Regexp field. Everywhere else, case-insensitive processing can be used.
NAPTRフィールドの内容は、大文字と小文字が区別される唯一の場所は、正規表現の場のREPLサブフィールドのすべての静的なテキストです。他のどこでも、大文字と小文字を区別しない処理を使用することができます。
The case-insensitivity flag ('i') could be added at the end of the Regexp field. However, in ENUM, the ERE sub-field operates on a string defined as the '+' character, followed by a sequence of digit characters. This flag is redundant for E2U NAPTRs, as it does not act on the Repl sub-field contents.
ケース非感受性フラグ（I「」）は、正規表現のフィールドの末尾に付加することができます。しかし、ENUMで、EREサブフィールドは、数字の文字列に続く「+」の文字として定義された文字列で動作します。このフラグは、REPLサブフィールドの内容に作用しないように、E2U NAPTRsために冗長です。
Thus, the case-sensitivity flag is inappropriate for ENUM, and SHOULD NOT be provisioned into E2U NAPTRs.
したがって、大文字と小文字の区別フラグは、ENUMには不適切であり、及びE2U NAPTRsにプロビジョニングされるべきではありません。
It is not possible to select a delimiter character that cannot appear in one of the sub-fields. The '!' character is used as a delimiter in all of the examples in [RFC3403] and in [RFC3761]. It is the only character seen in existing zones, and a number of different client implementations are still "hardwired" to expect this character as a delimiter.
サブフィールドのいずれかで表示することはできません区切り文字を選択することはできません。 「！」文字は[RFC3403]及び[RFC3761]の例の全てにおいて、区切り文字として使用されています。これは、既存のゾーンで見られる唯一の文字で、異なるクライアント実装の数はまだ区切り文字としてこの文字を期待するのは「ハードワイヤード」です。
The '!' character will not normally appear in the ERE sub-field. It may appear in the content of some URIs, as it is a valid character (e.g., in http URLs). If it is present in the Regexp field, then that instance MUST be escaped using the standard technique proposed in Section 3.2 of [RFC3402]: a backslash character (U+005C) should be inserted before it in the string. Otherwise, a client may attempt to process this as a standard delimiter and interpret the Regexp field contents differently from the system that provisioned it.
「！」文字は通常、EREのサブフィールドに表示されません。それは（HTTP URLで、例えば、）有効な文字であるように、それは、いくつかのURIのコンテンツに表示される場合があります。文字列で前に挿入されるべきであるバックスラッシュ文字（U + 005C）：これは、正規表現のフィールドに存在する場合、そのインスタンスは、[RFC3402]のセクション3.2で提案されている標準的な技術を使用してエスケープする必要があります。そうでない場合、クライアントは、標準の区切り文字としてこれを処理しようとする場合があり、それをプロビジョニングシステムとは異なる正規表現、フィールドの内容を解釈します。
In ENUM, the ERE sub-field may include a literal character '+', as the Application Unique String on which it operates includes this. However, if it is present, then '+' MUST be escaped using a single backslash character (to produce the sub-string U+005C U+002B), as '+' is a meta-character in POSIX Extended Regular Expression syntax.
ENUMでは、EREのサブフィールドは、それがこれを含んで動作するアプリケーション固有文字列リテラル文字「+」を含むことができます。それが存在する場合は、その後、「+」「+」POSIX拡張正規表現構文でのメタ文字であるとして、（サブ文字列U + 005C U + 002Bを生成するために）単一のバックスラッシュ文字を使用してエスケープしなければなりません。
Not escaping the '+' character produces an invalid ERE, but is a common mistake. Even standards have given incorrect examples; the obsolete [RFC2916] (Section 3.4.3, example 3) has this problem.
「+」文字をエスケープしないと、無効なEREを生成するが、一般的な間違いです。でも、基準は正しくない例を与えています。廃止された[RFC2916]（セクション3.4.3、実施例3）は、この問題があります。
For example, the following NAPTR example is incorrect: * IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\\1@example.net!" .
たとえば、以下のNAPTRの例は間違っています：* NAPTR 100 10 "U" "E2U +一口" "^ + 4655 $一口！（*）：！！\\ 1@example.net" 。
A correct way to write this example is: * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" .
この例を記述するための正しい方法は次のとおりです。* NAPTR 100 10 "U" "E2U +一口" "！（。*）！^ \\ + 4655 $一口：\\ 1@example.net！" 。
Note that when a NAPTR resource record is shown in DNS master file syntax (as in this example above), the backslash itself must be escaped using a second backslash. The DNS on-the-wire packet will have only a single backslash.
NAPTRリソースレコードを（上記の例のように）、DNSマスタファイルの構文に示されている場合、バックスラッシュ自身が第二のバックスラッシュを使用してエスケープされなければならないことに留意されたいです。 DNSオン・ワイヤーパケットは、単一のバックスラッシュを持つことになります。
An ENUM client MAY discard a NAPTR received in response to an ENUM query because:
ENUMクライアントがNAPTRを捨てる可能性があるため、ENUMクエリーに応答して受信されました：
o the NAPTR is syntactically or semantically incorrect,
O NAPTRは、構文的または意味的に間違っています
o the NAPTR has a different (non-empty) DDDS Application identifier from the 'E2U' used in ENUM,
O NAPTRは、ENUMに使用される「E2U」から（空ではない）異なるDDDSアプリケーション識別子を有しています
o the NAPTR's ERE does not match the Application Unique String for this ENUM query,
O NAPTRのEREは、このENUMクエリーのためのアプリケーション固有文字列と一致していません、
o the ENUM client does not recognise any Enumservice held in this NAPTR, or
ENUMクライアントは、このNAPTRで開催された任意のEnumserviceを認識しない、O、または
o this NAPTR (only) contains an Enumservice that is unsupported.
OこのNAPTR（のみ）がサポートされていないEnumserviceが含まれています。
These conditions SHOULD NOT cause the whole ENUM query to terminate, and processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet).
これらの条件は、全体ENUMクエリーは終了しません。また、処理が返されるリソースレコードセットの次のNAPTR（資源レコード集合）を継続する必要があります。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice -- see also Section 4.4.1) and cannot process or cannot recognise one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.
処理できないか、ENUMクライアントは、このEnumserviceを無視して継続することを、その中Enumservicesのいずれかを認識することはできません - ENUMクライアントは、化合物のNAPTRを検出すると（セクション4.4.1を参照してくださいつまり、1つ以上のEnumserviceを含みます）このNAPTRのサービスフィールド内の次のEnumservice、それはEnumservicesのいずれかが含まれて扱うことができない場合にのみ、NAPTRを破棄する。これらの条件は、エラーとみなされるべきではありません。
ENUM uses regular-expression processing when generating URIs from the Regexp field of "terminal" NAPTRs. Just as with all uses of regular expressions, there is a potential for buffer overrun when generating this output. There may be repeated back-reference patterns in a NAPTR's Repl sub-field, and the output these generate may consume a considerable amount of buffer space.
「端末」NAPTRsの正規表現のフィールドからURIを生成する際にENUMは、正規表現処理を使用します。ただ、正規表現のすべての使用と同様に、この出力を生成する際に、バッファオーバーランの可能性があります。そこNAPTRのREPLサブフィールドにおいてバック基準パターンを繰り返してもよいし、これらが生成する出力は、バッファ・スペースのかなりの量を消費することができます。
Even if an ENUM client would normally encounter only NAPTRs with short URIs, it may also receive NAPTRs with repeated back-reference patterns in their Repl sub-fields that could generate strings longer than the client's buffer. Such NAPTRs may have been misconfigured accidentally or by design. The client MUST NOT fail in this case. It SHOULD NOT discard the entire ENUM query, but instead just discard the NAPTR that would otherwise have caused this overrun.
ENUMクライアントは通常、短いURIを持つ唯一のNAPTRsを遭遇しても、それはまた、クライアントのバッファよりも長い文字列を生成することができ、そのREPLサブフィールドで繰り返さ後方参照パターンとNAPTRsを受け取ることができます。このようなNAPTRsは、偶然やデザインによって誤って構成されている可能性があります。クライアントは、この場合には失敗してはなりません。これは、全体のENUMクエリーを破棄し、代わりにちょうどそうでない場合は、このオーバーランを起こしていたNAPTRを破棄すべきではありません。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), then the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred. See Section 5.2.2 for more details.
（非末端NAPTR参照に従うことによって）複数のドメインを横切るENUMクエリーを処理する際に問題が検出された場合、ENUM照会が放棄されるべきではなく、代わりに呼ばれる非末端NAPTR後の次のNAPTRで続けるべき処理します問題が発生していると思われるドメイン。詳細は、5.2.2項を参照してください。
Through monitoring current ENUM clients, a number of non-compliant behaviours have been detected. These behaviours are incorrect, but may be encountered in still-operational client implementations.
現在のENUMクライアントの監視を通じて、非準拠の行動の数が検出されています。これらの行動は間違っていますが、まだ稼動クライアントの実装に遭遇することができます。
ENUM clients have been known to discard NAPTRs in which the Services field holds more than one Enumservice.
ENUMクライアントは、サービスのフィールドが複数のEnumserviceを保持しているNAPTRsを破棄することが知られています。
ENUM clients have also been known to discard NAPTRs with a "non-greedy" ERE sub-field expression (i.e., EREs that are dissimilar to "^.*$").
ENUMクライアントは、「非貪欲な」EREサブフィールド式でNAPTRsを破棄することが知られている（すなわち、に似ていないのERE「^。* $」）。
ENUM clients have been known to discard NAPTRs that do not use '!' as their Regexp delimiter character.
ENUMクライアントは使用しませんNAPTRsを破棄することが知られています「！」その正規表現区切り文字として。
ENUM clients have been known to discard NAPTRs in which the delimiter is NOT the last character in the Regexp field.
ENUMクライアントは、区切り文字が正規表現、フィールドの最後の文字されていないNAPTRsを破棄することが知られています。
ENUM clients have been known to discard NAPTRs with an empty Flags field (i.e., "non-terminal" NAPTRs).
ENUMクライアントは、空のFlagsフィールド（すなわち、「非末端」NAPTRs）とNAPTRsを破棄することが知られています。
ENUM clients have been known to ignore the ORDER field value entirely, sorting the NAPTRs in an RRSet based solely on the PREFERENCE/PRIORITY field values.
ENUMクライアントは、優先/ PRIORITYフィールドの値のみに基づいて資源レコード集合でNAPTRsを並べ替え、完全にORDERフィールドの値を無視することが知られています。
Finally, many ENUM clients have been known to discard a NAPTR where they have local knowledge that the URI that would be generated by processing the NAPTR is unusable. This behaviour is, strictly speaking, non-compliant, but might be considered reasonable (see Section 4.1).
最後に、多くのENUMクライアントは、NAPTRが使用できない処理することにより生成されるURIという地元の知識を持っているNAPTRを破棄することが知られています。この動作は、厳密には非対応、話しているが、（セクション4.1を参照）合理的と考えられるかもしれません。
ENUM is a DDDS Application, and the way in which NAPTRs in an RRSet are processed reflects this. The details are described in Section 3.3 of [RFC3402]. The client is expected to sort the records it receives into a sequence and then process those records in that sequence. The sequence reflects the ORDER and PREFERENCE/PRIORITY field values in each of the NAPTRs.
ENUMはDDDSアプリケーションであり、資源レコード集合でNAPTRsが処理される方法は、これを反映しています。詳細は[RFC3402]のセクション3.3に記載されています。クライアントは、シーケンスには、受信したレコードをソートし、その順序でこれらのレコードを処理することが期待されます。配列はNAPTRsのそれぞれにおけるORDER嗜好/ PRIORITYフィールド値を反映します。
The ORDER field value is the major, or most significant, sort term and the PREFERENCE/PRIORITY field value is the minor, or least significant, sort term. The combination of ORDER and PREFERENCE/ PRIORITY field values indicates the sequence chosen by the publisher of this data, and NAPTRs will be considered in this sequence.
ORDERフィールドの値は、主要な、または最も重要である、用語を並べ替えると優先/ PRIORITYフィールド値は、マイナー、または最下位で、用語を並べ替えます。 ORDERと優先/ PRIORITYフィールド値の組み合わせは、このデータの発行者によって選択された配列を示し、NAPTRsは、この順序で考慮されます。
Once the NAPTRs are sorted into sequence, further processing is done to determine if each of the NAPTRs is appropriate for this ENUM evaluation. This involves looking at the Flags field. If the Flags field is empty, this is a "non-terminal" NAPTR and is processed as described in Section 5.
NAPTRsがシーケンスにソートされると、さらなる処理がNAPTRsの各々は、この列挙評価に適しているかどうかを決定するために行われます。これは、フラグフィールドを見て必要とします。 Flagsフィールドが空の場合、これは「非末端」NAPTRで、第5節で説明したように処理されます。
If the "u" Flag is present (and so the NAPTR is a "terminal" rule that generates a URI), the Services field is checked to ensure that this NAPTR is intended for ENUM (i.e., that this NAPTR includes the "E2U" DDDS Application identifier in the Services field). The ERE in the Regexp field is checked and must match the Application Unique String (AUS) for this ENUM evaluation (the queried telephone number). Unless each of these checks succeeds, the NAPTR is discarded and the next in sequence is processed.
「u」はフラグが存在している（ので、NAPTRがURIを生成し、「ターミナル」のルールである）場合は、サービスフィールドは、このNAPTRは「E2U」が含まれていること、すなわち（このNAPTRはENUMのために意図されていることを確認するためにチェックされていますサービス分野におけるDDDSアプリケーション識別子）。正規表現の分野でのEREがチェックされ、このENUM評価のためのアプリケーション固有文字列（AUS）（照会電話番号）と一致する必要があります。これらのチェックのそれぞれが成功しない限り、NAPTRは破棄され、シーケンスの次に処理されます。
During this processing, clients will also consider the Enumservices within the Services field. Enumservices indicate the kind of interaction that can be achieved through use of the URI this NAPTR generates. If there is local knowledge that a NAPTR includes only an Enumservice that is either not supported or not recognised, then this
この処理中に、クライアントは、サービスフィールド内Enumservicesを検討します。 Enumservicesは、このNAPTRが生成するURIを使用して達成することができます相互作用の種類を示しています。 NAPTRは、この、サポートされていないか、認識されていないかだけEnumserviceが含まれていることを地元の知識があれば
NAPTR can be discarded and the next in sequence will be processed. Thus, for a system that has support only for SIP interactions, if it receives an RRSet in which the "best" NAPTR indicates the H323 Enumservice, then that client could reasonably discard that NAPTR and go on to the next in sequence.
NAPTRは破棄することができ、シーケンスの次が処理されます。したがって、それは「最高」NAPTRはH323 Enumserviceを示している資源レコード集合を受信した場合のみ、SIPの相互作用をサポートしているシステムのために、そのクライアントは、合理的NAPTRことを破棄可能性があり、シーケンス内の次に進みます。
The processing of ORDER and PREFERENCE/PRIORITY fields has been a significant source of confusion, and many ENUM clients do not implement the processing exactly as specified.
ORDERおよびPREFERENCE / PRIORITYフィールドの処理が混乱の大きな原因となっている、と指定されている多くのENUMクライアントは正確に処理を実装していません。
In particular, many ENUM clients use local prior knowledge about URIs during ENUM processing. If a client has prior knowledge that a particular URI will not result in an acceptable outcome, it might discard that NAPTR and consider the next one in the sequence. Examples of such local prior knowledge include: the URI does not resolve, authentication has been recently rejected, or user policies mark a particular URI as unacceptable (the URI could be a "premium rate" telephone number that would be charged at an unacceptable rate).
特に、多くのENUMクライアントは、ENUM処理中にURIに関する地元の事前知識を使用しています。クライアントが特定のURIが許容できる結果にはなりませんという事前知識を持っている場合は、そのNAPTRを破棄し、シーケンス内の次のいずれかを検討するかもしれません。こうした地元の事前知識としては、例えば、URIが解決されない、認証が最近拒否された、またはユーザーポリシーが受け入れられないように、特定のURIをマーク（URIは、「保険料率」容認できないレートで課金されます電話番号かもしれません） 。
Strictly speaking, this behaviour is non-compliant if the next NAPTR record has a different ORDER value. The ENUM algorithm (Section 3.3 of [RFC3402] and Section 4.1 of [RFC3403]) states that once a match has been found for the Application Unique String (AUS), and the service description satisfies the client's requirements, NAPTR records with larger ORDER values must not be considered (but other NAPTR records with the same ORDER value can still be considered).
次のNAPTRレコードが異なるORDER値を持っている場合は厳密に言えば、この動作は非対応です。 ENUMアルゴリズム（[RFC3402]のセクション3.3と[RFC3403]のセクション4.1）は、一度マッチがアプリケーション固有文字列（AUS）のために発見された、およびサービスの説明は、より大きなORDER値とクライアントの要件、NAPTRレコードを満たしていることを述べて考慮されてはなりません（ただし、同じORDER値を持つ他のNAPTRレコードはまだ考えることができます）。
However, embedding local knowledge about the URI within the ENUM evaluation process is almost universal in systems employing ENUM. Also, since the difference between ORDER and PRIORITY/PREFERENCE has been unclear, NAPTR records have been provisioned in ways that would make strictly compliant systems unusable in practice. Given that such systems are intended to provide communications, this non-compliant, "embedded decision" behaviour is understandable.
しかしながら、ENUM評価プロセス内URIに関するローカル知識を埋め込むことENUMを使用するシステムではほぼ普遍的です。 ORDERおよびPRIORITY / PREFERENCEの違いは不明であったので、また、NAPTRレコードは、実際には、厳密に準拠したシステムが使用できなくなるだろうな方法でプロビジョニングされています。このようなシステムは、通信を提供することを意図していることを考えると、この非対応、「埋め込まれた決定」動作が理解できます。
It is proposed that when the ENUM specification is updated, processing of ORDER and PRIORITY/PREFERENCE should be updated based on implementation and deployment experiences described in this document.
ENUMの仕様が更新された場合、ORDERおよびPRIORITY /優先処理が実現し、この文書で説明する展開の経験に基づいて更新することが提案されています。
The example in this section is intended to further understanding about the difference between what [RFC3402] and [RFC3403] specify and what existing ENUM clients do.
このセクションの例では、[RFC3402]と[RFC3403]は指定して、どのような既存のENUMクライアントが何をすべきかの違いについて理解を促進するためのものです。
WARNING: The NAPTR records shown in this section are intended to illustrate somewhat unclear corner cases, and are not intended as good examples of how to do ENUM provisioning.
警告：このセクションに示すNAPTRレコードがやや不明瞭なコーナーケースを例示することを意図しており、ENUMのプロビジョニングを行う方法の良い例として意図されていません。
Consider the following RRset, which maps numbers in the UK drama range to one server, and all other numbers to a second server: * 3600 IN NAPTR 1 1 "u" "e2u+sip" "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . * 3600 IN NAPTR 2 1 "u" "e2u+sip" "!^(.*)$!sip:\\1@biloxi.example.com!" .
一つのサーバに英国のドラマの範囲で番号をマッピングし、次のRRセット、および第二のサーバへの他のすべての数字を考えてみます！* 3600をNAPTR 1 1「U」「E2U +一口」」^（\\は+ 441632960. * ！）$では、SIP：\\ 1@atlanta.example.com「！ 。 * NAPTR 2 IN 1 3600 "U" "E2U +一口" "^ $一口！（*）：！\\ 1@biloxi.example.com！" 。
According to the processing specified in [RFC3402] and [RFC3403], the ENUM client is never intended to consider the second rule for e.g., AUS "+441632960123", even if it does not support "sips" URIs, or the atlanta.example.com server cannot be reached, or the user indicates he or she doesn't wish to contact atlanta.example.com. However, existing ENUM implementations are known to do this, and as described above, it can be useful if the alternative is failing to communicate at all.
[RFC3402]と[RFC3403]で指定された処理によると、ENUMクライアントは、例えば、AUSのための二番目のルールを検討する「441632960123」を意図されることはありません、それはサポートしていない場合でもすることのURI、またはatlanta.example「すすります」 .comサーバは到達できない、またはユーザーが彼または彼女がatlanta.example.comに連絡したくないことを示します。しかし、既存のENUM実装は、これを行うことが知られており、そして上記のように代替が全く通信に失敗した場合、それは有用であり得ます。
To prevent a client from considering the second rule for the UK drama range, the example could be rewritten to have more predictable behaviour as follows: * 3600 IN NAPTR 1 1 "u" "e2u+sip" "!^(\\+441632960.*)$!sips:\\1@atlanta.example.com!" . * 3600 IN NAPTR 2 1 "u" "e2u+sip" "!^(\\+[^4].*|\\+4[^4].*|\\+44[^1].*|\\+441[^6].*|\\+4416[^3].*| \\+44163[^2].*|\\+441632[^9].*|\\+4416329[^6].*| \\+44163296[^0].*)$!sip:\\1@biloxi.example.com!" .
イギリスのドラマの範囲のための二番目のルールを考慮からクライアントを防ぐために、例は以下のように、より予測可能な動作を持つように書き直すことができ：* 3600をNAPTR 1 1「U」「E2U +一口」「^（\\は+ 441632960！ 。！*）$では、SIP：\\ 1@atlanta.example.com「！ 。 * 3600 NAPTR、IN 2 1 "U" "E2U +一口"「^（\\ + [^ 4] * |！。\\ + 4 [^ 4] * |。\\ + 44 [^ 1] *。| \\ + 441 [^ 6] * |。\\ + 4416 [^ 3] * |。\\ + 44163 [^ 2] * |。\\ + 441632 [^ 9] * |。\\ + 4416329 [^ 。。！6] * | \\ + 44163296 [^ 0] *）$一口：\\ 1@biloxi.example.com「！ 。
[RFC3761] and [RFC3403] state that the ENUM client MUST sort the NAPTRs using the ORDER field value ("lowest value is first") and SHOULD order the NAPTRs using the PREFERENCE/PRIORITY field value as the minor sort term (again, lowest value first). The NAPTRs in the sorted list must be processed in order. Subsequent NAPTRs with worse ORDER values must only be dealt with once the current ones with a better ORDER value have been processed.
[RFC3761]とENUMクライアントはORDERフィールド値を使用してNAPTRsをソートしなければならない（「最小値が最初である」）とマイナーソート用語（再び、最も低いとしてPREFERENCE / PRIORITYフィールド値を使用してNAPTRsを注文すべきであること、[RFC3403]の状態最初の値）。ソートされたリスト内NAPTRsは順番に処理されなければなりません。さらに悪いORDER値を持つ後続のNAPTRsは、より良いORDER値と現在のものが処理された後に対処する必要があります。
However, as described in the introduction to this section, this stated behaviour is a simplification. Once sorted into a sequence reflecting ORDER and PREFERENCE/PRIORITY values, other fields are also considered during evaluation of retrieved NAPTRs; local knowledge may play a factor in the decision process, once a NAPTR has reached that point in the sequence at which it is considered.
このセクションの冒頭で説明したようにしかし、この記載された動作は単純化です。一度ORDER嗜好/ PRIORITY値を反映する配列にソート、他のフィールドも検索NAPTRsの評価中に考慮されます。 NAPTRは、それが考慮された順序でそのポイントに達すると地元の知識は、意思決定プロセスの要因を果たしている可能性があります。
ENUM clients may also include the end user "in the decision loop", offering the end user the choice from a list of possible NAPTRs. Conceptually this choice is embedded within step 4 of the DDDS algorithm (as described in Section 3.3 of [RFC3402]). Given that the ORDER field value is the major sort term, one would expect a conforming ENUM client to present only those NAPTRs with the currently "best" ORDER field value as choices. When/if all the presented options had been rejected, then the ENUM client might offer those with the "next best" ORDER field value, and so on. As this may be confusing for the end user, some clients simply offer all of the available NAPTRs as options to the end user for his or her selection at once, in the sequence defined by the ORDER and PREFERENCE/PRIORITY fields.
ENUMクライアントも可能NAPTRsのリストからエンドユーザーに選択肢を提供し、「決定ループで、」エンドユーザーを含むことができます。概念的に、この選択は、（[RFC3402]のセクション3.3に記載されているように）DDDSアルゴリズムのステップ4内に埋め込まれています。 ORDERフィールドの値は、主要なソートの用語であることを考えると、1が準拠するENUMクライアントは選択肢として現在「最高」ORDERフィールド値でのみNAPTRsを提示するために期待されます。すべての提示オプションが拒否された場合場合は/、その後、ENUMクライアントはように「次善の」ORDERフィールドの値を有するものを提供し、可能性があります。これは、エンドユーザーのために混乱することができるように、一部のクライアントは単にORDERや好み/ PRIORITYフィールドで定義された順序で一度に彼または彼女の選択のためのエンドユーザーにオプションとして利用可能NAPTRsのすべてを提供します。
In summary, ENUM clients will take into account the Services field value, the Flags field, and the Regexp ERE sub-field, along with the ORDER and PREFERENCE/PRIORITY field values, and may consider local policies or available local knowledge.
要約すると、ENUMクライアントはORDERや好み/ PRIORITYフィールド値とともに、口座にサービスフィールド値、フラグフィールド、および正規表現EREサブフィールドがかかりますし、ローカルポリシーまたは利用可能なローカルな知識を考慮することができます。
The Registrant and the ENUM zone provisioning system he or she uses must be aware of this and SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields alone.
登録者と彼または彼女が使用するENUMゾーンプロビジョニングシステムは、このことを認識する必要があり、単にORDER単独PREFERENCE / PRIORITYフィールドの値を考慮したENUMクライアントに依存しないでください。
Specifically, it is unsafe to assume that an ENUM client will not consider another NAPTR if there is one with a better ORDER value. The instructions in Section 4.1 and Section 8 of [RFC3403] may or may not be followed strictly by different ENUM clients for perfectly justifiable reasons.
具体的には、より良いORDER値を持つものがある場合はENUMクライアントは別のNAPTRを考慮しないであろうと仮定することは危険です。セクション4.1と[RFC3403]の第8章の命令は、または完全に正当な理由のために異なるENUMクライアントによって厳密に続いてもしなくてもよいです。
Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MUST do so in the sequence defined by the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.
ENUMクライアントは、彼または彼女の選択のためのエンドユーザーに可能なURLのリストを提示した場合、それは登録者によって指定された順序と優先/ PRIORITY値によって定義された順序で行う必要があります。
However, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.
しかし、登録者は彼または彼女がサポートしても構わないと思っている連絡先だけ自分のゾーンに配置する必要があります。でも、それらの最悪ORDERや好みに/ PRIORITY値は、エンドユーザによって選択されてもよいです。
NAPTRs in ENUM zones that hold incorrect ORDER values can cause major problems. [RFC3403] highlights that having both ORDER and PREFERENCE/PRIORITY fields is a historical artifact of the NAPTR resource record type. It is reasonable to have a common default value for the ORDER field, relying on the PREFERENCE/PRIORITY field to indicate the preferred sort.
間違ったORDER値を保持するENUMゾーンのNAPTRsは大きな問題を引き起こす可能性があります。 [RFC3403]はORDER嗜好/ PRIORITYフィールドの両方を有するNAPTRリソースレコードタイプの歴史的人工物であることを強調しています。優先の並べ替えを示すために、PREFERENCE / PRIORITYフィールドに頼って、ORDERフィールドの一般的なデフォルト値を持つことが合理的です。
We have noticed a number of ENUM domains with NAPTRs that have identical PREFERENCE/PRIORITY field values and different ORDER values. This may be the result of an ENUM zone provisioning system "bug" or a misunderstanding over the uses of the two fields, or simply a difference of interpretation of the standards.
私たちは、同じPREFERENCE / PRIORITYフィールドの値と異なるORDER値を持つNAPTRsとENUMドメインの数に気づきました。これは、ENUMゾーンプロビジョニングシステム「バグ」または単に二つのフィールド、または標準の解釈の違いの用途を超える誤解の結果である可能性があります。
To clarify, the ORDER field value is the major sort term, and the PREFERENCE/PRIORITY field value is the minor sort term. Thus, one should expect to have a set of NAPTRs in a zone with identical ORDER field values and different PREFERENCE/PRIORITY field values; not the other way around.
明確にするために、ORDERフィールドの値は、主要なソート用語であり、そしてPREFERENCE / PRIORITYフィールド値は、マイナーソート用語です。したがって、一つは同じORDERフィールドの値と異なるPREFERENCE / PRIORITYフィールド値を有するゾーンにNAPTRsのセットを持つことを期待すべきです。その逆ではありません。
To avoid these common interoperability issues, it is recommended that ENUM NAPTRs SHOULD hold a default value in their ORDER field.
これらの一般的な相互運用性の問題を回避するために、ENUM NAPTRsが自分ORDERフィールドにデフォルト値を保持することをお勧めします。
From experience, it has been learned that there are zones that hold discrete NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values. This will lead to indeterminate client behaviour and so SHOULD NOT normally occur.
経験から、同じORDERと同じPREFERENCE / PRIORITYフィールドの値と離散NAPTRsを保持するゾーンがあることを学習されています。これは、不確定なクライアントの動作につながるので、通常は発生しません。
Such a condition indicates that these NAPTRs are truly identical in priority and that there is no preference between the services these NAPTRs offer. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.
このような条件は、これらのNAPTRsが優先で、本当に同一であることを示し、これらNAPTRsが提供するサービスの間には優先順位がないこと。実装者はDNSが特定の順序で資源レコード集合内NAPTRsをお届けすることを仮定するべきではありません。
Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical in priority and there is no preference between them.
意図は、これらのNAPTRsが優先で、真に同一であり、それらの間には優先順位がないことである場合を除き、同一の順序と同じ嗜好に複数のNAPTRs / PRIORITYフィールドの値は資源レコード集合にプロビジョニングされるべきではありません。
Some ENUM client implementations have considered this case to be an error and have rejected such duplicates entirely. Others have attempted to further randomise the order in which such duplicates are processed. Thus, use of such duplicate NAPTRs is unwise, as client implementations exist that will behave in different ways.
いくつかのENUMクライアントの実装がエラーになるこのケースを検討していると、完全な重複を拒否してきました。その他には、さらに、このような重複が処理される順序をランダム化することを試みてきました。クライアントの実装は、それがさまざまな方法で動作しますが存在するようしたがって、そのような重複NAPTRsの使用は、賢明ではありません。
With [RFC3761], it is possible to have more than one Enumservice associated with a single NAPTR. These Enumservices share the same Regexp field and so generate the same URI. Such a "compound" NAPTR could well be used to indicate a mobile phone that supports both "voice:tel" and "sms:tel" Enumservices. The Services field in that case would be "E2U+voice:tel+sms:tel".
[RFC3761]によれば、単一のNAPTRに関連付けられた複数のEnumserviceを有することが可能です。これらのEnumservicesは同じ正規表現、フィールドを共有するので、同じURIを生成します。 「：TEL声」と「SMS：TEL」Enumservicesこのような「化合物」NAPTRはよく両方をサポートして携帯電話を示すために使用することができます。その場合のサービスフィールドは「：TEL + SMS：TEL E2U +音声」になります。
A compound NAPTR can be treated as a set of NAPTRs that each hold a single Enumservice. These reconstructed NAPTRs share the same ORDER and PREFERENCE/PRIORITY field values but should be treated as if each had a logically different priority. In this case, the reconstructed NAPTR holding the leftmost Enumservice within the compound NAPTR has the best priority, and the reconstructed NAPTR holding the rightmost Enumservice has the worst priority in this set.
化合物NAPTRは、それぞれが単一Enumserviceを保持NAPTRsの集合として扱うことができます。これらの再構築NAPTRsは同じORDERや好み/ PRIORITYフィールド値を共有するが、それぞれが論理的に異なる優先順位を持っていたかのように扱われるべきです。この場合、化合物のNAPTR内左端Enumserviceを保持して再構築されたNAPTRは最高の優先順位を持っており、右端のEnumserviceを保持して再構築されたNAPTRは、このセットの中で最悪の優先権を持っています。
To avoid indeterminate behaviour, it is recommended that ENUM clients SHOULD process the Enumservices within a compound NAPTR in a left-to-right sequence. ENUM provisioning systems SHOULD assume that such a processing order will be used and provision the Enumservices within a compound NAPTR accordingly.
不確定な動作を回避するためには、ENUMクライアントは、左から右への順序で複合NAPTR内Enumservicesを処理しなければならないことをお勧めします。 ENUMプロビジョニングシステムは、このような処理順序はそれに応じて、化合物NAPTR内Enumservicesを使用し、提供されると仮定すべきです。
Using a different ORDER field value in different domains is unimportant for most queries. However, DDDS includes a mechanism for continuing a search for NAPTRs in another domain by including a reference to that other domain in a "non-terminal" NAPTR. The treatment of non-terminal NAPTRs is covered in the next section. If they are supported, then the way that ORDER and PREFERENCE/PRIORITY field values are processed is affected.
異なるドメインで異なるORDERフィールドの値を使用すると、ほとんどのクエリのために重要ではありません。しかし、DDDSは「非末端」NAPTRにおける他のドメインへの参照を含めることによって、別のドメインのNAPTRsの探索を継続するための機構を含みます。非終端NAPTRsの処理は、次のセクションで覆われています。彼らはサポートされている場合は、ORDERおよびPREFERENCE / PRIORITYフィールドの値が処理されることを、その後の方法は、影響を受けています。
Two main questions remain from the specifications of DDDS and [RFC3761]:
二つの主な質問はDDDSと[RFC3761]の仕様から残っています：
o If there is a different (lower) ORDER field value in a domain referred to by a non-terminal NAPTR, then does this mean that the ENUM client discards any remaining NAPTRs in the referring RRSet?
非終端NAPTRによって参照領域中の異なる（低い）ORDERフィールド値が存在する場合、O、これはENUMクライアントが参照する資源レコード集合に残っNAPTRsを破棄することを意味しますか？
o Conversely, if the domain referred to by a non-terminal NAPTR contains entries that only have a higher ORDER field value, then does the ENUM client ignore those NAPTRs in the referenced domain?
唯一のより高次のフィールド値を持つエントリが含まれているO逆に、ドメインは、非ターミナルNAPTRで参照される場合は、ENUMクライアントは、参照されたドメインでこれらのNAPTRsを無視するのですか？
Whilst one interpretation of [RFC3761] is that the answer to both questions is "yes", this is not the way that those examples of non-terminal NAPTRs that do exist (and those ENUM clients that support them) seem to be designed.
[RFC3761]の1つの解釈しながら、両方の質問への答えは「はい」、これが存在しない非末端NAPTRsのこれらの例（およびそれらをサポートしているENUMクライアント）が設計しているように見えるという方法ではありませんということです。
In keeping with the interpretation made so far, ENUM implementations MUST consider the ORDER and PREFERENCE/PRIORITY values only within the context of the domain currently being processed in an ENUM query. These values MUST be discarded when processing other RRSets in the query.
これまでの解釈を踏まえて、ENUMの実装は現在、ENUMクエリーに処理されているドメインのコンテキスト内でORDERと優先/ PRIORITY値を考慮する必要があります。クエリ内の他のRRsetを処理するときにこれらの値は捨てなければなりません。
Consider an ENUM RRSet that contains a non-terminal NAPTR record. This non-terminal NAPTR holds, as its target, another domain that has a set of NAPTRs. In effect, this is similar to the non-terminal NAPTR being replaced by the NAPTRs contained in the domain to which it points.
非ターミナルNAPTRレコードを含むENUM資源レコード集合を考えてみましょう。この非終端NAPTRは、そのターゲットとして、NAPTRsのセットを持っている別のドメインを保持しています。実際には、これは、それがポイントするドメインに含まNAPTRsにより置換された非末端NAPTRと同様です。
It is possible to have a non-terminal NAPTR in a domain that is, itself, pointed to by another non-terminal NAPTR. Thus, a set of domains forms a "chain", and the list of NAPTRs to be considered is the set of all NAPTRs contained in all of the domains in that chain.
別の非ターミナルNAPTRで指さ、自身をあるドメイン内の非ターミナルNAPTRを持つことが可能です。したがって、ドメインの集合は、「チェーン」を形成し、考慮すべきNAPTRsのリストは、チェーン内のすべてのドメインに含まれるすべてのNAPTRsの集合です。
For an ENUM management system to support non-terminal NAPTRs, it is necessary for it to be able to analyse, validate, and (where needed) correct not only the NAPTRs in its current ENUM domain but also those referenced by non-terminal NAPTRs in other domains. If the domains pointed to have non-terminal NAPTRs of their own, the management system will have to check each of the referenced domains in turn, as their contents form part of the result of a query on the "main" ENUM domain. The domain content in the referenced domains may well not be under the control of the ENUM management system, and so it may not be possible to correct any errors in those RRSets. This is both complex and prone to error in the management system design, and any reported errors in validation may well be non-intuitive for users.
ENUM管理システムは非末端NAPTRsをサポートするために、分析検証することができる、及び（必要な場合）、その現在のENUMドメインに正しくないだけNAPTRsなく、それらは、非端末NAPTRsによって参照することが必要です他のドメイン。ドメインは、独自の非ターミナルNAPTRsを持つように指摘した場合、管理システムは、その内容が「メイン」ENUMドメインに対するクエリの結果の一部を形成するように、順番に参照されたドメインのそれぞれをチェックする必要があります。参照されたドメインのドメイン含有量は、十分ENUM管理システムの制御下ではないかもしれない、そしてこれらの資源レコード集合内の任意のエラーを修正することは可能ではないかもしれません。これは、管理システムの設計におけるエラーに複雑となりやすいの両方で、検証のいずれかの報告されたエラーはよくユーザーのための非直感的かもしれません。
For an ENUM client, supporting non-terminal NAPTRs can also be difficult. Processing non-terminal NAPTRs causes a set of sequential DNS queries that can take an indeterminate time, and requires extra resources and complexity to handle fault conditions like non-terminal loops. The indeterminacy of response time makes ENUM-supported Telephony Applications difficult (such as in an "ENUM-aware" Private Branch Exchange (PBX)), whilst the added complexity and resources needed makes support problematic in embedded devices like "ENUM-aware" mobile phones.
ENUMクライアントの場合、非ターミナルNAPTRsを支援することも困難な場合があります。非ターミナルNAPTRsの処理は、不確定な時間がかかることがシーケンシャルDNSクエリのセットを引き起こし、非ターミナルループなどの障害条件を処理するために、余分なリソースと複雑さを必要とします。必要に応じて追加の複雑さとリソースは、「ENUM対応の」モバイルなどの組み込み機器でのサポートは、問題のあるものにする一方で、応答時間の不確定性は、（例えば、「ENUM対応」構内交換機（PBX）のように）ENUM対応のテレフォニーアプリケーションを困難に電話。
Given that, in principle, a non-terminal NAPTR can be replaced by the NAPTRs in the domain to which it points, support of non-terminal NAPTRs is not needed and non-terminal NAPTRs may not be useful. Furthermore, some existing ENUM clients do not support non-terminal NAPTRs and ignore them if received.
ことを考えると、原則的に、非ターミナルNAPTRは、それが指しているドメインでNAPTRsに置き換えることができ、非末端NAPTRsのサポートが必要とされていないと非終端NAPTRsは役に立たないかもしれません。さらに、いくつかの既存のENUMクライアントが非ターミナルNAPTRsをサポートし、受信した場合はそれらを無視しないでください。
To avoid interoperability problems, some kind of acceptable advice is needed on non-terminal NAPTRs. As current support is limited, non-terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that all of the ENUM clients this environment supports can process these.
相互運用性の問題を回避するために、許容可能なアドバイスのいくつかの種類は、非ターミナルNAPTRs上で必要とされています。現在のサポートが限られているとして、ENUMクライアントのすべてのこのような環境のサポートはこれらを処理できることは明らかである場合を除き、非ターミナルNAPTRsはENUMでは使用しないでください。
The following specific issues need to be considered if non-terminal NAPTRs are to be supported in a particular environment. These issues are gleaned from experience and indicate the kinds of conditions that should be considered before support for non-terminal NAPTRs is contemplated. Note that these issues are in addition to the point just mentioned on ENUM provisioning or management system complexity and the potential for that management system to have no control over the zone contents to which non-terminal NAPTRs in its managed zones refer.
非終端NAPTRsは、特定の環境でサポートされる場合は、次の特定の問題を考慮する必要があります。これらの問題は経験から収集し、非ターミナルNAPTRsのサポートが企図される前に考慮すべき条件の種類を示しています。これらの問題は、単にその管理区域内の非末端NAPTRsが参照するゾーンの内容を制御することはできませんしENUMのプロビジョニングや管理システムの複雑さとその管理システムの可能性に言及したポイントに加えて、あることに注意してください。
As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the NAPTRs contained in another domain. The NAPTRs in the domain referred to by the non-terminal NAPTR may have a different ORDER value from that in the referring non-terminal NAPTR. See Section 4.5 for details.
前述したように、ある資源レコード集合における非末端NAPTRは、別のドメインに含まNAPTRsを指します。非終端NAPTRによって参照領域におけるNAPTRsは、参照非末端NAPTRとは異なる順序値を有することができます。詳細については、4.5節を参照してください。
Where a chain of non-terminal NAPTRs refers back to a domain already traversed in the current query, a "non-terminal" or referential loop is implied. An implementation MAY treat a chain of more than 5 domains traversed during a single ENUM query as an indication that a self-referential loop has been entered.
非末端NAPTRsの鎖がバック既に現在のクエリ、「非末端」または参照ループが示唆されるで横断ドメインを指します。実装は、自己参照ループが入力されていることを示すものとして、単一のENUMクエリーの間に横断する5つの以上のドメインのチェーンを扱うかもしれ。
There are many techniques that can be used to detect such a loop, but the simple approach of counting the number of domains queried in the current ENUM query suffices.
そこにこのようなループを検出するために使用することができる多くの技術があるが、現在のENUMクエリーで問い合わせドメインの数をカウントする単純なアプローチは、十分です。
Where a loop has been detected, processing SHOULD continue at the next NAPTR in the referring domain (i.e., after the non-terminal NAPTR that included the reference that triggered the loop detection).
ループが検出された場合、処理は（すなわち、ループ検出をトリガした参照を含ん非末端NAPTR後）参照領域の次のNAPTRで続けるべきです。
The set of specifications defining DDDS and its applications are complex and multi-layered. This reflects the flexibility that the system provides but does mean that some of the specifications need clarification as to their interpretation, particularly where non-terminal rules are concerned.
DDDSとそのアプリケーションを定義する仕様のセットは、複雑で多層化されています。これは、システムが提供しますが、仕様の一部を非ターミナルルールが懸念している場合は特に、その解釈に関して、明確化が必要であることを意味して柔軟性を反映しています。
Section 2.4.1 of [RFC3761] states that the only flag character valid for use with the "E2U" DDDS Application is 'u'. The flag 'u' is defined (in Section 4.3 of [RFC3404]) thus: 'The "u" flag means that the output of the Rule is a URI'.
[RFC3761]のセクション2.4.1「E2U」DDDSのアプリケーションで使用するために有効な唯一のフラグ文字が「U」であると述べています。 「U」はこうして（[RFC3404]のセクション4.3で）定義されるフラグ：「『U』フラグは、ルールの出力は、URIであることを意味します」。
Section 2.4.1 of [RFC3761] also states that an empty Flags field indicates a non-terminal NAPTR. This is also the case for other DDDS Application specifications, such as that specified in [RFC3404]. One could well argue that this is a feature potentially common to all DDDS Applications, and so might have been specified in [RFC3402] or [RFC3403].
[RFC3761]のセクション2.4.1には、空のフラグフィールドが非末端NAPTRを示していると述べています。これはまた、[RFC3404]で指定されるような他のDDDSアプリケーション仕様の場合です。一つは、よく、これはすべてのDDDSアプリケーションに対して潜在的に共通の特徴である、そしてので、[RFC3402]か[RFC3403]で指定されている可能性があることを主張することができます。
The Flags field will be empty in non-terminal NAPTRs encountered in ENUM processing. ENUM does not have any other way to indicate a non-terminal NAPTR.
FlagsフィールドはENUM処理で遭遇非ターミナルNAPTRsで空になります。 ENUMは、非ターミナルNAPTRを示すために、他の方法を持っていません。
Furthermore, [RFC3761] states that any Enumservice Specification requires definition of the URI that is the expected output of this Enumservice. This means that, at present, there is no way to specify an Enumservice that is non-terminal; such a non-terminal NAPTR has, by definition, no URI as its expected output, instead returning a key (DNS domain name) that is to be used in the "next round" of DDDS processing.
さらに、[RFC3761]は、任意のEnumservice仕様このEnumserviceの予想出力されるURIの定義を必要とすることを述べています。これは現在、非端末であるEnumserviceを指定する方法がない、ことを意味します。このような非末端NAPTR代わりDDDS処理の「次回」で使用されるキー（DNSドメイン名）を返す、その期待される出力として、定義により、まったくURIを有していません。
This in turn means that a non-terminal NAPTR cannot hold a valid (non-empty) Services field when used in ENUM. Section 2.4.2 of [RFC3761] specifies the syntax for this field content and requires at least one element of type <servicespec> (i.e., at least one Enumservice identifier). Given that there cannot be a non-terminal Enumservice (and so no such Registered Enumservice identifier), this syntax cannot be met with a non-terminal NAPTR; there are no non-terminal Enumservices to put into this field.
これは、順番にENUMに使用した場合の非末端NAPTRが有効な（空でない）サービスのフィールドを保持できないことを意味します。 [RFC3761]のセクション2.4.2は、このフィールドの内容のための構文を指定し、タイプの少なくとも1つの要素<servicespec>（即ち、少なくとも一つのEnumservice識別子）を必要とします。非終端Enumservice（及び従ってそのような登録Enumservice識別子）が存在しないことを考えると、この構文は、非末端NAPTRで満たすことができません。このフィールドに置くために何の非ターミナルEnumservicesはありません。
A reasonable interpretation of the specifications is that for a non-terminal NAPTR, the Services field must also be empty. This appears to be the approach taken by those clients that do either process non-terminal NAPTRs or check the validity of the fields.
仕様の合理的な解釈は、非ターミナルNAPTRのために、サービスのフィールドも空でなければならないということです。これは、非ターミナルNAPTRsを処理するか、フィールドの妥当性をチェックしますかのどちらかそれらのクライアントが取るアプローチであるように思われます。
It is expected that future revisions of the ENUM standard will clarify this text, making this interpretation plain. This was the intent of the current standard, and the intent will be made explicit in its revision.
ENUMの標準の将来の改訂はこの解釈平野を作り、このテキストを明確化することが期待されます。これは、現在の標準の意図だった、との意図は、そのリビジョンで明示的に行われます。
In keeping with existing implementations, in a non-terminal NAPTR encountered in an ENUM query, the Services field SHOULD be empty, and clients SHOULD ignore any content it contains.
ENUMクエリーに遭遇した非ターミナルNAPTRでは、既存の実装に合わせて、サービスのフィールドが空であるべきであり、クライアントはそれが含まれているすべてのコンテンツを無視する必要があります。
Of course, such non-terminal NAPTRs with an empty Services field are not specific to any DDDS Application. Thus, other means must be used to ensure a non-terminal NAPTR that is intended only for a particular DDDS Application cannot be encountered during a lookup for another DDDS Application (for example, by ensuring that the same domain is not used to host NAPTRs for more than one such DDDS Application).
もちろん、空のサービス分野でのこのような非ターミナルNAPTRsはどんなDDDSアプリケーションに固有のものではありません。従って、他の手段は、同一のドメインがためNAPTRsをホストするために使用されないことを保証することにより、例えば別のDDDSアプリケーションのルックアップ（中に遭遇することができない特定のDDDSアプリケーションのためにのみ意図されている非末端NAPTRを確実にするために使用されなければなりません以上のようにDDDSアプリケーション）。
5.2.3.3. Regular Expression and Replacement Field Content with Non-Terminal NAPTRs
5.2.3.3。非ターミナルNAPTRsと正規表現と置換フィールド内容
The descriptive text in Section 4.1 of [RFC3403] is intended to explain how the fields are to be used in a NAPTR. However, the descriptions associated with the Regexp and Replacement elements have led to some confusion over which of these should be considered when dealing with non-terminal NAPTRs.
[RFC3403]のセクション4.1で説明テキストをフィールドはNAPTRで使用される方法を説明することを意図しています。しかし、正規表現および交換要素に関連した記述は、非末端NAPTRsを扱う際に考慮すべきこれらのその上にいくつかの混乱につながっています。
[RFC3403] is specific; these two elements are mutually exclusive. This means that if the Regexp element is not empty, then the Replacement element must be empty, and vice versa. However, [RFC3403] does not specify which is used with terminal and non-terminal rules.
[RFC3403]は特異的です。これら2つの要素は相互に排他的です。これは、正規表現の要素が空でない場合、次に交換要素が空でなければならないことを意味し、その逆。しかしながら、[RFC3403]端子と非末端規則に使用される指定されていません。
The descriptive text of Section 4.1 of [RFC3403] for the NAPTR Replacement element shows that this element holds an uncompressed domain name. Thus, it is clear that this element cannot be used to deliver the terminal string for any DDDS Application that does not have a domain name as its intended terminal output.
NAPTR交換要素のための[RFC3403]のセクション4.1の説明のテキストは、この要素が圧縮されていないドメイン名を保持していることを示しています。したがって、この要素はその意図したターミナル出力としてドメイン名を持っていない任意のDDDSアプリケーション用の端子列を送達するために使用することができないことは明らかです。
However, the first paragraph of descriptive text for the NAPTR Regexp element has led to some confusion. It appears that the Regexp element is to be used to find "the next domain name to lookup". This might be interpreted as meaning that a client program processing the DDDS Application could need to examine each non-terminal NAPTR to decide whether the Regexp element or instead the Replacement element should be used to construct the key (a domain name) to be used next in non-terminal rule processing.
しかし、NAPTR正規表現要素の説明テキストの最初の段落は、いくつかの混乱につながっています。正規表現の要素は、「ルックアップするために、次のドメイン名」を見つけるために使用されることが表示されます。これはDDDSアプリケーションを処理するクライアントプログラムが正規表現要素またはその代わりに交換要素が次に使用するキー（ドメイン名）を構築するために使用する必要があるかどうかを決定するために、各非終端NAPTRを検討する必要がある可能性があることを意味するものとして解釈される可能性があります非終端ルール処理インチ
Given that a NAPTR holding a terminal rule (a "terminal NAPTR") must use the Substitution expression field to generate the expected output of that DDDS Application, the Regexp element is also used in such rules. Indeed, unless that DDDS Application has a domain name as its terminal output, the Regexp element is the only possibility.
端末ルール（「ターミナルNAPTR」）を保持するNAPTRそのDDDSアプリケーションの予想される出力を生成するために代入式フィールドを使用しなければならないことを考えると、正規表現の要素は、そのようなルールで使用されています。そのDDDSアプリケーションがその端子出力としてドメイン名を持っていない限り、確かに、正規表現の要素が唯一の可能性です。
Thus, from the descriptive text of this section, a Replacement element can be used only in NAPTRs holding a non-terminal rule (a "non-terminal NAPTR") unless that DDDS Application has a domain name as its terminal output, whilst the alternative Regexp element may be used either to generate a domain name as the next key to be used in the non-terminal case or to generate the output of the DDDS Application.
したがって、このセクションの説明文から、置換素子は別のながら、そのDDDSアプリケーションは、その端子の出力としてドメイン名を持っていない限り、非末端ルール（「非末端NAPTR」）を保持NAPTRsにのみ使用することができます正規表現要素は、非末端場合又はDDDSアプリケーションの出力を生成するために使用される次のキーとしてドメイン名を生成するために使用することができます。
Note that each DDDS Application is free to specify the set of flags to be used with that application. This includes specifying whether a particular flag is associated with a terminal or non-terminal rule, and also includes specifying the interpretation of an empty Flags field (i.e., whether this is to be interpreted as a terminal or non-terminal rule, and if it is terminal, then what is the expected output). ENUM (as specified in Section 2.4.1 of [RFC3761]) uses only the 'u' flag, with an empty Flags field indicating a non-terminal NAPTR.
各DDDSアプリケーションがそのアプリケーションで使用するフラグのセットを指定するために自由であることに留意されたいです。これは、特定のフラグは末端または非末端ルールに関連付けられているかどうかを指定含み、また、これは末端または非末端ルールとして解釈されるべきであるかどうか、すなわち、空のFlagsフィールド（の解釈を指定すると、その場合端末であり、その後、）期待出力するものです。 ENUMは、（[RFC3761]のセクション2.4.1で指定されるように）非末端NAPTRを示す空のFlagsフィールドでのみ「U」フラグを使用します。
The general case in which a client program must check which of the two elements to use in non-terminal NAPTR processing complicates implementation, and this interpretation has NOT been made in current ENUM implementations. It would be useful to define exactly when a client program can expect to process the Regexp element and when to expect to process the Replacement element, if only to improve robustness. Generating an ENUM domain name from the Regexp field is difficult at best and impossible for the general case of a variable-length telephone number, or one that has more than 9 digits. Thus, it is proposed that when the ENUM specification is updated, this option is deprecated, and using the Regexp field for non-terminal ENUM NAPTRs is prohibited.
クライアントプログラムは、非ターミナルNAPTR処理に使用するために、2つの要素のどの確認する必要がある一般的なケースでは実装を複雑にし、この解釈は、現在のENUMの実装で行われていませんでした。クライアントプログラムは、正規表現の要素を処理することを期待することができますし、場合にのみ堅牢性を向上させるためならば、交換要素を処理することを期待するとき、正確に定義することが有用であろう。正規表現フィールドからENUMドメイン名を生成する可変長の電話番号、または9桁以上のものを有するものの一般的な場合のために最高の状態では困難と不可能です。したがって、ENUMの仕様が更新された場合、このオプションは廃止されていることを提案し、禁止されている非終端ENUMのNAPTRsのための正規表現のフィールドを使用しています。
In keeping with current implementations, the target domain of a non-terminal ENUM NAPTR MUST be placed in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. Conversely, the Regexp field MUST be empty in a non-terminal NAPTR encountered in ENUM processing, and ENUM clients MUST ignore its content.
現在の実装に合わせて、非末端ENUMのNAPTRの標的ドメインは、（空でない）交換分野に置かなければなりません。このフィールドは、この非ターミナルルールから次のキー出力を形成ドメイン名を保持していると解釈されなければなりません。逆に、正規表現のフィールドは、ENUM処理で遭遇する非末端NAPTRに空でなければなりません、そして、ENUMクライアントは、その内容を無視しなければなりません。
[RFC3761] is the current standard for the syntax for NAPTRs supporting the ENUM DDDS Application. This obsoletes the original specification that was given in [RFC2916]. RFC 3761 made a change to the syntax of the Services field of the NAPTR that reflects a refinement of the concept of ENUM processing.
[RFC3761]はENUM DDDSアプリケーションをサポートNAPTRsするための構文のための現在の標準です。これは[RFC2916]で与えられた元の仕様を時代遅れ。 RFC 3761は、ENUM処理の概念の洗練を反映したNAPTRのサービスフィールドの構文を変更しました。
As defined in [RFC3403], there is now a single identifier that indicates the DDDS Application. In the obsolete specification [RFC2915], there were zero or more "Resolution Service" identifiers (the equivalent of the DDDS Application). The same identifier string for the DDDS identifier or the Resolution Service is defined in both the [RFC3761] and [RFC2916] specifications: "E2U".
[RFC3403]で定義されるように、今DDDSアプリケーションを示す単一の識別子です。廃止された仕様[RFC2915]において、ゼロ以上の「解決サービス」識別子（DDDSアプリケーション相当）がありました。 「E2U」：DDDS識別子または解決サービスのために同じ識別子の文字列は、[RFC3761]と[RFC2916]の両方の仕様で定義されています。
Also, [RFC3761] defines at least one but potentially several Enumservice sub-fields; in the obsolete specification, only one "protocol" sub-field was allowed.
また、[RFC3761]は、少なくとも1つの潜在的にいくつかのEnumserviceサブフィールドは定義します。廃止された仕様で、唯一の「プロトコル」のサブフィールドが許可されました。
In many ways, the most important change for implementations is that the order of the sub-fields has been reversed. [RFC3761] specifies that the DDDS Application identifier is the leftmost sub-field, followed by one or more Enumservice sub-fields, each separated by the '+' character delimiter. [RFC2916] specified that the protocol sub-field was the leftmost, followed by the '+' delimiter, in turn followed by the "E2U" resolution service tag.
多くの点では、実装のための最も重要な変更は、サブフィールドの順序が逆にされていることです。 [RFC3761]はDDDSアプリケーション識別子は、1つ以上のEnumserviceサブフィールド、「+」文字区切り文字で区切られ、続いて、左端のサブフィールドであることを指定します。 [RFC2916]は、プロトコルサブフィールドが「+」区切り文字に続く左端、た、今度は「E2U」解像度サービスタグが続くことを指定しました。
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404] and by [RFC3761]. However, [RFC3824] suggests that ENUM clients should be prepared to accept NAPTRs with the obsolete syntax. Thus, an ENUM client implementation may have to deal with both forms. This need not be difficult. For example, an implementation could process the Services field into a set of tokens and expect exactly one of these tokens to be "E2U". In this way, the ENUM client might be designed to handle both the old and the current forms without added complexity.
[RFC3404]及び[RFC3761]で - [RFC2915]及び[RFC2916]は[RFC3401]によって廃止されてきました。ただし、[RFC3824]はENUMクライアントが廃止された構文でNAPTRsを受け入れるように準備されるべきであることを示唆しています。このように、ENUMクライアントの実装では、両方のフォームに対処する必要があります。これは困難である必要はありません。例えば、実装は、トークンのセットにサービスのフィールドを処理し、「E2U」であることを正確にこれらのトークンのいずれかを期待できます。このように、ENUMクライアントは、追加の複雑させずに古いと現在の形態の両方を処理するように設計されることがあります。
To facilitate this method, IANA should reject any request to register an Enumservice with the label "E2U".
この方法を容易にするために、IANAは、ラベル「E2U」とEnumserviceを登録するための要求を拒否しなければなりません。
To summarise, ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs. ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field is according to [RFC3761].
要約すると、ENUMクライアントは[RFC3761]構文に従ってENUMのNAPTRsをサポートしなければなりません。 ENUMクライアントは、[RFC2916]の廃止された構文に従ってENUMのNAPTRsを支持します。 「古い」構文NAPTRsを保持するゾーンが残っています。 ENUMゾーンは廃止形態に係るNAPTRsでプロビジョニングされてはいけません、およびサービスフィールドは[RFC3761]に記載されているNAPTRsでプロビジョニングされなければなりません。
ENUM NAPTRs SHOULD NOT include characters outside the printable US-ASCII equivalent range (U+0020 to U+007E) unless it is clear that all ENUM clients they are designed to support will be able to process such characters correctly. If ENUM zone provisioning systems require non-ASCII characters, these systems SHOULD encode the non-ASCII data to emit only US-ASCII characters by applying the appropriate mechanism ([RFC3492], [RFC3987]). Non-printable characters SHOULD NOT be used, as ENUM clients may need to present NAPTR content in a human-readable form.
彼らがサポートするように設計されているすべてのENUMクライアントが正しく、このような文字を処理できるようになることは明らかでない限り、ENUM NAPTRsは（U + 007EへのU + 0020）の印刷可能なUS-ASCII同等の範囲外の文字を含めないでください。 ENUMゾーンプロビジョニングシステムは、非ASCII文字が必要な場合、これらのシステムは、適切な機構（[RFC3492]、[RFC3987]）を適用することによって、US-ASCII文字だけを放出するように、非ASCIIデータを符号化すべきです。 ENUMクライアントは、人間が読める形式でNAPTRコンテンツを提示する必要があるかもしれないとして、非印字可能な文字は、使用されるべきではありません。
The case-sensitivity flag ('i') is inappropriate for ENUM, and SHOULD NOT be provisioned into the Regexp field of E2U NAPTRs.
大文字と小文字の区別フラグ（I「」）は、ENUMには不適切であり、及びE2U NAPTRsの正規表現フィールドにプロビジョニングされるべきではありません。
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character.
ENUMゾーンのプロビジョニング・システムは使用すべきです「！」その正規表現の区切り文字として（U + 0021）。
If the Regexp delimiter is a character in the static text of the Repl sub-field, it MUST be "escaped" using the escaped-delimiter production of the BNF specification shown in Section 3.2 of [RFC3402] (i.e., "\!", U+005C U+0021). Note that when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
正規表現区切り文字はREPLサブフィールドの静的テキストの文字である場合、それは[RFC3402]の3.2節に示したBNFの仕様のエスケープ・区切りの生産を使用して「エスケープ」する必要があります（つまり、「\！」、 U + 005C U + 0021）。 NAPTRリソースレコードをDNSマスターファイルの構文で入力された場合、バックスラッシュ自身が第二のバックスラッシュを使ってエスケープしなければならないことに注意してください。
If present in the ERE sub-field of an ENUM NAPTR, the literal character '+' MUST be escaped as "\+" (i.e. U+005C U+002B). Note that, as always, when a NAPTR resource record is entered in DNS master file syntax, the backslash itself must be escaped using a second backslash.
ENUM NAPTR、リテラル文字「+」のEREサブフィールドに存在する場合は「\ +」（すなわち、U + 005C U + 002B）のようにエスケープする必要があります。 NAPTRリソースレコードをDNSマスターファイルの構文で入力されたとき、いつものように、なお、バックスラッシュ自体は、第二のバックスラッシュを使ってエスケープする必要があります。
The Registrant and the ENUM zone provisioning system he or she uses SHOULD NOT rely on ENUM clients solely taking account of the value of the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a Registrant SHOULD place into his or her zone only contacts that he or she is willing to support; even those with the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an end user.
登録者と彼または彼女が使用するENUMゾーンプロビジョニングシステムは、単にORDERとENUM NAPTRsでPREFERENCE / PRIORITYフィールドの値を考慮したENUMクライアントに依存しないでください。このように、登録者は彼または彼女がサポートしても構わないと思っている連絡先だけ自分のゾーンに配置する必要があります。でも、それらの最悪ORDERや好みに/ PRIORITY値は、エンドユーザによって選択されてもよいです。
Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have been detected in provisioned ENUM zones. To avoid these common interoperability issues, provisioning systems SHOULD NOT use different ORDER field values for NAPTRs in a Resource Record Set (RRSet). To generalise, all ENUM NAPTRs SHOULD hold a default value in their ORDER field. A value of "100" is recommended, as it seems to be used in most provisioned domains.
ORDERと優先的に多くの明白なミス/ PRIORITY値は、プロビジョニングさENUMゾーンで検出されています。これらの一般的な相互運用性の問題を回避するには、プロビジョニング・システムは、リソースレコードセット（資源レコード集合）でNAPTRsに異なるORDERフィールド値を使用しないでください。一般化するには、すべてのENUMのNAPTRsはそのORDERフィールドのデフォルト値を保持する必要があります。ほとんどのプロビジョニングドメインで使用しているように見えるとして、「100」の値が、推奨されます。
Multiple NAPTRs with identical ORDER and identical PREFERENCE/ PRIORITY field values SHOULD NOT be provisioned into an RRSet unless the intent is that these NAPTRs are truly identical and there is no preference between them. Implementers SHOULD NOT assume that the DNS will deliver NAPTRs within an RRSet in a particular sequence.
意図は、これらのNAPTRsが本当に同一であり、それらの間には優先順位がないことである場合を除き、同一の順序と同じPREFERENCE / PRIORITYフィールド値を持つ複数のNAPTRsは資源レコード集合にプロビジョニングされるべきではありません。実装者はDNSが特定の順序で資源レコード集合内NAPTRsをお届けすることを仮定するべきではありません。
An ENUM zone provisioning system SHOULD assume that, if it generates compound NAPTRs, the Enumservices will normally be processed in left-to-right order within such NAPTRs.
ENUMゾーンプロビジョニングシステムは、化合物NAPTRsを生成した場合、Enumservicesは通常、NAPTRs内の左から右への順序で処理され、それを想定すべきです。
ENUM zone provisioning systems SHOULD assume that, once a non-terminal NAPTR has been selected for processing, the ORDER field value in a domain referred to by that non-terminal NAPTR will be considered only within the context of that referenced domain (i.e., the ORDER value will be used only to sort within the current RRSet and will not be used in the processing of NAPTRs in any other RRSet).
非終端NAPTRは、処理のために選択された後、システムをプロビジョニングENUMゾーンは、それを前提とすべきである、ドメイン順序フィールドの値は、非終端NAPTRで参照のみが参照されるドメイン（すなわち、のコンテキスト内で考慮されます、 ORDER値）が現在の資源レコード集合内でソートするためにのみ使用され、他の資源レコード集合にNAPTRsの処理に使用されることはありません。
Whilst this client behaviour is non-compliant, ENUM provisioning systems and their users should be aware that some ENUM clients have been detected with poor (or no) support for non-trivial ERE sub-field expressions.
このクライアントの動作は非対応であるが、ENUMプロビジョニングシステムとそのユーザーは、いくつかのENUMクライアントが非自明なEREサブフィールド式の貧弱（またはなし）をサポートして検出されたことを認識する必要があります。
ENUM provisioning systems SHOULD be cautious in the use of multiple back-reference patterns in the Repl sub-field of NAPTRs they provision. Some clients have limited buffer space for character expansion when generating URIs (see also Section 3). These provisioning systems SHOULD check the back-reference replacement patterns they use, ensuring that regular expression processing will not produce excessive-length URIs.
ENUMプロビジョニングシステムは、それら提供NAPTRsのREPLサブフィールドにおける複数のバック基準パターンの使用に注意が必要です。 URIを生成するときに一部のクライアントは、文字拡張のためのバッファスペースが限られている（また、セクション3を参照）。これらプロビジョニングシステムは、正規表現処理が過剰長のURIを生成しないことを確実にすること、彼らが使用する後方参照置換パターンを確認してください。
As current support is limited, non-terminal NAPTRs SHOULD NOT be provisioned in ENUM zones unless it is clear that all ENUM clients that this environment supports can process these.
現在のサポートが限られているとして、この環境でサポートされているすべてのENUMクライアントはこれらを処理できることは明らかである場合を除き、非ターミナルNAPTRsはENUMのゾーンにプロビジョニングされるべきではありません。
When populating a set of domains with NAPTRs, ENUM zone provisioning systems SHOULD NOT configure non-terminal NAPTRs so that more than 5 such NAPTRs will be processed in an ENUM query.
NAPTRsとドメインのセットを移入する際以上5かかるNAPTRsは、ENUMクエリーで処理されるように、ENUMゾーンプロビジョニングシステムは、非末端NAPTRsを設定しないでください。
In a non-terminal NAPTR encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.
ENUMクエリーに遭遇する非末端NAPTR（すなわち、空のFlagsフィールドを有するもの）において、サービスフィールドが空であるべきです。
A non-terminal NAPTR MUST include its target domain in the (non-empty) Replacement field. This field MUST be interpreted as holding the domain name that forms the next key output from this non-terminal rule. The Regexp field MUST be empty in a non-terminal NAPTR intended to be encountered during an ENUM query.
非終端NAPTRは（空でない）交換分野におけるその標的ドメインを含まなければなりません。このフィールドは、この非ターミナルルールから次のキー出力を形成ドメイン名を保持していると解釈されなければなりません。正規表現のフィールドは、ENUMクエリーの間に遭遇することを意図し非終端NAPTRでは空でなければなりません。
ENUM zones MUST NOT be provisioned with NAPTRs according to the obsolete form, and MUST be provisioned with NAPTRs in which the Services field is according to [RFC3761].
ENUMゾーンは廃止形態に係るNAPTRsでプロビジョニングされてはいけません、およびサービスフィールドは[RFC3761]に記載されているNAPTRsでプロビジョニングされなければなりません。
ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).
ENUMクライアントは、US-ASCII印刷可能範囲（0x7Eを16進数には0x20）以外の文字を検出するNAPTRsを破棄すべきではありません。
ENUM clients MAY discard NAPTRs that have octets in the Flags, Services, or Regexp fields that have byte values outside the US-ASCII equivalent range (i.e., byte values above 0x7F). Clients MUST be ready to encounter NAPTRs with such values without failure.
ENUMクライアントは、US-ASCII同等の範囲外のバイト値を持っている国旗、サービス、または正規表現の分野でのオクテットを持っNAPTRsを捨てるかもしれ（すなわち、0x7Fを上記のバイト値）。クライアントは、失敗することなく、そのような値を持つNAPTRsに遭遇する準備ができなければなりません。
ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.
ENUMクライアントは、区切り文字が正規表現のフィールドの最後の文字であると仮定するべきではありません。
Unless they are sure that in their environment this is the case, in general an ENUM client may still encounter NAPTRs that have been provisioned with a following 'i' (case-insensitive) flag, even though that flag has no effect at all in an ENUM scenario.
彼らは自分の環境ではこれが事実であることが確実な場合を除き、一般的にはENUMクライアントはまだそのフラグがに全く影響を与えないにもかかわらず、以下の「I」（大文字と小文字を区別しない）フラグでプロビジョニングされているNAPTRsが発生する可能性がありますENUMのシナリオ。
ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.
ENUMクライアントは、正規表現のフィールド内の区切り文字のより多くても少なくても3つのエスケープされていないインスタンスを持つNAPTRsを捨てます。
In the spirit of being liberal with what it will accept, if the ENUM client is sure how the Regexp field should be interpreted, then it may choose to process the NAPTR even in the face of an incorrect number of unescaped delimiter characters. If it is not clear how the Regexp field should be interpreted, then the client must discard the NAPTR.
ENUMクライアントは、正規表現の場をどのように解釈すべきか確実であるならば、それは、受け入れるものとのリベラルであることの精神で、それも、エスケープされていない区切り文字の不正確な数の顔でNAPTRを処理することもできます。それは正規表現フィールドがどのように解釈すべきか明確でない場合、クライアントはNAPTRを破棄しなければなりません。
Where the ENUM client presents a list of possible URLs to the end user for his or her choice, it MAY present all NAPTRs -- not just the ones with the highest currently unprocessed ORDER field value. The client SHOULD keep to the ORDER and PREFERENCE/PRIORITY values specified by the Registrant.
最高の現在未処理のORDERフィールドの値を持つものだけでなく - ENUMクライアントは、彼または彼女の選択のためのエンドユーザーに可能なURLのリストを提示した場合、それはすべてのNAPTRsを提示することができます。クライアントは、登録者により指定された順序と優先/ PRIORITY値に保つべきです。
ENUM clients SHOULD accept all NAPTRs with identical ORDER and identical PREFERENCE/PRIORITY field values, and process them in the sequence in which they appear in the DNS response. (There is no benefit in further randomising the order in which these are processed, as intervening DNS Servers might have done this already).
ENUMクライアントは、同一の順序と同じPREFERENCE / PRIORITYフィールド値を持つすべてのNAPTRsを受け入れ、彼らはDNS応答に表示される順番に処理しなければなりません。 （すでにこれを行っている可能性がさらにDNSサーバーを介在として、これらが処理される順序をランダム化における利点はありません）。
ENUM clients receiving compound NAPTRs (i.e., ones with more than one Enumservice) SHOULD process these Enumservices using a left-to-right sort ordering, so that the first Enumservice to be processed will be the leftmost one, and the last will be the rightmost one.
ENUMクライアントは、処理すべき最初のEnumserviceは左端の1になるように（すなわち、複数のEnumserviceを持つもの）は、左から右へのソート順を使用して、これらのEnumservicesを処理すべき化合物のNAPTRsを受け、最後は一番右になります1。
ENUM clients SHOULD consider the ORDER field value only when sorting NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be taken into account when processing NAPTRs across a sequence of DNS queries created by traversal of non-terminal NAPTR references.
単一資源レコード集合内NAPTRsをソートする場合にのみ、ENUMクライアントはORDERフィールドの値を考慮する必要があります。非ターミナルNAPTR参照のトラバーサルにより作成されたDNSクエリのシーケンス全体NAPTRsを処理するときORDERフィールドの値は考慮されるべきではありません。
ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.
ENUMクライアントは、異なる文字を使用NAPTRsを処理する準備ができなければなりません「！」失敗せずに自分の正規表現の区切り文字として。
ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.
ENUMクライアントは、失敗することなく、EREサブフィールド値の非自明なパターンを持っているNAPTRsを処理する準備ができなければなりません。
ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.
ENUMクライアントは、失敗することなく、「E2U」以外のDDDSアプリケーション識別子とNAPTRsを処理する準備ができなければなりません。
ENUM clients MUST be ready to process NAPTRs with many copies of back-reference patterns within the Repl sub-field without failure (see also Section 3).
ENUMクライアントは、（セクション3を参照）障害なしREPLサブフィールド内で後方参照パターンの多数のコピーとNAPTRsを処理する準備ができなければなりません。
If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query to terminate and processing SHOULD continue with the next NAPTR in the returned Resource Record Set (RRSet).
NAPTRが破棄された場合、これは全体のENUMクエリーを終了させるべきではなく、処理が返されるリソースレコードセットの次のNAPTR（資源レコード集合）を継続する必要があります。
When an ENUM client encounters a compound NAPTR (i.e., one containing more than one Enumservice) and cannot process or cannot recognise one of the Enumservices within it, that ENUM client SHOULD ignore this Enumservice and continue with the next Enumservice within this NAPTR's Services field, discarding the NAPTR only if it cannot handle any of the Enumservices contained. These conditions SHOULD NOT be considered errors.
ENUMクライアントは、化合物のNAPTRを検出すると（すなわち、1つ以上のEnumserviceを含む）と、処理できないか、ENUMクライアントは、このEnumserviceを無視し、このNAPTRのサービスフィールド内の次のEnumserviceを継続すべきであること、その中Enumservicesのいずれかを認識することができず、 NAPTRを捨てることがEnumservicesのいずれかに含まを扱うことができない場合にのみ。これらの条件は、エラーとみなされるべきではありません。
ENUM clients MUST support ENUM NAPTRs according to [RFC3761] syntax. ENUM clients SHOULD also support ENUM NAPTRs according to the obsolete syntax of [RFC2916]; there are still zones that hold "old" syntax NAPTRs.
ENUMクライアントは[RFC3761]構文に従ってENUMのNAPTRsをサポートしなければなりません。 ENUMクライアントは、[RFC2916]の廃止された構文に従ってENUMのNAPTRsを支持します。 「古い」構文NAPTRsを保持するゾーンが残っています。
ENUM clients MUST be ready to process NAPTRs with an empty Flags field ("non-terminal" NAPTRs) without failure. More generally, non-terminal NAPTR processing SHOULD be implemented, but ENUM clients MAY discard non-terminal NAPTRs they encounter.
ENUMクライアントは、失敗せずに空のFlagsフィールド（「非末端」NAPTRs）でNAPTRsを処理する準備ができなければなりません。より一般的には、非終端NAPTR処理が実施されるべきであるが、ENUMクライアントは、彼らが遭遇する非ターミナルNAPTRsを捨てるかもしれ。
ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.
空のFlagsフィールドで非ターミナルNAPTRに遭遇したときENUMクライアントは、サービス分野のいずれかの内容を無視します。
ENUM clients receiving a non-terminal NAPTR with an empty Flags field MUST treat the Replacement field as holding the domain name to be used in the next round of the ENUM query. An ENUM client MUST discard such a non-terminal NAPTR if the Replacement field is empty or does not contain a valid domain name. By definition, it follows that the Regexp field will be empty in such a non-terminal NAPTR. If present in a non-terminal NAPTR, a non-empty Regexp field MUST be ignored by ENUM clients.
空のFlagsフィールドで非ターミナルNAPTRを受けたENUMクライアントは、ENUMクエリーの次のラウンドで使用されるドメイン名を保持するよう置換フィールドを扱わなければなりません。交換用フィールドが空であるか、有効なドメイン名が含まれていない場合、ENUMクライアントは、このような非ターミナルNAPTRを捨てなければなりません。定義することで、正規表現、フィールドには、このような非ターミナルNAPTRで空になることになります。非ターミナルNAPTRに存在する場合は、空でない正規表現のフィールドはENUMクライアントによって無視されなければなりません。
If a problem is detected when processing an ENUM query across multiple domains (by following non-terminal NAPTR references), then the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD continue at the next NAPTR after the non-terminal NAPTR that referred to the domain in which the problem would have occurred.
（非末端NAPTR参照に従うことによって）複数のドメインを横切るENUMクエリーを処理する際に問題が検出された場合、ENUM照会が放棄されるべきではなく、代わりに呼ばれる非末端NAPTR後の次のNAPTRで続けるべき処理します問題が発生していると思われるドメイン。
If all NAPTRs in a domain traversed as a result of a reference in a non-terminal NAPTR have been discarded, then the ENUM client SHOULD continue its processing with the next NAPTR in the "referring" RRSet (i.e., the one including the non-terminal NAPTR that caused the traversal).
ドメイン内のすべてのNAPTRsは非ターミナルNAPTRで参照した結果、横断場合は破棄された後、ENUMクライアントは、「参照」資源レコード集合（すなわち、非含めて1の次のNAPTRでその処理を継続すべきですトラバーサルを引き起こし、端末NAPTR）。
ENUM clients MAY consider a chain of more than 5 "non-terminal" NAPTRs traversed in a single ENUM query as an indication that a referential loop has been entered.
ENUMクライアントは、参照ループが入力されていることを示すものとして、単一のENUMクエリーに横断する5つ以上の「非末端」NAPTRsの連鎖を考慮することができます。
Where a domain is about to be entered as the result of a reference in a non-terminal NAPTR, and the ENUM client has detected a potential referential loop, then the client SHOULD discard the non-terminal NAPTR from its processing and continue with the next NAPTR in its list. It SHOULD NOT make the DNS query indicated by that non-terminal NAPTR.
ドメインは、非末端NAPTRにおける基準の結果として入力されようとしている、及びENUMクライアントは、潜在的参照ループを検出した場合、クライアントはその処理から非末端NAPTRを破棄し、次に進みSHOULDそのリストでNAPTR。これは、その非終端NAPTRで示されたDNSクエリを行うべきではありません。
In addition to the security implications of recommendations in this document, those in the basic use of ENUM (and specified in the normative documents for this protocol) should be considered as well; this document does not negate those in any way.
この文書に記載されている推奨のセキュリティへの影響に加えて、ENUMの基本的な使用のもの（およびこのプロトコルの規範文書で指定された）も考慮すべきです。この文書は、どのような方法でそれらを否定するものではありません。
The clarifications throughout this document are intended only as that: clarifications of text in the normative documents. They do not appear to have any security implications above those mentioned in the normative documents.
この文書を通じて明確化のみを目的としているものとして：規範文書内のテキストの明確化を。彼らは規範的文書で言及されたもの上記のいずれかのセキュリティへの影響を持っているように見えません。
The suggestions in Section 2, Section 4, and Section 6 do not appear to have any security considerations (either positive or negative).
第2、第4、及び第6節での提案は、（正または負のいずれか）の任意のセキュリティ上の考慮事項を持っているように見えません。
The suggestions in Section 5.2.2 are a valid approach to a known security threat. It does not open an advantage to an attacker in causing excess processing or memory usage in the client. It does, however, mean that an ENUM client will traverse a "tight loop" of non-terminal NAPTRs in two domains 5 times before the client detects this as a loop; this does introduce slightly higher processing load than would be provided using other methods, but avoids the risks they incur.
5.2.2での提案は、既知のセキュリティ脅威への有効なアプローチです。これは、クライアントに過剰処理やメモリ使用量の原因に攻撃者に利益を開きません。しかし、クライアントがループとしてこれを検出する前にENUMクライアントは、2個のドメインで5回を無ターミナルNAPTRsの「タイトなループを」横断することを意味しています。これは、他の方法を使用して提供されるよりもわずかに高い処理負荷を紹介していますが、彼らは被るリスクを回避できます。
As mentioned in Section 3, ENUM uses regular expressions to generate URIs. Though it is a standard feature of DDDS, use of "non-greedy" regular expressions with multiple back-reference patterns in the Repl sub-field does create the potential for buffer-overrun attacks. Provisioning system designers SHOULD be aware of this and SHOULD limit the repeated use of back-reference replacement patterns. Conversely, ENUM client implementers SHOULD avoid using fixed character buffers when generating URIs from Repl sub-fields that include Back-reference patterns, and MUST avoid failure in the case of buffer exhaustion.
第3節で述べたように、ENUMは、URIを生成するために、正規表現を使用しています。それはDDDSの標準機能ですが、REPLのサブフィールドで複数のバック参照パターンと「非貪欲」の正規表現の使用は、バッファオーバーラン攻撃の可能性を作成しません。システム設計者のプロビジョニングはこのことを認識すべきであり、逆参照置換パターンの繰り返しの使用を制限する必要があります。逆に、ENUMクライアントの実装は、後方参照パターンを含むREPLサブフィールドからURIを生成するときに確定文字バッファの使用を避けるべきであり、バッファ枯渇の場合に故障を回避しなければなりません。
We would like to thank the various development teams who implemented ENUM (both creation systems and clients) and who read the normative documents differently -- without these differences it would have been harder for us all to develop robust clients and suitably conservative management systems. We would also thank those who allowed us to check their implementations to explore behaviour; their trust and help were much appreciated.
私たちのすべては、堅牢なクライアントと適切に保守的な管理システムを開発することは困難であったであろうこれらの違いなし - 私たちは、ENUM（作成システムとクライアントの両方）を実装し、異なった規範文書を読んで誰が様々な開発チームに感謝したいと思います。また、行動を探るために彼らの実装を確認することができました人々に感謝します。彼らの信頼とヘルプははるかに高く評価されました。
In particular, thanks to Richard Stastny for his hard work on a similar task, TS 102 172 [ETSI-TS102172] under the aegis of ETSI, and for supporting some of the ENUM implementations that exist today.
具体的には、ETSIの庇護の下で、同様の課題に彼のハードワーク、TS 102 172 [ETSI-TS102172]のためのリチャードStastnyのおかげで、今日存在するENUM実装の一部を支援します。
Finally, thanks for the dedication of Michael Mealling in giving us such detailed DDDS specifications, without which the ENUM development effort would have had a less rigorous framework on which to build. This document reflects how complex a system it is: without the intricacy of [RFC3401] - [RFC3404] and the work that went into them, it could have been very difficult to ensure interoperability.
最後に、私たちにENUMの開発努力を構築するためにあまり厳格なフレームワークを持っていたと思われることなく、このような詳細なDDDS仕様を与えることにマイケル・メオーリングの献身に感謝。 [RFC3404]及びそれらに入った仕事、相互運用性を確保することは非常に困難だったかもしれない - [RFC3401]の複雑なし：この文書では、どのように複雑なことがあるシステム反映しています。
[E.164] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[E.164] ITU-T、 "国際公共通信番号プラン"、勧告E.164は、2005年2月。
[IEEE.1003-2.1992] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2, January 1993.
[IEEE.1003-2.1992]電気電子技術者協会、 "情報技術 - ポータブルオペレーティングシステムインタフェース（POSIX） - パート2：シェルとユーティリティ（第1巻）"、IEEE標準1003.2、1993年1月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[RFC3404] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）"、RFC 3404、2002年10月。
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
[RFC3405] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、BCP 65、RFC 3405、2002年10月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761] Faltstrom、P.とM. Mealling、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
「 - 情報交換のための7ビットの米国標準コードコード化文字セット」、ANSI X3.4、1986 [ASCII]米国規格協会、。
[ETSI-TS102172] ETSI, "Minimum Requirements for Interoperability of European ENUM Implementations", ETSI TS 102 172, October 2004.
[ETSI-TS102172] ETSI、 "欧州のENUM実装の相互運用性のための最小要件"、ETSI TS 102 172、2004年10月。
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2915] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年9月。
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC2916] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824]ピーターソン、J.、劉、H.、ユー、J.、およびB.キャンベル、RFC 3824、2004年6月 "セッション開始プロトコル（SIP）とE.164番号を使用します"。
Authors' Addresses
著者のアドレス
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイRokeマナー研究Rokeマナーオールド・ソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666 EMail: lconroy@insensate.co.uk URI: http://www.sienum.co.uk
電話：+ 44-1794-833666電子メール：lconroy@insensate.co.uk URI：http://www.sienum.co.uk
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku Tokyo 101-0165 JAPAN
かずのり ふじわら じゃぱん れぎｓｔｒｙ せｒゔぃせｓ こ。、 Ｌｔｄ。 ちよだ ふぃｒｓｔ Ｂｌｄｇ。 えあｓｔ １３Ｆ ３ー８ー１ にしーかんだ ちよだーく ときょ １０１ー０１６５ じゃぱん
EMail: fujiwara@jprs.co.jp URI: http://jprs.co.jp/en/
電子メール：URI fujiwara@jprs.co.jp：http://jprs.co.jp/en/