Jasdip, I have option 5, which is to get more implementation experience with RFC 9537. I believe that the ICANN clients can implement RFC 9537 using the required “name” and “method” members in the redacted extension, as I demonstrated with the simple JSON clients. There will be many server implementations leveraging the registered “redacted name” entries by the gTLD registrars and registries. These clients and servers may or may not leverage the optional JSONPath expressions (“prePath”, “postPath”, “replacementPath”). I don’t consider removing support for JSONPath expressions as an issue of correctness of Option 2, since the JSONPath expression members are optional in RFC 9537. There are many examples of features defined in other RFCs that had no adoption or had very little adoption (e.g., protocol extension in RFC 5730, data-collection policy in RFC 5733, key data interface in RFC 5910, account balance and credit limit in RFC 8748) over the years.
With implementations starting with RFC 9537, I would first see how those implementations work out. 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: Jasdip Singh <jasd...@arin.net> Date: Saturday, June 15, 2024 at 2:50 PM To: Mario Loffredo <mario.loffr...@iit.cnr.it> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, Mario, sorry for my late reply. Agree that JSON objects seem more conducive to pinpointing redaction than JSON arrays, and preferring JSONPath over JSONPointer. But, overall, the challenge remains for us to somehow address the JSONPath deficiencies identified in Andy’s paper, to end up with a normative, correct redaction spec for RDAP data. Please allow me to explain how we might be able to move forward here. Imagine a JSON response from an RDAP server as a text document, and with parts of that text redacted. Since such a document would be structured for RDAP, beside human-friendly perception of redacted text (like we cannot see redacted words or lines in a redacted text document), we would need precise pinpointing of fields whose values are fully or partially redacted, especially if one were to build a general-purpose RDAP client serving all industries (be it DNRs, RIRs, space, etc.). We thought JSONPath could but seems deficient, especially for prePath scenarios and wildcard and recursive selectors. IMO, we have few options to help achieve a normative, correct redaction spec: Option 1: Try addressing deficiencies identified in Andy’s paper vis-à-vis the JSONPath and name approaches. Option 2: Gut out the JSONPath approach completely to improve correctness of RFC 9537. Option 3: As for the current name approach in RFC 9537, set the expectation that clients would need to hardcode the redacted name to field name mapping for IANA-registered names, periodically check the IANA registry for newer name registrations, and that mapping unregistered names to field names could be problematic in terms of a client missing some. Option 4: Look for another way to do redaction that guarantees redacted field name pinpointing correctness. We might eventually need a WG poll on these options, or another set of options, but let me try assessing above options: Doesn’t look Option 1 could be fully achieved, especially because of prePath scenarios and wildcard and recursive selectors. Option 2 helps. Option 3 won’t make general-purpose client implementors happy. Option 4 might need to work with some assumptions/constraints, like what JSON types (out of string, number, boolean, array, and object) it guarantees redaction pinpointing accuracy for when it comes to RDAP data. In other words, there does not seem to be a redaction panacea out there. :) Thanks, Jasdip From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Tuesday, June 11, 2024 at 6:27 AM To: Jasdip Singh <jasd...@arin.net>, Andrew Newton (andy) <a...@hxr.us>, regext@ietf.org <regext@ietf.org> Subject: Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Hi Jasdip, I'm inclined to think that the problem lies in how the JSON content is structured rather than the language used to select JSON values. There exist two standard languages to select JSON values, namely JSONPointer and JSONPath. The former is mostly inapplicable to RDAP as the values that are likely redacted are located in the entity object but entities associated to an object are represented through an array where the entity role matters instead of the index. The latter works much better but the selection of values in the RDAP response generates language expressions that are very tricky to process because the jCard format makes use of jagged arrays where items are selected by property name or by index. The additional issue in redacting arrays is that redacting an item by removal results in rearranging the array items. On the contrary, redacting an object member by removal doesn't impact on the other members. Definitely, objects i.e. maps should be preferred to arrays as much as possible because they fits better the redaction process . If you can't avoid arrays, you should consider to redact the entire array whenever the items must be redacted. Sorry if I recall once again the implementation choice Robert and I made when we had to deal with localizations in JSContact but it comes to mind easily. Localization as well as redaction requires to select a JSON value. To facilitate localizations, we decided to use maps to represent almost all collections in JSContact and mandate the localization of the entire array of name and address components. IMO, we should do likewise to best accomplish redaction in RDAP. Here in the following two JSONPath expressions extracted from a redacted domain lookup response using jCard [1] and JSContact [2] respectively: "prePath": "$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]"<mailto:$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]>, "prePath": "$.entities[?(@.roles[0]=='technical')].jscard.phones.voice"<mailto:$.entities[?(@.roles[0]=='technical')].jscard.phones.voice> Please note that in the case of a redacted entity lookup response, the latter would include only the name selector. Obviously, using maps to represent the collections of entities associated to objects would be very helpful but some issues connected with the entity role should be fixed first (i.e multiple entities having the same role and single entites having multiple roles). However, representing the contact data through a fully object-oriented format, no matter if it will be JSContact or something else, would make redaction handling by clients as well as the overall handling of the RDAP response much easier. Best, Mario [1] https://rdap.pubtest.nic.it/domain/meep.it<https://secure-web.cisco.com/1EufMWCq2of7t82pkxPzZQNBqVpR4AIfG9meUSBIYQEAxEQeHDKRlseJ0yEZHTeIhdCDDhPxFDPe5aL0DxGJGSm5q_TUgqIPmWXaLeS85CEEQq7bUmBs1iptcC_-i-GYccOgc34MDRQx1QXOANY_FY6bl6I20OCWAi98tRcLf8tC0vvpxX7-RC7dM_atAM8s1PCqrsLK0zfXroTyAhTvLjkww_MO-vavbiU9P6JCuGj6-gR1W6DlytZje97Om7Z8vTLM_J8iytT0vEbHmpT7KxYspgXWF4A0-sDkQ9L2yZuA/https%3A%2F%2Frdap.pubtest.nic.it%2Fdomain%2Fmeep.it> [2] https://rdap.pubtest.nic.it/domain/meep.it?jscard=1<https://secure-web.cisco.com/1QMvAVm7TYbuUghjwAf9NsvfsNNE1PYTsIqFt4IafWBMjDLEM6CaIf9X7vNB5Hcf6FgQdoexgfVULOVjOMyZD9WV-drlfvb0pfB9x0KSOv3Te-RLYJ0FNm2Y7dsUlvJqIKJ00CODjxqjbIS0oy2XHbNOydxa6iPWcWDc9Y8kRPfThiVGc-KeA5c_UZCzN5961eP_YwRFAIiCdTkEZVw3zauH47uHry9_AUBjpg9ns0xIhX71LiANW6EpoarRWdZ7qpB_3dtQFWdCBNZ1T1ZnJPJMCr2x0Iyv5OscqRcqviOY/https%3A%2F%2Frdap.pubtest.nic.it%2Fdomain%2Fmeep.it%3Fjscard%3D1> Il 11/06/2024 06:28, Jasdip Singh ha scritto: 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<https://secure-web.cisco.com/1Yq7IPhJZdoiKCZ_ULXyOoBQiSnM6Lkh4-bQx66qxIVq-9F9nP-cVfF26gzOYtNBqr8KYRWc2p2BfnpDXXdUF18b3gRjw6FJ6JYMsoEa7ELfQu9ndOtsunqM4VUUwmixXIaJs1JJuWn5QFdlN7M6hCbut5QgjMRqutshYDijjW-flQusoaqS-Ue4QjzApPfOalMM8uNx18j1e3f6OiXaBHykxdw_r-FRMrUH3i7ToGcWDwf_I7SE7rZoWNbOnqu3g_2YLQJnifcJfko3p37Q3iocY3sYnrVjtGS3aSu3sviM/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/10mmYqlZTaebafgwBBV40W1sYZjhA2AvXsOgXd5xCHF6m5bJkGg7DCP4h5aiIGlE-eU3VJK79gjuOnnMQqQGP73jgNxYLlS8CpmhVKxCa6NxMhLABVULKP6hqO9lvMw1o1ReiVyPjzQjJSzFFi3llvnK8GLolpE03mV9zBPBnmkaqUtThregzKskWM0aVEqLTkqOCyDMUvQ5XZE-HcWf82V2PJl5qmefulcAOfCGKm3JtilCPgx6xhRovnjHfr45UGGOD7pA0JGKkMfqkaOTArw28_4B3sGrFnWN75hUlK40/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/1EecrxubV6KBffnGqMiLBOZ6UVnTMS5rro3w6OX10_KinuBBiCWlowZlkENbIGPim7GjZTM4MYLVdfRwHDrlV-Q-fl_PbKqOs2BQmsWlrtVqYisG0Ra6gCpQy7ioDgYqCQOurevxYhTkiyl7kZXw14HAnNQuekAN4XHAMJsNHBa7K_5hylZWNvYzeX6iNYNHR0EBBliRIUVthZm89SqsbC5DyyID1ZPA-8ehg0zmTMPwFceXz2ju97kP0TxX_RANOe1wf_8bZ_3MMMY7CAIBbV4PQMcFPh8bTirmGFg5MNuA/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/1MKjEAxFrjuFhDW0AyQrXERa2geOrjx3XNODFgMi3HABR5Y89_xHSzZ6MmvD2SrzgbH_WfmqOE1nKWC5S8jijbuA9pU7CZOSoxvVNjrTt0UXgn_OEeglqPf1M_4afjxiqF3idcUEGSIr80zRZs6hEbE8HTqZfywvZwZZJqzj2nlU9bDasfq2G5Snf2BOBgJPn75cJRnGBrlvehb2AmeKmNhIdPNwFs_ZTvOK75AF4EPfcvE_hBYjO-o-8GK1EIC4LUseArvPPqi7oW-mZN9AbDAkm6lWBGCRE80d-9o82Ivc/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> -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1itviCWtpdUa2uLZj1NragR74jOeUd45_NJA292eWkdEVshH3QrKa7DUko0guKQ8nbQs3do15kpBC2UgcV9wfCMNJ_-GXmYvBEuiqRBbNheJ9QCNg1kLpeW2SpF7Ia9MXDFHoap6yfOzWzKLLN9yKq3_a5W4qtQqwhLtekVUuluEWCA7vLmKf68o5dw9IHfyd6h_hqra9x-Gtj0O5yyJKQUR71mjoN0coz5BSCVNGzhjQ2Sc7sm5rtWMCMq5KOrmFm5PTGNvhtf-V0oTEZooJO59CSEinTNWHSmwlePD_ros/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
