Hi Pawel, “Not enough?” – that’s an excellent question. I think 5.1.1 ends up diluting the normativeness of RFC 9537 (as you earlier mentioned in that thread). It’s like an implementor saying, “I can’t use JSONPath for my most frequent (default) removal use case.” and the spec saying, “I know, just use registered/unregistered names instead.” It begs the question that if the redacted fields are so determinative that the name-based approach suffices for some object profile, then why even bother with the JSONPath approach in RFC 9537 when it seems problematic and hard to implement correctly, per Andy’s findings, for not just removal but apparently other use cases as well? Hope we resolve this.
Thanks, Jasdip From: [email protected] <[email protected]> Date: Tuesday, June 11, 2024 at 7:57 AM To: [email protected] <[email protected]> Subject: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt 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) <[email protected]><mailto:[email protected]> Date: Wednesday, May 29, 2024 at 6:51 AM To: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Hi 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: [email protected]<mailto:[email protected]> To: Andy Newton <[email protected]><mailto:[email protected]> 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: 12 URL: 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-rfc9537 Abstract: 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
