[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt

["[e-mail]" <[e-mail]>]

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) <[e-mail]>
Sent: Tuesday, June 18, 2024 1:15 PM
To: Gould, James <[e-mail]>; Hollenbeck, Scott <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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 -- [e-mail]
To unsubscribe send an email to [e-mail]