draft-ietf-urn-ddds-07.txt		rfc3402.txt
	URN M. Mealling		Network Working Group M. Mealling
	Internet-Draft VeriSign		Request for Comments: 3402 Verisign
	Expires: November 5, 2002 May 7, 2002		Obsoletes: 2915, 2168 October 2002
			Category: Standards Track
	Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm		Dynamic Delegation Discovery System (DDDS)
	draft-ietf-urn-ddds-07.txt		Part Two: The Algorithm
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document specifies an Internet standards track protocol for the
	all provisions of Section 10 of RFC2026.		Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
	Internet-Drafts are working documents of the Internet Engineering		Official Protocol Standards" (STD 1) for the standardization state
	Task Force (IETF), its areas, and its working groups. Note that		and status of this protocol. Distribution of this memo is unlimited.
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 5, 2002.
	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		This document describes the Dynamic Delegation Discovery System
	(DDDS) algorithm for applying dynamically retrieved string		(DDDS) algorithm for applying dynamically retrieved string
	transformation rules to an application-unique string. Well-formed		transformation rules to an application-unique string. Well-formed
	transformation rules will reflect the delegation of management of		transformation rules will reflect the delegation of management of
	information associated with the string. This document is also part		information associated with the string. This document is also part
	of a series that is completely specified in "Dynamic Delegation		of a series that is completely specified in "Dynamic Delegation
	Discovery System (DDDS) Part One: The Comprehensive DDDS Standard"		Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).
	(RFC WWWW). It is very important to note that it is impossible to		It is very important to note that it is impossible to read and
	read and understand any document in this series without reading the		understand any document in this series without reading the others.
	others.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6		3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 7		3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 6
	3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 8		3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 6
	3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 10		3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 8
	4. Specifying An Application . . . . . . . . . . . . . . . . . . 12		4. Specifying An Application . . . . . . . . . . . . . . . . . . 9
	5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 14		5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1 An Automobile Parts Identification System . . . . . . . . . . 16		6.1 An Automobile Parts Identification System . . . . . . . . . . 12
	6.2 A Document Identification Service . . . . . . . . . . . . . . 17		6.2 A Document Identification Service . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
	Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23		Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The Dynamic Delegation Discovery System is used to implement lazy		The Dynamic Delegation Discovery System (DDDS) is used to implement
	binding of strings to data, in order to support dynamically		lazy binding of strings to data, in order to support dynamically
	configured delegation systems. The DDDS functions by mapping some		configured delegation systems. The DDDS functions by mapping some
	unique string to data stored within a DDDS Database by iteratively		unique string to data stored within a DDDS Database by iteratively
	applying string transformation rules until a terminal condition is		applying string transformation rules until a terminal condition is
	reached.		reached.
	This document describes the general DDDS algorithm, not any		This document describes the general DDDS algorithm, not any
	particular application or usage scenario. The entire series of		particular application or usage scenario. The entire series of
	documents is specified in "Dynamic Delegation Discovery System (DDDS)		documents is specified in "Dynamic Delegation Discovery System (DDDS)
	Part One: The Comprehensive DDDS Standard" (RFC WWWW) [1]. It is		Part One: The Comprehensive DDDS" (RFC 3401) [1]. It is very
	very important to note that it is impossible to read and understand a		important to note that it is impossible to read and understand a
	single document in that series without reading the related documents.		single document in that series without reading the related documents.
	The DDDS's history is an evolution from work done by the Uniform		The DDDS's history is an evolution from work done by the Uniform
	Resource Name Working Group. When Uniform Resource Names [6] were		Resource Name Working Group. When Uniform Resource Names (URNs) [6]
	originally formulated there was the desire to locate an authoritative		were originally formulated there was the desire to locate an
	server for a URN that (by design) contained no information about		authoritative server for a URN that (by design) contained no
	network locations. A system was formulated that could use a database		information about network locations. A system was formulated that
	of rules that could be applied to a URN to find out information about		could use a database of rules that could be applied to a URN to find
	specific chunks of syntax. This system was originally called the		out information about specific chunks of syntax. This system was
	Resolver Discovery System [7] and only applied to URNs.		originally called the Resolver Discovery Service (RDS) [7] and only
			applied to URNs.
	Over time other systems began to apply this same algorithm and		Over time other systems began to apply this same algorithm and
	infrastructure to other, non-URN related, systems (see Section 6 for		infrastructure to other, non-URN related, systems (see Section 6 for
	examples of other ways of using the DDDS). This caused some of the		examples of other ways of using the DDDS). This caused some of the
	underlying assumptions to change and need clarification. These		underlying assumptions to change and need clarification. These
	document are an update of those original URN specifications in order		documents are an update of those original URN specifications in order
	to allow new applications and rule databases to be developed in a		to allow new applications and rule databases to be developed in a
	standardized manner.		standardized manner.
	This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as		This document obsoletes RFC 2168 [11] and RFC 2915 [9] as well as
	updates RFC 2276 [7].		updates RFC 2276 [7].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	Application Unique String		Application Unique String
	A string that is the initial input to a DDDS application. The		A string that is the initial input to a DDDS application. The
	lexical structure of this string must imply a unique delegation		lexical structure of this string must imply a unique delegation
	path, which is analyzed and traced by the repeated selection and		path, which is analyzed and traced by the repeated selection and
	application of Rewrite Rules.		application of Rewrite Rules.
	Rewrite Rule		Rewrite Rule
	A rule that is applied to an Application Unique String to produce		A rule that is applied to an Application Unique String to produce
	skipping to change at page 4, line 46		skipping to change at page 4, line 12
	Application Unique String, the First Well Known Rule, and one or		Application Unique String, the First Well Known Rule, and one or
	more Databases that are valid for the Application.		more Databases that are valid for the Application.
	Rule Database		Rule Database
	Any store of Rules such that a unique key can identify a set of		Any store of Rules such that a unique key can identify a set of
	Rules that specify the delegation step used when that particular		Rules that specify the delegation step used when that particular
	Key is used.		Key is used.
	Services		Services
	A common rule database may be used to associate different services		A common rule database may be used to associate different services
	with a given Application Unique String; e.g. different protocol		with a given Application Unique String; e.g., different protocol
	functions, different operational characteristics, geographic		functions, different operational characteristics, geographic
	segregation, backwards compatibility, etc. Possible service		segregation, backwards compatibility, etc. Possible service
	differences might be message receiving services for email/fax/		differences might be message receiving services for email/fax/
	voicemail, load balancing over web servers, selection of a nearby		voicemail, load balancing over web servers, selection of a nearby
	mirror server, cost vs performance trade-offs, etc. These		mirror server, cost vs performance trade-offs, etc. These
	Services are included as part of a Rule to allow the Application		Services are included as part of a Rule to allow the Application
	to make branching decisions based on the applicability of one		to make branching decisions based on the applicability of one
	branch or the other from a Service standpoint.		branch or the other from a Service standpoint.
	Flags		Flags
	Most Applications will require a way for a Rule to signal to the		Most Applications will require a way for a Rule to signal to the
	Application that some Rules provide particular outcomes that		Application that some Rules provide particular outcomes that
	others do not; e.g. different output formats, extensibility		others do not; e.g., different output formats, extensibility
	mechanisms, terminal rule signaling, etc. Most Datatabases will		mechanisms, terminal rule signaling, etc. Most Databases will
	define a Flags field that an Application can use to encode various		define a Flags field that an Application can use to encode various
	values that express these signals.		values that express these signals.
	3. The Algorithm		3. The Algorithm
	The DDDS algorithm is based on the concept of Rewrite Rules. These		The DDDS algorithm is based on the concept of Rewrite Rules. These
	rules are collected into a DDDS Rule Database, and accessed by given		rules are collected into a DDDS Rule Database, and accessed by given
	unique keys. A given Rule, when applied to an Application Unique		unique keys. A given Rule, when applied to an Application Unique
	String, transforms that String into new Key that can be used to		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		retrieve a new Rule from the Rule Database. This new rule is then
	re-applied to the original Application Unique String and the cycle		reapplied to the original Application Unique String and the cycle
	repeats itself until a terminating condition is reached. An		repeats itself until a terminating condition is reached. An
	Application MUST NOT apply a Rule to the output of a previous Rule.		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		All Rewrite Rules for all Applications must ALWAYS apply to the exact
	same Application Unique String that the algorithm started with.		same Application Unique String that the algorithm started with.
	It is a fundamental assumption that the Application Unique String has		It is a fundamental assumption that the Application Unique String has
	some kind of regular, lexical structure that the rules can be applied		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		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		make a delegation decision is simple enough to be contained within
	the Application Unique String itself. The DDDS does not solve the		the Application Unique String itself. The DDDS does not solve the
	case where a delegation decision is made using knowledge contained		case where a delegation decision is made using knowledge contained
	outside the AUS and the Rule (time of day, financial transactions,		outside the AUS and the Rule (time of day, financial transactions,
	rights management, etc).		rights management, etc.).
	Diagramatically the algorithm looks like this:		Diagrammatically the algorithm looks like this:
	+--------- Application Unique String		+--------- Application Unique String
	| +-----+		| +-----+
	| |input|		| |input|
	| +-------+ +---------+		| +-------+ +---------+
	| | First Well Known Rule |		| | First Well Known Rule |
	| +-------+ +--------+		| +-------+ +--------+
	| |output|		| |output|
	| +------+		| +------+
	| First Key		| First Key
	| |		| |
	| |
	| +----<--------------<--------------+		| +----<--------------<--------------+
	| | |		| | |
	| key (a DDDS database always |		| key (a DDDS database always |
	| +-----+ takes a key and returns |		| +-----+ takes a key and returns |
	| |input| a rule) ^		| |input| a rule) ^
	| +---------+ +------------+ |		| +---------+ +------------+ |
	| | Lookup key in DDDS Database| |		| | Lookup key in DDDS Database| |
	| +---------+ +-----------+ |		| +---------+ +-----------+ |
	| |output| |		| |output| |
	| +------+ |		| +------+ |
	skipping to change at page 7, line 17		skipping to change at page 5, line 42
	+---------------->|input| either a key or the result) |		+---------------->|input| either a key or the result) |
	+---------------+ +------------------+ |		+---------------+ +------------------+ |
	| Apply Rules to Application Unique String| |		| Apply Rules to Application Unique String| |
	| until non-empty result are obtained | |		| until non-empty result are obtained | |
	| that meet the applications requirements | |		| that meet the applications requirements | |
	+---------------+ +-----------------+ |		+---------------+ +-----------------+ |
	|output| |		|output| |
	+------+ ^		+------+ ^
	key |		key |
	| |		| |
	| |
	| |
	| |
	v |		v |
	+--------------------------------------+ |		+--------------------------------------+ |
	| Was the last matching rule terminal? | No >------+		| Was the last matching rule terminal? | No >------+
	+--------------------------------------+		+--------------------------------------+
	Yes (if the rule isn't terminal		Yes (if the rule isn't terminal then
	| then its output is the new		| its output is the new key which
	| key which is used to find a		| is used to find a new rule set)
	| new rule set)
	|
	+------------------------------------+		+------------------------------------+
	| The output of the last rule is the |		| The output of the last rule is the |
	| result desired by the application |		| result desired by the application |
	+------------------------------------+		+------------------------------------+
	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		A Priority
	Simply a number used to show which of two otherwise equal rules		Simply a number used to show which of two otherwise equal rules
	may have precedence. This allows the database to express rules		may have precedence. This allows the database to express rules
	that may offer roughly the same results but one delegation path		that may offer roughly the same results but one delegation path
	may be faster, better, cheaper than the other.		may be faster, better, cheaper than the other.
	A set of Flags		A Set of Flags
	Flags are used to specify attributes of the rule that determine if		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		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 terminal rule and its output should be the intended result for
	the application. Flags are unique across Applications. An		the application. Flags are unique across Applications. An
	Application may specify that it is using a flag defined by yet		Application may specify that it is using a flag defined by yet
	another Application but it must use that other Application's		another Application but it must use that other Application's
	definition. One Application cannot re-define a Flag used by		definition. One Application cannot redefine a Flag used by
	another Application. This may mean that a registry of Flags will		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.		be needed in the future but at this time it is not a requirement.
	A description of Services		A Description of Services
	Services are used to specify semantic attributes of a particular		Services are used to specify semantic attributes of a particular
	delegation branch. There are many cases where two delegation		delegation branch. There are many cases where two delegation
	branches are identical except that one delegates down to a result		branches are identical except that one delegates down to a result
	that provides one set of features while another provides some		that provides one set of features while another provides some
	other set. Features may include operational issues such as load		other set. Features may include operational issues such as load
	balancing, geographically based traffic segregation, degraded but		balancing, geographically based traffic segregation, degraded but
	backwardly compatibile functions for older clients, etc. For		backwardly compatible functions for older clients, etc. For
	example, two rules may equally apply to a specific delegation		example, two rules may equally apply to a specific delegation
	decision for a string. One rule can lead to a terminal rule that		decision for a string. One rule can lead to a terminal rule that
	produces information for use in high availability environments		produces information for use in high availability environments
	while another may lead to an archival service that may be slower		while another may lead to an archival service that may be slower
	but is more stable over long periods of time.		but is more stable over long periods of time.
	A Substitution Expression		A Substitution Expression
	This is the actual string modification part of the rule. It is a		This is the actual string modification part of the rule. It is a
	combination of a POSIX Extended Regular Expression [8] and a		combination of a POSIX Extended Regular Expression [8] and a
	replacement string similar to Unix sed-style substitution		replacement string similar to Unix sed-style substitution
	skipping to change at page 8, line 41		skipping to change at page 7, line 9
	The character set(s) that the substitution expression is in and can		The character set(s) that the substitution expression is in and can
	act on are dependent both on the Application and on the Database		act on are dependent both on the Application and on the Database
	being used. An Application must define what the allowed character		being used. An Application must define what the allowed character
	sets are for the Application Unique String. A DDDS Database		sets are for the Application Unique String. A DDDS Database
	specification must define what character sets are required for		specification must define what character sets are required for
	producing its keys and for how the substitution expression itself is		producing its keys and for how the substitution expression itself is
	encoded. The grammar-required characters below only have meaning		encoded. The grammar-required characters below only have meaning
	once a specific character set is defined for the Database and/or		once a specific character set is defined for the Database and/or
	Application.		Application.
	The syntax of the Substitution Expression part of the rule is a sed-		The syntax of the Substitution Expression part of the rule is a
	style substitution expression. True sed-style substitution		sed-style substitution expression. True sed-style substitution
	expressions are not appropriate for use in this application for a		expressions are not appropriate for use in this application for a
	variety of reasons, therefore the contents of the regexp field MUST		variety of reasons, therefore the contents of the regexp field MUST
	follow this grammar:		follow this grammar:
	subst-expr = delim-char ere delim-char repl delim-char *flags		subst-expr = delim-char ere delim-char repl delim-char *flags
	delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'>		delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'>
	; All occurances of a delim_char in a subst_expr must		; All occurrences of a delim_char in a subst_expr
	; be the same character.>		; must be the same character.>
	ere = <POSIX Extended Regular Expression>		ere = <POSIX Extended Regular Expression>
	repl = *(string / backref)		repl = *(string / backref)
	string = *(anychar / escapeddelim)		string = *(anychar / escapeddelim)
	anychar = <any character other than delim-char>		anychar = <any character other than delim-char>
	escapeddelim = "\" delim-char		escapeddelim = "\" delim-char
	backref = "\" POS-DIGIT		backref = "\" POS-DIGIT
	flags = "i"		flags = "i"
	POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"		POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
	The result of applying the substitution expression to the String MUST		The result of applying the substitution expression to the String MUST
	result in a key which obeys the rules of the Database (unless of		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		course it is a Terminal Rule in which case the output follows the
	rules of the application). Since it is possible for the regular		rules of the application). Since it is possible for the regular
	expression to be improperly specified, such that a non-conforming key		expression to be improperly specified, such that a non-conforming key
	can be constructed, client software SHOULD verify that the result is		can be constructed, client software SHOULD verify that the result is
	a legal database key before using it.		a legal database key before using it.
	Backref expressions in the repl portion of the substitution		Backref expressions in the repl portion of the substitution
	skipping to change at page 10, line 15		skipping to change at page 8, line 26
	occurrences of that character, digits MUST NOT be used as delimiters.		occurrences of that character, digits MUST NOT be used as delimiters.
	Backrefs would be confused with literal digits were this allowed.		Backrefs would be confused with literal digits were this allowed.
	Similarly, if flags are specified in the substitution expression, the		Similarly, if flags are specified in the substitution expression, the
	delimiter character must not also be a flag character.		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		1. The First Well Known Rule is applied to the Application Unique
	String which produces a Key		String which produces a Key.
	2. The Application asks the Database for the ordered set of Rules		2. The Application asks the Database for the ordered set of Rules
	that are bound to that Key (see NOTE below on order details)		that are bound to that Key (see NOTE below on order details).
	3. The Substitution Expression for each Rule in the list is applied,		3. The Substitution Expression for each Rule in the list is applied,
	in order, to the Application Unique String until a non-empty		in order, to the Application Unique String until a non-empty
	string is produced. The position in the list is noted and the		string is produced. The position in the list is noted and the
	Rule that produced the non-empty string is used for the next		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. If the next step rejects this rule and returns to this
	step then the Substitution Expression application process		step then the Substitution Expression application process
	continues at the point where it left off. If the list is		continues at the point where it left off. If the list is
	exhausted without a valid match then the application is notified		exhausted without a valid match then the application is notified
	that no valid output was available.		that no valid output was available.
	skipping to change at page 11, line 11		skipping to change at page 9, line 24
	express the case where two or more Rules are considered equal. These		express the case where two or more Rules are considered equal. These
	Rules are treated as the same Rule, each one possibly having a		Rules are treated as the same Rule, each one possibly having a
	Priority which is used to communicate a preference for otherwise		Priority which is used to communicate a preference for otherwise
	equivalent Rules. This allows for Rules to act as fallbacks for		equivalent Rules. This allows for Rules to act as fallbacks for
	others. It should be noted that this is a real Preference, not a		others. It should be noted that this is a real Preference, not a
	load balancing mechanism. Applications should define the difference		load balancing mechanism. Applications should define the difference
	carefully.		carefully.
	NOTE 2: Databases may or may not have rules that determine when and		NOTE 2: Databases may or may not have rules that determine when and
	how records within that database expire (expiration dates, times to		how records within that database expire (expiration dates, times to
	live, etc). These expiration mechanisms must be adhered to in all		live, etc.). These expiration mechanisms must be adhered to in all
	cases. Specfically, since the expiration of a databases record could		cases. Specifically, since the expiration of a databases record
	cause a new Rule to be retrieved that is inconsistent with previous		could cause a new Rule to be retrieved that is inconsistent with
	Rules, while in the algorithm any attempts to optimize the process by		previous Rules, while in the algorithm any attempts to optimize the
	falling back to previous keys and Rules MUST ensure that no		process by falling back to previous keys and Rules MUST ensure that
	previously retrieved Rule has expired. If a Rule has expired then		no previously retrieved Rule has expired. If a Rule has expired then
	the application MUST start over at Step 1.		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		In order for this algorithm to have any usefulness, a specification
	must be written describing an application and one or more databases.		must be written describing an application and one or more databases.
	In order to specify an application the following pieces of		In order to specify an application the following pieces of
	information are required:		information are required:
	Application Unique String:		Application Unique String:
	This is the only string that the rewrite rules will apply to. The		This is the only string that the rewrite rules will apply to. The
	string must have some regular structure and be unique within the		string must have some regular structure and be unique within the
	application such that anyone applying Rules taken from the same		application such that anyone applying Rules taken from the same
	skipping to change at page 13, line 12		skipping to change at page 10, line 39
	that will produce the correct Keys. In the URI Resolution example		that will produce the correct Keys. In the URI Resolution example
	shown here, the character set of a URI is 7 bit ASCII which		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		matches fairly well with DNS's 8 bit limitation on characters in
	its zone files.		its zone files.
	Expected Output:		Expected Output:
	The Application must define what the expected output of the		The Application must define what the expected output of the
	Terminal Rule should be. For example, the URI Resolution		Terminal Rule should be. For example, the URI Resolution
	application is concerned with finding servers that contain		application is concerned with finding servers that contain
	authoritative data about a given URI. Thus the output of the		authoritative data about a given URI. Thus the output of the
	terminal rule would be information (hosts, ports, protocols, etc)		terminal rule would be information (hosts, ports, protocols, etc.)
	that would be used to contact that authoritative server.		that would be used to contact that authoritative server.
	In the past there has been some confusion concerning load balancing		In the past there has been some confusion concerning load balancing
	and the use of the DDDS 'Priority'. Applications should be aware		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 the Priority of a given rule is just that: a way of specifying
	that one rule is "better, faster, cheaper" than another. If an		that one rule is "better, faster, cheaper" than another. If an
	application needs some method of allowing a client to load balance		application needs some method of allowing a client to load balance
	between servers (i.e. weighted random selection, etc) then it should		between servers (i.e., weighted random selection, etc.) then it
	do so outside the DDDS algorithm. For example, Applications that		should do so outside the DDDS algorithm. For example, Applications
	make use of the DNS Database may use the SRV record as a way of		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		signifying that a particular service is actually handled by several
	hosts cooperating with each other. The difference being that load		hosts cooperating with each other. The difference being that load
	balancing is done between hosts that are identical to each other		balancing is done between hosts that are identical to each other
	where as DDDS is concerned with delegation paths that have some		where as DDDS is concerned with delegation paths that have some
	particular feature set or administrative domain.		particular feature set or administrative domain.
	5. Specifying A Database		5. Specifying A Database
	Additionally, any Application must have at least one corresponding		Additionally, any Application must have at least one corresponding
	Database from which to retrieve the Rules. It is important to note		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		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		this is the case, each rule must be use some combination of its
	Services and/or substitution expression to match only those		Services and/or substitution expression to match only those
	Application Unique Strings for which it is valid.		Application Unique Strings for which it is valid.
	A Database specification must include the following pieces of		A Database specification must include the following pieces of
	information:		information:
	General Specification:		General Specification:
	The Database must have a general specification. This can		The Database must have a general specification. This can
	reference other standards (SQL, DNS, etc) or it can fully specify		reference other standards (SQL, DNS, etc.) or it can fully specify
	a novel database system. This specification MUST be clear as to		a novel database system. This specification MUST be clear as to
	what allowed character sets exist in order to know in which		what allowed character sets exist in order to know in which
	character set the Keys and Rules are encoded.		character set the Keys and Rules are encoded.
	Lookup Procedure:		Lookup Procedure:
	This specifies how a query is formulated and submitted to the		This specifies how a query is formulated and submitted to the
	database. In the case of databases that are used for other		database. In the case of databases that are used for other
	purposes (such as DNS), the specification must be clear as to how		purposes (such as DNS), the specification must be clear as to how
	a query is formulated specifically for the database to be a DDDS		a query is formulated specifically for the database to be a DDDS
	database. For example, a DNS based Database must specify which		database. For example, a DNS based Database must specify which
	skipping to change at page 16, line 8		skipping to change at page 12, line 18
	how rule collisions will be avoided. There are usually two		how rule collisions will be avoided. There are usually two
	methods for handling this: 1) disallow one key from being valid in		methods for handling this: 1) disallow one key from being valid in
	two different Applications; 2) if 1 isn't possible then write the		two different Applications; 2) if 1 isn't possible then write the
	substitution expression such that the regular expression part		substitution expression such that the regular expression part
	contains enough of the Application Unique String as part of its		contains enough of the Application Unique String as part of its
	match to differentiate between the two Applications.		match to differentiate between the two Applications.
	6. Examples		6. Examples
	The examples given here are for pedagogical purposes only. They are		The examples given here are for pedagogical purposes only. They are
	specifically taken from fictious applications that have not been		specifically taken from ficticious applications that have not been
	specified in any published document.		specified in any published document.
	6.1 An Automobile Parts Identification System		6.1 An Automobile Parts Identification System
	In this example imagine a system setup where all automobile		In this example imagine a system setup where all automobile
	manufacturers come together and create a standardized part numbering		manufacturers come together and create a standardized part numbering
	system for the various parts (nuts, bolts, frames, instruments, etc)		system for the various parts (nuts, bolts, frames, instruments, etc.)
	that make up the automobile manufacturing and repair process. The		that make up the automobile manufacturing and repair process. The
	problem with such a system is that the auto industry is a very		problem with such a system is that the auto industry is a very
	distributed system where parts are built by various third parties		distributed system where parts are built by various third parties
	distributed around the world. In order to find information about a		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		given part a system must be able to find out who makes that part and
	contact them about it.		contact them about it.
	To facilitate this distributed system the identification number		To facilitate this distributed system the identification number
	assigned to a part is assigned hierarchically such that the first 5		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		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		an auto line identifier (Ford, Toyota, etc.). The rest of the digits
	are assigned by the parts manufacturer according to rules that the		are assigned by the parts manufacturer according to rules that the
	manufacturer decides.		manufacturer decides.
	The auto industry decides to use the DDDS to create a distributed		The auto industry decides to use the DDDS to create a distributed
	information retrieval system that routes queries to the actual owner		information retrieval system that routes queries to the actual owner
	of the data. The industry specifies a database and a query syntax		of the data. The industry specifies a database and a query syntax
	for retrieving rewrite rules (the APIDA Network) and then specifies		for retrieving rewrite rules (the APIDA Network) and then specifies
	the Auto Parts Identification DDDS Application (APIDA).		the Auto Parts Identification DDDS Application (APIDA).
	The APIDA specification would define the following:		The APIDA specification would define the following:
	o Application Unique String: the part number		o Application Unique String: the part number.
	o First Well Known Rule: take the first 5 digits (the manufacturers		o First Well Known Rule: take the first 5 digits (the manufacturers
	ID number) and use that as the Key		ID number) and use that as the Key.
	o Valid Databases: The APIDA Network		o Valid Databases: The APIDA Network.
	o Expected Output: EDIFAC information about the part		o Expected Output: EDIFAC information about the part.
	The APIDA Network Database specification would define the following:		The APIDA Network Database specification would define the following:
	o General Specification: a network of EDI enabled databases and		o General Specification: a network of EDI enabled databases and
	services that, when given a subcomponent of a part number will		services that, when given a subcomponent of a part number will
	return an XML encoded rewrite rule		return an XML encoded rewrite rule.
	o Lookup Procedure: following normal APIDA Network protocols, ask		o Lookup Procedure: following normal APIDA Network protocols, ask
	the network for a rewrite rule for the Key.		the network for a rewrite rule for the Key.
	o Key Format: no conversion is required		o Key Format: no conversion is required.
	o Rule Format: see APIDA Network documentation for the XML DTD		o Rule Format: see APIDA Network documentation for the XML DTD.
	o Rule Insertion Procedure: determined by the authority that has		o Rule Insertion Procedure: determined by the authority that has
	control over each section of the part number. I.e. in order to		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		get a manufacturer ID you must be a member of the Auto Parts
	Manufacturers Association		Manufacturers Association.
	In order to illustrate how the system would work, imagine the part		In order to illustrate how the system would work, imagine the part
	number "4747301AB7D". The system would take the first 5 digits,		number "4747301AB7D". The system would take the first 5 digits,
	'47473' and ask the network for that Rewrite Rule. This Rule would		'47473' and ask the network for that Rewrite Rule. This Rule would
	be provided by the parts manufacturers database and would allow the		be provided by the parts manufacturers database and would allow the
	manufacturer to either further sub-delegate the space or point the		manufacturer to either further sub-delegate the space or point the
	querier directly at the EDIFAC information in the system.		querier directly at the EDIFAC information in the system.
	In this example let's suppose that the manufacturer returns a Rule		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		that states that the next 3 digits should be used as part of a query
	skipping to change at page 17, line 52		skipping to change at page 14, line 22
	Also, in order to keep from having a large flat space of authors, the		Also, in order to keep from having a large flat space of authors, the
	authors are organized by organizations and departments.		authors are organized by organizations and departments.
	Let's suppose that the Application Unique String in this example		Let's suppose that the Application Unique String in this example
	looks like the following:		looks like the following:
	<organization>-<department>-<author>:<project>-<bookcase>-<book>		<organization>-<department>-<author>:<project>-<bookcase>-<book>
	The Application specification would look like this:		The Application specification would look like this:
	o Application Unique String: the Document ID string given above		o Application Unique String: the Document ID string given above.
	o First Well Known Rule: the characters up to but not including the		o First Well Known Rule: the characters up to but not including the
	first '-' is treated as the first Key.		first '-' is treated as the first Key.
	o Valid Databases: the DIS LDAP Directory		o Valid Databases: the DIS LDAP Directory.
	o Expected Output: a record from an LDAP server containing		o Expected Output: a record from an LDAP server containing
	bibliographic information about the document in XML		bibliographic information about the document in XML.
	The Database specification for the DIS LDAP Directory would look like		The Database specification for the DIS LDAP Directory would look like
	this:		this:
	o General Specification: the Database uses the LDAP directory		o General Specification: the Database uses the LDAP directory
	service. Each LDAP server has a record that contains the Rewrite		service. Each LDAP server has a record that contains the Rewrite
	Rule. Rules refer to other LDAP servers using the LDAP URL		Rule. Rules refer to other LDAP servers using the LDAP URL
	scheme.		scheme.
	o Lookup Procedure: using standard LDAP queries, the client asks the		o Lookup Procedure: using standard LDAP queries, the client asks the
	LDAP server for information about the Key.		LDAP server for information about the Key.
	o Key Format: no conversion is necessary.		o Key Format: no conversion is necessary.
	o Rule Format: See the LDAP Rewrite Rule specification		o Rule Format: See the LDAP Rewrite Rule specification.
	o Rule Insertion Procedure: See the procedures published by the		o Rule Insertion Procedure: See the procedures published by the
	entity that has authority over that section of the DIS tree. The		entity that has authority over that section of the DIS tree. The
	first section, the organization, is owned by the DIS Agency.		first section, the organization, is owned by the DIS Agency.
	In this example, the first lookup is for the organization's Rule. At		In this example, the first lookup is for the organization's Rule. At
	that point the organization may point the client directly at some		that point the organization may point the client directly at some
	large, organization wide database that contains the expected output.		large, organization wide database that contains the expected output.
	Other organizations may decentralize this process so that Rules end		Other organizations may decentralize this process so that Rules end
	up delegating the query all the way down to the authors document		up delegating the query all the way down to the authors document
	skipping to change at page 21, line 7		skipping to change at page 15, line 29
	attack.		attack.
	8. IANA Considerations		8. IANA Considerations
	This document does not create any requirements on the IANA. Database		This document does not create any requirements on the IANA. Database
	and Application specifications may have considerable requirements but		and Application specifications may have considerable requirements but
	they cannot be enumerated here.		they cannot be enumerated here.
	References		References
	[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-		Part One: The Comprehensive DDDS", RFC 3401, October 2002.
	urn-ddds-toc-02.txt (work in progress), May 2002.
	[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-07.txt (work		Part Two: The Algorithm", RFC 3402, October 2002.
	in progress), May 2002.
	[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-		Part Three: The Domain Name System (DNS) Database", RFC 3403,
	database-09.txt (work in progress), May 2002.		October 2002.
	[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	Four: The URI Resolution Application", RFC YYYY, draft-ietf-		Part Four: The Uniform Resource Identifiers (URI) Resolution
	urn-uri-res-ddds-07.txt (work in progress), May 2002.		Application", RFC 3404, October 2002.
	[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part		[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
	Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-		Part Five: URI.ARPA Assignment Procedures", RFC 3405,
	urn-net-procedures-11.txt (work in progress), May 2002.		October 2002.
	[6] Moats, R., "URN Syntax", RFC 2141, May 1997.		[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[7] Sollins, K., "Architectural Principles of Uniform Resource Name		[7] Sollins, K., "Architectural Principles of Uniform Resource Name
	Resolution", RFC 2276, January 1998.		Resolution", RFC 2276, January 1998.
	[8] The Institute of Electrical and Electronics Engineers, "IEEE		[8] The Institute of Electrical and Electronics Engineers, "IEEE
	Standard for Information Technology - Portable Operating System		Standard for Information Technology - Portable Operating System
	Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE		Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE
	Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.		Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.
	[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer		[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer
	(NAPTR) DNS Resource Record", RFC 2915, August 2000.		(NAPTR) DNS Resource Record", RFC 2915, August 2000.
	[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September		[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
	2000.		2000.
	[11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource		[11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
	Identifiers using the Domain Name System", RFC 2168, June 1997.		Identifiers using the Domain Name System", RFC 2168, June 1997.
	Author's Address		Author's Address
	Michael Mealling		Michael Mealling
	VeriSign		VeriSign
	21345 Ridgetop Circle		21345 Ridgetop Circle
	Sterling, VA 20166		Sterling, VA 20166
	US		US
	EMail: michael@neonym.net		EMail: michael@neonym.net
End of changes. 59 change blocks.
	150 lines changed or deleted		129 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/