Hi Scott,
please find my comments inline.
Il 05/04/2022 18:26, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: regext <[email protected]> On Behalf Of Antoin Verschuren
Sent: Monday, April 4, 2022 9:19 AM
To: regext <[email protected]>
Subject: [EXTERNAL] [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-
search
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.
Dear Working Group,
The authors of the following working group document have indicated that it
is believed to be ready for submission to the IESG for publication as a
standards track document:
[SAH] I generally agree that the document is ready, but I do have a question
that might drive a change or two: Section 2.1 describes search using vcardArray
RDAP properties. Will additional/different search properties be required if an
RDAP server operator switches from jCard to JSContact?
[ML] JSContact doesn't introduce any additional required property. The
reverse search properties defined in this document are conventional
names to be used as query parameters. The only possible change resulted
from switching to JSContact would affect some of the JSONPath
expressions presented in this document to uniquely map those names to
the RDAP response fields. For example, "$..entities[*].jscard.fullName"
would be the JSONPath expression related to the "fn" research search
property.
Would it sound good to you if I clarified such a concept by adding some
text?
If so, it might be worth noting that these search properties can be affected by
RDAP extensions that modify RDAP data structures.
[ML] As stated in section 2.1, servers are allowed to implement other
properties than those defined. These additional reverse search
properties would be defined out-of-band, just as it would happen for
RDAP response extensions.
Are you suggesting to use an in-band mechanism (like "sorting_metadata"
of RFC8977) by which servers can provide clients with the list of
available reverse search properties?
It might also mean that the JSContact draft will need to include some text to
describe reverse search implications of the data structures it describes.
[ML] Don't see the need for that. Currently, JSContact includes the same
information as jCard so IMO there are no JSContact-specific implications
on reverse search.
Best,
Mario
Scott
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
