[scim] Httpdir early review of draft-ietf-scim-cursor-pagination-00

[Julian Reschke via Datatracker <[e-mail]>]

Reviewer: Julian Reschke
Review result: Ready with Issues

# Questions

## Introduction

"The two common patterns for result pagination in HTTP-based protocols ..."

Is this specific to HTTP based protocols?

## Section 2

Maybe "Query parameter" should be defined (it's not part of HTTP). For
instance, what happens if a cursor name obtained from a JSON response contains
characters not allowed in a query parameter?

"Service Providers implementing cursor pagination that are unable to estimate
totalResults MAY return a response with totalResults set to zero (0)."

Wouldn't it be clearer not to set totalResults at all?

## Section 2.1

"For example, cursor pagination implementations SHOULD anticipate the following
error conditions:"

Which follows seems to be a list of error conditions in prose. It's a bit
unclear what the normative requirement is.

## Section 2.3

What would be the HTTP status here?

## Section 3

I'm confused by the term '"/.search" path extension'. The example URL
"/User.search" does not seem to use that pattern.

# Editorial

- please expand "SCIM" on first use

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

"A cursor value string that MAY be used in a subsequent request to obtain the
previous page of results. Use of previousCursor is OPTIONAL. Service Providers
that are unable to support a previousCursor MAY omit previousCursor when
sending paged query responses. "

The last sentence appears to be redundant.

"The SCIM client MUST consider cursor to be opaque and make no assumptions
about cursor values."

Maybe "Cursor values are opaque; clients MUST not make assumptions about their
structure."

"The response to the query above returns metadata regarding pagination similar
to the following example (actual resources removed for brevity)"

The example only shows the response content; either use the full message or
rephrase.

The last example could be read as showing a GET request with content; but the
content is from the response, right?

## Section 3

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

It's 3.4.3. Also, the correct term is "method", not "verb".

# Nits

- for some reason, the draft name does not appear on the front page of the HTML
version (bug in xml2rfc?)

- Typo in "Rsesources"

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

- Example in Section 3 misses empty line before content.

- Definition list in Section 4 has weird indentation.