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

Reply via email to