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

Hi Julian,

Thank you for sending feedback on the draft:

## Section 2

Please add some intro text about what "query params" and "response attributes"
refer to (one is in the HTTP URL, the other in the response content, right?)

"This value may only contain characters from the unreserved characters set
defined in section 2.2 of [RFC3986]"

It's section 2.3 of RFC 3986. (also, trailing "." missing)

FIXED

"Cursor has expired. Do not wait longer than cursorTimeout (600 sec) to request
additional pages."

Are these limits hard-wired?

FIXED.

## Section 2.2

"If sorting is implemented as described Section 3.4.2.3 of [RFC7644], then
cursor-paged results SHOULD be sorted."

What would be a reason not to sort them but still return a 2xx? Maybe this is
really a MUST?

As stated in the “introduction”, the reason for the pagination draft is to allow SCIM service provider implementations to be written on top of databases that do not readily support index-based pagination.  We did not want to additionally limit pagination by requiring that pages are sorted.  A service provider may be able to support sorted index-based pagination but not support sorted cursor pagination.   Use of “SHOULD” allows for this (hopefully rare) situation.

## Section 2.4

"Implementers of SCIM service providers that previously supported index-based
pagination and are adding support for cursor-based pagination SHOULD carefully
consider the impact to existing SCIM clients before changing the default
pagination method in a return set."

Do not use conformance keywords when talking about *implementors*.

RFC7644 (which this draft is an extension of) established the pattern of using conformance words with talking about implementers.  There are 11 instances of this in RFC7644.   However, thanks to your feedback we have changed two spellings of implementor to implementer to be consistent with RFC7644😊

## Section 3

"Section 3.4.2.4 of [RFC7644] defines how clients MAY execute the HTTP POST
method combined with the /.search path extension to issue execute queries
without passing parameters on the URL."

That is Section 3.4.3 (unless I'm missing something here).

FIXED

Also: is this a
BCP14 "MAY"?
Also: maybe "path postfix" instead of "path extension". Furthermore: "passing
*query* parameters *in* the URL".

NO CHANGE.  The use of the “MAY” and “path extension” are result of quoting RFC7644 section 3.4.3

"When using /.search, the client would pass the parameters defined in Section 2"

Sentence incomplete, or just a dot missing?

FIXED (missing period)

General remark: it's not entirely clear here why POST is described as
alternative. URL length limits? Prevent logging of queries as part of URLs? A
short sentence explaining the motivation would be good.

Also note that in general POST is not idempotent nor safe. You may want to have
a look at the QUERY method (soonish ready).

NO CHANGE.  The draft extends RFC7644.  This section 3 was not in early drafts because we thought it was implied that cursor pagination attributes would be used in the same way as index pagination parameters in a POST query.   We don’t comment on the rationale that the authors of RFC 7644 had for specifying POSTing queries

"Before using cursor-based pagination, a SCIM client MAY fetch the Service
Provider Configuration document from the SCIM service provider and verify that
cursor-based pagination is supported."

That's a good example for incorrect use of BCP14 keywords. Does a client need
permission to do this? And is this permission only valid before using
pagination?

NO CHANGE.  Use of MAY in this paragraph came from similar usage of MAY found in RFC 7644 section 4 when “that [serviceProviderConfig] MAY be retrieved using HTTP GET”.   Honestly... I don’t think it matters for interoperability whether it’s MAY, may, or can (which is how BCP 14 sec 5 defines the use of MAY).    If changing from “MAY” to “can” will help really help produce better interoperability, we’ll change it.

## Section 9

Is the HTTP reference really only informative?

NO CHANGE.  Yes. Informative.  HTTP reference isn’t even normative for RFC7644.

Tables 1 and 2 seem to be good candidates for definition lists.

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.

## Nits

FIXED.  Most nits fixed by me using more up-to-date markdown to RFC converter  before uploading to the IETF editor :-/

--
Matt

From: Julian Reschke via Datatracker <noreply@ietf.org>
Sent: Friday, April 11, 2025 10:54 AM
To: ietf-http-wg@w3.org
Cc: draft-ietf-scim-cursor-pagination.all@ietf.org; last-call@ietf.org; scim@ietf.org
Subject: [EXTERNAL] Httpdir ietf last call review of draft-ietf-scim-cursor-pagination-07

Document: draft-ietf-scim-cursor-pagination Title: Cursor-based Pagination of SCIM Resources Reviewer: Julian Reschke Review result: On the Right Track # Non Editorial I do understand that this spec builds upon earlier work, but. . . .. . this is


Document: draft-ietf-scim-cursor-pagination

Title: Cursor-based Pagination of SCIM Resources

Reviewer: Julian Reschke

Review result: On the Right Track



# Non Editorial



I do understand that this spec builds upon earlier work, but...



....this is an example (among many many others, indeed) of violating the

principles explained in <https://urldefense.com/v3/__https://www.rfc-editor..org/rfc/rfc8820.html__;!!FJ-Y8qCqXTj2!al7ChYP_tJv5HamRYDHpiwjt9S9uMRnYlNCUhPsm8iPMv-fEhScrU8PYeY5tLPmCe9XmG-DX48JHpA0bvA$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8820.html__;!!FJ-Y8qCqXTj2!al7ChYP_tJv5HamRYDHpiwjt9S9uMRnYlNCUhPsm8iPMv-fEhScrU8PYeY5tLPmCe9XmG-DX48JHpA0bvA$>>;

discovery of capabilities should happen using links in response (such as link

relations); global resources should go under "/.well-known/" (see

https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8615.html__;!!FJ-Y8qCqXTj2!al7ChYP_tJv5HamRYDHpiwjt9S9uMRnYlNCUhPsm8iPMv-fEhScrU8PYeY5tLPmCe9XmG-DX48KG6f-Dmw$<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc8615.html__;!!FJ-Y8qCqXTj2!al7ChYP_tJv5HamRYDHpiwjt9S9uMRnYlNCUhPsm8iPMv-fEhScrU8PYeY5tLPmCe9XmG-DX48KG6f-Dmw$>).



## Section 2



Please add some intro text about what "query params" and "response attributes"

refer to (one is in the HTTP URL, the other in the response content, right?)



"This value may only contain characters from the unreserved characters set

defined in section 2.2 of [RFC3986]"



It's section 2.3 of RFC 3986. (also, trailing "." missing)



## Section 2.1



"For HTTP status code 400 (Bad Request) responses, the following detail error

types are defined."



For status 400 only?



"Cursor has expired. Do not wait longer than cursorTimeout (600 sec) to request

additional pages."



Are these limits hard-wired?



## Section 2.2



"If sorting is implemented as described Section 3.4.2.3 of [RFC7644], then

cursor-paged results SHOULD be sorted."



What would be a reason not to sort them but still return a 2xx? Maybe this is

really a MUST?



## Section 2.4



"Implementers of SCIM service providers that previously supported index-based

pagination and are adding support for cursor-based pagination SHOULD carefully

consider the impact to existing SCIM clients before changing the default

pagination method in a return set."



Do not use conformance keywords when talking about *implementors*.



## Section 3



"Section 3.4.2.4 of [RFC7644] defines how clients MAY execute the HTTP POST

method combined with the /.search path extension to issue execute queries

without passing parameters on the URL."



That is Section 3.4.3 (unless I'm missing something here). Also: is this a

BCP14 "MAY"?



Also: maybe "path postfix" instead of "path extension". Furthermore: "passing

*query* parameters *in* the URL".



"When using /.search, the client would pass the parameters defined in Section 2"



Sentence incomplete, or just a dot missing?



General remark: it's not entirely clear here why POST is described as

alternative. URL length limits? Prevent logging of queries as part of URLs? A

short sentence explaining the motivation would be good.



Also note that in general POST is not idempotent nor safe. You may want to have

a look at the QUERY method (soonish ready).



## Section 4



"Service providers containing multiple resource types may have different values

set for each resource type."



Not sure how important discovery is. But if it is, it might be good to allow

discovery per resource or type of resource (link relation?).



"Before using cursor-based pagination, a SCIM client MAY fetch the Service

Provider Configuration document from the SCIM service provider and verify that

cursor-based pagination is supported."



That's a good example for incorrect use of BCP14 keywords. Does a client need

permission to do this? And is this permission only valid before using

pagination?



-> Just replace "MAY" by "can".



## Section 9



Is the HTTP reference really only informative?



## Editorial



- BCP14 keywords should only be used for real conformance topics. SHOULD

usually requires explaining why it's not a MUST (that is, under which

circumstances it might be ok not to follow it).



- please expand "SCIM" on first use



Tables 1 and 2 seem to be good candidates for definition lists.



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.



## Nits



- Definition list in Section 4 has weird indentation.



- Section 3: "to issue execute queries"



- Section 5.4: "&Cursor"



- Section 5.5: "relvant"



- Section 6: "...requests IANA to amends the..."



- Sections references are not links (both internal and external)



- Change logs and Acks should be in the appendix.







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.