No worries Jasdip. I'll reply to that post.
Thanks
Mario
Il 05/04/2023 16:46, Jasdip Singh ha scritto:
Hello Mario,
I have attached my comment to Scott’s comment in the other thread. :)
Thanks,
Jasdip
*From: *Mario Loffredo <[email protected]>
*Date: *Wednesday, April 5, 2023 at 4:07 AM
*To: *Jasdip Singh <[email protected]>, Andy Newton <[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Il 04/04/2023 17:37, Jasdip Singh ha scritto:
On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh<[email protected]>
<mailto:[email protected]> 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
[email protected]
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
