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

"Sehgal, Anjali" <anjalisg@amazon.com> Mon, 15 May 2023 18:39 UTC

Return-Path: <prvs=4925b9b20=anjalisg@amazon.com>
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 956F9C1DF989; Mon, 15 May 2023 11:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.899
X-Spam-Level:
X-Spam-Status: No, score=-11.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ401RbMUsPn; Mon, 15 May 2023 11:39:34 -0700 (PDT)
Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 9B16AC1DF988; Mon, 15 May 2023 11:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1684175974; x=1715711974; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=JbNIRbGM3Z1jmJvtglkcwLEX9H8KiCLqnT7kD+hp70c=; b=tkI9/2w2kFcvMFAeMwL2W20z19IIY/y7uxjHw553sEtW6DMZlNPQ8jg6 pN5DQXWIzhZIrfwo3GLD6O7WSZW7ZmwZdxgUWp9IudFZxMbzc4QOY4WcH 6D5aTeJrAe9DALZ5oUT8jGGjO1Bya6ZUJjx8yChkVhpf3f4rNS1CedZGo U=;
X-IronPort-AV: E=Sophos;i="5.99,277,1677542400"; d="scan'208";a="331996979"
Thread-Topic: [scim] Httpdir early review of draft-ietf-scim-cursor-pagination-00
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-iad-1e-m6i4x-3554bfcf.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-6001.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2023 18:39:33 +0000
Received: from EX19MTAUEA001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1e-m6i4x-3554bfcf.us-east-1.amazon.com (Postfix) with ESMTPS id BEE4080D77; Mon, 15 May 2023 18:34:04 +0000 (UTC)
Received: from EX19D014UEA001.ant.amazon.com (10.252.134.217) by EX19MTAUEA001.ant.amazon.com (10.252.134.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Mon, 15 May 2023 18:34:01 +0000
Received: from EX19D014UEA003.ant.amazon.com (10.252.134.168) by EX19D014UEA001.ant.amazon.com (10.252.134.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.26; Mon, 15 May 2023 18:34:00 +0000
Received: from EX19D014UEA003.ant.amazon.com ([fe80::e4e7:1c85:21fb:5422]) by EX19D014UEA003.ant.amazon.com ([fe80::e4e7:1c85:21fb:5422%3]) with mapi id 15.02.1118.026; Mon, 15 May 2023 18:34:00 +0000
From: "Sehgal, Anjali" <anjalisg@amazon.com>
To: Julian Reschke <julian.reschke@greenbytes.de>, Danny Zollner <Danny.Zollner@microsoft.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
CC: "draft-ietf-scim-cursor-pagination.all@ietf.org" <draft-ietf-scim-cursor-pagination.all@ietf.org>, "scim@ietf.org" <scim@ietf.org>
Thread-Index: AQHZgqwNvLR+7G79M0KQRzdMvpTAVq9TnZeAgAfRpAA=
Date: Mon, 15 May 2023 18:34:00 +0000
Message-ID: <246F8797-9831-4988-A0B9-E23BBEFBE3BA@amazon.com>
References: <167947704028.37309.14733731358104762761@ietfa.amsl.com> <CH0PR00MB1415468132B59D2B74B5F56BFF76A@CH0PR00MB1415.namprd00.prod.outlook.com> <7565e907-1bf3-51f6-a956-c2b1b344944c@greenbytes.de>
In-Reply-To: <7565e907-1bf3-51f6-a956-c2b1b344944c@greenbytes.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.178.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <194E54CDB1CA354F87655675F36ADFC7@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/L3MpGHfH-mX03aEtF-N7qVjYCy4>
Subject: Re: [scim] Httpdir early review of draft-ietf-scim-cursor-pagination-00
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 15 May 2023 18:39:38 -0000

Hi Julian, 

Thank you for your feedback. For point related to cursor obtained that cannot be passed in as query parameter the Specification under Section 3 Querying Resources using POST provides and alternate way to execute the HTTP
POST method combined with the "/.search" path extension to issue execute queries without passing parameters on the URL.

POST /User/.search
 Host: example.com
 Accept: application/scim+json
 Authorization: Bearer U8YJcYYRMjbGeepD
 {
 "schemas": [
 "urn:ietf:params:scim:api:messages:2.0:SearchRequest"],
 "attributes": ["displayName", "userName"],
 "filter":
 "displayName sw \"smith\"",
 "cursor": "",
 "count": 10
 }


Thanks
Anjali

On 2023-05-10, 11:10 AM, "scim on behalf of Julian Reschke" <scim-bounces@ietf.org <mailto:scim-bounces@ietf.org> on behalf of julian.reschke@greenbytes.de <mailto:julian.reschke@greenbytes.de>> wrote:


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.






On 09.05.2023 21:24, Danny Zollner wrote:
> Thank you for the review, Julian. We've just published a new version of the draft (-01) that should address most/all of your feedback. I'm adding notes in-line (prefixed with [DZ] ) to cover what changes were made in response to your feedback.
>
>
> -----Original Message-----
> From: Julian Reschke via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>>
> Sent: Wednesday, March 22, 2023 4:24 AM
> To: ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>
> Cc: draft-ietf-scim-cursor-pagination.all@ietf.org <mailto:draft-ietf-scim-cursor-pagination.all@ietf.org>; scim@ietf.org <mailto:scim@ietf.org>
> Subject: [EXTERNAL] Httpdir early review of draft-ietf-scim-cursor-pagination-00
>
> [You don't often get email from noreply@ietf.org <mailto:noreply@ietf.org>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
>
> 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?
>
> [DZ] Changed to drop the HTTP-based protocols piece, now says "The two common patterns for result pagination are..."


Ok.


> ## 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?
>
> [DZ] The term 'query parameters' is introduced in RFC 7644 3.4.2 and values are introduced throughout the 3.4.2.x section of the spec as filtering, sorting and pagination are defined. Given that, defining query parameters again doesn't seem necessary. If you disagree, happy to reconsider. For the totalResults piece, we've updated the guidance to: " Service Providers implementing cursor pagination that are unable to estimate totalResults MAY choose to omit the totalResults attribute."


Ok, this seems to be an issue with the base spec then. Anyway, what do
you do with a cursor name obtained from JSON that can not be a query
parameter name?





> ## 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.
>
> [DZ] Updated this section to be normative - explicitly states that it is extending the scimType values used in RFC 7644 3.12 to define error response types.


Ok.


> ## Section 2.3
>
> What would be the HTTP status here?
>
> [DZ] Fixed this - 200/OK.


Ok.


> ## Section 3
>
> I'm confused by the term '"/.search" path extension'. The example URL "/User.search" does not seem to use that pattern.
>
> [DZ] There was a typo here - example now states POST /User/.search which should be correct.


Ok.


> # Editorial
>
> - please expand "SCIM" on first use
>
> [DZ] Done.
>
> 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.
>
> [DZ] Agreed, fixed.


Ok.


> "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."
>
> [DZ] Took your wording here and updated.


Ok.


> "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.
>
> [DZ] Expanded to full example.


Thanks.


> The last example could be read as showing a GET request with content; but the content is from the response, right?
>
> [DZ] Adjusted structure to clarify.


Ok.


> ## 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".
>
> [DZ] Fixed both.


Ok.


> # 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.
>
> [DZ] For the nits - they should all be fixed. I may have introduced new formatting (probably indentation) issues however as between last version and this version the draft was rewritten into Markdown/Kramdown from its original XML format.


Thanks!


--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782


_______________________________________________
scim mailing list
scim@ietf.org <mailto:scim@ietf.org>
https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>