Network Working Group M. Mealling
Request for Comments: 3402 Verisign
Obsoletes: 2915, 2168 October 2002
Category: Standards Track
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）第二部分：算法
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）算法。格式良好的转换规则将反映与字符串关联的信息管理的委托。本文档也是“动态委托发现系统（DDDS）第一部分：综合DDDS”（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
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无关的系统（有关使用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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照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算法的各个通用部分指定实际值。应用程序必须定义应用程序唯一字符串、第一条已知规则以及一个或多个对应用程序有效的数据库的语法和语义。
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.
服务公共规则数据库可用于将不同的服务与给定的应用程序唯一字符串相关联；e、 例如，不同的协议功能、不同的操作特征、地理隔离、向后兼容性等。可能的服务差异可能是电子邮件/传真/语音邮件的消息接收服务、web服务器上的负载平衡、选择附近的镜像服务器、成本与性能权衡，等等。这些服务作为规则的一部分包含，以允许应用程序根据一个分支的适用性或从服务的角度考虑另一个分支的适用性来做出分支决策。
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.
标记大多数应用程序将需要一种规则向应用程序发出信号的方式，即某些规则提供其他规则不提供的特定结果；e、 例如，不同的输出格式、扩展机制、终端规则信令等。大多数数据库将定义一个标志字段，应用程序可使用该字段对表示这些信号的各种值进行编码。
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 |
+------------------------------------+
+--------- 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.
优先级仅仅是一个数字，用于显示两条本来相等的规则中的哪一条可能具有优先级。这允许数据库表达可能提供大致相同结果的规则，但一个委托路径可能比另一个更快、更好、更便宜。
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.
服务的描述用于指定特定委派分支的语义属性。在许多情况下，两个委派分支是相同的，只是一个委派的结果提供了一组特性，而另一个委派的结果提供了另一组特性。功能可能包括操作问题，如负载平衡、基于地理位置的流量隔离、较旧客户端的降级但向后兼容的功能等。例如，两个规则可能同样适用于字符串的特定委派决策。一个规则可能导致生成用于高可用性环境的信息的终端规则，而另一个规则可能导致归档服务速度较慢，但在较长时间内更稳定。
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
替换表达式所在并可对其执行操作的字符集取决于应用程序和所使用的数据库。应用程序必须为应用程序唯一字符串定义允许的字符集。DDDS数据库规范必须定义所需的字符集
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.
生成其键以及替换表达式本身的编码方式。以下语法要求的字符仅在为数据库和/或应用程序定义了特定字符集后才有意义。
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样式的替换表达式。由于各种原因，True sed样式替换表达式不适合在此应用程序中使用，因此regexp字段的内容必须遵循以下语法：
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 *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部分中由“（”和“）”括起的（可能为空）字符串。N是从1到9的一个数字，包括在内。它指定第N个backref表达式，该表达式以第N个'（'并继续到匹配的'）'开头。例如，ERE
(A(B(C)DE)(F)G)
(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”标志时，任何backref替换都可以标准化为小写。只有当应用程序和数据库都定义了不区分大小写有效的字符集时，此标志才有意义。
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.
替换表达式中的第一个字符应用作分隔替换表达式组成部分的字符。在替换表达式中，分隔符字符必须正好出现三次非转义。由于分隔符字符的转义出现将被解释为该字符的出现，因此不能将数字用作分隔符。如果允许的话，backref将与文本数字混淆。类似地，如果在替换表达式中指定了标志，则分隔符字符也不能是标志字符。
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：在某些应用程序和/或数据库中，结果集可以表示两个或多个规则被视为相等的情况。这些规则被视为相同的规则，每个规则可能都有一个优先级，用于传达对其他等效规则的偏好。这允许规则充当其他规则的后备。应该注意的是，这是一种真正的偏好，而不是一种负载平衡机制。应用程序应该仔细定义差异。
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:
为了使该算法有任何用处，必须编写一个描述应用程序和一个或多个数据库的规范。要指定应用程序，需要以下信息：
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
不允许任何应用程序定义应用程序唯一字符串，以便将重写规则获得的密钥视为输入新规则的应用程序唯一字符串。这导致了sendmail风格的重写规则非常脆弱且容易出错。唯一的例外是，当应用程序定义某个标志或状态时，该应用程序的规则在其中
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.
挂起，新的DDDS应用程序或其他任意规则集接管。如果是这种情况，那么根据定义，这些规则都不适用。在URI解析应用程序中可以找到这样一种情况，该应用程序定义了“p”标志，该标志表示下一步是“特定于协议的”，因此超出了DDDS的范围。
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有效域名。此外，对于应用程序定义的每个数据库，它还必须指定将生成正确密钥的有效字符集。在这里显示的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
在过去，关于负载平衡和DDDS“优先级”的使用存在一些混乱。应用程序应该知道，给定规则的优先级正是：一种指定一个规则比另一个规则“更好、更快、更便宜”的方法。如果应用程序需要某种方法来允许客户端在服务器之间进行负载平衡（即加权随机选择等），那么它应该在DDDS算法之外进行。例如，使用DNS数据库的应用程序可以使用SRV记录作为表示特定服务实际上由相互协作的多个主机处理的方式。不同之处在于负荷
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.
平衡是在相互相同的主机之间完成的，其中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.
此外，任何应用程序必须至少有一个相应的数据库，从中检索规则。需要注意的是，一个给定的数据库可能被多个应用程序使用。如果是这种情况，则每个规则都必须使用其服务和/或替换表达式的某种组合，以仅匹配其有效的应用程序唯一字符串。
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解析），因此规范必须明确如何避免规则冲突。通常有两种处理方法：1）禁止一个密钥在两个不同的应用程序中有效；2） 如果1不可能，则编写替换表达式，使正则表达式部分包含足够的应用程序唯一字符串作为其匹配的一部分，以区分两个应用程序。
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”。系统将获取前5位数字“47473”，并向网络询问重写规则。该规则将由零件制造商数据库提供，并允许制造商进一步转授空间，或将查询者直接指向系统中的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>
<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 预期输出：来自LDAP服务器的记录，其中包含有关XML文档的书目信息。
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）第二部分：算法”，RFC3402，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）第三部分：域名系统（DNS）数据库”，RFC3403，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）解析应用”，RFC3404，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.，“瓮语法”，RFC 21411997年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部分：外壳和实用程序（第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.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，2000年8月。
[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[10] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年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，弗吉尼亚州，美国20166
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
EMail: 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编辑功能的资金目前由互联网协会提供。