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

From: Antoin Verschuren <[email-masked]>
Date: Mon, 4 Apr 2022 15:18:33 +0200

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:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

This WG last call will end at close of business, Monday, 18 April 2022.

Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list.

The document shepherd for this document is Tom Harrison.

Regards,

Jim and Antoin

---

From: Jasdip Singh <[email-masked]>
Date: Mon, 4 Apr 2022 20:38:06 +0000

+1

Jasdip

On 4/4/22, 9:18 AM, "regext on behalf of Antoin Verschuren" <[email-masked] on behalf of ietf=[email-masked]> wrote:

    Dear Working Group,

    Regards,

    Jim and Antoin

    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 5 Apr 2022 08:31:00 +0200

+1

Mario

-- 
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

---

From: Maurizio Martinelli <[email-masked]>
Date: Tue, 5 Apr 2022 10:38:58 +0200

+1

Maurizio

> Il giorno 4 apr 2022, alle ore 15:18, Antoin Verschuren <ietf=[email-masked]> ha scritto:
> 
> Dear Working Group,
> 

----
Dr. Maurizio Martinelli
Responsabile Unità Tecnologica Innovazione Digitale
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, 56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39 050 3152087
Web: http://www.iit.cnr.it/maurizio.martinelli

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 5 Apr 2022 16:26:15 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Antoin Verschuren
> Sent: Monday, April 4, 2022 9:19 AM
> To: regext <[email-masked]>
> 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? If so, it might be worth noting that these search properties can be affected by RDAP extensions that modify RDAP data structures. 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.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 6 Apr 2022 10:18:04 +0200

Hi Scott,

please find my comments inline.

Il 05/04/2022 18:26, Hollenbeck, Scott ha scritto:
> [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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 6 Apr 2022 13:31:57 +0000

> From: Mario Loffredo <[email-masked]>
> Sent: Wednesday, April 6, 2022 4:18 AM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-
> reverse-search
>
> >> 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?
>
> 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"

[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

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 11 Apr 2022 15:50:09 +0200

Reminder,

1 more week remaining for this WGLC. 
In addition to the authors, we received 3 responses so far.

Regards,

Jim and Antoin

> Op 4 apr. 2022, om 15:18 heeft Antoin Verschuren <ietf=[email-masked]> het volgende geschreven:
> 
> Dear Working Group,
>

---

From: Tom Harrison <[email-masked]>
Date: Mon, 18 Apr 2022 21:10:30 +1000

> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

I think this document is in good shape as it is.  Some minor
points/suggestions:

 - Section 2 has "All the predicates are joined by the AND logical
   operator".  For the multivalued predicate properties ('role', 'fn',
   and 'email'), the behaviour as required by the text here may be
   slightly unintuitive.  For example, if two 'fn' predicates are
   included, then an object will only be included in the results if
   one of its related entities matches against both of those
   predicates, which would be unusual given that most entities have a
   single 'fn' property.  Making this requirement clearer may help to
   avoid confusion:

    All the predicates are joined by the AND logical operator.  This
    includes predicates that are for the same property: it is
    necessary in such a case for the related object to match against
    each of those predicates.

 - Section 2 has "Based on their policy, servers MAY restrict the
   usage of predicates to make a valid search condition".  It may be
   useful to clarify how this will happen.  For example:

    Based on their policy, servers MAY restrict the usage of
    predicates to make a valid search condition, by returning a 400
    (Bad Request) response when a problematic request is received.

   (Possibly there's a more appropriate response code than 400 that
   can be used.)

 - Section 2 has:

    related-resource-type: it MUST be one of the resource types for
    lookup defined in Section 3.1 of [RFC9082], i.e. "domain",
    "nameserver", "entity", "ip" and "autnum";

   But the document defines semantics only for "entity" in this
   context.  Some additional text (after the bullet points) that makes
   it clear that this is intentional may be useful:

    While related-resource-type is defined as having one of a number
    of different values, the only searches defined in this document
    are for a related-resource-type of "entity".  Searches for the
    other mentioned types may be defined by future documents.

 - There is no text that specifies the response format for the
   searches.  Although this is arguably implicit based on RFC 9082, it
   may be useful to be explicit about it, by adding another section
   between 2 and 2.1:

    2.1 RDAP Response Specification

    Reverse search responses use the formats defined in section 8 of
    RFC 9082, which correspond to the searchable resource types
    defined in section 2.

 - I-D.ietf-calext-jscontact is listed as an informative reference,
   but it appears to be a normative reference, given that the
   JSONPaths for 'fn' and 'email' are taken from that document.
   Assuming that it is a normative reference, then it may be that the
   reverse search document will be approved notwithstanding the
   downref.  However, there are a couple of options for avoiding that
   in the first place:
    - Define the document in terms of jCard only, and note that
      documents defining successor formats to jCard will describe how
      to handle the conversion from 'fn'/'email' to the corresponding
      fields in the new format.
    - Define inline metadata, so that the relevant JSONPaths are
      available to the client, and can be changed to work for
      JSContact when a server switches to use JSContact (similarly to
      how things work with RFC 8977).

 - Section 2.1 has "Servers MAY implement other properties than those
   defined in this section".  A server that supports other properties
   for the purposes of reverse search has no way to indicate that
   support except by way of a standards-track specification that
   defines a new rdapConformance value, which would be the case
   regardless of this additional text in the document, so it seems
   like this text could be omitted.

-Tom