Since I’m named below, response inline. > Le 29 mai 2024 à 08:57, Gould, James <jgould=40verisign....@dmarc.ietf.org> a > écrit : > > Andy, > > Thank you for providing information on the client implementation experience. > I will review all the content in detail to provide my thoughts on how to > address the issues. Much of your feedback is associated with the > complexities of processing the JSONPath expressions, which provides an > optional hint to the clients. The RDAP JSON responses are inherently complex > with the mix of structured and unstructured content with jCard. > > At a minimum, the client can re-display the list of redactions to the end > user in a user-friendly manner by keying off the “name” and “method” members. > A standard set of “name” values can be defined by registering the “redacted > name” RDAP JSON Values, which include a description that is meant for manual > review by client implementors and not programmatic discovery. Such as the > following for Figure 12: “Redacted RDAP Lookup Response” in RFC 9537: > > Redacted by Removal: > > Registry Domain ID > Registrant Name > Registrant Organization > Registrant Street > Registrant City > Registrant Postal Code > Registrant Email > Registrant Phone > Technical Name > Technical Email > Technical Phone > Technical Fax > Administrative Contact > Billing Contact > > The “emptyValue” and “removal” method are different forms of removal, so they > can be grouped in the removal bucket for the end users. > > Is there any other experience from client implementers (e.g., Marc Blanchet) > that can be shared?
I’ve been busy on other projects, so redaction is on my todo list. I did some initial coding, but it is now on hold. In my mind when I read the draft sometime ago, - removed is something that was not a concern to me (in terms of implementing something specific). I thought of just showing what I received. A nice to have would have been to show the field name and then display an icon to show the value has been removed. I’m still not sure the real value of this, especially since my experience with real RDAP responses is that so many fields are in this category, therefore showing all kinds of fields with a « removed » tag does not look great in my mind for a UI. - my key point was to make sure that all the boiler plate text that varies from each registry/registrar such as « This field has been removed » would not appear to the user, but instead in a more UI friendly, which in my mind is either: do not show anything, or if field was changed, then I would display the value of the field but with some icon telling the user the field has changed from its primary value. Hoping that these boiler plate fields would be removed by the registries/registries and instead signalled them in the jsonpath meta data. Having all said that, I reserve the right to change my mind as I implement it ;-) So at the moment, I cannot help much in this discussion, as I haven’t implemented it yet. Regards, Marc. > > Thanks, > > -- > > JG > > <image001.png> > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > From: "Andrew Newton (andy)" <a...@hxr.us> > Date: Wednesday, May 29, 2024 at 6:51 AM > To: "regext@ietf.org" <regext@ietf.org> > Subject: [EXTERNAL] [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 > > <https://secure-web.cisco.com/1mPMfNI2zob5OY_RHSNl_P1tnUeETO0o09c0W99TATan4s3PHChO6Kh1GiGUrfpIOmq6rKMwYi0JSWGkAQs2-cjvAkdc7uWAKWTZ_6BxEYYPPJgxWQILWPHRcZ_Tpd5HTVE30WZyezOXpEI0mSmbMrUK_Q30sXwoF87IHofTbGV7STLZFRkmmNTofEO74X4EQY6enivux3oILbYyXDii0CLePuRqOAZ4Qp3aWC4SLOnsSriEi-34rlQSYQIjI6h7_Q-SH5FjXk1QGLcdhrptCiGgVCA6f7sRzI_WC4NHhZtk/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00.txt> > Status: > https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/ > > <https://secure-web.cisco.com/1fNr0Hl9vsQaWidCOrR4dk8_7jjg-1TO_r1Bszl7rGuy8SKgw9GD6cCHI2YQnFxZdFFx5WZupc9gOjmLjjgcXrwyw-FTAWtkrPceSmR8xS87wUYeveCOq1QLrIj4GDwrSRyf8sAFwiQYIsMI6NTjxHl8mRM92bJEyMP7j64D3uMXkuv_wKVyOaHvmd7-C272ah5DqW4YenHArcCZ5tON4CO43CGN2Gra2u9d5V6C6ARisZgLcHvKN4LtnkGoIqHmLHj0ZoH-8EY_r6zhnNgmb2DIOfwC6iYe8JRpJDQSsjx4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-considerations-on-rfc9537%2F> > HTML: > https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html > > <https://secure-web.cisco.com/1aste1pdAhq_TMFqsj5FriZl0Uu9f059LMSBJJnZqQV8xMWJnw9mkTR_sut4SqV4A8VXdSyu1ww4Z2J2gjs5GBNL61WGWNc_vpADz1cHfghH-SEa5EVH9VBgPFz8_Ew3N05VZTPteEm5fSDNjw_XFAR4zGVO162EDUHyhOAqZAusu5i-6fTmy4axI-u_ydLzKqM-O_Js9MmBNrLEoryJrgBB66uvGkEFJcfezAumeAFoCPxkE2aOqSRYvzCnsZkbnuoVWtt1RPY4-DHYLP63OrtDx3JK8Mcs0YORdR20d_Pw/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00.html> > HTMLized: > https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537 > > <https://secure-web.cisco.com/1REPzMDdSw__QNYdJu2_kLVewC2cr1haTsVsmIarmU-cprYlCco2gFbdcSX2pPVwrfkcM-fCQxOEmba-0NcdZQ8IR0Y_-IExINWk53AiyGysA7lIGTNK7YqmMbWN_SmcpSNs7U_EhZ3fF14yDoZcqVkZHSMj0Kr8uRcPKB-IX3iArW3ZIayS2xHbCk3IxP-9otAp-K4QUd5jSUl9HByZpvm-6VrZ3dLoQtnXneeWnlpSlq0EPIiuZHgTTJTGChawd9d8MAHlybuEab0icvIWBx1HmwSiVVT-nn9ryTJCBqjM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-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 > To unsubscribe send an email to regext-le...@ietf.org
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
