Network Working Group M. Mealling
Request for Comments: 3402 Verisign
Obsoletes: 2915, 2168 October 2002
Category: Standards Track
Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
この文書は、アプリケーション固有の文字列を動的に検索された文字列の変換規則を適用するためのダイナミックな委譲発見システム（DDDS）アルゴリズムを記載しています。整形式の変換ルールは、文字列に関連付けられた情報の管理の委任を反映します。 （RFC 3401）：この文書はまた、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されているシリーズの一部です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 6
3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 6
3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 8
4. Specifying An Application . . . . . . . . . . . . . . . . . . 9
5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 An Automobile Parts Identification System . . . . . . . . . . 12
6.2 A Document Identification Service . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
The Dynamic Delegation Discovery System (DDDS) 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.
ダイナミックな委譲発見システム（DDDS）は、動的に構成された委任システムをサポートするために、データへの文字列の遅延結合を実装するために使用されます。 DDDS機能端末状態が達成されるまで反復文字列変換規則を適用することによって、DDDSデータベース内に格納されたデータにいくつかのユニークな文字列をマッピングすることによって。
This document describes the general DDDS algorithm, not any particular application or usage scenario. The entire series of documents is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. It is very important to note that it is impossible to read and understand a single document in that series without reading the related documents.
この文書では、一般的なDDDSアルゴリズムではなく、任意の特定のアプリケーションや使用シナリオを説明します。文書の全シリーズは、「ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS」に指定されている（RFC 3401）[1]。関連文書を読まずにそのシリーズで単一の文書を読んで理解することは不可能であることに注意することが非常に重要です。
The DDDS's history is an evolution from work done by the Uniform Resource Name Working Group. When Uniform Resource Names (URNs) [6] were originally formulated there was the desire to locate an authoritative server for a URN that (by design) contained no information about network locations. A system was formulated that could use a database of rules that could be applied to a URN to find out information about specific chunks of syntax. This system was originally called the Resolver Discovery Service (RDS) [7] and only applied to URNs.
DDDSの歴史は統一リソース名ワーキンググループによって行われた仕事から進化したものです。場合ユニフォームリソース名（のURN）[6]元々ネットワークロケーションに関する情報を含んでいなかった（設計によって）ことURNに対する権限サーバを見つけたいという願望があった処方しました。システムは、構文の特定のチャンクについての情報を見つけるためにURNに適用できるルールのデータベースを使用することができることを処方しました。このシステムは、もともとリゾルバディスカバリサービス（RDS）と呼ばれていた[7]のみのURNに適用しました。
Over time other systems began to apply this same algorithm and infrastructure to other, non-URN related, systems (see Section 6 for examples of other ways of using the DDDS). This caused some of the underlying assumptions to change and need clarification. These documents are an update of those original URN specifications in order to allow new applications and rule databases to be developed in a standardized manner.
時間が経つにつれて、他のシステムでは、関連する他、非URN、システム（DDDSを使用する他の方法の例については、セクション6を参照）に、この同じアルゴリズムおよびインフラストラクチャを適用し始めました。これは、変更と明確化を必要とする基礎となる仮定の一部を引き起こしました。これらの文書は、新しいアプリケーションやルールデータベースは、標準化された方法で開発することを可能にするためのもの元URN仕様の更新です。
This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as updates RFC 2276 [7].
この文書は、RFC 2168 [11]およびRFC 2915を時代遅れ[9]と同様に更新するRFC 2276 [7]。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Application Unique String A string that is the initial input to a DDDS application. The lexical structure of this string must imply a unique delegation path, which is analyzed and traced by the repeated selection and application of Rewrite Rules.
アプリケーション固有文字列DDDSアプリケーションへの初期入力された文字列。この文字列の字句構造を分析し、書き換えルールの繰り返し選択すると、アプリケーションがトレースしている固有の委任パスを、暗示しなければなりません。
Rewrite Rule A rule that is applied to an Application Unique String to produce either a new key to select a new rewrite rule from the rule database, or a final result string that is returned to the calling application. Also simply known as a Rule.
ルールデータベースから新しい書き換えルールを選択するための新しいキー、または呼び出し元のアプリケーションに返され、最終的な結果の文字列のいずれかを生成するために、アプリケーション固有文字列に適用されるルールをルール書き換えます。また、単にルールとして知られています。
First Well Known Rule This is a rewrite rule that is defined by the application and not actually in the Rule Database. It is used to produce the first valid key.
まずよく知られているルールは、これはルールデータベースに実際にアプリケーションによって定義されていない書き換えルールです。最初の有効なキーを生成するために使用されます。
Terminal Rule A Rewrite Rule that, when used, yields a string that is the final result of the DDDS process, rather than another database key.
使用される、ことを端末ルールAリライトルールは、DDDSプロセスの最終結果ではなく、別のデータベースのキーで文字列を生じます。
Application A set of protocols and specifications that specify actual values for the various generalized parts of the DDDS algorithm. An Application must define the syntax and semantics of the Application Unique String, the First Well Known Rule, and one or more Databases that are valid for the Application.
アプリケーションDDDSアルゴリズムの様々な一般的な部品の実際の値を指定するプロトコル及び仕様のセット。アプリケーションは、アプリケーション固有文字列、まずよく知られているルール、およびアプリケーションに対して有効である1つの以上のデータベースの構文とセマンティクスを定義する必要があります。
Rule Database Any store of Rules such that a unique key can identify a set of Rules that specify the delegation step used when that particular Key is used.
ルールデータベース固有のキーは、その特定のキーを使用しているときに使用される委任ステップを指定するルールのセットを識別することができるようなルールのいずれか店。
Services A common rule database may be used to associate different services with a given Application Unique String; e.g., different protocol functions, different operational characteristics, geographic segregation, backwards compatibility, etc. Possible service differences might be message receiving services for email/fax/ voicemail, load balancing over web servers, selection of a nearby mirror server, cost vs performance trade-offs, etc. These Services are included as part of a Rule to allow the Application to make branching decisions based on the applicability of one branch or the other from a Service standpoint.
共通ルールのデータベースが、指定されたアプリケーション固有文字列と異なるサービスを関連付けるために使用することができるサービス。例えば、異なるプロトコル機能、異なる動作特性、地理的隔離、後方互換性など可能なサービスの違いは、メッセージ、電子メール/ファックス/ボイスメールサービスを受けて、Webサーバ上でロードバランシング、近くのミラーサーバの選択、性能のトレード対費用かもしれません-offs、等が挙げられる。これらのサービスは、アプリケーションがサービスの観点から、1つの支店または他の適用可能性に基づいて決定を分岐させることを可能にする規則の一部として含まれています。
Flags Most Applications will require a way for a Rule to signal to the Application that some Rules provide particular outcomes that others do not; e.g., different output formats, extensibility mechanisms, terminal rule signaling, etc. Most Databases will define a Flags field that an Application can use to encode various values that express these signals.
フラグほとんどのアプリケーションは、いくつかのルールが他にはない特別な成果を提供し、アプリケーションに知らせるためのルールのための方法が必要になります。例えば、異なる出力形式、拡張メカニズム、端末ルールシグナリング、等ほとんどのデータベースは、アプリケーションがこれらの信号を表現する様々な値をエンコードするために使用できるフラグフィールドを定義します。
The DDDS algorithm is based on the concept of Rewrite Rules. These rules are collected into a DDDS Rule Database, and accessed by given unique keys. A given Rule, when applied to an Application Unique String, transforms that String into new Key that can be used to retrieve a new Rule from the Rule Database. This new rule is then reapplied to the original Application Unique String and the cycle repeats itself until a terminating condition is reached. An Application MUST NOT apply a Rule to the output of a previous Rule. All Rewrite Rules for all Applications must ALWAYS apply to the exact same Application Unique String that the algorithm started with.
DDDSアルゴリズムは書き換えルールの概念に基づいています。これらのルールは、DDDSルールデータベースに集め、そして与えられたユニークキーによってアクセスされています。アプリケーション固有文字列に適用されたときに与えられたルールは、ルールデータベースから新しいルールを取得するために使用することができ、新たなキーにその文字列を変換します。この新しい規則は、元のアプリケーション固有文字列に再度適用され、終了条件に達するまでのサイクルが繰り返されます。アプリケーションは、以前のルールの出力にルールを適用してはなりません。すべてのアプリケーションのすべての書き換えルールは常にアルゴリズムが使用を開始することを正確に同じアプリケーション固有文字列に適用する必要があります。
It is a fundamental assumption that the Application Unique String has some kind of regular, lexical structure that the rules can be applied to. It is an assumption of the DDDS that the lexical element used to make a delegation decision is simple enough to be contained within the Application Unique String itself. The DDDS does not solve the case where a delegation decision is made using knowledge contained outside the AUS and the Rule (time of day, financial transactions, rights management, etc.).
これは、アプリケーション固有文字列がルールを適用することができ、通常、字句構造のいくつかの種類を持っている基本的な前提です。これは、委任決定を行うために使用される字句要素は十分に単純なアプリケーション固有文字列自体の中に含まれていることがあるDDDSの仮定です。 DDDSは、委任決定がAUSとルール（日、金融取引、著作権管理の時間など）外に含まれる知識を利用して作られて事件を解決しません。
Diagrammatically the algorithm looks like this:
図式アルゴリズムは次のようになります。
+--------- Application Unique String
| +-----+
| |input|
| +-------+ +---------+
| | First Well Known Rule |
| +-------+ +--------+
| |output|
| +------+
| First Key
| |
| +----<--------------<--------------+
| | |
| key (a DDDS database always |
| +-----+ takes a key and returns |
| |input| a rule) ^
| +---------+ +------------+ |
| | Lookup key in DDDS Database| |
| +---------+ +-----------+ |
| |output| |
| +------+ |
| rule set |
| | |
| | (the input to a rule |
| rule set is the rule and the AUS. ^
| +-----+ The output is always |
+---------------->|input| either a key or the result) |
+---------------+ +------------------+ |
| Apply Rules to Application Unique String| |
| until non-empty result are obtained | |
| that meet the applications requirements | |
+---------------+ +-----------------+ |
|output| |
+------+ ^
key |
| |
v |
+--------------------------------------+ |
| Was the last matching rule terminal? | No >------+
+--------------------------------------+
Yes (if the rule isn't terminal then
| its output is the new key which
| is used to find a new rule set)
+------------------------------------+
| The output of the last rule is the |
| result desired by the application |
+------------------------------------+
A Rule is made up of 4 pieces of information:
ルールは、情報の4枚で構成されています。
A Priority Simply a number used to show which of two otherwise equal rules may have precedence. This allows the database to express rules that may offer roughly the same results but one delegation path may be faster, better, cheaper than the other.
優先順位は、単に数が優先され得る2つのさもなければ等しいルールのどの表示するために使用されます。これは、データベースがほぼ同じ結果を提供することがありますが、1つの委任パスが他よりも安く、より速く、より良いかもしれルールを表現することができます。
A Set of Flags Flags are used to specify attributes of the rule that determine if this rule is the last one to be applied. The last rule is called the terminal rule and its output should be the intended result for the application. Flags are unique across Applications. An Application may specify that it is using a flag defined by yet another Application but it must use that other Application's definition. One Application cannot redefine a Flag used by another Application. This may mean that a registry of Flags will be needed in the future but at this time it is not a requirement.
フラグフラグのセットは、このルールが適用される最後のものであるかどうかを判断ルールの属性を指定するために使用されています。最後のルールは、端末のルールと呼ばれ、その出力は、アプリケーションのために意図した結果である必要があります。フラグは、アプリケーション全体で一意です。アプリケーションは、それはまた別のアプリケーションで定義されたフラグを使用していることを指定するかもしれませんが、それは、他のアプリケーションの定義を使用する必要があります。 1つのアプリケーションが別のアプリケーションで使用するフラグを再定義することはできません。これは、フラグのレジストリが将来的に必要とされるであろうことを意味するが、この時点でそれは必須ではありません。
A Description of Services Services are used to specify semantic attributes of a particular delegation branch. There are many cases where two delegation branches are identical except that one delegates down to a result that provides one set of features while another provides some other set. Features may include operational issues such as load balancing, geographically based traffic segregation, degraded but backwardly compatible functions for older clients, etc. For example, two rules may equally apply to a specific delegation decision for a string. One rule can lead to a terminal rule that produces information for use in high availability environments while another may lead to an archival service that may be slower but is more stable over long periods of time.
サービスサービスの説明は、特定の委任ブランチの意味属性を指定するために使用されています。ダウン他は他のいくつかのセットを提供しながら、機能の1セットを提供し、結果には、2本の委任枝がその1人の代表団を除いて同一である場合が多いです。特長は、ロードバランシングなどの運用上の問題を含むこともできるなど、地理的に基づいて、トラフィックの分離、劣化したが、古いクライアントのための下位互換性の機能、例えば、2つのルールが同じように文字列のための具体的な代表団の決定に適用される場合があります。一つのルールは、別のは遅くなるが、長時間にわたってより安定であることができるアーカイブサービスにつながる可能性がありながら、高可用性環境で使用するための情報を生成する端末ルールをもたらすことができます。
A Substitution Expression This is the actual string modification part of the rule. It is a combination of a POSIX Extended Regular Expression [8] and a replacement string similar to Unix sed-style substitution expression.
代入式は、これは、ルールの実際の文字列の変更部分です。これは、POSIX拡張正規表現[8]およびUnixのsedのスタイルの置換式に似置換文字列の組み合わせです。
The character set(s) that the substitution expression is in and can act on are dependent both on the Application and on the Database being used. An Application must define what the allowed character sets are for the Application Unique String. A DDDS Database specification must define what character sets are required for producing its keys and for how the substitution expression itself is encoded. The grammar-required characters below only have meaning once a specific character set is defined for the Database and/or Application.
代入式がであり、アプリケーション上で、使用しているデータベースの両方に依存しているに基づいて行動できることを文字セット（複数可）。アプリケーションは、許可された文字セットはアプリケーション固有文字列のためのものであるかを定義しなければなりません。 DDDSデータベースの仕様では、文字セットは、その鍵を生成するためと置換式自体のエンコード方法のために必要とされるかを定義しなければなりません。一度だけ、特定の文字セットを意味している以下の文法、必要な文字データベースおよび/またはアプリケーションのために定義されています。
The syntax of the Substitution Expression part of the rule is a sed-style substitution expression. True sed-style substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow this grammar:
ルールの置換式の部分の構文は、SEDスタイルの代入式です。真のsedのスタイルの置換式は、様々な理由のため、このアプリケーションでの使用に適していない、したがって、正規表現フィールドの内容は、この文法に従う必要があります。
subst-expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'> ; All occurrences of a delim_char in a subst_expr ; must be the same character.> ere = <POSIX Extended Regular Expression> repl = *(string / backref) string = *(anychar / escapeddelim) anychar = <any character other than delim-char> escapeddelim = "\" delim-char backref = "\" POS-DIGIT flags = "i" POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
SUBST-exprの= DELIM-CHAR EREでdelim-charをREPLでdelim-のchar *フラグDELIM-CHAR = "/" / "！" / <ない「POS-DIGIT」または「フラグ」のいかなるオクテット>。 subst_exprでdelim_charのすべての出現。同じ文字でなければなりません。> ERE = <POSIX拡張正規表現> REPL = *（文字列/後方参照）文字列= *（anychar / escapeddelim）anychar = <delimを-文字以外の任意の文字> escapeddelim = "\" でdelim-CHAR後方参照= "\" POS-DIGITフラグ= "I" POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / " 9"
The result of applying the substitution expression to the String MUST result in a key which obeys the rules of the Database (unless of course it is a Terminal Rule in which case the output follows the rules of the application). Since it is possible for the regular expression to be improperly specified, such that a non-conforming key can be constructed, client software SHOULD verify that the result is a legal database key before using it.
（もちろん、それは出力がアプリケーションの規則に従った場合には、ターミナルルールでない限り）データベースの規則に従うキーをもたらさなければなりません文字列に置換式を適用した結果。正規表現が不適切不適合キーを構築することができるように、指定することは可能であるので、クライアントソフトウェアは、結果がそれを使用する前に、法的なデータベース・キーがあることを確認する必要があります。
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部分で後方参照式が代入式のERE部分に「（」と「）」で囲まれた文字の（空）の文字列に置き換えられます。 Nは1〜9、包括的なから一桁です。これは、「（」とのマッチングに続く「）」N番目の後方参照表現、N番目から始まるものを指定します。例えば、ERE
(A(B(C)DE)(F)G)
（あ（Ｂ（Ｃ）で）（Ｆ）Ｇ）
has backref expressions:
後方参照表現があります。
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = error - no matching subexpression
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. This flag has meaning only when both the Application and Database define a character set where case insensitivity is valid.
「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つの非エスケープの発生がなければなりません。区切り文字のエスケープ出現は、その文字の出現と解釈されますので、数字は区切り文字として使用してはいけません。 Backrefsは数字列が、この許可されたと混同されるだろう。フラグが代入式で指定されている場合も同様に、区切り文字もフラグ文字であってはなりません。
The following is the exact DDDS algorithm:
以下では、正確なDDDSアルゴリズムです：
1. The First Well Known Rule is applied to the Application Unique String which produces a Key.
1.まず、よく知られているルールは、キーを生成したアプリケーション固有文字列に適用されます。
2. The Application asks the Database for the ordered set of Rules that are bound to that Key (see NOTE below on order details).
2.アプリケーションは、（注文の詳細に下記注を参照）、そのキーにバインドしているルールの順序付きセットのデータベースを要求します。
3. The Substitution Expression for each Rule in the list is applied, in order, to the Application Unique String until a non-empty string is produced. The position in the list is noted and the Rule that produced the non-empty string is used for the next step. If the next step rejects this rule and returns to this step then the Substitution Expression application process continues at the point where it left off. If the list is exhausted without a valid match then the application is notified that no valid output was available.
3.リスト内の各ルールのための代替表現は、非空の文字列が生成されるまで、アプリケーション固有文字列に順番に適用されます。リスト内の位置が注目され、非空の文字列を生成したルールは、次の工程のために使用されます。次のステップは、このルールを拒否し、このステップに戻った場合、代入式のアプリケーションプロセスは、中断点に続きます。リストは有効な一致せずに排出された場合、アプリケーションは有効な出力が利用できなかったことが通知されます。
4. If the Service description of the rule does not meet the client's requirements, go back to step 3 and continue through the already retrieved list of rules. If it does match the client's requirements then this Rule is used for the next step. If and only if the client is capable of handling it and if it is deemed safe to do so by the Application's specification, the client may make a note of the current Rule but still return to step 3 as though it had rejected it. In either case, the output of this step is one and only one Rule.
4.ルールのサービス内容は、クライアントの要件を満たしていない場合は、手順3とルールのすでに取得リストを続けるために戻って行きます。それは、クライアントの要求に合致しなければ、この規則は、次の工程のために使用されています。クライアントは、それを処理することが可能である、アプリケーションの仕様によってそうすることが安全であると見なされた場合、クライアントは、現在のルールをメモしておくことがありますが、それはそれを拒否していたかのように、まだステップ3に戻ります。場合にのみ、いずれの場合も、このステップの出力は、唯一のルールです。
5. If the Flags part of the Rule designate that this Rule is NOT Terminal, go back to step 2 with the substitution result as the new Key.
5.ルールの国旗の一部は、新しいキーとして、置換結果で、ステップ2に戻って、このルールが端末でないことを指定する場合。
6. Notify the Application that the process has finished and provide the Application with the Flags and Services part of the Rule along with the output of the last Substitution Expression.
6.プロセスが完了したアプリケーションに通知し、最後の代入式の出力と一緒にルールの国旗やサービスの一部を使用したアプリケーションを提供しています。
NOTE 1: In some applications and/or databases the result set can express the case where two or more Rules are considered equal. These Rules are treated as the same Rule, each one possibly having a Priority which is used to communicate a preference for otherwise equivalent Rules. This allows for Rules to act as fallbacks for others. It should be noted that this is a real Preference, not a load balancing mechanism. Applications should define the difference carefully.
注1：結果セットは、2つの以上のルールが同じであると考えられる場合を表現することができ、いくつかのアプリケーションおよび/またはデータベースで。これらのルールは、それぞれがおそらくそうでない場合は同等のルールの優先度を通信するために使用される優先順位を有する、同じルールとして扱われます。これは、他の人のためのフォールバックとして機能するようにルールが可能になります。本当の好みではなく、負荷分散メカニズムであることに留意すべきです。アプリケーションは慎重に違いを定義する必要があります。
NOTE 2: Databases may or may not have rules that determine when and how records within that database expire (expiration dates, times to live, etc.). These expiration mechanisms must be adhered to in all cases. Specifically, since the expiration of a databases record could cause a new Rule to be retrieved that is inconsistent with previous Rules, while in the algorithm any attempts to optimize the process by falling back to previous keys and Rules MUST ensure that no previously retrieved Rule has expired. If a Rule has expired then the application MUST start over at Step 1.
注2：データベースの場合や、どのようにそのデータベース内のレコードの有効期限が切れる（有効期限は、時間がなど、生きるために）決定のルールを持っていない可能性があります。これらの有効期限のメカニズムは、すべてのケースでに付着しなければなりません。アルゴリズムの前のキーとルールにフォールバックすることによりプロセスを最適化するために、任意の試みは全く以前に取得したルールを持っていないことを確認しなければならないが、具体的に、データベース・レコードの有効期限は、以前のルールと矛盾すること検索する新しいルールを引き起こす可能性があるので有効期限が切れています。ルールの有効期限が切れた場合、アプリケーションは、ステップ1で、最初からやり直す必要があります。
In order for this algorithm to have any usefulness, a specification must be written describing an application and one or more databases. In order to specify an application the following pieces of information are required:
このアルゴリズムは、任意の有用性を持たせるために、仕様は、アプリケーションと1つ以上のデータベースを記述する書き込まなければなりません。アプリケーションを指定するために、以下の情報が必要です。
Application Unique String: This is the only string that the rewrite rules will apply to. The string must have some regular structure and be unique within the application such that anyone applying Rules taken from the same Database will end up with the same Keys. For example, the URI Resolution application defines the Application Unique String to be a URI.
アプリケーション固有文字列：これは、書き換えルールを適用することを唯一の文字列です。文字列には、いくつかの規則的な構造を持っているし、同じデータベースから取得した誰も適用するルールは同じキーで終了するようなアプリケーション内で一意でなければなりません。例えば、URI解決アプリケーションは、URIされるアプリケーション固有の文字列を定義します。
No application is allowed to define an Application Unique String such that the Key obtained by a rewrite rule is treated as the Application Unique String for input to a new rule. This leads to sendmail style rewrite rules which are fragile and error prone. The one single exception to this is when an Application defines some flag or state where the rules for that application are suspended and a new DDDS Application or some other arbitrary set of rules take over. If this is the case then, by definition, none of these rules apply. One such case can be found in the URI Resolution application which defines the 'p' flag which states that the next step is 'protocol specific' and thus outside of the scope of DDDS.
何のアプリケーションが書き換え規則によって得られたキーを新しいルールへの入力のためのアプリケーション固有の文字列として扱われるように、アプリケーション固有の文字列を定義することが許されません。これが発生しやすい脆弱でエラーが発生しているスタイルの書き換えルールをsendmailにつながります。アプリケーションは、そのアプリケーションのためのルールが中断されるいくつかのフラグまたは状態を定義し、新しいDDDSアプリケーションまたはルールのいくつかの他の任意のセットを引き継ぐ場合にこれに対する一つの例外があります。これはその後、そうであるならば、定義によって、これらのルールのどれも適用されません。そのような場合は、次のステップは、したがって、DDDSの範囲の外「特定のプロトコル」であると述べている「P」のフラグを定義するURI解決出願に見出すことができます。
First Well Known Rule: This is the first rule that, when applied to the Application Unique String, produces the first valid Key. It can be expressed in the same form as a Rule or it can be something more complex. For example, the URI Resolution application might specify that the rule is that the sequence of characters in the URI up to but not including the first colon (the URI scheme) is the first Key.
まずよく知られているルール：これは、アプリケーション固有文字列に適用された場合、最初の有効なキーを生成する第1のルールです。それはルールと同じ形式で表現することができるか、それはより複雑なものにすることができます。例えば、URI解決アプリケーションは、ルールはURIの文字までが、最初のコロン（URIスキーム）を含めていないの順序は最初のキーであるということであることを指定するかもしれません。
Valid Databases: The application can define which Databases are valid. For each Database the Application must define how the First Well Known Rule's output (the first Key) is turned into something that is valid for that Database. For example, the URI Resolution application could use the Domain Name System (DNS) as a Database. The operation for turning this first Key into something that was valid for the database would be to to turn it into some DNS-valid domain-name. Additionally, for each Database an Application defines, it must also specify what the valid character sets are that will produce the correct Keys. In the URI Resolution example shown here, the character set of a URI is 7 bit ASCII which matches fairly well with DNS's 8 bit limitation on characters in its zone files.
有効なデータベース：アプリケーションが有効であるデータベースを定義することができます。各データベースのアプリケーションは、まずよく知られているルールの出力（最初のキー）は、そのデータベースに対して有効であるものになっている方法を定義しなければなりません。たとえば、URIの解像度アプリケーションがデータベースとしてドメインネームシステム（DNS）を使用することができます。データベースのために有効であったものに、この最初のキーを回すための操作は、いくつかのDNS-有効なドメイン名にそれを回すためにすることです。また、アプリケーションが定義され、データベースごとに、それはまた、有効な文字セットが正しいキーを生成することが何であるかを指定する必要があります。ここに示したURIの解決の例では、URIの文字セットは、そのゾーンファイル内の文字の上にDNSの8ビット制限とかなりよく一致した7ビットのASCIIです。
Expected Output: The Application must define what the expected output of the Terminal Rule should be. For example, the URI Resolution application is concerned with finding servers that contain authoritative data about a given URI. Thus the output of the terminal rule would be information (hosts, ports, protocols, etc.) that would be used to contact that authoritative server.
予想される出力：アプリケーションは、ターミナルルールの予想出力はどうあるべきかを定義しなければなりません。例えば、URI解像度アプリケーションが指定されたURIに関する信頼できるデータが含まれているサーバを見つけることに関係しています。したがって、端末ルールの出力は、認証サーバに連絡するために使用される情報（ホスト、ポート、プロトコル、等）であろう。
In the past there has been some confusion concerning load balancing and the use of the DDDS 'Priority'. Applications should be aware that the Priority of a given rule is just that: a way of specifying that one rule is "better, faster, cheaper" than another. If an application needs some method of allowing a client to load balance between servers (i.e., weighted random selection, etc.) then it should do so outside the DDDS algorithm. For example, Applications that make use of the DNS Database may use the SRV record as a way of signifying that a particular service is actually handled by several hosts cooperating with each other. The difference being that load balancing is done between hosts that are identical to each other where as DDDS is concerned with delegation paths that have some particular feature set or administrative domain.
過去には、ロードバランシングとDDDS「優先順位」の使用に関するいくつかの混乱がありました。一つのルールが他よりも「より良いより速く、より安く」であることを指定する方法：アプリケーションは、特定のルールの優先順位だけではあることに注意する必要があります。アプリケーションは、クライアントが（などすなわち、重み付けランダム選択、）のサーバー間で負荷を分散することを可能にするいくつかの方法を必要とする場合、それはDDDSアルゴリズム外に行う必要があります。たとえば、DNSデータベースを利用するアプリケーションは、特定のサービスが実際にお互いに協力し、いくつかのホストによって処理されていることを意味する方法としてSRVレコードを使用することができます。差は、そのロード・バランシングはDDDSは、いくつかの特定の機能セットまたは管理ドメインを有する委任パスに関係している通りであり、互いに同一であるホスト間で行われています。
Additionally, any Application must have at least one corresponding Database from which to retrieve the Rules. It is important to note that a given Database may be used by more than one Application. If this is the case, each rule must be use some combination of its Services and/or substitution expression to match only those Application Unique Strings for which it is valid.
さらに、任意のアプリケーションは、ルールを取得するから少なくとも1つの対応するデータベースを持っている必要があります。特定のデータベースが複数のアプリケーションで使用できることに留意することが重要です。このような場合は、各ルールは、それが有効であるのみ適用ユニークな文字列に一致するように、いくつかのサービスの組み合わせおよび/または置換式を使用しなければなりません。
A Database specification must include the following pieces of information:
データベースの仕様は、以下の情報を含める必要があります。
General Specification: The Database must have a general specification. This can reference other standards (SQL, DNS, etc.) or it can fully specify a novel database system. This specification MUST be clear as to what allowed character sets exist in order to know in which character set the Keys and Rules are encoded.
一般仕様：データベースは、一般的な仕様を持っている必要があります。これは、他の規格（SQL、DNSなど）を参照することができ、またはそれは完全に新規のデータベースシステムを指定することができます。この仕様は、文字セットが文字キーとルールがエンコードされている設定したかを知るために存在して許可するものに関しては明確でなければなりません。
Lookup Procedure: This specifies how a query is formulated and submitted to the database. In the case of databases that are used for other purposes (such as DNS), the specification must be clear as to how a query is formulated specifically for the database to be a DDDS database. For example, a DNS based Database must specify which Resource Records or Query Types are used.
検索手順：これは、クエリが処方され、データベースに送信される方法を指定します。 （DNSなどの）他の目的のために使用されるデータベースの場合には、仕様は、クエリが具体DDDSデータベースするデータベースのために処方される方法として明確でなければなりません。たとえば、DNSベースのデータベースは、リソースレコードまたはクエリタイプを使用するかを指定しなければなりません。
Key Format: If any operations are needed in order to turn a Key into something that is valid for the database then these must be clearly defined. For example, in the case of a DNS database, the Keys must be constructed as valid domain-names.
キーフォーマット：すべての操作は、これらが明確に定義されている必要があり、データベースの有効な何かにキーを回すために必要な場合。たとえば、DNSデータベースの場合、キーは有効なドメイン名として構築されなければなりません。
Rule Format: The specification for the output format of a rule.
ルールのフォーマット：ルールの出力形式の仕様。
Rule Insertion Procedure: A specification for how a Rule is inserted into the database. This can include policy statements about whether or not a Rule is allowed to be added.
挿入手順をルール：ルールをデータベースに挿入する方法の仕様を。これは、ルールを追加することを許可するかどうかについてのポリシーステートメントを含めることができます。
Rule Collision Avoidance: Since a Database may be used by multiple Applications (ENUM and URI Resolution for example), the specification must be clear about how rule collisions will be avoided. There are usually two methods for handling this: 1) disallow one key from being valid in two different Applications; 2) if 1 isn't possible then write the substitution expression such that the regular expression part contains enough of the Application Unique String as part of its match to differentiate between the two Applications.
衝突回避ルール：データベースは、複数のアプリケーション（例えばENUMとURI解像度）で使用することができるので、仕様はルールの衝突を回避する方法について明確にする必要があります。これを処理するための2つの方法は、通常あります：1）2つの異なるアプリケーションに有効であることから、一つのキーを許可しません。 1ができない場合2）その後、正規表現の一部を2つのアプリケーションを区別するためにその試合の一部として適用ユニークな文字列を十分に含むように代入式を記述します。
The examples given here are for pedagogical purposes only. They are specifically taken from ficticious applications that have not been specified in any published document.
ここに挙げた例は、教育的な目的のみのためのものです。彼らは、特に任意の公表文書で指定されていない架空のアプリケーションから取得されます。
In this example imagine a system setup where all automobile manufacturers come together and create a standardized part numbering system for the various parts (nuts, bolts, frames, instruments, etc.) that make up the automobile manufacturing and repair process. The problem with such a system is that the auto industry is a very distributed system where parts are built by various third parties distributed around the world. In order to find information about a given part a system must be able to find out who makes that part and contact them about it.
この例では、すべての自動車メーカーが一緒にシステム設定を想像し、自動車製造及び修復プロセスを構成する様々な部品（ナット、ボルト、フレーム、器具、等）のための標準化された部分のナンバリングシステムを作成します。このようなシステムの問題は、自動車産業は部品が世界中に分散し、さまざまなサードパーティによって構築されている非常に分散システムであるということです。指定された部分についての情報を見つけるためにシステムがその部分を作る人を見つけると、それについてのそれらに連絡することができなければなりません。
To facilitate this distributed system the identification number assigned to a part is assigned hierarchically such that the first 5 digits make up a parts manufacturer ID number. The next 3 digits are an auto line identifier (Ford, Toyota, etc.). The rest of the digits are assigned by the parts manufacturer according to rules that the manufacturer decides.
この分散系を容易にする部分に割り当てられた識別番号は、最初の5桁は、部品メーカーのID番号を構成することが階層よう割り当てられます。次の3桁は、自動ライン識別子（フォード、トヨタ、等）です。数字の残りは製造業者が決定するルールに従って、部品メーカによって割り当てられます。
The auto industry decides to use the DDDS to create a distributed information retrieval system that routes queries to the actual owner of the data. The industry specifies a database and a query syntax for retrieving rewrite rules (the APIDA Network) and then specifies the Auto Parts Identification DDDS Application (APIDA).
自動車産業は、データの実際の所有者にそのルート照会分散型情報検索システムを作成するDDDSを使用することを決定します。業界では、データベースと書き換えルールを取得するためのクエリ構文（APIDAネットワーク）を指定して、自動車部品の識別DDDSアプリケーション（APIDA）を指定します。
The APIDA specification would define the following:
APIDA仕様は以下のように定義します：
o Application Unique String: the part number.
Oアプリケーション固有文字列：部品番号。
o First Well Known Rule: take the first 5 digits (the manufacturers ID number) and use that as the Key.
Oまずよく知られているルール：最初の5桁（メーカーのID番号）を取り、キーとして使用していること。
o Valid Databases: The APIDA Network.
O有効なデータベース：APIDAネットワーク。
o Expected Output: EDIFAC information about the part.
O予想される出力：一部についてEDIFAC情報。
The APIDA Network Database specification would define the following:
APIDAネットワークデータベースの仕様は以下のように定義します：
o General Specification: a network of EDI enabled databases and services that, when given a subcomponent of a part number will return an XML encoded rewrite rule.
O一般仕様：部品番号のサブコンポーネントを与え、EDI対応データベースとサービスのネットワークは、XMLエンコードされた書き換えルールを返します。
o Lookup Procedure: following normal APIDA Network protocols, ask the network for a rewrite rule for the Key.
検索手順O：通常APIDAネットワークプロトコルに従って、キーの書き換えルールのためのネットワークをお願いします。
o Key Format: no conversion is required.
Oキーフォーマット：何の変換は必要ありません。
o Rule Format: see APIDA Network documentation for the XML DTD.
Oルールフォーマット：XMLのDTDのためAPIDAネットワークのマニュアルを参照してください。
o Rule Insertion Procedure: determined by the authority that has control over each section of the part number. I.e., in order to get a manufacturer ID you must be a member of the Auto Parts Manufacturers Association.
O挿入手順をルール：部品番号の各部を制御している機関によって決定されます。すなわち、製造者のIDを取得するために、あなたは自動車部品製造業者協会のメンバーである必要があります。
In order to illustrate how the system would work, imagine the part number "4747301AB7D". The system would take the first 5 digits, '47473' and ask the network for that Rewrite Rule. This Rule would be provided by the parts manufacturers database and would allow the manufacturer to either further sub-delegate the space or point the querier directly at the EDIFAC information in the system.
システムが動作する方法を説明するために、部品番号「4747301AB7D」を想像してみてください。このシステムは、「47473」を最初の5桁を取り、その書き換えルールのためのネットワークを求めるだろう。このルールは、部品データベースをメーカーや製造業者がさらに空間サブ委任又はシステムにおけるEDIFAC情報を直接クエリアをポイントするか可能にすることによって提供されます。
In this example let's suppose that the manufacturer returns a Rule that states that the next 3 digits should be used as part of a query to their service in order to find a new Rule. This new Rule would allow the parts manufacturer to further delegate the query to their parts factories for each auto line. In our example part number the number '01A' denotes the Toyota line of cars. The Rule that the manufacturer returns further delegates the query to a supply house in Japan. This rule also denotes that this Rule is terminal and thus the result of this last query will be the actual information about the part.
この例では、の製造業者は、次の3桁の数字は、新しいルールを見つけるために彼らのサービスへのクエリの一部として使用されるべきであると述べているルールを返すと仮定してみましょう。この新しいルールは、部品メーカーは、さらに、各自動車ラインのための彼らの部品工場にクエリーを委任することができるようになります。私たちの例の部品番号で番号「01A」は車のトヨタ線です。メーカーは日本での供給の家に、さらに代表者にクエリを返すルール。このルールは、このルールがターミナルであることを意味し、したがって、この最後のクエリの結果は、一部について実際の情報となります。
This example is very similar to the last since the documents in this system can simply be thought of as the auto part in the last example. The difference here is that the information about the document is kept very close to the author (usually on their desktop). Thus there is the probability that the number of delegations can be very deep. Also, in order to keep from having a large flat space of authors, the authors are organized by organizations and departments.
このシステム内の文書は、単に最後の例では自動車部品と考えることができますので、この例では、最後に非常に似ています。ここでの違いは、ドキュメントに関する情報は、作者（通常は自分のデスクトップ上）に非常に近く保たれているということです。したがって、代表団の数は非常に深いことができる可能性があります。また、著者の大型フラットスペースを持っていることから保つために、著者は、組織や部門別に整理されています。
Let's suppose that the Application Unique String in this example looks like the following:
のは、この例では、アプリケーション固有文字列には、次のようになっていることを仮定してみましょう：
<organization>-<department>-<author>:<project>-<bookcase>-<book>
<組織> - <部署> - <著者>：<プロジェクト> - <本棚> - <本>
The Application specification would look like this:
アプリケーションの仕様は次のようになります。
o Application Unique String: the Document ID string given above.
上記の文書IDの文字列：アプリケーション固有文字列O。
o First Well Known Rule: the characters up to but not including the first '-' is treated as the first Key.
Oまずよく知られているルール：最初含む文字までではなく、「 - 」最初のキーとして扱われます。
o Valid Databases: the DIS LDAP Directory.
O有効なデータベース：DIS LDAPディレクトリ。
o Expected Output: a record from an LDAP server containing bibliographic information about the document in XML.
O予想される出力：XMLでの文書についての書誌情報を含むLDAPサーバーからレコード。
The Database specification for the DIS LDAP Directory would look like this:
DIS LDAPディレクトリのデータベースの仕様は次のようになります。
o General Specification: the Database uses the LDAP directory service. Each LDAP server has a record that contains the Rewrite Rule. Rules refer to other LDAP servers using the LDAP URL scheme.
O一般仕様：データベースは、LDAPディレクトリサービスを使用しています。各LDAPサーバは、書き換え規則を含むレコードを持っています。ルールはLDAPのURLスキームを使用して他のLDAPサーバーを参照してください。
o Lookup Procedure: using standard LDAP queries, the client asks the LDAP server for information about the Key.
検索手順O：標準のLDAPクエリを使用して、クライアントがキーについては、LDAPサーバーを要求します。
o Key Format: no conversion is necessary.
Oキーフォーマット：変換は必要ありません。
o Rule Format: See the LDAP Rewrite Rule specification.
Oルールフォーマット：LDAP書き換え規則の仕様を参照してください。
o Rule Insertion Procedure: See the procedures published by the entity that has authority over that section of the DIS tree. The first section, the organization, is owned by the DIS Agency.
O挿入手順をルール：DISツリーのその部分の上に権限を有するエンティティによって公開された手順を参照してください。最初のセクション、組織は、DIS庁が所有しています。
In this example, the first lookup is for the organization's Rule. At that point the organization may point the client directly at some large, organization wide database that contains the expected output. Other organizations may decentralize this process so that Rules end up delegating the query all the way down to the authors document management environment of choice.
この例では、最初の検索は、組織のルールのためです。その時点で、組織が期待される出力が含まれているいくつかの大規模な、組織全体のデータベースにクライアントを直接指し示すことができます。ルールはすべての方法の選択肢の作者の文書管理環境までクエリを委任終わるように、他の組織では、このプロセスを分散化します。
This document simply defines the DDDS algorithm and thus, by itself, does not imply any security issues. It is when this algorithm is coupled with a Database and an Application that security considerations can be known well enough to enumerate them beyond simply saying that dynamic delegation points are a possible point of attack.
この文書では、単にDDDSアルゴリズムを定義するため、それ自体で、すべてのセキュリティ上の問題を意味するものではありません。このアルゴリズムは、データベースやセキュリティ上の考慮事項は、単にダイナミック委任ポイントが攻撃の可能地点であることを言っ超えて、それらを列挙することも十分に知ることができるアプリケーションに結合されている場合もございます。
This document does not create any requirements on the IANA. Database and Application specifications may have considerable requirements but they cannot be enumerated here.
このドキュメントは、IANA上の任意の要求を作成しません。データベースとアプリケーションの仕様には、かなりの要件がある場合がありますが、彼らはここに列挙することはできません。
References
リファレンス
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）解像度アプリケーション"、RFC 3404、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、RFC 3405、2002年10月。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6]堀、R.、 "URN構文"、RFC 2141、1997月。
[7] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[7] Sollins、K.、 "ユニフォームリソース名前解決の建築原則"、RFC 2276、1998年1月。
[8] The Institute of Electrical and Electronics Engineers, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.
[8]電気電子技術者協会、「情報技術のためのIEEE規格 - ポータブルオペレーティングシステムインタフェース（POSIX） - パート2：シェルとユーティリティ（第1巻）」、IEEE規格1003.2-1992、ISBN 1-55937- 255から9、1993年1月。
[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[9] Mealling、M.およびR.ダニエル、 "命名権限ポインタ（NAPTR）DNSリソースレコード"、RFC 2915、2000年8月。
[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[10] Faltstrom、P.、 "E.164番号とDNS"、RFC 2916、2000年9月。
[11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[11]ダニエル、R.とM. Mealling、 "ドメインネームシステムを使用して統一リソース識別子の決議"、RFC 2168、1997年6月。
Author's Address
著者のアドレス
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
マイケル・メオーリングベリサイン21345 Ridgetopサークルスターリング、バージニア州20166米国
EMail: michael@neonym.net URI: http://www.verisignlabs.com
電子メール：michael@neonym.net URI：http://www.verisignlabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。