[要約] RFC 2915は、NAPTR DNSリソースレコードの定義と使用方法に関するものであり、電話番号や電子メールアドレスなどの識別子を特定のサービスに関連付けるために使用されます。目的は、識別子の解決とサービスの選択を効率的に行うことです。
Network Working Group M. Mealling
Request for Comments: 2915 Network Solutions, Inc.
Updates: 2168 R. Daniel
Category: Standards Track DATAFUSION, Inc.
September 2000
The Naming Authority Pointer (NAPTR) DNS Resource Record
命名権限ポインター（NAPTR）DNSリソースレコード
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer (NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
このドキュメントでは、既存の文字列に適用すると、新しいドメインラベルまたはユニフォームリソース識別子（URI）が生成されるという正規表現ベースの書き換えルールを指定するドメイン名システム（DNS）リソースレコードについて説明します。リソースレコードのフラグフィールドの値に応じて、結果のドメインラベルまたはURIは、命名権限ポインター（NAPTR）リソースレコードの後続のクエリで使用される可能性があります（名前検索を削除するため）、またはプロセス全体の出力として使用できます。このシステムが使用されています（URI解像度の解像度サーバー、EnumスタイルE.164番号のURIマッピングなどのサービスURI）。
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.
これにより、DNSを使用して、ドメイン名構文にないさまざまなリソース名（URIを含む）のサービスを検索することができます。これを行う理由は、URNリソースディスカバリーシステムから、時代遅れのサービスの移動に至るまで、新しいドメインに移行します。
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.
このドキュメントでは、NAPTRレコードの定義と、他の非uri固有のアプリケーションの定義を具体的に扱うRFC 2168の一部を更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3
3. Substitution Expression Grammar . . . . . . . . . . . . . . 7
4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8
5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9
6. Application Specifications . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13
9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14
10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
This RR was originally produced by the URN Working Group [3] as a way to encode rule-sets in DNS so that the delegated sections of a URI could be decomposed in such a way that they could be changed and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name. Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet.
このRRはもともと、URIのルールセットをエンコードする方法としてURNワーキンググループ[3]によって生成されたため、URIの委任されたセクションを、時間の経過とともに変更して再配分できるように分解できます。結果は、クライアントプログラムで使用される正規表現を含むリソースレコードで、文字列をドメイン名に書き換えました。コンパクトさと表現率の比率のために正規表現が選択され、かなり小さなDNSパケットで多くの情報をエンコードできるようになりました。
The function of rewriting a string according to the rules in a record has usefulness in several different applications. This document defines the basic assumptions to which all of those applications must adhere to. It does not define the reasons the rewrite is used, what the expected outcomes are, or what they are used for. Those are specified by applications that define how they use the NAPTR record and algorithms within their contexts.
記録のルールに従って文字列を書き換える機能は、いくつかの異なるアプリケーションで有用です。このドキュメントでは、これらのすべてのアプリケーションが順守しなければならない基本的な仮定を定義します。書き換えが使用される理由、予想される結果が何であるか、またはそれらが何に使用されるかを定義するものではありません。これらは、コンテキスト内でNAPTRレコードとアルゴリズムの使用方法を定義するアプリケーションによって指定されています。
Flags and other fields are also specified in the RR to control the rewrite procedure in various ways or to provide information on how to communicate with the host at the domain name that was the result of the rewrite.
フラグやその他のフィールドもRRで指定されており、さまざまな方法で書き換え手順を制御したり、書き直しの結果であるドメイン名でホストと通信する方法に関する情報を提供します。
The final result is a RR that has several fields that interact in a non-trivial but implementable way. This document specifies those fields and their values.
最終結果は、非自明であるが実装可能な方法で相互作用するいくつかのフィールドを持つRRです。このドキュメントは、これらのフィールドとその値を指定します。
This document does not define applications that utilizes this rewrite functionality. Instead it specifies just the mechanics of how it is done. Why its done, what the rules concerning the inputs, and the types of rules used are reserved for other documents that fully specify a particular application. This separation is due to several different applications all wanting to take advantage of the rewrite rule lookup process. Each one has vastly different reasons for why and how it uses the service, thus requiring that the definition of the service be generic.
このドキュメントは、この書き換え機能を利用するアプリケーションを定義しません。代わりに、それがどのように行われるかのメカニズムのみを指定します。なぜそれが行われたのか、入力に関するルール、および使用されるルールの種類は、特定のアプリケーションを完全に指定する他のドキュメント用に予約されています。この分離は、すべての異なるアプリケーションがすべてのルールルール検索プロセスを利用したいと考えているためです。それぞれには、サービスの使用と方法の理由が大きく異なる理由があるため、サービスの定義が一般的であることを要求しています。
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 RFC 2119.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されているとおりに解釈されます。
All references to Uniform Resource Identifiers in this document adhere to the 'absoluteURI' production of the "Collected ABNF" found in RFC 2396 [9]. Specifically, the semantics of URI References do not apply since the concept of a Base makes no sense here.
このドキュメントの均一なリソース識別子へのすべての参照は、RFC 2396 [9]で見つかった「収集されたABNF」の「絶対的な」生成を順守しています。具体的には、ベースの概念が意味がないため、URI参照のセマンティクスは適用されません。
The format of the NAPTR RR is given below. The DNS type code [1] for NAPTR is 35.
NAPTR RRの形式を以下に示します。NAPTRのDNSタイプコード[1]は35です。
Domain TTL Class Type Order Preference Flags Service Regexp Replacement
ドメインTTLクラスタイプ注文設定フラグサービスregexp交換
Domain The domain name to which this resource record refers. This is the 'key' for this entry in the rule database. This value will either be the first well known key (<something>.uri.arpa for example) or a new key that is the output of a replacement or regexp rewrite. Beyond this, it has the standard DNS requirements [1].
ドメインこのリソースレコードが参照するドメイン名。これは、ルールデータベースのこのエントリの「キー」です。この値は、最初によく知られているキー（<monething> .uri.arpaなど）または交換またはregexpの書き換えの出力である新しいキーのいずれかです。これを超えて、標準のDNS要件があります[1]。
TTL Standard DNS meaning [1].
TTL標準DNS意味[1]。
Class Standard DNS meaning [1].
クラス標準DNS意味[1]。
Type The Type Code [1] for NAPTR is 35.
NAPTRのタイプコード[1]を入力すると35です。
Order A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field).
NAPTRレコードを処理する順序を指定して、ルールの正しい順序を確保する必要がある16ビットの署名のない整数を注文します。低い数値は高い数値の前に処理され、ルールがターゲットに「一致する」NAPTRが見つかると、クライアントは順序の高い値を持つNAPTRを考慮してはなりません（フラグフィールドについて以下に記載されている場合を除く）。
Preference A 16-bit unsigned integer that specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not understanding the preferred protocol or service.
選好NAPTRが等しい「順序」値を持つ順序を指定する16ビットの署名されていない整数を処理する必要があり、高い数値が高い数の前に処理される必要があります。これは、MXレコードの優先フィールドに似ており、ドメイン管理者がより有能なホストまたは軽量プロトコルにクライアントを誘導できるように使用されるためです。クライアントは、優先プロトコルやサービスを理解しないなどの正当な理由がある場合、優先順位の高いレコードを見ることができます。
The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
順序と好みの重要な違いは、一致が見つかった後、クライアントは異なる順序でレコードを考慮してはならないが、同じ順序でレコードを処理することができるが、異なる好みであることです。つまり、優先順位は、当局の観点からも同じと見なされるルールに重みを与えるために使用されますが、単純な負荷分散の観点からではありません。
Flags A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant.
レコード内のフィールドの書き換えと解釈の側面を制御するためのフラグを含むフラグA <文字ストリング>。フラグは、セット[A-Z0-9]の単一文字です。アルファベット文字の場合は重要ではありません。
At this time only four flags, "S", "A", "U", and "P", are defined. The "S", "A" and "U" flags denote a terminal lookup. This means that this NAPTR record is the last one and that the flag determines what the next stage should be. The "S" flag means that the next lookup should be for SRV records [4]. See Section 5 for additional information on how NAPTR uses the SRV record type. "A" means that the next lookup should be for either an A, AAAA, or A6 record. The "U" flag means that the next step is not a DNS lookup but that the output of the Regexp field is an URI that adheres to the 'absoluteURI' production found in the ABNF of RFC 2396 [9]. Since there may be applications that use NAPTR to also lookup aspects of URIs, implementors should be aware that this may cause loop conditions and should act accordingly.
現時点では、「S」、「A」、「U」、および「P」の4つのフラグのみが定義されています。「s」、「a」、および「u」フラグは、端子の検索を示します。これは、このNAPTRレコードが最後のレコードであり、フラグが次の段階がどうあるべきかを決定することを意味します。「S」フラグは、次のルックアップがSRVレコードのものであることを意味します[4]。NAPTRがSRVレコードタイプをどのように使用するかについての追加情報については、セクション5を参照してください。「A」とは、次のルックアップがA、AAAA、またはA6レコードのいずれかのものであることを意味します。「u」フラグは、次のステップはDNSルックアップではなく、regexpフィールドの出力がRFC 2396のABNFに見られる「Absoluteuri」生産を順守するURIであることを意味します[9]。NAPTRを使用してURIの側面を検索するアプリケーションがある可能性があるため、実装者はこれがループ条件を引き起こし、それに応じて行動する必要があることに注意する必要があります。
The "P" flag says that the remainder of the application side algorithm shall be carried out in a Protocol-specific fashion. The new set of rules is identified by the Protocol specified in the Services field. The record that contains the 'P' flag is the last record that is interpreted by the rules specified in this document. The new rules are dependent on the application for which they are being used and the protocol specified. For example, if the application is a URI RDS and the protocol is WIRE then the new set of rules are governed by the algorithms surrounding the WIRE HTTP specification and not this document.
「P」フラグは、アプリケーション側のアルゴリズムの残りの部分がプロトコル固有の方法で実行されると述べています。新しいルールのセットは、サービスフィールドで指定されたプロトコルによって識別されます。「P」フラグを含むレコードは、このドキュメントで指定されたルールで解釈される最後のレコードです。新しいルールは、使用されているアプリケーションとプロトコルが指定されているアプリケーションに依存しています。たとえば、アプリケーションがURI RDSであり、プロトコルがワイヤーである場合、新しいルールのセットは、このドキュメントではなく、ワイヤHTTP仕様を囲むアルゴリズムによって支配されます。
The remaining alphabetic flags are reserved for future versions of the NAPTR specification. The numeric flags may be used for local experimentation. The S, A, U and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assisting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). It is anticipated that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters. Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next record. This test takes precedence even over the "order" field. Since flags can control the interpretation placed on fields, a novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target.
残りのアルファベットフラグは、NAPTR仕様の将来のバージョン用に予約されています。数値フラグは、局所実験に使用できます。S、a、u、およびPフラグはすべて相互に排他的であり、解像度ライブラリは、複数のものが与えられた場合、エラーを通知する場合があります。（NAPTRの作成を支援するための実験コードとコードは、ブラウザなどのクライアントよりもそのようなエラーを信号する可能性が高くなります）。将来複数のフラグが許可されると予想されるため、実装者はフラグフィールドに0または1文字のみを含めることができると想定してはなりません。最後に、クライアントが未知のフラグでレコードに遭遇した場合、それを無視して次のレコードに移動する必要があります。このテストは、「注文」フィールドよりも優先されます。フラグはフィールドに配置された解釈を制御できるため、新しいフラグは、レコンシが特定のターゲットと一致するかどうかを判断することが不可能になるように、正規表現および/または交換場の解釈を変更する可能性があります。
The "S", "A", and "U" flags are called 'terminal' flags since they halt the looping rewrite algorithm. If those flags are not present, clients may assume that another NAPTR RR exists at the domain name produced by the current rewrite rule. Since the "P" flag specifies a new algorithm, it may or may not be 'terminal'. Thus, the client cannot assume that another NAPTR exists since this case is determined elsewhere.
「S」、「A」、および「U」フラグは、ループの書き直しアルゴリズムを停止するため、「端末」フラグと呼ばれます。これらのフラグが存在しない場合、クライアントは、現在の書き換えルールによって作成されたドメイン名に別のNAPTR RRが存在すると仮定する場合があります。「P」フラグは新しいアルゴリズムを指定するため、「端末」である場合とそうでない場合があります。したがって、このケースは他の場所で決定されるため、クライアントは別のNAPTRが存在すると想定できません。
DNS servers MAY interpret these flags and values and use that information to include appropriate SRV and A,AAAA, or A6 records in the additional information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so.
DNSサーバーは、これらのフラグと値を解釈し、その情報を使用して、DNSパケットの追加情報部分に適切なSRVとA、AAAA、またはA6レコードを含めることができます。クライアントは追加情報を確認することをお勧めしますが、そうする必要はありません。
Service Specifies the service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a service. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon.
サービスこの書き換えパスで利用可能なサービスを指定します。また、サービスとの通話に使用される特定のプロトコルを指定することもできます。フラグフィールドがNAPTRが端子であると述べている場合、プロトコルを指定する必要があります。プロトコルが指定されているが、FlagsフィールドにNAPTRが端子であると述べていない場合、次のルックアップはNAPTRのものでなければなりません。クライアントは、プロトコルが不明な場合は次のルックアップを実行しないことを選択できますが、その動作は依存してはなりません。
The service field may take any of the values below (using the Augmented BNF of RFC 2234 [5]):
サービスフィールドは、以下のいずれかの値を取得する場合があります（RFC 2234 [5]の拡張BNFを使用）：
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; The protocol and rs fields are limited to 32
; characters and must start with an alphabetic.
For example, an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character.
たとえば、オプションのプロトコル仕様に続いて0以上の解像度サービスが続きます。各解像度サービスは、最初の「文字」で示されます。
Note that the empty string is also a valid service field. This will typically be seen at the beginning of a series of rules, when it is impossible to know what services and protocols will be offered by a particular service.
空の文字列も有効なサービスフィールドであることに注意してください。これは通常、特定のサービスによってどのようなサービスとプロトコルが提供されるかを知ることが不可能な場合、一連のルールの開始時に見られます。
The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant.
サービス要求と応答の実際の形式は、解決プロトコルによって決定され、他のドキュメントの主題です。プロトコルはすべてのサービスを提供する必要はありません。サービスリクエストのラベルは、文字のセット[A-Z0-9]から形成されます。アルファベット文字の場合は重要ではありません。
The list of "valid" protocols for any given NAPTR record is any protocol that implements some or all of the services defined for a NAPTR application. Currently, THTTP [6] is the only protocol that is known to make that claim at the time of publication. Any other protocol that is to be used must have documentation specifying:
特定のNAPTRレコードの「有効な」プロトコルのリストは、NAPTRアプリケーション用に定義されたサービスの一部またはすべてを実装するプロトコルです。現在、THTTP [6]は、公開時にその主張をすることが知られている唯一のプロトコルです。使用する他のプロトコルには、指定するドキュメントが必要です。
* how it implements the services of the application
* アプリケーションのサービスをどのように実装するか
* how it is to appear in the NAPTR record (i.e., the string id of the protocol)
* NAPTRレコード（つまり、プロトコルの文字列ID）に表示されることはどうですか）
The list of valid Resolution Services is defined by the documents that specify individual NAPTR based applications.
有効な解像度サービスのリストは、個々のNAPTRベースのアプリケーションを指定するドキュメントによって定義されます。
It is worth noting that the interpretation of this field is subject to being changed by new flags, and that the current specification is oriented towards telling clients how to talk with a URN resolver.
このフィールドの解釈は、新しいフラグによって変更される可能性があり、現在の仕様はクライアントにurnリゾルバーと話す方法を伝えることに向けられていることは注目に値します。
Regexp A STRING containing a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. The grammar of the substitution expression is given in the next section.
regexp次のドメイン名をルックアップに構築するために、クライアントが保持している元の文字列に適用される置換式を含む文字列。代替式の文法は、次のセクションに記載されています。
The regular expressions MUST NOT be used in a cumulative fashion, that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, and extremely difficult to debug.
正規表現は累積的に使用してはなりません。つまり、クライアントが保持している元の文字列にのみ適用する必要があります。後者はいくつかのアプリケーションで魅力的ですが、経験により、そのような使用が非常に過失に敏感で、非常にエラーが発生しやすく、デバッグが非常に困難であることが示されています。
Replacement The next NAME to query for NAPTR, SRV, or address records depending on the value of the flags field. This MUST be a fully qualified domain-name. Unless and until permitted by future standards action, name compression is not to be used for this field.
NAPTR、SRV、またはFlagsフィールドの値に応じてレコードを渡すためにクエリする次の名前を置き換えます。これは完全に適格なドメイン名でなければなりません。将来の標準措置によって許可されない限り、および名前の圧縮はこのフィールドに使用されません。
The content of the regexp field is a substitution expression. True sed(1) and Perl style substitution expressions are not appropriate for use in this application for a variety of reasons stemming from internationalization requirements and backref limitations, therefore the contents of the regexp field MUST follow the grammar below:
Regexpフィールドの含有量は置換式です。真のSED（1）およびPERLスタイルの置換式は、国際化の要件と逆の制限に起因するさまざまな理由で、このアプリケーションでの使用には適していません。
subst_expr = delim-char ere delim-char repl delim-char *flags
delim-char = "/" / "!" / ... <Any non-digit or non-flag character
other than backslash '\'. All occurances of a delim_char
in a subst_expr must be the same character.>
ere = POSIX Extended Regular Expression
repl = 1 * ( OCTET / backref )
backref = "\" 1POS_DIGIT
flags = "i"
POS_DIGIT = %x31-39 ; 0 is not an allowed backref
The definition of a POSIX Extended Regular Expression can be found in [8], section 2.8.4.
拡張された正規表現の定義は、[8]、セクション2.8.4に記載されています。
The result of applying the substitution expression to the original URI MUST result in either a string that obeys the syntax for DNS domain-names [1] or a URI [9] if the Flags field contains a 'u'. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain-name can be constructed, client software SHOULD verify that the result is a legal DNS domain-name before making queries on it.
元のURIに置換式を適用した結果、DNSドメイン名[1]の構文に従う文字列またはURI [9]に、フラグフィールドに「U」が含まれている場合は、URI [9]になる必要があります。regexpフィールドが不適切に指定されているため、不適合ドメイン名を構築できるようにすることが可能であるため、クライアントソフトウェアは、結果がクエリを作成する前に合法的なDNSドメイン名であることを確認する必要があります。
Backref expressions in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE
置換式のREPL部分のbackref式は、置換式のeRE部分に「（ 'and'）」が囲まれた（おそらく空の）文字列に置き換えられます。nは、1〜9から9までの1桁です。n'th backref式を指定します。これは、n'th '（' 'on to natching'）で始まるものです。たとえば、ere
(A(B(C)DE)(F)G)
has backref expressions:
backref式があります：
\1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression
\ 1 = abcdefg \ 2 = bcde \ 3 = c \ 4 = f \ 5 .. \ 9 =エラー - 一致するサブエクスペッションなし
The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given.
「i」フラグは、eREマッチングがケースに依存しない方法で実行されることを示しています。さらに、「I」フラグが与えられたときに、逆方向の交換が小文字に正規化される場合があります。
The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character.
置換式の最初の文字は、置換式の成分を区切る文字として使用するものとします。置換式には、デリミタ文字のエスクロードが正確に3つある必要があります。デリミッター文字の脱出された発生は、そのキャラクターの発生と解釈されるため、数字は区切り文字として使用してはなりません。これが許可されていれば、バックレフは文字通りの数字と混同されます。同様に、置換式でフラグが指定されている場合、区切り文字もフラグ文字であってはなりません。
The behavior and meaning of the flags and services assume an algorithm where the output of one rewrite is a new key that points to another rule. This looping algorithm allows NAPTR records to incrementally specify a complete rule. These incremental rules can be delegated which allows other entities to specify rules so that one entity does not need to understand _all_ rules.
フラグとサービスの動作と意味は、1つの書き換えの出力が別のルールを指す新しい鍵であるアルゴリズムを想定しています。このループアルゴリズムにより、NAPTRレコードは完全なルールを徐々に指定できます。これらの増分ルールを委任することができ、他のエンティティがルールを指定できるため、1つのエンティティが_all_ルールを理解する必要がありません。
The algorithm starts with a string and some known key (domain). NAPTR records for this key are retrieved, those with unknown Flags or inappropriate Services are discarded and the remaining records are sorted by their Order field. Within each value of Order, the records are further sorted by the Preferences field.
アルゴリズムは、文字列といくつかの既知のキー（ドメイン）で始まります。このキーのNAPTRレコードは取得され、不明なフラグまたは不適切なサービスを持つものは破棄され、残りのレコードは注文フィールドでソートされます。順序の各値内で、レコードはさらに設定フィールドによってソートされます。
The records are examined in sorted order until a matching record is found. A record is considered a match iff: o it has a Replacement field value instead of a Regexp field value.
レコードは、マッチングレコードが見つかるまで、並べ替えられた順序で検討されます。レコードは、一致IFFと見なされます。Oは、再gExpフィールド値の代わりに交換フィールド値を持っています。
o or the Regexp field matches the string held by the client.
o または、regexpフィールドは、クライアントが保持している文字列と一致します。
The first match MUST be the match that is used. Once a match is found, the Services field is examined for whether or not this rule advances toward the desired result. If so, the rule is applied to the target string. If not, the process halts. The domain that results from the regular expression is then used as the domain of the next loop through the NAPTR algorithm. Note that the same target string is used throughout the algorithm.
最初の試合は使用される試合でなければなりません。一致が見つかると、このルールが望ましい結果に向かって進むかどうかについて、サービスフィールドが検討されます。その場合、ルールはターゲット文字列に適用されます。そうでない場合、プロセスは停止します。正規表現から生じるドメインは、NAPTRアルゴリズムを介して次のループのドメインとして使用されます。アルゴリズム全体で同じターゲット文字列が使用されていることに注意してください。
This looping is extremely important since it is the method by which complex rules are broken down into manageable delegated chunks. The flags fields simply determine at which point the looping should stop (or other specialized behavior).
このループは、複雑なルールが管理可能な委任されたチャンクに分解される方法であるため、非常に重要です。フラグフィールドは、ループがどの時点で停止するか（または他の特殊な動作）を決定するだけです。
Since flags are valid at any level of the algorithm, the degenerative case is to never loop but to look up the NAPTR and then stop. In many specialized cases this is all that is needed. Implementors should be aware that the degenerative case should not become the common case.
フラグはアルゴリズムの任意のレベルで有効であるため、変性の場合は、NAPTRを検索して停止することは決してループしません。多くの専門的なケースでは、これが必要なすべてです。実装者は、変性症例が一般的なケースになってはならないことに注意する必要があります。
When the SRV record type was originally specified it assumed that the client did not know the specific domain-name before hand. The client would construct a domain-name more in the form of a question than the usual case of knowing ahead of time that the domain-name should exist. I.e., if the client wants to know if there is a TCP based HTTP server running at a particular domain, the client would construct the domain-name _http._tcp.somedomain.com and ask the DNS if that records exists. The underscores are used to avoid collisions with potentially 'real' domain-names.
SRVレコードタイプが当初指定されていたとき、クライアントが特定のドメイン名を手元に知らなかったと想定していました。クライアントは、ドメイン名が存在するはずであることを事前に知っている通常のケースよりも、質問の形でドメイン名を構築します。つまり、特定のドメインで実行されているTCPベースのHTTPサーバーがあるかどうかをクライアントが知りたい場合、クライアントはドメイン名_http._tcp.somedomain.comを構築し、その記録が存在するかどうかをDNSに尋ねます。アンダースコアは、潜在的に「実際の」ドメイン名との衝突を回避するために使用されます。
In the case of NAPTR, the actual domain-name is specified by the various fields in the NAPTR record. In this case the client isn't asking a question but is instead attempting to get at information that it has been told exists in an SRV record at that particular domain-name. While this usage of SRV is slightly different than the SRV authors originally intended it does not break any of the assumptions concerning what SRV contains. Also, since the NAPTR explicitly spells out the domain-name for which an SRV exists, that domain-name MUST be used in SRV queries with NO transformations. Any given NAPTR record may result in a domain-name to be used for SRV queries that may or may not contain the SRV standardized underscore characters. NAPTR applications that make use of SRV MUST NOT attempt to understand these domains or use them according to how the SRV specification structures its query domains.
NAPTRの場合、実際のドメイン名はNAPTRレコードのさまざまなフィールドによって指定されます。この場合、クライアントは質問をしていませんが、その特定のドメイン名でSRVレコードに存在すると言われた情報を取得しようとしています。このSRVの使用法は、SRVの著者が元々意図していたSRVの著者とはわずかに異なりますが、SRVに含まれるものに関する仮定のいずれも壊れていません。また、NAPTRはSRVが存在するドメイン名を明示的に説明するため、そのドメイン名は変換のないSRVクエリで使用する必要があります。与えられたNAPTRレコードは、SRV標準化されたアンダースコア文字を含む場合と含まない場合があるSRVクエリにドメイン名を使用する可能性があります。SRVを使用するNAPTRアプリケーションは、これらのドメインを理解しようとしたり、SRV仕様がクエリドメインを構成する方法に従って使用したりしてはなりません。
It should be noted that the NAPTR algorithm is the basic assumption about how NAPTR works. The reasons for the rewrite and the expected output and its use are specified by documents that define what applications the NAPTR record and algorithm are used for. Any document that defines such an application must define the following:
NAPTRアルゴリズムは、NAPTRの仕組みに関する基本的な仮定であることに注意する必要があります。書き換えの理由と予想される出力とその使用は、NAPTRレコードとアルゴリズムが使用されるアプリケーションを定義するドキュメントによって指定されています。そのようなアプリケーションを定義するドキュメントは、以下を定義する必要があります。
o The first known domain-name or how to build it
o 最初に既知のドメイン名またはそれを構築する方法
o The valid Services and Protocols
o 有効なサービスとプロトコル
o What the expected use is for the output of the last rewrite
o 最後の書き換えの出力に期待される使用とは何か
o The validity and/or behavior of any 'P' flag protocols.
o 「P」フラグプロトコルの有効性および/または動作。
o The general semantics surrounding why and how NAPTR and its algorithm are being used.
o NAPTRとそのアルゴリズムが使用されている理由と方法を取り巻く一般的なセマンティクス。
NOTE: These are examples only. They are taken from ongoing work and may not represent the end result of that work. They are here for pedagogical reasons only.
注：これらは例のみです。それらは進行中の仕事から取られており、その作業の最終結果を表していない場合があります。彼らは教育的な理由のためだけにここにいます。
NAPTR was originally specified for use with the a Uniform Resource Name Resolver Discovery System. This example details how a particular URN would use the NAPTR record to find a resolver service.
NAPTRはもともと、均一なリソース名のリゾルバーディスカバリーシステムで使用するために指定されていました。この例では、特定のURNがNAPTRレコードを使用してリゾルバーサービスを見つける方法を詳しく説明しています。
Consider a URN namespace based on MIME Content-Ids. The URN might look like this:
Mime Content-IDに基づいたurnネームスペースを検討してください。urnは次のように見えるかもしれません：
urn:cid:39CB83F7.A8450130@fake.gatech.edu
(Note that this example is chosen for pedagogical purposes, and does not conform to the CID URL scheme.)
（この例は教育目的で選択されており、CID URLスキームに適合していないことに注意してください。）
The first step in the resolution process is to find out about the CID namespace. The namespace identifier [3], 'cid', is extracted from the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first 'known' key in the NAPTR algorithm. The NAPTR records for cid.urn.arpa looked up and return a single record: cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" .
解決プロセスの最初のステップは、CIDネームスペースについて調べることです。名前空間識別子[3]、「cid」は、urn.arpaに加えられたurから抽出されます。「cid.urn.arpa」は、Naptrアルゴリズムの最初の「既知の」キーになります。cid.urn.arpaのNaptrレコードは調べて、単一のレコードを返します：cid.urn.arpa。;;NAPTR 100 10 "" ""/urn：Cid：。 @（[^\
There is only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used. We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is ' gatech.edu' and the string is the same string as before.
NAPTR応答は1つしかないため、応答を注文することは問題ではありません。交換場は空であるため、regexpフィールドで提供されるパターンが使用されます。そのregexpをur全体に適用して、それが一致するかどうかを確認します。置換式の\ 2部分は、文字列「gatech.edu」を返します。フラグフィールドには「s」または「a」が含まれていないため、ルックアップは端末ではなく、DNSへの次のプローブは、新しいドメインが「gatech.edu」であり、文字列が以前と同じ文字列であるより多くのNaptrレコードを対象としています。。
Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as mordred, could have their very own NAPTR, maintaining those records for all the machines at a site as large as Georgia Tech would be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system.
ルールはCIDから完全なドメイン名を抽出しないことに注意してください。代わりに、CIDがホストから来ていると仮定し、そのドメインを抽出します。Mordredなどのすべてのホストは、独自のNAPTRを持つことができ、ジョージア工科大学と同じ大きさのサイトにあるすべてのマシンの記録を維持することは耐え難い負担です。ワイルドカードは、システム内に既に正確に一致する名前がない場合にのみ結果を返すため、ここでは適切ではありません。
The record returned from the query on "gatech.edu" might look like:
「gatech.edu」のクエリから返されたレコードは、次のように見えるかもしれません。
;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
;;NAPTR 100 50 "s" "Z3950 I2L I2C" "" _Z3950._TCP.GATECH.EDUのPref Flags Service Regexpの交換。in naptr 100 50 "s" "rcds i2c" "" _rcds._udp.gatech.edu。in naptr 100 50 "s" "http i2l i2c i2r" "" _http._tcp.gatech.edu。
Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service.
この例を継続して、注文フィールドと優先フィールドの値はすべてのレコードで等しいため、クライアントはレコードを自由に選択できることに注意してください。Flagsフィールドは、これらが表示される最後のNAPTRパターンであることを示しており、書き換え（この場合の単純な代替品）の後、SRVレコードを調べて、必要なサービスを提供できるホストに関する情報を取得する必要があります。
Assuming we prefer the Z39.50 protocol, our lookup might return:
Z39.50プロトコルを好むと仮定すると、ルックアップが戻る可能性があります。
;; Pref Weight Port Target _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu. IN SRV 0 0 1000 z3950.cc.gatech.edu. IN SRV 0 0 1000 z3950.uga.edu.
;;Pref Weight Port Target _Z3950._TCP.GATECH.EDU。in srv 0 0 1000 Z3950.gatech.edu。in srv 0 0 1000 Z3950.cc.gatech.edu。in srv 0 0 1000 Z3950.uga.edu。
telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server.
実際に解像度を行うことができる3つのホストを教えてくれ、Z39.50サーバーと話すために使用するポートを提供します。
Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '\' is the escape character, literal occurances of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually receives the record, the pattern will have been converted to "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
正規表現が\ 2を使用してCIDからドメイン名を抽出したことを思い出してください。リテラルを一致させるために。ドメイン名コンポーネントを分離する文字。「\」はエスケープキャラクターであるため、バックスラッシュの文字通りの発生は別のバックスラッシュによって逃げなければなりません。上記のcid.urn.arpaレコードの場合、マスターファイルに入力された正規表現は「/urn：cid：。 @（[^\\。] \\。）（。*）$/\\でなければなりません。2/i "。クライアントコードが実際にレコードを受信すると、パターンは「/urn：Cid：。 @（[^\。] \。）（。*）$/\ 2/i」に変換されます。
Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement that URNs be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc.
たとえURNシステムが現在設置されていたとしても、まだ膨大な数のURLがあります。これらのURLに場所の独立性を提供できるURN解像度システムを開発することが可能です。これは、ISOの正式なパブリック識別子、議会のコール番号、ISBNS、ISSNSなど、ISOの正式なパブリック識別子、ISOの正式な公開識別子など、他の命名システムの名前でurが祖父にできるという要件に関連しています。
The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world:
Naptr RRは、すでに割り当てられているURLにも使用できます。出版社が世界中の複数のサイトでミラーリングしたいという非常に人気のあるソフトウェアのURLがあると仮定します。
Using the rules specified for this application we extract the prefix, "http", and lookup NAPTR records for http.uri.arpa. This might return a record of the form
このアプリケーションに指定されたルールを使用して、http.uri.arpaのプレフィックス、「http」、およびlookup naptrレコードを抽出します。これにより、フォームのレコードが返される場合があります
http.uri.arpa. IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "!http://([^/:]+)!\1!i" .
http.uri.arpa。naptr ;;Pref Flags Service Regexp交換100 90 "" ""！http：//（[^/：]）！\ 1！i "。
This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes and would have a regexp in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
この表現は、最初のダブルスラッシュの後、次のスラッシュまたはコロンの前にすべてを返します。（「！」文字を使用して置換式の部分を区切ります。そうしないと、バックスラッシュを使用してフォワードスラッシュを逃れる必要があり、ゾーンファイルに「/http：\\/\\/（[^\\/：]）/\\ 1/i "。）。
Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return:
このパターンをURL抽出に適用する「www.foo.com」。そのためのNAPTRレコードを検索すると、戻る可能性があります。
www.foo.com. ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com. IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
www.foo.com。;;NAPTR 100 "s" "HTTP I2R" "" _HTTP._TCP.FOO.COMでのnaptr 100 "s" "http i2rでのregexp交換を注文します。in naptr 100 100 "s" "ftp i2r" "" _ftp._tcp.foo.com。
Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user.
http.tcp.foo.comのSRVレコードを検索すると、Foo.comがそのミラーサイトに指定したホストに関する情報が返されます。クライアントは、ユーザー用に1つを選択できます。
A non-URI example is the ENUM application which uses a NAPTR record to map an e.164 telephone number to a URI. In order to convert the phone number to a domain name for the first iteration all characters other than digits are removed from the the telephone number, the entire number is inverted, periods are put between each digit and the string ".e164.arpa" is put on the left-hand side. For example, the E.164 phone number "+1-770-555-1212" converted to a domain-name it would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
URI以外の例は、NAPTRレコードを使用してE.164の電話番号をURIにマッピングするEnumアプリケーションです。電話番号を最初の反復のドメイン名に変換するために、数字以外のすべての文字が電話番号から削除されます。全体の番号が反転し、各数字と文字列の間に期間が配置されます。左側に置きます。たとえば、E.164の電話番号「1-770-555-1212」は、「2.1.2.1.1.5.5.5.5.5.55.5.7.7.1.e164.ARPA」になります。
For this example telephone number we might get back the following NAPTR records:
この例の電話番号では、次のNAPTRレコードを取り戻す可能性があります。
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" .
$ origin 2.1.2.1.5.5.5.5.0.7.7.1.e164.arpa。in naptr 100 10 "u" "sip e2u" "！^。*$！sip：information@tele2.se！"。in naptr 102 10 "u" "mailto e2u" "！^。*$！mailto：information@tele2.se！"。
This application uses the same 'u' flag as the URI Resolution application. This flag states that the Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service. ENUM also uses the same format for its Service field except that it defines the 'E2U' service instead of the 'I2*' services that URI resolution uses. The example above states that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.
このアプリケーションは、URI解像度アプリケーションと同じ「U」フラグを使用します。このフラグは、ルールは端末であり、出力はその電話サービスに連絡するために必要な情報を含むURIであると述べています。enumは、URI解像度が使用する「i2*」サービスの代わりに「E2U」サービスを定義することを除いて、そのサービスフィールドに同じ形式を使用します。上記の例は、電話のサービスにアクセスするために使用される利用可能なプロトコルは、セッション開始プロトコルまたはSMTPメールのいずれかであると述べています。
The packet format for the NAPTR record is:
NAPTRレコードのパケット形式は次のとおりです。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ただし：
FLAGS A <character-string> which contains various flags.
さまざまなフラグを含むフラグA <文字通り>。
SERVICES A <character-string> which contains protocol and service identifiers.
プロトコルとサービス識別子を含むサービス<文字弦>。
REGEXP A <character-string> which contains a regular expression.
正規表現を含むregexp a <文字弦>。
REPLACEMENT A <domain-name> which specifies the new value in the case where the regular expression is a simple replacement operation.
交換A <domain-name>正規表現が単純な交換操作である場合の新しい値を指定します。
<character-string> and <domain-name> as used here are defined in RFC1035 [1].
ここで使用される<文字通り>および<domain-name>は、RFC1035 [1]で定義されています。
The master file format follows the standard rules in RFC-1035 [1]. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags and Services and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes and thus should be treated with care. See Section 10 for how to correctly enter and escape the regular expression.
マスターファイル形式は、RFC-1035 [1]の標準ルールに従います。16ビットの署名されていない整数である順序と優先権は、0〜65535の整数でなければなりません。フラグとサービスとregexpフィールドはすべて<キャラクターストリング> sを引用しています。regexpフィールドには多数のバックスラッシュが含まれている可能性があるため、注意して扱う必要があります。正規表現を正しく入力して逃れる方法については、セクション10を参照してください。
Beware of regular expressions. Not only are they difficult to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers.
正規表現に注意してください。自分で正しいことをするのが難しいだけでなく、前述のDNSとの相互作用があります。正規表現のバックスラッシュは、クエリ応答に1回表示するために、ゾーンファイルに2回入力する必要があります。さらに真剣に、ダブルバックスラッシュの必要性は、おそらくDNSサーバーのすべての実装者によってテストされていないでしょう。
The "a" flag allows the next lookup to be for address records (A, AAAA, A6) rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port.
「a」フラグは、SRVレコードではなく、次のルックアップ（A、AAAA、A6）のものにすることができます。NAPTRレコードにはポート仕様の場所がないため、「A」フラグが使用される場合、指定されたプロトコルはデフォルトのポートで実行されている必要があります。
The URN Syntax draft defines a canonical form for each URN, which requires %encoding characters outside a limited repertoire. The regular expressions MUST be written to operate on that canonical form. Since international character sets will end up with extensive use of %encoded characters, regular expressions operating on them will be essentially impossible to read or write by hand.
urn構文ドラフトは、各urnの標準形式を定義します。これには、限られたレパートリーの外側の％をエンコードする％が必要です。正規表現は、その標準形式で動作するために書かれている必要があります。国際的なキャラクターセットは、％エンコードされた文字を広範囲に使用することになるため、手作業で動作する正規表現は本質的に不可能です。
o A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination.
o クライアントは、「順序」フィールドで指定された順序で複数のNAPTRレコードを処理する必要があります。既知のプロトコルとサービスの組み合わせを提供する最初のレコードを単に使用してはなりません。
o When multiple RRs have the same "order" and all other criteria being equal, the client should use the value of the preference field to select the next NAPTR to consider. However, because it will often be the case where preferred protocols or services exist, clients may use this additional criteria to sort the records.
o 複数のRRが同じ「順序」を持ち、他のすべての基準が等しい場合、クライアントは設定フィールドの値を使用して次のNAPTRを選択する必要があります。ただし、優先プロトコルまたはサービスが存在する場合が多いため、クライアントはこの追加基準を使用してレコードをソートすることができます。
o If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths.
o 書き換えの後の検索が失敗した場合、クライアントは、他の書き換えパスを追求するためにバックアップするのではなく、失敗を報告することを強くお勧めします。
o Note that SRV RRs impose additional requirements on clients.
o SRV RRSはクライアントに追加の要件を課していることに注意してください。
The only registration function that impacts the IANA is for the values that are standardized for the Services and Flags fields. To extend the valid values of the Flags field beyond what is specified in this document requires a published specification that is approved by the IESG.
IANAに影響を与える唯一の登録関数は、サービスフィールドとフラグフィールドに標準化された値のためです。このドキュメントで指定されているものを超えてフラグフィールドの有効な値を拡張するには、IESGによって承認された公開された仕様が必要です。
The values for the Services field will be determined by the application that makes use of the NAPTR record. Those values must be specified in a published specification and approved by the IESG.
サービスフィールドの値は、NAPTRレコードを使用するアプリケーションによって決定されます。これらの値は、公開された仕様で指定し、IESGによって承認される必要があります。
The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed.
DNSSECとの相互作用は現在研究中です。DNSSECの作業が展開されると、NAPTRレコードにSIGレコードと署名されることが予想されます。
The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem.
書き換えルールは、通常のドメイン名と同じ攻撃を受ける他の名前空間から識別子を作成します。彼らは以前に簡単に解決できなかったので、これは問題と見なされるかもしれないし、そうでないかもしれません。
Regular expressions should be checked for sanity, not blindly passed to something like PERL.
正規表現は、perlのようなものに盲目的に渡されるのではなく、正気をチェックする必要があります。
This document has discussed a way of locating a service, but has not discussed any detail of how the communication with that service takes place. There are significant security considerations attached to the communication with a service. Those considerations are outside the scope of this document, and must be addressed by the specifications for particular communication protocols.
このドキュメントでは、サービスを見つける方法について説明しましたが、そのサービスとの通信がどのように行われるかについての詳細については説明していません。サービスとのコミュニケーションに関連する重要なセキュリティ上の考慮事項があります。これらの考慮事項は、このドキュメントの範囲外であり、特定の通信プロトコルの仕様によって対処する必要があります。
The editors would like to thank Keith Moore for all his consultations during the development of this memo. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. Finally, we would like to acknowledge our enormous intellectual debt to the participants in the Knoxville series of meetings, as well as to the participants in the URI and URN working groups.
編集者は、このメモの開発中のすべての相談について、キース・ムーアに感謝したいと思います。また、Paul Vixieが私たちの実装をデバッグする際の支援と、私たちの質問に対する彼の答えに感謝したいと思います。最後に、ノックスビルシリーズの一連の会議の参加者と、URIおよびURNワーキンググループの参加者に対する莫大な知的債務を認めたいと思います。
References
参考文献
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[1] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[4] Gulbrandsen、A.、Vixie、P。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、RFC 2782、2000年2月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker、D。、「構文仕様のための拡張BNF：ABNF」、RFC 2234、1997年11月。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[6] Daniel、R。、「urn解像度でHTTPを使用するための些細な条約」、RFC 2169、1997年6月。
[7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[7] Daniel、R。およびM. Mealling、「ドメイン名システムを使用した均一なリソース識別子の解像度」、RFC 2168、1997年6月。
[8] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[8] IEEE、「情報技術のIEEE標準 - ポータブルオペレーティングシステムインターフェイス（POSIX） - パート2：シェルとユーティリティ（Vol。1）」、IEEE STD 1003.2-1992、1993年1月。
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] バーナーズリー、T。、フィールディング、R.T。およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
Authors' Addresses
著者のアドレス
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070 US
Michael Mealling Network Solutions、Inc。505 Huntmar Park Drive Herndon、VA 22070 US
Phone: +1 770 921 2251
EMail: michaelm@netsol.com
URI: http://www.netsol.com
Ron Daniel DATAFUSION, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 US
Ron Daniel DataFusion、Inc。139 Townsend Street、Ste。100サンフランシスコ、CA 94107 US
Phone: +1 415 222 0100
EMail: rdaniel@datafusion.net
URI: http://www.datafusion.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。