On 6/21/24 09:32, kowa...@denic.de wrote:
Hi Andy,
Taking into account that this proposal is a result of considerations
on rfc9537 I think this draft takes the issue too simplified or easy,
just by removing the difficult part of the problem in rfc9537.
If you are saying that this draft is the result of experience with rfc
9537, I 100% agree. I did not think of it until after realizing that,
with few exceptions, the redaction methods in 9537 can only apply to
strings.
Actually it dictates allowed methods how redaction is done by the
server, practically eliminating the possibilities foreseen in rfc9537
which lead to removal of properties, objects or array elements (mainly
"Redaction by Removal" and one mode of "Redaction by Replacement
Value"). If you'd remove these methods from rfc9537, you'd actually
fix the issues with prePath as well because prePath would never occur.
If redaction by removal was instead redaction by placeholder, then the
items being redacted could be identified by JSONPath (assuming JSONPath
is usable). I believe you proposed placeholder values but the 9537
authors rejected it.
The group consensus was however that these methods exist and are in
use by the servers, so not taking them into account in rfc9537 would
have too much of an implication on the servers. This would result in
servers still doing the same thing (ergo removing properties, objects
or array elements) and not having a way to signal it.
I am struggling to understand the logic that a server has the adequate
knowledge to redact by empty value or redact by partial value but cannot
substitute values for keys.
postPath does not pose such an issue, because even if more than one
path is selected it is clear which elements of the response have been
redacted any why. If an overlap happens the client can display both
reasons fo the redaction.
Overlaps are problematic to clients (and users) when they are signaled
by multiple redaction methods. I cannot think of a compelling reason why
they should be allowed.
A feature that your proposal adds is a possibility to mark exactly
which part of partial redaction have been replaced. It didn't appear
to me as a goal for rfc9537 to have information specific to that
extend, especially in an unstructured data. The clients processing
such response may still mark the whole field as redacted leaving the
interpretation to the user. If this feature is deemed to be important
it can be still added on top of rfc953, using a method you've proposed
or any other suitable mean.
Being able to differentiate the parts of a string that are redacted is
particularly acute when it comes to things like unstructured postal
addresses (see section 4.1 of my draft) and tel URIs (see section 2.2 of
my draft).
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
