Hi James,
See my feedback below.
Am 15.11.22 um 21:15 schrieb Gould, James:
[...]
JG - The use of placeholder values for redaction is prohibited based on the second normative
sentence. The normative language is needed to implement the redaction defined by the RDAP
extension. I agree that stating "A placeholder text value will not match" is too strong
and needs to be changed to "A placeholder text may not match". This will be changed in
the next version of the draft.
[PK] Yes, the changed text is way better.
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.
JG - I understand that there may be a transition period to fully implement the
RDAP extension as will be the case of any RDAP extension that standardizes a
crosscutting feature like redaction, but weakening the normative language from
MUST NOT to SHOULD NOT misses the purpose of the RDAP extension and will result
in potentially long running interoperability issues.
[PK] Looking at the Abstract and the Introduction of the draft it reads
"This document describes an RDAP extension for explicitly identifying
redacted RDAP response fields, using JSONPath as the default expression
language.". I see a clear focus on "identify", whereas such strong
normative language actually influences the way the redaction is done. I
don't think this should be the main focus of this draft and a bit softer
SHOULD allows to align servers to the best practice without a dilemma if
one can use the rdapConformance "redacted" even if placeholders are in
use for whatever reason. Placeholders are perfectly fitting the
"Redaction by Replacement Value Method", so also fitting the draft.
[...]
JG - jCard is currently used in RFC 9083 and the specifics of handling redaction of jCard
is an important concept that needs to be covered. The "Redaction by Empty Value
Method" is needed because of jCard. I believe the combination of jCard being used
in RFC 9083 and the definition of a redaction method to support jCard warrants providing
the detail.
[PK] Fine
[...]
JG - The path refers to the object before the redaction for the Redaction by
Removal Method, since the RDAP field was removed. In this case the path points
to where the RDAP field would have been. The path refers to the object before
and after the redaction for the Redaction by Empty Value Method, since the RDAP
field exists but has been set to an empty value. The path refers to the object
before the redaction for the Redaction by Replacement Value Method, while the
replacementPath refers to the object after the redaction, since it points to
the replacement JSON field. Right, requiring the path to a non-existent JSON
fields in the case of the Redaction by Removal Method and the Redaction by
Replacement Value Method consequently requires the client to validate the
JSONPath expression using a non-redacted RDAP response,, which the client does
not have. Having the JSONPath for where the field would have existed may be
useful for a client, but they would need to generate the non-redacted response.
[PK] It would be of a great value to describe to which object the path
refers to to make it clear for the implementers.
Maybe even worth considering to have 2 distinct members "originalPath"
and "responsePath" where each one is clearly defined to be referring to
a source or a result object respectively.
I don't oppose setting the "path" to OPTIONAL but with normative language
specifying that it MUST be included when the JSON field does exist in the redacted
response. Do you agree with this?
[PK] Yes, I would support that.
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.
JG - Yes, Section 5 provides non-normative considerations for the server. Offhand I believe considerations
#2 "Validate a JSONPath expression using a non-redacted RDAP response" could be applicable when a
client receives a response that includes the "path" expression for the Redaction by Removal Method
and the Redaction by Replacement Value Method, per the feedback above, but the client would need to generate
a template non-redacted RDAP response based on the "path" expressions. Do you agree with this
possible consideration, and do you have any other considerations that should be considered? If there are
useful client considerations, they certainly can be added.
[PK] The approach with a "template non-redacted RDAP response" may be
interesting to take a deeper look into.
My first impression would be that such fits-all template may be
difficult to build, accounting that an entity may have multiple roles
assigned or that vCard allows also for custom fields the client would
not be aware of.
Another approach would be to define a way of interpreting the JSONPath
so that it is reversible or even defining a subset of JSONPath which is
reversible in the narrower RDAP context.
In the end, implementing a client, I would rather want to rely on the
"redacted name" from the "JSON Values Registry" for paths which have
been deleted, and treating the path member as only informative.
If you agree for such processing by the client I suggest to put it down
in the chapter 5 (maybe splitting it into server and client side).
JG - The expression language being stuck with JSONPath was brought up on the list, which resulted in adding the OPTIONAL
"pathLang" field. A new JSON Values Registry field value could be added, like "redacted name" and "redacted
reason". How about the "redacted expression language" Type with a pre-registration of the Value "jsonpath" and
the description "JSON path expression language, as defined in draft-ietf-jsonpath-base"? We would replace
draft-ietf-jsonpath-base with the published RFC, which is a normative reference dependency.
[PK] If WG feels we need to foresee support for more expression
languages then the approach with JSON Values Registry is a good proposal.
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.
JG - It's really meant to directly address the jCard use case, but I believe it would
apply to all fixed length arrays. Would it help to clarify this more by updating the
language to be "using the fixed field position of a fixed length array"?
[PK] Does it mean you intend to forbid fixed field positioning in all
cases, meaning $.entities[0] would not be allowed?
In case of jCard I understand this is to prevent breaking the format,
where the position plays a distinct role. What is the rationale to block
it in all cases?
[...]
JG - Agreed that the registering a new JSON Values Registry Type and pre-registering the
"jsonpath" expression language can help as stated above.
[PK] Fine
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.
JG - No, the JSON Values Registry defines the values that can be used for fields, which is applicable here for the valid set of "type"
field values used in the redacted "name" and "reason" fields. The same can be done to define the valid field values for the
"pathLang" field. The registered Type values of "redacted name", "redacted reason", and potentially the "
redacted expression language" will provide the needed isolation with the other typed values in the registry.
[PK] I get that. This is just an observation, that "reverse search"
will also define a JSON Value Registry" with a mapping of labels to
JSONPaths. The risk is to end up with different labels for the same
thing in context of redaction or reverse search.
It would be good to have some voices from the WG if we care about it.
---
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).
JG - Interesting tricky corner-case. I do believe it's an implementation
detail, where the draft provides a redaction example based on the unredacted
response that doesn't require the wildcard.
[PK] I wanted to bring this up just in case (which obviously never
happens) that the implementers of the server just copy-paste the examples...
[...]
Kind Regards
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
