- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 May 2025 11:16:46 +1000
- To: Matt Peterson <Matt.Peterson=40entrust.com@dmarc.ietf.org>
- Cc: "Julian F. Reschke" <julian.reschke@greenbytes.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "draft-ietf-scim-cursor-pagination.all@ietf.org" <draft-ietf-scim-cursor-pagination.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "scim@ietf.org" <scim@ietf.org>
Just focusing on a couple of points here - > On 6 May 2025, at 11:00 am, Matt Peterson <Matt.Peterson=40entrust.com@dmarc.ietf.org> wrote: > >> Is the HTTP reference really only informative? > > NO CHANGE. Yes. Informative. HTTP reference isn’t even normative for RFC7644. That seems like an errata on 7644, then. If it's not possible to implement SCIM without implementing HTTP, and the requirements of HTTP are also relevant to SCIM, it needs to be a normative reference. >> The last example in Section 2 could be read as showing a GET request with >> content; but the content is from the response, right? So please split the >> artwork into request/response. > > NO CHANGE. Again, we follow patterns established by RFC 7644. We wanted cursor pagination draft to fit as closely as possible as an “addendum to” RFC 7644 where, in 3.4.2.4 which uses table to define index pagination query parameters. From what I can see, 7644 typically separates responses from requests with a phrase like "The server responds with", to more clearly delineate them; that is not done here. For best editorial practice, see also: https://httpwg.org/admin/editors/style-guide#example-messages Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 6 May 2025 01:16:57 UTC