Hi Mario, That’s a reasonable interpretation of the issues on hand, for both name- and JSONPath-based redaction in RFC 9537. I think the question would come down to how far are we willing to evolve the JSONPath portion of RFC 9537 (Scott’s -bis idea) to guarantee client/server interoperability (thereby, correctness)? Or would we be better off trying (experimenting with) a more limited (not all JSON types covered), JSONPath-free, in-situ redaction (no prePath-like issues) approach that the Simple Redaction proposal could afford? Client/server interoperability, correctness, and cost of implementation should be good measures to help decide. I don’t know if there has been a precedence at the IETF to allow 2 specs for the same goal to proceed parallelly -- RFC 9537-bis and Simple Redaction In our case. We would need some guidance here.
Thanks, Jasdip P.S. FWIW, based on the discussion, here is the updated options list: 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. Option 5: Get more implementation experience with RFC 9537, especially the name-based redaction. Option 6: Opt for a contact format that minimizes the use of arrays and, when they are used, prevent the redaction of a single item. From: Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> Date: Tuesday, June 18, 2024 at 3:33 AM To: Jasdip Singh <jasd...@arin.net> Cc: regext@ietf.org <regext@ietf.org> Subject: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Hi Jasdip, AFAIU, the name.type value is a shortcut to point to a precise field and I suppose such pointer should be hardcoded in the client. When the name.description value is reported, the path value must be used instead. However, there are cases where the name.type value is not sufficient to uniquely indentify the redacted field. For example, when there are multiple tech contacts associated to a domain and some/all of them are redacted. Anyway, one thing that IMO would really help clients in handling the redaction paths is to avoid (as much as possible) operators that can select multiple path nodes lke wildcard, filters and so on. No matter if you use JSONPath or another language to select JSON values, the usage of those operators along with arrays would always make the implementers' burden very hard. I would also normatively prevent registries from redacting multiple objects or same field across multiple objects in one shot such as redacting all the email addresses of tech contacts. I mean, the items in the redacted array should exactly match the fields or the entire objects redacted. That said, I would add the following option to your list: Option 5: Opt for a contact format that minimizes the use of arrays and, when they are used, prevent the redaction of a single item. Best, Mario Il 15/06/2024 20:49, Jasdip Singh ha scritto: 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><mailto:mario.loffr...@iit.cnr.it> Date: Tuesday, June 11, 2024 at 6:27 AM To: Jasdip Singh <jasd...@arin.net><mailto:jasd...@arin.net>, Andrew Newton (andy) <a...@hxr.us><mailto:a...@hxr.us>, regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org><mailto: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 [2] https://rdap.pubtest.nic.it/domain/meep.it?jscard=1 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 Status: https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/ HTML: https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-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 -- 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
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
