On 6/11/24 07:57, kowa...@denic.de wrote:
Hi,
I think the issue of JSONPath not being easy/possible to interpret in
case of removed paths was brought up on the mailing list and the
conclusion was to key off the "redacted name" rather than base on
JSONPath [1].
This is also what has been covered in 5.1.1 with a clear
recommendation for the client implementers. Not enough?
[1]
https://mailarchive.ietf.org/arch/msg/regext/nP9BZFbwhOkgiMim9s5upRqCYRs/
Section 5 is not normative. And the text says "The client can key off
the "name" member for display logic related to the redaction." But there
is no explanation of how to do it. And the words "display logic" imply
it can be used for an algorithmic method, such as bold red text saying
"REDACTED" where the information would have been placed.
I think any fair reading of this RFC implies the extension provides a
programmatic means using algorithms to "explicitly specify which RDAP
fields are not included in the RDAP response due to redaction" (that is
from section 1, paragraph 1).
The very first prose of this RFC, the abstract, 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.
WRT to redaction by removal, section 3.1 describes it but does not state
that prePath is optional (that is in section 4.2), and the example given
in 3.1 uses prePath.
-andy
p.s. I just reread the archived message above, and it looks like you
identified these issues two years ago. My apologies for a lack of
understanding back then.
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
