Re: [scim] Queries on SCIM Cursor-based Pagination Draft

Danny Mayer <mayer@pdmconsulting.net> Wed, 09 February 2022 17:31 UTC

Return-Path: <mayer@pdmconsulting.net>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99B33A0A48 for <scim@ietfa.amsl.com>; Wed, 9 Feb 2022 09:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.513
X-Spam-Level:
X-Spam-Status: No, score=-7.513 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYmh45E318Yb for <scim@ietfa.amsl.com>; Wed, 9 Feb 2022 09:31:33 -0800 (PST)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146053A0A6F for <scim@ietf.org>; Wed, 9 Feb 2022 09:31:24 -0800 (PST)
Received: from [192.168.1.193] (pool-108-26-223-182.bstnma.fios.verizon.net [108.26.223.182]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4Jv6P45pbLzMNjx; Wed, 9 Feb 2022 17:31:20 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------D2r0Oz0NqEHtJbQb0XSJKGPQ"
Message-ID: <af56ec62-f73a-2e28-534c-f57db8326bc6@pdmconsulting.net>
Date: Wed, 09 Feb 2022 12:31:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
Content-Language: en-US
To: "Matt Peterson (mpeterso)" <Matt.Peterson=40oneidentity.com@dmarc.ietf.org>, Anuradha Karunarathna <anuradha199528@gmail.com>, "scim@ietf.org" <scim@ietf.org>
References: <CA+OkT=9V-+b7nR=MEovu8r620vPwP_2y5Pprv-YW-8QiXGCLKg@mail.gmail.com> <MWHPR19MB095729F6C69FE4D4C0D5ACCDE12D9@MWHPR19MB0957.namprd19.prod.outlook.com>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <MWHPR19MB095729F6C69FE4D4C0D5ACCDE12D9@MWHPR19MB0957.namprd19.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/WMl360lwnQMWZegDc8G-ptt01bs>
Subject: Re: [scim] Queries on SCIM Cursor-based Pagination Draft
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2022 17:31:40 -0000

I'm not sure I understand this. Why would you have a previous cursor? In 
order to get to a point where you might have a previous cursor you would 
already have traversed that data set. I expect that it would be up to 
the client to have absorbed that data set and not expect the server to 
have remembered that. I can't imagine how you would be able to jump into 
the middle of a set of data. Maybe I'm not understanding how you got to 
this point. Don't forget too that the data may have changed between 
requests so whatever was on that previous data set may have changed.

Danny

On 2/8/22 11:37 AM, Matt Peterson (mpeterso) wrote:
>
> Anurada,
>
> Thank you for the feedback on SCIM Cursor-based Pagination Draft.
>
> You asked:  “No explanation on backward traversal (traverse to the 
> previous page result set)”
>
> I agree.  The draft could describe more clearly the use of 
> previousCursor (when supported).   Would the following rewording of 
> the cursor query parameter be clearer?
>
> cursor – To request the next page, pass the nextCursor value from
>
> the current result page. For the previous page, pass the
>
> previousCursor from the current result page. The cursor parameter
>
> SHOULD be omitted for the first request of a paginated query.
>
> You asked: “As per the following paragraph in the introduction, is the 
> cursor-based pagination supported only when all resources are fetched 
> from the server?”
>
> Not only is filtering an OPTIONAL capability,for service providers,
>
> it is also a very common for SCIM clients to not to use a query
>
> filter in order to intentionally to retrieve all resources.
>
> Therefore, pagination of results (more so than filtering) is a
>
> primary scalability mechanism for SCIM service providers.
>
> No, cursor-based pagination should be supported for filtered and 
> unfiltered requests.  This paragraph in the introduction was intended 
> to counter the opinion that high performance pagination would not be 
> needed if clients would constrain queries with filter.   In a future 
> version of this draft, I would omit this paragraph as there is less 
> controversy on this point than I originally thought.
>
> --
>
> Matt
>
> *From:* scim <scim-bounces@ietf.org> *On Behalf Of * Anuradha Karunarathna
> *Sent:* Monday, February 7, 2022 9:24 AM
> *To:* scim@ietf.org
> *Subject:* [scim] Queries on SCIM Cursor-based Pagination Draft
>
> *CAUTION:*This email originated from outside of the organization. Do 
> not follow guidance, click links, or open attachments unless you 
> recognize the sender and know the content is safe.
>
> Hi all,
>
> WSO2 Identity Server(IS) is a SCIM service provider which supports 
> SCIM 2.0, and SCIM is the main protocol used in identity management in 
> WSO2-IS.
>
> After seeing performance and functionality improvements that can be 
> achieved with the cursor-based pagination we are planning to implement 
> the cursor-based pagination draft [1] in WSO2 IS. While reading the 
> draft spec we encountered the following concerns. Appreciate your 
> clarification and input on these points.
>
> 1.
> 2.
>  3. No explanation on backward traversal (traverse to the previous
>     page result set)
> 4.
>
> ·
>
> ·
>
> ·As per the draft, count and cursor are the URL pagination parameters 
> for cursor-based pagination.
>
> ·(eg: GET /Users?cursor=VZUTiyhEQJ94I&count=10).
>
> ·
>
> ·
>
> ·
>
> ·Also, the definition of the “cursor” attribute is
>
> ·/“//The/
>
> ·*/string/*
>
> ·*/ value from the nextCursor /*/attribute/
>
> ·/ from the previous result page. A  cursor parameter SHOULD be  
> omitted for the first request of the paginated query//”/
>
> ·
>
> ·
>
> ·
>
> ·If the SCIM service provider supports previousCursor, what should be 
> the API request format to
>
> · traverse back to the previous page?
>
> ·
>
> o
>
> o
>
> oSuggestions:
>
> o
>
> 1.
>
> 2.
>
> 3.Instead of “cursor” query param, support two query params as 
> “before” and “after” as similar to
>
> 4. Facebook API[2]
>
> 5.
>
> 6.
>
> 7.
>
> 8.Introduce new query param as “cursorDirection”  to indicate whether 
> the client needs the before/next
>
> 9. set of results from the cursor, and change cursor attribute definition
>
> 10.
>
> 11.
>
> 12.
>
> 13.Only if “count” and “cursor” params are supported, add a prefix to 
> the cursor such as prev_ and
>
> 14. next_ that can be parsed before sending to the DB layer[3].
>
> 15.
>
> *Get next page results*: GET 
> /Users?cursor=base64encode<next_cursor1>&count=10
>
> *Get previous page results*: GET 
> /Users?cursor=base64encode<pre_cursor2>&count=10
>
> 2.
>
> 3.
>
> 4.Supporting filtering params and cursor-based pagination params 
> together in the API request
>
> 5.
>
> As per the following paragraph in the introduction, is the 
> cursor-based pagination supported only when all resources are fetched 
> from the server?
>
> “Not only is filtering an OPTIONAL capability,for service providers,
>
>    it is also a very common for SCIM clients to not to use a query
>
>    filter in order to intentionally to retrieve all resources.
>
>    Therefore, pagination of results (more so than filtering) is a
>
>    primary scalability mechanism for SCIM service providers.
>
> “
>
> [1] 
> https://datatracker.ietf.org/doc/html/draft-peterson-scim-cursor-pagination-00 
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peterson-scim-cursor-pagination-00&data=04%7C01%7Cmatt.peterson%40quest.com%7Cb71a260276744b4a0b2908d9ea564b70%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637798478629490490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UkfdM6WJPc5kO%2FYXW8XEAOMK%2BJo7Yu6Tz84JLWYbTKM%3D&reserved=0>
>
> [2] https://developers.facebook.com/docs/graph-api/results 
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.facebook.com%2Fdocs%2Fgraph-api%2Fresults&data=04%7C01%7Cmatt.peterson%40quest.com%7Cb71a260276744b4a0b2908d9ea564b70%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637798478629490490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=w8VD1YVMi3ZY9ugyo2OwqTILNfcYnR7GPc39oQj5ogo%3D&reserved=0>
>
> [3] 
> https://medium.com/swlh/how-to-implement-cursor-pagination-like-a-pro-513140b65f32 
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fswlh%2Fhow-to-implement-cursor-pagination-like-a-pro-513140b65f32&data=04%7C01%7Cmatt.peterson%40quest.com%7Cb71a260276744b4a0b2908d9ea564b70%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637798478629490490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P%2B8mICK6yoZpnWCcgIB%2FwtSN1ntI%2B8%2Ba64YRi4baVYQ%3D&reserved=0>
>
>
>
> Regards,
>
> Anuradha
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim