Andy,
Let me address the issue that you've raised with the use of the "name" members
required in RFC 9537:
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,
JG - You need to clarify what you expect to be included in the RFC. Can you
point to specific language for the implementation of base RDAP RFCs as an
example?
b) it treats each IANA registry entry as a psuedo-specification,
JG - No, it registers a set of standard values that the servers can use in the
RDAP response, and the clients can key off. The "redacted name" and "redacted
reason" RDAP JSON Values types follow the same purpose as the other RDAP JSON
Values types ("status", "role", " notice and remark type", "event action"). Do
you have a similar issue with the other RDAP JSON Values types?
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."
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.
d) clients must be updated every time the IANA registry is updated
(unlikely),
JG - No, the clients can ignore any redacted "name" values that they don't
recognize, but I don't see a reason to do that. This is consistent with the
language in RFC 9083, " Clients of these JSON responses SHOULD ignore
unrecognized JSON members in responses." I would display all the "name" values
returned in the response and key off the registered ones for additional display
features to the end user, such as displaying a deleted field using strikeout
text.
and e) renders the need for all the complexity in the RFC as unnecessary.
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.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 6/14/24, 3:58 PM, "Andrew Newton (andy)" <a...@hxr.us <mailto:a...@hxr.us>>
wrote:
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.
On 6/14/24 14:59, Hollenbeck, Scott wrote:
>> -----Original Message-----
>> From: Andrew Newton (andy) <a...@hxr.us <mailto:a...@hxr.us>>
>> Sent: Friday, June 14, 2024 2:42 PM
>> To: Gould, James <jgo...@verisign.com <mailto:jgo...@verisign.com>>;
>> kowa...@denic.de <mailto:kowa...@denic.de>; regext@ietf.org
>> <mailto: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://secure-web.cisco.com/1RsSEeXWP0prNdzuBkTV16IIF0gufCiEyzAzySVVGmF79znykoCncMyxR6pBXzRqo-SRVrhVpuh5fz0y2LT0H2n7JwUioPcwJOArdfdEqYUjILhmHQl6HehjQ-h8YeIHLv73s3KXjHdUN328W18klV8JgQAFiubhI5aXoOTSQK3iy95k0Ksmhapnvbpztc9GSohSSIwkhrKczfldPrtYWsW1Pk-RkqUDqMni0-ANzNa7L4NM28nmXACLnJcWPEfaJSotWiMSlVm0A687De2Hz7hEXSJ7CtX-dECnPkSCxo4A/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FFlDF-Hcmf_4vPwU8ULqiBaThRCE%2F
<https://secure-web.cisco.com/1RsSEeXWP0prNdzuBkTV16IIF0gufCiEyzAzySVVGmF79znykoCncMyxR6pBXzRqo-SRVrhVpuh5fz0y2LT0H2n7JwUioPcwJOArdfdEqYUjILhmHQl6HehjQ-h8YeIHLv73s3KXjHdUN328W18klV8JgQAFiubhI5aXoOTSQK3iy95k0Ksmhapnvbpztc9GSohSSIwkhrKczfldPrtYWsW1Pk-RkqUDqMni0-ANzNa7L4NM28nmXACLnJcWPEfaJSotWiMSlVm0A687De2Hz7hEXSJ7CtX-dECnPkSCxo4A/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FFlDF-Hcmf_4vPwU8ULqiBaThRCE%2F>
I outline the use of the name value here:
https://secure-web.cisco.com/1o3iQmNkajmZZwvrcUDE1Y6MfuFqsDQ6P5aSjg6yDJS-pCkCG4Gc_GoisHK9pp9d8-3_ARG3yAeGtMmoUNqsvE5AJKHzhO3WWXPlTa1EpxJRopRoEJC643bo7lRNSeulbHHn-K3PEJ4Q-JqkwDrDa4lA3vaXp-C3oUDCffJ7V2cNM5JJNcQ5dMXcCWca2OTsQuVGo_Jn7Dqd-_OOZy74bUNwfOtJ1nRm-8fliz3hls4rQJutcjXpzeM9JRoS-ZhSi2DLVZ1uxWW3nfM9wt84HvFiSRJujLQV1U1BWRQwGFSk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00%23name-redaction-by-removal
<https://secure-web.cisco.com/1o3iQmNkajmZZwvrcUDE1Y6MfuFqsDQ6P5aSjg6yDJS-pCkCG4Gc_GoisHK9pp9d8-3_ARG3yAeGtMmoUNqsvE5AJKHzhO3WWXPlTa1EpxJRopRoEJC643bo7lRNSeulbHHn-K3PEJ4Q-JqkwDrDa4lA3vaXp-C3oUDCffJ7V2cNM5JJNcQ5dMXcCWca2OTsQuVGo_Jn7Dqd-_OOZy74bUNwfOtJ1nRm-8fliz3hls4rQJutcjXpzeM9JRoS-ZhSi2DLVZ1uxWW3nfM9wt84HvFiSRJujLQV1U1BWRQwGFSk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-newton-regext-rdap-considerations-on-rfc9537-00%23name-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
