Return-Path: X-Original-To: scim@mail2.ietf.org Delivered-To: scim@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8B047AEB0F85 for ; Wed, 28 Jan 2026 21:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7rhR3vDvEB7 for ; Wed, 28 Jan 2026 21:19:39 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 18DF1AEB0F7D for ; Wed, 28 Jan 2026 21:19:39 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id d75a77b69052e-5014e1312c6so3794501cf.2 for ; Wed, 28 Jan 2026 21:19:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769663972; cv=none; d=google.com; s=arc-20240605; b=S3zeofMp+7UwoE+Lr6SiEex5Fcj0au78Ylz+75Nf03p9eY36XK1x+xqE1rhANipbmF RUucVMGDnOfJBd8KELjcNV20AdBr/ASSWLb3dSHUiBlnJpZ53igPDqRPgjcqLf3v/snM jgiU6AiFFMgo+hSCyJQHEP5y+HmPXny4dExWV2Y7gXF0tzPWCZXzDP12buIWm1XR//wA 7fAyiKWf+Ek4ml5e8d311HCRT0kHxG9F1PhkPkh5ELnbDKCO5/H3Mg3RG3Q+9HbWj8EN 6qu4uQBf37qrJD6jQXDsNewuL7z1Z9mggwD1C7hDhDs4SXwSLrtSRdglXwASfm6gFL9O ldkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=42cWSUj4P7suTR11K/0qsXrVcdjdx8MSnvhD2hVtOLg=; fh=8bOUSh6t261nbsXaFS0WEt8D90h9WM7e/eMlPdONK2E=; b=OyOQgxwFVDKaVQwOGK4QxPXfLd5VWAyk6gmfqja7rF2mCO2qdUljstI1afy/K/5bOr H5vN6zFaLQt/4x8Mby5sjccZ8FmkJWp4GqZEzDf61opsbfrZmjb99tk3ckSgiLruHmI0 QPBwj6fN9ivmZjudjmPjYSrNCTSkISK1HONMgfEDIpNK63TQQS13i4xYqtzmQMB9uAm4 DpnFL/hJqj6bDuzKzFoO5sqbmIpkYJ5f42hBidGUkFWDj7hwGfKy746JFQ+RS7UL/FWs xR7OdzGZgs3gHEABhhu1Z/Xr7TujZd4xVd2rYjNto+M0WEAHWTHqMkBsr+NeZT0rMCHN hjQQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769663972; x=1770268772; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=42cWSUj4P7suTR11K/0qsXrVcdjdx8MSnvhD2hVtOLg=; b=Z4EaGZkZ8duu57kBQhsczHc+ZszHTSAYnk+/bZjblgfxpBi2g+SFNLSpP57qct4Am0 EGN1RW2ttV1RJFbxrBeQ6mowIb9hHlRcez1UzIqLkz/RSM34RHKBtl4DCs88jr8QD9Uq pLN68Z+RJ+0OVNWA0QcgYSwjfc3jKHiTPmoFMBGn2nt7lasLNoCOf5dZMJWj+Q+rdlH4 5uV+XMrafIzL42zBXO7KhsW1TR5lunc8nOLT5Ozv3ZilJ4dMCfD0GXlW2KCA/zi7T+t7 DA/DNUjIIh2NBtCk2C6PABimzZpWtDLnTiYEBeD1swJDKsaSjFJTa4qN8g2nZpo/IN1f A/zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769663972; x=1770268772; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=42cWSUj4P7suTR11K/0qsXrVcdjdx8MSnvhD2hVtOLg=; b=sassBpZxUwWt95ZEri8h29Rxp85J5HzHzry0a76jcA/fvGijjvwjxL+VSyIdevgzC6 z4+7N65cCM9BGek+QBVci6ugin310a2M720gFFfXoeWtAHX2Lxm2DW0HhJNlsKy5LMkg QSbkmufGJ991FJm0q4TXQ4bFqdlg6u3Sn5oKNQ0EgatyzdyRdSthP6hMx3Ayu3uySEV0 pudA47dRV+egJRkDSJRy8O0lwU6nTpoKXLoYJWa7CTZClZ0f/jPSdvucEmTuKDn/q3uc 1V0m7I2xjrkN0esjn9wrmduV/tlTOcwhSpX0I7HMIzIuVi3sbKmGEfS9/uwsFU5+Jqtg ArOQ== X-Gm-Message-State: AOJu0YzUGH0PM6MkU+qgIWiBullbWX2Lt/EDVy0beAdircRGe8SQPDrk ztx10/e8mMi7kE/UuRtuTPzr4vvgnyLgJbO9/ZK3R6SNhi83nF1i1bHR+VIFXRj+lYyT8CnNNqi 4mtB5JSIUyUy/civ/Y4wqB7M3YSc0gsAdikTg X-Gm-Gg: AZuq6aLNLaHTMr3IFMeI7ZS5bjC9lM2sQ+lf5NAA/Cna3HUlIWp7vmnPE6E7Lt2gh4z zW9OIjZKtjgi9f89w2ISVvwNnNrGeGmvtUsx1kZ7tnbK7iknRMYJ4Lrm17kmJsausAS+XWaZ4s6 P6LAXq3CEBOSTbUp5w4FsGaIZckr/8AHWAfmu54n+tQhYhHKzHk8iTjVVaHDiW0QCi1vDvOoS9W dzgvA+CqS33gK2MsVF0AaVaTOBas2ftKisPxhgpEx7KS1npCvV3jcXAXoGbWUx5ecPAXAA= X-Received: by 2002:a05:622a:15cb:b0:4ec:f6d5:ee46 with SMTP id d75a77b69052e-5032fb18e33mr95824931cf.78.1769663971973; Wed, 28 Jan 2026 21:19:31 -0800 (PST) MIME-Version: 1.0 From: saurabh kushwaha Date: Wed, 28 Jan 2026 21:19:21 -0800 X-Gm-Features: AZwV_QiVrC-Zx3j-rt82jPIeKF7KYL63AIXLuJneHuY_CKG4k0jkOpS1rP_GEww Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="0000000000006bdd210649800022" Message-ID-Hash: AEVUA6LKNDEGAERX5O6KGXVXWDWD4A6Z X-Message-ID-Hash: AEVUA6LKNDEGAERX5O6KGXVXWDWD4A6Z X-MailFrom: saurabhkushwaha123@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-scim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bscim=5D_Pagination_Support_for_Multi-Valued_Attributes_in_SCIM_?= =?utf-8?q?2=2E0?= List-Id: Simple Cloud Identity Management BOF Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006bdd210649800022 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Team, Please review my enchantment request. Description *1. Problem Statement* The current SCIM 2.0 specification (RFC 7644, Section 3.4.2.4 ) defines pagination exclusively at the Resource level using startIndex and count. While this manages the number of Resources (e.g., Groups) returned in a ListResponse, it fails to address Multi-Valued Attributes (MVAs) that may contain a high volume of sub-elements. *Scenario:* =E2=80=A2 A Service Provider (SP) has 10,000 Group resources. =E2=80=A2 One specific Group contains 100,000 members. =E2=80=A2 A client requesting this Group via GET /Groups/{id} or a filtered= search will receive a massive JSON payload because the specification provides no standard mechanism to paginate the members attribute itself. *2. Proposed Enhancement* I propose an extension to the query syntax that allows clients to request specific "slices" of multi-valued attributes. This could be achieved through a new query parameter or an extension of the attributes parameter. *Option A: Attribute-Specific Range Parameters* Introduce a syntax that targets specific attributes for indexing: GET /Groups/{id}?attrStartIndex=3Dmembers:1&attrCount=3Dmembers:100 Option B: Bracketed Indexing in attributes GET /Groups/{id}?attributes=3DdisplayName,members[1-100] *3. Impact Analysis* =E2=80=A2 *Performance*: Drastically reduces memory overhead for both Ident= ity Providers (IdPs) and Service Providers (SPs) when dealing with "Large Groups." =E2=80=A2 *Reliability*: Prevents HTTP 504 (Gateway Timeout) and 413 (Paylo= ad Too Large) errors during full-sync operations. =E2=80=A2 *Backward Compatibility*: If the SP does not support attribute-le= vel pagination, it can default to the current behavior of returning the full list (standard SCIM graceful degradation). Thanks Saurabh Kushwaha --0000000000006bdd210649800022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Team,=C2=A0

Please review my enchantment= =C2=A0request.

Description

1. Problem Statement
The current SCIM 2.0 specification (= RFC 7644, Section 3.4.2.4) defines pagination exclusively at the Resour= ce level using startIndex and count. While this manages the number of Resou= rces (e.g., Groups) returned in a ListResponse, it fails to address Multi-V= alued Attributes (MVAs) that may contain a high volume of sub-elements.
Scenario:
=E2=80= =A2 A Service Provider (SP) has 10,000 Group resources.
=E2=80=A2 One specific Group contains 100,000 members.
=E2=80=A2 A client requesting this Group via= GET /Groups/{id} or a filtered search will receive a massive JSON payload = because the specification provides no standard mechanism to paginate the me= mbers attribute itself.

2. Proposed Enhancement
I propose an extension to the query syntax that allows clients = to request specific "slices" of multi-valued attributes. This cou= ld be achieved through a new query parameter or an extension of the attribu= tes parameter.

Option A: Attribute-Specific Range Parameters
Introduce a syntax that targets specific attribu= tes for indexing: GET /Groups/{id}?attrStartIndex=3Dmembers:1&attrCount= =3Dmembers:100
Option B: Bracketed Index= ing in attributes
GET /Groups/{id}?attri= butes=3DdisplayName,members[1-100]

3. Impact Analysis
=E2=80=A2=C2=A0Performance: Drastically reduces memory= overhead for both Identity Providers (IdPs) and Service Providers (SPs) wh= en dealing with "Large Groups."
=E2=80=A2=C2=A0Reliability: Prevents HTTP 504 (Gateway Timeout) and 41= 3 (Payload Too Large) errors during full-sync operations.
=E2=80=A2=C2=A0Backward Compatibility: If the SP does = not support attribute-level pagination, it can default to the current behav= ior of returning the full list (standard SCIM graceful degradation).

Tha= nks
Saurabh Kushwaha
--0000000000006bdd210649800022--