Hi Jasdip,
AFAIU, the name.type value is a shortcut to point to a precise field and
I suppose such pointer should be hardcoded in the client.
When the name.description value is reported, the path value must be used
instead.
However, there are cases where the name.type value is not sufficient to
uniquely indentify the redacted field. For example, when there are
multiple tech contacts associated to a domain and some/all of them are
redacted.
Anyway, one thing that IMO would really help clients in handling the
redaction paths is to avoid (as much as possible) operators that can
select multiple path nodes lke wildcard, filters and so on.
No matter if you use JSONPath or another language to select JSON values,
the usage of those operators along with arrays would always make the
implementers' burden very hard.
I would also normatively prevent registries from redacting multiple
objects or same field across multiple objects in one shot such as
redacting all the email addresses of tech contacts. I mean, the items in
the redacted array should exactly match the fields or the entire objects
redacted.
That said, I would add the following option to your list:
Option 5: Opt for a contact format that minimizes the use of arrays and,
when they are used, prevent the redaction of a single item.
Best,
Mario
Il 15/06/2024 20:49, Jasdip Singh ha scritto:
Hi,
Mario, sorry for my late reply.
Agree that JSON objects seem more conducive to pinpointing redaction
than JSON arrays, and preferring JSONPath over JSONPointer. But,
overall, the challenge remains for us to somehow address the JSONPath
deficiencies identified in Andy’s paper, to end up with a normative,
correct redaction spec for RDAP data. Please allow me to explain how
we might be able to move forward here.
Imagine a JSON response from an RDAP server as a text document, and
with parts of that text redacted. Since such a document would be
structured for RDAP, beside human-friendly perception of redacted text
(like we cannot see redacted words or lines in a redacted text
document), we would need precise pinpointing of fields whose values
are fully or partially redacted, especially if one were to build a
general-purpose RDAP client serving all industries (be it DNRs, RIRs,
space, etc.). We thought JSONPath could but seems deficient,
especially for prePath scenarios and wildcard and recursive selectors.
IMO, we have few options to help achieve a normative, correct
redaction spec:
Option 1: Try addressing deficiencies identified in Andy’s paper
vis-à-vis the JSONPath and name approaches.
Option 2: Gut out the JSONPath approach completely to improve
correctness of RFC 9537.
Option 3: As for the current name approach in RFC 9537, set the
expectation that clients would need to hardcode the redacted name to
field name mapping for IANA-registered names, periodically check the
IANA registry for newer name registrations, and that mapping
unregistered names to field names could be problematic in terms of a
client missing some.
Option 4: Look for another way to do redaction that guarantees
redacted field name pinpointing correctness.
We might eventually need a WG poll on these options, or another set of
options, but let me try assessing above options:
Doesn’t look Option 1 could be fully achieved, especially because of
prePath scenarios and wildcard and recursive selectors.
Option 2 helps.
Option 3 won’t make general-purpose client implementors happy.
Option 4 might need to work with some assumptions/constraints, like
what JSON types (out of string, number, boolean, array, and object) it
guarantees redaction pinpointing accuracy for when it comes to RDAP data.
In other words, there does not seem to be a redaction panacea out
there. :)
Thanks,
Jasdip
*From: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Date: *Tuesday, June 11, 2024 at 6:27 AM
*To: *Jasdip Singh <jasd...@arin.net>, Andrew Newton (andy)
<a...@hxr.us>, regext@ietf.org <regext@ietf.org>
*Subject: *Re: [regext] Re: Fwd: New Version Notification for
draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
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')]"
<mailto:$.entities[?(@.roles[0]=='technical')].vcardArray[1][?(@[1].type=='voice')]>,
"prePath":
"$.entities[?(@.roles[0]=='technical')].jscard.phones.voice"
<mailto:$.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> <mailto:a...@hxr.us>
*Date: *Wednesday, May 29, 2024 at 6:51 AM
*To: *regext@ietf.org <regext@ietf.org> <mailto: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
--
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
