Marc, Thank you for providing your perspective on implementation of RFC 9537. To help in your decision to implement for the gTLDs, ICANN has registered a set of “redacted name” entries in the RDAP JSON Values based on Appendix E of the RDAP Response Profile, Version 2.2. This means that the required “name” members for each redaction may include a standard “type” field value.
If you were to implement RFC 9537, would your client focus on the “name” and “method” members of the redacted items, and do you view any inherent issues in using this information from the RDAP response? Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] 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: Marc Blanchet <marc.blanc...@viagenie.ca> Date: Wednesday, May 29, 2024 at 2:59 PM To: James Gould <jgo...@verisign.com> Cc: Andrew Newton <a...@hxr.us>, Registration Protocols Extensions <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt 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://secure-web.cisco.com/1hn_6Il2eD95xv4pWIz_dMa98QzRZ71_mRXIglmmqE4KLLHKw998up4Yd36Waj_IXQrWt0GxCtK9DFa9P0L8dBL9Yr_pS9WcIG4HDNXyGcBRY2o_3eV0DV0JzJ_JfyJxYC4TvDvB_51EoM6-c9FIynH64_7oWvRbPhHZzrlvww4XcrOK9HXrKRRcULaYemLNz7aFZm0IeZAM58y5eiC8A1xNAjZJQcU2ee1rrw59Wrv_EWthAJHrdluVWtKJ0FBeFopfD8fD7_ds_yK5YFLA0bdK977iqKNMMhJV11CQJKoQ/http%3A%2F%2Fverisigninc.com%2F> 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
