> On 5 Jun 2024, at 16:54, Gould, James <jgould=40verisign....@dmarc.ietf.org> > wrote: > > Andy, > As noted in my prior response, below is my detailed responses to > draft-newton-regext-rdap-considerations-on-rfc9537: > > • Abstract > • “Some of these problems may be insurmountable, leaving portions of > RFC 9537 non-interoperable between clients and servers, while other problems > place a high degree of complexity upon clients.” > i. The RFC provides a set of required members for each redaction > with the “name” and “method” members, along with a set of optional members. > Your considerations focus on the implementation of the optional members that > use an expression language (JSONPath) to technically identify the JSON > members redacted via the supported methods. We’ve had a lot of discussion on > the list with the inherent complexity of RDAP and jCard containing structured > and unstructured content that any JSON expression language will have > challenges with. I still believe that JSONPath is the appropriate expression > language to use currently, but the RFC supports extensibility of expression > languages if a better expression language is created. At a minimum, the > client should be capable of easily leveraging the required “name” and > “method” members to provide a list of redactions to the end users with > optional visual field-level indication, which is not insurmountable and can > be done in an interoperable way.
With my client developer hat on, I disagree with this last statement. If I had an existing tool that was used to presenting Whois records that I was retrofitting to support RDAP, then perhaps it would be the case, but the "name" property of a redaction object is useless unless I completely rewrite my clients so that they use a Whois-style internal data model, which is much less flexible if you want a client that can display all types of RDAP responses using a single framework. > • Background > • “This RFC also modifies the IANA RDAP JSON Values registry with > additional fields to be used in the process of presenting information about a > redaction, however the registry contains text intended for humans and does > not explicitly contain JSONPath expressions.” > i. Correct, the RFC leverages the existing RDAP JSON Values IANA > registry with the new types of “redacted name”, “redacted reason”, and > “redacted expression language”. The registry is meant for humans and not > programmatic discovery I think you are being a bit naive here: the RDAP registry is published in CSV and XML formats, so the registries are clearly intended for programmatic usage. Otherwise, why differentiate between "registered" and "unregistered" names? > • “clients merely rendering the values of "prePath", "postPath", or > "replacementPath" are of little use to most humans.” > i. Agreed, the “name” values and especially the standard “name” > values, using the IANA RDAP JSON Values registry, is the most appropriate to > display to the end user. The “name” values can be used by the client to > highlight a field displayed to the user that has been redacted, such as > including the “Registry Domain ID” field without a value and with red > strikeout text if the “Registry Domain ID” registered “name” value is > included in the redaction extension with a “method” value of “removal”. Again, this assumes that the client is a tool originally designed to display Whois records that's being retrofitted to display RDAP records. That's not true of many RDAP clients. If we are to make any progress on resolving the issues identified in Andy's document, we need to recognise that not all RDAP display tools are Whois display tools wearing RDAP trenchcoats. G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
