Hello Mario, Please find my comment below.
Thanks, Jasdip From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Monday, April 3, 2023 at 6:18 AM To: Jasdip Singh <jasd...@arin.net>, Andy Newton <a...@hxr.us>, "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20 Hi Jasdip, Il 01/04/2023 23:55, Jasdip Singh ha scritto: On 3/22/23, 5:44 PM, "regext on behalf of Andrew Newton" <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us<mailto:a...@hxr.us> <mailto:a...@hxr.us><mailto:a...@hxr.us>> wrote: Ok. I did find one small issue. Should the draft give explicit mention of returning an HTTP 501 for searches not supported by a server? [JS] Section 1 of RFC 9082 says, "Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported query types." If that strictly applies to the query types listed in RFC 9082, then an explicit mention in this draft makes sense. Sorry but it's not clear to me the meaning of "unsupported query types". In RFC7231 HTTP 501 is used to signal a client that it requested a method on a given resource the server doesn't implement : Section 4.1 The set of methods allowed by a target resource can be listed in an Allow header field (Section 7.4.1). However, the set of allowed methods can change dynamically. When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code. and Section 6.6.2 The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. The only HTTP method available on RDAP search endpoints is GET so I don't think we need to add text to clarify it. In the case the client requests for an endpoint that is not supported, the HTTP code to be used is 404 (Not Found). Section 6.5.4. The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. The remaining case to handle is when the client requests for a supported endpoint but the server policy restricts the usage of the predicates in the reverse search and the draft have already addressed it. Which "unsupported query types" are you thinking about ? [JS] From Section 1 of RFC 9082: “The intent of the patterns described here is to enable queries of: * networks by IP address; * Autonomous System (AS) numbers by number; * reverse DNS metadata by domain; * nameservers by name; and * entities (such as registrars and contacts) by identifier. Server implementations are free to support only a subset of these features depending on local requirements. Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported query types.” IIUC, "unsupported query types" seems to apply to the above list of queries via-a-vis returning HTTP 501. What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HTTP 501 to unsupported request methods seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly in RFC 9082?
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
