> Le 30 mai 2024 à 08:01, Gould, James <jgo...@verisign.com> a écrit : > > Marc,
Sorry to take long time to respond. I was hoping to have time to look closely before responding, but did not find time. So right now I can’t really help since I haven’t gone enough far into the implementation to properly respond. Sorry. Will respond when I will be more in. 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 > > <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: Marc Blanchet <marc.blanc...@viagenie.ca > <mailto:marc.blanc...@viagenie.ca>> > Date: Wednesday, May 29, 2024 at 2:59 PM > To: James Gould <jgo...@verisign.com <mailto:jgo...@verisign.com>> > Cc: Andrew Newton <a...@hxr.us <mailto:a...@hxr.us>>, Registration Protocols > Extensions <regext@ietf.org <mailto: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 >> <mailto: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 <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: [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 <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
