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 "&#160;">
eference.RFC.6350.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC7095 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/r <!ENTITY nbhy "&#8209;">
eference.RFC.7095.xml"> <!ENTITY wj "&#8288;">
<!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&nbsp;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 &quot;&quot; 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
&quot;rdapConformance&quot; (<xref target="RFC9083" format="default"/ "rdapConformance" <xref target="RFC9083"/> value of "redacted".
>) value of &quot;redacted&quot;. The "redacted" extension identifier is described in <xref target="rda
The &quot;redacted&quot; 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 &quot;rdapConformance&quot; 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>&quot;rdapConformance&quot; 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>&quot;redacted&quot; Member</name> <name>"redacted" Member</name>
<t>The &quot;redacted&quot; 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 &quot;redacted&quot; 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 &quot;redacted&quot; 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 &lt;iesg@ietf.org&gt;</dd> <dd>IESG &lt;iesg@ietf.org&gt;</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 &quot;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 &quot;alpha&quot; 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.