I don't believe we're using advanced features of JSONPath in draft-ietf-regext-rdap-redacted and jsonpath.com has been used to validate the included examples. If there is a better tool to use, please let me know and I'll validate the examples with it. Otherwise, I believe we can continue to leverage jsonpath.com.
Thanks, -- JG 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/> On 4/26/23, 1:07 PM, "regext on behalf of Mario Loffredo" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it>> wrote: Hi Andy, Il 26/04/2023 17:55, Andrew Newton ha scritto: > I see in the implementation section of the draft there is a test > server that lists the redactions. > However, has anybody taken any real output from a DNR and INR server > and run some JSONPath expressions on them? > Doing so would help to prove out this spec. Think the main problem is that AFAIK there aren't JSONPath online testers fully compliant with jsonpath-base :-( I have used some of them thus far (e.g. jsonpath.com, jsonpath.curiousconcept.com/) but they refer to proprietary implementations sharing only the basic features with jsonpath-base. Just to be sure, have also tested on those sites some advanced JSONPath expressions included in jsonpath-base but they returned no results. Mario > > -andy > > On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo > <mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it>> wrote: >> >> Il 26/04/2023 02:16, Tom Harrison ha scritto: >>> On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote: >>>> The document editors have indicated that the following document is >>>> ready for submission to the IESG to be considered for publication as >>>> a Proposed Standard: >>>> >>>> Redacted Fields in the Registration Data Access Protocol (RDAP) Response >>>> https://secure-web.cisco.com/1KCYlZwumc1dMsWu4lHKi2uzBOOZvyGHP9hcYqgZZYMGctG6zT4WbgzJ4D7h00jgOtrNq-nsfqTPXQBiM-5NJUav2WwZAU6S44oavA2cTJbO2RNP-fXyJ3dWNpJ0kFN2Zkh4RLQm8xqqIofV2Vv5YEUrAyQcoVWKK7ZmjvnawHVQHFwdXd6FGwi15qKRETU82bAeP9GZePR3sCRJcmYowAT5gOf5M6zRDa65D-xeYOxmcOsyWHz5pwvW2WAwJTk-59INdwGqqglOwT_zhx90HhP7BkEDlAtcZ_VA2NL1kRNs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F >>>> >>>> <https://secure-web.cisco.com/1KCYlZwumc1dMsWu4lHKi2uzBOOZvyGHP9hcYqgZZYMGctG6zT4WbgzJ4D7h00jgOtrNq-nsfqTPXQBiM-5NJUav2WwZAU6S44oavA2cTJbO2RNP-fXyJ3dWNpJ0kFN2Zkh4RLQm8xqqIofV2Vv5YEUrAyQcoVWKK7ZmjvnawHVQHFwdXd6FGwi15qKRETU82bAeP9GZePR3sCRJcmYowAT5gOf5M6zRDa65D-xeYOxmcOsyWHz5pwvW2WAwJTk-59INdwGqqglOwT_zhx90HhP7BkEDlAtcZ_VA2NL1kRNs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F> >>>> >>>> Please indicate your support or no objection for the publication of >>>> this document by replying to this message on list (a simple “+1” is >>>> sufficient). >>>> >>>> If any working group member has questions regarding the publication >>>> of this document please respond on the list with your concerns by >>>> close of business everywhere, Monday, 1 May 2023. >>>> >>>> If there are no objections the document will be submitted to the >>>> IESG. >>>> >>>> The Document Shepherd for this document is Gustavo Lozano Ibarra. >>> Looks good overall, some minor comments/suggestions. >>> >>> Per previous mail from Pawel and Mario, some of the JSON path >>> expressions are not quite right for entities that have multiple roles. >>> There are some issues with the guidance added to the document to >>> account for this, though, and some further updates in this space that >>> would be useful. (We rely on entities having multiple roles in our >>> server implementation at the moment, for reference, and returning a >>> copy of each entity per role as a workaround is not ideal, >>> particularly when addressing the comments here shouldn't be >>> difficult.) To summarise these issues (mostly along the lines of the >>> comments from Pawel and Mario): >>> >>> - The first example use of prePath has a value of: >>> >>> $.entities[?(@.roles[0]=='administrative')] >>> >>> But all that a client can infer from this path is that all entities >>> with "administrative" as their first role have been removed. Since >>> there are no guarantees around ordering of roles within an entity, >>> this doesn't necessarily mean that all entities with >>> "administrative" as one of their roles have been removed from the >>> resulting object. It would be better to use a more general >>> expression in this example (and the others like it) that captured >>> the intent more clearly. Per earlier mail from Pawel, something >>> like: >>> >>> $.entities[?(@.roles[*]=='administrative')] >>> >>> should do the job, though I wasn't able to determine the syntax >>> that would be acceptable for draft-ietf-jsonpath-base. >> [ML] Per what is reported in Sections 2.3.5.1 (filter selector syntax) >> and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not >> accepted. >> >> The only acceptable values are integers (e.g. 0, 1, -1) >> >> Neither any of the pre-defined functions seems helpful. >> >> Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ == >> 'administrative]] could work maybe. >> >> >> Another solution might be using the indexOf function that is defined by >> some JSONPath implementations such as JSONPath.com and should be >> registered as Function Extension (see Section 3.2) : >> >> $.entities[?(@.roles.indexOf('administrative')!=-1)] //tested on >> jsonpath.com >> >> Anyway, the indexOf syntax should be redefined to be compliant with the >> jsonpath-base syntax: >> >> $.entities[?indexOf(@.roles,'administrative')!=-1] >> >> >> Best, >> >> Mario >> >>> - Section 5.2 at point 4 has: >>> >>> When an entity has multiple roles, include "redacted" members >>> for each role using the role index. This will result in >>> duplicate "redacted" members, but will enable the client to >>> treat redaction consistently when there is a single role per >>> entity or multiple roles per entity. >>> >>> It's not clear why this advice is present, when compared with e.g. >>> having the redacted members be a mapping from the server's >>> policies. For example, if the policy is that administrative >>> contacts not be returned, then a single "redacted" entry with a >>> prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly >>> conveys that message to the client, and the client will understand >>> that those entities will be removed regardless of any additional >>> roles that they might have. How do multiple redacted members >>> enable the client to treat redaction consistently? >>> >>> - Section 5.2 at point 5 has: >>> >>> When there are multiple entities with the same role, include >>> "redacted" members for each entity using the entity index >>> instead of the role. A JSONPath can be created that >>> identifies the entity based on an index of a role selector >>> nodelist, such as "$.entities[?(@.roles[0]=='technical')][0]" >>> for the first entity with the "technical" role. Using the >>> entity index, such as "$.entities[1]", is simpler and >>> recommended. >>> >>> Similarly to the previous point, removing by index obscures the >>> server's intent. To use the example given above, if the server's >>> policy is that the first entity with a technical role is omitted, >>> then the first expression (though with 'roles[*]' instead of >>> 'roles[0]') conveys that message more clearly than removal by way >>> of index. (If the server's behaviour can't be conveyed by way of a >>> JSON path, e.g. where an entity is omitted because they have opted >>> out of being included in responses, then simply omitting the >>> prePath and relying on a specific registered redacted name for the >>> behaviour would make things clearer for the client than presenting >>> an entity index that they can't resolve/use.) >>> >>> - Section 5.1 at point 1 has: >>> >>> When the server is using the Redaction By Removal Method >>> (Section 3.1) or the Redaction by Replacement Value Method >>> (Section 3.4) with an alternate field value, the JSONPath >>> expression of the "prePath" member will not resolve >>> successfully with the redacted response. The client can >>> first key off the "name" member for display logic and >>> utilize a template RDAP response overlaid with the redacted >>> response to successfully resolve the JSONPath expression. >>> >>> There is an earlier thread where the "template RDAP response" is >>> discussed, but it was noted there that it would likely be difficult >>> to construct a one-size-fits-all template response. I think that's >>> correct, given the flexibility of the underlying data format, but >>> that in turns means that a "template RDAP response" would have to >>> be generated on a per-server basis (something that was also flagged >>> in that thread). There's no guidance for clients (or servers) on >>> this point, though. Omitting the last sentence here will address >>> the problem. >>> >>> - Also on section 5.1 point 1, the prePath expression will sometimes >>> resolve 'successfully' when evaluating the redacted response, in >>> the sense that it can be applied to the response and will return a >>> result. For example, if the first technical-role entity is >>> redacted by removal, but the object contains two technical-role >>> entities, then the prePath will resolve to the second >>> technical-role entity. This could be confusing for implementors, >>> particularly given that the other JSONPath expressions will resolve >>> correctly when evaluated against the redacted response. Some extra >>> text here clarifying that the expression may evaluate >>> 'successfully', but not 'correctly', would be useful. >>> >>> - (Another way of addressing all of the above is to remove prePath >>> altogether, given that it's optional, and given that in most cases >>> servers should use registered redacted names anyway, the >>> descriptions for which can document the associated behaviour >>> clearly and unambiguously.) >>> >>> In the definition for "name" in the "redacted" member, in section 4.2, >>> the text has "[t]he logical name is defined using an object with a >>> 'type' field denoting a registered redacted name (see Section 6.2)". >>> The document uses various names in the examples (e.g. "Administrative >>> Contact" in figure 1) without registering them, though. Registering >>> those names would address the problem, or alternatively the >>> "description" field for unregistered names could be used in the >>> examples instead. >>> >>> Section 6.2 has: >>> >>> Two new JSON Values Registry Type field values are used to register >>> pre-defined redacted name and reason values: >>> >>> "redacted name": Redacted name being registered. The registered >>> redacted name is referenced using the "type" field of the >>> redacted "name" field. >>> >>> "redacted reason": Redacted reason being registered. The registered >>> redacted reason is referenced using the "type" field of the >>> redacted "reason" field. >>> >>> "redacted expression language": Redacted expression language being >>> registered. The registered redacted expression language is >>> referenced using the "pathLang" field. >>> >>> The following values should be registered by the IANA in the RDAP >>> JSON Values Registry described in [RFC7483]: ... >>> >>> This would read better if the first sentence took account of the >>> "redacted expression language" registration as well, or alternatively >>> if similar text was added after the "redacted reason" entry. >>> >>> -Tom >>> >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org <mailto:regext@ietf.org> >>> https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>> >>> <https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >> -- >> Dott. Mario Loffredo >> Technological Unit “Digital Innovation” >> Institute of Informatics and Telematics (IIT) >> National Research Council (CNR) >> via G. Moruzzi 1, I-56124 PISA, Italy >> Phone: +39.0503153497 >> Web: >> http://secure-web.cisco.com/1Cb2OTkcuHwNjKyWzZAWakoJg4dYeLjCT_txGytMjP0jHL3d5e_GnUoLi-sHyMWyU4c0ftyVDWIv1_PbXaWwh3vPyBuqPUmiS-Q4hRtHl2JuRkKXqLYQIYUULFtfPejaqmZeMqd52ncaBSHoNx9OU4K4iYYAsDDtOqvnQEjnklMnkcdmTm4zDJDZvv_DLN86aCChqfKftAvCPHJrCSQWKnNuGeLpFB_As-tZ-LvjT-mEQHTIIa1kGug9ph5GnekGdWuUcwZ0ONtavYH-WWcCLCgqqNYIWzORCKmfnriUg6Ys/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo >> >> <http://secure-web.cisco.com/1Cb2OTkcuHwNjKyWzZAWakoJg4dYeLjCT_txGytMjP0jHL3d5e_GnUoLi-sHyMWyU4c0ftyVDWIv1_PbXaWwh3vPyBuqPUmiS-Q4hRtHl2JuRkKXqLYQIYUULFtfPejaqmZeMqd52ncaBSHoNx9OU4K4iYYAsDDtOqvnQEjnklMnkcdmTm4zDJDZvv_DLN86aCChqfKftAvCPHJrCSQWKnNuGeLpFB_As-tZ-LvjT-mEQHTIIa1kGug9ph5GnekGdWuUcwZ0ONtavYH-WWcCLCgqqNYIWzORCKmfnriUg6Ys/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> >> >> _______________________________________________ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >> >> <https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > <https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> -- Dott. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://secure-web.cisco.com/1Cb2OTkcuHwNjKyWzZAWakoJg4dYeLjCT_txGytMjP0jHL3d5e_GnUoLi-sHyMWyU4c0ftyVDWIv1_PbXaWwh3vPyBuqPUmiS-Q4hRtHl2JuRkKXqLYQIYUULFtfPejaqmZeMqd52ncaBSHoNx9OU4K4iYYAsDDtOqvnQEjnklMnkcdmTm4zDJDZvv_DLN86aCChqfKftAvCPHJrCSQWKnNuGeLpFB_As-tZ-LvjT-mEQHTIIa1kGug9ph5GnekGdWuUcwZ0ONtavYH-WWcCLCgqqNYIWzORCKmfnriUg6Ys/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo <http://secure-web.cisco.com/1Cb2OTkcuHwNjKyWzZAWakoJg4dYeLjCT_txGytMjP0jHL3d5e_GnUoLi-sHyMWyU4c0ftyVDWIv1_PbXaWwh3vPyBuqPUmiS-Q4hRtHl2JuRkKXqLYQIYUULFtfPejaqmZeMqd52ncaBSHoNx9OU4K4iYYAsDDtOqvnQEjnklMnkcdmTm4zDJDZvv_DLN86aCChqfKftAvCPHJrCSQWKnNuGeLpFB_As-tZ-LvjT-mEQHTIIa1kGug9ph5GnekGdWuUcwZ0ONtavYH-WWcCLCgqqNYIWzORCKmfnriUg6Ys/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1LuDlqRFmAesEznhWoTjoUNrZfrrZ6tUeiFr5SHqJAAS0fiB6ahOZCwO5wkREH7pqZWRLeaAqVcrFIqQsdAhA47w6R8rC0nBRulapR1JWJuLeVizl0derxR4z6zm4DvuZjzsiitVKuvvpErgvGhsFpyjzVWh93S5WcMJ3kdZ182aWFxImMdjY_5tHEp48DYfLTKJM4x0P5GKC62azxtyoX3BhX0upAoKJbOfskF0tdSuXaK1Egj2E8bNvYBTY8L4YEhTt3nchhNM1YYzFFiigbMe5tYjjEOLpEe4DUA0eQ_8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
