> -----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) > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > Murray Kucherawy has entered the following ballot position for > draft-ietf-regext-rfc7482bis-02: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.)
[SAH] [snip] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I concur with Alissa and others that this should make the disposition of RFC > 7482 more explicit. [SAH] Will fix. > "REST" in the glossary is only ever used to defined the next term in it, > "RESTful". It seems to me these could be consolidated. [SAH] I'll keep these as-is since they were inherited from 7482. > 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? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
