Hi James,
My comments below.
Am 23.11.22 um 14:17 schrieb Gould, James:
[...]
JG3 – What triggered the creation of this extension was a proposal to
use placeholder text for redaction, which in my opinion is an
anti-pattern that needs to be directly addressed. I believe that you
see the need to support a transition period that would be up to server
policy. See my comment below related to creating a Transition
Considerations section to make this explicit. The draft can define the
methods for redaction, disallow the use of placeholder text for
redaction outside of a transition period, and add explicit support for
a transition period with a set of considerations. Does this meet your
needs?
[PK3] OK, please include also this part in the Abstract and
Introduction, that the draft also defines certain rules for redaction to
mitigate the anti-patterns, if there is a consensus in WG to mandate how
redaction is done.
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.
JG3 – Yes, use of a privacy proxy email is a form of "Redaction by
Replacement Value Method", since the real value is not being provided
but a replacement value is being used instead. In this case the
“method” value is “replacementValue” and the “replacementPath” is not
used. Does this need to be clarified in the draft, since the intent is
to support replacing the value in place or replacing the value using
an alternate field, such as the replacement with the “contact—uri”
property?
[PK3] Now I see it from examples that replacementPath might be omitted.
It would be good to have some normative text defining that.
[...]
JG3 – Ok, that helps. I believe the biggest issue from a client
perspective is when they expect a non-empty value, and the server
implements the Redaction by Empty Value Method and then returns an
empty value. The use of the placeholder redaction text can be used in
parallel with draft-ietf-regext-rdap-redacted during a transition
period. The duration of the transition period would be up to server
policy. What I don’t want to introduce is parallel forms of redaction
for beyond a transition period. How about including the definition of
a transition period in a Transition Considerations section and
updating the MUST NOT language to “The use of placeholder text … MUST
NOT be used for redaction outside of a transition period defined in
Section X . In the Transition Considerations section, it can define
that placeholder redaction text may exist and may overlap with this
extension during a transition period that is up to server policy.
Then there can be a set of considerations for the server and client in
making the transition. I believe this would address the transition
more explicitly and leave the timing of the transition up to server
policy. Do you agree?
[PK3] If the WG is in consensus to keep "MUST NOT" then Transition
Considerations is a good way to cover the smooth transition.
[...]
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).
JG3 – Thanks for the reference, I’ll review it and see whether
something can be used. My initial thought is that it’s going to be
too complex and won’t cover the broad set of use cases in RDAP. Right
now, we’ll assume that it can’t be used in
draft-ietf-regext-rdap-redacted, but it’s being reviewed.
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.
JG3 – Ok, the “JSONPath Considerations” section will have two
subsections of “JSONPath Client Considerations” and “JSONPath Server
Considerations”, where the above will be the starting JSONPath client
consideration. How about the JSONPath Client Consideration:
When the server is using the Redaction By Removal Method
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal> (Section
3.1
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-removal>) or
the Redaction by Replacement Value Method
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value> (Section
3.3
<file:///Users/jgould/projects/github/rdap-redaction/draft-ietf-regext-rdap-redacted.html#redaction-replacement-value>) with
an alternate field value, the JSONPath expression of the "path" 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.
[PK3] OK
[...]
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."
JG3 – Just a tweak, how about “The Redaction by Removal Method MUST
NOT be used to remove an element of an array where the position of the
element in the array determines semantic meaning.”?
[PK3] Thanks.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
