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.
- 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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
