Hi Scott,

please find my response below.

Il 05/04/2023 16:43, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Sent: Wednesday, April 5, 2023 10:04 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>; a...@hxr.us
Cc: jasd...@arin.net; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC:
draft-ietf-regext-rdap-reverse-search-
20

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.

Il 05/04/2023 14:40, Hollenbeck, Scott ha scritto:
-----Original Message-----
From: Mario Loffredo <mario.loffr...@iit.cnr.it>
Sent: Wednesday, April 5, 2023 4:24 AM
To: Andrew Newton <a...@hxr.us>; Hollenbeck, Scott
<shollenb...@verisign.com>
Cc: jasd...@arin.net; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC:
draft-ietf-regext-rdap-reverse-search-
20

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 and Andy,

Il 04/04/2023 18:33, Andrew Newton ha scritto:
On Tue, Apr 4, 2023 at 9:20 AM Hollenbeck, Scott
<shollenb...@verisign.com> wrote:
[SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been
obsoleted by
RFC 9110.

The 501 text is 9110 is consistent with 7231, but I don’t think
it’s limited to
an invalid method. If the operative text is “the server does not
support the functionality required to fulfill the request”, the
response can be returned for
*any* condition in which the server does not support the
functionality required to fulfill the request. It doesn’t say that
“the server does not support the requested method”. I still believe that
501
would be the best response.
After rereading the text, I agree with Scott.
[ML] Just to understand better, daes it mean that an RDAP server
should support additional lookups and searches to those really
implemented with the only purpose of returning an error ?
[SAH] No. The point I'm trying to make is that if a client sends a valid
request
to an RDAP server, and that request can't be processed because the requested
functionality isn't supported, then a 501 response is appropriate.

[ML] It's unclear to me what "functionality" (as well as "unsupported query
type") means.

Excluding the HTTP methods and the endpoints, what remains is a
functionality
requested by clients through either a query parameter or an header but
unsupported/unknown parameters/headers are simply ignored.

Is there something else ?
[SAH] A path segment? Imagine sending something like this to a domain name
registry:

https://example.com/rdap/autnum/12

It's RDAP-valid, but a domain name registry probably doesn't support
autonomous system number lookup functionality.

[ML] Don't know if I'm the only one but I think it's an unpractical recommendation.

I admit that 501 is more explanatory because, taking your example, 404 would be returned when the autnum lookup is unsupported and when autnum/12 is not found but a server can provide the clients with information about the supported features by other means.

Conversely,  exposing useless endpoints on the web means not only to require an unnecessary implementation effort but also to enlarge the surface of cyberattacks.

Definitely, the servers need only to handle  the endpoints they really listen at and the query parameters or request headers they really support.

That said, if I'm the only dissonant voice in discussion, I'll add  that recommendation to rdap-reverse-search.


Best,

Mario


Scott
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

--
Dott. 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to