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: kowa...@denic.de <kowa...@denic.de> Date: Tuesday, June 11, 2024 at 7:57 AM To: regext@ietf.org <regext@ietf.org> 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) <a...@hxr.us><mailto:a...@hxr.us> Date: Wednesday, May 29, 2024 at 6:51 AM To: regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org> 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: internet-dra...@ietf.org<mailto: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: 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 -- regext@ietf.org<mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org<mailto:regext-le...@ietf.org>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
