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

[Jasdip Singh <[e-mail]>]

Hello Scott,

Please find my comment below.

Jasdip

On 2/18/21, 11:13 AM, "regext on behalf of Hollenbeck, Scott" <[e-mail] on behalf of shollenbeck=[e-mail]> wrote:

    > -----Original Message-----
    > From: Murray Kucherawy via Datatracker <[e-mail]>
    > Sent: Thursday, February 18, 2021 3:30 AM
    > To: The IESG <[e-mail]>
    > Cc: [e-mail]; [e-mail];
    > [e-mail]; Mario Loffredo <[e-mail]>
    > 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?

[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. :)