Hi,
As an action item after IETF 115 I reviewed
draft-ietf-regext-rdap-redacted-09 before WG LC and have the following
questions / remarks:
Section 3, first paragraph:
> Redaction in RDAP can be handled in multiple ways. The use of
> placeholder text for the values of the RDAP fields, such as the
> placeholder text "XXXX", MUST NOT be used for redaction. A
> placeholder text value will not match the format requirements of each
> of the RDAP fields and provides an inconsistent and unreliable
> redaction signal.
Is the normative language adequate here? Firstly, I am not sure if the
text can be well understood.
Does it mean that use of a fixed placeholder is prohibited, or any
placeholder?
I can imagine a way of using placeholders, which do not necessarily
break the format requirements,
therefore the second sentence shall not categorically tell "will not
match" as it may not be even true.
My proposal would be to use SHOULD NOT instead of MUST NOT. It can be
useful for the servers willing
still to support clients not implementing this extension in the
transition period to populate fields with placeholders instead of just
empty/missing fields.
---
Section 3, second paragraph:
The whole paragraph deals with particularities of redacting jCard with
some very specific guidelines and examples.
Wouldn't it be more and future proof to have a general statement that
redacting the data MUST NOT break the underlying data format?
The same remark applies then later to 3.2. with normative language for
jCard redaction.
---
4.2. "redacted" Member
The whole "redacted" member and especially the "path" and
"replacementPath" members
shall allow the client to recognise parts of the JSON response which
have been transformed
in the process of redaction.
Here some interesting questions:
- do the paths refer to the object before or after the redaction?
- if the paths refer to the object before the redaction, how should the
client be able to interpret the path if not having access to this
object, especially the JSONPath may even match multiple paths, e.g. from
result and the path the client cannot digest which paths have been
really removed? More to that each redaction step is actually
transforming the object, so the order of redaction is also relevant in
this case. Normalized Paths from JSONPath allow "reversing" the process
from the result object if the order of redaction is being held.
- if the paths refer to the object after the redaction, likely the path
member should be OPTIONAL not not required for redaction by removal or
replacement, because in this case the object likely does not exist in
the result object
With Section 5 being not-normative and about processing by the server,
the draft should similarly include considerations for processing of the
responses by the clients.
---
"pathLang" member
What is the rationale behind introducing this extension point? Right now
the RFC specifies only one language, which is default one. If there will
be an additional one I would expect it added by a RFC also answering
some questions how to transition from one path language to another.
Without any way for the client to express which "pathLang" it would like
to get response with, the server would only be able to migrate after all
clients support both formats, otherwise risking some clients to break.
And if this "pathLang" member is to persist, shouldn't there be IANA
registry for allowed values, so that the clients have an ide what to
implement?
---
3.1. Redaction by Removal Method
> The Redaction by Removal Method MUST NOT be used to remove a field
> using the position in a fixed length array to signal the redacted
> field. For example, removal of an individual data field in jCard
> [RFC7095] will result in a non-conformant jCard [RFC7095] array
> definition.
Is the first normative sentence meant to apply to every case, or just
the case where removal of such field would render an invalid jCard?
I think there is quite legit way or removing whole objects by position
in a fixed length array, like "path": "$.entities[0]" which should be
still allowed.
---
6.2. JSON Values Registry
Registry for "redacted name" allows to identify what has been removed
without interpreting it from the path member. This is of a great
benefit, looking at the difficulties of interpreting the "path" member I
mentioned above.
However, semantically, isn't this registry rather defining the members
and objects of RDAP response in a general sense? I mean "Registry Domain
ID" means the same no matter if in context of redaction or in context of
RDAP response and actually IMHO we should make sure it means the same in
any other RDAP context it would be used in the future. IMHO this IANA
registry shall be a generic one defining labels to the information
pieces in RDAP responses.
---
Examples with entity role indexing.
The draft has many examples of the kind
$.entities[?(@.roles[0]=='registrant')] which might be incorrect if an
entity holds multiple roles, as RFC9083 does not specify any particular
order of roles in the array and also depending on the roles held by the
entity the array might have different length. This means that
'registrant' can be at index 0, but also at index 1. The correct
expression would rather be with wildcard index as per 3.5.2. of
JSONPath, like this $.entities[?(@.roles[*]=='registrant')].
The example of multiple roles shows also a tricky corner-case, as the
server may want to redact a contact in one role but same time not redact
it due to other role attached to the same entity. Not sure if JSONPath
allows to express this, but this might remain an implementation detail
of the server and not particularly a concern of this draft (apart from
the questions to 4.2 above).
---
Re previous discussion on multiple email addresses.
Just a remark that after the last discussion on
draft-ietf-regext-epp-eai it may be more common to have more than one
email address. Likely RDAP needs to get EAI-aware as well on the
response side.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
