Diff: rfc9537.original.xml

	rfc9537.original.xml	rfc9537.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [	<!-- FYI: We note that this XML file was submitted
	<!-- One method to get references from the online citation libraries.	in "prepped" format. We have "unprepped" the file to make
	There has to be one entity for each item to be referenced.	editing the document easier. Note that this does not impact
	An alternate method (rfc include) is described in the references. -->	the document text but does cause many changes to the XML code. -->
	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.2119.xml">	<!DOCTYPE rfc [
	<!ENTITY RFC6350 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r	<!ENTITY nbsp " ">
	eference.RFC.6350.xml">	<!ENTITY zwsp "">
	<!ENTITY RFC7095 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r	<!ENTITY nbhy "‑">
	eference.RFC.7095.xml">	<!ENTITY wj "⁠">
	<!ENTITY RFC7942 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.7942.xml">
	<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.8126.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.8174.xml">
	<!ENTITY RFC8259 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.8259.xml">
	<!ENTITY RFC8605 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.8605.xml">
	<!ENTITY RFC9082 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.9082.xml">
	<!ENTITY RFC9083 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
	eference.RFC.9083.xml">
	<!ENTITY I-D.ietf-regext-rdap-jscontact PUBLIC ''
	'https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-re
	gext-rdap-jscontact.xml'>
	<!ENTITY I-D.ietf-jsonpath-base PUBLIC ''
	'https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-js
	onpath-base.xml'>
	]>	]>

	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	<?rfc tocdepth="4"?>	category="std"
	<?rfc compact="yes"?>	consensus="true"
	<?rfc subcompact="no"?>	docName="draft-ietf-regext-rdap-redacted-16"
	<?rfc sortrefs="yes"?>	number="9537"
	<?rfc symrefs="yes"?>	ipr="trust200902"
	<?rfc iprnotified="no"?>	obsoletes=""
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"	updates=""
	docName="draft-ietf-regext-rdap-redacted-16" ipr="trust200902" obsoletes="" upda	submissionType="IETF"
	tes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" sortRe	xml:lang="en"
	fs="true" symRefs="true" version="3">	tocInclude="true"
		tocDepth="4"
		sortRefs="true"
		symRefs="true"
		version="3">

	<front>	<front>
	<title abbrev="Redacted Fields in RDAP">Redacted Fields in the Registration Data Access Protocol	<title abbrev="Redacted Fields in RDAP">Redacted Fields in the Registration Data Access Protocol
	(RDAP) Response</title>	(RDAP) Response</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-regext-rdap-redacted-16"	<seriesInfo name="RFC" value="9537"/>
	/>	<author fullname="James Gould" initials="J." surname="Gould">
	<author fullname="James Gould" initials="J.G" surname="Gould">
	<organization>VeriSign, Inc.</organization>	<organization>VeriSign, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>
	<city>Reston</city>	<city>Reston</city>
	<region>VA</region>	<region>VA</region>
	<code>20190</code>	<code>20190</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jgould@verisign.com</email>	<email>jgould@verisign.com</email>
	<uri>http://www.verisigninc.com</uri>	<uri>http://www.verisigninc.com</uri>
	</address>	</address>
	</author>	</author>

	<author fullname="David Smith" initials="D.S" surname="Smith">	<author fullname="David Smith" initials="D." surname="Smith">
	<organization>VeriSign, Inc.</organization>	<organization>VeriSign, Inc.</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>
	<city>Reston</city>	<city>Reston</city>
	<region>VA</region>	<region>VA</region>
	<code>20190</code>	<code>20190</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>dsmith@verisign.com</email>	<email>dsmith@verisign.com</email>
	<uri>http://www.verisigninc.com</uri>	<uri>http://www.verisigninc.com</uri>
	</address>	</address>
	</author>	</author>

	<author fullname="Jody Kolker" initials="J.K" surname="Kolker">	<author fullname="Jody Kolker" initials="J." surname="Kolker">
	<organization>GoDaddy Inc.</organization>	<organization>GoDaddy Inc.</organization>
	<address>	<address>
	<postal>	<postal>

	<street>14455 N. Hayden Rd. #219</street>	<street>14455 N. Hayden Rd., #219</street>
	<city>Scottsdale</city>	<city>Scottsdale</city>
	<region>AZ</region>	<region>AZ</region>
	<code>85260</code>	<code>85260</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>jkolker@godaddy.com</email>	<email>jkolker@godaddy.com</email>
	<uri>http://www.godaddy.com</uri>	<uri>http://www.godaddy.com</uri>
	</address>	</address>
	</author>	</author>

	<author fullname="Roger Carney" initials="R.C" surname="Carney">	<author fullname="Roger Carney" initials="R." surname="Carney">
	<organization>GoDaddy Inc.</organization>	<organization>GoDaddy Inc.</organization>
	<address>	<address>
	<postal>	<postal>

	<street>14455 N. Hayden Rd. #219</street>	<street>14455 N. Hayden Rd., #219</street>
	<city>Scottsdale</city>	<city>Scottsdale</city>
	<region>AZ</region>	<region>AZ</region>
	<code>85260</code>	<code>85260</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>rcarney@godaddy.com</email>	<email>rcarney@godaddy.com</email>
	<uri>http://www.godaddy.com</uri>	<uri>http://www.godaddy.com</uri>
	</address>	</address>
	</author>	</author>

		<date year="2024" month="March"/>
		<area>art</area>
		<workgroup>regext</workgroup>

	<keyword>Redacted</keyword>	<keyword>Redacted</keyword>
	<keyword>Redaction</keyword>	<keyword>Redaction</keyword>
	<keyword>Redacting</keyword>	<keyword>Redacting</keyword>
	<keyword>JSONPath</keyword>	<keyword>JSONPath</keyword>


	<abstract>	<abstract>

	<t>This document describes an RDAP extension for specifying methods of	<t>This document describes a Registration Data Access
		Protocol (RDAP) extension for specifying methods of
	redaction of RDAP responses and explicitly identifying redacted RDAP	redaction of RDAP responses and explicitly identifying redacted RDAP
	response fields, using JSONPath as the default expression language.</t>	response fields, using JSONPath as the default expression language.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<section numbered="true" toc="default">	<section>
	<name>Introduction</name>	<name>Introduction</name>
	<t>This document describes an RDAP extension for specifying methods of	<t>This document describes an RDAP extension for specifying methods of
	redaction of RDAP responses and explicitly identifying redacted RDAP	redaction of RDAP responses and explicitly identifying redacted RDAP
	response fields, using JSONPath as the default expression language. A red acted RDAP field is one that has data	response fields, using JSONPath as the default expression language. A red acted RDAP field is one that has data
	removed or replaced in the RDAP response due to server policy, such as t he lack of client privilege to	removed or replaced in the RDAP response due to server policy, such as t he lack of client privilege to
	receive the field. This extension can be used to identify	receive the field. This extension can be used to identify

	redacted RDAP fields in any RDAP object class, as defined in <xref target= "RFC9083" format="default"/>, or	redacted RDAP fields in any RDAP object class, as defined in <xref target= "RFC9083"/>, or
	RDAP fields defined in RDAP extensions. Because an RDAP response may excl ude a field due to either the lack of data	RDAP fields defined in RDAP extensions. Because an RDAP response may excl ude a field due to either the lack of data

	or based on the lack of RDAP client privileges,	or the lack of RDAP client privileges,
	this extension is used to explicitly specify which RDAP fields are not inc luded in the RDAP response due	this extension is used to explicitly specify which RDAP fields are not inc luded in the RDAP response due
	to redaction. It thereby provides a capability for disambiguation	to redaction. It thereby provides a capability for disambiguation

	between redaction and possible other reasons for data or field absence.</t	between redaction and other possible reasons for data or field absence.</t
	>	>
	<t>In <xref target="RFC9082" format="default"/> RDAP supports both looku	<t>In <xref target="RFC9082"/>, RDAP supports both lookup and search queri
	p and search queries, where a lookup query responds	es, where a lookup query responds
	with a single object and a search query responds with a list of objects.	with a single object and a search query responds with a list of objects.
	This document applies to redaction of a single object of a lookup respon se and in each of the objects of a search response.</t>	This document applies to redaction of a single object of a lookup respon se and in each of the objects of a search response.</t>

	<t>JSONPath, as defined in <xref target="I-D.ietf-jsonpath-base" format="d efault"/>, is used	<t>JSONPath, as defined in <xref target="RFC9535"/>, is used
	as the default expression language to reference RDAP fields that have been redacted.	as the default expression language to reference RDAP fields that have been redacted.

	The redacted JSON fields will either be removed, have empty values, have p	The redacted JSON fields will be removed, have empty values, have partial
	artial values, or be replaced in the RDAP response.	values, or be replaced in the RDAP response.
	JSON is defined by <xref target="RFC8259" format="default"/>.</t>	JSON is defined by <xref target="RFC8259"/>.</t>
	</section>	</section>

	<section numbered="true" toc="default">	<section>
	<name>Conventions Used in This Document</name>	<name>Conventions Used in This Document</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	"MAY", and "OPTIONAL" in this document are to be interpreted as	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119" format="default"/> <xref target	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	="RFC8174" format="default"/>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	when, and only when, they	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	appear in all capitals, as shown here.</t>	be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>
	<t>The JSON examples include extra line breaks and whitespace. For	<t>The JSON examples include extra line breaks and whitespace. For
	instance, the JSONPath expressions are broken out into multiple	instance, the JSONPath expressions are broken out into multiple

	lines when required for illustration.</t>	lines when required for illustration.</t>
	<t>The JSONPath expressions in the examples are for illustration purposes
	with single-role entities and the exact expressions to use by the server is out-	<!--[rfced] To clarify the second half of the sentence below, may we update
	of-scope.</t>	it as follows?

		Original:
		The JSONPath expressions in the examples are for illustration
		purposes with single-role entities and the exact expressions to use
		by the server is out-of-scope.

		Perhaps:
		The JSONPath expressions in the examples are for illustration
		purposes with single-role entities, and the exact expressions to be used
		by the server are out of scope.
		-->

		<t>The JSONPath expressions in the examples are for illustration purposes
		with single-role entities, and the exact expressions to use by the server is out
		of scope.</t>
	</section>	</section>

	<section anchor="redaction-methods" numbered="true" toc="default">	<section anchor="redaction-methods">
	<name>Redaction Methods</name>	<name>Redaction Methods</name>

	<t>Redaction in RDAP can be handled in multiple ways. Redaction in RDAP c	<t>Redaction in RDAP can be handled in multiple ways. The resulting redact
	an be handled in multiple ways. The resulting redacted RDAP response MUST comply	ed RDAP response <bcp14>MUST</bcp14> comply with the format defined in the RDAP
	with the format defined in the RDAP RFCs with the RDAP RFCs, such as <xref targ	RFCs, such as <xref target="RFC9083"/> and updates.
	et="RFC9083" format="default"/> and updates.	The use of placeholder text for the values of the RDAP fields, such as "XX
	The use of placeholder text for the values of the RDAP fields, such as the	XX",
	placeholder text "XXXX",	<bcp14>MUST NOT</bcp14> be used for redaction, since the placeholder text
	MUST NOT be used for redaction, since the placeholder text value may not m	value may not match the format requirements of each of the RDAP fields, which co
	atch the format requirements of each of the RDAP fields and provides an inconsis	uld provide an inconsistent and unreliable redaction signal.
	tent and unreliable redaction signal.
	This section covers the redaction	This section covers the redaction

	methods that can be used with the redaction signaling defined in <xref t	methods that can be used with the redaction signaling defined in <xref t
	arget="redacted-member" format="default"/>.</t>	arget="redacted-member"/>.</t>
	<t>RDAP responses, as defined in <xref target="RFC9083" format="default"/>	<t>RDAP responses, as defined in <xref target="RFC9083"/>, include
	, include	a mix of JSON objects and JSON arrays, where JSON arrays are heavily used
	a mix of JSON objects and JSON arrays, where JSON arrays are heavily used	for entity objects with <xref target="RFC7095">jCard</xref>.
	for entity objects with <xref target="RFC7095" format="default">jCard</xref>.	<xref target="RFC7095">jCard</xref> is a JSON representation of <xref targ
	<xref target="RFC7095" format="default">jCard</xref> is a JSON representat	et="RFC6350">vCard</xref> that
	ion of <xref target="RFC6350" format="default">vCard</xref> that	inherits its dependency on arrays.
	inherits its dependency on arrays. An example is the <xref target="RFC635
	0" format="default">vCard</xref> "ADR" property / <xref target="RFC7095" format=	<!--[rfced] May we reorder the references in this sentence for easier
	"default">jCard</xref> "adr" property	readability as shown below?
	that defines a sequence of address components. According to <xref target=
	"RFC6350" format="default"/>, when an "ADR" property component value is missing,	Original:
	the associated component separator MUST still be specified.	An example is the vCard [RFC6350] "ADR" property / jCard [RFC7095]
	<xref target="RFC7095" format="default">jCard</xref> extends the use of ar	"adr" property that defines a sequence of address components.
	rays with
		Perhaps:
		An example is the vCard "ADR" property [RFC6350], or the jCard
		"adr" property [RFC7095], which defines a sequence of
		address components.
		-->

		An example is the <xref target="RFC6350">vCard</xref> "ADR" property / <xr
		ef target="RFC7095">jCard</xref> "adr" property,
		which defines a sequence of address components. According to <xref target
		="RFC6350"/>, when an "ADR" property component value is missing,
		the associated component separator <bcp14>MUST</bcp14> still be specified.
		<xref target="RFC7095">jCard</xref> extends the use of arrays with
	each individual vCard property being represented by an array of three fixe d elements, followed by one or more additional elements.	each individual vCard property being represented by an array of three fixe d elements, followed by one or more additional elements.
	The mix of JSON objects and JSON arrays impacts the methods used for redac tion in RDAP.</t>	The mix of JSON objects and JSON arrays impacts the methods used for redac tion in RDAP.</t>

	<t>The redaction of RDAP fields fall into the four categories defined in t	<t>The redaction of RDAP fields fall into the four categories defined in t
	he following sub-sections.</t>	he following subsections.</t>
	<section anchor="redaction-removal" numbered="true" toc="default">	<section anchor="redaction-removal">
	<name>Redaction by Removal Method</name>	<name>Redaction by Removal Method</name>
	<t>The Redaction by Removal Method is when the RDAP field is removed fro m the RDAP response, which is the default method.	<t>The Redaction by Removal Method is when the RDAP field is removed fro m the RDAP response, which is the default method.

	The Redaction by Removal Method can be done for all RDAP response fields	The Redaction by Removal Method can be done for all RDAP response fields
	other than response fields using the position in an array to signal the redacte	except for response fields using the position in an array to signal the redacte
	d field (e.g., the JSON arrays used with <xref target="RFC7095" format="default"	d field (e.g., the JSON arrays used with <xref target="RFC7095">jCard</xref>).
	>jCard</xref>).	RDAP extensions, such as the one described in <xref target="I-D.ietf-reg
	RDAP extensions such as <xref target="I-D.ietf-regext-rdap-jscontact" fo	ext-rdap-jscontact">"Using JSContact in Registration Data Access Protocol (RDAP)
	rmat="default">JSContact in Registration Data Access Protocol (RDAP) JSON Respon	JSON Responses"</xref>, do not have a dependency on the use of positional JSON
	ses</xref> do not have a dependency on the use of positional JSON arrays and	arrays and
	are therefore suited for the Redaction by Removal Method.</t>	are therefore suited for the Redaction by Removal Method.</t>
	<t>When an RDAP object is redacted	<t>When an RDAP object is redacted
	by removal, all of the RDAP object's child fields are also removed. Onl y the redacted RDAP object needs to be referenced in the list of redacted fields ,	by removal, all of the RDAP object's child fields are also removed. Onl y the redacted RDAP object needs to be referenced in the list of redacted fields ,

	as defined in <xref target="redacted-member" format="default"/>.</t>	as defined in <xref target="redacted-member"/>.</t>
	<t>An example of redacting an RDAP object is removing the administrative contact	<t>An example of redacting an RDAP object is removing the administrative contact
	from the RDAP response and including the following "redacted" member:</t >	from the RDAP response and including the following "redacted" member:</t >

	<figure anchor="redacted-admin-contact" align="left" suppress-title="false" pn="	<figure anchor="redacted-admin-contact">
	figure-1">	<name>Redacted Administrative Contact</name>
	<name>Redacted Administrative Contact</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	"redacted": [	"redacted": [
	{	{
	"name": {	"name": {
	"description": "Administrative Contact"	"description": "Administrative Contact"
	},	},
	"prePath": "$.entities[?(@.roles[0]=='administrative')]",	"prePath": "$.entities[?(@.roles[0]=='administrative')]",
	"method": "removal"	"method": "removal"
	}	}
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
		<t>The Redaction by Removal Method <bcp14>MUST NOT</bcp14> be used to re
		move an element of an array where the position of the element in the array deter
		mines semantic meaning.


	<t>The Redaction by Removal Method MUST NOT be used to remove an element	<!--[rfced] Since "RFC 7095" is referenced for "jCard" in Section 3,
	of an array where the position of the element in the array determines semantic	is it necessary to reference "RFC 7095" each time "jCard" is used
	meaning.	thereafter as it affects readability when there are multiple
	For example, removal of an individual data field in <xref target="RFC7	references within one sentence or in close proximity.
	095" format="default">jCard</xref> will result in a non-conformant <xref target=
	"RFC7095" format="default">jCard</xref> array definition.</t>	Please let us know if "[RFC7095]" (from instances of "jCard
		[RFC7095]") may be removed after the first mention in
		Section 3. If that is not desired, may we update the
		sentences that contain multiple mentions to include only
		one mention as shown below? Please let us know your preference.

		Some examples:

		Original:
		The empty jCard [RFC7095] values ("" or null) are
		referenced in the "redacted" member in place of the jCard [RFC7095]
		property name in a array, such as referencing the "fn" jCard
		[RFC7095] property value at position 3 instead of referencing the
		"fn" jCard property name at position 0.

		Perhaps:
		The empty jCard [RFC7095] values ("" or null) are
		referenced in the "redacted" member in place of the jCard
		property name in an array, such as referencing the "fn" jCard
		property value at position 3 instead of referencing the
		"fn" jCard property name at position 0.

		...
		Original:
		For example, removal of an individual data field in
		jCard [RFC7095] will result in a non-conformant
		jCard [RFC7095] array definition.

		Perhaps:
		For example, removal of an individual data field in jCard will
		result in a non-conformant jCard array definition [RFC7095].

		...
		Original:
		Reference index 0 of the jCard [RFC7095] property array, which is
		the jCard [RFC7095] "name" property, with a filter expression
		containing the name of the field, when redacting a jCard [RFC7095]
		field using the Redaction by Removal Method (Section 3.1).

		Perhaps:
		Reference index 0 of the jCard [RFC7095] property array,
		which is the jCard "name" property, with a filter expression
		containing the name of the field, when redacting a jCard field using
		the Redaction by Removal Method (Section 3.1).
		-->

		For example, removal of an individual data field in <xref target="RFC7
		095">jCard</xref> will result in a non-conformant <xref target="RFC7095">jCard</
		xref> array definition.</t>
	</section>	</section>

	<section anchor="redaction-empty-value" numbered="true" toc="default">	<section anchor="redaction-empty-value">
	<name>Redaction by Empty Value Method</name>	<name>Redaction by Empty Value Method</name>

	<t>The Redaction by Empty Value Method is when a redacted field is not r
	emoved, but its value is set to an empty value, such as "" for a <xref	<!--[rfced] Per usage in RFC 7095 and throughout the document, may we make
	target="RFC7095" format="default">jCard</xref>	"Text" lowercase?
	Text ("text") property or null for a non-Text property. The empty <xref
	target="RFC7095" format="default">jCard</xref> values ("" or null) are referenc	Original:
	ed in the "redacted"	The Redaction by Empty Value Method is when a redacted field is not
	member in place of the <xref target="RFC7095" format="default">jCard</xr	removed, but its value is set to an empty value, such as "" for a
	ef> property name in a array, such as referencing the "fn" <xref target="RFC7095	jCard [RFC7095] Text ("text") property or null for a non-Text
	" format="default">jCard</xref> property value at position 3 instead of referenc	property.
	ing the "fn"
		Perhaps:
		The Redaction by Empty Value Method is when a redacted field is not
		removed but its value is set to an empty value, such as "" for a
		jCard [RFC7095] text ("text") property or null for a non-text
		property.
		-->

		<t>The Redaction by Empty Value Method is when a redacted field is not r
		emoved but its value is set to an empty value, such as "" for a <xref target="RF
		C7095">jCard</xref>
		Text ("text") property or null for a non-Text property. The empty <xref
		target="RFC7095">jCard</xref> values ("" or null) are referenced in the "redact
		ed"
		member in place of the <xref target="RFC7095">jCard</xref> property name
		in an array, such as referencing the "fn" <xref target="RFC7095">jCard</xref> p
		roperty value at position 3 instead of referencing the "fn"
	jCard property name at position 0.	jCard property name at position 0.

	The Redaction by Empty Value Method MUST be used only when redacting JSO	The Redaction by Empty Value Method <bcp14>MUST</bcp14> be used only whe
	N response fields that use the position in an	n redacting JSON response fields that use the position in an
	array to signal the redacted field (e.g., <xref target="RFC7095" format=	array to signal the redacted field (e.g., <xref target="RFC7095">jCard</
	"default">jCard</xref> arrays).	xref> arrays).
	Optional <xref target="RFC7095" format="default">jCard</xref> properties	Optional <xref target="RFC7095">jCard</xref> properties <bcp14>MUST</bcp
	MUST	14>
	use the <xref target="redaction-removal" format="default">Redaction by R	use the <xref target="redaction-removal">Redaction by Removal Method</xr
	emoval Method</xref> to redact the entire property.	ef> to redact the entire property.
	The required <xref target="RFC7095" format="default">jCard</xref> "fn" p	The required <xref target="RFC7095">jCard</xref> "fn" property, defined
	roperty, defined in section 6.2.1 of	in <xref target="RFC6350" section="6.2.1" sectionFormat="of">vCard</xref>, <bcp1
	<xref target="RFC6350" format="default">vCard</xref>, MUST use the Redac	4>MUST</bcp14> use the Redaction by Empty Value Method to redact the property va
	tion by Empty Value Method to redact the property value.	lue.
	Removing the "fn" property would violate <xref target="RFC6350" format="	Removing the "fn" property would violate <xref target="RFC6350">vCard</x
	default">vCard</xref> and removing the property value	ref>, and removing the property value
	would violate the fixed array positions defined in <xref target="RFC7095	would violate the fixed array positions defined in <xref target="RFC7095
	" format="default">jCard</xref>.</t>	">jCard</xref>.</t>
	<t>An example of the redacted "fn" jCard property using the Redaction by Empty V	<t>An example of the redacted "fn" jCard property using the Redaction by
	alue Method:</t>	Empty Value Method:</t>
	<figure anchor="redacted-fn-empty-value" align="left" suppress-title="false" pn=
	"figure-2">	<!--[rfced] We note that Figures 2, 6, 7, 8, 9, and 10 include
	<name>Redacted "fn" jCard property using Redaction by Empty Value Method</name	introductory text that repeats the information stated in their
	>	titles. To avoid redundancy, may we remove the introductory text
	<sourcecode type="json" markers="false">	for the figures listed?
		-->

		<figure anchor="redacted-fn-empty-value">
		<name>Redacted "fn" jCard Property Using the Redaction by Empty Value
		Method</name>
		<sourcecode type="json">
	[	[
	"fn",	"fn",
	{},	{},
	"text",	"text",
	""	""
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>An example of the "redacted" member for the redacted "fn" jCard property valu	<t>An example of the "redacted" member for the redacted "fn" jCard prope
	e, which is array position 3:</t>	rty value, which is array position 3:</t>
	<figure anchor="redacted-fn-array-pos" align="left" suppress-title="false" pn="f	<figure anchor="redacted-fn-array-pos">
	igure-3">	<name>Redacted Registrant Name Using an Array Position</name>
	<name>Redacted Registrant Name using Array Position</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	"redacted": [	"redacted": [
	{	{
	"name": {	"name": {
	"description": "Registrant Name"	"description": "Registrant Name"
	},	},
	"postPath": "$.entities[?(@.roles[0]=='registrant')].	"postPath": "$.entities[?(@.roles[0]=='registrant')].
	vcardArray[1][?(@[0]=='fn')][3]",	vcardArray[1][?(@[0]=='fn')][3]",
	"pathLang": "jsonpath",	"pathLang": "jsonpath",
	"method": "emptyValue",	"method": "emptyValue",
	"reason": {	"reason": {
	"description": "Server policy"	"description": "Server policy"
	}	}
	}	}
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	</section>	</section>

	<section anchor="redaction-partial-value" numbered="true" toc="default">	<section anchor="redaction-partial-value">
	<name>Redaction by Partial Value Method</name>	<name>Redaction by Partial Value Method</name>

	<t>The Redaction by Partial Value Method is when a redacted field is not removed, but its value has a portion of the data removed, such as for the "labe l" or "fn" <xref target="RFC7095" format="default">jCard</xref>	<t>The Redaction by Partial Value Method is when a redacted field is not removed but its value has a portion of the data removed, such as for the "label " or "fn" <xref target="RFC7095">jCard</xref>
	properties. The partial values are referenced in the "redacted"	properties. The partial values are referenced in the "redacted"

	member in place of the property name in a array, such as referencing the "fn" <xref target="RFC7095" format="default">jCard</xref> property value at pos ition 3 instead of referencing the "fn"	member in place of the property name in an array, such as referencing th e "fn" <xref target="RFC7095">jCard</xref> property value at position 3 instead of referencing the "fn"
	jCard property name at position 0.	jCard property name at position 0.

	The Redaction by Partial Value Method SHOULD be used only when redacting	The Redaction by Partial Value Method <bcp14>SHOULD</bcp14> be used only
	JSON response fields that use a formatted value, where a portion of the value i	when redacting JSON response fields that use a formatted value, where a portion
	s removed.	of the value is removed.
	</t>	</t>
	<t>An example of the "label" jCard property in Figure 15 of <xref target="RFC709
	5" format="default"/> that redacts "123 Maple Ave\nSuite 901\n":</t>	<!--[rfced] As RFC 7095 does not have its figures numbered, may we update
	<figure anchor="redacted-home-address-label-value" align="left" suppress-title="	"Figure 15" to be "Section 3.3.1.3" instead?
	false" pn="figure-4">
	<name>Redacted "label" jCard property</name>	Original:
	<sourcecode type="json" markers="false">	An example of the "label" jCard property in Figure 15 of [RFC7095]
		that redacts "123 Maple Ave\nSuite 901\n":
		...
		An example of the "redacted" member for the redacted "label" jCard
		property value, based on Figure 15 of [RFC7095]:

		Perhaps:
		An example of the "label" jCard property in Section 3.3.1.3 of [RFC7095]
		that redacts "123 Maple Ave\nSuite 901\n":
		...
		An example of the "redacted" member for the redacted "label" jCard
		property value, based on Section 3.3.1.3 of [RFC7095]:
		-->

		<t>An example of the "label" jCard property in Figure 15 of <xref target
		="RFC7095"/> that redacts "123 Maple Ave\nSuite 901\n":</t>
		<figure anchor="redacted-home-address-label-value">
		<name>Redacted "label" jCard Property</name>
		<sourcecode type="json">
	["adr",	["adr",
	{	{
	"type":"home",	"type":"home",
	"label":"Vancouver\nBC\n1239\n"	"label":"Vancouver\nBC\n1239\n"
	},	},
	"text",	"text",
	[	[
	"", "", "", "", "", "", ""	"", "", "", "", "", "", ""
	]	]
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>An example of the "redacted" member for the redacted "label" jCard property v	<t>An example of the "redacted" member for the redacted "label" jCard pr
	alue, based on Figure 15 of <xref target="RFC7095" format="default"/>:</t>	operty value, based on Figure 15 of <xref target="RFC7095"/>:</t>
	<figure anchor="redacted-home-address-label" align="left" suppress-title="false"	<figure anchor="redacted-home-address-label">
	pn="figure-5">	<name>Redacted Label Using the Redaction by Partial Value Method</name
	<name>Redacted Label using the Redaction by Partial Value Method</name>	>
	<sourcecode type="json" markers="false">	<sourcecode type="json">
	"redacted": [	"redacted": [
	{	{
	"name": {	"name": {
	"description": "Home Address Label"	"description": "Home Address Label"
	},	},
	"postPath": "$.vcardArray[1][?(@[0]=='adr')][1].label",	"postPath": "$.vcardArray[1][?(@[0]=='adr')][1].label",
	"pathLang": "jsonpath",	"pathLang": "jsonpath",
	"method": "partialValue",	"method": "partialValue",
	"reason": {	"reason": {
	"description": "Server policy"	"description": "Server policy"
	}	}
	}	}
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	</section>	</section>

	<section anchor="redaction-replacement-value" numbered="true" toc="default ">	<section anchor="redaction-replacement-value">
	<name>Redaction by Replacement Value Method</name>	<name>Redaction by Replacement Value Method</name>

	<t>The Redaction by Replacement Value Method is when a redacted field is not removed, but its value is replaced with a different value, such as protecti ng the "email" <xref target="RFC7095" format="default">jCard</xref>	<t>The Redaction by Replacement Value Method is when a redacted field is not removed but its value is replaced with a different value, such as protectin g the "email" <xref target="RFC7095">jCard</xref>
	property value with an anonymized email "text" value or the use of an al ternative "uri" value to a web form. Replacing a property value is a form of re daction, since it protects the	property value with an anonymized email "text" value or the use of an al ternative "uri" value to a web form. Replacing a property value is a form of re daction, since it protects the
	true property value for privacy reasons.</t>	true property value for privacy reasons.</t>

	<t>An example of the redacted "email" jCard property using the Redaction by Repl	<t>An example of the redacted "email" jCard property using the Redaction
	acement Value Method with an anonymized email:</t>	by Replacement Value Method with an anonymized email:</t>
	<figure anchor="redacted-email-anonymized-value" align="left" suppress-title="fa	<figure anchor="redacted-email-anonymized-value">
	lse" pn="figure-6">	<name>Redacted "email" jCard Property Using the Redaction by Replaceme
	<name>Redacted "email" jCard property using Redaction by Replacement Value Met	nt Value Method with an Anonymized Email</name>
	hod with an anonymized email</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	[	[
	"email",	"email",
	{},	{},
	"text",	"text",
	"anonymized123@example.com"	"anonymized123@example.com"
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>An example of the "redacted" member for the redacted registrant "email" jCard	<t>An example of the "redacted" member for the redacted registrant "emai
	property value with an anonymized "text" value.</t>	l" jCard property value with an anonymized "text" value:</t>
	<figure anchor="redacted-email-replacement-anonymized" align="left" suppress-tit	<figure anchor="redacted-email-replacement-anonymized">
	le="false" pn="figure-7">	<name>Redacted Email Using a Replacement Value with an Anonymized "tex
	<name>Redacted Email using Replacement Value with an anonymized "text" value</	t" Value</name>
	name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	"redacted": [	"redacted": [
	{	{
	"name": {	"name": {
	"description": "Registrant Email"	"description": "Registrant Email"
	},	},
	"postPath": "$.entities[?(@.roles[0]=='registrant')].	"postPath": "$.entities[?(@.roles[0]=='registrant')].
	vcardArray[1][?(@[0]=='email')][3]",	vcardArray[1][?(@[0]=='email')][3]",
	"pathLang": "jsonpath",	"pathLang": "jsonpath",
	"method": "replacementValue",	"method": "replacementValue",
	}	}
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>An example of the redacted "email" jCard property using the Redaction by Repl	<t>An example of the redacted "email" jCard property using the Redaction
	acement Value Method with a <xref target="RFC8605" format="default"/> "contact-u	by Replacement Value Method with a "contact-uri" <xref target="RFC8605"/> jCard
	ri" jCard property to a web form:</t>	property to a web form:</t>
	<figure anchor="redacted-email-links-related" align="left" suppress-title="false	<figure anchor="redacted-email-links-related">
	" pn="figure-8">	<name>Redacted "email" jCard Property Using the Redaction by Replaceme
	<name>Redacted "email" jCard property using Redaction by Replacement Value Met	nt Value Method with a "contact-uri" jCard Property to a Web Form</name>
	hod with a "contact-uri" jCard property to a web form</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	[	[
	"contact-uri",	"contact-uri",
	{},	{},
	"uri",	"uri",
	"https://email.example.com/123"	"https://email.example.com/123"
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>An example of the "redacted" member for the redacted registrant "email" jCard	<t>An example of the "redacted" member for the redacted registrant "emai
	property with a <xref target="RFC8605" format="default"/> "contact-uri" jCard p	l" jCard property with a "contact-uri" <xref target="RFC8605"/> jCard property t
	roperty to a web form:</t>	o a web form:</t>
	<figure anchor="redacted-email-replacement-links-related" align="left" suppress-	<figure anchor="redacted-email-replacement-links-related">
	title="false" pn="figure-9">	<name>Redacted Email Using a Replacement Value with a "contact-uri" jC
	<name>Redacted Email using Replacement Value with a "contact-uri" jCard proper	ard Property to a Web Form</name>
	ty to a web form</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	"redacted": [	"redacted": [
	{	{
	"name": {	"name": {
	"description": "Registrant Email"	"description": "Registrant Email"
	},	},
	"prePath": "$.entities[?(@.roles[0]=='registrant')].	"prePath": "$.entities[?(@.roles[0]=='registrant')].
	vcardArray[1][?(@[0]=='email')]",	vcardArray[1][?(@[0]=='email')]",
	"replacementPath": "$.entities[?(@.roles[0]=='registrant')].	"replacementPath": "$.entities[?(@.roles[0]=='registrant')].
	vcardArray[1][?(@[0]=='contact-uri')]",	vcardArray[1][?(@[0]=='contact-uri')]",
	"pathLang": "jsonpath",	"pathLang": "jsonpath",
	"method": "replacementValue",	"method": "replacementValue",
	}	}
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	</section>	</section>
	</section>	</section>

	<section anchor="redacted-rdap-response" numbered="true" toc="default">	<section anchor="redacted-rdap-response">
	<name>Redacted RDAP Response</name>	<name>Redacted RDAP Response</name>

	<section anchor="rdap-conformance" numbered="true" toc="default">	<section anchor="rdap-conformance">
	<name>RDAP Conformance</name>	<name>RDAP Conformance</name>

	<t>RDAP responses that contain values described in this document MUST	<t>RDAP responses that contain values described in this document <bcp14> MUST</bcp14>
	indicate conformance with this specification by including an	indicate conformance with this specification by including an

	"rdapConformance" (<xref target="RFC9083" format="default"/	"rdapConformance" <xref target="RFC9083"/> value of "redacted".
	>) value of "redacted".	The "redacted" extension identifier is described in <xref target="rda
	The "redacted" extension identifier is described in <xref t	p-extensions-registry"/>.</t>
	arget="rdap-extensions-registry" format="default"/>.</t>	<t>Example "rdapConformance" member with the redacted extension:</t>
	<t>Example "rdapConformance" member with the redacted exten	<figure anchor="rdapConformance-with-redacted">
	sion:</t>	<name>"rdapConformance" with Redacted Extension</name>
	<figure anchor="rdapConformance-with-redacted" align="left" suppress-title="fals	<sourcecode type="json">
	e" pn="figure-10">
	<name>"rdapConformance" with Redacted Extension</name>
	<sourcecode type="json" markers="false">
	"rdapConformance": [	"rdapConformance": [
	"rdap_level_0",	"rdap_level_0",
	"redacted"	"redacted"
	]	]
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	</section>	</section>

	<section anchor="redacted-member" numbered="true" toc="default">	<section anchor="redacted-member">
	<name>"redacted" Member</name>	<name>"redacted" Member</name>
	<t>The "redacted" member MUST be added to the RDAP response wh	<t>The "redacted" member <bcp14>MUST</bcp14> be added to the RDAP respon
	en	se when
	there is one or more redacted fields. The "redacted" member i	there is one or more redacted fields. The "redacted" member is included
	s included as a member of the object instance in a lookup response, such as the	as a member of the object instance in a lookup response, such as the object cla
	object classes defined in <xref target="RFC9083" format="default"/>, and	sses defined in <xref target="RFC9083"/>, and
	as a member of the object instances in a search response.</t>	as a member of the object instances in a search response.</t>

		<t>The server, including a redacted signal, provides an unauthorized cli
	<t>The server including a redacted signal provides an unauthorized clien	ent additional
	t additional	information related to the existence of data and <bcp14>MAY</bcp14> excl
	information related to the existence of data and MAY exclude the redacte	ude the redacted members
	d members
	for RDAP fields that are considered a privacy issue in providing a data existence signal.	for RDAP fields that are considered a privacy issue in providing a data existence signal.

	The server MAY choose to publish a redaction policy describing how this extension is implemented for their constituency.	The server <bcp14>MAY</bcp14> choose to publish a redaction policy descr ibing how this extension is implemented for their constituency.
	The contents of such a policy are outside the scope of this specificatio n.</t>	The contents of such a policy are outside the scope of this specificatio n.</t>

		<t>The "redacted" member contains an array
	<t>The "redacted" member contains an array
	of objects with the following child members:</t>	of objects with the following child members:</t>

	<dl newline="false" indent="4">	<dl indent="4" newline="false">
	<dt>"name":</dt>	<dt>"name":</dt>

	<dd>REQUIRED logical name for the redacted field. The logical name us	<dd><bcp14>REQUIRED</bcp14> logical name for the redacted field. The
	ed	logical name used
	for the redacted field is up to server policy. The logical name	for the redacted field is up to server policy.
		The logical name
	is defined using an object with a "type" field denoting a registered r edacted	is defined using an object with a "type" field denoting a registered r edacted

	name (see <xref target="json-values-registry" format="default"/>) or a "description" field denoting an unregistered redacted name.	name (see <xref target="json-values-registry"/>) or a "description" fi eld denoting an unregistered redacted name.
	The registered redacted names and the chosen unregistered names	The registered redacted names and the chosen unregistered names
	can meet the needs of different RDAP services or industries.</dd>	can meet the needs of different RDAP services or industries.</dd>
	<dt>"prePath":</dt>	<dt>"prePath":</dt>

	<dd>OPTIONAL JSON path expression referencing a redacted JSON field in	<dd><bcp14>OPTIONAL</bcp14> JSON path expression referencing a redacte
	the pre-redacted response.	d JSON field in the pre-redacted response.
	The "prePath" member MAY be set when the redacted field does not exist	The "prePath" member <bcp14>MAY</bcp14> be set when the redacted field
	in the redacted response for the <xref target="redaction-removal">Redaction By	does not exist in the redacted response for the <xref target="redaction-removal
	Removal Method</xref> and the <xref target="redaction-replacement-value">Redacti	">Redaction by Removal Method</xref> and the <xref target="redaction-replacement
	on by Replacement Value Method</xref>.	-value">Redaction by Replacement Value Method</xref>.
	The "prePath" member MUST NOT be set when the "postPath" member is set	The "prePath" member <bcp14>MUST NOT</bcp14> be set when the "postPath
	.	" member is set.
	</dd>	</dd>
	<dt>"postPath":</dt>	<dt>"postPath":</dt>

	<dd>OPTIONAL JSON path expression referencing a redacted JSON field in	<dd><bcp14>OPTIONAL</bcp14> JSON path expression referencing a redacte
	the redacted (post-redacted) response.	d JSON field in the redacted (post-redacted) response.
	The "postPath" member MUST be set when the redacted field does exist i	The "postPath" member <bcp14>MUST</bcp14> be set when the redacted fie
	n the redacted response for the <xref target="redaction-empty-value">Redaction b	ld does exist in the redacted response for the <xref target="redaction-empty-val
	y Empty Value Method</xref>, the <xref target="redaction-partial-value">Redactio	ue">Redaction by Empty Value Method</xref>, the <xref target="redaction-partial-
	n by Partial Value Method</xref>, and the <xref target="redaction-replacement-va	value">Redaction by Partial Value Method</xref>, and the <xref target="redaction
	lue">Redaction by Replacement Value Method</xref>.	-replacement-value">Redaction by Replacement Value Method</xref>.
	The "postPath" member MUST NOT be set when the "prePath" member is set	The "postPath" member <bcp14>MUST NOT</bcp14> be set when the "prePath
	.	" member is set.
	</dd>	</dd>
	<dt>"replacementPath":</dt>	<dt>"replacementPath":</dt>

	<dd>OPTIONAL JSON path expression of the replacement field of the reda cted field with the	<dd><bcp14>OPTIONAL</bcp14> JSON path expression of the replacement fi eld of the redacted field with the
	<xref target="redaction-replacement-value">Redaction by Replacement Value Method</xref>, using the expression language defined by the "pathLang" mem ber.	<xref target="redaction-replacement-value">Redaction by Replacement Value Method</xref>, using the expression language defined by the "pathLang" mem ber.
	</dd>	</dd>
	<dt>"pathLang":</dt>	<dt>"pathLang":</dt>

	<dd>OPTIONAL JSON path expression language used, with the default valu	<dd><bcp14>OPTIONAL</bcp14> JSON path expression language used, with t
	e of "jsonpath" for JSONPath (<xref target="I-D.ietf-jsonpath-base" format="defa	he default value of "jsonpath" for JSONPath <xref target="RFC9535"/>.
	ult"/>).	Other JSON path expression languages registered with the "redacted ex
	Other JSON path expression languages registered with the "redacted exp	pression language" Type in the "RDAP JSON Values" registry <bcp14>MAY</bcp14> be
	ression language" RDAP JSON Values Registry Type MAY be used based on server pol	used based on server policy.</dd>
	icy.</dd>
	<dt>"method":</dt>	<dt>"method":</dt>
	<dd>	<dd>

	<t>OPTIONAL redaction method used; with one of the following values: </t>	<t><bcp14>OPTIONAL</bcp14> redaction method used, with one of the fo llowing values:</t>
	<ul>	<ul>

	<li>"removal" indicating the <xref target="redaction-removal">Reda	<li>"removal" indicating the <xref target="redaction-removal">Reda
	ction By Removal Method</xref>,</li>	ction by Removal Method</xref>,</li>
	<li>"emptyValue" indicating the <xref target="redaction-empty-valu	<li>"emptyValue" indicating the <xref target="redaction-empty-valu
	e">Redaction by Empty Value Method</xref>, or</li>	e">Redaction by Empty Value Method</xref>,</li>
	<li>"partialValue" indicating the <xref target="redaction-partial- value">Redaction by Partial Value Method</xref>, or</li>	<li>"partialValue" indicating the <xref target="redaction-partial- value">Redaction by Partial Value Method</xref>, or</li>

	<li>"replacementValue" indicating the <xref target="redaction-repl acement-value">Redaction by Replacement Value Method.</xref></li>	<li>"replacementValue" indicating the <xref target="redaction-repl acement-value">Redaction by Replacement Value Method</xref>.</li>
	</ul>	</ul>
	<t>The default value is "removal" when not provided.</t>	<t>The default value is "removal" when not provided.</t>
	</dd>	</dd>
	<dt>"reason":</dt>	<dt>"reason":</dt>

	<dd>OPTIONAL human readable reason(s) for the redacted field in	<dd><bcp14>OPTIONAL</bcp14> human-readable reason(s) for the redacted
	the language defined by the <xref target="RFC9083" format="default"/>	field in
	"lang" member.	the language defined by the "lang" <xref target="RFC9083"/> member.
	The default language is "en" if the <xref target="RFC9083" format="def	The default language is "en" if the "lang" <xref target="RFC9083"/> me
	ault"/> "lang" member is not specified.	mber is not specified.
	The reason is defined using an object with an OPTIONAL "type" field de	The reason is defined using an object with an <bcp14>OPTIONAL</bcp14> "ty
	noting a registered redacted reason	pe" field denoting a registered redacted reason
	(see see <xref target="json-values-registry" format="default"/>) and a	(see <xref target="json-values-registry"/>) and an <bcp14>OPTIONAL</bc
	n OPTIONAL "description" field denoting an unregistered redacted reason.	p14> "description" field denoting an unregistered redacted reason.
	The "description" field MUST NOT be a client processing dependency.</d	The "description" field <bcp14>MUST NOT</bcp14> be a client processing
	d>	dependency.</dd>
	</dl>	</dl>

	<t>Example unredacted version of an RDAP lookup response:</t>	<t>Example of the unredacted version of an RDAP lookup response:</t>
	<figure anchor="unredacted-lookup-response" align="left" suppress-title="false"	<figure anchor="unredacted-lookup-response">
	pn="figure-11">	<name>Unredacted RDAP Lookup Response</name>
	<name>Unredacted RDAP Lookup Response</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	{	{
	"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
	},	},

	skipping to change at line 815 ¶	skipping to change at line 943 ¶
	}	}
	],	],
	"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"
	]	]
	}	}
	</sourcecode>	</sourcecode>

	</figure>	</figure>
		<t>Example of the redacted version of an RDAP lookup response:</t>
	<t>Example redacted version of an RDAP lookup response:</t>	<figure anchor="redacted-lookup-response">
	<figure anchor="redacted-lookup-response" align="left" suppress-title="false" pn	<name>Redacted RDAP Lookup Response</name>
	="figure-12">	<sourcecode type="json">
	<name>Redacted RDAP Lookup Response</name>
	<sourcecode type="json" markers="false">
	{	{
	"rdapConformance": [	"rdapConformance": [
	"rdap_level_0",	"rdap_level_0",
	"redacted"	"redacted"
	],	],
	"objectClassName": "domain",	"objectClassName": "domain",
	"ldhName": "example.com",	"ldhName": "example.com",
	"secureDNS": {	"secureDNS": {
	"delegationSigned": false	"delegationSigned": false
	},	},

	skipping to change at line 1226 ¶	skipping to change at line 1353 ¶
	},	},
	"prePath": "$.entities[?(@.roles[0]=='billing')]",	"prePath": "$.entities[?(@.roles[0]=='billing')]",
	"method": "removal",	"method": "removal",
	"reason": {	"reason": {
	"description": "Refer to the registrant contact"	"description": "Refer to the registrant contact"
	}	}
	}	}
	]	]
	}	}
	</sourcecode>	</sourcecode>

	</figure>	</figure>
	<t>Example unredacted version of an RDAP search response:</t>	<t>Example of the unredacted version of an RDAP search response:</t>
	<figure anchor="unredacted-search-response" align="left" suppress-title="false"	<figure anchor="unredacted-search-response">
	pn="figure-13">	<name>Unredacted RDAP Search Response</name>
	<name>Unredacted RDAP Search Response</name>	<sourcecode type="json">
	<sourcecode type="json" markers="false">
	{	{
	"rdapConformance": [	"rdapConformance": [
	"rdap_level_0"	"rdap_level_0"
	],	],
	"domainSearchResults":[	"domainSearchResults":[
	{	{
	"objectClassName": "domain",	"objectClassName": "domain",
	"handle": "ABC121",	"handle": "ABC121",
	"ldhName": "example1.com",	"ldhName": "example1.com",
	"links":[	"links":[

	skipping to change at line 1277 ¶	skipping to change at line 1404 ¶
	"value":"https://example.com/rdap/domain/example2.com",	"value":"https://example.com/rdap/domain/example2.com",
	"rel":"related",	"rel":"related",
	"href":"https://example.com/rdap/domain/example2.com",	"href":"https://example.com/rdap/domain/example2.com",
	"type":"application/rdap+json"	"type":"application/rdap+json"
	}	}
	]	]
	}	}
	]	]
	}	}
	</sourcecode>	</sourcecode>

	</figure>	</figure>
		<t>Example of the redacted version of an RDAP search response:</t>
	<t>Example redacted version of an RDAP search response:</t>	<figure anchor="redacted-search-response">
	<figure anchor="redacted-search-response" align="left" suppress-title="false" pn	<name>Redacted RDAP Search Response</name>
	="figure-14">	<sourcecode type="json">
	<name>Redacted RDAP Search Response</name>
	<sourcecode type="json" markers="false">
	{	{
	"rdapConformance": [	"rdapConformance": [
	"rdap_level_0",	"rdap_level_0",
	"redacted"	"redacted"
	],	],
	"domainSearchResults":[	"domainSearchResults":[
	{	{
	"objectClassName": "domain",	"objectClassName": "domain",
	"ldhName": "example1.com",	"ldhName": "example1.com",
	"links":[	"links":[

	skipping to change at line 1354 ¶	skipping to change at line 1480 ¶
	"method": "removal",	"method": "removal",
	"reason": {	"reason": {
	"description": "Server policy"	"description": "Server policy"
	}	}
	}	}
	]	]
	}	}
	]	]
	}	}
	</sourcecode>	</sourcecode>

	</figure>	</figure>

	</section>	</section>
	</section>	</section>

	<section anchor="jsonpath-considerations" numbered="true" toc="default">	<section anchor="jsonpath-considerations">
	<name>JSONPath Considerations</name>	<name>JSONPath Considerations</name>

	<t><xref target="I-D.ietf-jsonpath-base" format="default">JSONPath</xref> is the default	<t><xref target="RFC9535">JSONPath</xref> is the default
	JSON path expression language. This section includes JSONPath considerati ons for clients and servers.</t>	JSON path expression language. This section includes JSONPath considerati ons for clients and servers.</t>

		<section anchor="jsonpath-client-considerations">
	<section anchor="jsonpath-client-considerations" numbered="true" toc="defa
	ult">
	<name>JSONPath Client Considerations</name>	<name>JSONPath Client Considerations</name>


	<t>This section covers considerations for clients that receive responses from	<t>This section covers considerations for clients that receive responses from

	servers using <xref target="I-D.ietf-jsonpath-base" format="default"/> to identify	servers using JSONPath <xref target="RFC9535"/> to identify
	redacted RDAP fields with the "prePath" or "postPath" member of redact ed objects in the "redacted" member.	redacted RDAP fields with the "prePath" or "postPath" member of redact ed objects in the "redacted" member.

	The list of JSONPath client considerations include:</t>	The list of JSONPath client considerations include:</t>
		<ol spacing="compact">
	<ol spacing="compact" type="1">	<li>When the server is using the <xref target="redaction-removal">Reda
	<li>When the server is using the <xref target="redaction-removal">Reda	ction by Removal Method</xref> or the <xref target="redaction-replacement-value"
	ction By Removal Method</xref> or the <xref target="redaction-replacement-value"	>Redaction by Replacement Value Method</xref> with an alternative field value,
	>Redaction by Replacement Value Method</xref> with an alternative field value,
	the JSONPath expression of the "prePath" member will not resolve succe ssfully with the redacted response.	the JSONPath expression of the "prePath" member will not resolve succe ssfully with the redacted response.
	The client can key off the "name" member for display logic related to the redaction.</li>	The client can key off the "name" member for display logic related to the redaction.</li>
	</ol>	</ol>
	</section>	</section>

		<section anchor="jsonpath-server-considerations">
	<section anchor="jsonpath-server-considerations" numbered="true" toc="defa
	ult">
	<name>JSONPath Server Considerations</name>	<name>JSONPath Server Considerations</name>


	<t>This section covers considerations for servers	<t>This section covers considerations for servers

	using <xref target="I-D.ietf-jsonpath-base" format="default"/> to identi fy	using JSONPath <xref target="RFC9535"/> to identify
	redacted RDAP fields with the "prePath" or "postPath" member of redacted objects in the "redacted" member.	redacted RDAP fields with the "prePath" or "postPath" member of redacted objects in the "redacted" member.
	The list of JSONPath considerations include:</t>	The list of JSONPath considerations include:</t>

		<ol spacing="normal">
	<ol spacing="compact" type="1">
	<li>Use absolute paths with the '$' JSONPath element. An example is " $.handle" for the "Registry Domain ID" in a lookup response or "$.domainSearchRe sults[0].handle" in a search response.</li>	<li>Use absolute paths with the '$' JSONPath element. An example is " $.handle" for the "Registry Domain ID" in a lookup response or "$.domainSearchRe sults[0].handle" in a search response.</li>
	<li>Validate a JSONPath expression with the non-redacted RDAP response when using the "prePath" member, where evaluating the expression results in ret urning the redacted field.</li>	<li>Validate a JSONPath expression with the non-redacted RDAP response when using the "prePath" member, where evaluating the expression results in ret urning the redacted field.</li>

	<li>Reference the removed object field when redacting an entire object by the <xref target="redaction-removal" format="default">Redaction by Removal Method</xref>, where all of the object's child fields are explicitly removed.	<li>Reference the removed object field when redacting an entire object by the <xref target="redaction-removal">Redaction by Removal Method</xref>, wh ere all of the object's child fields are explicitly removed.
	An example is "$.entities[?(@.roles[0]=='administrative')]" for the en tire "Administrative Contact".</li>	An example is "$.entities[?(@.roles[0]=='administrative')]" for the en tire "Administrative Contact".</li>

	<li>It is possible for there to be multiple bases for the redaction of	<li>Use multiple bases for the redaction of
	certain content. For example, if server policy is such that all	certain content. For example, if server policy is such that all
	administrative-role entities are redacted and all technical-role	administrative-role entities are redacted and all technical-role
	entities are redacted, then an entity having both the	entities are redacted, then an entity having both the
	administrative role and the technical role could be redacted for	administrative role and the technical role could be redacted for
	two different reasons. In this situation, a server is required to	two different reasons. In this situation, a server is required to

	include at least one "redacted" entry, but should consider	include at least one "redacted" entry, but it should consider
	including a separate "redacted" entry for each applicable basis	including a separate "redacted" entry for each applicable basis

	for redaction, so as to clearly document the server policies that	for redaction to clearly document the server policies that
	are relevant to redaction in each instance.</li>	are relevant to redaction in each instance.</li>

	<li>Reference the removed field when using the <xref target="redactio	<li>Reference the removed field when using the <xref target="redaction
	n-removal" format="default">Redaction by Removal Method</xref>. An example is "	-removal">Redaction by Removal Method</xref>. An example is "$.handle" for the
	$.handle" for the "Registry Domain ID".</li>	"Registry Domain ID".</li>
	<li>Reference index 0 of the <xref target="RFC7095" format="default">j	<li>Reference index 0 of the <xref target="RFC7095">jCard</xref> prope
	Card</xref> property array, which is the <xref target="RFC7095" format="default"	rty array, which is the <xref target="RFC7095">jCard</xref> "name" property,
	>jCard</xref> "name" property,	with a filter expression containing the name of the field when redacti
	with a filter expression containing the name of the field, when redact	ng a <xref target="RFC7095">jCard</xref> field using the <xref target="redaction
	ing a <xref target="RFC7095" format="default">jCard</xref> field using the <xref	-removal">Redaction by Removal Method</xref>.
	target="redaction-removal" format="default">Redaction by Removal Method</xref>.
	An example is "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][? (@[0]=='email')]" for the "Registrant Email".</li>	An example is "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][? (@[0]=='email')]" for the "Registrant Email".</li>

	<li>Reference <xref target="RFC7095" format="default">jCard</xref> fie	<li>Reference the <xref target="RFC7095">jCard</xref> field value or v
	ld value or values redacted by array index 3 and greater,	alues redacted by array index 3 and greater
	when redacting a <xref target="RFC7095" format="default">jCard</xref>	when redacting a <xref target="RFC7095">jCard</xref> field using the <
	field using the <xref target="redaction-empty-value" format="default">Redaction	xref target="redaction-empty-value">Redaction by Empty Value Method</xref>.
	by Empty Value Method</xref>.	The <xref target="RFC7095">jCard</xref> property array index 3 and gre
	The <xref target="RFC7095" format="default">jCard</xref> property arra	ater contain the property values, where the property values set with an empty va
	y index 3 and greater contain the property values, where the property values set	lue
	with an empty value	are referenced directly in place of the <xref target="RFC7095">jCard</
	are referenced directly in place of the <xref target="RFC7095" format=	xref> property name. Servers can then systematically redact the <xref target="R
	"default">jCard</xref> property name. Servers can then systematically redact <x	FC7095">jCard</xref>
	ref target="RFC7095" format="default">jCard</xref>	field value or values based on the JSONPath expressions, and clients w
	field value or values based on the JSONPath expressions and clients wi	ill directly know which <xref target="RFC7095">jCard</xref> property values have
	ll directly know which <xref target="RFC7095" format="default">jCard</xref> prop	been redacted.
	erty values have been redacted.
	An example is "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][? (@[0]=='fn')][3]" for the "Registrant Name" or "$.entities[?(@.roles[0]=='regist rant')].vcardArray[1][?(@[0]=='adr')][3][5]"	An example is "$.entities[?(@.roles[0]=='registrant')].vcardArray[1][? (@[0]=='fn')][3]" for the "Registrant Name" or "$.entities[?(@.roles[0]=='regist rant')].vcardArray[1][?(@[0]=='adr')][3][5]"
	for the "Registrant Postal Code".</li>	for the "Registrant Postal Code".</li>
	<li>RDAP extensions should define any special JSONPath considerations required to identify redacted RDAP fields if these considerations are insufficie nt.</li>	<li>RDAP extensions should define any special JSONPath considerations required to identify redacted RDAP fields if these considerations are insufficie nt.</li>
	</ol>	</ol>


	</section>	</section>
	</section>	</section>

	<section anchor="iana-considerations" numbered="true" toc="default">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<section anchor="rdap-extensions-registry" numbered="true" toc="default">	<section anchor="rdap-extensions-registry">
	<name>RDAP Extensions Registry</name>	<name>RDAP Extensions Registry</name>

	<t>IANA is requested to register the following value in the RDAP	<t>IANA has registered the following value in the "RDAP
	Extensions Registry:</t>	Extensions" registry:</t>
	<dl newline="false" spacing="compact">
	<dt>Extension identifier:</dt>	<!-- [rfced] We have included some specific questions about the IANA
	<dd>redacted</dd>	text below. In addition to responding to those questions, please
	<dt>Registry operator:</dt>	review all of the IANA-related updates carefully and let us know
	<dd>Any</dd>	if any further updates are needed.
	<dt>Published specification:</dt>
	<dd>This document.</dd>	a) Section 6.1. In the "RDAP Extensions" registry under the "redacted"
		value, the Contact is listed as "IESG" in this document; however, it
		is listed as "IETF" in the IANA registry at
		"https://www.iana.org/assignments/rdap-extensions". For consistency,
		should this document be updated to reflect "IETF", or should the IANA
		registry be updated to reflect "IESG"?

		Current (Section 6.1):
		Contact: IESG <iesg@ietf.org>

		b) Section 6.2. In the "RDAP JSON Values" registry under the Description
		for "jsonpath", this document references "draft-ietf-jsonpath-base" ("RFC 9535")
		but IANA references this document (see "https://www.iana.org/assignments/
		rdap-json-values/"). Please confirm which document should be listed,
		and we will update this specification or the IANA registry accordingly.

		Original (Section 6.2):
		Description: JSON path expression language, as defined in
		draft-ietf-jsonpath-base.
		-->

		<dl spacing="normal">
		<dt>Extension Identifier:</dt>
		<dd>redacted</dd>
		<dt>Registry Operator:</dt>
		<dd>Any</dd>
		<dt>Specification:</dt>
		<dd>RFC 9537</dd>
	<dt>Contact:</dt>	<dt>Contact:</dt>

	<dd>IESG <iesg@ietf.org></dd>	<dd>IESG <iesg@ietf.org></dd>
	<dt>Intended usage:</dt>	<dt>Intended Usage:</dt>
	<dd>This extension identifies the redacted fields in an RDAP response.<	<dd>This extension identifies the redacted fields in an RDAP response.
	/dd>	</dd>
	</dl>	</dl>
	</section>	</section>

	<section anchor="json-values-registry" numbered="true" toc="default">	<section anchor="json-values-registry">
	<name>RDAP JSON Values Registry</name>	<name>RDAP JSON Values Registry</name>

	<t>Section 10.2 of <xref target="RFC9083" format="default"/> defines the	<t><xref target="RFC9083" section="10.2" sectionFormat="of" /> defines t
	RDAP JSON Values Registry with pre-defined Type field values and the use	he
	of the	"RDAP JSON Values" registry with predefined Type field values and a
	"Expert Review" policy defined in <xref target="RFC8126" format="default	registration policy of Expert Review <xref target="RFC8126"/>.
	"/>.	This specification defines three new Type field
	This specification defines three new RDAP JSON Values Registry Type fiel	values that can be used to register predefined redacted name, reason, an
	d	d
	values that can be used to register pre-defined redacted name, reason, a	expression language values. IANA has updated the "RDAP JSON Values" regi
	nd	stry to accept these additional Type field values as follows:</t>
	expression language values. IANA is instructed to update the RDAP JSON V	<dl indent="4">
	alues
	Registry to accept these additional type field values as follows:</t>
	<dl newline="false" indent="4">
	<dt>"redacted name":</dt>	<dt>"redacted name":</dt>
	<dd>Redacted name being registered. The registered redacted name	<dd>Redacted name being registered. The registered redacted name
	is referenced using the "type" field of the redacted "name" field.</dd >	is referenced using the "type" field of the redacted "name" field.</dd >
	<dt>"redacted reason":</dt>	<dt>"redacted reason":</dt>
	<dd>Redacted reason being registered. The registered redacted reason	<dd>Redacted reason being registered. The registered redacted reason
	is referenced using the "type" field of the redacted "reason" field.</ dd>	is referenced using the "type" field of the redacted "reason" field.</ dd>
	<dt>"redacted expression language":</dt>	<dt>"redacted expression language":</dt>
	<dd>Redacted expression language being registered. The registered red acted expression	<dd>Redacted expression language being registered. The registered red acted expression
	language is referenced using the "pathLang" field.</dd>	language is referenced using the "pathLang" field.</dd>
	</dl>	</dl>

	<t>The following values should be registered by the IANA in the RDAP JSO	<t>IANA has also listed this document as a reference for the "RDAP JSON
	N Values Registry described in <xref target="RFC9083"/>:</t>	Values" registry and has registered the following value:</t>
	<dl newline="false" indent="4">	<dl indent="4">
	<dt>Value:</dt>	<dt>Value:</dt>
	<dd>jsonpath</dd>	<dd>jsonpath</dd>
	<dt>Type:</dt>	<dt>Type:</dt>
	<dd>redacted expression language</dd>	<dd>redacted expression language</dd>
	<dt>Description:</dt>	<dt>Description:</dt>

	<dd>JSON path expression language, as defined in draft-ietf-jsonpath-b	<dd>JSON path expression language, as defined in RFC 9535.</dd>
	ase.</dd>	<dt>Registrant:</dt>
	<dt>Registrant Name:</dt>
	<dd>IETF</dd>	<dd>IETF</dd>

	<dt>Registrant Contact Information:</dt>	<dt>Contact Information:</dt>
	<dd>iesg@ietf.org</dd>	<dd>iesg@ietf.org</dd>

		<dt>Reference:</dt>
		<dd>RFC 9537</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>

	<section anchor="Implementation" numbered="true" toc="default">	<section anchor="security-considerations">
	<name>Implementation Status</name>
	<t>Note to RFC Editor: Please remove this section and the reference to
	<xref target="RFC7942" format="default">RFC 7942</xref> before publicat
	ion.</t>
	<t>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 <xref target=
	"RFC7942" format="default">RFC
	7942</xref>. 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.</t>
	<t>According to <xref target="RFC7942" format="default">RFC 7942</xref>, "
	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".</t>
	<section anchor="iit-cnr-registro-it-rdap-server" numbered="true" toc="def
	ault">
	<name>IIT-CNR/Registro.it RDAP Server</name>
	<t>Responsible Organization: Institute of Informatics and Telematics of
	National Research Council (IIT-CNR)/Registro.it</t>
	<t>Location: https://rdap.pubtest.nic.it/</t>
	<t>Description: This implementation includes support for RDAP queries us
	ing data from the public test environment of .it ccTLD. The "redacted&quot
	; array can be returned in the response to the domain lookup that is the only av
	ailable to anonymous users.</t>
	<t>Level of Maturity: This is an "alpha" test implementation.<
	/t>
	<t>Coverage: This implementation includes all of the features described
	in this specification.</t>
	<t>Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it</t>
	</section>
	</section>
	<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>The extension described in this document does not provide any security services	<t>The extension described in this document does not provide any security services

	beyond those described by <xref target="RFC9083" format="default"/>.</t>	beyond those described by <xref target="RFC9083"/>.</t>
	</section>	</section>

	<section anchor="Acknowledgements" numbered="true" toc="default">	</middle>
		<back>

		<displayreference target="I-D.ietf-regext-rdap-jscontact" to="RDAP-JSCONTACT
		"/>

		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
		19.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.63
		50.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.70
		95.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
		26.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
		74.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
		59.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
		82.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
		83.xml"/>

		<!-- [I-D.ietf-jsonpath-base] is now RFC 9535 -->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		535.xml"/>
		</references>

		<references>
		<name>Informative References</name>

		<!-- [I-D.ietf-regext-rdap-jscontact] IESG State I-D Exists as of 3/6/24-->
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-reg
		ext-rdap-jscontact.xml"/>

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
		05.xml"/>

		</references>
		</references>
		<section anchor="Acknowledgements" numbered="false">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>The authors wish to thank the following persons for their feedback and suggestions:	<t>The authors wish to thank the following persons for their feedback and suggestions:
	<contact fullname="Marc Blanchet"/>,	<contact fullname="Marc Blanchet"/>,
	<contact fullname="Tom Harrison"/>,	<contact fullname="Tom Harrison"/>,
	<contact fullname="Scott Hollenbeck"/>,	<contact fullname="Scott Hollenbeck"/>,
	<contact fullname="Pawel Kowalik"/>,	<contact fullname="Pawel Kowalik"/>,
	<contact fullname="Mario Loffredo"/>,	<contact fullname="Mario Loffredo"/>,
	<contact fullname="Gustavo Lozano"/>,	<contact fullname="Gustavo Lozano"/>,
	<contact fullname="Andy Newton"/>,	<contact fullname="Andy Newton"/>,
	<contact fullname="Jasdip Singh"/>,	<contact fullname="Jasdip Singh"/>,
	and <contact fullname="Rick Wilhelm"/>.	and <contact fullname="Rick Wilhelm"/>.
	</t>	</t>
	</section>	</section>

	</middle>
	<back>
	<references>
	<name>References</name>


	<references>	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	<name>Informative References</name>	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	&I-D.ietf-regext-rdap-jscontact;	and let us know if any changes are needed.
	&RFC8605;
	</references>


	<references>	For example, please consider whether "whitespace" should be updated.
	<name>Normative References</name>	-->
	&RFC2119;
	&RFC6350;
	&RFC7095;
	&RFC7942;
	&RFC8126;
	&RFC8174;
	&RFC8259;
	&RFC9082;
	&RFC9083;
	&I-D.ietf-jsonpath-base;
	</references>
	</references>
	<section numbered="true" toc="default">
	<name>Change History</name>
	<section anchor="change-00-to-01" numbered="true" toc="default">
	<name>Change from 00 to 01</name>
	<ol spacing="compact" type="1">
	<li>Changed rdapConformance to use pointed "redacted_0.1" value to sup
	port structural changes of the extension up to the target of "redacted_1.0".</li
	>
	<li>
	<t>Updates based on the Gustavo Lozano feedback:</t>
	<ol spacing="compact" type="1">
	<li>Updated the language to change the special treatment of jCard
	to be more generic for future RDAP extensions that leverage fixed length JSON ar
	rays.</li>
	<li>Added "RDAP extensions should define any special JSONPath cons
	iderations required to identify redacted RDAP fields if the these considerations
	are insufficient." to the JSONPath
	Considerations section to generalize it.</li>
	</ol>
	</li>
	<li>
	<t>Updates based on the Marc Blanchet feedback:</t>
	<ol spacing="compact" type="1">
	<li>Added a reference to draft-ietf-regext-rdap-jscontact as an
	example of an RDAP extension that is suited for the Redaction by
	Removal Method based on the lack of dependency on positional JSON arrays.</li>
	<li>Added support for registered and unregistered (free-form) reda
	ction reasons by changing the "reason" property to be a JSON object with the "ty
	pe" and "description" properties.
	The "type" property includes registration in the IANA JSON Value
	s Registry.</li>
	<li>Added a "JSON Values Registry" section in the IANA Considersat
	ions section to define the
	"redaction reason" JSON Values Registry Type values to support t
	he registration of redaction reasons.</li>
	</ol>
	</li>
	<li>
	<t>Updates based on the Mario Loffredo feedback:</t>
	<ol spacing="compact" type="1">
	<li>Added support for registered and unregistered (free-form) reda
	ction names by changing the "reason" property to be a JSON object with the "type
	" and "description" properties.
	The "type" property includes registration in the IANA JSON Value
	s Registry.</li>
	<li>Added a "JSON Values Registry" section in the IANA Considersat
	ions section to define the
	"redaction name" JSON Values Registry Type values to support the
	registration of redaction names.</li>
	<li>Added a JSONPath Considerations item associated with handling
	entities with multiple roles.</li>
	<li>Added language to restrict the extension to responses.</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-01-to-02" numbered="true" toc="default">
	<name>Change from 01 to 02</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates to add support for RDAP search responses:</t>
	<ol spacing="compact" type="1">
	<li>Replaced "RDAP lookup response" with "RDAP response" throughou
	t the draft to expand the scope to include search.</li>
	<li>Updated the description in the second paragraph of the Introdu
	ction to cover both a lookup response and a search response.</li>
	<li>Added an example of the use of an absoluate path for a search
	response to the "JSONPath Considerations" section.</li>
	<li>Added a description of the placement of the "redacted" member
	in a lookup response and a search response in the ""redacted" Member" section.</
	li>
	<li>Added an example of an unredacted search response and a redact
	ed search response in the ""redacted" Member" section.</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-02-to-03" numbered="true" toc="default">
	<name>Change from 02 to 03</name>
	<ol spacing="compact" type="1">
	<li>Fixed mismatch of the extension identifier, which was updated to "
	redacted_0.1" throughout the draft based on feedback from Mario Loffredo.</li>
	<li>Added the JSONPath Considerations item associated with redacting f
	ields for multiple entities with the same role based on implementation feedback
	from Mario Loffredo.</li>
	<li>Added the Implementation Status section that includes the server i
	mplementation by Mario Loffredo.</li>
	<li>Added use of numbered figures for easy reference for JSON Values R
	egistry registrations.</li>
	<li>Updated the example unredacted and redacted lookup responses to in
	clude the "objectClassName" and "handle" members.</li>
	<li>Changed RFC7482 and RFC7483 references to RFC9082 and RFC9083, res
	pectively.</li>
	</ol>
	</section>
	<section anchor="change-03-to-04" numbered="true" toc="default">
	<name>Change from 03 to 04</name>
	<ol spacing="compact" type="1">
	<li>Changed the extension identifier to be "redacted" instead of a ver
	sioned value, which will be leveraged for both the rdapConformance value and the
	JSON Values.</li>
	<li>Changed the RDAP Conformance to be "redacted_level_0.2", which lev
	eraged the extension identifier as a prefix along with "_level_" and a pointed v
	ersion number.
	The version number will become "1.0" once the draft passes WGLC.</li
	>
	<li>Added the Redaction by Replacement Value Method.</li>
	</ol>
	</section>
	<section anchor="change-04-to-05" numbered="true" toc="default">
	<name>Change from 04 to 05</name>
	<ol spacing="compact" type="1">
	<li>Update the RDAP Extensions Registry entries to include the identif
	ier that is used for the RDAP conformance value and to
	include the "redacted" prefix indentifier to use for the JSON respon
	se member.</li>
	<li>Changed the RDAP Conformance to be "redacted_level_0_3", which is
	registered in the RDAP Extensions Registry.
	The RDAP Conformance value will become "redacted_level_1" once the d
	raft passes WGLC.</li>
	</ol>
	</section>
	<section anchor="change-05-to-06" numbered="true" toc="default">
	<name>Change from 05 to 06</name>
	<ol spacing="compact" type="1">
	<li>Fixed a couple nits.</li>
	<li>Updated the Redaction by Replacement Value Method email web form e
	xamples to use the "contact-uri" jCard property of RFC 8605.</li>
	</ol>
	</section>
	<section anchor="change-06-to-07" numbered="true" toc="default">
	<name>Change from 06 to 07</name>
	<ol spacing="compact" type="1">
	<li>Added the optional replacementPath child member for use with the R
	edaction by Replacement Value Method.</li>
	</ol>
	</section>
	<section anchor="change-07-to-08" numbered="true" toc="default">
	<name>Change from 07 to 08</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates based on the Rick Wilhelm feedback:</t>
	<ol spacing="compact" type="1">
	<li>Updated the definition of a redacted RDAP field in the Introdu
	ction section.</li>
	<li>Updated the reference to three methods instead of two in the R
	edaction Methods section.</li>
	<li>Created a new paragraph for the example in the Redaction by Re
	moval Method section.</li>
	<li>Explicitly specified one or more redacted fields for inclusio
	n of the "redacted" member in the "redacted" Member section.</li>
	<li>Updated the description of the "method" member in the "redacte
	d" Member section.</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-08-to-09" numbered="true" toc="default">
	<name>Change from 08 to 09</name>
	<ol spacing="compact" type="1">
	<li>Updated the RDAP extensions Registry registration and RDAP conform
	ance to match the working group consensus that does not include
	a version with "redacted".</li>
	</ol>
	</section>
	<section anchor="change-09-to-10" numbered="true" toc="default">
	<name>Change from 09 to 10</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates based on the Pawel Kowalik feedback:</t>
	<ol spacing="compact" type="1">
	<li>Changed "placeholder text value will not match the format requ
	irements" to "placeholder text value may not match the format requirements" in S
	ection 3.</li>
	<li>Changed the "path" member OPTIONAL and added "The "path" membe
	r MUST be set when the redacted field does exist in the redacted response" to co
	ver when it's required.</li>
	<li>Added the definition of the "redacted expression language" JSO
	N Values Registry Type in the IANA Considerations and pre-registered the "jsonpa
	th" "redacted expression language" value.</li>
	<li>In the definition of the "path" member, added clarification wh
	ether the "path" member expression refers to the pre-redacted response field or
	the redacted response field based on the redaction method.</li>
	<li>Replaced "The Redaction by Removal Method MUST NOT be used to
	remove a field using the position in a fixed length array to signal the redacted
	field" with
	"The Redaction by Removal Method MUST NOT be used to remove an e
	lement of an array where the position of the element in the array determines sem
	antic meaning" in Section 3.1.</li>
	<li>Added the "JSONPath Client Considerations" and "JSONPath Serve
	r Considerations" subsections to the "JSONPath Considerations" section.</li>
	</ol>
	</li>
	<li>
	<t>Updates based on the Mario Loffredo feedback:</t>
	<ol spacing="compact" type="1">
	<li>Revised Figure 7 to reference the "email" property and the "co
	ntract-uri" property instead of the value elements of the properties.</li>
	<li>Rephrased the sentence in section 4.2 to 'The "redacted" membe
	r contains an array of objects with the following child members'.</li>
	<li>Added the Redaction by Partial Value Method for redaction of a
	portion of a formatted property, such as the jCard "fn" and "label" properties.
	</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-10-to-11" numbered="true" toc="default">
	<name>Change from 10 to 11</name>
	<ol spacing="compact" type="1">
	<li>Updated Abstract and first sentence of Introduction to "This docum
	ent describes an RDAP extension for specifying methods of redaction of RDAP resp
	onses and explicitly identifying redacted RDAP response fields, using JSONPath a
	s the default expression language.", based on feedback by Pawel Kowalik.</li>
	<li>Changed "path" member to a "prePath" and "postPath" member to indi
	cate whether the path expression applies to the pre-redacted or post-redacted re
	sponse, based on feedback by Pawel Kowalik.</li>
	</ol>
	</section>
	<section anchor="change-11-to-12" numbered="true" toc="default">
	<name>Change from 11 to 12</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates based on the Andy Newton feedback:</t>
	<ol spacing="compact" type="1">
	<li>Added section "The resulting redacted RDAP response MUST compl
	y with the RDAP RFCs, such as [RFC9083]" as second sentence of Section 3.</li>
	</ol>
	</li>
	<li>
	<t>Updates based on the Tom Harrison feedback:</t>
	<ol spacing="compact" type="1">


	<li>Added clarification in Section 2 "Conventions Used in This Doc
	ument" that the JSONPath expressions in the examples are for illustration purpos
	es with single-role entities and the exact expressions to use by the server are
	out-of-scope.</li>
	<li>Replaced consideration #4 "When an entity has multiple roles..
	." in Section 5.2 "JSONPath Server Considerations" with the recommended language
	starting with "It is possible for there to be muliple bases for redaction..."</
	li>
	<li>Revised the sentence "The client can first key off the "name"
	member for display logic and utilize a template RDAP response overlaid with the
	redacted response
	to successfully resolve the JSONPath expression." in Section 5.1 "JSON
	Path Client Considers" to "The client can key off the "name" member for display
	logic related to the redaction.".</li>
	<li>Replaced "type" with "description" for the example redaction "
	name" and "reason" members, so not to infer that they are being registered for u
	se.</li>
	<li>Changed "Two new JSON Values Registry Type field values are us
	ed to register pre-defined redacted name and reason values" in Section 6.2 "JSON
	Values Registry" to
	"Three new JSON Values Registry Type field values are used to regi
	ster pre-defined redacted name, reason, and expression language values".</li>
	</ol>
	</li>
	<li>
	<t>Updates based on validating each of the draft examples:</t>
	<ol spacing="compact" type="1">
	<li>Added missing comma between the "Administrative Contact" and "
	Billing Contact" "redacted" members.</li>
	<li>Removed consideration #5 in Section 5.2 "JSONPath Server Consi
	derations" since the use of the JSONPath expression "$.entities[?(@.roles[0]=='t
	echnical')][0]" is not valid and the exact JSONPath expression to use is out-of-
	scope.</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-12-to-13" numbered="true" toc="default">
	<name>Change from 12 to 13</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates based on the Jasdip Singh feedback:</t>
	<ol spacing="compact" type="1">
	<li>In Section 1, replaced the sentence "The redacted JSON fields
	will either be removed or have empty values in the RDAP response" with
	"The redacted JSON fields will either be removed, have empty value
	s, have partial values, or be replaced in the RDAP response.".</li>
	<li>In Section 3, changed the reference of three categories to fou
	r categories.</li>
	<li>In Section 3.1, changed ", which is the preferred method" to "
	, which is the default method"
	to clarify the Removal Method as the default redaction method.</li
	>
	<li>In Section 4.2, updated the sentence to read
	"The "redacted" member is included as a member of the object insta
	nce in a lookup response,
	for the object classes defined in [RFC9083], and as a member of th
	e array of object instances in a search response.".</li>
	<li>In Section 4.2, explicitly defined the "name" member as REQUIR
	ED".</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-13-to-14" numbered="true" toc="default">
	<name>Change from 13 to 14</name>
	<ol spacing="compact" type="1">
	<li>Replaced RFC 7483 reference with RFC 9083 based on the Document She
	pherd review by Andy Newton.</li>
	<li>Replaced the "Registrant Name" "IESG" value with "IETF" for the "RD
	AP JSON Values Registry" registrations.</li>
	<li>
	<t>Updates based on the Murray Kucherawy AD evaluation feedback:</t>
	<ol spacing="compact" type="1">
	<li>Combined sentences on the use of placeholder text in Section 3
	"Redaction Methods" for clarification.</li>
	<li>Changed the two SHOULDs to MUSTs in Section 3.2 "Redaction by E
	mpty Value Method".</li>
	<li>Changed "alternate" to "alternative" in Section 3.4 "Redaction
	by Replacement Value Method".</li>
	<li>Changed "JSON expression" to "JSON path expression" in Section
	4.2 "</li>
	<li>Changed references of "JSON Values Registry" to "RDAP JSON Valu
	es Registry" to match the IANA registry name.</li>
	</ol>
	</li>
	</ol>
	</section>
	<section anchor="change-14-to-15" numbered="true" toc="default">
	<name>Change from 14 to 15</name>
	<ol spacing="compact" type="1">
	<li>Based on feedback from Paul Wouters, moved the Security Considerati
	ons language to Section 4.2 ""redacted" Member", since exclusion of a "redacted"
	child member due to privacy is a feature. The Security Considerations section
	was made generic.</li>
	<li>Revised the RDAP JSON Values Registry IANA Considerations used to r
	egister pre-register the pre-defined
	redacted name, redacted reason, and redacted expression language values
	based on Scott Hollenbeck's expert review feedback.</li>
	</ol>
	</section>
	<section anchor="change-15-to-16" numbered="true" toc="default">
	<name>Change from 15 to 16</name>
	<ol spacing="compact" type="1">
	<li>
	<t>Updates based on feedback from Roman Danyliw:</t>
	<ol spacing="compact" type="1">
	<li>Updated "Redaction in RDAP can be handled in multiple ways. The
	resulting redacted RDAP response MUST comply with the RDAP RFCs, such as [RFC90
	83]" to
	"Redaction in RDAP can be handled in multiple ways. The resulting r
	edacted RDAP response MUST comply with the format defined in the RDAP RFCs with
	the RDAP RFCs, such as [RFC9083] and updates"</li>
	<li>Add "The server MAY choose to publish a redaction policy descri
	bing how this extension is implemented for their constituency. The contents of s
	uch a policy are outside the scope of this specification."
	to Section 4.2 ""redacted" Member".</li>
	</ol>
	</li>
	</ol>
	</section>
	</section>
	</back>	</back>
	</rfc>	</rfc>

End of changes. 110 change blocks.
	835 lines changed or deleted	571 lines changed or added
This html diff was produced by rfcdiff 1.48.