[要約] RFC 3401は、Dynamic Delegation Discovery System（DDDS）の詳細な仕様を提供しています。このRFCの目的は、DDDSの基本的な概念とプロトコルを説明し、インターネット上でのデータベース検索とデータの委譲をサポートすることです。
Network Working Group M. Mealling
Request for Comments: 3401 VeriSign
Updates: 2276 October 2002
Obsoletes: 2915, 2168
Category: Informational
Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS
動的委任ディスカバリーシステム（DDDS）パート1：包括的なDDD
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) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.
このドキュメントは、完全な動的委任ディスカバリーシステム（DDDS）を構成する正確なドキュメントを指定します。DDDSは、動的に取得された文字列変換ルールをアプリケーションユニークな文字列に適用するための抽象的なアルゴリズムです。
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276.
このドキュメントは、RFC 3402、RFC 3403、およびRFC 3404 Obsolete RFC 2168およびRFC 2915、およびRFC 2276を更新します。
This document and the documents that it references are intended for anyone attempting to implement or understand the generic DDDS algorithm, URI Resolution, ENUM telephone number to URI resolution, and the NAPTR DNS resource record. The reader is warned that reading one of the documents in this series without reading the others will probably lead to misunderstandings and interoperability problems.
このドキュメントと、それが参照するドキュメントは、一般的なDDDSアルゴリズム、URI解像度、URI解像度への列挙電話番号、およびNAPTR DNSリソースレコードを実装または理解しようとする人を対象としています。読者は、他のシリーズを読むことなくこのシリーズのドキュメントの1つを読むと、おそらく誤解と相互運用性の問題につながると警告されています。
The Dynamic Delegation Discovery System is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. This document defines the entire DDDS by listing the documents that make up the complete specification at this time.
動的に構成された委任システムをサポートするために、動的委任ディスカバリーシステムを使用してデータへの文字列の怠zyな結合を実装します。DDDSは、端末条件に達するまで文字列変換ルールを反復的に適用することにより、DDDSデータベース内に保存されたデータにいくつかの一意の文字列をマッピングすることにより機能します。このドキュメントでは、現時点で完全な仕様を構成するドキュメントをリストすることにより、DDD全体を定義します。
This document along with RFC 3402, RFC 3403 and RFC 3404 obsoletes RFC 2168 [8] and RFC 2915 [6], as well as updates RFC 2276 [5]. This document will be updated and or obsoleted when changes are made to the DDDS specifications. Thus the reader is strongly encouraged to check the IETF RFC repository for any documents that obsoletes or updates this one.
このドキュメントは、RFC 3402、RFC 3403、およびRFC 3404 OBERETES RFC 2168 [8]およびRFC 2915 [6]とともに、RFC 2276 [5]を更新します。このドキュメントは、DDDS仕様に変更が加えられたときに更新または廃止されます。したがって、読者は、これを廃止または更新するドキュメントについて、IETF RFCリポジトリを確認することを強くお勧めします。
The DDDS algorithm is defined by RFC 3402 [1]. That document defines the following DDDS concepts:
DDDSアルゴリズムは、RFC 3402 [1]によって定義されます。そのドキュメントは、次のDDDSの概念を定義しています。
o The basic DDDS vocabulary.
o 基本的なDDDS語彙。
o The algorithm.
o アルゴリズム。
o The requirements on applications using the algorithm.
o アルゴリズムを使用したアプリケーションの要件。
o The requirements on databases that store DDDS rules.
o DDDSルールを保存するデータベースの要件。
RFC 3402 is the actual DDDS Algorithm specification. But the specification by itself is useless without some additional document that defines how and why the algorithm is used. These documents are called Applications and do not actually make up part of the DDDS core specification. Applications require databases in which to store their Rules. These databases are called DDDS Databases and are usually specified in separate documents. But again, these Database specifications are not included in the DDDS core specification itself.
RFC 3402は、実際のDDDSアルゴリズムの仕様です。ただし、仕様自体は、アルゴリズムが使用される方法と理由を定義する追加のドキュメントなしでは役に立ちません。これらのドキュメントはアプリケーションと呼ばれ、実際にはDDDSコア仕様の一部を構成していません。アプリケーションには、ルールを保存するデータベースが必要です。これらのデータベースはDDDSデータベースと呼ばれ、通常は別々のドキュメントで指定されています。ただし、これらのデータベース仕様は、DDDSコア仕様自体に含まれていません。
No implementation can begin without an Application specification, as this is what provides the concrete instantiation details for the DDDS Algorithm. Without them the DDDS is nothing more than a general algorithm. Application documents define the following:
アプリケーション仕様なしでは実装を開始できません。これは、DDDSアルゴリズムの具体的なインスタンス化の詳細を提供するためです。それらがなければ、DDDは一般的なアルゴリズムにすぎません。アプリケーションドキュメントは以下を定義します。
o the Application Unique String (the thing the delegation rules act on).
o アプリケーションユニークな文字列（代表団が行うもの）。
o the First Well Known Rule (the Rule that says where the process starts).
o 最初によく知られているルール（プロセスが始まる場所を示すルール）。
o the list of valid Databases (you can't just use any Database).
o 有効なデータベースのリスト（データベースだけを使用することはできません）。
o the final expected output.
o 最終予想出力。
Some sample Applications are documented in:
一部のサンプルアプリケーションは、次のように文書化されています。
o "E.164 number and DNS" (RFC 2916) [7]. This Application uses the DDDS to map a telephone number to service endpoints such as SIP or email.
o 「E.164数とDNS」（RFC 2916）[7]。このアプリケーションでは、DDDを使用して電話番号をマッピングして、SIPや電子メールなどのエンドポイントにサービスを提供します。
o "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application" (RFC 3404) [3]. This Application uses the DDDS to resolve any URI to a set of endpoints or 'resolvers' that can give additional information about the URI independent of its particular URI scheme.
o 「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）解像度アプリケーション」（RFC 3404）[3]。このアプリケーションでは、DDDを使用して、特定のURIスキームとは無関係にURIに関する追加情報を提供できるエンドポイントまたは「リゾルバー」のセットにURIを解決します。
Any DDDS Application must use some type of DDDS Database. Database documents define the following:
DDDSアプリケーションは、何らかのタイプのDDDSデータベースを使用する必要があります。データベースドキュメントは次のものを定義します。
o the general spec for how the Database works.
o データベースの仕組みの一般的な仕様。
o formats for Keys.
o キーのフォーマット。
o formats for Rules.
o ルールのフォーマット。
o Key lookup process.
o キールックアッププロセス。
o rule insertion procedures.
o ルール挿入手順。
o collision avoidance measures.
o 衝突回避措置。
A Database cannot be used on its own; there must be at least one Application that uses it. Multiple Databases and Applications are defined, and some Databases will support multiple Applications. However, not every Application uses each Database, and vice versa. Thus, compliance is defined by the combination of a Database and Application specification.
データベースは単独では使用できません。少なくとも1つのアプリケーションを使用する必要があります。複数のデータベースとアプリケーションが定義されており、一部のデータベースは複数のアプリケーションをサポートします。ただし、すべてのアプリケーションが各データベースを使用するわけではなく、逆も同様です。したがって、コンプライアンスは、データベースとアプリケーションの仕様の組み合わせによって定義されます。
One sample Database specification is documented in:
1つのサンプルデータベースの仕様は、次のように文書化されています。
o "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database" (RFC 3402) [1]. (This document is the official specification for the NAPTR DNS Resource Record.)
o 「動的委任発見システム（DDDS）パート3：ドメイン名システム（DNS）データベース」（RFC 3402）[1]。（このドキュメントは、NAPTR DNSリソースレコードの公式仕様です。）
Any known security issues that arise from the use of algorithms and databases must be specified in the respective specifications. They must be completely and fully described. It is not required that the database and algorithms be secure or that it be free from risks, but that the known risks be identified. Publication of a new database type or algorithm does require a security review, and the security considerations section should be subject to continuing evaluation. Additional security considerations should be addressed by publishing revised versions of the database and algorithm specifications.
アルゴリズムとデータベースの使用から生じる既知のセキュリティの問題は、それぞれの仕様で指定する必要があります。それらは完全に完全に記述されている必要があります。データベースとアルゴリズムが安全であるか、リスクがないことは必須ではなく、既知のリスクを特定する必要はありません。新しいデータベースタイプまたはアルゴリズムの公開には、セキュリティレビューが必要であり、セキュリティに関する考慮事項セクションには継続的な評価の対象となります。追加のセキュリティに関する考慮事項は、データベースとアルゴリズムの仕様の改訂版を公開することで対処する必要があります。
While this document itself does not create any new requirements for the IANA, the documents in this series create many varied requirements. The IANA Considerations sections in those documents should be reviewed by the IANA to determine the complete set of new registries and requirements. Any new algorithms, databases or applications should take great care in what they require the IANA to do in the future.
このドキュメント自体はIANAの新しい要件を作成しませんが、このシリーズのドキュメントは多くのさまざまな要件を作成します。これらのドキュメントのIANAに関する考慮事項セクションは、新しいレジストリと要件の完全なセットを決定するために、IANAによってレビューする必要があります。新しいアルゴリズム、データベース、またはアプリケーションは、IANAが将来行う必要があることに細心の注意を払う必要があります。
References
参考文献
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[1] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート2：アルゴリズム」、RFC 3402、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Doman Name System (DNS) Database", RFC 3403, October 2002.
[2] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：The Doman Name System（DNS）データベース」、RFC 3403、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[3] Mealling、M。、「動的委任発見システム（DDDS）パート4：ユニフォームリソース識別子（URI）解像度アプリケーション」、RFC 3404、2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[4] Mealling、M。、「動的委任発見システム（DDDS）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。
[5] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[5] Sollins、K。、「均一なリソース名の解決の建築原理」、RFC 2276、1998年1月。
[6] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[6] Mealling、M。and R. Daniel、「The Naming Authority Pointer（NAPTR）DNSリソースレコード」、RFC 2915、2000年8月。
[7] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[7] Faltstrom、P。、「E.164番号とDNS」、RFC 2916、2000年9月。
[8] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[8] Daniel、R。およびM. Mealling、「ドメイン名システムを使用した均一なリソース識別子の解像度」、RFC 2168、1997年6月。
Author's Address
著者の連絡先
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling Verisign 21345 Ridgetop Circle Sterling、VA 20166 US
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。