rfc7483.txt		draft-ietf-regext-rfc7483bis-05.original
	Internet Engineering Task Force (IETF) A. Newton		REGEXT Working Group S. Hollenbeck
	Request for Comments: 7483 ARIN		Internet-Draft Verisign Labs
	Category: Standards Track S. Hollenbeck		Obsoletes: 7483 (if approved) A. Newton
	ISSN: 2070-1721 Verisign Labs		Intended status: Standards Track AWS
	March 2015		Expires: 28 August 2021 24 February 2021
	JSON Responses for the Registration Data Access Protocol (RDAP)		JSON Responses for the Registration Data Access Protocol (RDAP)
			draft-ietf-regext-rfc7483bis-05
	Abstract		Abstract
	This document describes JSON data structures representing		This document describes JSON data structures representing
	registration information maintained by Regional Internet Registries		registration information maintained by Regional Internet Registries
	(RIRs) and Domain Name Registries (DNRs). These data structures are		(RIRs) and Domain Name Registries (DNRs). These data structures are
	used to form Registration Data Access Protocol (RDAP) query		used to form Registration Data Access Protocol (RDAP) query
	responses.		responses. If approved, this document obsoletes RFC 7483.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This Internet-Draft is submitted in full conformance with the
			provisions of BCP 78 and BCP 79.
	This document is a product of the Internet Engineering Task Force		Internet-Drafts are working documents of the Internet Engineering
	(IETF). It represents the consensus of the IETF community. It has		Task Force (IETF). Note that other groups may also distribute
	received public review and has been approved for publication by the		working documents as Internet-Drafts. The list of current Internet-
	Internet Engineering Steering Group (IESG). Further information on		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet Standards is available in Section 2 of RFC 5741.
	Information about the current status of this document, any errata,		Internet-Drafts are draft documents valid for a maximum of six months
	and how to provide feedback on it may be obtained at		and may be updated, replaced, or obsoleted by other documents at any
	http://www.rfc-editor.org/info/rfc7483.		time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			This Internet-Draft will expire on 28 August 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2021 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/
	(http://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3		1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3
	1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 7		3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 7
	4. Common Data Structures . . . . . . . . . . . . . . . . . . . 8		4. Common Data Structures . . . . . . . . . . . . . . . . . . . 8
	4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8		4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8
	4.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Notices and Remarks . . . . . . . . . . . . . . . . . . . 10		4.3. Notices and Remarks . . . . . . . . . . . . . . . . . . . 10
	4.4. Language Identifier . . . . . . . . . . . . . . . . . . . 11		4.4. Language Identifier . . . . . . . . . . . . . . . . . . . 12
	4.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.7. Port 43 WHOIS Server . . . . . . . . . . . . . . . . . . 13		4.7. Port 43 WHOIS Server . . . . . . . . . . . . . . . . . . 14
	4.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13		4.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 14
	4.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 14		4.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 14
	4.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14		4.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 15		5. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. The Entity Object Class . . . . . . . . . . . . . . . . . 16		5.1. The Entity Object Class . . . . . . . . . . . . . . . . . 17
	5.2. The Nameserver Object Class . . . . . . . . . . . . . . . 22		5.2. The Nameserver Object Class . . . . . . . . . . . . . . . 23
	5.3. The Domain Object Class . . . . . . . . . . . . . . . . . 26		5.3. The Domain Object Class . . . . . . . . . . . . . . . . . 26
	5.4. The IP Network Object Class . . . . . . . . . . . . . . . 38		5.4. The IP Network Object Class . . . . . . . . . . . . . . . 39
	5.5. Autonomous System Number Entity Object Class . . . . . . 42		5.5. The Autonomous System Number Object Class . . . . . . . . 43
	6. Error Response Body . . . . . . . . . . . . . . . . . . . . . 45		6. Error Response Body . . . . . . . . . . . . . . . . . . . . . 46
	7. Responding to Help Queries . . . . . . . . . . . . . . . . . 48		7. Responding to Help Queries . . . . . . . . . . . . . . . . . 48
	8. Responding To Searches . . . . . . . . . . . . . . . . . . . 48		8. Responding To Searches . . . . . . . . . . . . . . . . . . . 48
	9. Indicating Truncated Responses . . . . . . . . . . . . . . . 49		9. Indicating Truncated Responses . . . . . . . . . . . . . . . 49
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 52		10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 52
	10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 53		10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 53
	10.2.1. Notice and Remark Types . . . . . . . . . . . . . . 54		10.2.1. Notice and Remark Types . . . . . . . . . . . . . . 54
	10.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 56		10.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 56
	10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 49		10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 60
	10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 61		10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 62
	10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 63		10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 65
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 64		11. Implementation Status . . . . . . . . . . . . . . . . . . . . 66
	12. Internationalization Considerations . . . . . . . . . . . . . 64		11.1. RedDog . . . . . . . . . . . . . . . . . . . . . . . . . 67
	12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 64		11.2. Verisign . . . . . . . . . . . . . . . . . . . . . . . . 67
	12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 64		11.3. Verisign Labs . . . . . . . . . . . . . . . . . . . . . 68
	12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 64		11.4. Asia-Pacific Network Information Centre (APNIC) . . . . 68
	12.4. Internationalized Domain Names . . . . . . . . . . . . . 65		12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
	13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 65		13. Internationalization Considerations . . . . . . . . . . . . . 69
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65		13.1. Character Encoding . . . . . . . . . . . . . . . . . . . 69
	14.1. Normative References . . . . . . . . . . . . . . . . . . 65		13.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 69
	14.2. Informative References . . . . . . . . . . . . . . . . . 67		13.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 69
			13.4. Internationalized Domain Names . . . . . . . . . . . . . 69
	Appendix A. Suggested Data Modeling with the Entity Object Class 68		14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 70
	A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 68		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
	A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 70		15.1. Normative References . . . . . . . . . . . . . . . . . . 70
	Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 72		15.2. Informative References . . . . . . . . . . . . . . . . . 72
	Appendix C. Structured vs. Unstructured Addresses . . . . . . . 74		Appendix A. Suggested Data Modeling with the Entity Object
	Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 76		Class . . . . . . . . . . . . . . . . . . . . . . . . . . 73
	Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 77		A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 73
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 77		A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78		Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 77
			Appendix C. Structured vs. Unstructured Addresses . . . . . . . 79
			Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 82
			Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 82
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 83
			Changes from RFC 7483 . . . . . . . . . . . . . . . . . . . . . . 83
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
	1. Introduction		1. Introduction
	This document describes responses in the JSON [RFC7159] format for		This document describes responses in the JSON [RFC8259] format for
	the queries as defined by the Registration Data Access Protocol Query		the queries as defined by the Registration Data Access Protocol Query
	Format [RFC7482]. A communication protocol for exchanging queries		Format [I-D.ietf-regext-rfc7482bis]. A communication protocol for
	and responses is described in [RFC7480].		exchanging queries and responses is described in [RFC7480]. If
			approved, this document obsoletes RFC 7483.
	1.1. Terminology and Definitions		1.1. Terminology and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119] when		"OPTIONAL" in this document are to be interpreted as described in BCP
	specified in their uppercase forms.		14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	The following list describes terminology and definitions used		The following list describes terminology and definitions used
	throughout this document:		throughout this document:
	DNR: Domain Name Registry		DNR: Domain Name Registry or Domain Name Registrar
	LDH: letters, digits, hyphen		LDH: letters, digits, hyphen
	member: data found within an object as defined by JSON		member: data found within an object as defined by JSON [RFC8259]
	[RFC7159].
	object: a data structure as defined by JSON [RFC7159].		object: a data structure as defined by JSON [RFC8259]
	object class: the definition of members that may be found in JSON		object class: the definition of members that may be found in JSON
	objects described in this document.		objects described in this document
	object instance: an instantiation or specific instance of an object		object instance: an instantiation or specific instance of an object
	class.		class
	RDAP: Registration Data Access Protocol		RDAP: Registration Data Access Protocol
	RIR: Regional Internet Registry		RIR: Regional Internet Registry
	1.2. Data Model		1.2. Data Model
	The data model for JSON responses is specified in five sections:		The data model for JSON responses is specified in five sections:
	1. simple data types conveyed in JSON strings		1. simple data types conveyed in JSON primitive types (strings,
			numbers, booleans, and null)
	2. data structures specified as JSON arrays or objects that are used		2. data structures specified as JSON arrays or objects that are used
	repeatedly when building up larger objects		repeatedly when building up larger objects
	3. object classes representing structured data corresponding to a		3. object classes representing structured data corresponding to a
	lookup of a single object		lookup of a single object
	4. arrays of objects representing structured data corresponding to a		4. arrays of objects representing structured data corresponding to a
	search for multiple objects		search for multiple objects
	skipping to change at page 5, line 50 ¶		skipping to change at page 6, line 19 ¶
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	]		]
	}		}
	Figure 1		Figure 1
	If The Registry of the Moon desires to express information not found		If The Registry of the Moon desires to express information not found
	in this specification, it might select "lunarNic" as its identifying		in this specification, it might select "lunarNIC" as its identifying
	prefix and insert, as an example, the member named		prefix and insert, as an example, the member named
	"lunarNic_beforeOneSmallStep" to signify registrations occurring		"lunarNIC_beforeOneSmallStep" to signify registrations occurring
	before the first moon landing and the member named		before the first moon landing and the member named
	"lunarNic_harshMistressNotes" that contains other descriptive text.		"lunarNIC_harshMistressNotes" that contains other descriptive text.
	Consider the following JSON response with JSON names, some of which		Consider the following JSON response with JSON names, some of which
	should be ignored by clients without knowledge of their meaning.		should be ignored by clients without knowledge of their meaning.
	{		{
	"handle" : "ABC123",		"handle" : "ABC123",
	"lunarNic_beforeOneSmallStep" : "TRUE THAT!",		"lunarNIC_beforeOneSmallStep" : "TRUE THAT!",
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"lunarNic_harshMistressNotes" :		"lunarNIC_harshMistressNotes" :
	[		[
	"In space,",		"In space,",
	"nobody can hear you scream."		"nobody can hear you scream."
	]		]
	}		}
	Figure 2		Figure 2
	Insertion of unrecognized members ignored by clients may also be used		Insertion of unrecognized members ignored by clients may also be used
	for future revisions to this specification.		for future revisions to this specification.
	Clients processing JSON responses need to be prepared for members		Clients processing JSON responses need to be prepared for members
	representing registration data specified in this document to be		representing registration data specified in this document to be
	absent from a response. In other words, servers are free to not		absent from a response. In other words, servers are free to omit
	include JSON members containing registration data based on their own		unrequired/optional JSON members containing registration data based
	policies.		on their own policies.
	Finally, all JSON names specified in this document are case		Finally, all JSON names specified in this document are case
	sensitive. Both servers and clients MUST transmit and process them		sensitive. Both servers and clients MUST transmit and process them
	using the specified character case.		using the specified character case.
	3. Common Data Types		3. Common Data Types
	JSON [RFC7159] defines the data types of a number, character string,		JSON [RFC8259] defines the data types of a number, character string,
	boolean, array, object, and null. This section describes the		boolean, array, object, and null. This section describes the
	semantics and/or syntax reference for common, JSON character strings		semantics and/or syntax reference for common, JSON character strings
	used in this document.		used in this document.
	handle: DNRs and RIRs have registry-unique identifiers that		handle: DNRs and RIRs have registry-unique identifiers that
	may be used to specifically reference an object		may be used to specifically reference an object
	instance. The semantics of this data type as found		instance. The semantics of this data type as found
	in this document are to be a registry-unique		in this document are to be a registry-unique
	reference to the closest enclosing object where the		reference to the closest enclosing object where the
	value is found. The data type names "registryId",		value is found. The data type names "registryId",
	"roid", "nic-handle", "registrationNo", etc., are		"roid", "nic-handle", "registrationNo", etc., are
	terms often synonymous with this data type. In		terms often synonymous with this data type. In
	this document, the term "handle" is used. The term		this document, the term "handle" is used. The term
	exposed to users by clients is a presentation issue		exposed to users by clients is a presentation issue
	beyond the scope of this document.		beyond the scope of this document. This value is a
			simple character string.
	IPv4 addresses: The representation of IPv4 addresses in this		IPv4 addresses: The representation of IPv4 addresses in this
	document uses the dotted-decimal notation. An		document uses the dotted-decimal notation. An
	example of this textual representation is		example of this textual representation is
	"192.0.2.0".		"192.0.2.0".
	IPv6 addresses: The representation of IPv6 addresses in this		IPv6 addresses: The representation of IPv6 addresses in this
	document follow the forms outlined in [RFC5952].		document follow the forms outlined in [RFC5952].
	An example of this textual representation is		An example of this textual representation is
	"2001:db8::1:0:0:1".		"2001:db8::1:0:0:1".
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 27 ¶
	more of the labels are U-labels as described by		more of the labels are U-labels as described by
	[RFC5890]. Trailing periods are optional.		[RFC5890]. Trailing periods are optional.
	dates and times: The syntax for values denoting dates and times is		dates and times: The syntax for values denoting dates and times is
	defined in [RFC3339].		defined in [RFC3339].
	URIs: The syntax for values denoting a Uniform Resource		URIs: The syntax for values denoting a Uniform Resource
	Identifier (URI) is defined by [RFC3986].		Identifier (URI) is defined by [RFC3986].
	Contact information is defined using jCards as described in		Contact information is defined using jCards as described in
	[RFC7095].		[RFC7095]. The "fn" member is required and MUST NOT be null
			according to [RFC6350]. An empty "fn" member MAY be used when the
			contact name does not exist or is redacted.
	4. Common Data Structures		4. Common Data Structures
	This section defines common data structures used in responses and		This section defines common data structures used in responses and
	object classes.		object classes.
	4.1. RDAP Conformance		4.1. RDAP Conformance
	The data structure named "rdapConformance" is an array of strings,		The data structure named "rdapConformance" is an array of strings,
	each providing a hint as to the specifications used in the		each providing a hint as to the specifications used in the
	construction of the response. This data structure appears only in		construction of the response. This data structure MUST appear in the
	the topmost JSON object of a response.		topmost JSON object of a response and MUST NOT appear anywhere else.
			A response to a "help" request will include identifiers for all of
			the specifications supported by the server. A response to any other
			request will include only identifiers for the specifications used in
			the construction of the response. The set of returned identifiers
			MAY vary depending on the authorization level of the client.
	An example rdapConformance data structure:		An example rdapConformance data structure:
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0"		"rdap_level_0"
	]		]
	Figure 3		Figure 3
	The string literal "rdap_level_0" signifies conformance with this		The string literal "rdap_level_0" signifies conformance with this
	specification. When custom JSON values are inserted into responses,		specification. When custom JSON values are inserted into responses,
	conformance to those custom specifications MUST use a string prefixed		conformance to those custom specifications MUST be indicated by
	with the appropriate identifier from the IANA RDAP Extensions		including a unique string literal value registered in the IANA RDAP
	registry specified in [RFC7480]. For example, if the fictional		Extensions registry specified in [RFC7480]. For example, if the
	Registry of the Moon wants to signify that their JSON responses are		fictional Registry of the Moon wants to signify that their JSON
	conformant with their registered extensions, the string used might be		responses are conformant with their registered extensions, the string
	"lunarNIC_level_0". These prefixes aid the identification of		used might be "lunarNIC_level_0". These registered values aid the
	specifications for software implementers, and failure to use them		identification of specifications for software implementers, and
	could result in slower adoption of extensions.		failure to use them could result in slower adoption of extensions.
	Example rdapConformance structure with custom extensions noted:		Example rdapConformance structure with custom extensions noted:
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0",		"rdap_level_0",
	"lunarNic_level_0"		"lunarNIC_level_0"
	]		]
	Figure 4		Figure 4
	4.2. Links		4.2. Links
	The "links" array is found in data structures to signify links to		The "links" array is found in data structures to signify links to
	other resources on the Internet. The relationship of these links is		other resources on the Internet. The relationship of these links is
	defined by the IANA registry described by [RFC5988].		defined by the IANA registry described by [RFC8288].
	The following is an example of the link structure:		The following is an example of the link structure:
	{		{
	"value" : "http://example.com/context_uri",		"value" : "https://example.com/context_uri",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.com/target_uri",		"href" : "https://example.com/target_uri",
	"hreflang" : [ "en", "ch" ],		"hreflang" : [ "en", "ch" ],
	"title" : "title",		"title" : "title",
	"media" : "screen",		"media" : "screen",
	"type" : "application/json"		"type" : "application/json"
	}		}
	Figure 5		Figure 5
	The JSON name/values of "rel", "href", "hreflang", "title", "media",		The JSON name/values of "rel", "href", "hreflang", "title", "media",
	and "type" correspond to values found in Section 5 of [RFC5988]. The		and "type" correspond to values found in Section 3 of [RFC8288]. The
	"value" JSON value is the context URI as described by [RFC5988]. The		"value" JSON value is the context URI as described by [RFC8288]. The
	"href" JSON value MUST be specified. All other JSON values are		"value", "rel" and "href" JSON values MUST be specified. All other
	OPTIONAL.		JSON values are OPTIONAL. A "related" link relation MUST NOT include
			an "href" URI that is the same as the "self" link relation "href" URI
			to reduce the risk of infinite client processing loops.
			Internationalized Domain Names (IDNs) returned in URIs SHOULD be
			consistently returned in LDH name format to allow clients to process
			these IDNs according to their capabilities.
	This is an example of the "links" array as it might be found in an		This is an example of the "links" array as it might be found in an
	object class:		object class:
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.com/ip/2001:db8::123",		"value" : "https://example.com/ip/2001:db8::123",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.com/ip/2001:db8::123",		"href" : "https://example.com/ip/2001:db8::123",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	},		},
	{		{
	"value" : "http://example.com/ip/2001:db8::123",		"value" : "https://example.com/ip/2001:db8::123",
	"rel" : "up",		"rel" : "up",
	"href" : "http://example.com/ip/2001:db8::/48",		"href" : "https://example.com/ip/2001:db8::/48",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	]		]
	Figure 6		Figure 6
	4.3. Notices and Remarks		4.3. Notices and Remarks
	The "notices" and "remarks" data structures take the same form. The		The "notices" and "remarks" data structures take the same form. The
	notices structure denotes information about the service providing		notices structure denotes information about the service providing
	RDAP information and/or information about the entire response,		RDAP information and/or information about the entire response,
	whereas the remarks structure denotes information about the object		whereas the remarks structure denotes information about the object
	class that contains it (see Section 5 regarding object classes).		class that contains it (see Section 5 regarding object classes).
	Both are arrays of objects. Each object contains an optional "title"		Both are arrays of objects. Each object contains a "title" string
	string representing the title of the object, an optional "type"		representing the title of the object, a "type" string denoting a
	string denoting a registered type of remark or notice (see		registered type of remark or notice (see Section 10.2.1), an array of
	Section 10.2.1), an array of strings named "description" for the		strings named "description" for the purposes of conveying any
	purposes of conveying any descriptive text, and an optional "links"		descriptive text, and a "links" array as described in Section 4.2.
	array as described in Section 4.2.		The "description" array MUST be included. All other JSON values are
			OPTIONAL.
	An example of the notices data structure:		An example of the notices data structure:
	"notices" :		"notices" :
	[		[
	{		{
	"title" : "Terms of Use",		"title" : "Terms of Use",
	"description" :		"description" :
	[		[
	"Service subject to The Registry of the Moon's TOS.",		"Service subject to The Registry of the Moon's TOS.",
	"Copyright (c) 2020 LunarNIC"		"Copyright (c) 2020 LunarNIC"
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/entity/XXXX",		"value" : "https://example.net/entity/XXXX",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/terms_of_use.html"		"href" : "https://www.example.com/terms_of_use.html"
	}		}
	]		]
	}		}
	]		]
	Figure 7		Figure 7
	It is the job of the clients to determine line breaks, spacing, and		It is the job of the clients to determine line breaks, spacing, and
	display issues for sentences within the character strings of the		display issues for sentences within the character strings of the
	"description" array. Each string in the "description" array contains		"description" array. Each string in the "description" array contains
	a single complete division of human-readable text indicating to		a single complete division of human-readable text indicating to
	clients where there are semantic breaks.		clients where there are semantic breaks.
	An example of the remarks data structure:		An example of the remarks data structure:
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	]		]
	Figure 8		Figure 8
	Note that objects in the "remarks" array may also have a "links"		Note that objects in the "remarks" array may also have a "links"
	array.		array.
	While the "title" and "description" fields are intended primarily for		While the "title" and "description" fields are intended primarily for
	human consumption, the "type" string contains a well-known value to		human consumption, the "type" string contains a well-known value to
	be registered with IANA (see Section 10.2.1) for programmatic use.		be registered with IANA (see Section 10.2.1) for programmatic use.
	An example of the remarks data structure:		An example of the remarks data structure:
	skipping to change at page 11, line 41 ¶		skipping to change at page 12, line 23 ¶
	{		{
	"type" : "object truncated due to authorization",		"type" : "object truncated due to authorization",
	"description" :		"description" :
	[		[
	"Some registration data may not have been given.",		"Some registration data may not have been given.",
	"Use proper authorization credentials to see all of it."		"Use proper authorization credentials to see all of it."
	]		]
	}		}
	]		]
	Figure 9		Figure 9
	While the "remarks" array will appear in many object classes in a		While the "remarks" array will appear in many object classes in a
	response, the "notices" array appears only in the topmost object of a		response, the "notices" array appears only in the topmost object of a
	response.		response.
	4.4. Language Identifier		4.4. Language Identifier
	This data structure consists solely of a name/value pair, where the		This data structure consists solely of a name/value pair, where the
	name is "lang" and the value is a string containing a language		name is "lang" and the value is a string containing a language
	identifier as described in [RFC5646].		identifier as described in [RFC5646].
	"lang" : "mn-Cyrl-MN"		"lang" : "mn-Cyrl-MN"
	Figure 10		Figure 10
	The "lang" attribute may appear anywhere in an object class or data		The "lang" attribute as defined in this section MAY appear anywhere
	structure except for in jCard objects.		in an object class or data structure, except for in jCard objects.
			vCard supports similar functionality by way of the LANGUAGE property
			parameter (see Section 5.1 of RFC 6350 [RFC6350]).
	4.5. Events		4.5. Events
	This data structure represents events that have occurred on an		This data structure represents events that have occurred on an
	instance of an object class (see Section 5 regarding object classes).		instance of an object class (see Section 5 regarding object classes).
	This is an example of an "events" array.		This is an example of an "events" array.
	"events" :		"events" :
	[		[
	skipping to change at page 12, line 44 ¶		skipping to change at page 13, line 24 ¶
	"eventActor" : "OTHERID-LUNARNIC",		"eventActor" : "OTHERID-LUNARNIC",
	"eventDate" : "1991-12-31T23:59:59Z"		"eventDate" : "1991-12-31T23:59:59Z"
	}		}
	]		]
	Figure 11		Figure 11
	The "events" array consists of objects, each with the following		The "events" array consists of objects, each with the following
	members:		members:
	o "eventAction" -- a string denoting the reason for the event		* "eventAction" -- a REQUIRED string denoting the reason for the
			event
	o "eventActor" -- an optional identifier denoting the actor		* "eventActor" -- an OPTIONAL identifier denoting the actor
	responsible for the event		responsible for the event
	o "eventDate" -- a string containing the time and date the event		* "eventDate" -- a REQUIRED string containing the time and date the
	occurred.		event occurred
			* "links" -- OPTIONAL; see Section 4.2
	o "links" -- see Section 4.2
	Events can be future dated. One use case for future dating of events		Events can be future dated. One use case for future dating of events
	is to denote when an object expires from a registry.		is to denote when an object expires from a registry.
	The "links" array in this data structure is provided for references		The "links" array in this data structure is provided for references
	to the event actor. In order to reference an RDAP entity, a "rel" of		to the event actor. In order to reference an RDAP entity, a "rel" of
	"related" and a "type" of "application/rdap+json" is used in the link		"related" and a "type" of "application/rdap+json" is used in the link
	reference.		reference.
	See Section 10.2.3 for a list of values for the "eventAction" string.		See Section 10.2.3 for a list of values for the "eventAction" string.
	See Appendix B regarding the various ways events can be modeled.		See Appendix B regarding the various ways events can be modeled.
	4.6. Status		4.6. Status
	This data structure, named "status", is an array of strings		This data structure, named "status", is an array of strings
	indicating the state of a registered object (see Section 10.2.2 for a		indicating the state of a registered object (see Section 10.2.2 for a
	list of values).		list of values).
	4.7. Port 43 WHOIS Server		4.7. Port 43 WHOIS Server
	This data structure, a member named "port43", is a simple string		This data structure, a member named "port43", is a simple character
	containing the fully qualified host name or IP address of the WHOIS		string containing the fully qualified host name or IP address of the
	[RFC3912] server where the containing object instance may be found.		WHOIS [RFC3912] server where the containing object instance may be
	Note that this is not a URI, as there is no WHOIS URI scheme.		found. Note that this is not a URI, as there is no WHOIS URI scheme.
	4.8. Public IDs		4.8. Public IDs
	This data structure maps a public identifier to an object class. It		This data structure maps a public identifier to an object class. It
	is named "publicIds" and is an array of objects, with each object		is named "publicIds" and is an array of objects, with each object
	containing the following members:		containing the following REQUIRED members:
	o type -- a string denoting the type of public identifier		* type -- a string denoting the type of public identifier
	o identifier -- a public identifier of the type denoted by "type"		* identifier -- a string denoting a public identifier of the type
			related to "type"
	The following is an example of a publicIds structure.		The following is an example of a publicIds structure.
	"publicIds":		"publicIds":
	[		[
	{		{
	"type":"IANA Registrar ID",		"type":"IANA Registrar ID",
	"identifier":"1"		"identifier":"1"
	}		}
	]		]
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 22 ¶
	{		{
	"title" : "Content Removed",		"title" : "Content Removed",
	"description" :		"description" :
	[		[
	"Without full authorization, content has been removed.",		"Without full authorization, content has been removed.",
	"Sorry, dude!"		"Sorry, dude!"
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/ip/192.0.2.0/24",		"value" : "https://example.net/ip/192.0.2.0/24",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/redaction_policy.html"		"href" : "https://www.example.com/redaction_policy.html"
	}		}
	]		]
	}		}
	],		],
	"lang" : "en",		"lang" : "en",
	"objectClassName" : "ip network",		"objectClassName" : "ip network",
	"startAddress" : "192.0.2.0",		"startAddress" : "192.0.2.0",
	"endAddress" : "192.0.2.255",		"endAddress" : "192.0.2.255",
	"handle" : "XXXX-RIR",		"handle" : "XXXX-RIR",
	"ipVersion" : "v4",		"ipVersion" : "v4",
	skipping to change at page 15, line 19 ¶		skipping to change at page 16, line 8 ¶
	]		]
	}		}
	]		]
	}		}
	Figure 13		Figure 13
	5. Object Classes		5. Object Classes
	Object classes represent structures appropriate for a response from		Object classes represent structures appropriate for a response from
	the queries specified in [RFC7482].		the queries specified in [I-D.ietf-regext-rfc7482bis].
	Each object class contains a "links" array as specified in		Each object class contains a "links" array as specified in
	Section 4.2. For every object class instance in a response, whether		Section 4.2. For every object class instance in a response, whether
	the object class instance is directly representing the response to a		the object class instance is directly representing the response to a
	query or is embedded in other object class instances or is an item in		query or is embedded in other object class instances or is an item in
	a search result set, servers SHOULD provide a link representing a URI		a search result set, servers SHOULD provide a link representing a URI
	for that object class instance using the "self" relationship as		for that object class instance using the "self" relationship as
	described in the IANA registry specified by [RFC5988]. As explained		described in the IANA registry specified by [RFC8288]. As explained
	in Section 5.2, this may be not always be possible for nameserver		in Section 5.2, this may be not always be possible for nameserver
	data. Clients MUST be able to process object instances without a		data. Clients MUST be able to process object instances without a
	self link. When present, clients can use the self link for caching		self link. When present, clients can use the self link for caching
	data. Servers MAY provide more than one self link for any given		data. Servers MAY provide more than one self link for any given
	object instance. Failure to provide any self link by a server may		object instance. Failure to provide any self link by a server may
	result in clients being unable to cache object class instances.		result in clients being unable to cache object class instances.
	Clients using self links for caching SHOULD not cache any object		Clients using self links for caching SHOULD NOT cache any object
	class instances where the authority of the self link is different		class instances where the authority of the self link is different
	than the authority of the server returning the data. Failing to do		than the authority of the server returning the data. Failing to do
	so might result in cache poisoning.		so might result in cache poisoning.
	Self links MUST contain a "type" element containing the "application/		Self links MUST contain a "type" element containing the "application/
	rdap+json" media type when referencing RDAP object instances as		rdap+json" media type when referencing RDAP object instances as
	defined by this document.		defined by this document.
	This is an example of the "links" array with a self link to an object		This is an example of the "links" array with a self link to an object
	class:		class:
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.com/ip/2001:db8::123",		"value" : "https://example.com/ip/2001:db8::123",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.com/ip/2001:db8::123",		"href" : "https://example.com/ip/2001:db8::123",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	]		]
	Figure 14		Figure 14
	5.1. The Entity Object Class		5.1. The Entity Object Class
	The entity object class appears throughout this document and is an		The entity object class appears throughout this document and is an
	appropriate response for the /entity/XXXX query defined in		appropriate response for the /entity/XXXX query defined in
	"Registration Data Access Protocol (RDAP) Query Format" [RFC7482].		"Registration Data Access Protocol (RDAP) Query Format"
	This object class represents the information of organizations,		[I-D.ietf-regext-rfc7482bis]. This object class represents the
	corporations, governments, non-profits, clubs, individual persons,		information of organizations, corporations, governments, non-profits,
	and informal groups of people. All of these representations are so		clubs, individual persons, and informal groups of people. All of
	similar that it is best to represent them in JSON [RFC7159] with one		these representations are so similar that it is best to represent
	construct, the entity object class, to aid in the reuse of code by		them in JSON [RFC8259] with one construct, the entity object class,
	implementers.		to aid in the reuse of code by implementers.
	The entity object class uses jCard [RFC7095] to represent contact		The entity object class uses jCard [RFC7095] to represent contact
	information, such as postal addresses, email addresses, phone numbers		information, such as postal addresses, email addresses, phone numbers
	and names of organizations and individuals. Many of the types of		and names of organizations and individuals. Many of the types of
	information that can be represented with jCard have no use in RDAP,		information that can be represented with jCard have little or no use
	such as birthdays, anniversaries, and gender.		in RDAP, such as birthdays, anniversaries, and gender.
	The entity object is served by both RIRs and DNRs. The following is		The entity object is served by both RIRs and DNRs. The following is
	an example of an entity that might be served by an RIR.		an example of an entity that might be served by an RIR.
	{		{
	"objectClassName" : "entity",		"objectClassName" : "entity",
	"handle":"XXXX",		"handle":"XXXX",
	"vcardArray":[		"vcardArray":[
	"vcard",		"vcard",
	[		[
	skipping to change at page 18, line 14 ¶		skipping to change at page 18, line 47 ¶
	{ "type":"work" },		{ "type":"work" },
	"text",		"text",
	"joe.user@example.com"		"joe.user@example.com"
	],		],
	["geo", {		["geo", {
	"type":"work"		"type":"work"
	}, "uri", "geo:46.772673,-71.282945"],		}, "uri", "geo:46.772673,-71.282945"],
	["key",		["key",
	{ "type":"work" },		{ "type":"work" },
	"uri",		"uri",
	"http://www.example.com/joe.user/joe.asc"		"https://www.example.com/joe.user/joe.asc"
	],		],
	["tz", {},		["tz", {},
	"utc-offset", "-05:00"],		"utc-offset", "-05:00"],
	["url", { "type":"home" },		["url", { "type":"home" },
	"uri", "http://example.org"]		"uri", "https://example.org"]
	]		]
	],		],
	"roles":[ "registrar" ],		"roles":[ "registrar" ],
	"publicIds":[		"publicIds":[
	{		{
	"type":"IANA Registrar ID",		"type":"IANA Registrar ID",
	"identifier":"1"		"identifier":"1"
	}		}
	],		],
	"remarks":[		"remarks":[
	{		{
	"description":[		"description":[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links":[		"links":[
	{		{
	"value":"http://example.com/entity/XXXX",		"value":"https://example.com/entity/XXXX",
	"rel":"self",		"rel":"self",
	"href":"http://example.com/entity/XXXX",		"href":"https://example.com/entity/XXXX",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events":[		"events":[
	{		{
	"eventAction":"registration",		"eventAction":"registration",
	"eventDate":"1990-12-31T23:59:59Z"		"eventDate":"1990-12-31T23:59:59Z"
	}		}
	],		],
	"asEventActor":[		"asEventActor":[
	skipping to change at page 19, line 15 ¶		skipping to change at page 19, line 49 ¶
	"eventAction":"last changed",		"eventAction":"last changed",
	"eventDate":"1991-12-31T23:59:59Z"		"eventDate":"1991-12-31T23:59:59Z"
	}		}
	]		]
	}		}
	Figure 15		Figure 15
	The entity object class can contain the following members:		The entity object class can contain the following members:
	o objectClassName -- the string "entity"		* objectClassName -- the string "entity"
			* handle -- a string representing a registry-unique identifier of
	o handle -- a string representing a registry unique identifier of
	the entity		the entity
	o vcardArray -- a jCard with the entity's contact information		* vcardArray -- a jCard with the entity's contact information
	o roles -- an array of strings, each signifying the relationship an		* roles -- an array of strings, each signifying the relationship an
	object would have with its closest containing object (see		object would have with its closest containing object (see
	Section 10.2.4 for a list of values)		Section 10.2.4 for a list of values)
	o publicIds -- see Section 4.8		* publicIds -- see Section 4.8
	o entities -- an array of entity objects as defined by this section		* entities -- an array of entity objects as defined by this section
	o remarks -- see Section 4.3		* remarks -- see Section 4.3
	o links -- see Section 4.2		* links -- see Section 4.2
	o events -- see Section 4.5		* events -- see Section 4.5
	o asEventActor -- this data structure takes the same form as the		* asEventActor -- this data structure takes the same form as the
	events data structure (see Section 4.5), but each object in the		events data structure (see Section 4.5), but each object in the
	array MUST NOT have an "eventActor" member. These objects denote		array MUST NOT have an "eventActor" member. These objects denote
	that the entity is an event actor for the given events. See		that the entity is an event actor for the given events. See
	Appendix B regarding the various ways events can be modeled.		Appendix B regarding the various ways events can be modeled.
	o status -- see Section 4.6		* status -- see Section 4.6
	o port43 -- see Section 4.7		* port43 -- see Section 4.7
	o networks -- an array of IP network objects as defined in		* networks -- an array of IP network objects as defined in
	Section 5.4		Section 5.4
	o autnums -- an array of autnum objects as defined in Section 5.5		* autnums -- an array of autnum objects as defined in Section 5.5
	Entities may also have other entities embedded with them in an array.		Entities may also have other entities embedded with them in an array.
	This can be used to model an organization with specific individuals		This can be used to model an organization with specific individuals
	fulfilling designated roles of responsibility.		fulfilling designated roles of responsibility.
	The following is an elided example of an entity with embedded		The following is an elided example of an entity with embedded
	entities.		entities.
	{		{
	"objectClassName" : "entity",		"objectClassName" : "entity",
	"handle" : "ANENTITY",		"handle" : "ANENTITY",
	skipping to change at page 21, line 41 ¶		skipping to change at page 22, line 33 ¶
	"remarks":[		"remarks":[
	{		{
	"description":[		"description":[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links":[		"links":[
	{		{
	"value":"http://example.com/entity/XXXX",		"value":"https://example.com/entity/XXXX",
	"rel":"self",		"rel":"self",
	"href":"http://example.com/entity/XXXX",		"href":"https://example.com/entity/XXXX",
	"type":"application/rdap+json"		"type":"application/rdap+json"
	}		}
	],		],
	"port43":"whois.example.net",		"port43":"whois.example.net",
	"events":[		"events":[
	{		{
	"eventAction":"registration",		"eventAction":"registration",
	"eventDate":"1990-12-31T23:59:59Z"		"eventDate":"1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 22, line 24 ¶		skipping to change at page 23, line 16 ¶
	See Appendix A for use of the entity object class to model various		See Appendix A for use of the entity object class to model various
	types of entities found in both RIRs and DNRs. See Appendix C		types of entities found in both RIRs and DNRs. See Appendix C
	regarding structured vs. unstructured postal addresses in entities.		regarding structured vs. unstructured postal addresses in entities.
	5.2. The Nameserver Object Class		5.2. The Nameserver Object Class
	The nameserver object class represents information regarding DNS		The nameserver object class represents information regarding DNS
	nameservers used in both forward and reverse DNS. RIRs and some DNRs		nameservers used in both forward and reverse DNS. RIRs and some DNRs
	register or expose nameserver information as an attribute of a domain		register or expose nameserver information as an attribute of a domain
	name, while other DNRs model nameservers as "first class objects".		name, while other DNRs model nameservers as "first class objects".
			Please note that some of the examples in this section include lines
			that have been wrapped for reading clarity.
	The nameserver object class accommodates both models and degrees of		The nameserver object class accommodates both models and degrees of
	variation in between.		variation in between.
	The following is an example of a nameserver object.		The following is an example of a nameserver object.
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"handle" : "XXXX",		"handle" : "XXXX",
	"ldhName" : "ns1.xn--fo-5ja.example",		"ldhName" : "ns1.xn--fo-5ja.example",
	"unicodeName" : "ns1.foo.example",		"unicodeName" : "ns.fóo.example",
	"status" : [ "active" ],		"status" : [ "active" ],
	"ipAddresses" :		"ipAddresses" :
	{		{
	"v4": [ "192.0.2.1", "192.0.2.2" ],		"v4": [ "192.0.2.1", "192.0.2.2" ],
	"v6": [ "2001:db8::123" ]		"v6": [ "2001:db8::123" ]
	},		},
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/nameserver/xxxx",		"value" : "https://example.net/nameserver/
			ns1.xn--fo-5ja.example",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/nameserver/xxxx",		"href" : "https://example.net/nameserver/
			ns1.xn--fo-5ja.example",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"port43" : "whois.example.net",		"port43" : "whois.example.net",
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	"eventAction" : "last changed",		"eventAction" : "last changed",
	"eventDate" : "1991-12-31T23:59:59Z",		"eventDate" : "1991-12-31T23:59:59Z",
	"eventActor" : "joe@example.com"		"eventActor" : "joe@example.com"
	}		}
	]		]
	}		}
	Figure 18		Figure 18
	Figure 18 is an example of a nameserver object with all values given.		Figure 18 is an example of a nameserver object with all appropriate
	Registries using a first-class nameserver data model would embed this		values given. Registries using a first-class nameserver data model
	in domain objects as well as allowing references to it with the		would embed this in domain objects as well as allowing references to
	"/nameserver" query type (all depending on the registry operators		it with the "/nameserver" query type (all depending on the registry
	policy). Other registries may pare back the information as needed.		operators policy). Other registries may pare back the information as
	Figure 19 is an example of a nameserver object as would be found in		needed. Figure 19 is an example of a nameserver object as would be
	RIRs and some DNRs, while Figure 20 is an example of a nameserver		found in RIRs and some DNRs, while Figure 20 is an example of a
	object as would be found in other DNRs.		nameserver object as would be found in other DNRs.
	The following is an example of the simplest nameserver object:		The following is an example of the simplest nameserver object:
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"ldhName" : "ns1.example.com"		"ldhName" : "ns1.example.com"
	}		}
	Figure 19		Figure 19
	skipping to change at page 25, line 8 ¶		skipping to change at page 25, line 45 ¶
	objects, they may also have an array of entities (Section 5.1)		objects, they may also have an array of entities (Section 5.1)
	embedded to signify parties responsible for the maintenance,		embedded to signify parties responsible for the maintenance,
	registrations, etc., of the nameservers.		registrations, etc., of the nameservers.
	The following is an elided example of a nameserver with embedded		The following is an elided example of a nameserver with embedded
	entities.		entities.
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"handle" : "XXXX",		"handle" : "XXXX",
	"ldhName" : "ns1.xn--fo-5ja.example",		"ldhName" : "ns.xn--fo-5ja.example",
	...		...
	"entities" :		"entities" :
	[		[
	...		...
	],		],
	...		...
	}		}
	Figure 21		Figure 21
	The nameserver object class can contain the following members:		The nameserver object class can contain the following members:
	o objectClassName -- the string "nameserver"		* objectClassName -- the string "nameserver"
	o handle -- a string representing a registry unique identifier of		* handle -- a string representing a registry-unique identifier of
	the nameserver		the nameserver
	o ldhName -- a string containing the LDH name of the nameserver (see		* ldhName -- a string containing the LDH name of the nameserver (see
	Section 3)		Section 3)
	o unicodeName -- a string containing a DNS Unicode name of the		* unicodeName -- a string containing a DNS Unicode name of the
	nameserver (see Section 3)		nameserver (see Section 3)
	o ipAddresses -- an object containing the following members:		* ipAddresses -- an object containing the following members:
	* v6 -- an array of strings containing IPv6 addresses of the		- v6 -- an array of strings containing IPv6 addresses of the
	nameserver		nameserver
	* v4 -- an array of strings containing IPv4 addresses of the		- v4 -- an array of strings containing IPv4 addresses of the
	nameserver		nameserver
	o entities -- an array of entity objects as defined by Section 5.1		* entities -- an array of entity objects as defined by Section 5.1
	o status -- see Section 4.6		* status -- see Section 4.6
	o remarks -- see Section 4.3		* remarks -- see Section 4.3
	o links -- see Section 4.2		* links -- see Section 4.2
	o port43 -- see Section 4.7		* port43 -- see Section 4.7
	o events -- see Section 4.5		* events -- see Section 4.5
	5.3. The Domain Object Class		5.3. The Domain Object Class
	The domain object class represents a DNS name and point of		The domain object class represents a DNS name and point of
	delegation. For RIRs, these delegation points are in the reverse DNS		delegation. For RIRs, these delegation points are in the reverse DNS
	tree, whereas for DNRs, these delegation points are in the forward		tree, whereas for DNRs, these delegation points are in the forward
	DNS tree.		DNS tree.
	In both cases, the high-level structure of the domain object class		In both cases, the high-level structure of the domain object class
	consists of information about the domain registration, nameserver		consists of information about the domain registration, nameserver
	skipping to change at page 26, line 40 ¶		skipping to change at page 27, line 28 ¶
	"entities" :		"entities" :
	[		[
	...		...
	]		]
	}		}
	Figure 22		Figure 22
	The domain object class can contain the following members:		The domain object class can contain the following members:
	o objectClassName -- the string "domain"		* objectClassName -- the string "domain"
	o handle -- a string representing a registry unique identifier of		* handle -- a string representing a registry-unique identifier of
	the domain object instance		the domain object instance
	o ldhName -- a string describing a domain name in LDH form as		* ldhName -- a string describing a domain name in LDH form as
	described in Section 3		described in Section 3
	o unicodeName -- a string containing a domain name with U-labels as		* unicodeName -- a string containing a domain name with U-labels as
	described in Section 3		described in Section 3
	o variants -- an array of objects, each containing the following		* variants -- an array of objects, each containing the following
	values:		values:
	* relation -- an array of strings, with each string denoting the		- relation -- an array of strings, with each string denoting the
	relationship between the variants and the containing domain		relationship between the variants and the containing domain
	object (see Section 10.2.5 for a list of suggested variant		object (see Section 10.2.5 for a list of suggested variant
	relations).		relations).
	* idnTable -- the name of the Internationalized Domain Name (IDN)		- idnTable -- the character string literal that represents the
	table of codepoints, such as one listed with the IANA (see IDN		Internationalized Domain Name (IDN) table that has been
	tables [IANA_IDNTABLES]).		registered in the IANA Repository of IDN Practices
			[IANA_IDNTABLES].
	* variantNames -- an array of objects, with each object		- variantNames -- an array of objects, with each object
	containing an "ldhName" member and a "unicodeName" member (see		containing an "ldhName" member and a "unicodeName" member (see
	Section 3).		Section 3).
	o nameservers -- an array of nameserver objects as defined by		* nameservers -- an array of nameserver objects as defined by
	Section 5.2		Section 5.2
	o secureDNS -- an object with the following members:		* secureDNS -- an object with the following members:
	* zoneSigned -- true if the zone has been signed, false		- zoneSigned -- boolean true if the zone has been signed, false
	otherwise.		otherwise.
	* delegationSigned -- boolean true if there are DS records in the		- delegationSigned -- boolean true if there are DS records in the
	parent, false otherwise.		parent, false otherwise.
	* maxSigLife -- an integer representing the signature lifetime in		- maxSigLife -- an integer representing the signature lifetime in
	seconds to be used when creating the RRSIG DS record in the		seconds to be used when creating the RRSIG DS record in the
	parent zone [RFC5910].		parent zone [RFC5910].
	* dsData -- an array of objects, each with the following members:		- dsData -- an array of objects, each with the following members:
	+ keyTag -- an integer as specified by the key tag field of a		o keyTag -- an integer as specified by the key tag field of a
	DNS DS record as specified by [RFC4034] in presentation		DNS DS record as specified by [RFC4034] in presentation
	format		format
	+ algorithm -- an integer as specified by the algorithm field		o algorithm -- an integer as specified by the algorithm field
	of a DNS DS record as described by RFC 4034 in presentation		of a DNS DS record as described by RFC 4034 in presentation
	format		format
	+ digest -- a string as specified by the digest field of a DNS		o digest -- a string as specified by the digest field of a DNS
	DS record as specified by RFC 4034 in presentation format		DS record as specified by RFC 4034 in presentation format
	+ digestType -- an integer as specified by the digest type		o digestType -- an integer as specified by the digest type
	field of a DNS DS record as specified by RFC 4034 in		field of a DNS DS record as specified by RFC 4034 in
	presentation format		presentation format
	+ events -- see Section 4.5		o events -- see Section 4.5
	+ links -- see Section 4.2		o links -- see Section 4.2
	* keyData -- an array of objects, each with the following		- keyData -- an array of objects, each with the following
	members:		members:
	+ flags -- an integer representing the flags field value in		o flags -- an integer representing the flags field value in
	the DNSKEY record [RFC4034] in presentation format		the DNSKEY record [RFC4034] in presentation format
	+ protocol -- an integer representation of the protocol field		o protocol -- an integer representation of the protocol field
	value of the DNSKEY record [RFC4034] in presentation format		value of the DNSKEY record [RFC4034] in presentation format
	+ publicKey -- a string representation of the public key in		o publicKey -- a string representation of the public key in
	the DNSKEY record [RFC4034] in presentation format		the DNSKEY record [RFC4034] in presentation format
	+ algorithm -- an integer as specified by the algorithm field		o algorithm -- an integer as specified by the algorithm field
	of a DNSKEY record as specified by [RFC4034] in presentation		of a DNSKEY record as specified by [RFC4034] in presentation
	format		format
	+ events -- see Section 4.5		o events -- see Section 4.5
	+ links -- see Section 4.2		o links -- see Section 4.2
	See Appendix D for background information on these objects.		See Appendix D for background information on these
			objects.
	o entities -- an array of entity objects as defined by Section 5.1		* entities -- an array of entity objects as defined by Section 5.1
	o status -- see Section 4.6		* status -- see Section 4.6
	o publicIds -- see Section 4.8		* publicIds -- see Section 4.8
	o remarks -- see Section 4.3		* remarks -- see Section 4.3
	o links -- see Section 4.2		* links -- see Section 4.2
	o port43 -- see Section 4.7		* port43 -- see Section 4.7
	o events -- see Section 4.5		* events -- see Section 4.5
	o network -- represents the IP network for which a reverse DNS		* network -- represents the IP network for which a reverse DNS
	domain is referenced. See Section 5.4		domain is referenced; see Section 5.4
	The following is an example of a JSON domain object representing a		The following is an example of a JSON domain object representing a
	reverse DNS delegation point that might be served by an RIR.		reverse DNS delegation point that might be served by an RIR (note
			that the dsData digest value has been modified to fit on one line).
	{		{
	"objectClassName" : "domain",		"objectClassName" : "domain",
	"handle" : "XXXX",		"handle" : "XXXX",
	"ldhName" : "0.2.192.in-addr.arpa",		"ldhName" : "0.2.192.in-addr.arpa",
	"nameservers" :		"nameservers" :
	[		[
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"ldhName" : "ns1.rir.example"		"ldhName" : "ns1.rir.example"
	skipping to change at page 29, line 21 ¶		skipping to change at page 30, line 4 ¶
	"ldhName" : "0.2.192.in-addr.arpa",		"ldhName" : "0.2.192.in-addr.arpa",
	"nameservers" :		"nameservers" :
	[		[
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"ldhName" : "ns1.rir.example"		"ldhName" : "ns1.rir.example"
	},		},
	{		{
	"objectClassName" : "nameserver",		"objectClassName" : "nameserver",
	"ldhName" : "ns2.rir.example"		"ldhName" : "ns2.rir.example"
	}		}
	],		],
	"secureDNS":		"secureDNS":
	{		{
	"delegationSigned": true,		"delegationSigned": true,
	"dsData":		"dsData":
	[		[
	{		{
	"keyTag": 12345,		"keyTag": 25345,
	"algorithm": 3,		"algorithm": 8,
	"digestType": 1,		"digestType": 2,
	"digest": "49FD46E6C4B45C55D4AC"		"digest": "2788970E18EA14...C890C85B8205B94"
	}		}
	]		]
	},		},
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value": "http://example.net/domain/XXXX",		"value": "https://example.net/domain/0.2.192.in-addr.arpa",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/domain/XXXXX",		"href" : "https://example.net/domain/0.2.192.in-addr.arpa",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	skipping to change at page 31, line 30 ¶		skipping to change at page 32, line 15 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value": "http://example.net/entity/xxxx",		"value": "https://example.net/entity/XXXX",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/entity/xxxx",		"href" : "https://example.net/entity/XXXX",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 32, line 7 ¶		skipping to change at page 32, line 41 ¶
	}		}
	]		]
	}		}
	],		],
	"network" :		"network" :
	{		{
	"objectClassName" : "ip network",		"objectClassName" : "ip network",
	"handle" : "XXXX-RIR",		"handle" : "XXXX-RIR",
	"startAddress" : "192.0.2.0",		"startAddress" : "192.0.2.0",
	"endAddress" : "192.0.2.255",		"endAddress" : "192.0.2.255",
	"ipVersion" : "v6",		"ipVersion" : "v4",
	"name": "NET-RTR-1",		"name": "NET-RTR-1",
	"type" : "DIRECT ALLOCATION",		"type" : "DIRECT ALLOCATION",
	"country" : "AU",		"country" : "AU",
	"parentHandle" : "YYYY-RIR",		"parentHandle" : "YYYY-RIR",
	"status" : [ "active" ]		"status" : [ "active" ]
	}		}
	}		}
	Figure 23		Figure 23
	The following is an example of a JSON domain object representing a		The following is an example of a JSON domain object representing a
	forward DNS delegation point that might be served by a DNR.		forward DNS delegation point that might be served by a DNR. Note
			that the secureDNS keyData publicKey value has been modified to fit
			on a single line.
	{		{
	"objectClassName" : "domain",		"objectClassName" : "domain",
	"handle" : "XXXX",		"handle" : "XXXX",
	"ldhName" : "xn--fo-5ja.example",		"ldhName" : "xn--fo-5ja.example",
	"unicodeName" : "foo.example",		"unicodeName" : "fóo.example",
	"variants" :		"variants" :
	[		[
	{		{
	"relation" : [ "registered", "conjoined" ],		"relation" : [ "registered", "conjoined" ],
	"variantNames" :		"variantNames" :
	[		[
	{		{
	"ldhName" : "xn--fo-cka.example",		"ldhName" : "xn--fo-cka.example",
	"unicodeName" : "foo.example"		"unicodeName" : "fõo.example"
	},		},
	{		{
	"ldhName" : "xn--fo-fka.example",		"ldhName" : "xn--fo-fka.example",
	"unicodeName" : "foo.example"		"unicodeName" : "föo.example"
	}		}
	]		]
	},		},
	{		{
	"relation" : [ "unregistered", "registration restricted" ],		"relation" : [ "unregistered", "registration restricted" ],
	"idnTable": ".EXAMPLE Swedish",		"idnTable": ".EXAMPLE Swedish",
	"variantNames" :		"variantNames" :
	[		[
	{		{
	"ldhName": "xn--fo-8ja.example",		"ldhName": "xn--fo-8ja.example",
	"unicodeName" : "foo.example"		"unicodeName" : "fôo.example"
	}		}
	]		]
	}		}
	],		],
	"status" : [ "locked", "transfer prohibited" ],		"status" : [ "locked", "transfer prohibited" ],
	"publicIds":[		"publicIds":[
	{		{
	"type":"ENS_Auth ID",		"type":"ENS_Auth ID",
	"identifier":"1234567890"		"identifier":"1234567890"
	skipping to change at page 33, line 39 ¶		skipping to change at page 34, line 27 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/nameserver/XXXX",		"value" : "https://example.net/nameserver/ns1.example.com",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/nameserver/XXXX",		"href" : "https://example.net/nameserver/ns1.example.com",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 34, line 31 ¶		skipping to change at page 35, line 20 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/nameserver/XXXX",		"value" : "https://example.net/nameserver/ns2.example.com",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/nameserver/XXXX",		"href" : "https://example.net/nameserver/ns2.example.com",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 41 ¶
	},		},
	{		{
	"eventAction" : "last changed",		"eventAction" : "last changed",
	"eventDate" : "1991-12-31T23:59:59Z"		"eventDate" : "1991-12-31T23:59:59Z"
	}		}
	]		]
	}		}
	],		],
	"secureDNS":		"secureDNS":
	{		{
	"zoneSigned": true,		"zoneSigned": true,
	"delegationSigned": true,		"delegationSigned": true,
	"maxSigLife": 604800,		"maxSigLife": 604800,
	"keyData":		"keyData":
	[		[
	{		{
	"flags": 257,		"flags": 257,
	"protocol": 3,		"protocol": 3,
	"algorithm": 1,		"algorithm": 8,
	"publicKey": "AQPJ////4Q==",		"publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
	"events":		"events":
	[		[
	{		{
	"eventAction": "last changed",		"eventAction": "last changed",
	"eventDate": "2012-07-23T05:15:47Z"		"eventDate": "2012-07-23T05:15:47Z"
	}		}
	]		]
	}		}
	]		]
	},		},
	skipping to change at page 35, line 37 ¶		skipping to change at page 36, line 27 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value": "http://example.net/domain/XXXX",		"value": "https://example.net/domain/xn--fo-5ja.example",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/domain/XXXX",		"href" : "https://example.net/domain/xn--fo-5ja.example",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"port43" : "whois.example.net",		"port43" : "whois.example.net",
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	skipping to change at page 37, line 31 ¶		skipping to change at page 38, line 22 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/entity/xxxx",		"value" : "https://example.net/entity/XXXX",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/entity/xxxx",		"href" : "https://example.net/entity/XXXX",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 38, line 9 ¶		skipping to change at page 39, line 9 ¶
	}		}
	]		]
	}		}
	Figure 24		Figure 24
	5.4. The IP Network Object Class		5.4. The IP Network Object Class
	The IP network object class models IP network registrations found in		The IP network object class models IP network registrations found in
	RIRs and is the expected response for the "/ip" query as defined by		RIRs and is the expected response for the "/ip" query as defined by
	[RFC7482]. There is no equivalent object class for DNRs. The high-		[I-D.ietf-regext-rfc7482bis]. There is no equivalent object class
	level structure of the IP network object class consists of		for DNRs. The high- level structure of the IP network object class
	information about the network registration and entities related to		consists of information about the network registration and entities
	the IP network (e.g., registrant information, contacts, etc.).		related to the IP network (e.g., registrant information, contacts,
			etc.).
	The following is an elided example of the IP network object type		The following is an elided example of the IP network object type
	showing the high-level structure:		showing the high-level structure:
	{		{
	"objectClassName" : "ip network",		"objectClassName" : "ip network",
	"handle" : "XXX",		"handle" : "XXX",
	...		...
	"entities" :		"entities" :
	[		[
	skipping to change at page 38, line 52 ¶		skipping to change at page 40, line 4 ¶
	"status" : [ "active" ],		"status" : [ "active" ],
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/ip/2001:db8::/48",		"value" : "https://example.net/ip/2001:db8::/48",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/ip/2001:db8::/48",		"href" : "https://example.net/ip/2001:db8::/48",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	},		},
	{		{
	"value" : "http://example.net/ip/2001:db8::/48",		"value" : "https://example.net/ip/2001:db8::/48",
	"rel" : "up",		"rel" : "up",
	"href" : "http://example.net/ip/2001:C00::/23",		"href" : "https://example.net/ip/2001:db8::/32",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 39, line 51 ¶		skipping to change at page 41, line 4 ¶
	["lang", {		["lang", {
	"pref":"1"		"pref":"1"
	}, "language-tag", "fr"],		}, "language-tag", "fr"],
	["lang", {		["lang", {
	"pref":"2"		"pref":"2"
	}, "language-tag", "en"],		}, "language-tag", "en"],
	["org", {		["org", {
	"type":"work"		"type":"work"
	}, "text", "Example"],		}, "text", "Example"],
	["title", {}, "text", "Research Scientist"],		["title", {}, "text", "Research Scientist"],
	["role", {}, "text", "Project Lead"],
			["role", {}, "text", "Project Lead"],
	["adr",		["adr",
	{ "type":"work" },		{ "type":"work" },
	"text",		"text",
	[		[
	"",		"",
	"Suite 1234",		"Suite 1234",
	"4321 Rue Somewhere",		"4321 Rue Somewhere",
	"Quebec",		"Quebec",
	"QC",		"QC",
	"G1V 2M2",		"G1V 2M2",
	skipping to change at page 40, line 42 ¶		skipping to change at page 41, line 43 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/entity/xxxx",		"value" : "https://example.net/entity/xxxx",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/entity/xxxx",		"href" : "https://example.net/entity/xxxx",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	skipping to change at page 41, line 19 ¶		skipping to change at page 42, line 20 ¶
	}		}
	]		]
	}		}
	]		]
	}		}
	Figure 26		Figure 26
	The IP network object class can contain the following members:		The IP network object class can contain the following members:
	o objectClassName -- the string "ip network"		* objectClassName -- the string "ip network"
	o handle -- a string representing an RIR-unique identifier of the		* handle -- a string representing the RIR-unique identifier of the
	network registration		network registration
	o startAddress -- the starting IP address of the network, either		* startAddress -- a string representing the starting IP address of
	IPv4 or IPv6		the network, either IPv4 or IPv6
	o endAddress -- the ending IP address of the network, either IPv4 or		* endAddress -- a string representing the ending IP address of the
	IPv6		network, either IPv4 or IPv6
	o ipVersion -- a string signifying the IP protocol version of the		* ipVersion -- a string signifying the IP protocol version of the
	network: "v4" signifies an IPv4 network, and "v6" signifies an		network: "v4" signifies an IPv4 network, and "v6" signifies an
	IPv6 network		IPv6 network
	o name -- an identifier assigned to the network registration by the		* name -- a string representing an identifier assigned to the
	registration holder		network registration by the registration holder
	o type -- a string containing an RIR-specific classification of the		* type -- a string containing an RIR-specific classification of the
	network		network as per that RIR's registration model
	o country -- a string containing the two-character country code of		* country -- a string containing the two-character country code of
	the network		the network
	o parentHandle -- a string containing an RIR-unique identifier of		* parentHandle -- a string containing an RIR-unique identifier of
	the parent network of this network registration		the parent network of this network registration
	o status -- an array of strings indicating the state of the IP		* status -- an array of strings indicating the state of the IP
	network		network as defined by Section 4.6
	o entities -- an array of entity objects as defined by Section 5.1		* entities -- an array of entity objects as defined by Section 5.1
			* remarks -- see Section 4.3
	o remarks -- see Section 4.3		* links -- see Section 4.2
	o links -- see Section 4.2
	o port43 -- see Section 4.7		* port43 -- see Section 4.7
	o events -- see Section 4.5		* events -- see Section 4.5
	5.5. Autonomous System Number Entity Object Class		5.5. The Autonomous System Number Object Class
	The Autonomous System number (autnum) object class models Autonomous		The Autonomous System number (autnum) object class models Autonomous
	System number registrations found in RIRs and represents the expected		System number registrations found in RIRs and represents the expected
	response to an "/autnum" query as defined by [RFC7482]. There is no		response to an "/autnum" query as defined by
	equivalent object class for DNRs. The high-level structure of the		[I-D.ietf-regext-rfc7482bis]. There is no equivalent object class
	autnum object class consists of information about the network		for DNRs. The high-level structure of the autnum object class
			consists of information about the autonomous system number
	registration and entities related to the autnum registration (e.g.,		registration and entities related to the autnum registration (e.g.,
	registrant information, contacts, etc.) and is similar to the IP		registrant information, contacts, etc.) and is similar to the IP
	network entity object class.		network object class.
	The following is an example of a JSON object representing an autnum.		The following is an example of a JSON object representing an autnum.
	{		{
	"objectClassName" : "autnum",		"objectClassName" : "autnum",
	"handle" : "XXXX-RIR",		"handle" : "XXXX-RIR",
	"startAutnum" : 10,		"startAutnum" : 65536,
	"endAutnum" : 15,		"endAutnum" : 65541,
	"name": "AS-RTR-1",		"name": "AS-RTR-1",
	"type" : "DIRECT ALLOCATION",		"type" : "DIRECT ALLOCATION",
	"status" : [ "active" ],		"status" : [ "active" ],
	"country": "AU",		"country": "AU",
	"remarks" :		"remarks" :
	[		[
	{		{
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/autnum/xxxx",		"value" : "https://example.net/autnum/65537",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/autnum/xxxx",		"href" : "https://example.net/autnum/65537",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 44, line 26 ¶		skipping to change at page 45, line 30 ¶
	"description" :		"description" :
	[		[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/entity/XXXX",		"value" : "https://example.net/entity/XXXX",
	"rel" : "self",		"rel" : "self",
	"href" : "http://example.net/entity/XXXX",		"href" : "https://example.net/entity/XXXX",
	"type" : "application/rdap+json"		"type" : "application/rdap+json"
	}		}
	],		],
	"events" :		"events" :
	[		[
	{		{
	"eventAction" : "registration",		"eventAction" : "registration",
	"eventDate" : "1990-12-31T23:59:59Z"		"eventDate" : "1990-12-31T23:59:59Z"
	},		},
	{		{
	skipping to change at page 45, line 8 ¶		skipping to change at page 46, line 8 ¶
	]		]
	}		}
	]		]
	}		}
	Figure 27		Figure 27
	The Autonomous System number object class can contain the following		The Autonomous System number object class can contain the following
	members:		members:
	o objectClassName -- the string "autnum"		* objectClassName -- the string "autnum"
	o handle -- a string representing an RIR-unique identifier of the		* handle -- a string representing the RIR-unique identifier of the
	autnum registration		autnum registration
	o startAutnum -- a number representing the starting number [RFC5396]		* startAutnum -- an unsigned 32-bit integer representing the
	in the block of Autonomous System numbers		starting number [RFC5396] in the block of Autonomous System
			numbers
	o endAutnum -- a number representing the ending number [RFC5396] in		* endAutnum -- an unsigned 32-bit integer representing the ending
	the block of Autonomous System numbers		number [RFC5396] in the block of Autonomous System numbers
	o name -- an identifier assigned to the autnum registration by the		* name -- a string representing an identifier assigned to the autnum
	registration holder		registration by the registration holder
	o type -- a string containing an RIR-specific classification of the		* type -- a string containing an RIR-specific classification of the
	autnum		autnum as per that RIR's registration model
	o status -- an array of strings indicating the state of the autnum		* status -- an array of strings indicating the state of the autnum
			as defined by Section 4.6
	o country -- a string containing the name of the two-character		* country -- a string containing the two-character country code of
	country code of the autnum		the autnum
	o entities -- an array of entity objects as defined by Section 5.1		* entities -- an array of entity objects as defined by Section 5.1
	o remarks -- see Section 4.3		* remarks -- see Section 4.3
	o links -- see Section 4.2		* links -- see Section 4.2
	o port43 -- see Section 4.7		* port43 -- see Section 4.7
	o events -- see Section 4.5		* events -- see Section 4.5
	6. Error Response Body		6. Error Response Body
	Some non-answer responses may return entity bodies with information		Some non-answer responses MAY return entity bodies with information
	that could be more descriptive.		that could be more descriptive.
	The basic structure of that response is an object class containing an		The basic structure of that response is an object class containing a
	error code number (corresponding to the HTTP response code) followed		REQUIRED error code number (corresponding to the HTTP response code)
	by a string named "title" and an array of strings named		followed by an OPTIONAL string named "title" and an OPTIONAL array of
	"description".		strings named "description".
	This is an example of the common response body.		This is an example of the common response body.
	{		{
	"errorCode": 418,		"errorCode": 418,
	"title": "Your Beverage Choice is Not Available",		"title": "Your Beverage Choice is Not Available",
	"description":		"description":
	[		[
	"I know coffee has more ummppphhh.",		"I know coffee has more ummppphhh.",
	"Sorry, dude!"		"Sorry, dude!"
	skipping to change at page 47, line 24 ¶		skipping to change at page 47, line 36 ¶
	[		[
	{		{
	"title" : "Beverage Policy",		"title" : "Beverage Policy",
	"description" :		"description" :
	[		[
	"Beverages with caffeine for keeping horses awake."		"Beverages with caffeine for keeping horses awake."
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/ip/192.0.2.0/24",		"value" : "https://example.net/ip/192.0.2.0/24",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/redaction_policy.html"		"href" : "https://www.example.com/redaction_policy.html"
	}		}
	]		]
	}		}
	],		],
	"lang" : "en",		"lang" : "en",
	"errorCode": 418,		"errorCode": 418,
	"title": "Your beverage choice is not available",		"title": "Your beverage choice is not available",
	"description":		"description":
	[		[
	"I know coffee has more ummppphhh.",		"I know coffee has more ummppphhh.",
	skipping to change at page 47, line 41 ¶		skipping to change at page 48, line 4 ¶
	],		],
	"lang" : "en",		"lang" : "en",
	"errorCode": 418,		"errorCode": 418,
	"title": "Your beverage choice is not available",		"title": "Your beverage choice is not available",
	"description":		"description":
	[		[
	"I know coffee has more ummppphhh.",		"I know coffee has more ummppphhh.",
	"Sorry, dude!"		"Sorry, dude!"
	]		]
	}		}
	Figure 29		Figure 29
	7. Responding to Help Queries		7. Responding to Help Queries
	The appropriate response to /help queries as defined by [RFC7482] is		The appropriate response to /help queries as defined by
	to use the notices structure as defined in Section 4.3.		[I-D.ietf-regext-rfc7482bis] is to use the notices structure as
			defined in Section 4.3.
	This is an example of a response to a /help query including the		This is an example of a response to a /help query including the
	rdapConformance data structure.		rdapConformance data structure.
	{		{
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0"		"rdap_level_0"
	],		],
	"notices" :		"notices" :
	[		[
	{		{
	"title" : "Authentication Policy",		"title" : "Authentication Policy",
	"description" :		"description" :
	[		[
	"Access to sensitive data for users with proper credentials."		"Access to sensitive data for users with proper credentials."
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/help",		"value" : "https://example.net/help",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/auth_policy.html"		"href" : "https://www.example.com/auth_policy.html"
	}		}
	]		]
	}		}
	]		]
	}		}
	Figure 30		Figure 30
	8. Responding To Searches		8. Responding To Searches
	[RFC7482] specifies three types of searches: domains, nameservers,		[I-D.ietf-regext-rfc7482bis] specifies three types of searches:
	and entities. Responses to these searches take the form of an array		domains, nameservers, and entities. Responses to these searches take
	of object instances where each instance is an appropriate object		the form of an array of object instances where each instance is an
	class for the search (i.e., a search for /domains yields an array of		appropriate object class for the search (i.e., a search for /domains
	domain object instances). These arrays are contained within the		yields an array of domain object instances). These arrays are
	response object.		contained within the response object.
	The names of the arrays are as follows:		The names of the arrays are as follows:
	o for /domains searches, the array is "domainSearchResults"		* for /domains searches, the array is "domainSearchResults"
	o for /nameservers searches, the array is "nameserverSearchResults"		* for /nameservers searches, the array is "nameserverSearchResults"
	o for /entities searches, the array is "entitySearchResults"		* for /entities searches, the array is "entitySearchResults"
	The following is an elided example of a response to a /domains		The following is an elided example of a response to a /domains
	search.		search.
	{		{
	"rdapConformance" :		"rdapConformance" :
	[		[
	"rdap_level_0"		"rdap_level_0"
	],		],
	...		...
	skipping to change at page 50, line 22 ¶		skipping to change at page 50, line 22 ¶
	{		{
	"title" : "Search Policy",		"title" : "Search Policy",
	"type" : "result set truncated due to authorization",		"type" : "result set truncated due to authorization",
	"description" :		"description" :
	[		[
	"Search results are limited to 25 per day per querying IP."		"Search results are limited to 25 per day per querying IP."
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/help",		"value" : "https://example.net/help",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/search_policy.html"		"href" : "https://www.example.com/search_policy.html"
	}		}
	]		]
	}		}
	],		],
	"domainSearchResults" :		"domainSearchResults" :
	[		[
	...		...
	]		]
	}		}
	skipping to change at page 51, line 39 ¶		skipping to change at page 51, line 37 ¶
	{		{
	"title" : "Data Policy",		"title" : "Data Policy",
	"type" : "object truncated due to unexplainable reason",		"type" : "object truncated due to unexplainable reason",
	"description" :		"description" :
	[		[
	"Some of the data in this object has been removed."		"Some of the data in this object has been removed."
	],		],
	"links" :		"links" :
	[		[
	{		{
	"value" : "http://example.net/help",		"value" : "https://example.net/help",
	"rel" : "alternate",		"rel" : "alternate",
	"type" : "text/html",		"type" : "text/html",
	"href" : "http://www.example.com/data_policy.html"		"href" : "https://www.example.com/data_policy.html"
	}		}
	]		]
	}		}
	]		]
	}		}
	Figure 33		Figure 33
	10. IANA Considerations		10. IANA Considerations
			IANA is requested to update the description of the "transfer" event
			action as described in Section 10.2.3.
	10.1. RDAP JSON Media Type Registration		10.1. RDAP JSON Media Type Registration
	This specification registers the "application/rdap+json" media type.		IANA is requested to update the media type registration as described
			below.
			This specification registers the "application/rdap+json" media
			type.
	Type name: application		Type name: application
	Subtype name: rdap+json		Subtype name: rdap+json
	Required parameters: n/a		Required parameters: n/a
	Encoding considerations: See Section 3.1 of [RFC6839].		Encoding considerations: See Section 3.1 of [RFC6839].
	Security considerations: The media represented by this identifier		Security considerations: The media represented by this identifier
	does not have security considerations beyond that found in		does not have security considerations beyond that found in
	Section 6 of [RFC7159].		Section 12 of [RFC8259].
	Interoperability considerations: There are no known		Interoperability considerations: There are no known
	interoperability problems regarding this media format.		interoperability problems regarding this media format.
	Published specification: RFC 7483		Published specification: RFC <this new RFC number>
	Applications that use this media type: Implementations of the		Applications that use this media type: Implementations of the
	Registration Data Access Protocol (RDAP).		Registration Data Access Protocol (RDAP).
	Additional information: This media type is a product of the IETF		Additional information: This media type is a product of the IETF
	WEIRDS working group. The WEIRDS charter, information on the		REGEXT working group. The REGEXT charter, information on the
	WEIRDS mailing list, and other documents produced by the WEIRDS		REGEXT mailing list, and other documents produced by the REGEXT
	working group can be found at		working group can be found at https://datatracker.ietf.org/wg/
	<https://datatracker.ietf.org/wg/weirds/>.		regext/.
	Person & email address to contact for further information: IESG		Person & email address to contact for further information: IESG
	<iesg@ietf.org>		<iesg@ietf.org>
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author: Andy Newton		Author: Andy Newton
	skipping to change at page 53, line 47 ¶		skipping to change at page 53, line 47 ¶
	meaning of the value, how it might be used, and/or how it should		meaning of the value, how it might be used, and/or how it should
	be interpreted by clients.		be interpreted by clients.
	4. Registrant Name -- the name of the person registering the value.		4. Registrant Name -- the name of the person registering the value.
	5. Registrant Contact Information -- an email address, postal		5. Registrant Contact Information -- an email address, postal
	address, or some other information to be used to contact the		address, or some other information to be used to contact the
	registrant.		registrant.
	This registry is operated under the "Expert Review" policy defined in		This registry is operated under the "Expert Review" policy defined in
	[RFC5226].		[RFC8126].
	Review of registrations into this registry by the designated		Review of registrations into this registry by the designated
	expert(s) should be narrowly judged on the following criteria:		expert(s) should be narrowly judged on the following criteria:
	1. Values in need of being placed into multiple types must be		1. Values in need of being placed into multiple types must be
	assigned a separate registration for each type.		assigned a separate registration for each type.
	2. Values must be strings. They should be multiple words separated		2. Values must be strings. They should be multiple words separated
	by single space characters. Every character should be		by single space characters. Every character should be
	lowercased. If possible, every word should be given in English		lowercased. If possible, every word should be given in English
	skipping to change at page 54, line 39 ¶		skipping to change at page 54, line 36 ¶
	DNR or RIR to make this determination.		DNR or RIR to make this determination.
	The following sections provide initial registrations into this		The following sections provide initial registrations into this
	registry.		registry.
	10.2.1. Notice and Remark Types		10.2.1. Notice and Remark Types
	The following values have been registered in the "RDAP JSON Values"		The following values have been registered in the "RDAP JSON Values"
	registry:		registry:
	Value: result set truncated due to authorization		* Value: result set truncated due to authorization
	Type: notice and remark type		Type: notice and remark type
	Description: The list of results does not contain all results due		Description: The list of results does not contain all results due
	to lack of authorization. This may indicate to some clients		to lack of authorization. This may indicate to some clients that
	that proper authorization will yield a longer result set.		proper authorization will yield a longer result set.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: result set truncated due to excessive load
			* Value: result set truncated due to excessive load
	Type: notice and remark type		Type: notice and remark type
	Description: The list of results does not contain all results due		Description: The list of results does not contain all results due
	to an excessively heavy load on the server. This may indicate		to excessively heavy load on the server. This may indicate to
	to some clients that requerying at a later time will yield a		some clients that requerying at a later time will yield a longer
	longer result set.		result set.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: result set truncated due to unexplainable reasons		* Value: result set truncated due to unexplainable reasons
	Type: notice and remark type		Type: notice and remark type
	Description: The list of results does not contain all results for		Description: The list of results does not contain all results for
	an unexplainable reason. This may indicate to some clients		an unexplainable reason. This may indicate to some clients that
	that requerying for any reason will not yield a longer result		requerying for any reason will not yield a longer result set.
	set.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: object truncated due to authorization		* Value: object truncated due to authorization
	Type: notice and remark type		Type: notice and remark type
	Description: The object does not contain all data due to lack of		Description: The object does not contain all data due to lack of
	authorization.		authorization.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: object truncated due to excessive load		* Value: object truncated due to excessive load
	Type: notice and remark type		Type: notice and remark type
	Description: The object does not contain all data due to an
	excessively heavy load on the server. This may indicate to		Description: The object does not contain all data due to
	some clients that requerying at a later time will yield all		excessively heavy load on the server. This may indicate to some
	data of the object.		clients that requerying at a later time will yield all data of the
			object.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: object truncated due to unexplainable reasons		* Value: object truncated due to unexplainable reasons
	Type: notice and remark type		Type: notice and remark type
	Description: The object does not contain all data for an		Description: The object does not contain all data for an
	unexplainable reason.		unexplainable reason.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	10.2.2. Status		10.2.2. Status
	The following values have been registered in the "RDAP JSON Values"		The following values have been registered in the "RDAP JSON Values"
	registry:		registry:
	Value: validated		* Value: validated
	Type: status		Type: status
	Description: Signifies that the data of the object instance has		Description: Signifies that the data of the object instance has
	been found to be accurate. This type of status is usually		been found to be accurate. This type of status is usually found
	found on entity object instances to note the validity of		on entity object instances to note the validity of identifying
	identifying contact information.		contact information.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: renew prohibited		* Value: renew prohibited
	Type: status		Type: status
	Description: Renewal or reregistration of the object instance is		Description: Renewal or reregistration of the object instance is
	forbidden.		forbidden.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: update prohibited		* Value: update prohibited
	Type: status		Type: status
	Description: Updates to the object instance are forbidden.		Description: Updates to the object instance are forbidden.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: transfer prohibited		* Value: transfer prohibited
	Type: status		Type: status
	Description: Transfers of the registration from one registrar to		Description: Transfers of the registration from one registrar to
	another are forbidden. This type of status normally applies to		another are forbidden. This type of status normally applies to
	DNR domain names.		DNR domain names.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: delete prohibited		* Value: delete prohibited
	Type: status		Type: status
	Description: Deletion of the registration of the object instance		Description: Deletion of the registration of the object instance
	is forbidden. This type of status normally applies to DNR		is forbidden. This type of status normally applies to DNR domain
	domain names.		names.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: proxy
			* Value: proxy
	Type: status		Type: status
	Description: The registration of the object instance has been		Description: The registration of the object instance has been
	performed by a third party. This is most commonly applied to		performed by a third party. This is most commonly applied to
	entities.		entities.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: private		* Value: private
	Type: status		Type: status
	Description: The information of the object instance is not		Description: The information of the object instance is not
	designated for public consumption. This is most commonly		designated for public consumption. This is most commonly applied
	applied to entities.		to entities.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: removed		* Value: removed
	Type: status		Type: status
	Description: Some of the information of the object instance has		Description: Some of the information of the object instance has
	not been made available and has been removed. This is most		not been made available and has been removed. This is most
	commonly applied to entities.		commonly applied to entities.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: obscured		* Value: obscured
	Type: status		Type: status
	Description: Some of the information of the object instance has		Description: Some of the information of the object instance has
	been altered for the purposes of not readily revealing the		been altered for the purposes of not readily revealing the actual
	actual information of the object instance. This is most		information of the object instance. This is most commonly applied
	commonly applied to entities.		to entities.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: associated		* Value: associated
	Type: status		Type: status
	Description: The object instance is associated with other object		Description: The object instance is associated with other object
	instances in the registry. This is most commonly used to		instances in the registry. This is most commonly used to signify
	signify that a nameserver is associated with a domain or that		that a nameserver is associated with a domain or that an entity is
	an entity is associated with a network resource or domain.		associated with a network resource or domain.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: active
			* Value: active
	Type: status		Type: status
	Description: The object instance is in use. For domain names, it		Description: The object instance is in use. For domain names, it
	signifies that the domain name is published in DNS. For		signifies that the domain name is published in DNS. For network
	network and autnum registrations, it signifies that they are		and autnum registrations it signifies that they are allocated or
	allocated or assigned for use in operational networks. This		assigned for use in operational networks. This maps to the
	maps to the "OK" status of the Extensible Provisioning Protocol		Extensible Provisioning Protocol (EPP) [RFC5730] 'OK' status.
	(EPP) [RFC5730] .
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: inactive		* Value: inactive
	Type: status		Type: status
	Description: The object instance is not in use. See "active".
			Description: The object instance is not in use. See 'active'.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: locked		* Value: locked
	Type: status		Type: status
	Description: Changes to the object instance cannot be made,		Description: Changes to the object instance cannot be made,
	including the association of other object instances.		including the association of other object instances.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: pending create		* Value: pending create
	Type: status		Type: status
	Description: A request has been received for the creation of the		Description: A request has been received for the creation of the
	object instance, but this action is not yet complete.		object instance but this action is not yet complete.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: pending renew		* Value: pending renew
	Type: status		Type: status
	Description: A request has been received for the renewal of the		Description: A request has been received for the renewal of the
	object instance, but this action is not yet complete.		object instance but this action is not yet complete.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: pending transfer
			* Value: pending transfer
	Type: status		Type: status
	Description: A request has been received for the transfer of the		Description: A request has been received for the transfer of the
	object instance, but this action is not yet complete.		object instance but this action is not yet complete.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: pending update		* Value: pending update
	Type: status		Type: status
	Description: A request has been received for the update or		Description: A request has been received for the update or
	modification of the object instance, but this action is not yet		modification of the object instance but this action is not yet
	complete.		complete.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: pending delete		* Value: pending delete
	Type: status		Type: status
	Description: A request has been received for the deletion or		Description: A request has been received for the deletion or
	removal of the object instance, but this action is not yet		removal of the object instance but this action is not yet
	complete. For domains, this might mean that the name is no		complete. For domains, this might mean that the name is no longer
	longer published in DNS but has not yet been purged from the		published in DNS but has not yet been purged from the registry
	registry database.		database.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	10.2.3. Event Actions		10.2.3. Event Actions
	The following values have been registered in the "RDAP JSON Values"		The following values have been registered in the "RDAP JSON Values"
	registry:		registry:
	Value: registration		* Value: registration
	Type: event action		Type: event action
	Description: The object instance was initially registered.		Description: The object instance was initially registered.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: reregistration		* Value: reregistration
	Type: event action		Type: event action
	Description: The object instance was registered subsequently to		Description: The object instance was registered subsequently to
	initial registration.		initial registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: last changed
			* Value: last changed
	Type: event action		Type: event action
	Description: An action noting when the information in the object		Description: An action noting when the information in the object
	instance was last changed.		instance was last changed.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: expiration		* Value: expiration
	Type: event action		Type: event action
	Description: The object instance has been removed or will be		Description: The object instance has been removed or will be
	removed at a predetermined date and time from the registry.		removed at a pre-determined date and time from the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: deletion		* Value: deletion
	Type: event action		Type: event action
	Description: The object instance was removed from the registry at		Description: The object instance was removed from the registry at
	a point in time that was not predetermined.		a point in time that was not pre-determined.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: reinstantiation		* Value: reinstantiation
	Type: event action		Type: event action
	Description: The object instance was reregistered after having		Description: The object instance was reregistered after having
	been removed from the registry.		been removed from the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: transfer		* Value: transfer
	Type: event action		Type: event action
	Description: The object instance was transferred from one		Description: The object instance was transferred from one
	registrant to another.		registrar to another.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: locked		* Value: locked
	Type: event action		Type: event action
	Description: The object instance was locked (see the "locked"
	status).		Description: The object instance was locked (see the 'locked'
			status).
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: unlocked
			* Value: unlocked
	Type: event action		Type: event action
	Description: The object instance was unlocked (see the "locked"
	status).		Description: The object instance was unlocked (see the 'locked'
			status).
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	10.2.4. Roles		10.2.4. Roles
	The following values have been registered in the "RDAP JSON Values"		The following values have been registered in the "RDAP JSON Values"
	registry:		registry:
	Value: registrant		* Value: registrant
	Type: role		Type: role
	Description: The entity object instance is the registrant of the		Description: The entity object instance is the registrant of the
	registration. In some registries, this is known as a		registration. In some registries, this is known as a maintainer.
	maintainer.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: technical		* Value: technical
	Type: role		Type: role
	Description: The entity object instance is a technical contact for		Description: The entity object instance is a technical contact for
	the registration.		the registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: administrative		* Value: administrative
	Type: role		Type: role
	Description: The entity object instance is an administrative		Description: The entity object instance is an administrative
	contact for the registration.		contact for the registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: abuse		* Value: abuse
	Type: role		Type: role
	Description: The entity object instance handles network abuse		Description: The entity object instance handles network abuse
	issues on behalf of the registrant of the registration.		issues on behalf of the registrant of the registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: billing
			* Value: billing
	Type: role		Type: role
	Description: The entity object instance handles payment and		Description: The entity object instance handles payment and
	billing issues on behalf of the registrant of the registration.		billing issues on behalf of the registrant of the registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: registrar		* Value: registrar
	Type: role		Type: role
	Description: The entity object instance represents the authority		Description: The entity object instance represents the authority
	responsible for the registration in the registry.		responsible for the registration in the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: reseller		* Value: reseller
	Type: role		Type: role
	Description: The entity object instance represents a third party		Description: The entity object instance represents a third party
	through which the registration was conducted (i.e., not the		through which the registration was conducted (i.e. not the
	registry or registrar).		registry or registrar).
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: sponsor		* Value: sponsor
	Type: role		Type: role
	Description: The entity object instance represents a domain policy		Description: The entity object instance represents a domain policy
	sponsor, such as an ICANN-approved sponsor.		sponsor, such as an ICANN approved sponsor.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: proxy		* Value: proxy
	Type: role		Type: role
	Description: The entity object instance represents a proxy for		Description: The entity object instance represents a proxy for
	another entity object, such as a registrant.		another entity object, such as a registrant.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: notifications		* Value: notifications
	Type: role		Type: role
	Description: An entity object instance designated to receive		Description: An entity object instance designated to receive
	notifications about association object instances.		notifications about association object instances.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: noc
			* Value: noc
	Type: role		Type: role
	Description: The entity object instance handles communications		Description: The entity object instance handles communications
	related to a network operations center (NOC).		related to a network operations center (NOC).
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	10.2.5. Variant Relations		10.2.5. Variant Relations
	The following values have been registered in the "RDAP JSON Values"		The following values have been registered in the "RDAP JSON Values"
	registry:		registry:
	Value: registered		* Value: registered
	Type: domain variant relation		Type: domain variant relation
	Description: The variant names are registered in the registry.		Description: The variant names are registered in the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: unregistered		* Value: unregistered
	Type: domain variant relation		Type: domain variant relation
	Description: The variant names are not found in the registry.		Description: The variant names are not found in the registry.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: registration restricted		* Value: registration restricted
	Type: domain variant relation		Type: domain variant relation
	Description: Registration of the variant names is restricted to		Description: Registration of the variant names is restricted to
	certain parties or within certain rules.		certain parties or within certain rules.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: open registration		* Value: open registration
	Type: domain variant relation		Type: domain variant relation
	Description: Registration of the variant names is available to		Description: Registration of the variant names is available to
	generally qualified registrants.		generally qualified registrants.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	Value: conjoined
			* Value: conjoined
	Type: domain variant relation		Type: domain variant relation
	Description: Registration of the variant names occurs		Description: Registration of the variant names occurs
	automatically with the registration of the containing domain		automatically with the registration of the containing domain
	registration.		registration.
	Registrant Name: IESG		Registrant Name: IESG
	Registrant Contact Information: iesg@ietf.org		Registrant Contact Information: iesg@ietf.org
	11. Security Considerations		11. Implementation Status
			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".
			11.1. RedDog
			* Responsible Organization: NIC Mexico
			* Location: https://reddog.mx/
			* Description: RedDog implements all the functionality of an RDAP
			Server defined in RFCs 7480,7481,7482 and 7483. RedDog is highly
			configurable and extensible to fit the needs of the developers and
			operators.
			* Level of Maturity: Production.
			* Coverage: RedDog supports all lookups, searches and responses for
			all object classes described in RFC 7482 and RFC 7483.
			* Version Compatibility: RFC 7482 and RFC 7483
			* Licensing: Apache License 2.0
			* Contact Information: reddog-dev@nic.mx
			* Information last updated: November 22, 2019
			11.2. Verisign
			* Responsible Organization: Verisign
			* Location: https://rdap.verisign.com/com/v1/,
			https://rdap.verisign.com/net/v1/
			* Description: Verisign's production RDAP service for the .com and
			.net gTLDs.
			* Level of Maturity: Production.
			* Coverage: Lookup of domain names, name servers, entities; name
			server search by IP address; help.
			* Version Compatibility: RFC 7483
			* Contact Information: info@verisign-grs.com
			11.3. Verisign Labs
			* Responsible Organization: Verisign Labs
			* Location: https://rdap.verisignlabs.com/rdap/v1/
			* Description: Verisign's experimental RDAP service for the .cc and
			.tv ccTLDs.
			* Level of Maturity: Experimental.
			* Coverage: Lookup of domain names, name servers, entities; name
			server search by IP address; basic search; regular expression
			search; federated authentication; help.
			* Version Compatibility: RFC 7483
			* Contact Information: Scott Hollenbeck, shollenbeck@verisign.com
			11.4. Asia-Pacific Network Information Centre (APNIC)
			* Responsible Organization: Asia-Pacific Network Information Centre
			(APNIC)
			* Location: https://rdap.apnic.net/, https://github.com/APNIC-net/
			rdapd
			* Description: APNIC's production RDAP service for Internet number
			resouces.
			* Level of Maturity: Production.
			* Coverage: Lookup of IP networks, AS numbers, domains, and
			entities. Also domain search by name, entity search by handle or
			full name, and help responses.
			* Version Compatibility: RFC 7483
			* Contact Information: helpdesk@apnic.net
			12. Security Considerations
	This specification models information serialized in JSON format. As		This specification models information serialized in JSON format. As
	JSON is a subset of JavaScript, implementations are advised to follow		JSON is a subset of JavaScript, implementations are advised to follow
	the security considerations outlined in Section 6 of [RFC7159] to		the security considerations outlined in Section 12 of [RFC8259] to
	prevent code injection.		prevent code injection.
	Though not specific to JSON, RDAP implementers should be aware of the		Though not specific to JSON, RDAP implementers should be aware of the
	security considerations specified in [RFC7480] and the security		security considerations specified in [RFC7480] and the security
	requirements and considerations in [RFC7481].		requirements and considerations in [RFC7481].
			RDAP responses allow for retrieval of DNSSEC (key) related
			information, but the RRSIG DS from the parent zone is not conveyed
			alongside it. This means that the DNSSEC keys retrieved by RDAP are
			disconnected from their containing PKI, and as such are not generally
			expected to be trusted without additional information. In
			particular, the HTTPS channel protecting the RDAP connection is not
			expected to be authorized to certify the validity of the DNSSEC keys.
	Clients caching data, especially clients using RDAP-specific caches		Clients caching data, especially clients using RDAP-specific caches
	(instead of HTTP-layer caches), should have safeguards to prevent		(instead of HTTP-layer caches), should have safeguards to prevent
	cache poisoning. See Section 5 for advice on using the self links		cache poisoning. See Section 5 for advice on using the self links
	for caching.		for caching.
	Finally, service operators should be aware of the privacy mechanisms		Finally, service operators should be aware of the privacy mechanisms
	noted in Section 13.		noted in Section 14.
	12. Internationalization Considerations		13. Internationalization Considerations
	12.1. Character Encoding		13.1. Character Encoding
	The default text encoding for JSON responses in RDAP is UTF-8		The default text encoding for JSON responses in RDAP is UTF-8
	[RFC3629], and all servers and clients MUST support UTF-8.		[RFC3629], and all servers and clients MUST support UTF-8.
	12.2. URIs and IRIs		13.2. URIs and IRIs
	[RFC7480] defines the use of URIs and IRIs in RDAP.		[RFC7480] defines the use of URIs and IRIs in RDAP.
	12.3. Language Tags		13.3. Language Tags
	Section 4.4 defines the use of language tags in the JSON responses		Section 4.4 defines the use of language tags in the JSON responses
	defined in this document.		defined in this document.
	12.4. Internationalized Domain Names		13.4. Internationalized Domain Names
	IDNs are denoted in this specification by the separation of DNS names		IDNs are denoted in this specification by the separation of DNS names
	in LDH form and Unicode form (see Section 3). Representation of IDNs		in LDH form and Unicode form (see Section 3). Representation of IDNs
	in registries is described by the "variants" object in Section 5.3		in registries is described by the "variants" object in Section 5.3
	and the suggested values listed in Section 10.2.5.		and the suggested values listed in Section 10.2.5.
	13. Privacy Considerations		14. Privacy Considerations
	This specification suggests status values to denote contact and		This specification suggests status values to denote contact and
	registrant information that has been marked as private and/or has		registrant information that has been marked as private and/or has
	been removed or obscured. See Section 10.2.2 for the complete list		been removed or obscured. See Section 10.2.2 for the complete list
	of status values. A few of the status values indicate that there are		of status values. A few of the status values indicate that there are
	privacy concerns associated with the object instance. The following		privacy concerns associated with the object instance. The following
	status codes SHOULD be used to describe data elements of a response		status codes SHOULD be used to describe data elements of a response
	when appropriate:		when appropriate:
	private -- The object is not be shared in query responses, unless		private -- The object is not be shared in query responses, unless
	skipping to change at page 65, line 41 ¶		skipping to change at page 70, line 34 ¶
	but the response value has been altered so that values are not		but the response value has been altered so that values are not
	easily discernible. A value changed from "1212" to "XXXX" is an		easily discernible. A value changed from "1212" to "XXXX" is an
	example of obscured data. This option may reveal privacy		example of obscured data. This option may reveal privacy
	sensitive information and should only be used when data		sensitive information and should only be used when data
	sensitivity does not require a more protective option like		sensitivity does not require a more protective option like
	"private" or "removed".		"private" or "removed".
	See Appendix A.1 for an example of applying those values to contacts		See Appendix A.1 for an example of applying those values to contacts
	and registrants.		and registrants.
	14. References		15. References
	14.1. Normative References		15.1. Normative References
			[I-D.ietf-regext-rfc7482bis]
			Hollenbeck, S. and A. Newton, "Registration Data Access
			Protocol (RDAP) Query Format", Work in Progress, Internet-
			Draft, draft-ietf-regext-rfc7482bis-02, 8 September 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-regext-
			rfc7482bis-02.txt>.
	[ISO.3166.1988]		[ISO.3166.1988]
	International Organization for Standardization, "Codes for		International Organization for Standardization, "Codes for
	the representation of names of countries, 3rd edition",		the representation of names of countries, 3rd edition",
	ISO Standard 3166, August 1988.		ISO Standard 3166, August 1988.
	[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, March 1997,		Requirement Levels", BCP 14, RFC 2119,
	<http://www.rfc-editor.org/info/rfc2119>.		DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Internet: Timestamps", RFC 3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<http://www.rfc-editor.org/info/rfc3339>.		<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003,		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	<http://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[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, RFC		Resource Identifier (URI): Generic Syntax", STD 66,
	3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008, <http://www.rfc-editor.org/info/rfc5226>.
	[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of		[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
	Autonomous System (AS) Numbers", RFC 5396, December 2008,		Autonomous System (AS) Numbers", RFC 5396,
	<http://www.rfc-editor.org/info/rfc5396>.		DOI 10.17487/RFC5396, December 2008,
			<https://www.rfc-editor.org/info/rfc5396>.
	[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying		[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
	Languages", BCP 47, RFC 5646, September 2009,		Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
	<http://www.rfc-editor.org/info/rfc5646>.		September 2009, <https://www.rfc-editor.org/info/rfc5646>.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, August 2010,		RFC 5890, DOI 10.17487/RFC5890, August 2010,
	<http://www.rfc-editor.org/info/rfc5890>.		<https://www.rfc-editor.org/info/rfc5890>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6		[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952, August 2010,		Address Text Representation", RFC 5952,
	<http://www.rfc-editor.org/info/rfc5952>.		DOI 10.17487/RFC5952, August 2010,
			<https://www.rfc-editor.org/info/rfc5952>.
	[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010,
	<http://www.rfc-editor.org/info/rfc5988>.
	[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,		[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
	January 2014, <http://www.rfc-editor.org/info/rfc7095>.		DOI 10.17487/RFC7095, January 2014,
			<https://www.rfc-editor.org/info/rfc7095>.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014,
	<http://www.rfc-editor.org/info/rfc7159>.
	[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the		[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
	Registration Data Access Protocol (RDAP)", RFC 7480, March		Registration Data Access Protocol (RDAP)", RFC 7480,
	2015, <http://www.rfc-editor.org/info/rfc7480>.		DOI 10.17487/RFC7480, March 2015,
			<https://www.rfc-editor.org/info/rfc7480>.
	[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the		[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
	Registration Data Access Protocol (RDAP)", RFC 7481, March		Registration Data Access Protocol (RDAP)", RFC 7481,
	2015, <http://www.rfc-editor.org/info/rfc7481>.		DOI 10.17487/RFC7481, March 2015,
			<https://www.rfc-editor.org/info/rfc7481>.
	[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Protocol (RDAP) Query Format", RFC 7482, March 2015,		Writing an IANA Considerations Section in RFCs", BCP 26,
	<http://www.rfc-editor.org/info/rfc7482>.		RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	14.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017,
			<https://www.rfc-editor.org/info/rfc8259>.
			[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
			DOI 10.17487/RFC8288, October 2017,
			<https://www.rfc-editor.org/info/rfc8288>.
			15.2. Informative References
	[IANA_IDNTABLES]		[IANA_IDNTABLES]
	IANA, "Repository of IDN Practices",		IANA, "Repository of IDN Practices",
	<http://www.iana.org/domains/idn-tables>.		<https://www.iana.org/domains/idn-tables>.
	[JSON_ascendancy]		[JSON_ascendancy]
	MacVittie, L., "The Stealthy Ascendancy of JSON", April		MacVittie, L., "The Stealthy Ascendancy of JSON", April
	2011, <https://devcentral.f5.com/weblogs/macvittie/		2011, <https://devcentral.f5.com/s/articles/the-stealthy-
	archive/2011/04/27/the-stealthy-ascendancy-of-json.aspx>.		ascendancy-of-json>.
	[JSON_performance_study]		[JSON_performance_study]
	Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta,		Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta,
	"Comparison of JSON and XML Data Interchange Formats: A		"Comparison of JSON and XML Data Interchange Formats: A
	Case Study", 2009,		Case Study", 2009,
	<http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf>.		<https://www.cs.montana.edu/izurieta/pubs/caine2009.pdf>.
	[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,		[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
	September 2004, <http://www.rfc-editor.org/info/rfc3912>.		DOI 10.17487/RFC3912, September 2004,
			<https://www.rfc-editor.org/info/rfc3912>.
	[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",		[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
	STD 69, RFC 5730, August 2009,		STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
	<http://www.rfc-editor.org/info/rfc5730>.		<https://www.rfc-editor.org/info/rfc5730>.
	[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)		[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
	Security Extensions Mapping for the Extensible		Security Extensions Mapping for the Extensible
	Provisioning Protocol (EPP)", RFC 5910, May 2010,		Provisioning Protocol (EPP)", RFC 5910,
	<http://www.rfc-editor.org/info/rfc5910>.		DOI 10.17487/RFC5910, May 2010,
			<https://www.rfc-editor.org/info/rfc5910>.
	[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,		[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
	August 2011, <http://www.rfc-editor.org/info/rfc6350>.		DOI 10.17487/RFC6350, August 2011,
			<https://www.rfc-editor.org/info/rfc6350>.
	[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type		[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
	Structured Syntax Suffixes", RFC 6839, January 2013,		Structured Syntax Suffixes", RFC 6839,
	<http://www.rfc-editor.org/info/rfc6839>.		DOI 10.17487/RFC6839, January 2013,
			<https://www.rfc-editor.org/info/rfc6839>.
			[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", BCP 205,
			RFC 7942, DOI 10.17487/RFC7942, July 2016,
			<https://www.rfc-editor.org/info/rfc7942>.
	Appendix A. Suggested Data Modeling with the Entity Object Class		Appendix A. Suggested Data Modeling with the Entity Object Class
	A.1. Registrants and Contacts		A.1. Registrants and Contacts
	This document does not provide specific object classes for		This document does not provide specific object classes for
	registrants and contacts. Instead, the entity object class may be		registrants and contacts. Instead, the entity object class may be
	used to represent a registrant or contact. When the entity object is		used to represent a registrant or contact. When the entity object is
	embedded inside a containing object such as a domain name or IP		embedded inside a containing object such as a domain name or IP
	network, the "roles" string array can be used to signify the		network, the "roles" string array can be used to signify the
	skipping to change at page 71, line 51 ¶		skipping to change at page 77, line 31 ¶
	"remarks":[		"remarks":[
	{		{
	"description":[		"description":[
	"She sells sea shells down by the sea shore.",		"She sells sea shells down by the sea shore.",
	"Originally written by Terry Sullivan."		"Originally written by Terry Sullivan."
	]		]
	}		}
	],		],
	"links":[		"links":[
	{		{
	"value":"http://example.net/entity/XXXX",		"value":"https://example.net/entity/XXXX",
	"rel":"alternate",		"rel":"alternate",
	"type":"text/html",		"type":"text/html",
	"href":"http://www.example.com"		"href":"https://www.example.com"
	}		}
	]		]
	}		}
	]		]
	}		}
	Figure 36		Figure 36
	Appendix B. Modeling Events		Appendix B. Modeling Events
	skipping to change at page 75, line 27 ¶		skipping to change at page 81, line 4 ¶
	{		{
	"type":["work", "cell", "voice", "video", "text"]		"type":["work", "cell", "voice", "video", "text"]
	},		},
	"uri",		"uri",
	"tel:+1-555-555-1234"		"tel:+1-555-555-1234"
	],		],
	["email",		["email",
	{ "type":"work" },		{ "type":"work" },
	"text", "joe.user@example.com"		"text", "joe.user@example.com"
	],		],
	["geo", {		["geo", {
	"type":"work"		"type":"work"
	}, "uri", "geo:46.772673,-71.282945"],		}, "uri", "geo:46.772673,-71.282945"],
	["key",		["key",
	{ "type":"work" },		{ "type":"work" },
	"uri", "http://www.example.com/joe.user/joe.asc"		"uri", "https://www.example.com/joe.user/joe.asc"
	],		],
	["tz", {},		["tz", {},
	"utc-offset", "-05:00"],		"utc-offset", "-05:00"],
	["url", { "type":"home" },		["url", { "type":"home" },
	"uri", "http://example.org"]		"uri", "https://example.org"]
	]		]
	]		]
	}		}
	Figure 40		Figure 40
	The arrays in Figure 40 with the first member of "adr" represent		The arrays in Figure 40 with the first member of "adr" represent
	postal addresses. In the first example, the postal address is given		postal addresses. In the first example, the postal address is given
	as an array of strings and constitutes a structured address. For		as an array of strings and constitutes a structured address. For
	components of the structured address that are not applicable, an		components of the structured address that are not applicable, an
	skipping to change at page 76, line 19 ¶		skipping to change at page 81, line 44 ¶
	3. street address -- 4321 Rue Somewhere		3. street address -- 4321 Rue Somewhere
	4. locality (e.g., city) -- Quebec		4. locality (e.g., city) -- Quebec
	5. region (e.g., state or province) -- QC		5. region (e.g., state or province) -- QC
	6. postal code -- G1V 2M2		6. postal code -- G1V 2M2
	7. country name (full name) -- Canada		7. country name (full name) -- Canada
	The second example is an unstructured address. It uses the label		The second example is an unstructured address. It uses the "label"
	attribute, which is a string containing a newline (\n) character to		attribute, which is a string containing a newline (\n) character to
	separate address components in an unordered, unspecified manner.		separate address components in an unordered, unspecified manner.
	Note that in this example, the structured address array is still		Note that in this example, the structured address array is still
	given but that each string is an empty string.		given but that each string is an empty string.
	Appendix D. Secure DNS		Appendix D. Secure DNS
	Section 5.3 defines the "secureDNS" member to represent secure DNS		Section 5.3 defines the "secureDNS" member to represent secure DNS
	information about domain names.		information about domain names.
	skipping to change at page 77, line 36 ¶		skipping to change at page 83, line 16 ¶
	not a universal constant in that industry. And finally, EPP's use of		not a universal constant in that industry. And finally, EPP's use of
	XML predates the specification of JSON. If EPP had been defined		XML predates the specification of JSON. If EPP had been defined
	today, it may very well have used JSON instead of XML.		today, it may very well have used JSON instead of XML.
	Beyond the specific DNR and RIR communities, the trend in the broader		Beyond the specific DNR and RIR communities, the trend in the broader
	Internet industry is also switching to JSON over XML, especially in		Internet industry is also switching to JSON over XML, especially in
	the area of RESTful web services (see [JSON_ascendancy]). Studies		the area of RESTful web services (see [JSON_ascendancy]). Studies
	have also found that JSON is generally less bulky and consequently		have also found that JSON is generally less bulky and consequently
	faster to parse (see [JSON_performance_study]).		faster to parse (see [JSON_performance_study]).
	Acknowledgements		Acknowledgments
	This document is derived from original work on RIR responses in JSON		This document is derived from original work on RIR responses in JSON
	by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L.		by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew
	Newton. Additionally, this document incorporates work on DNR		L. Newton. Additionally, this document incorporates work on DNR
	responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean		responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean
	Shen.		Shen.
	The components of the DNR object classes are derived from a		The components of the DNR object classes are derived from a
	categorization of WHOIS response formats created by Ning Kong, Linlin		categorization of WHOIS response formats created by Ning Kong, Linlin
	Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and		Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and
	Frederico Neves.		Frederico Neves.
	Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki		Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki
	Kambe, and Maarten Bosteels contributed significant review comments		Kambe, Maarten Bosteels, Mario Loffredo, and Jasdip Singh contributed
	and provided clarifying text. James Mitchell provided text regarding		significant review comments and provided clarifying text. James
	the processing of unknown JSON attributes and identified issues		Mitchell provided text regarding the processing of unknown JSON
	leading to the remodeling of events. Ernie Dainow and Francisco		attributes and identified issues leading to the remodeling of events.
	Obispo provided concrete suggestions that led to a better variant		Ernie Dainow and Francisco Obispo provided concrete suggestions that
	model for domain names.		led to a better variant model for domain names.
	Ernie Dainow provided the background information on the secure DNS		Ernie Dainow provided the background information on the secure DNS
	attributes and objects for domains, informative text on DNSSEC, and		attributes and objects for domains, informative text on DNSSEC, and
	many other attributes that appear throughout the object classes of		many other attributes that appear throughout the object classes of
	this document.		this document.
	The switch to and incorporation of jCard was performed by Simon		The switch to and incorporation of jCard was performed by Simon
	Perreault.		Perreault.
	Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working		Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working
	group from which this document has been created.		group from which this document was originally created. James Galvin
			and Antoin Verschuren chaired the REGEXT working group that worked on
			the -bis version.
	Authors' Addresses		Changes from RFC 7483
	Andrew Lee Newton		00: Initial version ported from RFC 7483. Addressed known errata.
	American Registry for Internet Numbers
	3635 Concorde Parkway
	Chantilly, VA 20151
	United States
	EMail: andy@arin.net		Added Implementation Status section.
	URI: http://www.arin.net
			01: Updated references to 7482 to 7482bis Internet-Draft. Updated
			"Change Log" to "Changes from RFC 7483". Added APNIC
			implementation status. Adjusted case of "xxxx" used in examples
			where "XXXX" was previously used, and removed an "X" from "XXXXX".
			Changed IPv6 address example using "C00" to "c00". Added "a
			string representing" to the definitions of startAddress and
			endAddress. Removed "entity" from "Autonomous System Number
			Entity Object Class". Added "an unsigned 32-bit integer" to the
			definition of startAutnum and endAutnum. Added "a string
			representing" to the definition of name in the IP network and ASN
			object classes. Clarified rdapConformance identifier registration
			expectations in Section 4.1. Changed "lunarNic_level_0" to
			"lunarNIC_level_0". Clarified that the "value", "rel" and "href"
			JSON values MUST be specified in the "links" array. Clarified
			that the "description" array is required in the Notices and
			Remarks data structures and other values are OPTIONAL. Noted that
			all members of the "events" and "Public IDs" arrays are REQUIRED.
			Fix "self" link values in examples. Changed "http" to "https"
			link values in examples. Noted that Figure 18 is an example of a
			nameserver object with all "appropriate" values given. In
			appendix C, quoted the word "label" in "label attribute". Added
			reference to "status" definition in the descriptions for IP
			networks and autnums. Fixed a 404 for the informative reference
			to "The Stealthy Ascendancy of JSON". Added "boolean" to the
			definition of zoneSigned. Clarified REQUIRED and OPTIONAL members
			of the "events" array. Changed "SHOULD not" to "SHOULD NOT" in
			Section 5. Updated normative references (5226-8126, 5988-8288,
			7159-8259). Changed examples using "ns1.xn--fo-5ja.example" to
			split URLs to avoid long lines.
			00: Initial working group version. Added acknowledgments.
			01: Changed "The "lang" attribute may appear anywhere in an object
			class or data structure except for in jCard objects" to "The
			"lang" attribute as defined in this section MAY appear anywhere in
			an object class or data structure, except for in jCard objects.
			jCard supports similar functionality by way of the LANGUAGE
			property parameter (see Section 5.1 of RFC 6350 [RFC6350]".
			Changed "simple data types conveyed in JSON strings" to "simple
			data types conveyed in JSON primitive types (strings, numbers,
			booleans, and null)". Changed "In other words, servers are free
			to not include JSON members containing registration data based on
			their own policies" to "In other words, servers are free to omit
			unrequired/optional JSON members containing registration data
			based on their own policies". Changed "This data structure
			appears only in the topmost JSON object of a response" to "This
			data structure MUST appear in the topmost JSON object of a
			response". Changed "Some non-answer responses may return entity
			bodies with information that could be more descriptive" to "Some
			non-answer responses MAY return entity bodies with information
			that could be more descriptive". Changed "The basic structure of
			that response is an object class containing an error code number
			(corresponding to the HTTP response code) followed by a string
			named "title" and an array of strings named "description"" to "The
			basic structure of that response is an object class containing a
			REQUIRED error code number (corresponding to the HTTP response
			code) followed by an OPTIONAL string named "title" and an OPTIONAL
			array of strings named "description"". Changed the "Autonomous
			System Number Object Class" section title to "The Autonomous
			System Number Object Class" for consistency with other section
			titles. Removed trailing periods in the "Terminology and
			Definitions" section for consistency. Changed instances of
			"lunarNic" to "lunarNIC" for consistency. Removed an extraneous
			trailing period after the eventDate description. Changed a "." to
			";" in the description of the "network" member of the domain
			object class. Changed "The high-level structure of the autnum
			object class consists of information about the network
			registration" to "The high-level structure of the autnum object
			class consists of information about the autonomous system number
			registration". Changed "registry unique" to "registry-unique".
			02: Changed "registrant" to "registrar" in the description of the
			"transfer" event action to address erratum 6158. Added IANA
			instructions to correct the description of the value in the
			registry. Added text to Section 4.2 to note that "self" and
			"related" "href" URIs MUST NOT be the same. Added text to
			Section 4.2 to describe return of IDNs in LDH name format.
			03: Added text to note that the "fn" member of a contact object MAY
			be empty in Section 3.
			04: Added text to clarify rdapConformance requirements in
			Section 4.1.
			05: Added "obsoletes 7483" to the headers, Abstract, and
			Introduction. Updated BCP14 template. Updated IANA
			Considerations to note that this new RFC (a product of the REGEXT
			working group) replaces 7483. Changed "simple string" to "simple
			character string" in Sections 3 and 4.7. Clarified requirement
			for the "fn" member in Section 3. Modified the requirement for
			rdapConformance placement in Section 4.1. Changed "jCard" to
			"vCard" LANGUAGE property reference in Section 4.4. Changed "no
			use" to "little or no use" in Section 5.1. Added example line
			wrap note in Section 5.2. Modified the definition of "idnTable"
			in Section 5.3. Modified the dsData and keyData examples in
			Section 5.3. Changed "2001:c00::/23" to "2001:db8::/32" in
			Section 5.4. Expanded the definition of "type" in Sections 5.4
			and 5.5. Modified example autnums in Section 5.5. Added text to
			the Security Considerations section to note that DNSSEC
			information returned in a response can not be trusted directly.
			Authors' Addresses
	Scott Hollenbeck		Scott Hollenbeck
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	United States		United States
	EMail: shollenbeck@verisign.com		Email: shollenbeck@verisign.com
	URI: http://www.verisignlabs.com/		URI: https://www.verisignlabs.com/
			Andy Newton
			Amazon Web Services, Inc.
			13200 Woodland Park Road
			Herndon, VA 20171
			United States of America
			Email: andy@hxr.us
End of changes. 477 change blocks.
	572 lines changed or deleted		1057 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/