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.
-andy On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo <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://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/ > >> > >> 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 > > https://www.ietf.org/mailman/listinfo/regext > > -- > 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://www.iit.cnr.it/mario.loffredo > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext