Hi James,
My comments also inline.
Am 22.11.22 um 14:18 schrieb Gould, James:
[...] [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. JG2 - The use of placeholder text,
such as "REDACTED", is an alternative approach that is incompatible
with the method of redaction defined in this draft. The draft
explicitly states that the use of placeholder text MUST NOT be used
for redaction, and it has no impact on the use of placeholder text for
other purposes.
[PK2] This is exactly what I allude to. The document describes not only
the "extension for explicitly identifying redacted RDAP response fields"
but also dictates what methods of redaction are allowed and which not.
If there is consensus that the document also shall mandate the methods
of redaction I think the Abstract and Introduction part should state it
as well.
The real question is whether the goal of making clear what part of the
dataset was redacted not enough for this draft.
For the client the indication that some data is not real, don't use it,
is just enough of information, no matter if the data was removed, set to
null, empty or otherwise replaced, isn't it?
Populating the existing value with a static placeholder value as a
signal for redaction is different from what is defined for the
"Redaction by Replacement Value Method", which changes the value to a
non-static value or moves the location of the value.
[PK2] I believe it should be perfectly valid to replace one email with
another email (for example privacy proxy email) without moving it,
shouldn't it? For me it would be "Redaction by Replacement Value Method"
where both paths are same.
If I currently implemented placeholder text for the purpose of
redaction and I decided to implement redaction using the approach
defined in this draft, then I don't see the purpose of running them in
parallel even during a transition period, since clients should be
notified of the transition and the draft includes the needed signaling
using the "redacted" rdapConformance value. Is there a specific use
case that would warrant a softer transition? If there is a softer
transition use case warranted, then adding a Transition Considerations
section, such as defined in section 6 of RFC 9154 "EPP Secure
Authorization Information for Transfer, may be needed.
[PK2] Assuming the initial situation: RDAP server does not support
"redacted" extension and puts the placeholder values and all the clients
do not support "redacted" extension but know how to interpret the
placeholder.
Now if the server would just turn on "redacted" first, not waiting for
the clients, being fully compatible with the extension it would have to
change the redaction with either empty value or removal of the fields.
By doing this the clients which are not aware of "redacted" extension
would potentially break due to changed behavior.
To avoid it the server would have to first make sure all clients support
"redacted" before switching. This is somewhat impossible, as client is
not informing the server in any way which extension it supports. If it
would have a way to inform the server the problem would be gone as well,
as server might have offered different representation to different
clients. The other way around is to relax the requirement and allow the
server operators to manage this.
SHOULD instead of MUST would give the operators a bit more of
flexibility and same time none of the benefits of this draft would be lost.
[...] 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. JG2 - I'm
not sure what is meant by JSONPath that is reversable. I believe that
JSONPath needs to be used as defined.
[PK2] Reversable means that you can unambiguously re-create the original
object structure based on the path. Normalized JSONPath have this
property (see 2.8 of JSONPath draft) but may not be the best in case of
array members identified by a property value of array member, like in
jCard. The expressions like $.entities[?(@.roles[0]=='registrant')] can
be also reversible, but this is not true for just any JSONPath
expression. If we would define a narrowed down definition of JSONPath
expressions which are allowed, we could achieve the property of
reversibility and maybe even that one kind of object or property would
have exactly one and only possible JSONPath describing it. Again - it's
just an idea how to deal with removed paths. It may be also not worth
following if we assume "redacted name" would be the leading property
(see below).
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). JG2 -
From a client perspective, I believe I would first key off the
"redacted name" to route my display logic and then I would utilize a
template RDAP response overlaid with the actual response and the
JSONPath to indicate the redacted values. It would be nice to hear
from some clients on this to identify useful client JSONPath
considerations.
[PK2] If I would be implementing the client likely I will do exactly this.
[...] JG2 - Your reference to $.entities[0] is an example of an
element in an array, but its' not referring to a fixed field position
of a fixed length array, such as the case for redacting the "fn" jCard
property. There is no intent to block all cases of redacting objects
via the use of an array position. Is there better language than "using
the fixed field position of a fixed length array" to provide the
proper scope?
OK, now I get it. My proposal would be: "The Redaction by Removal Method
MUST NOT be used to remove an element of an array where position of the
elements in the array determines semantic meaning of the element."
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
