Hi Jasdip,
I'm inclined to think that the problem lies in how the JSON content is
structured rather than the language used to select JSON values.
There exist two standard languages to select JSON values, namely
JSONPointer and JSONPath. The former is mostly inapplicable to RDAP as
the values that are likely redacted are located in the entity object but
entities associated to an object are represented through an array where
the entity role matters instead of the index.
The latter works much better but the selection of values in the RDAP
response generates language expressions that are very tricky to process
because the jCard format makes use of jagged arrays where items are
selected by property name or by index. The additional issue in redacting
arrays is that redacting an item by removal results in rearranging the
array items. On the contrary, redacting an object member by removal
doesn't impact on the other members.
Definitely, objects i.e. maps should be preferred to arrays as much as
possible because they fits better the redaction process . If you can't
avoid arrays, you should consider to redact the entire array whenever
the items must be redacted.
Sorry if I recall once again the implementation choice Robert and I made
when we had to deal with localizations in JSContact but it comes to mind
easily. Localization as well as redaction requires to select a JSON
value. To facilitate localizations, we decided to use maps to represent
almost all collections in JSContact and mandate the localization of the
entire array of name and address components.
IMO, we should do likewise to best accomplish redaction in RDAP.
Here in the following two JSONPath expressions extracted from a redacted
domain lookup response using jCard [1] and JSContact [2] respectively:
"prePath":
"$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]",
"prePath": "$.entities[?(@.roles[0]=='technical')].jscard.phones.voice"
Please note that in the case of a redacted entity lookup response, the
latter would include only the name selector.
Obviously, using maps to represent the collections of entities
associated to objects would be very helpful but some issues connected
with the entity role should be fixed first (i.e multiple entities having
the same role and single entites having multiple roles). However,
representing the contact data through a fully object-oriented format, no
matter if it will be JSContact or something else, would make redaction
handling by clients as well as the overall handling of the RDAP response
much easier.
Best,
Mario
[1] https://rdap.pubtest.nic.it/domain/meep.it
[2] https://rdap.pubtest.nic.it/domain/meep.it?jscard=1
Il 11/06/2024 06:28, Jasdip Singh ha scritto:
Hi.
It is a bit unfortunate for us as a WG that we missed the fundamental
shortcomings of the JSONPath usage for redaction, as highlighted in
the draft below. Especially, the “prePath” portion where a client
would have no idea about how to apply that expression to the response
in hand. Though the JSONPath use is optional in RFC 9537, that does
not help escape the fact that portions of this extension are
inherently incorrect. Not sure what the path forward is from here but
IMO it would help to address the highlighted issues; either as RFC
9537 bis, or an entirely new approach that does not depend on JSONPath.
Jasdip
*From: *Andrew Newton (andy) <a...@hxr.us>
*Date: *Wednesday, May 29, 2024 at 6:51 AM
*To: *regext@ietf.org <regext@ietf.org>
*Subject: *[regext] Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Hi all,
Over the past several months, we have been implementing the RDAP
redaction extension, RFC 9537.
This I-D describes the issues we have encountered.
-andy
-------- Forwarded Message --------
*Subject: *
New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
*Date: *
Wed, 29 May 2024 03:45:43 -0700
*From: *
internet-dra...@ietf.org
*To: *
Andy Newton <a...@hxr.us> <mailto:a...@hxr.us>
A new version of Internet-Draft
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt has been
successfully submitted by Andy Newton and posted to the
IETF repository.
Name: draft-newton-regext-rdap-considerations-on-rfc9537
Revision: 00
Title: Considerations on RFC 9537
Date: 2024-05-29
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
Status:
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-considerations-on-rfc9537/
HTML:
https://www.ietf.org/archive/id/draft-newton-regext-rdap-considerations-on-rfc9537-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-considerations-on-rfc9537
Abstract:
This document discusses client implementation issues relating to RFC
9537, “Redacted Fields in the Registration Data Access Protocol
(RDAP) Response”. The considerations in this document have arisen
from problems raised by two separate teams attempting to implement
RFC 9537 in both an RDAP web client and an RDAP command line client.
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.
The IETF Secretariat
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
