On 6/14/24 14:59, Hollenbeck, Scott wrote:
-----Original Message-----
From: Andrew Newton (andy) <a...@hxr.us>
Sent: Friday, June 14, 2024 2:42 PM
To: Gould, James <jgo...@verisign.com>; kowa...@denic.de; regext@ietf.org
Subject: [EXTERNAL] [regext] Re: Fwd: New Version Notification for draft-
newton-regext-rdap-considerations-on-rfc9537-00.txt
Caution: This email originated from outside the organization. Do not click links
or open attachments unless you recognize the sender and know the content is
safe.
James,
Thanks for this. I think I covered this in section 10 of the draft, though
probably not in as much detail as needed.
Yes, this is one path forward but it does not provide the functionality as
advertised in the RFC and is a lot machinery just to replicate the "remarks"
feature of core RDAP, albeit with less functionality as "remarks" can be
associated directly with an RDAP object and can provide descriptive text in
multiple languages (unlike "redaction").
As Gavin pointed out, such an approach does not work well with clients that
do not present the data in a linear style (rdap.org, search.arin.net/rdap,
etc...).
When time permits, I'll update the draft to more thoroughly cover this topic.
[SAH] Andy, with the various JSONPath elements being OPTIONAL, are you saying
that the clients you described above can't process a redacted response using
only the name value? Could you point me to Gavin's explanation?
Scott,
Gavin's email is here:
https://mailarchive.ietf.org/arch/msg/regext/FlDF-Hcmf_4vPwU8ULqiBaThRCE/
I outline the use of the name value here:
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537-00#name-redaction-by-removal
The name value can have two forms, one with a "type" and one with a
"description". "description" holds an unregistered value and "type"
holds an IANA registered value. The non-normative guidance in Section
5.1 does not say what to do in either case.
In the code James provided where the "name" is the value of "type" if
present otherwise it is the value of "description", the client is left
to displaying that value somewhere unspecified (see my email to James
above).
Now, if the client implementer determines that they are, at the time of
writing the client, to cross-reference "type" with the IANA registry and
hard-code the redaction based on the description in that registry, there
are a couple of problems:
a) the RFC doesn't say that so we cannot expect implementers to do it,
b) it treats each IANA registry entry as a psuedo-specification,
c) that goes counter to how the RFC describes the process which (from
the RFC abstract) states "This document describes a Registration Data
Access Protocol (RDAP) extension for specifying methods of redaction of
RDAP responses and explicitly identifying redacted RDAP response fields,
using JSONPath as the default expression language."
d) clients must be updated every time the IANA registry is updated
(unlikely),
and e) renders the need for all the complexity in the RFC as unnecessary.
Hopefully that adds more clarity, and if so I can update this section of
the draft with this text.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
