We evaluated the possible set of JSON expression languages when starting the draft. JSONPointer did not have enough features to meet the need. I still believe that JSONPath is the best expression language to use, but other expression languages can come on the scene and the extension added expression language extensibility in that case.
The RDAP responses themselves include structured and unstructured content, where no expression language will remove this complexity. The true challenge of using an expression language for formally defining redaction in the case of the “prePath” is the client’s need for a unredacted response to apply the expressions to, which could be done if the server provided a template unredacted response out-of-band or in-band. We could evaluate the capability of returning a template unredacted RDAP response that can be used with a redacted response for visualization. The RDAP responses will vary from server to server based on the flexibility provided in the RDAP RFCs, where there are no magic expressions that can be applied with every response and there are corner cases that may never be met at a fine grain level, such as the use of “partialValue” method of an unstructured member. What is required in the extension is the use of the name and method members, which can provide the clients with the redacted information to display to the end users. I don’t believe many end users will have the need to look at the source JSON, where the JSONPath would be applicable to. Do the ICANN clients see the need to visually display the redaction using JSON? We made the JSONPath expressions optional since they could be used in certain cases. -- 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: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> Date: Tuesday, June 11, 2024 at 6:28 AM To: Jasdip Singh <jasd...@arin.net>, "Andrew Newton (andy)" <a...@hxr.us>, "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 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/1X7qA2avUvP_WytakXSJk-EW105kKgF8Kk_vY8kkFF2xqXZxTEaAomelA9ZfWBkhrkaobJjexS-utzVYFwDlPRO8S_0huHcDrwPstYMbT5BQFWWfFervVwUN1tuTBRdOx2KZTjgR_O7PC83nXsD2I4rg4qrF9mb4qAtKw5sZtr0ivzl7ru6ZF_Co7zQcwY6o1Iki6NsDF_tjfgFnHQueBhVIkL90oyvVosw28aMjx5xCxvGYR0TDE7w7kGaqpM2Mi7gCtQHEWEbWRFb4K-MHneSzQ4mQbq7xm0Vh50585H7c/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/165GuEsXpW2RUUS4SXyXd87lOigbWFmiyd5TWXdGkWP44khIZfbwYXsgCBfxppQXgjvLO4e668Upbg8sLUyDItZWyyN6qNtX1chkx_WrF9zBHYeFt2Z3tGNp39zMFfrw4YMmwVhrVWBiQxz0FGvz8tLffvK4bbwOlxlDCw7ObALobCbrw8igQ5j_PAurWk4_O6Enzm8EF2Ve2-qyMwR8r4TeqGWRf5rDMyiQFlam3SSuwbikrDSTeCFBqzin-kUWn6SMHfEtARm45iw4i3aSWf6z6co1AXYDNY66n2ZbKB3k/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/1nyuQ9bpRHMt_iZBxFsMjf7RaVDIDjIXhTZQyuRHnjgdnODFeyeuW06wg4nohYDfdpvjGicnYY4at0h4IpxpYS5GZ8-qmJZfbn6R15vgzrcNFQfJypasbD2gfQbgdrVKBFjIV0L3AeVrWwCbGwrSx1IWPhTAAmgbNKFk1FunK2cqD6lNHMYTcPP_yYVnQmlk70N8hDDt3uyQNpiWH1kVdRSluaEBNy6Pt4dz_-bzFAxlAKwweHSfSqOToXDPt5HKyYAgOCSyavk3ZEW4FTdyj16uLPJbCumVjWZWUYAqqtr0/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/1kMPWhOqsWHuJxB-WJQEwdvLInHhq7SEhouggiw7d6JUgWZfRBofpW6AGn8QU9u46JInnDXIIF2ZC1VMiuPaZgVe_lDcLbIx_04mlGB4Mhsfkfq7syXSfLZTHrPjzVGKG6nNbHEA1IJt-9VXeWI6jIzp-f-nRhUAL-7KwlsaoKQUdGDvhtmAZmUNVdTTuuOCdkZslLk3MDjhkYkVjCpni8p-8_vKkYzwhNjFgQ1Q7HehQ3rtG59nlfWRwkz7lVjUlXpDT0eSAYc_RlQ9dRJzRUvyinF7frPRtLbdwGFyYWCQ/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/1SYy-BXeHrvZa-Ij7v2V1_LwRTbfNUjxZv2nqivxZS6S6_AvRky1Q1keR42tf2ovA0Dl-kHOeqAgLI37Mx_s9YMMKIaWvS1x2q-rBAPHsjezGn_pWe21duhCXPz4-P7vzq3taCTuTnVi8DzVi0HrKcyguRllmOdQoByGK7-NEXg2Ad-Vbum8hIWMaWsejR-dDKgXDmTPnmimhjcKFZ55_u7lefbIbtXfQyEV-PkBdEMaABXx0CbLeVJj4GR4s2YwaBDrWC_MKqG4BpA8A9eBSOKBSDqinN2azFF2Bp4wrcUQ/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/1BnPDIP2LlUGLI_fLZR_Z5hM9pZJtfzG3QZOnJefiiq-CgR7okHiXfxBLVDx1ngQmhiJc7WqKBN2PuTsJL9Ek6O5wSX5Owa6ctPHCIIHNdKXGW5aKaw8202UQrHCsnX08gu3_WHW5eQMraf-Z4lPg5Bv6hK1OF1FD7iu8Kc4qiWohaQR0aYzLeXIbb6HUhxOI1LmQ_wBXLxuHwV9q79SAHtoH0rS0mVijF8nW69cKJTpZiA-p0oDgiJRRzCZJ9yF1kODLjaMHTbSRWVFbN7cL3P_1FXUwoeGm3bZn0hD3qDA/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/1YBkh2-Hi7Ru6KpX_tTK5VdNhFwd4a43HUJA9yCoU41vBiDjWUHO7sCsAfivfsH26I3W5qhMlfeTGmHczwHOOgcNORdWsapkvkvSQkDheMDWT_NGUhyfVYLTIZ2JSCXfOL4vbk51_QUGjUIqHnHwdaEJQ9S74RcTk2KNomaaTaYXbrEJZl5-m1kLzw5ASzIYUneG891rAk5gfgqBXbNlZ7cERclaMjzBM_ZUTM5bKPYDApv-ZkD-qLThrXLlFeLQ6YERZMifu8Bh80-Me11HNo3FXtFUJ6SVR8AU2Q_bsEIs/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
