Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-rfc7482bis-02: (with COMMENT)

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-bounces@ietf.org on behalf of 
> shollenbeck=40verisign.com@dmarc.ietf.org>  wrote:
>
>      > -----Original Message-----
>      > From: Murray Kucherawy via Datatracker<noreply@ietf.org>
>      > Sent: Thursday, February 18, 2021 3:30 AM
>      > To: The IESG<iesg@ietf.org>
>      > Cc:draft-ietf-regext-rfc7482bis@ietf.org;regext-chairs@ietf.org;
>      >regext@ietf.org; Mario Loffredo<mario.loffredo@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