[要約] 要約：RFC 5483は、ENUM（電話番号とインターネットリソースの対応付け）の実装に関連する問題と経験についての情報を提供しています。 目的：このRFCの目的は、ENUMの実装に関する問題や経験を共有し、ENUMの普及と効果的な利用を促進することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントは、他の人によって作成された列挙データの列挙プロトコルとエクスペリエンスに基づいてシステムを実装する経験をキャプチャします。そのため、列挙および動的委任ディスカバリーシステムの標準を明確にします。その目的は、「外出」と潜在的な落とし穴の両方を報告することにより、他の人を支援することです。基準を修正するのではなく、これらの文書の将来の改訂に技術的なインプットを提供することを目的としています。
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.
このドキュメントの目標は、列挙および動的委任ディスカバリーシステム（DDDS）標準を明確にすることです。それ自体は、enumまたはDDDSの標準を改訂するものではありませんが、これらのドキュメントの将来の改訂に技術的なインプットを提供することを目的としています。また、実装者に見つけられる落とし穴について助言するのに役立ちます。列挙の実装が標準ドキュメントの解釈によって異なっているか、指定されているようにいくつかの機能を実装できなかった領域を強調しています。
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番号マッピング（列挙）プロトコル[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は、NAPTR（命名機関ポインター）リソースレコードタイプを使用して、DDDSルールをDNSドメインに保存します。ENUMはDNSサービスに依存しています。したがって、ENUMの実装者にとって、既存のすべてのDNS標準ドキュメントの徹底的な分析を実行して、列挙されているサービスが提供されるサービスと、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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リソースレコードと列挙サポートUnicodeをサポートすることを指定します。これにより、実装が「シングルバイト」文字列処理ルーチンを使用すると問題が発生します。Enum NAPTR内にマルチバイト文字がある場合、これらのUTF-8-Unawareシステムから誤った処理が生じる可能性があります。
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.
UTF-8エンコーディングにはUS-ASCII同等の範囲があるため、US-ASCII [ASCII]のすべての文字が0x00から0x7FヘキサデシマルにUTF-8エンコードのIDマップがあります。エンコーディングは同じです。UTF-8では、この範囲の上にUnicodeコードポイントを持つ文字は、複数のバイトを使用してエンコードされ、そのすべてが0x80〜0xffヘキサデシマルの範囲になります。したがって、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の印刷不可能な部分（0x00〜0x1fヘキサデシマルに加えて0x7fヘキサデシマル）の文字は「困難」です。NAPTRは機械で処理されますが、人間が読みやすい形式で書かれる必要がある場合があります。具体的には、NAPTRコンテンツがエンドユーザーに表示されて選択できるようにする場合、コンテンツが人間が読み取ることが不可欠です。したがって、米国ASCII範囲内にある場合でも、印刷できない文字を使用することは賢明ではありません。Enumクライアントは、エンドユーザーに容易に提示できないため、これらのキャラクターを含むNAPTRを拒否する正当な理由がある場合があります。
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.
NAPTRには、順序と優先度/優先度のフィールドという2つの数値フィールドがあります。これらにはバイナリ値が含まれているため、文字列処理を適用すべきではないため、リスクは関係ありません。文字列ベースのフィールドは、フラグ、サービス、およびregexpフィールドです。交換場には、標準のDNSメカニズム[RFC1034] [RFC1035]に従ってエンコードされた非圧縮ドメイン名があります。国際化されたドメイン名（IDN）をサポートできます（[RFC3490]、[RFC3491]、および[RFC3492]で指定されています）。このようなIDNは、Punycode [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.
文字列フィールドを順番に取るフラグフィールドには、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.
サービスフィールドには、列挙に使用されるdddsアプリケーション識別子（ "e2u"）、enumservice識別子のセットが含まれます。いずれかが '：'セパレーター文字を埋め込むことができます。このDDDSアプリケーション識別子。[RFC3761]のセクション2.4.2では、Enumservice Identifierトークンは1*32アルファ/桁として指定されているため、サービスフィールドに非ASCII文字の可能性はありません。
The Regexp field is more complex. It forms a sed-like substitution expression, defined in [RFC3402], and consists of two sub-fields:
regexpフィールドはより複雑です。[RFC3402]で定義されたSED様置換式を形成し、2つのサブフィールドで構成されています。
o a POSIX Extended Regular Expression (ERE) sub-field [IEEE.1003-2.1992]
o POSIX拡張正規表現（ERE）サブフィールド[IEEE.1003-2.1992]
o a replacement (Repl) sub-field [RFC3402].
o 交換（REPL）サブフィールド[RFC3402]。
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」ケース非感受性フラグ）は列挙に適していません - セクション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サブフィールドは、「アプリケーションユニークな文字列」と一致します。列挙の場合、これは[RFC3761]で定義され、最初の「文字」を持つ数字文字で構成されます。これは、[RFC3966]で指定されているように、Tel：URIのグローバルな数桁の生産に似ていますが、視覚的なセパレーターが除去されています。要するに、それは制限形式の電話番号（[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 NAPTRがENUMドメインでプロビジョニングされる通常の状況では、EREは電話番号と一致することを目的としているため、このサブフィールド内にマルチバイト文字はありません。Enumクライアントは、そのようなマルチバイト文字を含むNAPTRを処理できる必要があります（標準がそれらを排除しないため）が、これらがENUMドメインでプロビジョニングされているという運用上の理由はありません。enumドメインでプロビジョニングされたNAPTRがそのようなマルチバイト文字を含む遭遇に遭遇した場合、これらは合理的に破棄される可能性があります。
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.
REPLサブフィールドには、[rfc3403]で定義されているように、uRIと置換式に重要なURIと重要な文字を構築するために使用される明示的なテキストの混合物を含めることができます。後者のセットはすべてUTF-8エンコーディングの米国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 Generic構文は、[RFC3986]で、US-ASCII文字のレパートリーの限られたサブセットから選択された一連の文字として定義されています。現在の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をRegexpフィールドで生成することのみを許可します。ただし、[RFC3987]で定義されている国際化されたリソース識別子（IRIS）の使用を可能にするために、これを列挙仕様の将来の改訂に拡張したとしても、非ASCII文字のさらなるサポートを回避することができます。虹彩は、URIの構文を拡張すると定義されており、RFC 3987はIRISからURISへのマッピングを指定します。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.
これがこのようなマルチバイトエンコーディングが合理的に見つかる可能性のある列挙NAPTR内の唯一の場所であることを考えると、[RFC3987]のセクション3.1で指定されたマッピング方法を使用して、IRIを同等のURIに変換することです。
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ドメイン名がある場合はPunycodeを使用して処理する必要があり、残りは[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 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.
ちょうど与えられた分析から、非ASSASCII文字が見つかる可能性のあるEnum Naptr内の唯一の場所は、regexpフィールドです。非常に少ない運用上の制限を追加することにより、米国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.
米国ASCII同等の範囲外のキャラクターを許可することからの利益は不明であり、マルチバイトの文字処理のコストは非常に明確であるため、列挙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フィールドコンテンツがケースに敏感である唯一の場所は、regexpフィールドの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.
Case-insensitivityフラグ（ 'i'）は、regexpフィールドの最後に追加できます。ただし、ENUMでは、eREサブフィールドは「文字」として定義された文字列で動作し、その後に一連の数字文字が続きます。このフラグは、REPLサブフィールドの内容に作用しないため、E2U Naptrsにとって冗長です。
Thus, the case-sensitivity flag is inappropriate for ENUM, and SHOULD NOT be provisioned into E2U NAPTRs.
したがって、ケース感度フラグは列挙には不適切であり、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.
サブフィールドの1つに表示されない区切り文字を選択することはできません。「！」文字は、[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サブフィールドに表示されません。有効な文字であるため、一部のURIの内容に表示される場合があります（たとえば、HTTP URL）。Regexpフィールドに存在する場合、[RFC3402]のセクション3.2で提案されている標準手法を使用して、そのインスタンスを脱出する必要があります。それ以外の場合、クライアントはこれを標準の区切り文字として処理し、Regexpフィールドの内容をプロビジョニングしたシステムとは異なる方法で解釈しようとします。
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.
列挙では、ereサブフィールドには、操作するアプリケーションの一意の文字列にこれが含まれるため、リテラル文字 ''が含まれる場合があります。ただし、存在する場合は、「サブストリング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の例は正しくありません： * in naptr 100 10 "u" "e2u sip" "！^ 4655（。 *）$！sip：\\ 1@example.net！"。
A correct way to write this example is: * IN NAPTR 100 10 "u" "E2U+sip" "!^\\+4655(.*)$!sip:\\1@example.net!" .
この例を書く正しい方法は次のとおりです。 * in naptr 100 10 "u" "e2u sip" "。
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マスターファイルの構文に表示されている場合（上記の例のように）、2番目のバックスラッシュを使用してバックスラッシュ自体を逃れる必要があることに注意してください。DNSオンザワイヤパケットには、単一のバックスラッシュしかありません。
An ENUM client MAY discard a NAPTR received in response to an ENUM query because:
列挙クライアントは、列挙クエリに応じて受け取ったNAPTRを廃棄する場合があります。
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には、列挙で使用されている「E2U」とは異なる（空の非）DDDSアプリケーション識別子があります。
o the NAPTR's ERE does not match the Application Unique String for this ENUM query,
o naptrのereは、この列挙クエリのアプリケーションの一意の文字列と一致しません、
o the ENUM client does not recognise any Enumservice held in this NAPTR, or
o ENUMクライアントは、このNAPTRに保持されているenyserviceを認識していません。
o this NAPTR (only) contains an Enumservice that is unsupported.
o このNAPTR（のみ）には、サポートされていない絡み合いが含まれています。
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).
これらの条件は、列挙クエリ全体を終了させるものではなく、処理は返されたリソースレコードセット（RRSet）の次の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.
列挙クライアントが化合物Naptr（つまり、複数のEnumserviceを含むもの - セクション4.4.1も参照）に遭遇し、その中のencervicesのいずれかを処理できないか、認識できない場合、そのenumクライアントはこの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を生成するときに、通常の発現処理を使用します。正規表現のすべての使用と同様に、この出力を生成する際にバッファオーバーランの可能性があります。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.
列挙クライアントが通常、短いURIを持つNaptrのみに遭遇する場合でも、REPLサブフィールドに繰り返し逆委員会パターンを備えたNaptrsを受け取る可能性があり、クライアントのバッファよりも長く文字列を生成できます。このようなNaptrsは、誤ってまたは設計により誤解されている可能性があります。この場合、クライアントは失敗してはなりません。列挙クエリ全体を破棄するのではなく、代わりにこのオーバーランを引き起こしたであろう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参照に従うことにより）、列挙クエリは放棄されるべきではありませんが、代わりに、指定された非末端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 clients have been known to discard NAPTRs in which the Services field holds more than one Enumservice.
Enumクライアントは、サービスフィールドが複数のEnamserviceを保持しているNaptrを破棄することが知られています。
ENUM clients have also been known to discard NAPTRs with a "non-greedy" ERE sub-field expression (i.e., EREs that are dissimilar to "^.*$").
列挙クライアントは、「非グリーディ」ereサブフィールド式（つまり、「^。*$」とは異なるeres）でnaptrを破棄することも知られています。
ENUM clients have been known to discard NAPTRs that do not use '!' as their Regexp delimiter character.
列挙クライアントは、「！」を使用しないNaptrを破棄することが知られています。regexpデリミッター文字として。
ENUM clients have been known to discard NAPTRs in which the delimiter is NOT the last character in the Regexp field.
列挙クライアントは、デリミッターがregexpフィールドの最後のキャラクターではないNaptrを破棄することが知られています。
ENUM clients have been known to discard NAPTRs with an empty Flags field (i.e., "non-terminal" NAPTRs).
列挙クライアントは、空のフラグフィールド（つまり、「非末端」Naptrs）でNaptrを破棄することが知られています。
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クライアントは、順序フィールド値を完全に無視し、優先/優先度のフィールド値のみに基づいてrrsetでnaptrsを並べ替えることが知られています。
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アプリケーションであり、RRSet内のNAPTRが処理される方法はこれを反映しています。詳細については、[RFC3402]のセクション3.3で説明しています。クライアントは、受信したレコードをシーケンスにソートし、そのシーケンスでそれらのレコードを処理することが期待されます。シーケンスは、各NAPTRSの順序と優先度/優先度のフィールド値を反映しています。
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.
順序フィールド値は、主要な、または最も重要なソート用語であり、優先順位/優先度のフィールド値はマイナーな、または最も重要なソート用語です。順序と優先度/優先度のフィールド値の組み合わせは、このデータの出版社によって選択されたシーケンスを示し、NAPTRはこのシーケンスで考慮されます。
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.
NAPTRがシーケンスに分類されると、さらに処理が行われ、各NAPTRがこの列挙評価に適しているかどうかを判断します。これには、フラグフィールドを見ることが含まれます。フラグフィールドが空の場合、これは「非末端」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が列挙を目的としていることを確認します（つまり、このnaptrには「e2u」が含まれていることが含まれています。サービスフィールドのDDDSアプリケーション識別子）。regexpフィールドのEREがチェックされ、この列挙評価（照会された電話番号）のアプリケーション一意の文字列（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 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.
この処理中に、クライアントはサービスフィールド内のencresvicesも検討します。Enumservicesは、このNAPTRが生成するURIを使用することで達成できる相互作用の種類を示します。NAPTRにはサポートされていないか認識されていない酵素サービスのみが含まれているというローカルな知識がある場合、このNAPTRを破棄し、次のNAPTRを順番に処理できます。したがって、SIP相互作用のみをサポートするシステムの場合、「最良の」NAPTRがH323 Enumserviceを示すRRSetを受信する場合、そのクライアントはその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.
順序と優先度/優先度のフィールドの処理は、混乱の重要な原因であり、多くの列挙クライアントは指定されたとおりに処理を実装していません。
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).
特に、多くの列挙クライアントは、列挙処理中に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レコードに異なる注文値がある場合、この動作は非準拠です。列挙アルゴリズム（[RFC3402]のセクション3.3および[RFC3403]のセクション4.1）は、アプリケーションの一意の文字列（AUS）で一致が見つかると、サービスの説明はクライアントの要件を満たすと述べています。考慮してはなりません（ただし、同じ注文値を持つ他の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.
ただし、列挙評価プロセス内にURIに関するローカル知識を埋め込むことは、列挙を使用しているシステムではほぼ普遍的です。また、順序と優先度/選好の違いは不明であるため、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.
列挙仕様が更新されると、このドキュメントで説明されている実装と展開の経験に基づいて、順序と優先度/設定の処理を更新する必要があることが提案されています。
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レコードは、やや不明確なコーナーケースを説明することを目的としており、列挙プロビジョニングの実行方法の良い例として意図されていません。
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!" .
英国のドラマの数字を1つのサーバーにマップし、他のすべての数字を2番目のサーバーにマップする次のRRSetを考えてみましょう： * 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！"。
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]で指定された処理によると、列挙クライアントは、「SIPS」ウリス、またはアトランタの例をサポートしていなくても、「441632960123」の2番目のルールを考慮することを意図していません。comサーバーに到達できないか、ユーザーはatlanta.example.comに連絡したくないことを示します。ただし、既存の列挙の実装はこれを行うことが知られており、上記のように、代替がまったく通信できない場合に役立ちます。
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!" .
クライアントが英国のドラマ範囲の2番目のルールを考慮しないようにするために、次のようにより予測可能な動作をするように例を書き直すことができます： * 3600 in Naptr 1 1 "U" "e2u sip" "！^^（\\ 441632960. *）$！sips：\\ 1@atlanta.example.com！ "。*3600 in naptr 2 1 "u" "e2u sip" "！^（\\ [^4]。*| \\ 4]。*| \\ 44 [^1]。*| \\ 441 [^6]。*| \\ 4416 [^3]。*| \\ 44163 [^2]。*| \\ 441632 [^9]。*| \\ 4416329 [^6]。*| \\ 44163296 [^0]。*）$！sip：\\ 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]および[RFC3403]は、列挙クライアントがオーダーフィールド値（「最低値が最初」）を使用してNAPTRをソートする必要があることを述べています。最初に値）。ソートされたリストのNAPTRは、順番に処理する必要があります。より悪い順序値を持つその後のNAPTRは、より良い注文値を持つ現在のものが処理された後にのみ対処する必要があります。
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.
ただし、このセクションの紹介で説明されているように、この述べられた行動は単純化です。順序と優先度/優先度の値を反映したシーケンスに分類されると、取得したNAPTRの評価中に他のフィールドも考慮されます。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クライアントには、エンドユーザー「Decision Loop」を含めることもできます。これは、可能なNAPTRのリストからエンドユーザーに選択を提供します。概念的には、この選択はDDDSアルゴリズムのステップ4に埋め込まれています（[RFC3402]のセクション3.3で説明されています）。注文フィールド値が主要な並べ替え用語であることを考えると、Complorming Enumクライアントは、これらのNAPTRのみを選択して選択肢として現在の「最良の」注文フィールド値のみを提示することを期待します。提示されたすべてのオプションが拒否された場合、列挙クライアントは「次の最高の」注文フィールド値などを提供する場合があります。これはエンドユーザーにとって混乱を招く可能性があるため、一部のクライアントは、順序と優先/優先度フィールドで定義されたシーケンスで、利用可能なすべてのNAPTRをエンドユーザーに一度に選択するオプションとして単に提供するだけです。
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クライアントは、サービスフィールド値、Flagsフィールド、およびregexp 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クライアントに依存すべきではありません。
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.
具体的には、より良い注文値がある場合、列挙クライアントが別のNAPTRを考慮しないと仮定するのは安全ではありません。[RFC3403]のセクション4.1およびセクション8の指示には、完全に正当な理由で、異なる列挙クライアントが厳密に従うことがある場合とされない場合があります。
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のリストを提示している場合、登録者が指定した順序と優先/優先度の値によって定義されたシーケンスでそれを行う必要があります。
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.
ただし、登録者は自分のゾーンのみに配置する必要があります。最悪の順序と好み/優先度の値を持つ人でさえ、エンドユーザーが選択することができます。
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.
誤った順序値を保持する列ゾーンのNaptrsは、大きな問題を引き起こす可能性があります。[RFC3403]順序と優先度/優先度の両方のフィールドを持つことは、NAPTRリソースレコードタイプの歴史的アーティファクトであることを強調しています。優先順位を示すために設定/優先度フィールドに依存して、注文フィールドに共通のデフォルト値を持つことが合理的です。
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.
同一の好み/優先度のフィールド値と異なる順序値を持つNAPTRを持つ多くの列挙ドメインに気付きました。これは、Enum Zone Provisioning Systemの「バグ」または2つのフィールドの使用に関する誤解、または単に標準の解釈の違いの結果である可能性があります。
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.
明確にするために、注文フィールド値は主要な並べ替え用語であり、優先/優先度のフィールド値はマイナーな並べ替え用語です。したがって、同一の順序フィールド値と異なる好み/優先フィールド値を持つゾーンに一連のNAPTRがあることを期待する必要があります。その逆ではありません。
To avoid these common interoperability issues, it is recommended that ENUM NAPTRs SHOULD hold a default value in their ORDER field.
これらの一般的な相互運用性の問題を回避するには、Enum Naptrsが注文フィールドにデフォルト値を保持することをお勧めします。
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.
経験から、同一の順序と同一の優先順位/優先度のフィールド値を持つ離散NAPTRを保持するゾーンがあることがわかっています。これにより、クライアントの動作が不確定になるため、通常は発生しないでください。
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.
このような条件は、これらのNAPTRが優先順位がまったく同一であり、これらのNAPTRが提供するサービス間に好みがないことを示しています。実装者は、DNSが特定のシーケンスでRRSET内の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.
同一の順序と同一の優先順位/優先度のフィールド値を持つ複数のNAPTRは、これらのnaptrが優先順位が真に同一であり、それらの間に優先度がないという意図がない限り、RRSetにプロビジョニングされるべきではありません。
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.
一部の列挙クライアントの実装では、このケースはエラーであると考えており、そのような重複を完全に拒否しています。他の人は、そのような重複が処理される順序をさらにランダム化しようとしました。したがって、さまざまな方法で動作するクライアントの実装が存在するため、このような重複したNAPTRの使用は賢明ではありません。
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は同じregexpフィールドを共有するため、同じURIを生成します。このような「化合物」NAPTRは、「Voice：Tel」と「SMS：Tel」Enamservicesの両方をサポートする携帯電話を示すために使用できます。その場合のサービスフィールドは、「E2U音声：Tel SMS：Tel」です。
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は、それぞれが単一のencresviceを保持する一連のNAPTRとして扱うことができます。これらの再構築されたNAPTRSは、同じ順序と優先度/優先度のフィールド値を共有しますが、それぞれが論理的に異なる優先度を持っているかのように扱う必要があります。この場合、化合物NAPTR内の左端のエナムサービスを保持する再構築されたNAPTRの優先順位が最善であり、右端のエンマムサービスを保持する再構築された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.
不確定な動作を避けるために、列挙クライアントは、左から右へのシーケンスで複合NAPTR内のエンスムサービスを処理することをお勧めします。列挙プロビジョニングシステムは、そのような処理順序が使用され、それに応じて複合NAPTR内のエンスムサービスをプロビジョニングする必要があります。
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.
異なるドメインで異なるオーダーフィールド値を使用することは、ほとんどのクエリでは重要ではありません。ただし、DDDSには、「非末端」NAPTRに他のドメインへの参照を含めることにより、別のドメインでNAPTRの検索を継続するためのメカニズムが含まれています。非末端NAPTRSの治療は、次のセクションで説明します。それらがサポートされている場合、その順序と優先度/優先度のフィールド値の処理方法が影響を受けます。
Two main questions remain from the specifications of DDDS and [RFC3761]:
2つの主な質問は、DDDと[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?
o 非末端NAPTRによって言及されているドメインに異なる（低い）順序フィールド値がある場合、これは列挙クライアントが参照RRSETに残っているNAPTRを破棄することを意味しますか？
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によって参照されるドメインに、高次フィールド値のみがあるエントリが含まれている場合、列挙クライアントは参照されたドメイン内のそれらのNAPTRを無視しますか？
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つは、両方の質問に対する答えは「はい」であるということですが、これは存在する非末端NAPTR（およびそれらをサポートする列挙クライアント）の例が設計されているように見えるという方法ではありません。
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.
これまでに作成された解釈に沿って、列挙の実装は、列挙クエリで現在処理されているドメインのコンテキスト内でのみ、順序と優先度/優先度の値を考慮する必要があります。これらの値は、クエリ内の他の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レコードを含む列挙rrsetを考えてみましょう。この非末端NAPTRは、そのターゲットとして、一連のNAPTRを持つ別のドメインを保持します。実際、これは、指を指すドメインに含まれるNAPTRに置き換えられている非末端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によって指摘されることが可能です。したがって、ドメインのセットは「チェーン」を形成し、考慮すべきNAPTRのリストは、そのチェーン内のすべてのドメインに含まれるすべてのNAPTRのセットです。
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.
非末端NAPTRSをサポートする列挙管理システムの場合、現在の列挙ドメインのNAPTRだけでなく、非末端NAPTRSが参照しているドメインだけでなく、分析、検証、および（必要に応じて）修正できるようにする必要があります。他のドメイン。ドメインが独自の非末端NAPTRを持っていると指摘した場合、管理システムは、「メイン」列挙ドメインのクエリの結果の一部を形成するため、参照される各ドメインを順番にチェックする必要があります。参照されたドメインのドメインコンテンツは、列挙管理システムの制御下にない可能性があるため、それらのrrsetのエラーを修正することはできない場合があります。これは複雑であり、管理システムの設計でエラーが発生する傾向があり、検証の報告されたエラーはユーザーにとって直感的ではない場合があります。
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.
列挙クライアントの場合、非末端NAPTRをサポートすることも難しい場合があります。非末端NAPTRSを処理すると、不確定な時間をとることができる一連の順次DNSクエリが発生し、非末端ループなどの障害条件を処理するために追加のリソースと複雑さが必要です。応答時間の不確定性により、列挙されたテレフォニーアプリケーションが困難になります（「列挙された」プライベートブランチ交換（PBX）など）。電話。
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は、それが指すドメイン内のNAPTRに置き換えることができますが、非末端NAPTRのサポートは必要ありません。非末端NAPTRは役に立たない場合があります。さらに、一部の既存のENUMクライアントは、非末端NAPTRをサポートせず、受け取った場合は無視します。
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.
相互運用性の問題を回避するには、非末端NAPTRについて何らかの許容できるアドバイスが必要です。現在のサポートが限られているため、この環境がサポートするすべての列挙クライアントがこれらを処理できることが明らかでない限り、非末端NAPTRを列挙で使用しないでください。
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.
特定の環境で非末端NAPTRがサポートされる場合は、以下の特定の問題を考慮する必要があります。これらの問題は経験から収集され、非末端NAPTRSのサポートが考慮される前に考慮すべき条件の種類を示しています。これらの問題は、列挙のプロビジョニングまたは管理システムの複雑さで言及されたポイントと、その管理システムが管理されたゾーンの非末端NAPTRが参照するゾーンの内容を制御できない可能性に追加されていることに注意してください。
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.
前述のように、1つのRRSetの非末端NAPTRは、別のドメインに含まれるNAPTRを指します。非末端NAPTRによって参照されるドメイン内のNAPTRは、参照非末端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のチェーンが現在のクエリですでに通過しているドメインを参照する場合、「非末端」または参照ループが暗示されています。実装は、単一の列挙クエリ中に通過した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.
このようなループを検出するために使用できる多くの手法がありますが、現在の列挙クエリでクエリされたドメインの数をカウントする簡単なアプローチで十分です。
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.
DDDとそのアプリケーションを定義する一連の仕様は複雑で多層的です。これは、システムが提供する柔軟性を反映していますが、特に非ターミナルルールが関係する場合、仕様の一部が解釈に関して明確化が必要であることを意味します。
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で）定義されています。
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.
フラグフィールドは、列挙処理で遭遇する非末端NAPTRで空になります。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]は、エンマムサービス仕様には、このencresviceの予想出力であるURIの定義が必要であると述べています。これは、現時点では、非ターミナルであるencresviceを指定する方法がないことを意味します。このような非末端NAPTRには、定義上、予想出力としてURIがありません。代わりに、DDDS処理の「次のラウンド」で使用されるキー（DNSドメイン名）を返します。
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.
これは、列挙で使用された場合、非末端NAPTRが有効な（空の）サービスフィールドを保持できないことを意味します。[RFC3761]のセクション2.4.2は、このフィールドコンテンツの構文を指定し、<servicesPec>の少なくとも1つの要素を必要とします（つまり、少なくとも1つのEnmumservice識別子）。非末端のエンムサービスが存在できないことを考えると（したがって、そのような登録されたEnumservice識別子はありません）、この構文は非末端NAPTRで満たすことはできません。このフィールドに入れることのない非末端のエンムサービスはありません。
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.
既存の実装に合わせて、列挙クエリで遭遇した非末端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).
もちろん、空のサービスフィールドを持つこのような非末端NAPTRは、DDDSアプリケーションに固有のものではありません。したがって、他の手段を使用して、特定のDDDSアプリケーションにのみ意図されている非末端NAPTRを確認する必要があります。たとえば、同じドメインがNAPTRをホストするために使用されないことを確認することで複数のそのようなDDDSアプリケーション）。
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でフィールドをどのように使用するかを説明することを目的としています。ただし、正規表現と交換要素に関連する説明は、非末端NAPTRを扱うときにこれらのどれを考慮すべきかについての混乱をもたらしました。
[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つの要素は相互に排他的です。これは、regexp要素が空でない場合、交換要素が空でなければならず、逆もまた同様でなければならないことを意味します。ただし、[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 Regexp要素の記述テキストの最初の段落は、ある程度の混乱をもたらしました。regexp要素は、「ルックアップの次のドメイン名」を見つけるために使用されるようです。これは、DDDSアプリケーションを処理するクライアントプログラムが各非末端NAPTRを調べて、regexp要素を使用して、次に使用するキー（ドメイン名）を構築するために交換要素を使用する必要があるかどうかを決定する必要があることを意味する場合があります。非末端ルール処理。
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アプリケーションの予想出力を生成する必要があるため、Regexp要素もそのようなルールで使用されます。実際、そのDDDSアプリケーションに端子出力としてドメイン名がない限り、Regexp要素が唯一の可能性です。
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」）を保持しているNAPTRでのみ置換要素を使用できます。regexp要素は、非末端の場合に使用される次のキーとしてドメイン名を生成するか、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アプリケーションは、そのアプリケーションで使用するフラグのセットを自由に指定できることに注意してください。これには、特定のフラグが端末ルールまたは非末端ルールに関連付けられているかどうかを指定すること、つまり、空のフラグフィールドの解釈を指定することも含まれます（つまり、これが端末ルールまたは非末端ルールとして解釈されるかどうか、端子ですが、予想される出力は何ですか）。enum（[RFC3761]のセクション2.4.1で指定されているように）は、「u」フラグのみを使用し、非末端NAPTRを示す空のフラグフィールドがあります。
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つの要素のどれを確認する必要がある一般的なケースは、実装を複雑にし、この解釈は現在の列挙の実装では行われていません。クライアントプログラムがRegexp要素を処理することを期待できる時期と、堅牢性を向上させるためだけに交換要素を処理することを期待する時期を正確に定義することは便利です。regexpフィールドから列挙ドメイン名を生成することは、変動する長さの電話番号、または9桁以上の一般的な電話番号では、せいぜい困難であり、不可能です。したがって、列挙仕様が更新されると、このオプションは非推奨であり、非末端列挙のnaptrsにregexpフィールドを使用することが禁止されることが提案されています。
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.
現在の実装に沿って、非末端酵素NAPTRのターゲットドメインは、（空の）交換場に配置する必要があります。このフィールドは、この非末端ルールから次のキー出力を形成するドメイン名を保持すると解釈する必要があります。逆に、列挙処理で遭遇する非末端NAPTRでは、regexpフィールドが空でなければならず、列挙クライアントはそのコンテンツを無視する必要があります。
[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アプリケーションをサポートするNAPTRの構文の現在の標準です。これは、[RFC2916]で与えられた元の仕様を廃止します。RFC 3761は、列挙処理の概念の改良を反映する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アプリケーションに相当）がありました。DDDS識別子または解像度サービスの同じ識別子文字列は、[RFC3761]と[RFC2916]仕様の両方で定義されています：「E2U」。
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つではあるが潜在的に複数のencresviceサブフィールドを定義します。時代遅れの仕様では、1つの「プロトコル」サブフィールドのみが許可されました。
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つ以上のencerserviceサブフィールドが続くことを指定します。[RFC2916]は、プロトコルサブフィールドが左端であることを指定し、その後に「Delimiterが続き、その後に「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.
[RFC2915]および[RFC2916]は、[RFC3401] - [RFC3404]および[RFC3761]によって廃止されています。ただし、[RFC3824]は、ENUMクライアントを廃止された構文でNAPTRを受け入れる準備をする必要があることを示唆しています。したがって、Enumクライアントの実装は、両方のフォームに対処する必要がある場合があります。これは難しいことではありません。たとえば、実装により、サービスフィールドを一連のトークンに処理し、これらのトークンの1つが「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].
要約するには、[RFC3761]の構文に従って、列挙クライアントはenum naptrsをサポートする必要があります。列挙クライアントは、[RFC2916]の時代遅れの構文に従ってenum naptrsをサポートする必要があります。「古い」構文naptrsを保持するゾーンがまだあります。列挙ゾーンは、時代遅れのフォームに従ってNAPTRSでプロビジョニングする必要はなく、[RFC3761]に従ってサービスフィールドがあるNAPTRでプロビジョニングする必要があります。
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 Naptrsは、印刷可能なUS-ASCII同等の範囲（U 0020からU 007E）の外側の文字を含めるべきではありません。Enum Zone Provisioning Systemsに非ASCII文字が必要な場合、これらのシステムは、適切なメカニズム（[RFC3492]、[RFC3987]）を適用することにより、非ASCIIデータのみをEMIT US-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'）は列挙には不適切であり、E2U NaptrsのRegexpフィールドにプロビジョニングするべきではありません。
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their Regexp delimiter character.
enumゾーンプロビジョニングシステムは「！」を使用する必要があります。（u 0021）regexpデリミッター文字として。
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.
RegexpデリミッターがREPLサブフィールドの静的テキストの文字である場合、[RFC3402]のセクション3.2に示されているBNF仕様の脱出されたデリミッター生産を使用して「脱出」する必要があります（つまり、 "\！"、U 005C U 0021）。NAPTRリソースレコードがDNSマスターファイルの構文に入力されている場合、2番目のバックスラッシュを使用してバックスラッシュ自体を脱出する必要があることに注意してください。
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マスターファイルの構文に入力されている場合、2回目のバックスラッシュを使用してバックスラッシュ自体を逃れる必要があることに注意してください。
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 naptrsの注文の価値と優先/優先フィールドのみを考慮して、列挙クライアントに依存してはいけません。したがって、登録者は自分のゾーンにのみゾーンのみを配置する必要があります。最悪の順序と好み/優先度の値を持つ人でさえ、エンドユーザーが選択することができます。
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.
プロビジョニングされた列挙ゾーンでは、順番と優先度/優先度の値の多くの明らかな間違いが検出されています。これらの一般的な相互運用性の問題を回避するために、プロビジョニングシステムは、リソースレコードセット（RRSet）でNAPTRの異なる順序フィールド値を使用しないでください。一般化するには、すべてのEnum Naptrsが注文フィールドにデフォルト値を保持する必要があります。ほとんどのプロビジョニングドメインで使用されているように見えるため、「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.
同一の順序と同一の優先順位/優先度のフィールド値を持つ複数のNAPTRは、これらのNAPTRが本当に同一であり、それらの間に優先度がないという意図がない限り、RRSetにプロビジョニングされるべきではありません。実装者は、DNSが特定のシーケンスでRRSET内の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を生成する場合、encervicesは通常、そのようなNaptr内で左から右に処理されると想定する必要があります。
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).
Enum Zone Provisioning Systemsは、処理のために非末端NAPTRが選択されたら、その非末端NAPTRによって言及されるドメインの順序フィールド値は、その参照ドメインのコンテキスト内でのみ見なされると想定する必要があります（つまり、、注文値は、現在のRRSET内のソートにのみ使用され、他のRRSETのNAPTRの処理には使用されません）。
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.
このクライアントの動作は非準拠ですが、列挙プロビジョニングシステムとそのユーザーは、一部の列挙クライアントが、自明でない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.
列挙プロビジョニングシステムは、プロビジョニングする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.
現在のサポートが限られているため、非末端NAPTRは、この環境がサポートするすべての列挙クライアントがこれらを処理できることが明らかでない限り、列挙ゾーンにプロビジョニングされるべきではありません。
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つ以上のそのようなNAPTRが列挙クエリで処理されるように、非末端NAPTRを構成する必要はありません。
In a non-terminal NAPTR encountered in an ENUM query (i.e., one with an empty Flags field), the Services field SHOULD be empty.
列挙クエリ（つまり、空のフラグフィールドを持つもの）で遭遇した非末端NAPTRでは、サービスフィールドは空にする必要があります。
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には、（空の）交換場にターゲットドメインを含める必要があります。このフィールドは、この非末端ルールから次のキー出力を形成するドメイン名を保持すると解釈する必要があります。Regexpフィールドは、列挙クエリ中に遭遇することを目的とした非末端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].
列挙ゾーンは、時代遅れのフォームに従ってNAPTRSでプロビジョニングする必要はなく、[RFC3761]に従ってサービスフィールドがあるNAPTRでプロビジョニングする必要があります。
ENUM clients SHOULD NOT discard NAPTRs in which they detect characters outside the US-ASCII printable range (0x20 to 0x7E hexadecimal).
列挙クライアントは、US-ASCIIの印刷可能な範囲外（0x20〜0x7Eヘキサデシマル）の外側の文字を検出するNaptrを破棄してはなりません。
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.
列挙クライアントは、フラグ、サービス、または米国ASCII同等の範囲外（つまり、0x7Fを超えるバイト値）の外側にバイト値を持つReGEXPフィールドにオクテットを持つNAPTRを破棄できます。クライアントは、失敗することなく、そのような価値でNaptrsに遭遇する準備ができている必要があります。
ENUM clients SHOULD NOT assume that the delimiter is the last character of the Regexp field.
列挙クライアントは、区切り文字がregexpフィールドの最後の文字であると想定してはなりません。
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.
彼らが彼らの環境でこれが事実であると確信していない限り、一般に、列挙クライアントは、そのフラグがまったく効果がないにもかかわらず、次の「I」（ケース非感受性）フラグでプロビジョニングされたNaptrに遭遇する可能性があります。列挙シナリオ。
ENUM clients SHOULD discard NAPTRs that have more or less than 3 unescaped instances of the delimiter character within the Regexp field.
列挙クライアントは、regexpフィールド内の区切り文字の3つの無効なインスタンスを多少未満のNAPTRを破棄する必要があります。
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.
列挙クライアントがregexpフィールドをどのように解釈するかを確信している場合、それが受け入れるものにリベラルであるという精神で、誤った数の非脱型のデリミタ文字に直面してもNAPTRを処理することを選択するかもしれません。regexpフィールドをどのように解釈するかが明確でない場合、クライアントは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.
Enumクライアントが自分の選択のために可能なURLのリストをエンドユーザーに提示する場合、すべてのNAPTRを提示する可能性があります - 現在最高の未処理の注文フィールド値を持つものだけでなく。クライアントは、登録者が指定した注文と優先順位/優先度の値を維持する必要があります。
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クライアントは、すべてのNAPTRを同一の順序と同一の優先順位/優先フィールド値で受け入れ、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.
化合物NAPTRを受け取るクライアント（つまり、複数のEnumserviceを備えたクライアント）は、左から右へのソート順序を使用してこれらのエンスムサービスを処理する必要があります。一。
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.
Enumクライアントは、単一のRRSet内でNAPTRをソートする場合にのみ、注文フィールド値を考慮する必要があります。非末端NAPTR参照のトラバーサルによって作成されたDNSクエリのシーケンス全体でNAPTRを処理する場合、順序フィールド値を考慮しないでください。
ENUM clients MUST be ready to process NAPTRs that use a different character from '!' as their Regexp Delimiter without failure.
enumクライアントは、「！」とは異なる文字を使用するNAPTRを処理する準備ができている必要があります。故障せずにregexpデリミッターとして。
ENUM clients MUST be ready to process NAPTRs that have non-trivial patterns in their ERE sub-field values without failure.
Enumクライアントは、誤解せずにサブフィールド値に自明でないパターンを持つNAPTRを処理する準備ができている必要があります。
ENUM clients MUST be ready to process NAPTRs with a DDDS Application identifier other than 'E2U' without failure.
Enumクライアントは、失敗することなく「E2U」以外のDDDSアプリケーション識別子でNAPTRを処理する準備ができている必要があります。
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クライアントは、障害なしにREPLサブフィールド内のバックリファレンスパターンの多くのコピーを使用してNAPTRを処理する準備ができている必要があります（セクション3も参照）。
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が破棄された場合、これにより、列挙クエリ全体が終了し、処理が返されたリソースレコードセット（RRSET）の次の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.
列挙クライアントが化合物Naptr（つまり、複数のencerviceを含むもの）に遭遇し、その中のencervicesの1つを処理できないか、または認識できない場合、enumクライアントはこのencerviceを無視し、このNAPTRのサービスフィールド内の次のenyserviceを継続する必要があります。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をサポートする必要があります。列挙クライアントは、[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クライアントは、空のフラグフィールド（「非末端」NAPTRS）を使用してNAPTRSを障害なく処理する準備ができている必要があります。より一般的には、非末端NAPTR処理を実装する必要がありますが、列挙クライアントは遭遇する非末端NAPTRを破棄する場合があります。
ENUM clients SHOULD ignore any content of the Services field when encountering a non-terminal NAPTR with an empty Flags field.
Enumクライアントは、空のフラグフィールドで非末端NAPTRに遭遇したときに、サービスフィールドのコンテンツを無視する必要があります。
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.
空のフラグフィールドを使用して非末端NAPTRを受信する列挙クライアントは、列挙クエリの次のラウンドで使用されるドメイン名を保持するものとして交換フィールドを扱う必要があります。列挙クライアントは、交換場が空であるか、有効なドメイン名が含まれていない場合、そのような非末端NAPTRを破棄する必要があります。定義上、そのような非末端NAPTRでは、regexpフィールドが空になることになります。非末端NAPTRに存在する場合、空白のないregexpフィールドは、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参照に従うことにより）、列挙クエリは放棄されるべきではありませんが、代わりに、指定された非末端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).
非末端NAPTRの参照の結果として通過したドメイン内のすべてのNAPTRが破棄された場合、列挙クライアントは「参照」RRSETの次の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.
列挙クライアントは、参照ループが入力されていることを示すものとして、単一の列挙クエリで横断された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での参照の結果としてドメインが入力されようとしている場合、列挙クライアントは潜在的な参照ループを検出しました。リスト内の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.
このドキュメントの推奨事項のセキュリティへの影響に加えて、列挙の基本的な使用（およびこのプロトコルの規範的なドキュメントで指定されている）も考慮する必要があります。このドキュメントは、それらを決して否定しません。
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の提案は、既知のセキュリティ脅威に対する有効なアプローチです。クライアントに過剰な処理やメモリの使用を引き起こす際に、攻撃者に利点をもたらすことはありません。ただし、クライアントがこれをループとして検出する前に、列挙クライアントが2つのドメインで5回の非末端NAPTRの「タイトループ」を横断することを意味します。これは、他の方法を使用して提供されるよりもわずかに高い処理負荷を導入しますが、彼らが発生するリスクを回避します。
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を生成します。これはDDDの標準的な機能ですが、REPLサブフィールドに複数の背面パターンを備えた「非グリーディ」の正規表現の使用は、バッファーオーバーラン攻撃の可能性を生み出します。プロビジョニングシステム設計者はこれに注意する必要があり、逆リファレンス置換パターンの繰り返しの使用を制限する必要があります。逆に、列挙クライアントの実装者は、逆委員会を含む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.
特に、リチャード・スタストニーが同様のタスクでの努力をしてくれたことに感謝します。TS102172 [ETSI-TS102172]のETSIの下で、そして今日存在する列挙の実装の一部をサポートしてくれました。
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.
最後に、Michael Meallingの献身に感謝します。このような詳細なDDDS仕様を提供します。それなしでは、列挙開発の取り組みには、構築するためのより厳格なフレームワークがありました。このドキュメントは、[RFC3401] - [RFC3404]の複雑さとそれらに入った作業なしで、システムがどれほど複雑であるかを反映しています。相互運用性を確保することは非常に困難でした。
[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：シェルとユーティリティ（Vol。1）」、IEEE Standard 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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。、「Dynamic Delogation Discovery System（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）パート4：ユニフォームリソース識別子（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。、「Dynamic Delogation Discovery System（DDDS）パート5：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.、Hoffman、P。、およびA. Costello、「アプリケーションの国際化ドメイン名（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] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、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。and M. Mealling、「E.164へのユニフォームリソース識別子（URI）動的委任ディスカバリーシステム（DDDS）アプリケーション（ENUM）」、RFC 3761、2004年4月。
[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] Berners-Lee、T.、Fielding、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、「国際化されたリソース識別子（IRIS）」、RFC 3987、2005年1月。
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII] American National Standards Institute、「コード化された文字セット-7ビットの情報インターチェンジのためのアメリカ標準コード」、ANSI X3.4、1986。
[ETSI-TS102172] ETSI, "Minimum Requirements for Interoperability of European ENUM Implementations", ETSI TS 102 172, October 2004.
[ETSI-TS102172] ETSI、「ヨーロッパの列挙実装の相互運用性に関する最小要件」、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。and R. Daniel、「The Naming Authority Pointer（NAPTR）DNS Resource Record」、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）パート1：包括的な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] Peterson、J.、Liu、H.、Yu、J。、およびB. Campbell、「セッション開始プロトコル（SIP）でE.164番号を使用」、RFC 3824、2004年6月。
Authors' Addresses
著者のアドレス
Lawrence Conroy Roke Manor Research Roke Manor Old Salisbury Lane Romsey United Kingdom
ローレンスコンロイロークマナーリサーチロークマナーオールドソールズベリーレーンロムジーイギリス
Phone: +44-1794-833666
EMail: 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
Kazunori Fujiwara Japan Registry Services Co.、Ltd。Chiyoda First Bldg。イースト13F 3-8-1西カンダチヨーダ - クー東京101-0165日本
EMail: fujiwara@jprs.co.jp
URI: http://jprs.co.jp/en/