Il 04/04/2023 17:37, Jasdip Singh ha scritto:
On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh<jasd...@arin.net>
<mailto:jasd...@arin.net> wrote:
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?
That is what I meant, but perhaps 405 is the more appropriate
response. Kinda annoying that 9082 went through 2 IETF last calls and
this wasn't caught.
-andy
AFAIU, RFC 7231 states that:
- 404 must be returned to signal that the target resource is unknown
to the server;
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
- 405 must be returned to signal that an HTTP method is unsupported on
the target resource but known to the server;
The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not
supported by the target resource
- 501 must be returned to signal that an HTTP method is unknown to the
server
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.
Based on it, don't think rdap-reverse-search should add text to
address these cases.
As I wrote in my previous reply, the document had only to define the
server operation when the client includes in the request an
unsupported reverse search property or combination of reverse search
properties.
In this case, the server must return 400 (Bad Request).
With regard to RFC 9082, my proposal is to remove the sentence in
subject.
[JS] If the intent vis-à-vis error codes is to differentiate a feature
that is not implemented on the server side versus a bad request for an
implemented feature, 400 (Bad Request) does not look like a good fit
for the former since it is not a client error when a feature is not
supported. Thanks to Mario, we learnt 501 (Not Implemented) is also
not a good fit for the former since it is at the HTTP method level
(GET in our case). That seems to leave 405 (Method Not Allowed) as a
viable alternative to 501 since per RFC 9110, “The 405 (Method Not
Allowed) status code indicates that the method received in the
request-line is known by the origin server but not supported by the
target resource.” Irrespective, 501 looks like an errata for Section 1
in RFC 9082.
[ML] Sorry Jasdip, but I didn't catch if your comment (or which part) is
about the reverse search document or RFC 9082.
With regard to the reverse search document, 400 looks to me the only one
fitting the case.
Surely it's a client error if the client includes in the query string
either an unsupported or an invalid combination of reverse search
properties.
Just for example, .it RDAP server requires the client to always include
"role" along with another supported reverse search property in a
reverse search.
The server may restrict the use of the reverse search feature based on
its policy and the client must comply with those restrictions.
Best,
Mario
Thanks,
Jasdip
_______________________________________________
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
