< draft-lewis-domain-names-02.txt		draft-lewis-domain-names-03.txt >
	Independent Submission E. Lewis		Independent Submission E. Lewis
	Internet-Draft ICANN		Internet-Draft ICANN
	Expires: July 30, 2016 Date: January 30, 2016		Expires: January 1, 2017 Date: July 1, 2016
	Intended Status: unknown		Intended Status: unknown
	Domain Names		Domain Names
	draft-lewis-domain-names-02.txt		draft-lewis-domain-names-03.txt
	Abstract		Abstract
	This document states a definition of Domain Name beyond the use of		This document researches the origin of the term Domain Name in the
	the term within the Domain Name System. The document includes a		Request for Comments document series, documenting that the term did
	survey of the diverse ways Domain Names have been interpreted within		not originate in the documents defining the Domain Name System. The
			document describes how the term came to be used, how the DNS followed,
			and surveys the diverse ways Domain Names have been interpreted within
	various protocols over time. The purpose of this is to give a solid		various protocols over time. The purpose of this is to give a solid
	foundation for work on Domain Names across all protocols making use		foundation for work on Domain Names across all protocols making use of
	of Domain Names.		Domain Names.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 30, 2016.		This Internet-Draft will expire on January 1, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	0. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 1
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
	2. Reaching a definition of a Domain Name . . . . . . . . . . . 1
	3. Subtypes of Domain Names . . . . . . . . . . . . . . . . . . 1
	4. Interoperability Considerations . . . . . . . . . . . . . . 1
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 1
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 1
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 1
	9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 1
	0. NOTE TO RFC EDITOR AND REVIEWERS		0. NOTE TO RFC EDITOR AND REVIEWERS
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
			2. Emergence of Domain Names . . . . . . . . . . . . . . . . . . 1
			3. Dialects, so to speak, of Domain Names . . . . . . . . . . . . 1
			4. Interoperability Considerations . . . . . . . . . . . . . . . 1
			5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 1
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1
			9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 1
	A suitable venue for discussion of this document is the dnsop working		0. NOTE TO RFC EDITOR AND REVIEWERS
	group. Private comments may also be directed at the editor.
	This document will be presented to the Dispatch WG as it relates		The closest mailing list to this topic is arcing@ietf.org. Or maybe
	to the use of identifiers across protocols, despite perceptions		dnsop@ietf.org. Private comments may also be directed at the editor.
	that the DNS defines Domain Names.
	This section (and sub-sections) **probably** should be removed		This section (and sub-sections) **probably** should be removed
	prior to publication.		prior to publication.
	0.1 Backstory		Note on changes from earlier edition:
	Editorial note - I'm not sure whether 0.1 and 0.2 will remain in		The document's scope has been reduced, at least for now. The document
	the document. Despite the "probably should" above.		sticks to history and current observations without proposing a
			definition nor an architecture. There's too many degrees of freedom
			in the definition/architecture space at the moment to make a useful
			specific recommendation.
			1. Introduction
			What is the motivation behind the document and what is the anticipated
			result?
			1.1 Motivation for this Document
	Why bother to define Domain Names now, three decades after the		Why bother to define Domain Names now, three decades after the
	earliest mentions in RFC documents? There are many examples of		earliest mentions in RFC documents? There are many examples of
	names as identifiers in existence, a lot of running code. There is		names as identifiers in existence, a lot of running code. There is
	a large industry built on management of names as well, a lot of		a large industry built on management of names as well, a lot of
	financial investment made. Would not a definition appearing now be		financial investment made. Would not a definition appearing now be
	merely an academic exercise or worse, a disruption to what seems to		merely an academic exercise or worse, a disruption to what seems to
	be a reliable system?		be a reliable system?
	The tipping point related to addressing the lack of a definition is		A desire to examine this topic is a reaction to the discussion
	the call to apply a special meaning to certain Domain Names, with		related to the Special Use Domain Name Registry as described in
	special meaning "not managed via the DNS." The DNS, whose history		"Special Use Domain Names" [RFC 6761] and the process of adding
	and explanation follow, has been created to manage Domain Names and		"ONION" to that registry, as described in "The '.onion' Special-Use
	over time evolved to become the defining force behind Domain Names.		Domain Name" [RFC 7686]. Concerns raised on a mailing list used to
	The emergence of other name management systems, in the sense of		discuss the latter RFC included specific criterial to declare a name
	"permissionless innovation", have called into question whether DNS		as special as well as the conflict with other processes, such as the
	is the defining force for Domain Names.		process launched from "Memorandum of Understanding Concerning the
			Technical Work of the Internet Assigned Numbers Authority" [RFC 2860],
			for registering a name in the DNS.
	There are good reasons to call this into question. The DNS		During reviews of this document, documented studies of other
	definition makes some simplifyng assumptions about Domain Names,		difficulties have surfaced. "IAB Thoughts on Encodings for
	carving out some functionality that the newer name management systems		Internationalized Domain Names" [RFC 6055] documents issues related to
	wish to explore. To foster this innovation, better definitions,		converting human-readable forms of Domain Names in forms useful to
	boundaries and even an architectural review of Domain Names is		automated applications when there is no clear architecture or precise
	benefical.		definition of how to handle Domain Names. "Issues in Identifier
			Comparison for Security Purposes" [RFC 6943] documents issues related
			to the same conversion as related to evaluating security policies. The
			presence of these studies suggest a need to examine the architecture
			of naming and identifiers.
	The beneficiaries of such work include both the developers of		The beneficiaries of such work include both the developers of software
	software that makes use of names and identifiers. A single piece of		that makes use of names and identifiers. A single piece of code could
	code code be used in different nameing environments if the code can		be used in different naming environments if the code can determine how
	determine how to process a name. With code reusable across different		to process a name. With code reusable across different environments,
	environments, another beneficiary are those exploring new means of		another benefit are innovators exploring new means of identifying
	identifying objects.		objects.
	0.2 Goal		1.2 Goal
	The work ahead has the ingredients of a "clarification" - a loose		The work ahead has the ingredients of a "clarification" - a loose
	or poorly worded initial definition, multiple diverse valid		or poorly worded initial definition, multiple diverse valid
	interpretations in use, and a need to converge on a more precise		interpretations in use, and a need to converge on a more precise
	definition which may cause some issues with backwards compatibility.		definition which may cause some issues with backwards compatibility.
	Before knowing what a precise definition means, the goal ought to be		This document sets out to establish that a clarification is warranted.
	stated.
	Already proposed, including a definition in this document, are
	accurate but purely conceptual (or theoretical or mathematical)
	definitions that, on the one hand, are pure to the idea but not
	helpful to developing code. Walking from the land of theory into
	what is helpful means adding elements to the definition, for better
	or worse.
	What should the definition address? There are many environments for
	names and identifiers, what is the scope of Domain Names? How can
	one tell if a protocol, service, or application handles identifiers
	according to the definition of domain names or not? Can an
	application deviate "slightly" from the definition or is it
	all-or-nothing? Purporting to support Domain Names may appear to
	be more of a branding issue then a techinical one, that is, merely
	a name and not a clear distinction.
	0.3 Benchmark for revising this document
	Given the numbering, there will come a time to re-organize the draft,
	add in sensible paging, etc., or abandon it altogether. The point
	at which this document ought to "molt" into a more mature document
	could be when - there is a clearer sense of necessity for the work,
	a vague notion of a goal, and once the "deliverables" from the
	document are clearer. E.g., what is the definition, what is the
	scope of the definition, and possible how we apply rules for
	resolving names (is it DNS? is it not DNS?).
	1. Introduction		1.3 Background
	Two or three decades into the history of Domain Names, a popular		Two or three decades into the history of Domain Names, a popular
	notion has taken hold that Domains Names were defined and specified		notion has taken hold that Domains Names were defined and specified
	STD 13, the definition of the Domain Name System (DNS). The		in the definition of the Domain Name System (DNS). There are two
	definitions within RFC 1034 and RFC 1035 have become the		documents that form the basic definition of the DNS, "Domain names -
	apparently-authoritative source for discussions on what is a Domain		concepts and facilities" and "Domain names - implementation and
	Name.		specification" referred to as RFC 1034 and RFC 1035, respectively.
			(Note that there is another pair of Request for Comments documents
	The truth is, RFC 1034 and RFC 1035 do not define Domain Names, those		with the same titles that precede RFC 1034 and RFC 1035, those were
	documents define only how Domain Names are used and processed in the		declared obsolete in favor of the newer documents.) Together RFC 1034
	DNS. But the way in which those RFCs are written seem to lend to the		and RFC 1035 form STD 13, a full standard cataloged by the RFC Editor.
	confusion.		The definitions of DNS domain names within RFC 1034 and RFC 1035 have
			become the apparently-authoritative source for discussions on what is
			a Domain Name.
	Throughout this document the term "Domain Names" is capitalized to		Throughout this document the term "Domain Names" is capitalized to
	emphasize the concept of the names and DNS is used to describe the		emphasize the concept of the names and DNS is used to describe the
	protocol and algorithms described in STD 13, including any applicable		protocol and algorithms described in STD 13, including any applicable
	updates, related standards track documents and experimental track		updates, related standards track documents and experimental track
	documents.		documents.
	The term domain is a generic term. And there are many naming		The term domain is a generic term. And there are many naming
	systems in existence. The use of the term Domain Names in this		systems in existence. The use of the term Domain Names in this
	document refers to the roughly-defined set of protocols and their		document refers to the roughly-defined set of protocols and their
	applications use of a naming structure that is prevalent amongst		applications' use of a naming structure that is prevalent amongst
	many protocols defined in IETF RFC documents.		many protocols defined in IETF RFC documents.
	If there is a use of Domain Names not listed here it is merely an		The truth is, STD 13 does not define Domain Names, the documents define
	omission. The goal in this document is to provide a survey that		only how Domain Names are used and processed in the DNS. However the
	is sufficent to avoid hand-waving arguments, recognizing the dimishing		way in which the RFC documents read seem to lend to the confusion.
	return in trying to build a complete roster of uses of Domain Names.
	If there are omissions that ought to be included, please send
	references for the use case to the author (while this is an Internet
	Draft, that is).
	1.1 Deconstructing RFC 1034's Introduction
	RFC 1034, section 2 begins with this text:		RFC 1034, section 2 begins with this text:
	"This RFC introduces domain style names, their use for Internet mail		"This RFC introduces domain style names, their use for Internet mail
	and host address support, and the protocols and servers used to		and host address support, and the protocols and servers used to
	implement domain name facilities."		implement domain name facilities."
	Which seems to indicate that RFC 1034 is the origin of Domain Names.		Which seems to indicate that RFC 1034 is the origin of Domain Names.
	Immediately following is section 2.1, entitled "The history of domain		Immediately following is section 2.1, entitled "The history of domain
	names" which includes the following text.		names" which includes the following text.
	skipping to change at line 216 ¶		skipping to change at line 198 ¶
	"The Domain Naming Convention for Internet User Applications").		"The Domain Naming Convention for Internet User Applications").
	One important phrase to keep in mind is:		One important phrase to keep in mind is:
	"To simplify implementations,"		"To simplify implementations,"
	which appears in both RFC 1034 and RFC 1035 as well as their		which appears in both RFC 1034 and RFC 1035 as well as their
	predecessors RFC 882 and RFC 883. This gives credence to the notion		predecessors RFC 882 and RFC 883. This gives credence to the notion
	that Domain Names exist beyond the DNS.		that Domain Names exist beyond the DNS.
	1.2 Purpose of the Document		2. Emergence of Domain Names
	This document has a goal of establishing a definition of Domain Names
	for the purpose of continuing efforts to innovate in naming systems.
	The path by which this document aims to meet the goal is to describe
	in more detail the original definition of Domain Names (which never
	seems to have been documented in an RFC) and then to illustrate how
	Domain Names have been interpreted in the DNS, SMTP, X.509 Certificate
	(PKIX), URNs and other environments.
	1.3 Why Write This Now?
	RFC 6761 defines "Special Use Domain Names" which has engendered much
	confusion of the role of Domain Names with respect to the DNS,
	particularly Top-Level Domains, which have come to have special
	meanings.
	One of the outcomes from the recent discussion on RFC 6761 [this
	section is written informally] is an assumption that client software,
	that is an application receiving a string that looks like a name
	without any supplimental context, will be able to determine how
	to treat the string within the appropriate naming context. Within
	the familiar world of domain names today, certain top-level names
	are recognized as special (such as those whose last label is local).
	To date there are a limited number of special names, as the number
	scales up, there will be more work for client software developers.
	(See section 4.1 of this document.)
	Note that whether or not the last label takes on this role is
	suggested here solely as an example. Whether it does or not is a
	something for "a solution" for which we don't even have the starting
	point nailed down. Hence, it isn't clear 4.1 should be in this
	document.
	Given a lack of an explicit starting point, meaning a clear definition
	of what Domain Name means, this document is striving to provide a
	foundation.
	2. Reaching a definition of a Domain Name
	Domain Names emerged from the need to build a hierarchy around the		Domain Names emerged from the need to build a hierarchy around the
	growing number of identified hosts exchanging email. RFC 788, "SIMPLE		growing number of identified hosts exchanging email. RFC 788, "SIMPLE
	MAIL TRANSFER PROTOCOL", explains, in its section 3.7:		MAIL TRANSFER PROTOCOL", explains, in its section 3.7:
	"At some not too distant future time it might be necessary to		"At some not too distant future time it might be necessary to
	expand the mailbox format to include a region or name domain		expand the mailbox format to include a region or name domain
	identifier. There is quite a bit of discussion on this at		identifier. There is quite a bit of discussion on this at
	present, and is likely that SMTP will be revised in the future to		present, and is likely that SMTP will be revised in the future to
	take into account naming domains."		take into account naming domains."
	2.1 Historical Perspective
	Knowing the origins of a concept helps setting the correct boundaries		Knowing the origins of a concept helps setting the correct boundaries
	for discussion. The past isn't meant to restrict the future but		for discussion. The past isn't meant to restrict the future but
	meant to help provide a context, include forgotten ideas, and help		meant to help provide a context, include forgotten ideas, and help
	identify rational for scope creep.		identify rational for scope creep.
	RFC 799 "Internet Name Domains" has (arguably) the first formation of		RFC 799 "Internet Name Domains" has (arguably) the first formation of
	what is a Domain Name:		what is a Domain Name:
	"In its most general form, a standard internet mailbox name has		"In its most general form, a standard internet mailbox name has
	the syntax		the syntax
	skipping to change at line 334 ¶		skipping to change at line 276 ¶
	inside RFCs. The precise chain of events is likely slightly		inside RFCs. The precise chain of events is likely slightly
	different and nuanced. The point of the exercise is to show that		different and nuanced. The point of the exercise is to show that
	Domain Names are a concept the emerged over time, spawned the DNS		Domain Names are a concept the emerged over time, spawned the DNS
	with its domain names, a definition of host names derived from the		with its domain names, a definition of host names derived from the
	host tables, and was heavily influenced by SMTP as the driving		host tables, and was heavily influenced by SMTP as the driving
	application. The definition of the FTP protocol, originally defined		application. The definition of the FTP protocol, originally defined
	in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or		in RFC 959 "FILE TRANSFER PROTOCOL", never mentions hosts, domains or
	host names. But no formal definition of Domain Names has been		host names. But no formal definition of Domain Names has been
	written and recorded.		written and recorded.
	2.2 Newly Stated Definition of "Domain Name"		3. Dialects, so to speak, of Domain Names
	Looking through the early documents, and using the experience of the
	past decades, this new definition of Domain Names is stated:
	A Domain Name is a sequence of labels concatenated by a designated
	separating character. The Domain Name Space is organized in a strict
	hierarchical manner with a recognized root Domain Name. The
	organization follows the rules of tree structure as defined by the
	field of graph theory in mathematics [Diestel].
	Each label represents a node in a conceptual tree. The sequence of
	labels is concatenated from the deepest node in the tree up to the
	root node. "Fully qualified" refers to a sequence that ends with the
	root node.
	When considering a fully qualifed name, the first label of the name
	is the name of the deepest node in the tree, the last label is the
	name of the node is the root. The top-level label, top-level name,
	or top-level domain is the label just before the root (or last)
	label.
	Excluded from the definition is the appearance or representation of
	the labels, the designated separator character's representation, the
	ordering of the sequence in appearance, such as left-to-right or
	right-to-left, nor the written script nor encoding. The definition
	is purely conceptual.
	In RFC 819 "Simple Mail Transfer Protocol", the designated separating
	character is the dot ('.') as represented in the ASCII [RFC 20]
	[ANSIX34] character set. This is the earliest application definition
	of how it represents Domain Names.
	2.2.1 Definition from Lyman Chapin
	Included here is an emailed definition from Lyman Chapin, appearing
	in the archives of inip-discuss@ietf.org. The definition is in-line
	with the one in 2.2 except that it refers to a finite name space due
	to length restrictions.
	"In graph-theoretic terms, the domain name space constitutes a
	labelled directed rooted tree in which the syntax of the label
	associated with each vertex other than the unlabelled root is
	defined by RFCs 1035, 1123, and 2181. The term "nth level domain
	name label" refers to a member of the set of all vertices for which
	the path to the root contains n edges. For n=1 the term most often
	used is "top level domain name label" or simply "top level domain"
	(TLD). A fully qualified domain name is a sequence of labels that
	represents a path from the root to a leaf vertex of the domain name
	space. The shorter term "domain name" is not formally defined; in
	common usage it may be the shorthand equivalent of "fully qualified
	domain name" (FQDN) or refer to any non-empty subset of the sequence
	of labels formally identified by a fully qualified domain name.
	"In this formulation, the term "domain name space" refers to the
	complete graph consisting of all possible vertices and edges - not
	just those with which a specific meaning has been associated (what
	we might call "allocated" labels). It is a finite graph because the
	length of the longest possible FQDN is finite. At any point in time,
	there is another labelled directed rooted tree - a sub-graph of the
	domain name space - containing only vertices that represent
	allocated labels."
	2.3 Limitation
	There are many ways to build a name space, Domain Names are just one
	example. Domain Names are intended to build a name space that can
	scale tremendously as opposed to a name space for closed cluster of
	involved objects. Domain Names are used across many protocols
	defined inside and outside the IETF and have been defined to
	interoperate across implementations and protocols. This does not
	make Domain Names an official or required standard despite the name
	space's widespread use.
	2.4 Is This a Domain Name?
	In the vein of questions like "but is it art?" as to whether an
	object is art worthy of display in a museum, one can question
	whether any string with a dot in it is a Domain name. For example,
	is this multi-sentence paragraph a domain name? It has
	characters and dots in it.
	The important question is not whether a string is an example of a
	Domain Name based on its appearence. The use of a string is what
	makes it a Domain Name. A path name of a file with an extension
	looks like a Domain Name with the extension separated by a dot, if one
	allows the directory seperating character (a '/' perhaps) as a legal
	member of a label. Within an OS, this is a file/path name. In a
	protocol it might be used as if it were a domain name.
	3. Subtypes of Domain Names
	Subtypes of Domain Names have come to be defined for different		Subtypes of Domain Names have come to be defined for different
	protocols, evolving and sometimes building on previous definitions.		protocols, evolving and sometimes building on previous definitions.
	3.1 Domain Names as Restricted for DNS		3.1 Domain Names as Restricted for DNS
	The DNS protocol place size restrictions on Domain Names and defines		The DNS protocol place size restrictions on Domain Names and defines
	rules for matching domain names, treating sets of Domain Names as		rules for matching domain names, treating sets of Domain Names as
	equivalent to each other. (This matching refers to treating upper		equivalent to each other. (This matching refers to treating upper
	case and lower case ASCII letters as equivalent.) The DNS defines		case and lower case ASCII letters as equivalent.) The DNS defines
	skipping to change at line 478 ¶		skipping to change at line 330 ¶
	Domain Name (as a comment line parameter as an example) would		Domain Name (as a comment line parameter as an example) would
	opt to treat the string as an address literal and would therefore		opt to treat the string as an address literal and would therefore
	not look for the string in the DNS domain name space. The management		not look for the string in the DNS domain name space. The management
	model of the DNS would prefer to aggregate (as in routing) addresses		model of the DNS would prefer to aggregate (as in routing) addresses
	belonging together in the same zone, resulting in labels appearing in		belonging together in the same zone, resulting in labels appearing in
	reverse order. E.g., the network address 192.0.2.1 would be		reverse order. E.g., the network address 192.0.2.1 would be
	represented by a DNS domain name as "1.2.0.192.in-addr.arpa."		represented by a DNS domain name as "1.2.0.192.in-addr.arpa."
	as described in RFC 1035. For IPv6, the convention used is documented		as described in RFC 1035. For IPv6, the convention used is documented
	in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5.		in "DNS Extensions to Support IP Version 6" [RFC 3596], section 2.5.
			See also "Issues in Identifier Comparison for Security Purposes" [RFC
			6943] section 3.1, "Host Names", in particular section 3.1.1 and 3.1.2
			on address literals, and section 4.1, "Conflation."
	DNS domain names have become the dominant definition of domain names		DNS domain names have become the dominant definition of domain names
	due to the success (scale) of the DNS on the public Internet. Many		due to the success (scale) of the DNS on the public Internet. Many
	protocols interact with the DNS but instead of supporting the		protocols interact with the DNS but instead of supporting the
	complete definition of DNS domain names, the protocols rely on a		complete definition of DNS domain names, the protocols rely on a
	subset more commonly called host names.		subset more commonly called host names.
	3.2 Host Names		3.2 Host Names
	Work on the definition of a host name began well before the issuance		Work on the definition of a host name began well before the issuance
	of the STD 13 documents defining DNS. The rules for the Preferred		of the STD 13 documents defining DNS. The rules for the Preferred
	skipping to change at line 504 ¶		skipping to change at line 360 ¶
	Host names are subsets of DNS domain names in the sense that the		Host names are subsets of DNS domain names in the sense that the
	character set is limited. In particular, only "let" (i.e.,		character set is limited. In particular, only "let" (i.e.,
	presumably letters a-z), "digits" and "hyphen" can be used, with		presumably letters a-z), "digits" and "hyphen" can be used, with
	hyphen only internal to a label. (This description is meant to be		hyphen only internal to a label. (This description is meant to be
	illustrative, not normative. See the grammar presented on page 5 of		illustrative, not normative. See the grammar presented on page 5 of
	RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol --		RFC 952 for specifics.) RFC 1945 "Hypertext Transfer Protocol --
	HTTP/1.0", Section 3.2.2 "http URL" specifically references section		HTTP/1.0", Section 3.2.2 "http URL" specifically references section
	2.1 of RFC 1123. The reference is explicit.		2.1 of RFC 1123. The reference is explicit.
	RFC 5321 " Simple Mail Transfer Protocol" refers to RFC 1035 for a		"Simple Mail Transfer Protocol" [RFC 5321] refers to RFC 1035 for a
	definition of domain names but includes text close to what is in the		definition of domain names but includes text close to what is in the
	previous paragraph, noting that domain names as used in SMTP refer to		previous paragraph, noting that domain names as used in SMTP refer to
	both hosts and to other entities. RFC 5321 updates RFC 1123, but		both hosts and to other entities. RFC 5321 updates RFC 1123, but
	does not cite the latter for a definition of host names. RFC 5321		does not cite the latter for a definition of host names. RFC 5321
	additionally requires brackets to surround address literals,		additionally requires brackets to surround address literals,
	referring to the use case as an "alternative to a domain name."		referring to the use case as an "alternative to a domain name."
			See also "IAB Thoughts on Encodings for Internationalized Domain Names"
			[RFC 6055], particularly section 3 entitled "Use of Non-ASCII in DNS"
			for more thoughts on host names.
	3.3 URI Authority and Domain Names		3.3 URI Authority and Domain Names
	In RFC 3986, also known as STD 66, "Uniform Resource Identifier		In "Uniform Resource Identifier (URI): Generic Syntax" [RFC 3986], also
	(URI): Generic Syntax", mentions in its section 3.2.2 (page 20)		known as STD 66, mentions in its section 3.2.2 (page 20) that the host
	that the host subcomponent of the URI Authority (section 3.2) "should		subcomponent of the URI Authority (section 3.2) "should conform to the
	conform to the DNS syntax". This comes after discussion that		DNS syntax". This comes after discussion that the host subcomponent
	the host subcomponent is not strongly tied to the DNS, i.e., names		is not strongly tied to the DNS, i.e., names can be managed via a
	can be managed via concept other than the DNS. There's no		concept other than the DNS. There's no discussion on the rationale
	discussion on the rationale but this enables the reuse of code		but this enables the reuse of code parsing and marshalling the host
	parsing and marshalling the host subcomponent between different		subcomponent between different Domain Name environments.
	Domain Name environments.
	This reinforces the notion that there's a need to understand how		This reinforces the notion that there's a need to understand how Domain
	Domain Names interoperate amongst protocols and applications. And		Names interoperate amongst protocols and applications. And reinforces
	reinforces the need to derive or make explicit a way for client		the need to derive or make explicit a way for client software to know
	software to know how to resolve a name, that is, convert a name		how to resolve a name, that is, convert a name into a network address.
	into a network address.
	3.4 Internet Protocol Address Literals		3.4 Internet Protocol Address Literals
	The above definition includes address literals such as 192.0.2.1 for		The above definition includes address literals such as 192.0.2.1 for
	IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these		IPv4 and even IPv6 literals such as ::ffff:192.0.2.1. Yes, these
	qualify as Domain Names. In some protocols, these domain names are		qualify as Domain Names. In some protocols, these domain names are
	specified as being preceded by a "#" (find this and cite) or encased		specified as being preceded by a "#" (find this and cite) or encased
	in square brackets "[" and "]" (SMTP mentioned already). In the DNS,		in square brackets "[" and "]" (SMTP mentioned already). In the DNS,
	as previously described in section 3.1, they are represented		as previously described in section 3.1, they are represented
	according to appropriate conventions.		according to appropriate conventions.
	3.5 Internationalized Domain Names in Applications		3.5 Internationalized Domain Names in Applications
	The original uses of Domain Names (such as DNS domain names		The original uses of Domain Names (such as DNS domain names
	and host names) assumed the ASCII character set. Specifically,		and host names) assumed the ASCII character set. Specifically,
	making the labels case insensitive prohibited a straightforward use		making the labels case insensitive prohibited a straightforward use
	of any method of representation of non-ASCII characters.		of any method of representation of non-ASCII characters.
	RFC 5890 "Internationalized Domain Names for Applications (IDNA):		"Internationalized Domain Names for Applications (IDNA): Definitions
	Definitions and Document Framework", with associated other documents,		and Document Framework" [RFC 5890], with associated other documents,
	defines IDNA2008 as a convention for handling non-ASCII characters in		defines IDNA2008 as a convention for handling non-ASCII characters in
	DNS domain names. In figure 1 of that document, the sets of legal DNS		DNS domain names. In figure 1 of that document, the sets of legal DNS
	domain name formats are defined. Noted in the footnotes of the		domain name formats are defined. Noted in the footnotes of the
	figure, applications unaware of IDNA2008 cannot distinguish the sub		figure, applications unaware of IDNA2008 cannot distinguish the subsets
	sets defined by the document meaning this definition is not an		defined by the document meaning this definition is not an alteration
	alteration of Domain Names, but, like host names, yet another subset		of Domain Names, but, like host names, yet another subset of DNS
	of DNS domain names.		domain names.
	Open question - how closely is IDNA tied to DNS domain names as
	opposed to Domain Names? "IAB Thoughts on Encodings for
	Internationalized Domain Names" [RFC 6055], discusses the
	representations of IDNs.
	3.6 Restricted for DNS Registration		3.6 Restricted for DNS Registration
	RFC 4290 "Suggested Practices for Registration of Internationalized		"Suggested Practices for Registration of Internationalized Domain Names
	Domain Names (IDN)" presents reasons why registration of DNS domain		(IDN)" [RFC 4290] presents reasons why registration of DNS domain
	names is restricted, in the context of IDN. (That RFC refers to an		names is restricted, in the context of IDN. (That RFC refers to an
	older form than IDNA2008, but the concepts still apply.) This is yet		older form than IDNA2008, but the concepts still apply.) This is yet
	another convention related to DNS domain names, excluding names that		another convention related to DNS domain names, excluding names that
	would lead to undesirable outcomes.		would lead to undesirable outcomes.
	3.7 Tor Network Names		3.7 Tor Network Names
	The Tor network is an activity organized by the Tor Project, Inc.,		The Tor network is an activity organized by the Tor Project, Inc.,
	described on its main web page		described on its main web page
	"https://www.torproject.org/index.html.en". One component of the		"https://www.torproject.org/index.html.en". One component of the
	skipping to change at line 593 ¶		skipping to change at line 446 ¶
	Syntactically, a Tor domain name fits within the DNS domain name		Syntactically, a Tor domain name fits within the DNS domain name
	definition but the manner of assignment is different in a manner		definition but the manner of assignment is different in a manner
	incompatible with the DNS. (Not better or worse, still significantly		incompatible with the DNS. (Not better or worse, still significantly
	different.) Tor domain names are derived from cryptographic keys and		different.) Tor domain names are derived from cryptographic keys and
	organized by distributed hash tables, instead of assigned by a central		organized by distributed hash tables, instead of assigned by a central
	authority per zone.		authority per zone.
	3.8 X.509		3.8 X.509
	In RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and		"Internet X.509 Public Key Infrastructure Certificate and Certificate
	Certificate Revocation List (CRL) Profile", section 4.2.1.6 "Subject		Revocation List (CRL) Profile" [RFC 5280], section 4.2.1.6 "Subject
	Alternative Name" a dNSName is defined to be a host name, with the		Alternative Name" a dNSName is defined to be a host name, with the
	further restriction that the name " " cannot be used.		further restriction that the name " " cannot be used. (The sublte
			irony is that a name consisting of just a blank would hardly qualify
			as a Domain Name.)
	3.9 Multicast DNS		3.9 Multicast DNS
	Multicast DNS uses a name space ending with ".local." as described in		Multicast DNS uses a name space ending with ".local." as described in
	RFC 6762, "Multicast DNS". The rules for Multicast DNS domain names		"Multicast DNS" [RFC 6762]. The rules for Multicast DNS domain names
	differ from DNS domain names. Multicast DNS domain names are encoded		differ from DNS domain names. Multicast DNS domain names are encoded
	as Net-Unicode as defined in RFC5198 " Unicode Format for Network		as Net-Unicode as defined in RFC5198 " Unicode Format for Network
	Interchange" with the DNS domain name tradition of case folding the		Interchange" with the DNS domain name tradition of case folding the
	ASCII letters when matching names. Appendix F of RFC 6762 gives an		ASCII letters when matching names. Appendix F of RFC 6762 gives an
	explanation of why the punycode algorithm is not used.		explanation of why the punycode algorithm is not used.
	3.10 /etc/hosts		3.10 /etc/hosts
	The precursor to DNS, host tables, still exists in remnants in many		The precursor to DNS, host tables, still exists in remnants in many
	operating systems. There are library functions, used by applications		operating systems. There are library functions, used by applications
	to resolve DNS domain names, that can return names of arbitrary		to resolve DNS domain names, that can return names of arbitrary
	length (meaning, for example longer than what DNS domain names are		length (meaning, for example longer than what DNS domain names are
	defined to be).		defined to be).
	RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses		RFC 3493, "Basic Socket Interface Extensions for IPv6", addresses
	this in Section 6, further documentation can be found as part of		this in Section 6, further documentation can be found as part of
	The Open Group Base Specificatoins Issue 7 [IEEE1003.1] and Microsoft		The Open Group Base Specifications Issue 7 [IEEE1003.1] and Microsoft
	Winsock Functions [WINSOCK].		Winsock Functions [WINSOCK].
	3.11 Other Protocols		3.11 Other Protocols
	This section is used to enumerate other protocols that use Domain		This section is used to list (some) other protocols that use Domain
	Names but in general do not impose any other restrictions that what		Names but in general do not impose any other restrictions that what
	has been mentioned above.		has been mentioned above.
	SSH [RFC 4251 "The Secure Shell (SSH) Protocol Architecture"] uses		SSH, documented in "The Secure Shell (SSH) Protocol Architecture"
	host names, using the name when storing public keys of hosts. SSH		[RFC 4251] uses host names, using the name when storing public keys
	clients, not necessarily the protocol, illustrate how applications		of hosts. SSH clients, not necessarily the protocol, illustrate how
	juggle the different forms of Domain Names. SSH can be invoked to		applications juggle the different forms of Domain Names. SSH can be
	open a secure shell with a host via its DNS domain name/host name or		invoked to open a secure shell with a host via its DNS domain
	it can be used to open a secure shell with a host via its Multicast		name/host name or it can be used to open a secure shell with a host
	DNS domain name.		via its Multicast DNS domain name. (Note that SSH does not distinguish
			between DNS names and Multicast DNS domain names in the protocol
			definition, the difference is handled in resolution libraries belonging
			to the computing platform.)
	FTP [RFC 959 " FILE TRANSFER PROTOCOL (FTP)"] is silent on domain		FTP, defined in "FILE TRANSFER PROTOCOL (FTP)" [RFC 959], is silent on
	names but client implementations of the protocol behave as SSH		domain names but client implementations of the protocol behave as SSH
	clients, being un aware the differences between definitions of Domain		clients, being un aware the differences between definitions of Domain
	Names (DNS vs. MulticastDNS).		Names.
	DHCP [RFC 2131 "Dynamic Host Configuration Protocol"] includes domain		DHCP, defined in "Dynamic Host Configuration Protocol" [RFC 2131],
	names in its Domain Search Option [RFC 3397 "Dynamic Host		includes domain names in its Domain Search Option [RFC 3397 "Dynamic
	Configuration Protocol (DHCP) Domain Search Option"]. The encoding of		Host Configuration Protocol (DHCP) Domain Search Option"]. The
	Domain Names used is the on-the-wire format of the DNS, using		encoding of Domain Names used is the on-the-wire format of the DNS,
	DNS-defined message compression. DHCP handles Domain Names in other		using DNS-defined message compression. DHCP handles Domain Names in
	options such as in RFC 4702 defined "The DHCP Client FQDN Option", in		other options such as in RFC 4702 defined "The DHCP Client FQDN
	the same format. The significance of this is that most other		Option", in the same format. The significance of this is that most
	protocols represent DNS domain names or host names in a human readable		other protocols represent DNS domain names or host names in a human
	form, DHCP is using the machine-friendly format.		readable form, DHCP is using the machine-friendly format.
			3.12 Other others
			If there is a use of Domain Names not listed here it is merely an
			omission. The goal in this document is to provide a survey that
			is sufficient to avoid hand-waving arguments, recognizing the
			diminishing return in trying to build a complete roster of uses
			of Domain Names. If there are omissions that ought to be included,
			please send references for the use case to the author (while this is
			an Internet Draft, that is).
	4. Interoperability Considerations		4. Interoperability Considerations
	Any single protocol is able to define a format for a conceptual Domain		Any single protocol is able to define a format for a conceptual Domain
	Name. Examples given above show that many protocol have done so.		Name. Examples given above show that many protocols have done so.
	From the examples it is clear that the way in which protocols have		From the examples it is clear that the way in which protocols have
	interpreted Domain Names has varied, leading to, at least, user		interpreted Domain Names has varied, leading to, at least, user
	interfaces having to have built-in intelligence when handling names		interfaces having to have built-in intelligence when handling names
	and, at worst, a growing confusion over how the Domain Name space is		and, at worst, a growing confusion over how the Domain Name space is
	to be managed.		to be managed.
	When protocols having different formats and rules for Domain Names		When protocols having different formats and rules for Domain Names
	interact, software implementing the protocols translate one protocol's		interact, software implementing the protocols translate one protocol's
	domain name format to another's format. Even when the translation is		domain name format to another's format. Even when the translation is
	straightforward, software often fails to handle error conditions well.		straightforward, software often fails to handle error conditions well.
	(Is there a citation for that?)		(Is there a citation for that?)
	Often times the clash of definitions impacts the design of a new		Often times the clash of definitions impacts the design of a new
	protocol and/or an extension of a protocol. For example, adding		protocol and/or an extension of a protocol. For example, adding
	non-ASCII domain names has to be done with backwards compatibility		non-ASCII domain names has to be done with backwards compatibility
	with an installed base of ASCII-assuming code. This clash can		with an installed base of ASCII-assuming code. This clash can
	inhibit new uses of Domain Names.		inhibit new uses of Domain Names.
	Search lists are a Domain Name mechanism studied in SAC064 "SSAC		Search lists are a Domain Name mechanism studied in "SSAC Advisory
	Advisory on DNS 'Search List' Processing". One of the particular		on DNS 'Search List' Processing" [SAC 064]. One of the particular
	use cases related to this topic is the issuance of search lists via		use cases related to this topic is the issuance of search lists via
	DHCP and then used by any user-client protocol implementation. This		DHCP and then used by any user-client protocol implementation. This
	emphasizes an interoperability consideration for how Domain Names		emphasizes an interoperability consideration for how Domain Names
	are treated in different protocols, not just among implementations of		are treated in different protocols, not just among implementations of
	one protocol.		one protocol.
	The definition of a Fully Qualified Domain Name has two forms. The		The definition of a Fully Qualified Domain Name has two forms. The
	discussion over FQDN involved human-readable names. The principle		discussion over FQDN involved human-readable names. The principle
	question is whether to require the terminating dot or to assume it		question is whether to require the terminating dot or to assume it
	when the end of an input string is hit. Many protocol clients will		when the end of an input string is hit. Some protocol clients will
	silently add a dot when a user types in a name to a command line. But		silently add a dot when a user types in a name to a command line,
	some definitions, such as the one in SAC064 require the terminating		others will do so if there is a dot inside the name. [No reference]
	dot to be included before a name is considered to be fully qualified.		But some definitions, such as the one in the previously referenced
			SSAC advisory, require the terminating dot to be included before a name
			is considered to be fully qualified.
	The Special Use Domain Names registry defined in RFC 6761 lists Domain		The Special Use Domain Names registry lists Domain Names that are to
	Names that are to be treated in a manner inconsistent with the DNS		be treated in a manner inconsistent with the DNS normal processing
	normal processing rules. This registry contains Domain Names		rules. This registry contains Domain Names regardless of whether the
	regardless of whether the name is a DNS domain name and regardless		name is a DNS domain name and regardless whether the name is a
	whether the name is a top-level (domain) name [RFC 819] or is		top-level (domain) name [RFC 819] or is positioned elsewhere in the
	positioned elsewhere in the tree structure.		tree structure.
	These are reasons this document is needed. The reason for the		These are reasons this document is needed. The reason for the
	confusion over what's a legal domain name stems from		confusion over what's a legal domain name stems from
	application-defined restrictions. For example, using a one-label		application-defined restrictions. For example, using a one-label
	domain name ("dotless") for sending email is not a problem with the		domain name ("dotless") for sending email is not a problem with the
	DNS nor the name in concept, but is a problem for mail implementations		DNS nor the name in concept, but is a problem for mail implementations
	that expect more than one label. (One-label names may be assumed to		that expect more than one label. (One-label names may be assumed to
	be in ARPA host table format.)		be in ARPA host table format.) The "IAB Statement: Dotless Domains
			Considered Harmful" [IAB Stmt] elaborates.
	4.1(*) Use of Top-Level Domains as Protocol Identifiers
	(Would like to have "dns" and "dns<digit>" added to the Special Use
	Domain Names registry. As well as the digits [address literals].)
	(*) - I am not sure this belongs in this document. The idea is what
	one can select a name space by the top-level domain (label). I
	believe this would be scope creep for this document. Leaving it
	here for consideration.
	5. Acknowledgements		5. Acknowledgements
	Input received from Andrew Sullivan and Paul Hoffman. Not to imply		The definition of domain names was lifted from an email from Lyman
	endorsements of the text.		Chapin. The URL for that message is (combine the two lines):
	The definition in 2.2.1 was lifted from an email from Lyman Chapin.
	The URL for that message is (combine the two lines):
	https://mailarchive.ietf.org/arch/msg/inip-discuss/		https://mailarchive.ietf.org/arch/msg/inip-discuss/
	cqvFTt3_ve9EBOQfA9TlcqgTIFc		cqvFTt3_ve9EBOQfA9TlcqgTIFc
	Comments from George Michaelson, Kevin Darcy, Joe Abley, Jim Reid,		The definition has since been removed from this draft.
	Tony Finch, Robert Edmonds, hellekin, Stephane Bortzmeyer, Ray Bellis,
	Bob Harold, Alec Muffett, Stuart Cheshire and a growing list of		Comments from Andrew Sullivan, Paul Hoffman, George Michaelson,
	others I am losing track of. Not to imply endorsement.		Kevin Darcy, Joe Abley, Jim Reid, Tony Finch, Robert Edmonds,
			hellekin, Stephane Bortzmeyer, Ray Bellis, Bob Harold, Alec Muffett,
			Stuart Cheshire, Dave Thaler and a growing list of others I am losing
			track of. Not to imply endorsement.
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. Security Considerations		7. Security Considerations
	Nothing direct. This document proposes a definition of the term		Nothing direct. This document proposes a definition of the term
	"Domain Name" and surveys how it has been variously applied. In		"Domain Name" and surveys how it has been variously applied. In
	some sense, loosely defined terms give rise to security hazards.		some sense, loosely defined terms give rise to security hazards.
	skipping to change at line 814 ¶		skipping to change at line 675 ¶
	RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext		RFC 1945 Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945, DOI		Transfer Protocol -- HTTP/1.0", RFC 1945, DOI
	10.17487/RFC1945, May 1996,		10.17487/RFC1945, May 1996,
	<http://www.rfc-editor.org/info/rfc1945>.		<http://www.rfc-editor.org/info/rfc1945>.
	RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		RFC 2131 Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	DOI 10.17487/RFC2131, March 1997,		DOI 10.17487/RFC2131, March 1997,
	<http://www.rfc-editor.org/info/rfc2131>.		<http://www.rfc-editor.org/info/rfc2131>.
			RFC 2860 Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
			Understanding Concerning the Technical Work of the Internet
			Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860,
			June 2000, <http://www.rfc-editor.org/info/rfc2860>.
	RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration		RFC 3397 Aboba, B. and S. Cheshire, "Dynamic Host Configuration
	Protocol (DHCP) Domain Search Option", RFC 3397,		Protocol (DHCP) Domain Search Option", RFC 3397,
	DOI 10.17487/RFC3397, November 2002,		DOI 10.17487/RFC3397, November 2002,
	<http://www.rfc-editor.org/info/rfc3397>.		<http://www.rfc-editor.org/info/rfc3397>.
	RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode		RFC 3492 Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications (IDNA)",		for Internationalized Domain Names in Applications (IDNA)",
	RFC 3492, DOI 10.17487/RFC3492, March 2003,		RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<http://www.rfc-editor.org/info/rfc3492>.		<http://www.rfc-editor.org/info/rfc3492>.
	skipping to change at line 885 ¶		skipping to change at line 751 ¶
	<http://www.rfc-editor.org/info/rfc6055>.		<http://www.rfc-editor.org/info/rfc6055>.
	RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names",		RFC 6761 Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
	RFC 6761, DOI 10.17487/RFC6761, February 2013,		RFC 6761, DOI 10.17487/RFC6761, February 2013,
	<http://www.rfc-editor.org/info/rfc6761>.		<http://www.rfc-editor.org/info/rfc6761>.
	RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		RFC 6762 Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	DOI 10.17487/RFC6762, February 2013,		DOI 10.17487/RFC6762, February 2013,
	<http://www.rfc-editor.org/info/rfc6762>.		<http://www.rfc-editor.org/info/rfc6762>.
			RFC 6943 Thaler, D., Ed., "Issues in Identifier Comparison for
			Security Purposes", RFC 6943, DOI 10.17487/RFC6943,
			May 2013, <http://www.rfc-editor.org/info/rfc6943>.
			RFC 7686 Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
			Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015,
			<http://www.rfc-editor.org/info/rfc7686>.
	Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg		Diestel Diestel, R., "Graph Theory", Springer-Verlag, Heidelberg
	Graduate Texts in Mathematics, Volume 173 ISBN		Graduate Texts in Mathematics, Volume 173 ISBN
	978-3-642-14278-9, July 2010 (2005, 2000, 1997),		978-3-642-14278-9, July 2010 (2005, 2000, 1997),
	<http://diestel-graph-theory.com>		<http://diestel-graph-theory.com>
	SAC064 ICANN Security and Stability Committee, "SSAC Advisory on		SAC064 ICANN Security and Stability Committee, "SSAC Advisory on
	Search List Processing", SAC064, February 2014,		Search List Processing", SAC064, February 2014,
	<https://www.icann.org/en/system/files/files/sac-064-en.pdf>		<https://www.icann.org/en/system/files/files/sac-064-en.pdf>
	RENDEV Anonymous, "Tor Rendezvous Specification", Undated,		RENDEV Anonymous, "Tor Rendezvous Specification", Undated,
	<https://gitweb.torproject.org/torspec.git/tree/		<https://gitweb.torproject.org/torspec.git/tree/
	rend-spec.txt>		rend-spec.txt>
	OHOST Nick Mathewson, "Special Hostnames in Tor", Undated,		OHOST Nick Mathewson, "Special Hostnames in Tor", Undated,
	<https://gitweb.torproject.org/torspec.git/tree/		<https://gitweb.torproject.org/torspec.git/tree/
	address-spec.txt>		address-spec.txt>
			IABStmt IAB, 2013, <https://www.iab.org/documents/
			correspondence-reports-documents/2013-2/
			iab-statement-dotless-domains-considered-harmful/>
	IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std		IEEE1003 The Open Group Base Specifications Issue 7, IEEE Std
	1003.1, 2013 Edition, Copyright 2001-2013 The IEEE		1003.1, 2013 Edition, Copyright 2001-2013 The IEEE
	and The Open Group,		and The Open Group,
	<http://pubs.opengroup.org/onlinepubs/9699919799/		<http://pubs.opengroup.org/onlinepubs/9699919799/
	functions/freeaddrinfo.html>		functions/freeaddrinfo.html>
	WINSOCK URL only, <https://msdn.microsoft.com/en-us/library/		WINSOCK URL only, <https://msdn.microsoft.com/en-us/library/
	windows/desktop/ms738520(v=vs.85).aspx>		windows/desktop/ms738520(v=vs.85).aspx>
	9. Author's Address		9. Author's Address
	Edward Lewis		Edward Lewis
	ICANN		ICANN
	801 17th Street NW		801 17th Street NW
	Suite 401		Suite 401
	Washington DC, 20006 US		Washington DC, 20006 US
	edward.lewis@icann.org		edward.lewis@icann.org
	Lewis Expires July 30, 2016 [Page 1]		Lewis Expires January 1, 2016 [Page 1]
End of changes. 51 change blocks.
	316 lines changed or deleted		194 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/