RE: [Last-Call] [EXTERNAL] Httpdir ietf last call review of draft-ietf-scim-cursor-pagination-07

Hi Mark,

Thanks for your feedback.

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.

Using this criterion, should we also list TCP, and IP as normative references?    It seems overly complicated for every specification to reference the flattened list of the entire tree of normative references.   This will in most cases result in a *very* long list of normative references which makes it difficult to focus the reader’s attention on the few specification(s) that are critically useful in implementing the specification.

In the case of SCIM Cursor-based pagination, the “nearest” and most relevant normative reference is RFC 7644.  THIS is the spec that implementers must understand.... and if they need to also understand HTTP, then they can follow RFC 7644’s normative references... and the normative references in those RFCs until they get to a level (like TCP, IP) where understanding the details is irrelevant.

Is this wrong?

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

FIXED.  Added “The service provider responds with” in places where the reader might otherwise be confused that service provider response being the body of a request.



From: Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>
Sent: Monday, May 5, 2025 7:17 PM
To: Matt Peterson <Matt.Peterson@entrust.com>
Cc: Julian F. Reschke <julian.reschke@greenbytes.de>; ietf-http-wg@w3.org; draft-ietf-scim-cursor-pagination.all@ietf.org; last-call@ietf.org; scim@ietf.org
Subject: Re: [Last-Call] [EXTERNAL] Httpdir ietf last call review of draft-ietf-scim-cursor-pagination-07

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. 


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<mailto: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://urldefense.com/v3/__https://httpwg.org/admin/editors/style-guide*example-messages__;Iw!!FJ-Y8qCqXTj2!eRQmJrh2YdR9Iwl0LmZYUubBGMSka-TNIyzestSdhPNP1FhrxYEmiBOBt6Q4iAWzB1FtzOIbYY6ORlnSjbARfY8QGa69_J3mcg$<https://urldefense.com/v3/__https:/httpwg.org/admin/editors/style-guide*example-messages__;Iw!!FJ-Y8qCqXTj2!eRQmJrh2YdR9Iwl0LmZYUubBGMSka-TNIyzestSdhPNP1FhrxYEmiBOBt6Q4iAWzB1FtzOIbYY6ORlnSjbARfY8QGa69_J3mcg$>



Cheers,



--

Mark Nottingham   https://urldefense.com/v3/__https://www.mnot.net/__;!!FJ-Y8qCqXTj2!eRQmJrh2YdR9Iwl0LmZYUubBGMSka-TNIyzestSdhPNP1FhrxYEmiBOBt6Q4iAWzB1FtzOIbYY6ORlnSjbARfY8QGa7uBSdTvg$<https://urldefense.com/v3/__https:/www.mnot.net/__;!!FJ-Y8qCqXTj2!eRQmJrh2YdR9Iwl0LmZYUubBGMSka-TNIyzestSdhPNP1FhrxYEmiBOBt6Q4iAWzB1FtzOIbYY6ORlnSjbARfY8QGa7uBSdTvg$>



Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.