Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-reverse-search

Hi Scott,

please find my comments inline.

Il 05/04/2022 18:26, Hollenbeck, Scott ha scritto:
>> -----Original Message-----
>> From: regext <regext-bounces@ietf.org> On Behalf Of Antoin Verschuren
>> Sent: Monday, April 4, 2022 9:19 AM
>> To: regext <regext@ietf.org>
>> 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
> regext@ietf.org
> 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