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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 18 Feb 2021 00:29:30 -0800

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

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I concur with Alissa and others that this should make the disposition of RFC
7482 more explicit.

"REST" in the glossary is only ever used to defined the next term in it,
"RESTful".  It seems to me these could be consolidated.

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?

Thanks for including Section 7.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Feb 2021 16:10:26 +0000

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

[SAH] Will fix.

> "RESTful".  It seems to me these could be consolidated.

[SAH] I'll keep these as-is since they were inherited from 7482.

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Feb 2021 21:14:37 -0800

> [SAH] I'm going to blame that on one of the WEIRDS co-chairs ;) who

They really were a pair of slackers, weren't they?

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

That works for me!

-MSK

---

From: Jasdip Singh <[email-masked]>
Date: Sun, 21 Feb 2021 18:32:14 +0000

Hello Scott,

Please find my comment below.

Jasdip

    > rfc7482bis-02: (with COMMENT)
...    

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

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 22 Feb 2021 14:02:42 +0100

Hi guys,

please find my comments below.

Il 21/02/2021 19:32, Jasdip Singh ha scritto:
> On 2/18/21, 11:13 AM, "regext on behalf of Hollenbeck, Scott"<[email-masked] on behalf of 
> shollenbeck=[email-masked]>  wrote:
>
>      > From: Murray Kucherawy via Datatracker<[email-masked]>
>      > To: The IESG<[email-masked]>
>      > Cc:[email-masked];[email-masked];
>      >[email-masked]; Mario Loffredo<[email-masked]>

[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

> _______________________________________________
> regext mailing list
> [email-masked]
> 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