On 6/20/24 16:39, rcar...@godaddy.com wrote:
I was not sure if I should reply to this thread or the "Simple" thread
but as the "Simple" thread appears to be a product of this one, I
thought I would post here.
Several years ago, there were many discussions (in the REGEXT WG, the
RDAP WG and others) on how to handle redaction in the RDAP response
and using placeholder text was an option that was discussed. Through
those discussions it was determined that using placeholder text was
not fit for purpose (typed data, different types of redactions, varied
server implementations, etc) and was deemed as an engineering "hack"
and called for an original solution. Not using placeholder text was
exactly what drove us to the creation and eventual publication of RFC
9537.
Roger,
It is not simple placeholder text but patterned keys that retain
syntactic validity. I did search the archives and did not find any
discussion of this approach. However, if you can point us to the those
technical discussions or, better, recite them here that would be very
helpful. While some may pejoratively refer to it as a "hack", there is
another saying often used by engineers, "the best is the enemy of the good."
This solution also has some clear benefits.
1. It can cleanly deal with JSContact UIDs, whereas we had many
discussions on the list regarding the interaction between JSContact and
9537.
2. It can distinguish the parts of a string that are redacted from the
parts that are not.
3. Even if the client doesn't support the extension and passes the data
onto the user, there is some chance that the user will understand that
the data has been redacted.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
