Re: [scim] [EXTERNAL] Query on a specific known resource

Phillip Hunt <phil.hunt@independentid.com> Thu, 07 July 2022 18:43 UTC

Return-Path: <phil.hunt@independentid.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 B78FEC159827 for <scim@ietfa.amsl.com>; Thu, 7 Jul 2022 11:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.803
X-Spam-Level:
X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20210112.gappssmtp.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 W8xEcshiymEI for <scim@ietfa.amsl.com>; Thu, 7 Jul 2022 11:42:58 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B8CC15D47D for <scim@ietf.org>; Thu, 7 Jul 2022 11:42:48 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id j3so8491749pfb.6 for <scim@ietf.org>; Thu, 07 Jul 2022 11:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KzS8ulj97KhlkeSmfXoCkU3Fcc6MLuMEM61w5y9sEyI=; b=6gQGVqvv+cEHxbQ5V5t+qSp+OPVINgsPFoSjXGJ9qmfaGDKYilMlkVjaALx+ZyhIiw VxrfZilK7JBMnzEmBJ3UZxUJTdKF7snIOpjjlRl3C7c2p8etG82o1mJqQEwh7pjzPpF1 hLOpvjAwS3KEOPh2aI4CygvLiCjTTCBk4klsNBfppZ8EBQqA0g8J3QR/EuAvVY5WEygA HrbxDdaU6ydgiG3dGD9ahkU1je0LkAax/cJOvHhQRsvoWVcnpO9OroKyv4D7eyjOMopU UdWMF1hYfHceJBWptpni4hWrbw3g2Ho1MTXEQuZrDr4pLSaKfbTy4ycGgM7frU5Wf1a0 cLQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KzS8ulj97KhlkeSmfXoCkU3Fcc6MLuMEM61w5y9sEyI=; b=QrzlNu7VjDUJijDJQdp/jKKdejO12PTzThTDkD4YBn2s9KjouwK/rhLRvr/4Wc0siO PlMaAhGfQN4TIOnzEzAihZ7pXaDQcOOGGlwdJCVTTSPnO83FAcBof3rv1jvhKOIm0o8c c1kPIQGZSaa8wZxa2Ocgyy4t8i9zBOMZPXNvgsGMc9mPzm1y7Yn+Bn260ditr2jolyov 53p138aa8mcpOksmjLO330iVGXZmevDrAw0wlY2kryp7sn1yC+cgLsFxeLIiYXqtnsXk NsLZ1YvfvwZ9vRs+n8W6+Z4ov5e93ZcCiDvCNQeICmcQk2N8++EE55suatJ4vU9G/q09 gpqA==
X-Gm-Message-State: AJIora9tlkL/QNtbmD/LpyyLG6EBVNbWmydhGAfptc0WNc3TkjjxkqHX uuQLGouLn9uiS98Lqp9LDCSvUg==
X-Google-Smtp-Source: AGRyM1vD+TeTv2IjM0iQxQq89omXcgK/97Qt8tRA2N/KGYOKpNOCz3zDWdCD8R4FKyrN3ogtVSvmyg==
X-Received: by 2002:a17:902:f652:b0:156:701b:9a2a with SMTP id m18-20020a170902f65200b00156701b9a2amr54903811plg.14.1657219367533; Thu, 07 Jul 2022 11:42:47 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qjhqzxomcnng94hruik.ipv6.telus.net. [2001:569:7316:ae00:75b5:8761:3d20:a43c]) by smtp.gmail.com with ESMTPSA id m14-20020a056a00080e00b00525b61f4792sm22540208pfk.109.2022.07.07.11.42.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2022 11:42:47 -0700 (PDT)
From: Phillip Hunt <phil.hunt@independentid.com>
Message-Id: <22D90800-7379-42B6-8547-C922FC2EF0C0@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_58762BF1-3533-4179-8F76-8A9EC76CD82D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Thu, 07 Jul 2022 11:42:45 -0700
In-Reply-To: <MN2PR00MB0720FB58CB201915199826FDFF839@MN2PR00MB0720.namprd00.prod.outlook.com>
Cc: Julien Schneider <julien@audriga.com>, "scim@ietf.org" <scim@ietf.org>
To: Danny Zollner <Danny.Zollner@microsoft.com>
References: <bc9c53f8-82fd-57e9-8fe0-166e91048d6b@audriga.com> <MN2PR00MB07189D4A9DA54A11131E9896FF839@MN2PR00MB0718.namprd00.prod.outlook.com> <7792b174-48ad-181c-11e1-9adb5ff3bc54@audriga.com> <E034E806-F3BF-41B0-88BE-FC9C4E420561@independentid.com> <MN2PR00MB0720FB58CB201915199826FDFF839@MN2PR00MB0720.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/8Nx9SjZS3l6eFbBv9qp9wNnaUXs>
Subject: Re: [scim] [EXTERNAL] Query on a specific known resource
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: Thu, 07 Jul 2022 18:43:02 -0000

In practical terms, only the presence of a filter defines a query that mandates a ListResponse.  The other time a ListResponse is needed is a GET at the root level (which many don’t permit) or at the Resource folder level.

Attributes/excludedAttributes are listed under both 3.4.2 and 3.9.  In practical terms, the presence of the attributes/ecludedattributes qualifiers does not indicate a ListResponse.  Attributes are simply permitted on any SCIM operation. POST, GET, Query, etc.  A simple GET with Attributes does NOT require ListResponse (unless a filter is present) as per Section 3.9 and shown in the example.

Phillip Hunt
@independentid
phil.hunt@independentid.com




> On Jul 7, 2022, at 11:04 AM, Danny Zollner <Danny.Zollner@microsoft.com> wrote:
> 
> Hi Phil,
>  
> I’m attempting to clarify what you’ve said here for both my own knowledge and others. Anything under a subsection of RFC 7644 3.4.2 counts as a query. Query endpoints can be /Users/{id}, /Users, /Groups, and although not explicitly listed - /AnyOtherResource/{id} as well.
>  
> Features that fall under the label of queries and therefore require a ListResponse type response would be:
>  
> Filtering – i.e.: GET /x?filter=userName eq “blah”
> Sorting
> Pagination
> Attributes – both ?attributes= and ?excludedAttributes=
>  
> Looking at 3.4.2.1, where the query endpoints are listed, the following parts of 3.4.2.x make sense and what you’re saying is apparent. From my own observations, I think there may be hundreds of implementations out there that implement ?attributes and ?excludedAttributes without a ListResponse wrapper when the query URL is a known resource such as GET /Groups/456?excludedAttributes=members.
>  
> I think we’re still a while away from attempting major changes to the protocol and schema RFCs, but in the future I’d be interested in having a discussion on adding an exception to the ListResponse requirement for querying known resources. The attributes queries are a bit different from the others. For filter, sort and paginate you can only really use them against the root of the server or the root of a resource (i.e.: /Users) as I understand it. I can’t think of a scenario where you’d do a filter like GET /Users/123?filter=userName eq “x” – is there a use case there that I’m missing? Similarly, I can’t think of scenarios where you’d sort or paginate results for GET /Users/123.
>  
> Thanks,
>  
> Danny
>  
> From: Phillip Hunt <phil.hunt@independentid.com> 
> Sent: Thursday, July 7, 2022 12:36 PM
> To: Julien Schneider <julien@audriga.com>
> Cc: Danny Zollner <Danny.Zollner@microsoft.com>; scim@ietf.org
> Subject: Re: [scim] [EXTERNAL] Query on a specific known resource
>  
> Julien,
>  
> You are not wrong.  All queries regardless of path MUST have a ListResponse.
>  
> It may seem logical to make the jump to just returning a single resource for a query that can only return a single result, but this is not permitted in the RFC. From a protocol point of view, allowing skipping ListResponse makes the protocol more complex because it creates “exceptions” which have to be handled. For example, what happens if no filter match etc.
>  
> For the group:  For historical information, the issue is actually more complex than it seems.   For SCIM queries SCIM’s profile of HTTP overrides both HTTP GET (retrieves a resource) and HTTP POST (create a resource) to perform a search function. In the case of GET, url based filters cause privacy concerns because of the leak of confidential information in URLs. The GET method does not allow request bodies. Because of thies, SCIM also supports http POST queries. The HTTP definition suggests creation a resource.  Dual purposing these methods for search queries created necessary complexity. One of the basic rules of thumb is that whenever a “filter” shows up in a request, the request becomes a SCIM Query which mandates a ListResponse.
>  
> I discussed this at length with authors of the HTTP specifications and worked with Julian Reschke (co-author of HTTP) to submit a proposal for a HTTP SEARCH method.  This would unburden GET and POST methods and simplify protocol overall.  Julian indicated to me at the time of finalizing SCIM (around IETF93), that this issue comes up frequently for him as one of the HTTP authors.  In the end, the HTTPbis WG chose not to create a new method because there is too much water under the bridge.  See: https://httpwg.org/wg-materials/ietf93/ietf-93-httpbis-search.pdf <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fwg-materials%2Fietf93%2Fietf-93-httpbis-search.pdf&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ahU2tOHPGFEjoaXkz16HWA6W50waT9m5kcYXXIIpRzA%3D&reserved=0>
>  
> Phillip Hunt
> @independentid
> phil.hunt@independentid.com <mailto:phil.hunt@independentid.com>
>  
>  
> 
> 
> 
> On Jul 7, 2022, at 12:57 AM, Julien Schneider <julien@audriga.com <mailto:julien@audriga.com>> wrote:
>  
> Hi Danny, hi Phillip, hi everyone,
> 
> Thanks for your answers. I think the confusing part (for me at least) is "Queries MAY be made against a single resource or a resource type endpoint ......." at the beginning of RFC7644 section 3.4.2., followed by "Responses MUST be identified using the following URI: "urn:ietf:params:scim:api:messages:2.0:ListResponse" ".
> 
> My interpretation is that "GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName" is a query against a single resource, and should then have a "ListResponse" response? Where am I wrong here?
> 
> Thanks
> 
> 
> Julien Schneider
> Tel: +49 721 170293 16
> Fax: +49 721 170293 179
>  
> http://www.audriga.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.audriga.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ugCOwiY5EXLH8EfrAacwK9%2FDCGnhMp3Sh7L%2Fo8WQNOA%3D&reserved=0> | http://www.twitter.com/audriga <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Faudriga&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=e6nmZrdOJiUBA%2F31N1TwKLeeQTuwCVla%2FE4UuOds7AU%3D&reserved=0>
>  
> --------------------------------------------------------------------------
> audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
> --------------------------------------------------------------------------
> On 07/07/2022 04:51, Danny Zollner wrote:
> Hi Julien,
>  
> RFC 7644 section 3.4.2 specifically is talking about queries. Retrieving or modifying known resources (i.e.: GET /Users/12345 ) does not require a ListResponse type response. A query of GET /Users?filter=displayname contains “contoso.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcontoso.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2B7DoMHkSX3An6CfG913vNi5zgP%2BAJY28kXSnR%2FgBr80%3D&reserved=0>” or GET /Users?attributes=userName would require a ListResponse type response, as it does not identify a specific resource in the query URL via ID value (i.e.: “12345” in the previous example). On the other hand, GET /Users/12345?attributes=userName does not require the ListResponse type response as it does identify a specific resource.
>  
> To explicitly answer the final question in your email – the expected response to GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userNamewould be the second example you provided.
>  
> Cheers,
>  
> Danny Zollner
>  
> From: scim <scim-bounces@ietf.org> <mailto:scim-bounces@ietf.org> On Behalf Of Julien Schneider
> Sent: Wednesday, July 6, 2022 3:41 AM
> To: scim@ietf.org <mailto:scim@ietf.org>
> Subject: [EXTERNAL] [scim] Query on a specific known resource
>  
> Some people who received this message don't often get email from julien@audriga.com <mailto:julien@audriga.com>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>	
> Hi all,
> 
> I have a question about queries performed against a SCIM resource object (like "/Users/{id}").
> 
> The RFC (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.2&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=jbbn1Y43e0GFmChjRVbpMnTKZEqlB5TzLgiJmhz7ZRY%3D&reserved=0>) states: 
> Responses MUST be identified using the following URI:
>    "urn:ietf:params:scim:api:messages:2.0:ListResponse"
> 
> If I understand correctly, that means the "schemas" parameter of the response to those queries must be set to:
> "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"]
> 
> While I understand how that applies to queries on a resource type endpoint (like "/Users") or on the SCIM server root, I don't understand how that applies to queries on a specific resource object.
> If I understand correctly, queries on a specific resource object actually are quite identical to "retrieving a known resource" (https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.1 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7644%23section-3.4.1&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=wbOMKvqD9T7hP5OFtruAwY2r26XrKdncriLPSapazGQ%3D&reserved=0>) which are a GET on a specific resource, like:
> GET /Users/2819c223-7f76-453a-919d-413861904646
> Responses to those requests should have the "schemas" parameter set to the resource schema(s):
> {
>      "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
>      "id":"2819c223-7f76-453a-919d-413861904646",
> ...
> }
> 
> Now, how should the response to the following query should look like? And to what value should the "schemas" parameter of the response be set?
> GET /Users/2819c223-7f76-453a-919d-413861904646?attributes=userName
> 
> Should it be:
>    {
>      "schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
>      "totalResults":1,
>      "Resources":[
>        {
>          "id":"2819c223-7f76-453a-919d-413861904646",
>          "userName":"bjensen"
>        }
>      ]
>    }
> 
> Or something like:
>    {
>      "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
>      "id":"2819c223-7f76-453a-919d-413861904646",
>      "meta":{
>        "resourceType":"User",
>        "created":"2011-08-01T18:29:49.793Z",
>        "lastModified":"2011-08-01T18:29:49.793Z",
>        "location":
>    "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646" <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fv2%2FUsers%2F2819c223-7f76-453a-919d-413861904646&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=1BDZsY%2B1DkxD3t2ZObBwf5UHRZlnoXdE9UFuuBZioS0%3D&reserved=0>,
>        "version":"W\/\"f250dd84f0671c3\""
>      },
>      "userName":"bjensen"
>    }
> 
> Thanks a lot in advance
> 
> 
> -- 
> Julien Schneider
> Tel: +49 721 170293 16
> Fax: +49 721 170293 179
>  
> http://www.audriga.com <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.audriga.com%2F&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ugCOwiY5EXLH8EfrAacwK9%2FDCGnhMp3Sh7L%2Fo8WQNOA%3D&reserved=0> | http://www.twitter.com/audriga <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitter.com%2Faudriga&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=e6nmZrdOJiUBA%2F31N1TwKLeeQTuwCVla%2FE4UuOds7AU%3D&reserved=0>
>  
> --------------------------------------------------------------------------
> audriga GmbH |  Alter Schlachthof 57  | 76137 Karlsruhe
> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
> --------------------------------------------------------------------------
> 
> _______________________________________________
> scim mailing list
> scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.org/mailman/listinfo/scim <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7CDanny.Zollner%40microsoft.com%7C61a3ef6cefda487b73ef08da603f27f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637928122539415111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lgmWfvOoa2uTk4zhZ2eC6txKydhzire0Hd85sQ4Ib5Y%3D&reserved=0>