RFC 9537, "Redacted Fields in the Registration Data Access Protocol (RDAP) Response", March 2024

Errata ID: 8004
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: James Gould
Date Reported: 2024-06-26
Rejected by: Orie Steele
Date Rejected: 2024-08-12

Throughout the document, when it says:

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

It should say:

This document describes a Registration Data Access Protocol (RDAP)
extension for specifying methods of redaction of RDAP responses and
explicitly identifying redacted RDAP response fields.

Notes:

The Abstract and the first sentence of the Introduction is "This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language.". This sentence is combining two aspects into a single sentence ("explicitly identifying redacted RDAP response fields" and "using JSONPath as the default expression language") incorrectly. It is true that the extension is "explicitly identifying redacted RDAP response fields" and it's true that extension is "using JSONPath as the default expression language", but the expression languages are optional and the use of JSONPath as the default expression language is not relevant for the Abstract and first sentence of the Introduction. The recommended change is to remove the ", using JSONPath as the default expression language" from the sentences to correct it, resulting in:

"This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields."
--VERIFIER NOTES--
Per https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/

I considered HFDU based on:

>Technical items that have a clear resolution in line with the original intent should be classified as Verified. If the resolution is not clear or requires further discussion, the report should be classified as Hold for Document Update. In both cases, only items that are clearly wrong should be considered.

However, it is not obvious to me that this is "clearly wrong".

>The erratum is invalid or proposes a significant change to the RFC that should be done by publishing a new RFC that replaces or updates the current one. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list.

It seems to me that the correct solution is a -bis document, especially if the intention is to clarify mandatory or optional implementation details that impact interoperability.

Report New Errata