Good Afternoon, 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. Though the RDAP response is human readable, practically, I never thought it would be used by anyone except those building client interfaces (e.g. I never expected anyone to read the JSON, I expected clients to process the response and present the data to its users in the format the client wanted it to be presented). With that said I find it very difficult to believe that client implementors would find it challenging to present to the end users, of their client applications, the list of redactions included in an RDAP response using the redacted extension (RFC9537). I do (and I think most of the WG does) appreciate the excellent review and analysis of RFC9537, but after consultation with several members of the RDAP WG and REGEX WG, it is clear that RFC9537 does provide an end-to-end technical solution that is fully fit for purpose to redact data not just in the context of the ICANN gTLD RDAP Profile but for other use cases beyond this Profile as well. And just to reiterate what others have said on this topic, with more implementations of RFC9537, we will get to collect additional learnings that may help us in clarifications if needed. Thanks Roger ________________________________ From: Andrew Newton (andy) <[email protected]> Sent: Tuesday, June 18, 2024 1:15 PM To: Gould, James <[email protected]>; Hollenbeck, Scott <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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/17/24 08:11, Gould, James wrote: > JG - I agree that this language in the abstract could be better, but the > abstract does not override the content of the entire specification and is > factual. The extension explicitly identifies the redacted RDAP response > fields and JSONPath is the default expression language. The working group, > the co-editors, and you as the document shepherd could have made this > sentence better. James, I don't think this type of comment is appropriate. It is accusatory in nature and sets the wrong tone, especially if we want others to volunteer as document shepherds. I did take over as document shepherd from another participant on this RFC as I wanted to see it published (and I have volunteered as shepherd on multiple documents since). I have spent a considerable amount of time on RFC 9537, creating a GitHub repository of test cases, overseeing two development teams for two clients, and adding 9537 capabilities to a server. The issues I have brought forward are not trivial, and the finger-pointing is not appreciated. Regarding some of the other arguments made in the various emails: 1. It is true that section 4.2 states as OPTIONAL the various JSONPath attributes, but this is also from Section 4.2: The "postPath" member MUST be set when the redacted field does exist in the redacted response for the Redaction by Empty Value Method (Section 3.2), the Redaction by Partial Value Method (Section 3.3), and the Redaction by Replacement Value Method (Section 3.4). Section 4.2 is clearly describing a data structure that takes different forms based on the redaction method because the various paths only have meaning in certain contexts. The OPTIONALs are there to allow the structure to be re-used. This is reflected in EVERY example in the RFC. 2. You have stated the JSONPath expressions may or may not be useful and that we need to rely on implementation experience to determine their utility (this is paraphrasing, but it is also implied given the argument that they are completely optional). From this very thread: On 6/17/24 08:11, Gould, James wrote: > JG - There may be servers and clients that do decide to implement the > JSONPath expressions, but time will tell. A new JSON expression language may > be defined that is better suited as well, where JSONPath is the best match > right now. > If this is true, their defined usage with respect to redaction should not be in a standards track document. That is more appropriate for the Experimental track. 3. You state above the extension "explicitly identifies" the redacted response fields. Explicitly means "fully revealed or expressed without vagueness, implication, or ambiguity : leaving no question as to meaning or intent." If the JSONPath is optional, how can that be explicit? -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
