Hi guys,

please find my comments below.

Il 21/02/2021 19:32, Jasdip Singh ha scritto:
Hello Scott,

Please find my comment below.

Jasdip

On 2/18/21, 11:13 AM, "regext on behalf of Hollenbeck, Scott"<regext-boun...@ietf.org on behalf of shollenbeck=40verisign....@dmarc.ietf.org> wrote:

     > -----Original Message-----
     > From: Murray Kucherawy via Datatracker<nore...@ietf.org>
     > Sent: Thursday, February 18, 2021 3:30 AM
     > To: The IESG<i...@ietf.org>
     > Cc:draft-ietf-regext-rfc7482...@ietf.org;regext-cha...@ietf.org;
     >regext@ietf.org; Mario Loffredo<mario.loffr...@iit.cnr.it>
     > Subject: [EXTERNAL] Murray Kucherawy's No Objection on draft-ietf-regext-
     > rfc7482bis-02: (with COMMENT)
...
     > In Section 4.1:
     >
     >    If a server receives a search request but cannot process the request
     >    because it does not support a particular style of partial match
     >    searching, it SHOULD return an HTTP 422 (Unprocessable Entity)
     >    [RFC4918] response.
     >
     > Why's that only a SHOULD?  What else might an implementer choose to do,
     > and why might that be a reasonable thing to do?  Or if there's no good
     > answer to this, maybe that should be a MUST?
[SAH] I'm going to blame that on one of the WEIRDS co-chairs ;) who reviewed 7482. I agree that it might help to add some more text to explain the rationale for the SHOULD. I don't recall why we used SHOULD here, other than noting that there may be some other response code that might be more appropriate based on a server's policy settings. A server that doesn't support search at all, for example, might instead return a 405 response code. Hmm, might this be an appropriate explanation right here?

[ML] I guess that SHOULD was used instead of MUST because the asterisk character is meaningful only for those servers implementing partial matching, otherwise it is like any other character. Partial matching is optional and REST API providers generally ignores capabilities they don't support. For example, unrecognized optional query parameters are simply ignored when unsupported.

However, I agree that a server must inform the client that partial matching is not allowed just to disambiguate the 404 response received when the asterisk character is meaningless from the same response when it is meaningful but no results are found.


Best,

Mario

[JS] Since, per Section 1, returning 501 (Not Implemented) is a MUST for any 
unsupported query types (including search), employing 405 (Method Not Allowed) 
for the unsupported-search scenario to help explain the SHOULD for 422 
(Unprocessable Entity) could be confusing. Just wanted to highlight that. :)
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

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

Reply via email to