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