draft-ietf-regext-rdap-object-tag-05.txt		rfc8521.txt
	Registration Protocols Extensions S. Hollenbeck		Internet Engineering Task Force (IETF) S. Hollenbeck
	Internet-Draft Verisign Labs		Request for Comments: 8521 Verisign Labs
	Updates: 7484 (if approved) A. Newton		BCP: 221 A. Newton
	Intended status: Best Current Practice ARIN		Updates: 7484 ARIN
	Expires: February 4, 2019 August 3, 2018		Category: Best Current Practice November 2018
			ISSN: 2070-1721
	Registration Data Access Protocol (RDAP) Object Tagging		Registration Data Access Protocol (RDAP) Object Tagging
	draft-ietf-regext-rdap-object-tag-05
	Abstract		Abstract
	The Registration Data Access Protocol (RDAP) includes a method that		The Registration Data Access Protocol (RDAP) includes a method that
	can be used to identify the authoritative server for processing		can be used to identify the authoritative server for processing
	domain name, IP address, and autonomous system number queries. The		domain name, IP address, and autonomous system number queries. The
	method does not describe how to identify the authoritative server for		method does not describe how to identify the authoritative server for
	processing other RDAP query types, such as entity queries. This		processing other RDAP query types, such as entity queries. This
	limitation exists because the identifiers associated with these query		limitation exists because the identifiers associated with these query
	types are typically unstructured. This document updates RFC 7484 by		types are typically unstructured. This document updates RFC 7484 by
	describing an operational practice that can be used to add structure		describing an operational practice that can be used to add structure
	to RDAP identifiers that makes it possible to identify the		to RDAP identifiers and that makes it possible to identify the
	authoritative server for additional RDAP queries.		authoritative server for additional RDAP queries.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This memo documents an Internet Best Current Practice.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			BCPs is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on February 4, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8521.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3		2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3
	3. Bootstrap Service Registry for Provider Object Tags . . . . . 8		3. Bootstrap Service Registry for Provider Object Tags . . . . . 9
	3.1. Registration Procedure . . . . . . . . . . . . . . . . . 9		3.1. Registration Procedure . . . . . . . . . . . . . . . . . 10
	4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10		4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Bootstrap Service Registry Structure . . . . . . . . . . 10		5.1. Bootstrap Service Registry Structure . . . . . . . . . . 11
	5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 10		5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 11
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6.1. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.2. OpenRDAP . . . . . . . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Registration Data Access Protocol (RDAP) includes a method		The Registration Data Access Protocol (RDAP) includes a method
	([RFC7484]) that can be used to identify the authoritative server for		[RFC7484] that can be used to identify the authoritative server for
	processing domain name, IP address, and autonomous system number		processing domain name, IP address, and Autonomous System Number
	(ASN) queries. This method works because each of these data elements		(ASN) queries. This method works because each of these data elements
	is structured in a way that facilitates automated parsing of the		is structured in a way that facilitates automated parsing of the
	element and association of the data element with a particular RDAP		element and association of the data element with a particular RDAP
	service provider. For example, domain names include labels (such as		service provider. For example, domain names include labels (such as
	"com", "net", and "org") that are associated with specific service		"com", "net", and "org") that are associated with specific service
	providers.		providers.
	As noted in Section 9 of RFC 7484 [RFC7484], the method does not		As noted in Section 9 of RFC 7484 [RFC7484], the method does not
	describe how to identify the authoritative server for processing		describe how to identify the authoritative server for processing
	entity queries, name server queries, help queries, or queries using		entity queries, name server queries, help queries, or queries using
	certain search patterns. This limitation exists because the		certain search patterns. This limitation exists because the
	identifiers bound to these queries are typically not structured in a		identifiers bound to these queries are typically not structured in a
	way that makes it easy to associate an identifier with a specific		way that makes it easy to associate an identifier with a specific
	service provider. This document describes an operational practice		service provider. This document describes an operational practice
	that can be used to add structure to RDAP identifiers that makes it		that can be used to add structure to RDAP identifiers and makes it
	possible to identify the authoritative server for additional RDAP		possible to identify the authoritative server for additional RDAP
	queries.		queries.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Object Naming Practice		2. Object Naming Practice
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 50 ¶
	character "-" (U+002D, described as an "unreserved" character in RFC		character "-" (U+002D, described as an "unreserved" character in RFC
	3986 [RFC3986]) to an IANA-registered value that represents the		3986 [RFC3986]) to an IANA-registered value that represents the
	service provider. For example, a tag for a service provider		service provider. For example, a tag for a service provider
	identified by the string value "ARIN" is represented as "-ARIN".		identified by the string value "ARIN" is represented as "-ARIN".
	In combination with the rdapConformance attribute described in		In combination with the rdapConformance attribute described in
	Section 4, service provider tags are concatenated to the end of RDAP		Section 4, service provider tags are concatenated to the end of RDAP
	query object identifiers to unambiguously identify the authoritative		query object identifiers to unambiguously identify the authoritative
	server for processing an RDAP query. Building on the example from		server for processing an RDAP query. Building on the example from
	Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be		Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be
	constructed that allows an RDAP client to bootstrap an entity query.		constructed to allow an RDAP client to bootstrap an entity query.
	The following identifier is used to find information for the entity		The following identifier is used to find information for the entity
	associated with handle "XXXX" at service provider "ARIN":		associated with handle "XXXX" at service provider "ARIN":
	XXXX-ARIN		XXXX-ARIN
	Clients that wish to bootstrap an entity query can parse this		Clients that wish to bootstrap an entity query can parse this
	identifier into distinct handle and service provider identifier		identifier into distinct handle and service provider identifier
	elements. Handles can themselves contain HYPHEN-MINUS characters;		elements. Handles can themselves contain HYPHEN-MINUS characters;
	the service provider identifier is found following the last HYPHEN-		the service provider identifier is found following the last HYPHEN-
	MINUS character in the tagged identifier. The service provider		MINUS character in the tagged identifier. The service provider
	identifier is used to retrieve a base RDAP URL from an IANA registry.		identifier is used to retrieve a base RDAP URL from an IANA registry.
	The base URL and entity handle are then used to form a complete RDAP		The base URL and entity handle are then used to form a complete RDAP
	query path segment. For example, if the base RDAP URL		query path segment. For example, if the base RDAP URL
	"https://example.com/rdap/" is associated with service provider		"https://example.com/rdap/" is associated with service provider
	"YYYY" in an IANA registry, an RDAP client will parse a tagged entity		"YYYY" in an IANA registry, an RDAP client will parse a tagged entity
	identifier "XXXX-YYYY" into distinct handle ("XXXX") and service		identifier "XXXX-YYYY" into distinct handle ("XXXX") and service
	provider ("YYYY") identifiers. The service provider identifier		provider ("YYYY") identifiers. The service provider identifier
	"YYYY" is used to query an IANA registry to retrieve the base RDAP		"YYYY" is used to query an IANA registry to retrieve the base RDAP
	URL "https://example.com/rdap/". The RDAP query URL is formed using		URL "https://example.com/rdap/". The RDAP query URL is formed using
	the base RDAP URL and entity path segment described in Section 3.1.5		the base RDAP URL and entity path segment described in Section 3.1.5
	of RFC 7482 [RFC7482], using "XXXX-YYY" as the value of the handle		of RFC 7482 [RFC7482] and using "XXXX-YYY" as the value of the handle
	identifier. The complete RDAP query URL becomes		identifier. The complete RDAP query URL becomes
	"https://example.com/rdap/entity/XXXX-YYYY".		"https://example.com/rdap/entity/XXXX-YYYY".
	Implementation of this practice requires tagging of unstructured		Implementation of this practice requires tagging of unstructured
	potential query identifiers in RDAP responses. Consider these elided		potential query identifiers in RDAP responses. Consider these elided
	examples ("..." is used to note elided response objects) from		examples ("..." is used to note elided response objects) from
	Section 5.3 of RFC 7483 [RFC7483] in which the handle identifiers		Section 5.3 of RFC 7483 [RFC7483] in which the handle identifiers
	have been tagged with service provider tags "RIR", "DNR", and "ABC"		have been tagged with service provider tags "RIR", "DNR", and "ABC",
	respectively:		respectively:
	{		{
	"objectClassName" : "domain",		"objectClassName" : "domain",
	"handle" : "XXXX-RIR",		"handle" : "XXXX-RIR",
	"ldhName" : "0.2.192.in-addr.arpa",		"ldhName" : "0.2.192.in-addr.arpa",
	"nameservers" :		"nameservers" :
	[		[
	...		...
	],		],
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 25 ¶
	As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can		As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can
	contain "self" links. Service provider tags and self references		contain "self" links. Service provider tags and self references
	SHOULD be consistent. If they are inconsistent, the service provider		SHOULD be consistent. If they are inconsistent, the service provider
	tag is processed with higher priority when using these values to		tag is processed with higher priority when using these values to
	identify a service provider.		identify a service provider.
	There is a risk of unpredictable processing behavior if the HYPHEN-		There is a risk of unpredictable processing behavior if the HYPHEN-
	MINUS character is used for naturally occurring, non-separator		MINUS character is used for naturally occurring, non-separator
	purposes in an entity handle. This could lead to a client mistakenly		purposes in an entity handle. This could lead to a client mistakenly
	assuming that a HYPHEN-MINUS character represents a separator and the		assuming that a HYPHEN-MINUS character represents a separator and
	text that follows HYPHEN-MINUS is a service provider identifier. A		that the text that follows HYPHEN-MINUS is a service provider
	client that queries the IANA registry for what they assume is a valid		identifier. A client that queries the IANA registry for what they
	service provider will likely receive an unexpected, invalid result.		assume is a valid service provider will likely receive an unexpected,
	As a consequence, use of the HYPHEN-MINUS character as a service		invalid result. As a consequence, use of the HYPHEN-MINUS character
	provider tag separator MUST be noted by adding an rdapConformance		as a service provider tag separator MUST be noted by adding an
	value to query responses as described in Section 4.		rdapConformance value to query responses as described in Section 4.
	The HYPHEN-MINUS character was chosen as a separator for two reasons:		The HYPHEN-MINUS character was chosen as a separator for two reasons:
	1) it is a familiar separator character in operational use, and 2) it		1) it is a familiar separator character in operational use, and 2) it
	avoids collision with URI-reserved characters. The list of		avoids collision with URI-reserved characters. The list of
	unreserved characters specified in Section 2.3 of RFC 3986 [RFC3986]		unreserved characters specified in Section 2.3 of RFC 3986 [RFC3986]
	provided multiple options for consideration:		provided multiple options for consideration:
	unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"		unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
	ALPHA and DIGIT characters were excluded because they are commonly		ALPHA and DIGIT characters were excluded because they are commonly
	used in entity handles for non-separator purposes. HYPHEN-MINUS is		used in entity handles for non-separator purposes. HYPHEN-MINUS is
	commonly used as a separator and recognition of this practice will		commonly used as a separator, and recognition of this practice will
	reduce implementation requirements and operational risk. The		reduce implementation requirements and operational risk. The
	remaining characters were excluded because they are not broadly used		remaining characters were excluded because they are not broadly used
	as separators in entity handles.		as separators in entity handles.
	3. Bootstrap Service Registry for Provider Object Tags		3. Bootstrap Service Registry for Provider Object Tags
	The bootstrap service registry for the RDAP service provider space is		The bootstrap service registry for the RDAP service provider space is
	represented using the structure specified in Section 3 of RFC 7484		represented using the structure specified in Section 3 of RFC 7484
	[RFC7484]. The JSON output of this registry contains contact		[RFC7484]. The JSON output of this registry contains contact
	information for the registered service provider identifiers,		information for the registered service provider identifiers,
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 20 ¶
	Registration requests include an email address to be associated with		Registration requests include an email address to be associated with
	the registered service provider identifier, the requested service		the registered service provider identifier, the requested service
	provider identifier (or an indication that IANA should assign an		provider identifier (or an indication that IANA should assign an
	identifier), and one or more base RDAP URLs to be associated with the		identifier), and one or more base RDAP URLs to be associated with the
	service provider identifier.		service provider identifier.
	4. RDAP Conformance		4. RDAP Conformance
	RDAP responses that contain values described in this document MUST		RDAP responses that contain values described in this document MUST
	indicate conformance with this specification by including an		indicate conformance with this specification by including an
	rdapConformance ([RFC7483]) value of "rdap_objectTag_level_0". The		rdapConformance [RFC7483] value of "rdap_objectTag_level_0". The
	information needed to register this value in the RDAP Extensions		information needed to register this value in the "RDAP Extensions"
	Registry is described in Section 5.2.		registry is described in Section 5.2.
	Example rdapConformance structure with extension specified:		The following is an example rdapConformance structure with the
			extension specified.
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0",		"rdap_level_0",
	"rdap_objectTag_level_0"		"rdap_objectTag_level_0"
	]		]
	Figure 4		Figure 4
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to create the RDAP "Bootstrap Service Registry for		IANA has created the RDAP "Bootstrap Service Registry for Provider
	Provider Object Tags" listed below and make it available as JSON		Object Tags" listed below and made it available as a JSON object.
	objects. The contents of this registry is described in Section 3,		The contents of this registry are described in Section 3; the formal
	with the formal syntax specified in Section 10 of RFC 7484 [RFC7484].		syntax is specified in Section 10 of RFC 7484 [RFC7484].
	5.1. Bootstrap Service Registry Structure		5.1. Bootstrap Service Registry Structure
	Entries in this registry contain the following information:		Entries in this registry contain the following information:
	o An email address that identifies a contact associated with the		o an email address that identifies a contact associated with the
	registered RDAP service provider value.		registered RDAP service provider value.
	o An alphanumeric value that identifies the RDAP service provider		o an alphanumeric value that identifies the RDAP service provider
	being registered.		being registered.
	o One or more URLs that provide the RDAP service regarding this		o one or more URLs that provide the RDAP service regarding this
	registration. The URLS are expected to supply the same data, but		registration. The URLs are expected to supply the same data, but
	they can differ in scheme or other components as required by the		they can differ in scheme or other components as required by the
	service operator.		service operator.
	5.2. RDAP Extensions Registry		5.2. RDAP Extensions Registry
	IANA is requested to register the following value in the RDAP		IANA has registered the following value in the "RDAP Extensions"
	Extensions Registry:		registry:
	Extension identifier: rdap_objectTag		Extension identifier: rdap_objectTag
	Registry operator: Any		Registry operator: Any
	Published specification: This document.		Published specification: This document
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Intended usage: This extension describes a best practice for		Intended usage: This extension describes a best practice for
	structuring entity identifiers to enable query bootstrapping.		structuring entity identifiers to enable query bootstrapping.
	6. Implementation Status		6. Security Considerations
	NOTE: Please remove this section and the reference to RFC 7942 prior
	to publication as an RFC.
	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in RFC 7942
	[RFC7942]. The description of implementations in this section is
	intended to assist the IETF in its decision processes in progressing
	drafts to RFCs. Please note that the listing of any individual
	implementation here does not imply endorsement by the IETF.
	Furthermore, no effort has been spent to verify the information
	presented here that was supplied by IETF contributors. This is not
	intended as, and must not be construed to be, a catalog of available
	implementations or their features. Readers are advised to note that
	other implementations may exist.
	According to RFC 7942, "this will allow reviewers and working groups
	to assign due consideration to documents that have the benefit of
	running code, which may serve as evidence of valuable experimentation
	and feedback that have made the implemented protocols more mature.
	It is up to the individual working groups to use this information as
	they see fit".
	6.1. Verisign Labs
	Responsible Organization: Verisign Labs
	Location: https://rdap.verisignlabs.com/
	Description: This implementation includes support for domain
	registry RDAP queries using live data from the .cc and .tv country
	code top-level domains. Client authentication is required to
	receive entity information in query responses.
	Level of Maturity: This is a "proof of concept" research
	implementation.
	Coverage: This implementation includes all of the features
	described in this specification.
	Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
	6.2. OpenRDAP
	Responsible Organization: OpenRDAP
	Location: https://www.openrdap.org
	Description: RDAP client implementing bootstrapping for entity
	handles with a service provider tag. A test Bootstrap Services
	Registry file is currently used in lieu of an official one.
	Level of Maturity: Alpha
	Coverage: Implements draft 04+, supports the HYPHEN-MINUS
	separator character only.
	Contact Information: Tom Harwood, tfh@skip.org
	7. Security Considerations
	This practice uses IANA as a well-known, central trusted authority to
	allow users to get RDAP data from an authoritative source, reducing
	the risk of sending queries to non-authoritative sources and
	divulging query information to unintended parties. Using TLS
	[RFC5246] to protect the connection to IANA allows the server to
	authenticate itself as being operated by IANA and provides integrity
	protection for the resulting referral information, as well as
	providing privacy protection via data confidentiality. The
	subsequent RDAP connection is performed as usual, and retains the
	same security properties of the RDAP protocols themselves.
	8. Acknowledgements
	The author would like to acknowledge the following individuals for		This practice uses IANA as a well-known, centrally trusted authority
	their contributions to the development of this document: Tom		to allow users to get RDAP data from an authoritative source, which
	Harrison, Patrick Mevzek, and Marcos Sanz. In addition, the authors		reduces the risk of sending queries to non-authoritative sources and
	would like to recognize the Regional Internet Registry (RIR)		divulging query information to unintended parties. Using TLS 1.2
	operators (AFRINIC, APNIC, ARIN, LACNIC, and RIPE) that have been		[RFC5246] or TLS 1.3 [RFC8446], which obsoletes TLS 1.2, to protect
	implementing and using the practice of tagging handle identifiers for		the connection to IANA allows the server to authenticate itself as
	several years. Their experience provided significant inspiration for		being operated by IANA and provides integrity protection for the
	the development of this document.		resulting referral information, as well as provides privacy
			protection via data confidentiality. The subsequent RDAP connection
			is performed as usual and retains the same security properties of the
			RDAP protocols themselves as described in RFC 7481 [RFC7481].
	9. References		7. References
	9.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",		[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
	STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,		STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
	<https://www.rfc-editor.org/info/rfc5730>.		<https://www.rfc-editor.org/info/rfc5730>.
	skipping to change at page 13, line 14 ¶		skipping to change at page 12, line 31 ¶
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		7.2. Informative References
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	skipping to change at page 13, line 41 ¶		skipping to change at page 13, line 10 ¶
	[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access		[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
	Protocol (RDAP) Query Format", RFC 7482,		Protocol (RDAP) Query Format", RFC 7482,
	DOI 10.17487/RFC7482, March 2015,		DOI 10.17487/RFC7482, March 2015,
	<https://www.rfc-editor.org/info/rfc7482>.		<https://www.rfc-editor.org/info/rfc7482>.
	[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the		[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
	Registration Data Access Protocol (RDAP)", RFC 7483,		Registration Data Access Protocol (RDAP)", RFC 7483,
	DOI 10.17487/RFC7483, March 2015,		DOI 10.17487/RFC7483, March 2015,
	<https://www.rfc-editor.org/info/rfc7483>.		<https://www.rfc-editor.org/info/rfc7483>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Code: The Implementation Status Section", BCP 205,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		<https://www.rfc-editor.org/info/rfc8446>.
	<https://www.rfc-editor.org/info/rfc7942>.
	Appendix A. Change Log		Acknowledgements
	00: Initial version.		The authors would like to acknowledge the following individuals for
	01: Changed separator character from HYPHEN MINUS to COMMERCIAL AT.		their contributions to the development of this document: Tom
	Added a recommendation to maintain consistency between service		Harrison, Patrick Mevzek, and Marcos Sanz. In addition, the authors
	provider tags and "self" links (suggestion received from Tom		would like to recognize the Regional Internet Registry (RIR)
	Harrison). Fixed a spelling error, and corrected the network		operators (AFRINIC, APNIC, ARIN, LACNIC, and RIPE) that have been
	example in Section 2 (editorial erratum reported for RFC 7483 by		implementing and using the practice of tagging handle identifiers for
	Marcos Sanz). Added acknowledgements.		several years. Their experience provided significant inspiration for
	02: Changed separator character from COMMERCIAL AT to TILDE.		the development of this document.
	Clarity updates and fixed an example handle. Added text to
	describe the risk of separator characters appearing naturally in
	entity handles and being misinterpreted as separator characters.
	03: Added Implementation Status section (Section 6).
	04: Keepalive refresh.
	05: Added OpenRDAP implementation information to Section 6.
	00: Initial working group version.
	01: Added text to describe why the TILDE character was chosen as the
	separator character.
	02: Nit fixes. Added rdapConformance text, switched back to HYPHEN
	MINUS, and added IANA registration instructions per working group
	last call discussion. Updated suffix syntax reference from the
	IANA EPP ROID registry to RFC 5730 (which is what the IANA
	registry references).
	03: Shepherd writeup review updates to explain examples in
	Section 2.
	04: AD review update to clarify query path construction.
	05: IESG review update: object naming practice, revised an example
	to include multiple separator HYPHEN-MINUS characters, revised
	security considerations, revised IANA considerations, revised IANA
	registry description and registration procedure to add email
	address contact information.
	Authors' Addresses		Authors' Addresses
	Scott Hollenbeck		Scott Hollenbeck
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	USA		United States of America
	Email: shollenbeck@verisign.com		Email: shollenbeck@verisign.com
	URI: http://www.verisignlabs.com/		URI: http://www.verisignlabs.com/
	Andrew Lee Newton		Andrew Lee Newton
	American Registry for Internet Numbers		American Registry for Internet Numbers
	PO Box 232290		PO Box 232290
	Centreville, VA 20120		Centreville, VA 20120
	US		United States of America
	Email: andy@arin.net		Email: andy@arin.net
	URI: http://www.arin.net		URI: http://www.arin.net
End of changes. 37 change blocks.
	179 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/