draft-ietf-regext-rdap-redacted-01.txt		draft-ietf-regext-rdap-redacted-02.txt
	Network Working Group J.G. Gould		Network Working Group J.G. Gould
	Internet-Draft D.S. Smith		Internet-Draft D.S. Smith
	Intended status: Standards Track VeriSign, Inc.		Intended status: Standards Track VeriSign, Inc.
	Expires: 5 March 2022 J.K. Kolker		Expires: 22 May 2022 J.K. Kolker
	R.C. Carney		R.C. Carney
	GoDaddy Inc.		GoDaddy Inc.
	1 September 2021		18 November 2021
	Redacted Fields in the Registration Data Access Protocol (RDAP) Response		Redacted Fields in the Registration Data Access Protocol (RDAP) Response
	draft-ietf-regext-rdap-redacted-01		draft-ietf-regext-rdap-redacted-02
	Abstract		Abstract
	This document describes an RDAP extension for explicitly identifying		This document describes an RDAP extension for explicitly identifying
	redacted RDAP lookup response fields, using JSONPath as the default		redacted RDAP response fields, using JSONPath as the default
	expression language.		expression language.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 5 March 2022.		This Internet-Draft will expire on 22 May 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Redaction Methods . . . . . . . . . . . . . . . . . . . . . . 3		3. Redaction Methods . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Redaction by Removal Method . . . . . . . . . . . . . . . 4		3.1. Redaction by Removal Method . . . . . . . . . . . . . . . 4
	3.2. Redaction by Empty Value Method . . . . . . . . . . . . . 4		3.2. Redaction by Empty Value Method . . . . . . . . . . . . . 4
	4. Redacted RDAP Response . . . . . . . . . . . . . . . . . . . 5		4. Redacted RDAP Response . . . . . . . . . . . . . . . . . . . 5
	4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 5		4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 5
	4.2. "redacted" Member . . . . . . . . . . . . . . . . . . . . 6		4.2. "redacted" Member . . . . . . . . . . . . . . . . . . . . 6
	5. JSONPath Considerations . . . . . . . . . . . . . . . . . . . 22		5. JSONPath Considerations . . . . . . . . . . . . . . . . . . . 24
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 23		6.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 25
	6.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 24		6.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	9.1. Informative References . . . . . . . . . . . . . . . . . 24		9.1. Informative References . . . . . . . . . . . . . . . . . 26
	9.2. Normative References . . . . . . . . . . . . . . . . . . 24		9.2. Normative References . . . . . . . . . . . . . . . . . . 26
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26		Appendix A. Change History . . . . . . . . . . . . . . . . . . . 27
	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26		A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	This document describes an RDAP extension for explicitly identifying		This document describes an RDAP extension for explicitly identifying
	redacted RDAP lookup response fields, using JSONPath as the default		redacted RDAP response fields, using JSONPath as the default
	expression language. A redacted RDAP field is one that has data		expression language. A redacted RDAP field is one that has data
	removed from the RDAP lookup response due to the lack of client		removed from the RDAP response due to the lack of client privilege to
	privilege to receive the field. This extension can be used to		receive the field. This extension can be used to identify redacted
	identify redacted RDAP fields in any RDAP object class, as defined in		RDAP fields in any RDAP object class, as defined in [RFC7483], or
	[RFC7483], or RDAP fields defined in RDAP extensions. Because an		RDAP fields defined in RDAP extensions. Because an RDAP response may
	RDAP lookup response may exclude a field due to either the lack of		exclude a field due to either the lack of data or based on the lack
	data or based on the lack of RDAP client privileges, this extension		of RDAP client privileges, this extension is used to explicitly
	is used to explicitly specify which RDAP fields are not included in		specify which RDAP fields are not included in the RDAP response due
	the RDAP lookup response due to redaction. It thereby provides a		to redaction. It thereby provides a capability for disambiguation
	capability for disambiguation between redaction and possible other		between redaction and possible other reasons for data or field
	reasons for data or field absence.		absence.
	In [RFC7482] RDAP supports both lookup and search queries, where a		In [RFC7482] RDAP supports both lookup and search queries, where a
	lookup query responds with a single object and a search query		lookup query responds with a single object and a search query
	responds with a list of objects. This document applies to redaction		responds with a list of objects. This document applies to redaction
	of a single object in a lookup response.		of a single object of a lookup response and in each of the objects of
			a search response.
	JSONPath, as defined in [I-D.ietf-jsonpath-base], is used as the		JSONPath, as defined in [I-D.ietf-jsonpath-base], is used as the
	default expression language to reference RDAP fields that have been		default expression language to reference RDAP fields that have been
	redacted. The redacted JSON fields will either be removed or have		redacted. The redacted JSON fields will either be removed or have
	empty values in the RDAP lookup response. JSON is defined by		empty values in the RDAP response. JSON is defined by [RFC8259].
	[RFC8259].
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The JSON examples include extra line breaks and whitespace. For		The JSON examples include extra line breaks and whitespace. For
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶
	"reason": {		"reason": {
	"type": "Server policy"		"type": "Server policy"
	}		}
	}		}
	]		]
	4. Redacted RDAP Response		4. Redacted RDAP Response
	4.1. RDAP Conformance		4.1. RDAP Conformance
	RDAP lookup responses that contain values described in this document		RDAP responses that contain values described in this document MUST
	MUST indicate conformance with this specification by including an		indicate conformance with this specification by including an
	rdapConformance ([RFC7483]) value of "redacted_0.1". The information		rdapConformance ([RFC7483]) value of "redacted_0.1". The information
	needed to register this value in the RDAP Extensions Registry is		needed to register this value in the RDAP Extensions Registry is
	described in Section 6.1.		described in Section 6.1.
	Example rdapConformance member with the redacted extension:		Example rdapConformance member with the redacted extension:
	"rdapConformance": [		"rdapConformance": [
	"rdap_level_0",		"rdap_level_0",
	"redacted_0"		"redacted_0"
	]		]
	4.2. "redacted" Member		4.2. "redacted" Member
	The "redacted" member MUST be added to the RDAP lookup response when		The "redacted" member MUST be added to the RDAP response when there
	there are redacted fields. The "redacted" member contains an array		are redacted fields. The "redacted" member is included as a member
	of redacted objects with the following child members:		of the object class in a lookup response, such as the object classes
			defined in [RFC9083], and as a member of the object instances in a
			search response, such as the object instances defined in [RFC9083].
			The "redacted" member contains an array of redacted objects with the
			following child members:
	"name": A logical name for the redacted field. The logical name		"name": A logical name for the redacted field. The logical name
	used for the redacted field is up to server policy. The logical		used for the redacted field is up to server policy. The logical
	name is defined using an object with a "type" field denoting a		name is defined using an object with a "type" field denoting a
	registered redacted name (see Section 6.2) or a "description"		registered redacted name (see Section 6.2) or a "description"
	field denoting an unregistered redacted name. The registered		field denoting an unregistered redacted name. The registered
	redacted names and the chosen unregistered names can meet the		redacted names and the chosen unregistered names can meet the
	needs of different RDAP services or industries.		needs of different RDAP services or industries.
	"path": The JSON expression of the redacted field, using the		"path": The JSON expression of the redacted field, using the
	skipping to change at page 6, line 48 ¶		skipping to change at page 6, line 52 ¶
	"reason": OPTIONAL human readable reason(s) for the redacted field		"reason": OPTIONAL human readable reason(s) for the redacted field
	in the language defined by the [RFC7483] "lang" member. The		in the language defined by the [RFC7483] "lang" member. The
	default language is "en" if the [RFC7483] "lang" member is not		default language is "en" if the [RFC7483] "lang" member is not
	specified. The reason is defined using an object with an		specified. The reason is defined using an object with an
	OPTIONAL "type" field denoting a registered redacted reason (see		OPTIONAL "type" field denoting a registered redacted reason (see
	see Section 6.2) and an OPTIONAL "description" field denoting an		see Section 6.2) and an OPTIONAL "description" field denoting an
	unregistered redacted reason. The "description" field MUST NOT		unregistered redacted reason. The "description" field MUST NOT
	be a client processing dependency.		be a client processing dependency.
	Example unredacted version of RDAP lookup response:		Example unredacted version of an RDAP lookup response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_level_0"		"rdap_level_0"
	],		],
	"objectClassName": "domain",		"objectClassName": "domain",
	"handle": "ABC123",		"handle": "ABC123",
	"ldhName": "example.com",		"ldhName": "example.com",
	"secureDNS": {		"secureDNS": {
	"delegationSigned": false		"delegationSigned": false
	},		},
	"notices": [
	{
	"title": "Terms of Use",
	"description": [
	"Service subject to Terms of Use."
	],
	"links": [
	{
	"rel": "self",
	"href": "https://www.example.com/terms-of-use",
	"type": "text/html",
	"value": "https://www.example.com/terms-of-use"
	}
	]
	}
	],
	"nameservers": [		"nameservers": [
	{		{
	"objectClassName": "nameserver",		"objectClassName": "nameserver",
	"ldhName": "ns1.example.com"		"ldhName": "ns1.example.com"
	},		},
	{		{
	"objectClassName": "nameserver",		"objectClassName": "nameserver",
	"ldhName": "ns2.example.com"		"ldhName": "ns2.example.com"
	}		}
	],		],
	skipping to change at page 14, line 25 ¶		skipping to change at page 14, line 9 ¶
	}		}
	],		],
	"status": [		"status": [
	"server delete prohibited",		"server delete prohibited",
	"server update prohibited",		"server update prohibited",
	"server transfer prohibited",		"server transfer prohibited",
	"client transfer prohibited"		"client transfer prohibited"
	]		]
	}		}
	Example redacted version of RDAP response:		Example redacted version of an RDAP lookup response:
	{		{
	"rdapConformance": [		"rdapConformance": [
	"rdap_level_0",		"rdap_level_0",
	"redacted_0"		"redacted_0"
	],		],
	"objectClassName": "domain",		"objectClassName": "domain",
	"ldhName": "example.com",		"ldhName": "example.com",
	"secureDNS": {		"secureDNS": {
	"delegationSigned": false		"delegationSigned": false
	},		},
	"notices": [
	{
	"title": "Terms of Use",
	"description": [
	"Service subject to Terms of Use."
	],
	"links": [
	{
	"rel": "self",
	"href": "https://www.example.com/terms-of-use",
	"type": "text/html",
	"value": "https://www.example.com/terms-of-use"
	}
	]
	}
	],
	"nameservers": [		"nameservers": [
	{		{
	"objectClassName": "nameserver",		"objectClassName": "nameserver",
	"ldhName": "ns1.example.com"		"ldhName": "ns1.example.com"
	},		},
	{		{
	"objectClassName": "nameserver",		"objectClassName": "nameserver",
	"ldhName": "ns2.example.com"		"ldhName": "ns2.example.com"
	}		}
	],		],
	skipping to change at page 22, line 35 ¶		skipping to change at page 21, line 52 ¶
	},		},
	"path": "$.entities[?(@.roles[0]=='administrative')]",		"path": "$.entities[?(@.roles[0]=='administrative')]",
	"method": "removal",		"method": "removal",
	"reason": {		"reason": {
	"description": "Refer to the technical contact"		"description": "Refer to the technical contact"
	}		}
	}		}
	]		]
	}		}
			Example unredacted version of an RDAP search response:
			{
			"rdapConformance": [
			"rdap_level_0"
			],
			"domainSearchResults":[
			{
			"objectClassName": "domain",
			"handle": "ABC121",
			"ldhName": "example1.com",
			"links":[
			{
			"value":"https://example.com/rdap/domain/example1.com",
			"rel":"self",
			"href":"https://example.com/rdap/domain/example1.com",
			"type":"application/rdap+json"
			},
			{
			"value":"https://example.com/rdap/domain/example1.com",
			"rel":"related",
			"href":"https://example.com/rdap/domain/example1.com",
			"type":"application/rdap+json"
			}
			]
			},
			{
			"objectClassName": "domain",
			"handle": "ABC122",
			"ldhName": "example2.com",
			"links":[
			{
			"value":"https://example.com/rdap/domain/example2.com",
			"rel":"self",
			"href":"https://example.com/rdap/domain/example2.com",
			"type":"application/rdap+json"
			},
			{
			"value":"https://example.com/rdap/domain/example2.com",
			"rel":"related",
			"href":"https://example.com/rdap/domain/example2.com",
			"type":"application/rdap+json"
			}
			]
			}
			]
			}
			Example redacted version of an RDAP search response:
			{
			"rdapConformance": [
			"rdap_level_0",
			"redacted_0"
			],
			"domainSearchResults":[
			{
			"objectClassName": "domain",
			"ldhName": "example1.com",
			"links":[
			{
			"value":"https://example.com/rdap/domain/example1.com",
			"rel":"self",
			"href":"https://example.com/rdap/domain/example1.com",
			"type":"application/rdap+json"
			},
			{
			"value":"https://example.com/rdap/domain/example1.com",
			"rel":"related",
			"href":"https://example.com/rdap/domain/example1.com",
			"type":"application/rdap+json"
			}
			],
			"redacted": [
			{
			"name": {
			"type": "Registry Domain ID"
			},
			"path": "$.domainSearchResults[0].handle",
			"pathLang": "jsonpath",
			"method": "removal",
			"reason": {
			"type": "Server policy"
			}
			}
			]
			},
			{
			"objectClassName": "domain",
			"ldhName": "example2.com",
			"links":[
			{
			"value":"https://example.com/rdap/domain/example2.com",
			"rel":"self",
			"href":"https://example.com/rdap/domain/example2.com",
			"type":"application/rdap+json"
			},
			{
			"value":"https://example.com/rdap/domain/example2.com",
			"rel":"related",
			"href":"https://example.com/rdap/domain/example2.com",
			"type":"application/rdap+json"
			}
			],
			"redacted": [
			{
			"name": {
			"type": "Registry Domain ID"
			},
			"path": "$.domainSearchResults[1].handle",
			"pathLang": "jsonpath",
			"method": "removal",
			"reason": {
			"type": "Server policy"
			}
			}
			]
			}
			]
			}
	5. JSONPath Considerations		5. JSONPath Considerations
	JSONPath [I-D.ietf-jsonpath-base] is the default JSON path expression		JSONPath [I-D.ietf-jsonpath-base] is the default JSON path expression
	language. This section covers considerations for servers using		language. This section covers considerations for servers using
	[I-D.ietf-jsonpath-base] to identify redacted RDAP fields with the		[I-D.ietf-jsonpath-base] to identify redacted RDAP fields with the
	"path" member of redacted objects in the "redacted" member. The list		"path" member of redacted objects in the "redacted" member. The list
	of JSONPath considerations include:		of JSONPath considerations include:
	1. Use absolute paths with the '$' JSONPath element. An example is		1. Use absolute paths with the '$' JSONPath element. An example is
	"$.handle" for the "Registry Domain ID".		"$.handle" for the "Registry Domain ID" in a lookup response or
	2. Validate a JSONPath expression using a non-redacted RDAP lookup		"$.domainSearchResults[0].handle" in a search response.
			2. Validate a JSONPath expression using a non-redacted RDAP
	response, where evaluating the expression results in returning		response, where evaluating the expression results in returning
	the redacted field.		the redacted field.
	3. Reference the removed object field when redacting an entire		3. Reference the removed object field when redacting an entire
	object by the Redaction by Removal Method (Section 3.1), where		object by the Redaction by Removal Method (Section 3.1), where
	all of the object's child fields are explicitly removed. An		all of the object's child fields are explicitly removed. An
	example is "$.entities[?(@.roles[0]=='administrative')]" for the		example is "$.entities[?(@.roles[0]=='administrative')]" for the
	entire "Administrative Contact".		entire "Administrative Contact".
	4. When an entity has multiple roles, include "redacted" members for		4. When an entity has multiple roles, include "redacted" members for
	each role using the role index. This will result in duplicate		each role using the role index. This will result in duplicate
	"redacted" members, but will enable the client to treat redaction		"redacted" members, but will enable the client to treat redaction
	consistently when there is a single role per entity or multiple		consistently when there is a single role per entity or multiple
	roles per entity. An example is when the "roles" member has the		roles per entity. An example is when the "roles" member has the
	skipping to change at page 24, line 10 ¶		skipping to change at page 25, line 47 ¶
	6.1. RDAP Extensions Registry		6.1. RDAP Extensions Registry
	IANA is requested to register the following value in the RDAP		IANA is requested to register the following value in the RDAP
	Extensions Registry:		Extensions Registry:
	Extension identifier: redacted_0.1		Extension identifier: redacted_0.1
	Registry operator: Any		Registry operator: Any
	Published specification: This document.		Published specification: This document.
	Contact: IESG <iesg@ietf.org>		Contact: IESG <iesg@ietf.org>
	Intended usage: This extension identifies the redacted fields in an		Intended usage: This extension identifies the redacted fields in an
	RDAP lookup response.		RDAP response.
	6.2. JSON Values Registry		6.2. JSON Values Registry
	Section 10.2 of [RFC9083] defines the JSON Values Registry with pre-		Section 10.2 of [RFC9083] defines the JSON Values Registry with pre-
	defined Type field values and the use of the "Expert Review" policy		defined Type field values and the use of the "Expert Review" policy
	defined in [RFC8126]. Two new JSON Values Registry Type field values		defined in [RFC8126]. Two new JSON Values Registry Type field values
	are used to register pre-defined redacted name and reason values:		are used to register pre-defined redacted name and reason values:
	"redacted name": Redacted name being registered. The registered		"redacted name": Redacted name being registered. The registered
	redacted name is referenced using the "type" field of the		redacted name is referenced using the "type" field of the
	skipping to change at page 24, line 48 ¶		skipping to change at page 26, line 41 ¶
	Gustavo Lozano, and Rick Wilhelm.		Gustavo Lozano, and Rick Wilhelm.
	9. References		9. References
	9.1. Informative References		9.1. Informative References
	[I-D.ietf-regext-rdap-jscontact]		[I-D.ietf-regext-rdap-jscontact]
	Loffredo, M. and G. Brown, "Using JSContact in		Loffredo, M. and G. Brown, "Using JSContact in
	Registration Data Access Protocol (RDAP) JSON Responses",		Registration Data Access Protocol (RDAP) JSON Responses",
	Work in Progress, Internet-Draft, draft-ietf-regext-rdap-		Work in Progress, Internet-Draft, draft-ietf-regext-rdap-
	jscontact-02, 28 May 2021, <https://tools.ietf.org/html/		jscontact-03, 22 October 2021,
	draft-ietf-regext-rdap-jscontact-02>.		<https://tools.ietf.org/html/draft-ietf-regext-rdap-
			jscontact-03>.
	9.2. Normative References		9.2. Normative References
	[I-D.ietf-jsonpath-base]		[I-D.ietf-jsonpath-base]
	Gössner, S., Normington, G., and C. Bormann, "JSONPath:		Gössner, S., Normington, G., and C. Bormann, "JSONPath:
	Query expressions for JSON", Work in Progress, Internet-		Query expressions for JSON", Work in Progress, Internet-
	Draft, draft-ietf-jsonpath-base-01, 8 July 2021,		Draft, draft-ietf-jsonpath-base-02, 25 October 2021,
	<https://tools.ietf.org/html/draft-ietf-jsonpath-base-01>.		<https://tools.ietf.org/html/draft-ietf-jsonpath-base-02>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,		[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
	DOI 10.17487/RFC6350, August 2011,		DOI 10.17487/RFC6350, August 2011,
	<https://www.rfc-editor.org/info/rfc6350>.		<https://www.rfc-editor.org/info/rfc6350>.
	skipping to change at page 26, line 46 ¶		skipping to change at page 28, line 41 ¶
	redaction names by changing the "reason" property to be a		redaction names by changing the "reason" property to be a
	JSON object with the "type" and "description" properties.		JSON object with the "type" and "description" properties.
	The "type" property includes registration in the IANA JSON		The "type" property includes registration in the IANA JSON
	Values Registry.		Values Registry.
	2. Added a "JSON Values Registry" section in the IANA		2. Added a "JSON Values Registry" section in the IANA
	Considersations section to define the "redaction name" JSON		Considersations section to define the "redaction name" JSON
	Values Registry Type values to support the registration of		Values Registry Type values to support the registration of
	redaction names.		redaction names.
	3. Added a JSONPath Considerations item associated with handling		3. Added a JSONPath Considerations item associated with handling
	entities with multiple roles.		entities with multiple roles.
	4. Added language to restrict the extension to lookup responses.		4. Added language to restrict the extension to responses.
			A.2. Change from 01 to 02
			1. Updates to add support for RDAP search responses:
			1. Replaced "RDAP lookup response" with "RDAP response"
			throughout the draft to expand the scope to include search.
			2. Updated the description in the second paragraph of the
			Introduction to cover both a lookup response and a search
			response.
			3. Added an example of the use of an absoluate path for a search
			response to the "JSONPath Considerations" section.
			4. Added a description of the placement of the "redacted" member
			in a lookup response and a search response in the ""redacted"
			Member" section.
			5. Added an example of an unredacted search response and a
			redacted search response in the ""redacted" Member" section.
	Authors' Addresses		Authors' Addresses
	James Gould		James Gould
	VeriSign, Inc.		VeriSign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	United States of America		United States of America
	Email: jgould@verisign.com		Email: jgould@verisign.com
End of changes. 23 change blocks.
	80 lines changed or deleted		191 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/