> -----Original Message----- > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Sent: Wednesday, April 6, 2022 4:18 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org > Subject: [EXTERNAL] Re: [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. > > Hi Scott, > > please find my comments inline. > > Il 05/04/2022 18:26, Hollenbeck, Scott ha scritto: > >> -----Original Message----- > >> From: regext <regext-boun...@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?
[SAH] Yes, please. As currently written, the draft includes these RDAP property descriptions (note use of vcardArray specifically): "Reverse search property: fn RDAP property: $..entities[*].vcardArray[1][?(@[0]=='fn')][3] RFC reference: Section 6.2.1 of [RFC6350] Reverse search property: email RDAP property: $..entities[*].vcardArray[1][?(@[0]=='email')][3] RFC reference: Section 6.4.2 of [RFC6350]" Now imagine that a server operator has made the switch from jCard to JSContact. draft-ietf-regext-rdap-jscontact says this: "Entity objects in RDAP responses MAY include a "jscard" property whose value is a JSCard object instead of the "vCardArray" property defined in [RFC9083]." If there is no vcardArray property, the RDAP property descriptions in the reverse search draft are invalid. That's the situation that needs to be addressed. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
