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/
Kind Regards, Pawel On 11.06.24 06:28, Jasdip Singh wrote:
Hi.It is a bit unfortunate for us as a WG that we missed the fundamental shortcomings of the JSONPath usage for redaction, as highlighted in the draft below. Especially, the “prePath” portion where a client would have no idea about how to apply that expression to the response in hand. Though the JSONPath use is optional in RFC 9537, that does not help escape the fact that portions of this extension are inherently incorrect. Not sure what the path forward is from here but IMO it would help to address the highlighted issues; either as RFC 9537 bis, or an entirely new approach that does not depend on JSONPath.Jasdip *From: *Andrew Newton (andy) <a...@hxr.us> *Date: *Wednesday, May 29, 2024 at 6:51 AM *To: *regext@ietf.org <regext@ietf.org>*Subject: *[regext] Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txtHi all,Over the past several months, we have been implementing the RDAP redaction extension, RFC 9537.This I-D describes the issues we have encountered. -andy -------- Forwarded Message -------- *Subject: *New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt*Date: * Wed, 29 May 2024 03:45:43 -0700 *From: * internet-dra...@ietf.org *To: * Andy Newton <a...@hxr.us> <mailto:a...@hxr.us> A new version of Internet-Draft draft-newton-regext-rdap-considerations-on-rfc9537-00.txt has been successfully submitted by Andy Newton and posted to the IETF repository. Name: draft-newton-regext-rdap-considerations-on-rfc9537 Revision: 00 Title: Considerations on RFC 9537 Date: 2024-05-29 Group: Individual Submission Pages: 12URL: https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Status: https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/ HTML: https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537Abstract: This document discusses client implementation issues relating to RFC 9537, “Redacted Fields in the Registration Data Access Protocol (RDAP) Response”. The considerations in this document have arisen from problems raised by two separate teams attempting to implement RFC 9537 in both an RDAP web client and an RDAP command line client. Some of these problems may be insurmountable, leaving portions of RFC 9537 non-interoperable between clients and servers, while other problems place a high degree of complexity upon clients. The IETF Secretariat _______________________________________________ regext mailing list --regext@ietf.org To unsubscribe send an email toregext-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
