[要約] RFC 3402は、Dynamic Delegation Discovery System（DDDS）のアルゴリズムについての詳細な説明を提供しています。このRFCの目的は、DDDSの実装と運用に関するガイドラインを提供することです。
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
動的委任発見システム（DDDS）パート2：アルゴリズム
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.
Copyright（c）The Internet Society（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）アルゴリズムについて説明します。適切に形成された変換ルールは、文字列に関連する情報の管理の委任を反映しています。このドキュメントは、「動的委任ディスカバリーシステム（DDDS）パート1：包括的なDDD」（RFC 3401）で完全に指定されたシリーズの一部でもあります。他のシリーズを読むことなく、このシリーズのドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
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）を使用してデータへの文字列の怠zyな結合を実装します。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）パート1：包括的な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の歴史は、ユニフォームのリソース名ワーキンググループによって行われた仕事からの進化です。均一なリソース名（URNS）[6]が元々策定されたとき、（設計上）ネットワークの場所に関する情報が含まれていないURNの権威あるサーバーを見つけたいという願望がありました。URNに適用できるルールのデータベースを使用して、特定の構文のチャンクに関する情報を見つけることができるシステムが策定されました。このシステムはもともとResolver Discovery Service（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.
時間が経つにつれて、他のシステムがこの同じアルゴリズムとインフラストラクチャを他の非ARN関連システムに適用し始めました（DDDを使用する他の方法の例については、セクション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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
端末ルールは、使用すると、別のデータベースキーではなく、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.
サービス共通のルールデータベースを使用して、異なるサービスを特定のアプリケーションの一意の文字列に関連付けることができます。たとえば、さまざまなプロトコル関数、さまざまな運用特性、地理的分離、後方互換性など。可能なサービスの違いは、電子メール/ FAX/ボイスメールのサービスを受信し、ウェブサーバー上のロードバランス、近くのミラーサーバーの選択、コスト対パフォーマンストレード - オフなど。これらのサービスは、サービスの観点から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.).
アプリケーションの一意の文字列には、ルールを適用できるいくつかの定期的な語彙構造があるという基本的な仮定です。DDDの仮定は、委任の決定を下すために使用された語彙要素が、アプリケーションの一意の文字列自体に含まれるほど簡単であるということです。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.
一連のフラグフラグは、このルールが適用される最後のルールであるかどうかを決定するルールの属性を指定するために使用されます。最後のルールは端末ルールと呼ばれ、その出力はアプリケーションの意図された結果である必要があります。フラグはアプリケーション全体でユニークです。アプリケーションは、さらに別のアプリケーションで定義されたフラグを使用していることを指定する場合がありますが、他のアプリケーションの定義を使用する必要があります。あるアプリケーションは、別のアプリケーションで使用されているフラグを再定義できません。これは、将来フラグのレジストリが必要になることを意味するかもしれませんが、現時点では要件ではありません。
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つの機能が1つの機能を提供し、別のセットが他のセットを提供する結果に委任することを除いて、2つの代表団のブランチが同一である多くのケースがあります。機能には、負荷分散、地理的にベースのトラフィックの分離、古いクライアントの劣化したが後方互換機能などの運用上の問題が含まれます。たとえば、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スタイルの置換式は、さまざまな理由でこのアプリケーションでの使用には適していないため、再gExpフィールドの内容はこの文法に従わなければなりません。
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"
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部分の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. 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つある必要があります。デリミッター文字の脱出された発生は、そのキャラクターの発生と解釈されるため、数字は区切り文字として使用してはなりません。これが許可されていれば、バックレフは文字通りの数字と混同されます。同様に、置換式でフラグが指定されている場合、区切り文字もフラグ文字であってはなりません。
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に戻ることができます。どちらの場合でも、このステップの出力は1つのルールのみです。
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スタイルにつながります。これの1つの例外は、アプリケーションがそのアプリケーションのルールが停止されているフラグまたは状態を定義し、新しいDDDSアプリケーションまたは他の任意のルールセットを引き継ぐ場合です。この場合、定義上、これらのルールのいずれも適用されません。そのようなケースの1つは、次のステップが「プロトコル固有」であり、したがってDDDの範囲外であることを示す「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.
最初によく知られているルール：これは、アプリケーションの一意の文字列に適用されると、最初の有効なキーを生成する最初のルールです。それは原則と同じ形で表現することができます、またはそれはより複雑なものになる可能性があります。たとえば、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-Validドメイン名に変えることです。さらに、アプリケーションが定義する各データベースについて、有効な文字セットが正しいキーを生成するものを指定する必要があります。ここに示すURI解像度の例では、URIの文字セットは7ビットASCIIであり、ゾーンファイルの文字に対するDNSの8ビット制限とかなりよく一致しています。
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レコードを使用する場合があります。違いは、DDDが特定の機能セットまたは管理ドメインを持つ委任パスに関係するように、互いに同一のホスト間で負荷分散が行われることです。
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.
ルールの衝突回避：データベースは複数のアプリケーション（列挙やURI解像度など）で使用される可能性があるため、ルールの衝突がどのように回避されるかについては、仕様が明確でなければなりません。通常、これを処理するには2つの方法があります。1）2つの異なるアプリケーションで1つのキーが有効であることを禁止します。2）1が不可能な場合は、正規式の部分に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).
自動車業界は、DDDを使用して、データの実際の所有者にクエリをルーティングする分散情報検索システムを作成することを決定します。業界は、書き換えルール（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 有効なデータベース：アピダネットワーク。
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 Networkドキュメントを参照してください。
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を取得するには、Auto Parts Manufacturers Associationのメンバーでなければなりません。
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」を想像してください。システムは、最初の5桁「47473」を取り、ネットワークにその書き換えルールを求めます。このルールは、部品メーカーデータベースによって提供され、メーカーがスペースをさらに下位にするか、システム内のEDIFAC情報をQuerierを直接指すことができます。
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.
o アプリケーション一意の文字列：上記のドキュメントID文字列。
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。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling、M。、「Dynamic Delogation Discovery System（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。、「Dynamic Delogation Discovery System（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）パート4：ユニフォームリソース識別子（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）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[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：シェルとユーティリティ（Vol。1）」、IEEE STD 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。and R. Daniel、「The Naming Authority Pointer（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] 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エディター機能の資金は現在、インターネット協会によって提供されています。