RFC3402 日本語訳
3402 Dynamic Delegation Discovery System (DDDS) Part Two: TheAlgorithm. M. Mealling. October 2002. (Format: TXT=38925 bytes) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
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.
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.
Mealling Standards Track [Page 1] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 1] RFC 3402 DDDS - The Algorithm October 2002
Table of Contents
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
1. Introduction
1. Introduction
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.
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.
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.
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.
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.
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.
Mealling Standards Track [Page 2] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 2] RFC 3402 DDDS - The Algorithm October 2002
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.
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.
This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as updates RFC 2276 [7].
This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as updates RFC 2276 [7].
2. Terminology
2. Terminology
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Mealling Standards Track [Page 3] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 3] RFC 3402 DDDS - The Algorithm October 2002
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.
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.
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.
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.
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.
3. The Algorithm
3. The Algorithm
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.
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.
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.).
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.).
Mealling Standards Track [Page 4] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 4] RFC 3402 DDDS - The Algorithm October 2002
Diagrammatically the algorithm looks like this:
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 | +------------------------------------+
Mealling Standards Track [Page 5] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 5] RFC 3402 DDDS - The Algorithm October 2002
3.1 Components of a Rule
3.1 Components of a Rule
A Rule is made up of 4 pieces of information:
A Rule is made up of 4 pieces of information:
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 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 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 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.
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.
3.2 Substitution Expression Syntax
3.2 Substitution Expression Syntax
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
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
Mealling Standards Track [Page 6] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 6] RFC 3402 DDDS - The Algorithm October 2002
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.
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:
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:
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.
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
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
(A(B(C)DE)(F)G)
(A(B(C)DE)(F)G)
has backref expressions:
has backref expressions:
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = error - no matching subexpression
\1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression
Mealling Standards Track [Page 7] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 7] RFC 3402 DDDS - The Algorithm October 2002
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.
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.
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.
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.3 The Complete Algorithm
3.3 The Complete Algorithm
The following is the exact DDDS algorithm:
The following is the exact DDDS algorithm:
1. The First Well Known Rule is applied to the Application Unique
String which produces a Key.
1. The First Well Known Rule is applied to the Application Unique String which produces a Key.
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. The Application asks the Database for the ordered set of Rules that are bound to that Key (see NOTE below on order details).
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. 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.
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. 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.
Mealling Standards Track [Page 8] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 8] RFC 3402 DDDS - The Algorithm October 2002
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. 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.
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. 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.
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.
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.
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.
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.
4. Specifying an Application
4. Specifying an Application
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:
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.
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.
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
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
Mealling Standards Track [Page 9] RFC 3402 DDDS - The Algorithm October 2002
Mealling Standards Track [Page 9] RFC 3402 DDDS - The Algorithm October 2002
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.
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.
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.
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.
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.
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.
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.
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.
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'優先権'の使用がありました。 アプリケーションは与えられた規則のPriorityがまさしくそれであることを意識しているべきです: その1つの規則を指定する方法は「より良く、より速く、別のものより安いです」。 アプリケーションがクライアントがサーバ(すなわち、荷重しているランダム・セレクションなど)の間のバランスをロードするのを許容する何らかのメソッドを必要とするなら、それはDDDSアルゴリズムの外でそうするべきです。 例えば、DNS Databaseを利用するApplicationsは特定のサービスが実際に互いと協力する数人のホストによって扱われるのを意味する方法としてSRV記録を使用するかもしれません。 その負荷である違い
Mealling Standards Track [Page 10] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[10ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
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はいくつかを特定にする委譲経路に関係があるので特徴がセットしたところで同じホストか管理ドメインの間でバランスをとることをします。
5. Specifying A Database
5. データベースを指定します。
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.
さらに、どんなApplicationもRulesを検索する少なくとも1対応するDatabaseを持たなければなりません。 与えられたDatabaseが1Applicationによって使用されるかもしれないことに注意するのは重要です。 これがそうであるなら、各規則はそれが有効であるそれらのApplication Unique Stringsだけを合わせるのにServices、そして/または、代替式の何らかの組み合わせを使用することであるに違いありません。
A Database specification must include the following pieces of information:
Database仕様は以下の情報を含まなければなりません:
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.
一般仕様: Databaseには、一般仕様がなければなりません。 これは他の規格(SQL、DNSなど)に参照をつけることができますか、またはそれが目新しいデータベース・システムを完全に指定できます。 この仕様は許容文字集合がキーズとRulesがどの文字集合にコード化されるかを知るために何に関して存在するかが明確であるに違いありません。
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のベースのDatabaseは、どのResource RecordsかQuery Typesが使用されているかを指定しなければなりません。
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がどうデータベースに挿入されるか仕様。 これは、Ruleが加えることができるかどうかを施政方針を含むことができます。
Mealling Standards Track [Page 11] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[11ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
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.
衝突回避用レーダー警報装置を統治してください: Databaseが複数のApplications(例えば、ENUMとURI Resolution)によって使用されるかもしれないので、規則衝突がどう避けられるかに関して仕様は明確であるに違いありません。 通常、これを扱うための2つのメソッドがあります: 1) 2異なったApplicationsで有効であるので、1個のキーを禁じてください。 2) 1が可能でないなら、正規表現部分がマッチの一部としてのApplication Unique Stringが2Applicationsを区別する十分を含むように、代替式を書いてください。
6. Examples
6. 例
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.
ここに出された例は教育学の目的だけのためのものです。 それらはどんな発行されたドキュメントでも指定されていないficticiousアプリケーションから明確に抜粋されます。
6.1 An Automobile Parts Identification System
6.1 自動車部品同定システム
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 Network)を検索するためのデータベースと質問構文を指定して、次に、Auto Parts Identification DDDS Application(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番号)を取ってください、そして、Keyとしてそれを使用してください。
Mealling Standards Track [Page 12] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[12ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
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 Network Database仕様は以下を定義するでしょう:
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 Networkプロトコルに従って、Keyのためにネットワークに書換規則を求めてください。
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'を取って、そのRewrite Ruleをネットワークに求めるでしょう。 このRuleは直接システムの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ケタが新しいRuleを見つけるのに質問の一部として彼らのサービスに使用されるべきであると述べるRuleを返すと思いましょう。 この新しいRuleは部品メーカーにそれぞれの自動系列のためにそれらの部品工場へ質問をさらに代表として派遣させるでしょう。 私たちの例の部品番号では、数の'01A'は車のトヨタ系列を指示します。 メーカーが返すRuleはさらに日本の生産財卸売商へ質問を代表として派遣します。 また、この規則は、このRuleが端末であることを指示します、そして、その結果、この最後の質問の結果は部分の実際の情報になるでしょう。
Mealling Standards Track [Page 13] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[13ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
6.2 A Document Identification Service
6.2 書類識別サービス
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:
この例のApplication Unique Stringが以下に似ていると思いましょう:
<organization>-<department>-<author>:<project>-<bookcase>-<book>
<組織>、-<部の>-<が>: 本箱>-<が予約する<プロジェクト>-<を書く、>。
The Application specification would look like this:
Application仕様はこれに似ているでしょう:
o Application Unique String: the Document ID string given above.
o アプリケーションのユニークなストリング: 上に与えられたDocument IDストリング。
o First Well Known Rule: the characters up to but not including the
first '-' is treated as the first Key.
o 最初のよく知られている規則: 包含だけでないのへの最初の'--'へのキャラクタは最初のKeyとして扱われます。
o Valid Databases: the DIS LDAP Directory.
o 有効なデータベース: 不-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ディレクトリのためのDatabase仕様はこれに似ているでしょう:
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 一般仕様: DatabaseはLDAPディレクトリサービスを使用します。 それぞれのLDAPサーバには、Rewrite Ruleを含む記録があります。 規則は、LDAP URL体系を使用することで他のLDAPサーバを示します。
o Lookup Procedure: using standard LDAP queries, the client asks the
LDAP server for information about the Key.
o ルックアップ手順: 標準のLDAP質問を使用して、クライアントはLDAPサーバにKeyの情報を求めます。
o Key Format: no conversion is necessary.
o 主要な形式: どんな変換も必要ではありません。
o Rule Format: See the LDAP Rewrite Rule specification.
o 形式を統治してください: LDAP Rewrite Rule仕様を見てください。
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 Agencyによって所有されています。
Mealling Standards Track [Page 14] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[14ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
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.
この例には、最初のルックアップが組織のRuleのためにあります。 その時、組織は直接いくつかで大きい状態でクライアントを指すかもしれません、予想された出力を含む組織の広いデータベース。 他の組織がこのプロセスを分散するかもしれないので、Rulesは結局、質問をいっぱいに選択の作者文書管理環境まで代表として派遣します。
7. Security Considerations
7. セキュリティ問題
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アルゴリズムを定義して、その結果、少しの安全保障問題も含意しません。 セキュリティ問題をダイナミックな委譲ポイントが攻撃の可能なポイントであると単に言うことを超えてそれらを数え上げることができるくらいよく知ることができるのは、このアルゴリズムがいつDatabaseに結びつけられるか、そして、Applicationです。
8. IANA Considerations
8. IANA問題
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に関するどんな要件も作成しません。 データベースとApplication仕様には、かなりの要件があるかもしれませんが、ここにそれらを数え上げることができません。
References
参照
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[2] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[3] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(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] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", RFC 3405,
October 2002.
[5] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[7] Sollins, K., "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998.
[7]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。
Mealling Standards Track [Page 15] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[15ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
[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] 米国電気電子技術者学会、「情報技術--携帯用のオペレーティングシステムインタフェース(POSIX)--第2部のIEEE規格:」 「シェルとユーティリティ(Vol.1)」、IEEE Std1003.2-1992、ISBN1-55937-255-9、1月1993日
[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, August 2000.
[9] 食事とM.とR.ダニエル、「命名権威指針(NAPTR)DNSリソース記録」、RFC2915、2000年8月。
[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[10]Faltstromと、P.と、「E.164番号とDNS」、RFC2916、9月2000日
[11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC 2168, June 1997.
[11] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。
Author's Address
作者のアドレス
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル
EMail: michael@neonym.net URI: http://www.verisignlabs.com
メール: michael@neonym.net ユリ: http://www.verisignlabs.com
Mealling Standards Track [Page 16] RFC 3402 DDDS - The Algorithm October 2002
標準化過程[16ページ]RFC3402DDDSを荒びきにします--アルゴリズム2002年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Mealling Standards Track [Page 17]
標準化過程を荒びきにします。[17ページ]
一覧
スポンサーリンク
