Re: [scim] Concerns Regarding Cursor-Based Pagination

["Bojitha Piyathilake (intern)" <[e-mail]>]

Hi Matt,

Thanks for the clarifications and sorry for the delay. As for question 2,
there are some points I would like to share;


   1.

   The service provider configuration could be updated to reflect which
   pagination type is provided by the SCIM service provider by default. For
   example;


{

      "schemas": [

         "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"],

      ...

      "pagination": {

         "cursor":true,

         “default”: “cursor”

      },

      ...

   }

If the default type is “cursor”, then we explicitly check for the existence
of startIndex, else pagination will be done with the cursor, and vice versa.


   1.

   The RFC detailing offset pagination is already published and states that
   the offset value is optional. Requiring the existence of startIndex to
   perform offset pagination would mean the RFC needs to be updated. Whereas
   updating the draft to state that the cursor parameter is mandatory to
   perform cursor pagination, would not require a new version of the RFC -
   7644 to be released. However, when performing cursor pagination, there is
   no cursor value for the initial request. Our approach was to pass an empty
   string as the initial cursor.


Best regards,


On Wed, Jun 1, 2022 at 6:27 AM Matt Peterson (mpeterso) <Matt.Peterson=
[e-mail]> wrote:

> Hi Bojitha,
>
>
>
> It’s important to note that the cursor-based pagination draft is… a draft,
> which means it hasn’t received the full rigor of peer review.  All 3 of
> your questions are reasons enough for a new version of the draft to be
> submitted.
>
>
>
> Question 1
>
> In the Cursor-based Pagination of SCIM Resources draft
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peterson-scim-cursor-pagination-00%23section-2&data=05%7C01%7Cmatt.peterson%40oneidentity.com%7C15ec43f5057c4cf25ece08da41fdbd2b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637894855326559034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yOfNhvjHZM%2Bc8i3S1TMJGt%2F7m9eEWuzqsosop2EkIOM%3D&reserved=0>
> [1], it hasn’t been mentioned how to handle an unspecified count. Am I
> right to assume this can follow the same, as per RFC - 7644
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.2.4&data=05%7C01%7Cmatt.peterson%40oneidentity.com%7C15ec43f5057c4cf25ece08da41fdbd2b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637894855326559034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GRrNcrT1wAUUbnSninzHGh5qXb76icnr7l8W9KRKeMg%3D&reserved=0>
> [2] which states, “If unspecified, the maximum number of results is set by
> the service provider”?
>
>
>
> Correct, the draft assumes that if count is omitted, the service provider
> will set the count as specified in RFC 7644.  It would be better if the
> draft explicitly mentioned this.
>
>
>
> Question 2
>
> In a situation where we wish to provide both cursor based pagination and
> index based pagination in the same SCIM service provider, how would you
> suggest the user decide the pagination approach? RFC - 7644
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.2.4&data=05%7C01%7Cmatt.peterson%40oneidentity.com%7C15ec43f5057c4cf25ece08da41fdbd2b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637894855326559034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GRrNcrT1wAUUbnSninzHGh5qXb76icnr7l8W9KRKeMg%3D&reserved=0>
> [2], states that both the startIndex value and the count are optional
> parameters when making the first offset based request. startIndex will be
> defaulted to 1 and the count will be defaulted to the value specified by
> the service provider. Furthermore, Cursor-based Pagination of SCIM
> Resources draft
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peterson-scim-cursor-pagination-00%23section-2&data=05%7C01%7Cmatt.peterson%40oneidentity.com%7C15ec43f5057c4cf25ece08da41fdbd2b%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637894855326559034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yOfNhvjHZM%2Bc8i3S1TMJGt%2F7m9eEWuzqsosop2EkIOM%3D&reserved=0>
> [1], states that the cursor value of the initial request should be omitted.
>
> eg:
>
> Possible first request for offset pagination: /scim2/Users?count=20 ->
> Offset will be defaulted to 1.
>
> Possible first request for cursor pagination: /scim2/Users?count=20 ->
> Initial cursor is omitted.
>
> The SCIM service provider fails to distinguish the pagination mechanism
> that the user wants for these requests.
>
>
>
> This is an ambiguity that I did not think of when writing the draft.   I
> assumed the ServiceProvider would detect index-based pagination by the
> existence of startIndex in the query.  You are correct, however, that
> startIndex is OPTIONAL.  The draft should be modified to address this
> ambiguity.  Do you have a recommendation?
>
>
>
> Question 3
>
> When querying for resources using a POST request combined with the
> "/.search" path extension, the query params will be contained in the
> request body. How should the cursor attribute be passed? This point is not
> mentioned in the Cursor-based Pagination of SCIM Resources draft [1]
>
>
>
> {
>
>   "schemas": [
>
>     "urn:ietf:params:scim:api:messages:2.0:SearchRequest"
>
>   ],
>
>   "filter": "userName sw A",
>
>   "domain": "PRIMARY",
>
>   "count": 10,
>
>   "cursor": "eyJ2YWx1ZSI6IlNDSU0yQ1"
>
> }
>
>
>
> Correct, this is how the cursor and count should be passed.  Again, the
> draft should be modified to use of cursor pagination with "/.search"
>
>
>
> Once there is feedback on your question #2, I will resubmit a new revision
> of the draft.
>
>
>
> --
>
> Matt Peterson
>


-- 
*Bojitha Piyathilake* | Software Engineering Intern | WSO2 Inc.
(m) [phone] | (e) [e-mail]

<http://wso2.com/signature>
[image: http://wso2.com/signature]
<http://wso2.com/signature>