Good Morning, Thanks Andy, it is hard to pinpoint specific discussions, but the RDAP WG started talking about this in early 2020, I saw some notes on the mailing list as early as February 2020. But I think the May 20 2021 RDAP WG meeting was when the WG coalesced around creating an RDAP extension to support the needs, the transcript from this meeting shows some good discussion specifically on this topic. The meetings (several months were spent discussing and refining) leading up to this one also show this continued dialog on this topic.
There were many messages on the mailing list associated with the opposition to the use of placeholder text. The message thread on -09 (https://mailarchive.ietf.org/arch/msg/regext/ee5kag1bDB61-IVy0FKwtDOT00U/) provides an example. The use of placeholder text is not a sound technical solution for a structured and formatted data structure. In the case of RDAP, use of placeholder text would change the response data to all clients, including clients that don’t support the extension. One of the foundations of RDAP is to enable clients to ignore members from extensions that they don’t understand, but a client can’t ignore the transformation of RDAP response data that they may not be capable of processing and make leak to end users that are not technical. RFC 9537 can be introduced by the server without having any negative side effect to clients that don’t support the extension. That is not the case for the Simple Redaction extension, where the processing of placeholder text instead of telephone numbers or e-mail addresses could break the clients or protocol content leaks to end users. Additionally, there is specific language in the RFC to directly address the opposition to the use of placeholder text as a form of RDAP redaction with “The use of placeholder text for the values of the RDAP fields, such as "XXXX", MUST NOT be used for redaction, since the placeholder text value may not match the format requirements of each of the RDAP fields, which could provide an inconsistent and unreliable redaction signal”. This internet draft received quite a bit of discussion and updates, 16 updates over three years, and this text has been in all the drafts since the original draft and through to the conclusion of RFC publication. Thanks Roger ________________________________ From: Andrew Newton (andy) <a...@hxr.us> Sent: Friday, June 21, 2024 7:41 AM To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org <regext@ietf.org> Subject: Re: [regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. 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
