Hi Everyone, Just adding my 2 cents.
When we were discussing how to redact information, we definitely discussed using place holder text and it was almost immediately rejected due to the fact that placeholder text in the phone field would cause the automated parsing performed by JSON libraries for the phone number fields to crash. As I remember it seemed like there was more than one person that was not in favor of replacement text and that's why it was not included as an option. It seems to me that there is an inconsistency in the spec in that most fields are redacted with "////" yet the email field is not, it is redacted as a key itself. If that is the case than any string could be a key without having "////" added and appended to it, which seems questionable. Having to determine the keys that identify redaction for each RDAP response seems less desirable than already having the possible redacted keys identified by the RDAP JSON values repository standard. I agree with what almost everyone has said that a minor revision of the draft to remove any ambiguity around the need for JSON path. Using the "name" from the RDAP JSON Values is a clear indication of the entity that has been redacted without the use of the JSON path. I'm not convinced that an entirely new draft is necessary. I'd like to see more implementations before the RFC is updated and/or dismissed. Thanks, Jody Kolker 319-329-9805 (mobile) Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. -----Original Message----- From: Andrew Newton (andy) <a...@hxr.us> Sent: Friday, June 21, 2024 7:41 AM To: rcar...@godaddy.com <rcarney=40godaddy....@dmarc.ietf.org>; regext@ietf.org Subject: [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 _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
