From nobody Mon Mar 2 06:47:41 2020 Return-Path: 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 92CC13A0805 for ; Mon, 2 Mar 2020 06:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 y1eUyoO8RkZw for ; Mon, 2 Mar 2020 06:47:37 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7542A3A07D4 for ; Mon, 2 Mar 2020 06:47:37 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id a76so1415584vki.13 for ; Mon, 02 Mar 2020 06:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lXKaN770uZsJIilpl4+zO2JC8hqydXXO5Dd1YN/6jWk=; b=RIpUIhmEtHhmoZqph5dWGrinjhwN0NDLqp8KrffjMjYBcbUTC/AoKNy4ujX15keliC HeYPARfR+p1rRYUIx3Kw6WWKyVQr3qgwxoaVc62AD6o2ZePXFYsxGpLmBDwrNKe6URL3 5AfywoE+tgnPZuddwhgieoyAipPZBx2bQUC23z0pX7lKWduDcna4LTLyP+4oh1mu9pgz o/ZPs1ke/Yr556WJ55ls622wufc7ugrJhFoDGuOmtsMg/s76muYqlVqbgNiwMZWOOMxX J595iVeH595HPq/0tks0kuE4iJNTP7OAGk2Wko4KQWGFsbFQ0MJOWhqOEz72wHZmfAo6 +gdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lXKaN770uZsJIilpl4+zO2JC8hqydXXO5Dd1YN/6jWk=; b=L5JFYJRUgCuONP8fqMpWqI2nDeKOwwBIO0czauwDzz8l7HhjOv0VjQgqQyeLPV6p3r ZHrk6CdKMOGEokC2rnSmGzDp46du4mKdqAswVJrWcLelJ3GpckBnS6RTDs0/vH4xI4ZM Aufd/W5tOxMq/Si7pADQ5zaa0IEb86ev3wAv6GTxHdnnpuihje1XHyiteghVcinuGWkl wg28XmNbMqLbPyBnvEPiucaG+l0UG94XvDxFyjzPv/75EvKOQmC40EZxnc1+h5En9uHe cAJKCooIOr8EypXUoFcJTRjmbRxkVLaOyU759q/s5A6wGGtlGlrbc4topPHAu1HBeQLg K6CA== X-Gm-Message-State: ANhLgQ2UmhaOKPEwcmCY5baqGvLl5R06TYkPk6q2/fYu22nul/ejKTzE iy8lRvcAOQSRvbSTHVjTjp1wFfldopRYXIOMLgiJ6W8o X-Google-Smtp-Source: ADFU+vvODm7/nSHM7HfALeQBowhNkPDtPcFnBdl1OIohVG3b7aZnwXHb0HR/JK1P8Rl3l2vxjCs/www8w7L8IWXllPE= X-Received: by 2002:ac5:cce3:: with SMTP id k3mr17136vkn.95.1583160456486; Mon, 02 Mar 2020 06:47:36 -0800 (PST) MIME-Version: 1.0 References: <12070853-9D12-4C07-A11D-29B67905BA0A@independentid.com> In-Reply-To: <12070853-9D12-4C07-A11D-29B67905BA0A@independentid.com> From: Shelley Date: Mon, 2 Mar 2020 08:47:25 -0600 Message-ID: To: Phillip Hunt Cc: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000a1a4c0059fe044fe" Archived-At: Subject: Re: [scim] Root Query & Search Requirements X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 14:47:40 -0000 --000000000000a1a4c0059fe044fe Content-Type: text/plain; charset="UTF-8" Thanks. If I'm understanding correctly, the server root supports two types of requests: - Searching via POST /.search [1] - Querying via GET / [2] Questions: - The root server endpoint is not defined as a well-known endpoint in Section 3.2 [3]. Given that general purpose querying (not just searching) seems to be supported on this endpoint, should it be defined in this section? - Are SCIM service providers REQUIRED to support querying and/or searching on the root server endpoint? Ticket #42 [4] provided text and an SP configuration attribute that more clearly indicated that support for this was OPTIONAL, but this was omitted from the final spec. Does this mean SPs MUST support querying/searching at the server root? [1] https://tools.ietf.org/html/rfc7644#section-3.4.3 [2] https://tools.ietf.org/html/rfc7644#section-3.4.2 [3] https://tools.ietf.org/html/rfc7644#section-3.2 [4] https://trac.ietf.org/trac/scim/ticket/42 On Sat, Feb 29, 2020 at 11:05 AM Phillip Hunt wrote: > Shelley, > > Section 3.4.2.1 of RFC7644 states that the server root is a valid search > endpoint. > > The root is not and endpoint for the purpose of holding resources. It only > holds the resource type containers (which each define their own endpoint) > and which in turn contain resources > > The use case for querying from the root came from implementers who were > using SCIM in a directory lookup style of functionality and performing > search while typing type of functionality. In these cases the scim client > does not know what type of resource the user wants and wants to be able to > return all resource types, or a specific set of types (like Users and > Groups). > > Phil Hunt > @independentid > phil.hunt@independentid.com > > > > On Feb 26, 2020, at 11:47 AM, Shelley wrote: > > The server root is not defined as a supported endpoint [1] for querying > (GET), yet the inline text for the Query Resources section [2] implies that > it is a required endpoint responsible for returning all resource types: > > *> Queries MAY be performed against a SCIM resource object, a resource >> type endpoint, or a SCIM server root.* >> > > *> A query against a server root indicates that all resources within the >> server SHALL be included, subject to filtering....* >> > > *> When processing query operations using endpoints that include more than >> one SCIM resource type (e.g., a query from the server root endpoint)...* >> > > Similarly, searching (POST) [3] seems to assume that the search is > attached to a valid SCIM endpoint, although the root is not clearly defined > as such: > > * > The inclusion of "/.search" on the end of a valid SCIM endpoint...* >> > > I found some old tickets/discussions [4,5,6] that proposed making these > requirements more clear in the RFC text and service provider configuration, > but that clarity doesn't appear to have made its way into the final RFCs. > > Can someone provide some clarity on whether the server root must be a > supported SCIM endpoint responsible for returning all resources (subject to > standard filtering) and/or if it must support the .search capability? > > Our SCIM implementation does not currently have any use cases that would > benefit from querying/searching across resource types, any I would prefer > to add any custom support there unless it becomes necessary (i.e. just > return a basic 404 response for any requests to the server root as an > unknown/unsupported resource). > > [1] https://tools.ietf.org/html/rfc7644#section-3.2 > [2] https://tools.ietf.org/html/rfc7644#section-3.4.2 > [3] https://tools.ietf.org/html/rfc7644#section-3.4.3 > [4] https://trac.ietf.org/trac/scim/ticket/42 > [5] > https://mailarchive.ietf.org/arch/msg/scim/WOT40hJ9t5RB1vEnwGoePWW18dI/ > [6] > https://mailarchive.ietf.org/arch/msg/scim/MXu6yJ3TxYTm566hW99TGTpvoZg/ > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --000000000000a1a4c0059fe044fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks.

If I'm understanding correctly, t= he server root supports two types of requests:
  • Sear= ching via POST /.search [1]
  • Querying via GET / [2]
Questions:
  • The root server endpoint is not defined as a = well-known endpoint in Section 3.2 [3]. Given that general purpose querying= (not just searching) seems to be supported on this endpoint, should it be = defined in this section?
  • Are SCIM service providers REQUIRED to sup= port querying and/or searching on the root server endpoint? Ticket #42 [4] = provided text and an SP configuration attribute that more clearly indicated= that support for this was OPTIONAL, but this was omitted from the final sp= ec. Does this mean SPs MUST support querying/searching at the server root?<= br>
[1] https://tools.ietf.org/html/rfc7644#section-3.4.3
[2] https://tools.ietf.org/= html/rfc7644#section-3.4.2
[3] https://tools.ietf.org/html/rfc7644#section-3.2<= br>[4] https://trac.i= etf.org/trac/scim/ticket/42

On Sat, Feb 29, 2020 at 11:05 AM Phillip Hun= t <phil.hunt@independenti= d.com> wrote:
Shelley,

= Section 3.4.2.1 of RFC7644 states that the server root is a valid search en= dpoint.=C2=A0

The root is not and endpoint for the= purpose of holding resources. It only holds the resource type containers (= which each define their own endpoint) and which in turn contain resources= =C2=A0

The use case for querying from the root cam= e from implementers who were using SCIM in a directory lookup style of func= tionality and performing search while typing type of functionality. In thes= e cases the scim client does not know what type of resource the user wants = and wants to be able to return all resource types, or a specific set of typ= es (like Users and Groups).

Phil Hunt
@independentid
<= a href=3D"mailto:phil.hunt@independentid.com" target=3D"_blank">phil.hunt@i= ndependentid.com

<= br>

On Feb 26, 2020, at 11:47 AM, Shell= ey <randoms= helley@gmail.com> wrote:

<= div>The server root is not defined as a supported endpoint [1] for querying= (GET), yet the inline text for the Query Resources section [2] implies tha= t it is a required endpoint responsible for returning all resource types:

> Queries MAY be performed against a SCIM resource object, = a resource type endpoint, or a SCIM server root.
=

&g= t; A query against a server root indicates that all resources within the se= rver SHALL be included, subject to filtering....

> When process= ing query operations using endpoints that include more than one SCIM resour= ce type (e.g., a query from the server root endpoint)...

Similarly, searching (POST) [3] seems to a= ssume that the search is attached to a valid SCIM endpoint, although the ro= ot is not clearly defined as such:

> The inclusion of "/.search" on the end of a valid SCIM en= dpoint...

I found some old tickets/discussions= [4,5,6] that proposed making these requirements more clear in the RFC text= and service provider configuration, but that clarity doesn't appear to= have made its way into the final RFCs.

Can someon= e provide some clarity on whether the server root must be a supported SCIM = endpoint responsible for returning all resources (subject to standard filte= ring) and/or if it must support the .search capability?

Our SCIM implementation does not currently have any use cases that wo= uld benefit from querying/searching across resource types, any I would pref= er to add any custom support there unless it becomes necessary (i.e. just r= eturn a basic 404 response for any requests to the server root as an unknow= n/unsupported resource).

_______________________________________________
scim mailing list
scim@ietf.org
https://= www.ietf.org/mailman/listinfo/scim

--000000000000a1a4c0059fe044fe-- From nobody Mon Mar 2 11:39:33 2020 Return-Path: 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 0FEB43A0477 for ; Mon, 2 Mar 2020 06:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZqjVvPnTe42Y for ; Mon, 2 Mar 2020 06:20:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD213A046D for ; Mon, 2 Mar 2020 06:20:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9CEE5F406C3; Mon, 2 Mar 2020 06:19:46 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200302141946.9CEE5F406C3@rfc-editor.org> Date: Mon, 2 Mar 2020 06:19:46 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2020 11:39:30 -0800 Subject: [scim] [Technical Errata Reported] RFC7643 (5999) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 14:20:07 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5999 -------------------------------------- Type: Technical Reported by: Shelley Baker Section: 8.7.1 Original Text ------------- "id" : "urn:ietf:params:scim:schemas:core:2.0:User", "name" : "User", "description" : "User Account", "id" : "urn:ietf:params:scim:schemas:core:2.0:Group", "name" : "Group", "description" : "Group", "id" : "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", "name" : "EnterpriseUser", "description" : "Enterprise User" Corrected Text -------------- "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"], "id" : "urn:ietf:params:scim:schemas:core:2.0:User", "name" : "User", "description" : "User Account", "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"], "id" : "urn:ietf:params:scim:schemas:core:2.0:Group", "name" : "Group", "description" : "Group", "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Schema"], "id" : "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User", "name" : "EnterpriseUser", "description" : "Enterprise User" Notes ----- The "schemas" attribute is missing from the example JSON representation schema resources. According to Sections 2.1 and Section 3, the "schemas" attribute is a REQUIRED and MUST be provided. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Mar 2 11:39:37 2020 Return-Path: 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 CBB6B3A0CCB for ; Mon, 2 Mar 2020 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 v80RAmA5TX_Y for ; Mon, 2 Mar 2020 09:14:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD333A0CD2 for ; Mon, 2 Mar 2020 09:14:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0EEB5F406F6; Mon, 2 Mar 2020 09:13:57 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200302171357.0EEB5F406F6@rfc-editor.org> Date: Mon, 2 Mar 2020 09:13:57 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2020 11:39:31 -0800 Subject: [scim] [Technical Errata Reported] RFC7643 (6000) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 17:14:24 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6000 -------------------------------------- Type: Technical Reported by: Shelley Baker Section: 8.7.1 Original Text ------------- { "name" : "x509Certificates", "type" : "complex", "multiValued" : true, "description" : "A list of certificates issued to the User.", "required" : false, "caseExact" : false, "subAttributes" : [ { "name" : "value", "type" : "binary", "multiValued" : false, "description" : "The value of an X.509 certificate.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Corrected Text -------------- { "name" : "x509Certificates", "type" : "complex", "multiValued" : true, "description" : "A list of certificates issued to the User.", "required" : false, "caseExact" : false, "subAttributes" : [ { "name" : "value", "type" : "binary", "multiValued" : false, "description" : "The value of an X.509 certificate.", "required" : false, "caseExact" : true, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Notes ----- Section 2.3.6 indicates that "binary is case exact." The "x509Certificates" binary "value" subattribute's "caseExact" characteristic is currently listed as "false", but should be "true". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Mar 2 11:39:40 2020 Return-Path: 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 F3E8D3A0BBA for ; Mon, 2 Mar 2020 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 5PsL_BeNDkIV for ; Mon, 2 Mar 2020 09:19:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650143A09BB for ; Mon, 2 Mar 2020 09:19:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 01B97F406D7; Mon, 2 Mar 2020 09:19:03 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200302171904.01B97F406D7@rfc-editor.org> Date: Mon, 2 Mar 2020 09:19:03 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2020 11:39:31 -0800 Subject: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 17:19:25 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6001 -------------------------------------- Type: Technical Reported by: Shelley Baker Section: 8.7.1 Original Text ------------- { "name" : "profileUrl", "type" : "reference", "referenceTypes" : ["external"], "multiValued" : false, "description" : "A fully qualified URL pointing to a page representing the User's online profile.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "photos", "type" : "complex", "multiValued" : true, "description" : "URLs of photos of the User.", "required" : false, "subAttributes" : [ { "name" : "value", "type" : "reference", "referenceTypes" : ["external"], "multiValued" : false, "description" : "URL of a photo of the User.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "$ref", "type" : "reference", "referenceTypes" : [ "User", "Group" ], "multiValued" : false, "description" : "The URI of the corresponding 'Group' resource to which the user belongs.", "required" : false, "caseExact" : false, "mutability" : "readOnly", "returned" : "default", "uniqueness" : "none" }, Corrected Text -------------- { "name" : "profileUrl", "type" : "reference", "referenceTypes" : ["external"], "multiValued" : false, "description" : "A fully qualified URL pointing to a page representing the User's online profile.", "required" : false, "caseExact" : true, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "photos", "type" : "complex", "multiValued" : true, "description" : "URLs of photos of the User.", "required" : false, "subAttributes" : [ { "name" : "value", "type" : "reference", "referenceTypes" : ["external"], "multiValued" : false, "description" : "URL of a photo of the User.", "required" : false, "caseExact" : true, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "$ref", "type" : "reference", "referenceTypes" : [ "User", "Group" ], "multiValued" : false, "description" : "The URI of the corresponding 'Group' resource to which the user belongs.", "required" : false, "caseExact" : true, "mutability" : "readOnly", "returned" : "default", "uniqueness" : "none" }, Notes ----- Section 2.3.7 indicates that "A reference is case exact." Section 8.7.1 defines a number of "reference" attributes that incorrectly have the "caseExact" characteristic set to "false"; these should instead be "true." Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Mar 3 11:02:32 2020 Return-Path: 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 193953A2447 for ; Tue, 3 Mar 2020 09:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Wnx_dRyhI2hB for ; Tue, 3 Mar 2020 09:17:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75313A2413 for ; Tue, 3 Mar 2020 09:17:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 030FCF4071A; Tue, 3 Mar 2020 09:17:14 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200303171714.030FCF4071A@rfc-editor.org> Date: Tue, 3 Mar 2020 09:17:14 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2020 11:02:31 -0800 Subject: [scim] [Technical Errata Reported] RFC7643 (6004) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 17:17:43 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6004 -------------------------------------- Type: Technical Reported by: Shelley Baker Section: 8.7.1 Original Text ------------- { "name" : "name", "type" : "complex", ... "uniqueness" : "none" }, ... { "name" : "emails", "type" : "complex", ... "uniqueness" : "none" }, ... { "name" : "addresses", "type" : "complex", ... "uniqueness" : "none" }, Corrected Text -------------- { "name" : "name", "type" : "complex", ... }, ... { "name" : "emails", "type" : "complex", ... }, ... { "name" : "addresses", "type" : "complex", ... }, Notes ----- The "emails", "name", and "addresses" complex user attributes have a "uniqueness" characteristic defined. According to Section 2.3.8, complex attributes have no uniqueness. No other complex attributes in Section 8.7.1 specify a "uniqueness" characteristic. For compliance with Section 2.3.8 and consistency with other attribute definitions, the "uniqueness" sub-attribute for these complex attributes should be removed. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Mar 3 11:02:37 2020 Return-Path: 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 E581E3A2466 for ; Tue, 3 Mar 2020 09:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vfyONe5VsJLE for ; Tue, 3 Mar 2020 09:41:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C683A2461 for ; Tue, 3 Mar 2020 09:41:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 87662F40713; Tue, 3 Mar 2020 09:40:49 -0800 (PST) To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, moransar@cisco.com, leifj@sunet.se X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: randomshelley@gmail.com, scim@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200303174049.87662F40713@rfc-editor.org> Date: Tue, 3 Mar 2020 09:40:49 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2020 11:02:31 -0800 Subject: [scim] [Editorial Errata Reported] RFC7643 (6005) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 17:41:14 -0000 The following errata report has been submitted for RFC7643, "System for Cross-domain Identity Management: Core Schema". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6005 -------------------------------------- Type: Editorial Reported by: Shelley Baker Section: 8.7.1 Original Text ------------- { "name" : "addresses", "type" : "complex", "multiValued" : true, "description" : "A physical mailing address for this User. Canonical type values of 'work', 'home', and 'other'. This attribute is a complex type with the following sub-attributes.", "required" : false, "subAttributes" : [ { "name" : "formatted", "type" : "string", "multiValued" : false, "description" : "The full mailing address, formatted for display or use with a mailing label. This attribute MAY contain newlines.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "streetAddress", "type" : "string", "multiValued" : false, "description" : "The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "locality", "type" : "string", "multiValued" : false, "description" : "The city or locality component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "region", "type" : "string", "multiValued" : false, "description" : "The state or region component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "postalCode", "type" : "string", "multiValued" : false, "description" : "The zip code or postal code component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "country", "type" : "string", "multiValued" : false, "description" : "The country name component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "type", "type" : "string", "multiValued" : false, "description" : "A label indicating the attribute's function, e.g., 'work' or 'home'.", "required" : false, "caseExact" : false, "canonicalValues" : [ "work", "home", "other" ], "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" } ], "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Corrected Text -------------- { "name" : "addresses", "type" : "complex", "multiValued" : true, "description" : "A physical mailing address for this User. Canonical type values of 'work', 'home', and 'other'. This attribute is a complex type with the following sub-attributes.", "required" : false, "subAttributes" : [ { "name" : "formatted", "type" : "string", "multiValued" : false, "description" : "The full mailing address, formatted for display or use with a mailing label. This attribute MAY contain newlines.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "streetAddress", "type" : "string", "multiValued" : false, "description" : "The full street address component, which may include house number, street name, P.O. box, and multi-line extended street address information. This attribute MAY contain newlines.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "locality", "type" : "string", "multiValued" : false, "description" : "The city or locality component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "region", "type" : "string", "multiValued" : false, "description" : "The state or region component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "postalCode", "type" : "string", "multiValued" : false, "description" : "The zip code or postal code component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "country", "type" : "string", "multiValued" : false, "description" : "The country name component.", "required" : false, "caseExact" : false, "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "type", "type" : "string", "multiValued" : false, "description" : "A label indicating the attribute's function, e.g., 'work' or 'home'.", "required" : false, "caseExact" : false, "canonicalValues" : [ "work", "home", "other" ], "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, { "name" : "primary", "type" : "boolean", "multiValued" : false, "description" : "A Boolean value indicating the 'primary' or preferred attribute value for this attribute, e.g., the preferred mailing address. The primary attribute value 'true' MUST appear no more than once.", "required" : false, "mutability" : "readWrite", "returned" : "default" } ], "mutability" : "readWrite", "returned" : "default", "uniqueness" : "none" }, Notes ----- The "addresses" user attribute should specify a "primary" sub-attribute. "addresses" is a multi-valued attribute. According to Section 2.4, multi-valued attributes include a "primary" sub-attribute. The "primary" sub-attribute text even mentions this attribute's use for mailing "addresses." Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7643 (draft-ietf-scim-core-schema-22) -------------------------------------- Title : System for Cross-domain Identity Management: Core Schema Publication Date : September 2015 Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore Category : PROPOSED STANDARD Source : System for Cross-domain Identity Management Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Mar 4 08:19:48 2020 Return-Path: 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 5BDD33A124B for ; Wed, 4 Mar 2020 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hAyyT6NgzyBa for ; Wed, 4 Mar 2020 08:19:40 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B303A122E for ; Wed, 4 Mar 2020 08:19:40 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id z26so892900uap.6 for ; Wed, 04 Mar 2020 08:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=k2nr99D3+tKyXmVcakDWulRGJo+LnqUvEE+ZIJ0NS2c=; b=pUktq+SLwDgR7abtbeozNBfPjwvkOWohjHBTLopbRZRNJk5/3p/Nx2Uaj1SmX+o4RH AtwXMMkZBhRe7xKVGG8DEP7DhaU3xnytApQQMmCaCv7uy3g8NMxr1qivzj6bkEHeASdd CIqDpdzeL+S/ksI3+RrejyS+GzflETUYk5xogsKpK0sXkNzDde7Fp4ppfgzLVMT7la2m mGt1k8O3hPrBPd0D8Y8V6rnRX/QPS0We//s8NY8t7eDac45nmi3laiN2CpmeJRja/8f3 dJNtZBMgS/Qn/plyPipzUSaqDuoiB/z72vbF0scr/kpZ66I1A6FdYUcCS9dTOZA4CXxR O+5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k2nr99D3+tKyXmVcakDWulRGJo+LnqUvEE+ZIJ0NS2c=; b=tYENs+715hP/P1o04RcZwEM82FxLmtgTrnb2WLEiuRAvC+VHOvI+x+/EL2JPemIAPE sCOSOXdnRXtgTcsG/C57ar7H2IagHBqTm3BfMAQtd9/n7RZ+H+caieGTMHN/CsYd9Tpv o7MBSNIrvw5wskLjd7mPTu8yCjZC9gFAn/DmjfRo51stgcxAJU8EyqCjChU/sb6XIeri em2RIWt7yuz2IQE218mPbqY5m3MB5W+ELYld+RousdIkiSNXzBG7ocLF6FfdUwhvrx+K QayZoS4yhTez7UDEHugF0Zctow6fzG8+IdgET8Twusg4xEiUongKgqUtbvqQZGxs3Zbf +STA== X-Gm-Message-State: ANhLgQ21uq1CfDh9hw4Yw0c+GydOcY1pYYzOPjBQ8odkTlBIc+GXGNGO gBQ8iSwZxkJir7D8Pqc4A9zxisSHGSpmvDR0c99rxOJm X-Google-Smtp-Source: ADFU+vsQgzgT8ng0UKmFYxTc7V9vvC7vuzMli577Xgkxs4onMFCiZqppZCDwwffeYQG8kflqca//oslI4vXZpJ4si9g= X-Received: by 2002:ab0:6029:: with SMTP id n9mr1940946ual.35.1583338779432; Wed, 04 Mar 2020 08:19:39 -0800 (PST) MIME-Version: 1.0 From: Shelley Date: Wed, 4 Mar 2020 10:19:28 -0600 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="00000000000081d9b105a009c941" Archived-At: Subject: [scim] Multi-Valued Display Attribute's Mutability Characteristic X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 16:19:46 -0000 --00000000000081d9b105a009c941 Content-Type: text/plain; charset="UTF-8" Multi-valued attributes' "display" sub-attribute is documented in Section 2.4 to be "immutable" by default: display [1] A human-readable name, primarily used for display purposes and having a mutability of "*immutable*". However, nearly all of "display" subattributes in Section 8.7.1 (user emails, phoneNumbers, ims, photos, entitlements, roles, x509Certificates) specify a mutability of "readWrite", despite the fact that the description indicates that they are "READ-ONLY" [2]: { "name" : "display", "type" : "string", "multiValued" : false, "description" : "A human-readable name, primarily used for display purposes. *READ-ONLY*.", "required" : false, "caseExact" : false, "mutability" : "*readWrite*", "returned" : "default", "uniqueness" : "none" }, Which of these is the expected mutability characteristic of the "display" attribute in these cases? - the attribute's definition of "immutable" [1] - the "description" of "readOnly" [2] - the "mutability" of "readWrite" [2] My understanding is that the "display" attribute is primarily intended for use by Service Providers to optionally return a suitable human-readable display name for the attribute, which has potentially been canonicalized (whereas the "value" may remain the raw value provided by the client). Given this, "readOnly" seems to be the most appropriate "mutability" characteristic (assuming my understanding of "readOnly" is correct, such that it means that the client cannot provide this value, but the service provider may update and return a value). Alternatively, if either clients or service providers are allowed to provide "display" values, "readWrite" seems appropriate. In none of the cases for "display" does "immutable" seem like the correct choice, though. [1] https://tools.ietf.org/html/rfc7643#section-2.4 [2] https://tools.ietf.org/html/rfc7643#section-8.7.1 --00000000000081d9b105a009c941 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Multi-valued attributes' "display" sub-attri= bute is documented in Section 2.4 to be "immutable" by default:
=C2=A0 =C2=A0display [1]
=C2= =A0 =C2=A0 =C2=A0 A human-readable name, primarily used for display purpose= s and
=C2=A0 =C2=A0 =C2=A0 having a mutability of "immutable= ".

However, nearly all of "display" subattribu= tes in Section 8.7.1 (user emails, phoneNumbers, ims, photos, entitlements,= roles, x509Certificates) specify a mutability of "readWrite", de= spite the fact that the description indicates that they are "READ-ONLY= " [2]:

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name= " : "display",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "type" : "string",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "multiValued" : false,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "description" : "A human-readable name, primar= ily used
for display purposes. =C2=A0READ-ONLY.",
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "required" : false,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "caseExact" : false,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "mutability" : "readW= rite",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "returned= " : "default",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "uniqueness" : "none"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 },

Which of these is the expected mutability character= istic=20 of the "display" attribute in these cases?
  • the attribute's definition of "immutabl= e" [1]
  • the "description" of "readOnly" [2]=
  • the "mutability" of "readWrite" [2]
<= br>My understanding is that the "display" attribute is primarily = intended for use by Service Providers to optionally return a suitable human= -readable display name for the attribute, which has potentially been canoni= calized (whereas the "value" may remain the raw value provided by= the client). Given this, "readOnly" seems to be the most appropr= iate "mutability" characteristic (assuming my understanding of &q= uot;readOnly" is correct, such that it means that the client cannot pr= ovide this value, but the service provider may update and return a value). = Alternatively, if either clients or service providers are allowed to provid= e "display" values, "readWrite" seems appropriate. In n= one of the cases for "display" does "immutable" seem li= ke the correct choice, though.

[1] https://tools.ietf.org/html/rfc7643#section-2.4<= /a>
[2] ht= tps://tools.ietf.org/html/rfc7643#section-8.7.1
--00000000000081d9b105a009c941-- From nobody Mon Mar 9 10:04:09 2020 Return-Path: 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 4D1793A1355 for ; Mon, 9 Mar 2020 10:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 I5QWifayicbV for ; Mon, 9 Mar 2020 10:04:01 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447933A13AE for ; Mon, 9 Mar 2020 10:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583773440; bh=olwwoP4QZQ6OoK0jaY6plM0OPH3BzvblPlxUx8nCPIQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=re9R3SEgy7qS/SZq/XmDc1dU3+OHhk9nJVmyu0FEI1QjOI98ycESJqoYPK4jmvvAon7u7ncsCf50h2pjLhnA++1A819AKSnfmTCix8NVrZT37snnfXjwsHUIssFbC+0FN/dRHt0Zsj3a2zV5a5TchtEY7PVjscmC40nzupoGPetsjpqj+4Yzflq9haOpvQW8+qFuHvBamFT9FOzs675lFbl9CCT+PvMRiKC9x2w00/fxiR2uloB/JtkpfZpSeWSkwQCXma78WpTqFk9ePwtF7GwJ7+ZZ0uYz0QxkJRkAH9l10qscs1DJibYx0VFNAXTbT2EfZu1QLlb5tCmfzxolAw== X-YMail-OSG: _j14jqgVM1mKLSGceT.05_ii4suR2lNoWy5b27xGnPdX.M6h1.tuV.C7Dud5HoH 2Lu8OO_4dd6sc5Z9c9MjobUcpmcVDUx5MwLBXAsfHdUG.Vn6zzcBO06rUajyPPeAgxrmBOgLokMQ 0Duq7Ra7mRIU8sxXwjskdHGBTDkskvewjmFQguozslnUBVJJTjJVB_AhS4FoMKWfwy0YmivEKDb7 cVRy9eOdnRSQTjiUu6uB1w720Hvz48QOA5yOy.0Vhp_tswz6UTRKfv8hKIHw.6433JK4heM9tahJ Hgevoa2rV5Ssp9z6JHzAbNaLMxDqSncZd8tyz7mzmQ5lEFmXUiuj.njD8jd0jpOiqpQdUggQrnud YCq1x68MHS7i2NU0R8MtCaL6giB2BvdidIggup3lCTAUGzaXX7vaw9AFQDgdET6o.Et1fZrQrf60 SChg1pU_G0TD43R4mTgvTVqCp3AFFq3kpiOkk6jHz2lv6sKYHvy1WPNmKPZ0vPs6z3ZQ03ozgxPu qy0uikBPPY8izCF5H0ImhO5Eo0a2spEWuNKmRxorcY88iYe0T_x8Mticzg1Fd1mBV4bsqEdzTORn pUUfVKF4u091WzurF1lXfz1pyeeTYY5cLWKidjvPqsHfrwiB1FXio.EvXuwXNPMMK9.tBuvGs8Ut zHTf8qjkJNq62T6XngACfX7MWUQTudueQgmb28DT3hqrmT3c49mXIhBR3G_L9juV7Of5kNb9Q_YD k26xIc185V_u0lehPj63FhSiqvpKdrBL0I0vHLilK9nI9VHOEqpBJT4_KoNSBJHbTAUgB2CT7R2S 0kCTbylW0lSmVtF4aMcPhMC.yz5UZYcseM45lrDDFE.nweJdAEIYJ9sCpLxmxl1pOXiNU7wAa5Ak cxXOOlk5qEkNMma1rMafnBUWLB1KP1tCnXGe7TC_UUa1Fa1IfFSNrfAZ8WUWBingvAjHHfsByoGP 1B3WyRQIuEw1G3Wjr2g8AWAjEcGrH8gycucBSis.L8xAbeC3LA7MGxsyF434tU.7.hbjV27KunoJ hbvjL.3ECNnCQ0MUrhbNTaa96WwkGVd359mt0HvrJt8DX1RKLb32Zz1tflz9Q4YjQ9F2EHkezNVf RDrecMCH_78zCTB6xDJ8FHiXXLNO1wFBWB3azSNXr1lqiLhgZYBJMnSY6bTCs79dbejcJpWP5Opr REldhOozZeiAlGwbHDqG0u9ll_G8U5WBqUf3ygPmBS9TB_X3WlRSPWbs6sjtb3ZQ0Fd7j0Kj2BMq XXJDC8NEi2Z_vNkpWxkdzwdGcRXiSBUlgeOQM6Bnqnk_ms8FhfOji16QYVBR2STG9NLdl.csPLEU O4RYn6M4KB711Ah_aKWFl1qndLH9Cl1xamIXqkGV6wODdLD8aYuJygN8QNWSwSrSI7XjrXHZQfYs .mmrcrCVFe1iq_Ycgww-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Mon, 9 Mar 2020 17:04:00 +0000 Received: by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f6a17423d2aebe9802ac21341884bee2; Mon, 09 Mar 2020 17:03:59 +0000 (UTC) From: Phil Hunt Message-Id: <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 9 Mar 2020 10:01:32 -0700 In-Reply-To: <20200309144726.4AE80F40720@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, Shelley , scim@ietf.org To: RFC Errata System References: <20200309144726.4AE80F40720@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6011) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:04:07 -0000 --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 VERIFIED However, the correction needs a correction. The display attribute is = =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D. { "name": "display", "type": "string", "multiValued": false, "description": "A human-readable name for the group member, = primarily used for display purposes.", "required": false, "caseExact": false, "mutability": "readOnly=E2=80=9D, =E2=80=94>. should be:=20 "mutability": =E2=80=9Cimmutable=E2=80=9D, "returned": "default", "uniqueness": "none" } Phil Hunt phil.hunt@yahoo.com > On Mar 9, 2020, at 7:47 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6011 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } >=20 > Corrected Text > -------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, = primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly", > "returned": "default", > "uniqueness": "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } >=20 > Notes > ----- > The group "members" attribute should define a "display" sub-attribute. >=20 > * Section 2.4 defines a standard multi-valued read-only attribute of = "display". > * The Group Representation example in Section 8.4 also includes the = "members.display" sub-attribute. > * This discussion in the SCIM mailing list [1] also indicates that = this should be fixed. >=20 > [1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/ >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 VERIFIED

However, the correction needs a correction.  The display = attribute is =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D.

    =      {
          &nb= sp;"name": "display",
          &nb= sp;"type": "string",
          &nb= sp;"multiValued": false,
          &nb= sp;"description": "A human-readable name for the group member, primarily = used for display purposes.",
          &nb= sp;"required": false,
          &nb= sp;"caseExact": false,
          &nb= sp;"mutability": "readOnly=E2=80=9D,
=E2=80=94>. = should be: 
    =        "mutability": =E2=80=9Cimmutable=E2=80=9D,

         &nb= sp; "returned": "default",
          &nb= sp;"uniqueness": "none"
         }

Phil Hunt



On Mar 9, 2020, at 7:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6011
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Corrected Text
--------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name": = "display",
=            "type": = "string",
=            "multiVa= lued": false,
=            "descrip= tion": "A human-readable name for the group member, primarily used for = display purposes.",
=            "require= d": false,
=            "caseExa= ct": false,
=            "mutabil= ity": "readOnly",
=            "returne= d": "default",
=            "uniquen= ess": "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Notes
-----
The group "members" = attribute should define a "display" sub-attribute.

* Section 2.4 defines a standard multi-valued read-only = attribute of "display".
* The Group Representation example = in Section 8.4 also includes the "members.display" sub-attribute.
* This discussion in the SCIM mailing list [1] also indicates = that this should be fixed.

[1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A-- From nobody Mon Mar 9 10:04:14 2020 Return-Path: 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 A0A083A13C8 for ; Mon, 9 Mar 2020 10:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 0zy8D9ZLCHMq for ; Mon, 9 Mar 2020 10:04:01 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5834C3A13D6 for ; Mon, 9 Mar 2020 10:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583773440; bh=olwwoP4QZQ6OoK0jaY6plM0OPH3BzvblPlxUx8nCPIQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=re9R3SEgy7qS/SZq/XmDc1dU3+OHhk9nJVmyu0FEI1QjOI98ycESJqoYPK4jmvvAon7u7ncsCf50h2pjLhnA++1A819AKSnfmTCix8NVrZT37snnfXjwsHUIssFbC+0FN/dRHt0Zsj3a2zV5a5TchtEY7PVjscmC40nzupoGPetsjpqj+4Yzflq9haOpvQW8+qFuHvBamFT9FOzs675lFbl9CCT+PvMRiKC9x2w00/fxiR2uloB/JtkpfZpSeWSkwQCXma78WpTqFk9ePwtF7GwJ7+ZZ0uYz0QxkJRkAH9l10qscs1DJibYx0VFNAXTbT2EfZu1QLlb5tCmfzxolAw== X-YMail-OSG: _j14jqgVM1mKLSGceT.05_ii4suR2lNoWy5b27xGnPdX.M6h1.tuV.C7Dud5HoH 2Lu8OO_4dd6sc5Z9c9MjobUcpmcVDUx5MwLBXAsfHdUG.Vn6zzcBO06rUajyPPeAgxrmBOgLokMQ 0Duq7Ra7mRIU8sxXwjskdHGBTDkskvewjmFQguozslnUBVJJTjJVB_AhS4FoMKWfwy0YmivEKDb7 cVRy9eOdnRSQTjiUu6uB1w720Hvz48QOA5yOy.0Vhp_tswz6UTRKfv8hKIHw.6433JK4heM9tahJ Hgevoa2rV5Ssp9z6JHzAbNaLMxDqSncZd8tyz7mzmQ5lEFmXUiuj.njD8jd0jpOiqpQdUggQrnud YCq1x68MHS7i2NU0R8MtCaL6giB2BvdidIggup3lCTAUGzaXX7vaw9AFQDgdET6o.Et1fZrQrf60 SChg1pU_G0TD43R4mTgvTVqCp3AFFq3kpiOkk6jHz2lv6sKYHvy1WPNmKPZ0vPs6z3ZQ03ozgxPu qy0uikBPPY8izCF5H0ImhO5Eo0a2spEWuNKmRxorcY88iYe0T_x8Mticzg1Fd1mBV4bsqEdzTORn pUUfVKF4u091WzurF1lXfz1pyeeTYY5cLWKidjvPqsHfrwiB1FXio.EvXuwXNPMMK9.tBuvGs8Ut zHTf8qjkJNq62T6XngACfX7MWUQTudueQgmb28DT3hqrmT3c49mXIhBR3G_L9juV7Of5kNb9Q_YD k26xIc185V_u0lehPj63FhSiqvpKdrBL0I0vHLilK9nI9VHOEqpBJT4_KoNSBJHbTAUgB2CT7R2S 0kCTbylW0lSmVtF4aMcPhMC.yz5UZYcseM45lrDDFE.nweJdAEIYJ9sCpLxmxl1pOXiNU7wAa5Ak cxXOOlk5qEkNMma1rMafnBUWLB1KP1tCnXGe7TC_UUa1Fa1IfFSNrfAZ8WUWBingvAjHHfsByoGP 1B3WyRQIuEw1G3Wjr2g8AWAjEcGrH8gycucBSis.L8xAbeC3LA7MGxsyF434tU.7.hbjV27KunoJ hbvjL.3ECNnCQ0MUrhbNTaa96WwkGVd359mt0HvrJt8DX1RKLb32Zz1tflz9Q4YjQ9F2EHkezNVf RDrecMCH_78zCTB6xDJ8FHiXXLNO1wFBWB3azSNXr1lqiLhgZYBJMnSY6bTCs79dbejcJpWP5Opr REldhOozZeiAlGwbHDqG0u9ll_G8U5WBqUf3ygPmBS9TB_X3WlRSPWbs6sjtb3ZQ0Fd7j0Kj2BMq XXJDC8NEi2Z_vNkpWxkdzwdGcRXiSBUlgeOQM6Bnqnk_ms8FhfOji16QYVBR2STG9NLdl.csPLEU O4RYn6M4KB711Ah_aKWFl1qndLH9Cl1xamIXqkGV6wODdLD8aYuJygN8QNWSwSrSI7XjrXHZQfYs .mmrcrCVFe1iq_Ycgww-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Mon, 9 Mar 2020 17:04:00 +0000 Received: by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f6a17423d2aebe9802ac21341884bee2; Mon, 09 Mar 2020 17:03:59 +0000 (UTC) From: Phil Hunt Message-Id: <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 9 Mar 2020 10:01:32 -0700 In-Reply-To: <20200309144726.4AE80F40720@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, Shelley , scim@ietf.org To: RFC Errata System References: <20200309144726.4AE80F40720@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6011) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:04:07 -0000 --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 VERIFIED However, the correction needs a correction. The display attribute is = =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D. { "name": "display", "type": "string", "multiValued": false, "description": "A human-readable name for the group member, = primarily used for display purposes.", "required": false, "caseExact": false, "mutability": "readOnly=E2=80=9D, =E2=80=94>. should be:=20 "mutability": =E2=80=9Cimmutable=E2=80=9D, "returned": "default", "uniqueness": "none" } Phil Hunt phil.hunt@yahoo.com > On Mar 9, 2020, at 7:47 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6011 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } >=20 > Corrected Text > -------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, = primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly", > "returned": "default", > "uniqueness": "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } >=20 > Notes > ----- > The group "members" attribute should define a "display" sub-attribute. >=20 > * Section 2.4 defines a standard multi-valued read-only attribute of = "display". > * The Group Representation example in Section 8.4 also includes the = "members.display" sub-attribute. > * This discussion in the SCIM mailing list [1] also indicates that = this should be fixed. >=20 > [1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/ >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 VERIFIED

However, the correction needs a correction.  The display = attribute is =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D.

    =      {
          &nb= sp;"name": "display",
          &nb= sp;"type": "string",
          &nb= sp;"multiValued": false,
          &nb= sp;"description": "A human-readable name for the group member, primarily = used for display purposes.",
          &nb= sp;"required": false,
          &nb= sp;"caseExact": false,
          &nb= sp;"mutability": "readOnly=E2=80=9D,
=E2=80=94>. = should be: 
    =        "mutability": =E2=80=9Cimmutable=E2=80=9D,

         &nb= sp; "returned": "default",
          &nb= sp;"uniqueness": "none"
         }

Phil Hunt



On Mar 9, 2020, at 7:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6011
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Corrected Text
--------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name": = "display",
=            "type": = "string",
=            "multiVa= lued": false,
=            "descrip= tion": "A human-readable name for the group member, primarily used for = display purposes.",
=            "require= d": false,
=            "caseExa= ct": false,
=            "mutabil= ity": "readOnly",
=            "returne= d": "default",
=            "uniquen= ess": "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Notes
-----
The group "members" = attribute should define a "display" sub-attribute.

* Section 2.4 defines a standard multi-valued read-only = attribute of "display".
* The Group Representation example = in Section 8.4 also includes the "members.display" sub-attribute.
* This discussion in the SCIM mailing list [1] also indicates = that this should be fixed.

[1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_C2A748BF-5D6E-4D57-9660-C48C29ECBA7A-- From nobody Mon Mar 9 10:21:35 2020 Return-Path: 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 1FFBF3A126D for ; Mon, 9 Mar 2020 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 S_bsQ3hisod7 for ; Mon, 9 Mar 2020 10:21:32 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4FF3A1243 for ; Mon, 9 Mar 2020 10:21:32 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id q17so3590174uao.12 for ; Mon, 09 Mar 2020 10:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kwCL++xcidhfUOBn38lzGhjbJBEBw1wv1at+mVpz4Ro=; b=t3G17t9JO7P2qPEwtIidsQF34pgWxzNYQ0PjZdF6vmnWWAg7BjWCtUQvXhX7ooInqZ 1U8Gj/hTARg+TlLZbQKBtZtmGGxHaptm0CB66R78NYfAPliPluDpAbCQ8ikOPRBDgSa5 aD6cCljuFN3aqq7edU4ED7eYu1Q9pGE+vfra41Aoy0XyOEHIKX9+ZVTgXWfKHVUcSEVm 1hcE9wHfzy4EglNmGqRcxnL1iix6TkVPqn1mgBxmD4FoG5HI8oRGFFWPPS8PS51mmB00 v6O25rqm9M7cSQfaA+K1KtKqAGNB4D/80FnPER2Ahf6u75fzuVLZc9/zCo5Kl+CAeeJP x/5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kwCL++xcidhfUOBn38lzGhjbJBEBw1wv1at+mVpz4Ro=; b=AhEe3wpP3iH/L1aCw3bffUuU4brWeg9HHujzX20/2tKwtQdkaLBpxbOwrZJ9bwlivR KL7BxFMb9m9wrW9nqzCcnMohezb379OEivS8aKz74bxrDFY9vHGNKd1/n5PEN0ytmZOt 3OJxv6Ac+yo+WdJYTbqciG+BsAL52OWoSuNjpJ5RGjH9OqeI0wRiQYUvT3wuRlv/Pv/7 hVLVP5VtGKrifU7jrrn1iGtWP3RL5MWHrTu5fA51aC2DiHdWPDizE0i3q//PTelB1F/z PBdv0H1ymLLBwOZo/Qk9CSVHPuIldnt4bkJuFxt575vsAhnlVyh2gazBYsR9vTASqVFL GmUw== X-Gm-Message-State: ANhLgQ2gerXs2avyRfbRQW34o9phL2a8mIRi3isyHEAvmaYqz2FNRpyK 6ywKHTLDrQv/kb6Yl7RACd8y/qf3onr4UD/vh4WScazoctA= X-Google-Smtp-Source: ADFU+vvcoHbRWSqAtw+NVoyt25rOKdcR+eTeGMlLiQ9QyR3L0MOd2/lJYz/TvRsU9CY7+EArSOakp8baUJD7N3okWGY= X-Received: by 2002:ab0:2991:: with SMTP id u17mr1701885uap.35.1583774491293; Mon, 09 Mar 2020 10:21:31 -0700 (PDT) MIME-Version: 1.0 References: <20200309144726.4AE80F40720@rfc-editor.org> <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> In-Reply-To: <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> From: Shelley Date: Mon, 9 Mar 2020 12:21:20 -0500 Message-ID: To: Phil Hunt Cc: RFC Errata System , Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000f53adf05a06f3b3b" Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6011) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 17:21:34 -0000 --000000000000f53adf05a06f3b3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. The use of "readOnly" for the "display" mutability overlaps a bit with a question posted here: https://mailarchive.ietf.org/arch/msg/scim/qI6J6ZwnlowstviRBMox41J_yo4/ Apologies for conflating these two issues. On Mon, Mar 9, 2020 at 12:04 PM Phil Hunt wrote: > VERIFIED > > However, the correction needs a correction. The display attribute is > =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D. > > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, > primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly=E2=80=9D, > =E2=80=94>. should be: > "mutability": =E2=80=9Cimmutable=E2=80=9D, > > "returned": "default", > "uniqueness": "none" > } > > Phil Hunt > phil.hunt@yahoo.com > > > > On Mar 9, 2020, at 7:47 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6011 > > -------------------------------------- > Type: Technical > Reported by: Shelley Baker > > Section: 8.7.1 > > Original Text > ------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } > > Corrected Text > -------------- > { > "name" : "members", > "type" : "complex", > "multiValued" : true, > "description" : "A list of members of the Group.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "string", > "multiValued" : false, > "description" : "Identifier of the member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI corresponding to a SCIM resource > that is a member of this Group.", > "required" : false, > "caseExact" : false, > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name" : "type", > "type" : "string", > "multiValued" : false, > "description" : "A label indicating the type of resource, > e.g., 'User' or 'Group'.", > "required" : false, > "caseExact" : false, > "canonicalValues" : [ > "User", > "Group" > ], > "mutability" : "immutable", > "returned" : "default", > "uniqueness" : "none" > }, > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, > primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly", > "returned": "default", > "uniqueness": "none" > } > ], > "mutability" : "readWrite", > "returned" : "default" > } > > Notes > ----- > The group "members" attribute should define a "display" sub-attribute. > > * Section 2.4 defines a standard multi-valued read-only attribute of > "display". > * The Group Representation example in Section 8.4 also includes the > "members.display" sub-attribute. > * This discussion in the SCIM mailing list [1] also indicates that this > should be fixed. > > [1] > https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/ > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: Core > Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimo= re > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG > > > --000000000000f53adf05a06f3b3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdj5UaGFua3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUg dXNlIG9mICZxdW90O3JlYWRPbmx5JnF1b3Q7IGZvciB0aGUgJnF1b3Q7ZGlzcGxheSZxdW90OyBt dXRhYmlsaXR5IG92ZXJsYXBzIGEgYml0IHdpdGggYSBxdWVzdGlvbiBwb3N0ZWQgaGVyZTo8L2Rp dj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2Np bS9xSTZKNlp3bmxvd3N0dmlSQk1veDQxSl95bzQvIj5odHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3NjaW0vcUk2SjZad25sb3dzdHZpUkJNb3g0MUpfeW80LzwvYT48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pg0KQXBvbG9naWVzIGZvciBjb25mbGF0aW5nIHRoZXNlIHR3byBp c3N1ZXMuDQoNCjwvZGl2PjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBk aXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIE1vbiwgTWFyIDksIDIwMjAgYXQgMTI6MDQg UE0gUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QHlhaG9vLmNvbSI+cGhp bC5odW50QHlhaG9vLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHls ZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiPlZFUklGSUVEPGRpdj48YnI+PC9kaXY+PGRp dj5Ib3dldmVyLCB0aGUgY29ycmVjdGlvbiBuZWVkcyBhIGNvcnJlY3Rpb24uwqAgVGhlIGRpc3Bs YXkgYXR0cmlidXRlIGlzIOKAnGltbXV0YWJsZeKAnSBub3Qg4oCccmVhZE9ubHnigJ0uPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj7CoCDCoCDCoCDCoCDCoHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoCZxdW90O25hbWUmcXVvdDs6ICZxdW90O2Rpc3BsYXkmcXVvdDssPGJyPsKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7OiAmcXVvdDtzdHJpbmcmcXVvdDssPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqAmcXVvdDttdWx0aVZhbHVlZCZxdW90OzogZmFsc2UsPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OzogJnF1b3Q7QSBodW1hbi1y ZWFkYWJsZSBuYW1lIGZvciB0aGUgZ3JvdXAgbWVtYmVyLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlz cGxheSBwdXJwb3Nlcy4mcXVvdDssPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1 aXJlZCZxdW90OzogZmFsc2UsPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtjYXNlRXhh Y3QmcXVvdDs6IGZhbHNlLDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXV0YWJpbGl0 eSZxdW90OzogJnF1b3Q7cmVhZE9ubHnigJ0sPC9kaXY+PGRpdj7igJQmZ3Q7LiBzaG91bGQgYmU6 wqA8L2Rpdj48ZGl2PjxkaXY+wqAgwqAgwqAgwqAgwqAgwqAmcXVvdDttdXRhYmlsaXR5JnF1b3Q7 OiDigJxpbW11dGFibGXigJ0sPC9kaXY+PGRpdj48YnI+PC9kaXY+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoCZxdW90O3JldHVybmVkJnF1b3Q7OiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj7CoMKgwqDC oMKgwqDCoMKgwqDCoMKgJnF1b3Q7dW5pcXVlbmVzcyZxdW90OzogJnF1b3Q7bm9uZSZxdW90Ozxi cj7CoMKgwqDCoMKgwqDCoMKgwqB9PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQt c2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlBoaWwgSHVudDwvZGl2PjxkaXYgc3R5 bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAeWFob28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QHlhaG9vLmNvbTwvYT48L2Rpdj48ZGl2IHN0 eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJw eDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6 bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50 OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6 MHB4O3RleHQtZGVjb3JhdGlvbjpub25lIj48YnI+PC9kaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pk9uIE1hciA5LCAyMDIwLCBhdCA3OjQ3IEFN LCBSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVk aXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZn dDsgd3JvdGU6PC9kaXY+PGJyPjxkaXY+PGRpdj5UaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQg aGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM3NjQzLDxicj4mcXVvdDtTeXN0ZW0gZm9yIENyb3Nz LWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50OiBDb3JlIFNjaGVtYSZxdW90Oy48YnI+PGJyPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPllvdSBtYXkgcmV2aWV3IHRo ZSByZXBvcnQgYmVsb3cgYW5kIGF0Ojxicj48YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9lcnJhdGEvZWlkNjAxMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2VycmF0YS9laWQ2MDExPC9hPjxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+VHlwZTogVGVjaG5pY2FsPGJyPlJlcG9ydGVkIGJ5OiBTaGVsbGV5 IEJha2VyICZsdDs8YSBocmVmPSJtYWlsdG86cmFuZG9tc2hlbGxleUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5yYW5kb21zaGVsbGV5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxicj5TZWN0aW9u OiA4LjcuMTxicj48YnI+T3JpZ2luYWwgVGV4dDxicj4tLS0tLS0tLS0tLS0tPGJyPiDCoMKgwqDC oMKgezxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1lJnF1b3Q7IDogJnF1b3Q7bWVtYmVycyZx dW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7dHlwZSZxdW90OyA6ICZxdW90O2NvbXBsZXgm cXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFsdWVkJnF1b3Q7IDogdHJ1ZSw8 YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgOiAmcXVvdDtBIGxpc3Qg b2YgbWVtYmVycyBvZiB0aGUgR3JvdXAuJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDty ZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtzdWJBdHRyaWJ1 dGVzJnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDt2YWx1ZSZxdW90Oyw8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7IDogJnF1b3Q7c3RyaW5nJnF1b3Q7LDxicj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFsdWVkJnF1b3Q7IDogZmFsc2UsPGJy PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgOiAmcXVvdDtJ ZGVudGlmaWVyIG9mIHRoZSBtZW1iZXIgb2YgdGhpcyBHcm91cC4mcXVvdDssPGJyPiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmVxdWlyZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAmcXVvdDtjYXNlRXhhY3QmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAmcXVvdDttdXRhYmlsaXR5JnF1b3Q7IDogJnF1b3Q7aW1tdXRhYmxlJnF1 b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3JldHVybmVkJnF1b3Q7IDogJnF1 b3Q7ZGVmYXVsdCZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt1bmlxdWVu ZXNzJnF1b3Q7IDogJnF1b3Q7bm9uZSZxdW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgfSw8YnI+ IMKgwqDCoMKgwqDCoMKgwqDCoHs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1l JnF1b3Q7IDogJnF1b3Q7JHJlZiZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVv dDt0eXBlJnF1b3Q7IDogJnF1b3Q7cmVmZXJlbmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCZxdW90O3JlZmVyZW5jZVR5cGVzJnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDtVc2VyJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAmcXVvdDtHcm91cCZxdW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoF0sPGJyPiDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXVsdGlWYWx1ZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyA6ICZxdW90O1RoZSBV UkkgY29ycmVzcG9uZGluZyB0byBhIFNDSU0gcmVzb3VyY2U8YnI+dGhhdCBpcyBhIG1lbWJlciBv ZiB0aGlzIEdyb3VwLiZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1 aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O2Nhc2VF eGFjdCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211dGFi aWxpdHkmcXVvdDsgOiAmcXVvdDtpbW11dGFibGUmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgJnF1b3Q7cmV0dXJuZWQmcXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3VuaXF1ZW5lc3MmcXVvdDsgOiAmcXVvdDtub25lJnF1 b3Q7PGJyPiDCoMKgwqDCoMKgwqDCoMKgwqB9LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgezxicj4g wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDt0eXBlJnF1b3Q7 LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3R5cGUmcXVvdDsgOiAmcXVvdDtzdHJp bmcmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXVsdGlWYWx1ZWQmcXVv dDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZx dW90OyA6ICZxdW90O0EgbGFiZWwgaW5kaWNhdGluZyB0aGUgdHlwZSBvZiByZXNvdXJjZSw8YnI+ ZS5nLiwgJiMzOTtVc2VyJiMzOTsgb3IgJiMzOTtHcm91cCYjMzk7LiZxdW90Oyw8YnI+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCZxdW90O2Nhc2VFeGFjdCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCZxdW90O2Nhbm9uaWNhbFZhbHVlcyZxdW90OyA6IFs8YnI+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7VXNlciZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgJnF1b3Q7R3JvdXAmcXVvdDs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBd LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211dGFiaWxpdHkmcXVvdDsgOiAmcXVv dDtpbW11dGFibGUmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmV0dXJu ZWQmcXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCZxdW90O3VuaXF1ZW5lc3MmcXVvdDsgOiAmcXVvdDtub25lJnF1b3Q7PGJyPiDCoMKgwqDCoMKg wqDCoMKgwqB9PGJyPiDCoMKgwqDCoMKgwqDCoF0sPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O211 dGFiaWxpdHkmcXVvdDsgOiAmcXVvdDtyZWFkV3JpdGUmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDC oCZxdW90O3JldHVybmVkJnF1b3Q7IDogJnF1b3Q7ZGVmYXVsdCZxdW90Ozxicj4gwqDCoMKgwqDC oH08YnI+PGJyPkNvcnJlY3RlZCBUZXh0PGJyPi0tLS0tLS0tLS0tLS0tPGJyPiDCoMKgwqDCoMKg ezxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1lJnF1b3Q7IDogJnF1b3Q7bWVtYmVycyZxdW90 Oyw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7dHlwZSZxdW90OyA6ICZxdW90O2NvbXBsZXgmcXVv dDssPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFsdWVkJnF1b3Q7IDogdHJ1ZSw8YnI+ IMKgwqDCoMKgwqDCoMKgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgOiAmcXVvdDtBIGxpc3Qgb2Yg bWVtYmVycyBvZiB0aGUgR3JvdXAuJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1 aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtzdWJBdHRyaWJ1dGVz JnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDt2YWx1ZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7IDogJnF1b3Q7c3RyaW5nJnF1b3Q7LDxicj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFsdWVkJnF1b3Q7IDogZmFsc2UsPGJyPiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7ZGVzY3JpcHRpb24mcXVvdDsgOiAmcXVvdDtJZGVu dGlmaWVyIG9mIHRoZSBtZW1iZXIgb2YgdGhpcyBHcm91cC4mcXVvdDssPGJyPiDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgJnF1b3Q7cmVxdWlyZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDtjYXNlRXhhY3QmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDttdXRhYmlsaXR5JnF1b3Q7IDogJnF1b3Q7aW1tdXRhYmxlJnF1b3Q7 LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3JldHVybmVkJnF1b3Q7IDogJnF1b3Q7 ZGVmYXVsdCZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt1bmlxdWVuZXNz JnF1b3Q7IDogJnF1b3Q7bm9uZSZxdW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgfSw8YnI+IMKg wqDCoMKgwqDCoMKgwqDCoHs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1lJnF1 b3Q7IDogJnF1b3Q7JHJlZiZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt0 eXBlJnF1b3Q7IDogJnF1b3Q7cmVmZXJlbmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCZxdW90O3JlZmVyZW5jZVR5cGVzJnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAmcXVvdDtVc2VyJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAm cXVvdDtHcm91cCZxdW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoF0sPGJyPiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXVsdGlWYWx1ZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyA6ICZxdW90O1RoZSBVUkkg Y29ycmVzcG9uZGluZyB0byBhIFNDSU0gcmVzb3VyY2U8YnI+dGhhdCBpcyBhIG1lbWJlciBvZiB0 aGlzIEdyb3VwLiZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1aXJl ZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O2Nhc2VFeGFj dCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211dGFiaWxp dHkmcXVvdDsgOiAmcXVvdDtpbW11dGFibGUmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgJnF1b3Q7cmV0dXJuZWQmcXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCZxdW90O3VuaXF1ZW5lc3MmcXVvdDsgOiAmcXVvdDtub25lJnF1b3Q7 PGJyPiDCoMKgwqDCoMKgwqDCoMKgwqB9LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgezxicj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDt0eXBlJnF1b3Q7LDxi cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3R5cGUmcXVvdDsgOiAmcXVvdDtzdHJpbmcm cXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXVsdGlWYWx1ZWQmcXVvdDsg OiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90 OyA6ICZxdW90O0EgbGFiZWwgaW5kaWNhdGluZyB0aGUgdHlwZSBvZiByZXNvdXJjZSw8YnI+ZS5n LiwgJiMzOTtVc2VyJiMzOTsgb3IgJiMzOTtHcm91cCYjMzk7LiZxdW90Oyw8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCZxdW90O2Nhc2VFeGFjdCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCZxdW90O2Nhbm9uaWNhbFZhbHVlcyZxdW90OyA6IFs8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7VXNlciZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgJnF1b3Q7R3JvdXAmcXVvdDs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBdLDxi cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211dGFiaWxpdHkmcXVvdDsgOiAmcXVvdDtp bW11dGFibGUmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmV0dXJuZWQm cXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZx dW90O3VuaXF1ZW5lc3MmcXVvdDsgOiAmcXVvdDtub25lJnF1b3Q7PGJyPiDCoMKgwqDCoMKgwqDC oMKgwqB9LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCZxdW90O25hbWUmcXVvdDs6ICZxdW90O2Rpc3BsYXkmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgJnF1b3Q7dHlwZSZxdW90OzogJnF1b3Q7c3RyaW5nJnF1b3Q7LDxicj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFsdWVkJnF1b3Q7OiBmYWxzZSw8YnI+IMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OzogJnF1b3Q7QSBodW1hbi1y ZWFkYWJsZSBuYW1lIGZvciB0aGUgZ3JvdXAgbWVtYmVyLCBwcmltYXJpbHkgdXNlZCBmb3IgZGlz cGxheSBwdXJwb3Nlcy4mcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmVx dWlyZWQmcXVvdDs6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O2Nhc2VF eGFjdCZxdW90OzogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXV0YWJp bGl0eSZxdW90OzogJnF1b3Q7cmVhZE9ubHkmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgJnF1b3Q7cmV0dXJuZWQmcXVvdDs6ICZxdW90O2RlZmF1bHQmcXVvdDssPGJyPiDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgJnF1b3Q7dW5pcXVlbmVzcyZxdW90OzogJnF1b3Q7bm9uZSZxdW90Ozxi cj4gwqDCoMKgwqDCoMKgwqDCoMKgfTxicj4gwqDCoMKgwqDCoMKgwqBdLDxicj4gwqDCoMKgwqDC oMKgwqAmcXVvdDttdXRhYmlsaXR5JnF1b3Q7IDogJnF1b3Q7cmVhZFdyaXRlJnF1b3Q7LDxicj4g wqDCoMKgwqDCoMKgwqAmcXVvdDtyZXR1cm5lZCZxdW90OyA6ICZxdW90O2RlZmF1bHQmcXVvdDs8 YnI+IMKgwqDCoMKgwqB9PGJyPjxicj5Ob3Rlczxicj4tLS0tLTxicj5UaGUgZ3JvdXAgJnF1b3Q7 bWVtYmVycyZxdW90OyBhdHRyaWJ1dGUgc2hvdWxkIGRlZmluZSBhICZxdW90O2Rpc3BsYXkmcXVv dDsgc3ViLWF0dHJpYnV0ZS48YnI+PGJyPiogU2VjdGlvbiAyLjQgZGVmaW5lcyBhIHN0YW5kYXJk IG11bHRpLXZhbHVlZCByZWFkLW9ubHkgYXR0cmlidXRlIG9mICZxdW90O2Rpc3BsYXkmcXVvdDsu PGJyPiogVGhlIEdyb3VwIFJlcHJlc2VudGF0aW9uIGV4YW1wbGUgaW4gU2VjdGlvbiA4LjQgYWxz byBpbmNsdWRlcyB0aGUgJnF1b3Q7bWVtYmVycy5kaXNwbGF5JnF1b3Q7IHN1Yi1hdHRyaWJ1dGUu PGJyPiogVGhpcyBkaXNjdXNzaW9uIGluIHRoZSBTQ0lNIG1haWxpbmcgbGlzdCBbMV0gYWxzbyBp bmRpY2F0ZXMgdGhhdCB0aGlzIHNob3VsZCBiZSBmaXhlZC48YnI+PGJyPlsxXSA8YSBocmVmPSJo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NjaW0vRUg5OUd4bi1oRGx1aWhN TnRXTElla3VGQ3M4LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvc2NpbS9FSDk5R3huLWhEbHVpaE1OdFdMSWVrdUZDczgvPC9hPjxicj48YnI+ SW5zdHJ1Y3Rpb25zOjxicj4tLS0tLS0tLS0tLS0tPGJyPlRoaXMgZXJyYXR1bSBpcyBjdXJyZW50 bHkgcG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxi cj51c2UgJnF1b3Q7UmVwbHkgQWxsJnF1b3Q7IHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQg YmUgdmVyaWZpZWQgb3I8YnI+cmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0 aGUgdmVyaWZ5aW5nIHBhcnR5IMKgPGJyPmNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMg YW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiA8YnI+PGJyPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPlJGQzc2NDMgKGRyYWZ0LWlldGYtc2NpbS1jb3Jl LXNjaGVtYS0yMik8YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ VGl0bGUgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDogU3lzdGVtIGZvciBDcm9zcy1kb21h aW4gSWRlbnRpdHkgTWFuYWdlbWVudDogQ29yZSBTY2hlbWE8YnI+UHVibGljYXRpb24gRGF0ZSDC oMKgwqA6IFNlcHRlbWJlciAyMDE1PGJyPkF1dGhvcihzKSDCoMKgwqDCoMKgwqDCoMKgwqDCoDog UC4gSHVudCwgRWQuLCBLLiBHcml6emxlLCBFLiBXYWhsc3Ryb2VtLCBDLiBNb3J0aW1vcmU8YnI+ Q2F0ZWdvcnkgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDogUFJPUE9TRUQgU1RBTkRBUkQ8YnI+U291 cmNlIMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgOiBTeXN0ZW0gZm9yIENyb3NzLWRvbWFpbiBJ ZGVudGl0eSBNYW5hZ2VtZW50PGJyPkFyZWEgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg OiBBcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZTxicj5TdHJlYW0gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqA6IElFVEY8YnI+VmVyaWZ5aW5nIFBhcnR5IMKgwqDCoMKgOiBJRVNHPGJyPjwvZGl2 PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwv ZGl2Pg0K --000000000000f53adf05a06f3b3b-- From nobody Tue Mar 10 11:44:58 2020 Return-Path: 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 21E683A084D for ; Tue, 10 Mar 2020 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 MXgmT4uWzhLR for ; Tue, 10 Mar 2020 11:44:52 -0700 (PDT) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B373A0849 for ; Tue, 10 Mar 2020 11:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583865891; bh=GcqKbb2yxAas4XXq6MaLdOQDwQnURbgYrVb8aDHtLN0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=bFYTHBgySvnBeJQxg8pIH9N+N4hws0yNd9NLLVVcRyayiXLD9TJp/vOEmKJRAQDwTKo1DUTZtRAi0+E4Yyr2fD0BzdmyU8dJ+p6M/gyZXl8eYFYbZlC2vrfb3VxbSpd9Edd0drG6Wha47y7dHKVcoZq33d4WOizVwBEaiL/eEvSUxDxxR5KB2PmFNPedET08IBhHfEXKifF7ekffsmkrvNWESyUtWmxuEfmd2Z2wm4gGieR79lJIwg1abPicNq/5DDDxm0fI9hIvbTXNIsorRdJsZMKsVe3N3P/O7QSzcBDOPibhwYNpfmonLbEXYiP7Mol0N/dYUVUFRiWLR9YOdQ== X-YMail-OSG: dWGoVKMVM1ljsxxttyOyZGV01xWm.mdAuuKn0auKQ4MMi0.FTtObdteRnlv5MHN wZ9IeCpJO39yRZTiexuHxPf2PP4BIqQISFQmyWozKmG58BHEJvIbEWomMeEBUzPOsKHU_t9UrvKG FAPwIrGj7G5i4QrSX2Hf1_8Ji0igggMCPv.WVsQpeKn6irFeCjrA5hjcPWaoBZ5S2JEEexgeDUHC 80feJQ7YFVtnwQZPOa62yh_gU9U7oU8RpLCalkLGwUuVMSaJba9mTRP6d7l6z6obMx.ZinGZSCp_ Hw9wd7QLHdmFwHffB0KrJwHOb3TDQWM2rhHahVO0yfxohjoCTmfaYaL5Sf9cFnVbh.FfU0d2QE8J nOyKRJyoWd.a0YW0fimCNl3B9XAJlfyyYv.sTmMKwrmV6k01gUTcmHqTESjUzj8zNMcSH2vPe3ZC 4zlIKXRLcObEhogMi8sVEbcVeeznfuw6wbr8RAqcjcZR1xoHxwr1ZdHmfGz55ZnqYbKgod_CPlDP Qls6.Ygsec6WFwd.JXWWmNFCqKV8OmvqPA74LLQ3w0FC6tDBQCYJW254Wr07VUpY7uWlMdBUkSso iRs7wcWkIyZELfA1xtfSXQGAD7HeTa94ANi4y.u6Zi1Wrgdsc5gMU8T5hctk3H3_2.wO1k4EM1EZ xmXSM1zNwtnTrFlwMXw4Wqkpv3y6qzCF6CW9EokNvpX_YY10I8wvjpIFGjMPv1lhE5afP.5Mud0N isFaIQ4WxrA1hcPxCk2kLEOw0lsYhZs1liGisq8gccYiPGuzeRTCGqL_RHyE5yGF7luj5iLsTVlM QJfx2i8ZVQjWhvKAviw381vBL3N4PWYwdAIBB8ESUCX8Va4I7Qi9rif65PEDOyyzYtWc0aj9p5GA M_Rcod3xbXDRsS2z1hT4z8xrFxrlNfxXND3lrRFRYQ84LbM3OkF3gCDHG2k92s7GTC4P6llfamni CPLAEzkI6iz01zOsvauBR.doArFUGVLEKOtbTXVAtv6mKzryKQlu5BNQ7RfQb4brvvL17Dm7mdpY .t5wteXPZFvuLj2FmhpJiZr.qz2AAgEZhu_s_eUFCVJqFy3AgoAv1mLPAn9HoHUlQsyq6J_tXawW vTxZIoNFl.TAWqtZR.yGrW5Hq2T4hjTr1.AxJfXxCnUguTZ3oAPOLmiulgWB.LBjftYpb5yW4DpT CQIJJt1GfCfw4Jcmx0fkez33STgn3duzG.X6KPyUO0RtXHHztkqowNFJo_.fwomukhK5SEnzA3bu AHPTJMZo2MYn4es6EXLEtHmAS2_5sqOAekS9984Dfd61lnyK_I.BIiPd_dylz5G7kF3htwqYwGBq KdXoaRERKJLpvPfutvz6hdHJFgpf9VddXSjIbSi5PJBT7Dk7ajivvHeY.iUjXchraFSs0mWNIyCK ogUWueY80_2XeUeDjWd8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 18:44:51 +0000 Received: by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8eb8bb14d529d94059f6209f2dab6717; Tue, 10 Mar 2020 18:44:47 +0000 (UTC) From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 11:44:45 -0700 In-Reply-To: Cc: Adam Roach , Alexey Melnikov , leifj@sunet.se, scim@ietf.org, Kelly Grizzle , Barry Leiba , Morteza Ansari , RFC Errata System To: Shelley References: <20200309144726.4AE80F40720@rfc-editor.org> <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6011) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:44:55 -0000 --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, The display attribute is usually set by the client creating the record. = AFAIK most of the time CMV attributes are immutable (at least that was = the discussion). In some cases it may be an attribute asserted only by the service = provider but not always. For this reason, I would not recommend the = example show =E2=80=9CreadOnly=E2=80=9D as this may cause a lot of = confusion. Instead I would go with =E2=80=9Cimmutable=E2=80=9D per the = spec default. =46rom a historical perspective... I know that as the SCIM 2 protocol evolved (from SCIM 1), we developed = the PATCH operation to be able to do discreet manipulation of CMVAs = which enabled updating of attributes in a readwrite fashion. Phil Hunt phil.hunt@yahoo.com > On Mar 9, 2020, at 10:21 AM, Shelley wrote: >=20 > Thanks. >=20 > The use of "readOnly" for the "display" mutability overlaps a bit with = a question posted here: > = https://mailarchive.ietf.org/arch/msg/scim/qI6J6ZwnlowstviRBMox41J_yo4/ = >=20 > Apologies for conflating these two issues. >=20 > On Mon, Mar 9, 2020 at 12:04 PM Phil Hunt > wrote: > VERIFIED >=20 > However, the correction needs a correction. The display attribute is = =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D. >=20 > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, = primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly=E2=80=9D, > =E2=80=94>. should be:=20 > "mutability": =E2=80=9Cimmutable=E2=80=9D, >=20 > "returned": "default", > "uniqueness": "none" > } >=20 > Phil Hunt > phil.hunt@yahoo.com >=20 >=20 >=20 >> On Mar 9, 2020, at 7:47 AM, RFC Errata System = > wrote: >>=20 >> The following errata report has been submitted for RFC7643, >> "System for Cross-domain Identity Management: Core Schema". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6011 = >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Shelley Baker > >>=20 >> Section: 8.7.1 >>=20 >> Original Text >> ------------- >> { >> "name" : "members", >> "type" : "complex", >> "multiValued" : true, >> "description" : "A list of members of the Group.", >> "required" : false, >> "subAttributes" : [ >> { >> "name" : "value", >> "type" : "string", >> "multiValued" : false, >> "description" : "Identifier of the member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "$ref", >> "type" : "reference", >> "referenceTypes" : [ >> "User", >> "Group" >> ], >> "multiValued" : false, >> "description" : "The URI corresponding to a SCIM resource >> that is a member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "type", >> "type" : "string", >> "multiValued" : false, >> "description" : "A label indicating the type of resource, >> e.g., 'User' or 'Group'.", >> "required" : false, >> "caseExact" : false, >> "canonicalValues" : [ >> "User", >> "Group" >> ], >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> } >> ], >> "mutability" : "readWrite", >> "returned" : "default" >> } >>=20 >> Corrected Text >> -------------- >> { >> "name" : "members", >> "type" : "complex", >> "multiValued" : true, >> "description" : "A list of members of the Group.", >> "required" : false, >> "subAttributes" : [ >> { >> "name" : "value", >> "type" : "string", >> "multiValued" : false, >> "description" : "Identifier of the member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "$ref", >> "type" : "reference", >> "referenceTypes" : [ >> "User", >> "Group" >> ], >> "multiValued" : false, >> "description" : "The URI corresponding to a SCIM resource >> that is a member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "type", >> "type" : "string", >> "multiValued" : false, >> "description" : "A label indicating the type of resource, >> e.g., 'User' or 'Group'.", >> "required" : false, >> "caseExact" : false, >> "canonicalValues" : [ >> "User", >> "Group" >> ], >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name": "display", >> "type": "string", >> "multiValued": false, >> "description": "A human-readable name for the group = member, primarily used for display purposes.", >> "required": false, >> "caseExact": false, >> "mutability": "readOnly", >> "returned": "default", >> "uniqueness": "none" >> } >> ], >> "mutability" : "readWrite", >> "returned" : "default" >> } >>=20 >> Notes >> ----- >> The group "members" attribute should define a "display" = sub-attribute. >>=20 >> * Section 2.4 defines a standard multi-valued read-only attribute of = "display". >> * The Group Representation example in Section 8.4 also includes the = "members.display" sub-attribute. >> * This discussion in the SCIM mailing list [1] also indicates that = this should be fixed. >>=20 >> [1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/ = >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC7643 (draft-ietf-scim-core-schema-22) >> -------------------------------------- >> Title : System for Cross-domain Identity Management: = Core Schema >> Publication Date : September 2015 >> Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore >> Category : PROPOSED STANDARD >> Source : System for Cross-domain Identity Management >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

The display attribute is usually set by the client creating = the record. AFAIK most of the time CMV attributes are immutable (at = least that was the discussion).

In some cases it may be an attribute = asserted only by the service provider but not always.  For this = reason, I would not recommend the example show =E2=80=9CreadOnly=E2=80=9D = as this may cause a lot of confusion. Instead I would go with = =E2=80=9Cimmutable=E2=80=9D per the spec default.
=46rom a historical = perspective...

I= know that as the SCIM 2 protocol evolved (from SCIM 1), we developed = the PATCH operation to be able to do discreet manipulation of CMVAs = which enabled updating of attributes in a readwrite fashion.

Phil Hunt



On Mar 9, 2020, at 10:21 AM, Shelley <randomshelley@gmail.com> wrote:

Thanks.

The use of "readOnly" for the "display" = mutability overlaps a bit with a question posted here:
https://mailarchive.ietf.org/arch/msg/scim/qI6J6ZwnlowstviRBMox= 41J_yo4/

Apologies for conflating these two issues.

On Mon, Mar 9, 2020 at 12:04 PM Phil Hunt <phil.hunt@yahoo.com>= wrote:
VERIFIED

However, the correction needs a correction.  The display = attribute is =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D.

    =      {
          &nb= sp;"name": "display",
          &nb= sp;"type": "string",
          &nb= sp;"multiValued": false,
          &nb= sp;"description": "A human-readable name for the group member, primarily = used for display purposes.",
          &nb= sp;"required": false,
          &nb= sp;"caseExact": false,
          &nb= sp;"mutability": "readOnly=E2=80=9D,
=E2=80=94>. = should be: 
    =        "mutability": =E2=80=9Cimmutable=E2=80=9D,

         &nb= sp; "returned": "default",
          &nb= sp;"uniqueness": "none"
         }

Phil Hunt
phil.hunt@yahoo.com



On Mar 9, 2020, at 7:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report = has been submitted for RFC7643,
"System for Cross-domain = Identity Management: Core Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6011
--------------------------------------
Type: = Technical
Reported by: Shelley Baker <randomshelley@gmail.com>

Section: 8.7.1

Original Text
-------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Corrected Text
--------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name": = "display",
=            "type": = "string",
=            "multiVa= lued": false,
=            "descrip= tion": "A human-readable name for the group member, primarily used for = display purposes.",
=            "require= d": false,
=            "caseExa= ct": false,
=            "mutabil= ity": "readOnly",
=            "returne= d": "default",
=            "uniquen= ess": "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Notes
-----
The group "members" = attribute should define a "display" sub-attribute.

* Section 2.4 defines a standard multi-valued read-only = attribute of "display".
* The Group Representation example = in Section 8.4 also includes the "members.display" sub-attribute.
* This discussion in the SCIM mailing list [1] also indicates = that this should be fixed.

[1] https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLI= ekuFCs8/

Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to = discuss whether it should be verified or
rejected. When a = decision is reached, the verifying party  
can log in = to change the status and edit the report, if necessary.
--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8-- From nobody Tue Mar 10 11:45:04 2020 Return-Path: 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 558333A0849 for ; Tue, 10 Mar 2020 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 CVYAn7k32eJB for ; Tue, 10 Mar 2020 11:44:52 -0700 (PDT) Received: from sonic301-32.consmr.mail.ne1.yahoo.com (sonic301-32.consmr.mail.ne1.yahoo.com [66.163.184.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7FA3A084A for ; Tue, 10 Mar 2020 11:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583865891; bh=GcqKbb2yxAas4XXq6MaLdOQDwQnURbgYrVb8aDHtLN0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=bFYTHBgySvnBeJQxg8pIH9N+N4hws0yNd9NLLVVcRyayiXLD9TJp/vOEmKJRAQDwTKo1DUTZtRAi0+E4Yyr2fD0BzdmyU8dJ+p6M/gyZXl8eYFYbZlC2vrfb3VxbSpd9Edd0drG6Wha47y7dHKVcoZq33d4WOizVwBEaiL/eEvSUxDxxR5KB2PmFNPedET08IBhHfEXKifF7ekffsmkrvNWESyUtWmxuEfmd2Z2wm4gGieR79lJIwg1abPicNq/5DDDxm0fI9hIvbTXNIsorRdJsZMKsVe3N3P/O7QSzcBDOPibhwYNpfmonLbEXYiP7Mol0N/dYUVUFRiWLR9YOdQ== X-YMail-OSG: dWGoVKMVM1ljsxxttyOyZGV01xWm.mdAuuKn0auKQ4MMi0.FTtObdteRnlv5MHN wZ9IeCpJO39yRZTiexuHxPf2PP4BIqQISFQmyWozKmG58BHEJvIbEWomMeEBUzPOsKHU_t9UrvKG FAPwIrGj7G5i4QrSX2Hf1_8Ji0igggMCPv.WVsQpeKn6irFeCjrA5hjcPWaoBZ5S2JEEexgeDUHC 80feJQ7YFVtnwQZPOa62yh_gU9U7oU8RpLCalkLGwUuVMSaJba9mTRP6d7l6z6obMx.ZinGZSCp_ Hw9wd7QLHdmFwHffB0KrJwHOb3TDQWM2rhHahVO0yfxohjoCTmfaYaL5Sf9cFnVbh.FfU0d2QE8J nOyKRJyoWd.a0YW0fimCNl3B9XAJlfyyYv.sTmMKwrmV6k01gUTcmHqTESjUzj8zNMcSH2vPe3ZC 4zlIKXRLcObEhogMi8sVEbcVeeznfuw6wbr8RAqcjcZR1xoHxwr1ZdHmfGz55ZnqYbKgod_CPlDP Qls6.Ygsec6WFwd.JXWWmNFCqKV8OmvqPA74LLQ3w0FC6tDBQCYJW254Wr07VUpY7uWlMdBUkSso iRs7wcWkIyZELfA1xtfSXQGAD7HeTa94ANi4y.u6Zi1Wrgdsc5gMU8T5hctk3H3_2.wO1k4EM1EZ xmXSM1zNwtnTrFlwMXw4Wqkpv3y6qzCF6CW9EokNvpX_YY10I8wvjpIFGjMPv1lhE5afP.5Mud0N isFaIQ4WxrA1hcPxCk2kLEOw0lsYhZs1liGisq8gccYiPGuzeRTCGqL_RHyE5yGF7luj5iLsTVlM QJfx2i8ZVQjWhvKAviw381vBL3N4PWYwdAIBB8ESUCX8Va4I7Qi9rif65PEDOyyzYtWc0aj9p5GA M_Rcod3xbXDRsS2z1hT4z8xrFxrlNfxXND3lrRFRYQ84LbM3OkF3gCDHG2k92s7GTC4P6llfamni CPLAEzkI6iz01zOsvauBR.doArFUGVLEKOtbTXVAtv6mKzryKQlu5BNQ7RfQb4brvvL17Dm7mdpY .t5wteXPZFvuLj2FmhpJiZr.qz2AAgEZhu_s_eUFCVJqFy3AgoAv1mLPAn9HoHUlQsyq6J_tXawW vTxZIoNFl.TAWqtZR.yGrW5Hq2T4hjTr1.AxJfXxCnUguTZ3oAPOLmiulgWB.LBjftYpb5yW4DpT CQIJJt1GfCfw4Jcmx0fkez33STgn3duzG.X6KPyUO0RtXHHztkqowNFJo_.fwomukhK5SEnzA3bu AHPTJMZo2MYn4es6EXLEtHmAS2_5sqOAekS9984Dfd61lnyK_I.BIiPd_dylz5G7kF3htwqYwGBq KdXoaRERKJLpvPfutvz6hdHJFgpf9VddXSjIbSi5PJBT7Dk7ajivvHeY.iUjXchraFSs0mWNIyCK ogUWueY80_2XeUeDjWd8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 18:44:51 +0000 Received: by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8eb8bb14d529d94059f6209f2dab6717; Tue, 10 Mar 2020 18:44:47 +0000 (UTC) From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 11:44:45 -0700 In-Reply-To: Cc: Adam Roach , Alexey Melnikov , leifj@sunet.se, scim@ietf.org, Kelly Grizzle , Barry Leiba , Morteza Ansari , RFC Errata System To: Shelley References: <20200309144726.4AE80F40720@rfc-editor.org> <149452C1-607B-4EDB-BF5C-647B662B73B8@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6011) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:44:55 -0000 --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, The display attribute is usually set by the client creating the record. = AFAIK most of the time CMV attributes are immutable (at least that was = the discussion). In some cases it may be an attribute asserted only by the service = provider but not always. For this reason, I would not recommend the = example show =E2=80=9CreadOnly=E2=80=9D as this may cause a lot of = confusion. Instead I would go with =E2=80=9Cimmutable=E2=80=9D per the = spec default. =46rom a historical perspective... I know that as the SCIM 2 protocol evolved (from SCIM 1), we developed = the PATCH operation to be able to do discreet manipulation of CMVAs = which enabled updating of attributes in a readwrite fashion. Phil Hunt phil.hunt@yahoo.com > On Mar 9, 2020, at 10:21 AM, Shelley wrote: >=20 > Thanks. >=20 > The use of "readOnly" for the "display" mutability overlaps a bit with = a question posted here: > = https://mailarchive.ietf.org/arch/msg/scim/qI6J6ZwnlowstviRBMox41J_yo4/ = >=20 > Apologies for conflating these two issues. >=20 > On Mon, Mar 9, 2020 at 12:04 PM Phil Hunt > wrote: > VERIFIED >=20 > However, the correction needs a correction. The display attribute is = =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D. >=20 > { > "name": "display", > "type": "string", > "multiValued": false, > "description": "A human-readable name for the group member, = primarily used for display purposes.", > "required": false, > "caseExact": false, > "mutability": "readOnly=E2=80=9D, > =E2=80=94>. should be:=20 > "mutability": =E2=80=9Cimmutable=E2=80=9D, >=20 > "returned": "default", > "uniqueness": "none" > } >=20 > Phil Hunt > phil.hunt@yahoo.com >=20 >=20 >=20 >> On Mar 9, 2020, at 7:47 AM, RFC Errata System = > wrote: >>=20 >> The following errata report has been submitted for RFC7643, >> "System for Cross-domain Identity Management: Core Schema". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid6011 = >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Shelley Baker > >>=20 >> Section: 8.7.1 >>=20 >> Original Text >> ------------- >> { >> "name" : "members", >> "type" : "complex", >> "multiValued" : true, >> "description" : "A list of members of the Group.", >> "required" : false, >> "subAttributes" : [ >> { >> "name" : "value", >> "type" : "string", >> "multiValued" : false, >> "description" : "Identifier of the member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "$ref", >> "type" : "reference", >> "referenceTypes" : [ >> "User", >> "Group" >> ], >> "multiValued" : false, >> "description" : "The URI corresponding to a SCIM resource >> that is a member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "type", >> "type" : "string", >> "multiValued" : false, >> "description" : "A label indicating the type of resource, >> e.g., 'User' or 'Group'.", >> "required" : false, >> "caseExact" : false, >> "canonicalValues" : [ >> "User", >> "Group" >> ], >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> } >> ], >> "mutability" : "readWrite", >> "returned" : "default" >> } >>=20 >> Corrected Text >> -------------- >> { >> "name" : "members", >> "type" : "complex", >> "multiValued" : true, >> "description" : "A list of members of the Group.", >> "required" : false, >> "subAttributes" : [ >> { >> "name" : "value", >> "type" : "string", >> "multiValued" : false, >> "description" : "Identifier of the member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "$ref", >> "type" : "reference", >> "referenceTypes" : [ >> "User", >> "Group" >> ], >> "multiValued" : false, >> "description" : "The URI corresponding to a SCIM resource >> that is a member of this Group.", >> "required" : false, >> "caseExact" : false, >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name" : "type", >> "type" : "string", >> "multiValued" : false, >> "description" : "A label indicating the type of resource, >> e.g., 'User' or 'Group'.", >> "required" : false, >> "caseExact" : false, >> "canonicalValues" : [ >> "User", >> "Group" >> ], >> "mutability" : "immutable", >> "returned" : "default", >> "uniqueness" : "none" >> }, >> { >> "name": "display", >> "type": "string", >> "multiValued": false, >> "description": "A human-readable name for the group = member, primarily used for display purposes.", >> "required": false, >> "caseExact": false, >> "mutability": "readOnly", >> "returned": "default", >> "uniqueness": "none" >> } >> ], >> "mutability" : "readWrite", >> "returned" : "default" >> } >>=20 >> Notes >> ----- >> The group "members" attribute should define a "display" = sub-attribute. >>=20 >> * Section 2.4 defines a standard multi-valued read-only attribute of = "display". >> * The Group Representation example in Section 8.4 also includes the = "members.display" sub-attribute. >> * This discussion in the SCIM mailing list [1] also indicates that = this should be fixed. >>=20 >> [1] = https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLIekuFCs8/ = >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party =20 >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC7643 (draft-ietf-scim-core-schema-22) >> -------------------------------------- >> Title : System for Cross-domain Identity Management: = Core Schema >> Publication Date : September 2015 >> Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore >> Category : PROPOSED STANDARD >> Source : System for Cross-domain Identity Management >> Area : Applications and Real-Time >> Stream : IETF >> Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

The display attribute is usually set by the client creating = the record. AFAIK most of the time CMV attributes are immutable (at = least that was the discussion).

In some cases it may be an attribute = asserted only by the service provider but not always.  For this = reason, I would not recommend the example show =E2=80=9CreadOnly=E2=80=9D = as this may cause a lot of confusion. Instead I would go with = =E2=80=9Cimmutable=E2=80=9D per the spec default.
=46rom a historical = perspective...

I= know that as the SCIM 2 protocol evolved (from SCIM 1), we developed = the PATCH operation to be able to do discreet manipulation of CMVAs = which enabled updating of attributes in a readwrite fashion.

Phil Hunt



On Mar 9, 2020, at 10:21 AM, Shelley <randomshelley@gmail.com> wrote:

Thanks.

The use of "readOnly" for the "display" = mutability overlaps a bit with a question posted here:
https://mailarchive.ietf.org/arch/msg/scim/qI6J6ZwnlowstviRBMox= 41J_yo4/

Apologies for conflating these two issues.

On Mon, Mar 9, 2020 at 12:04 PM Phil Hunt <phil.hunt@yahoo.com>= wrote:
VERIFIED

However, the correction needs a correction.  The display = attribute is =E2=80=9Cimmutable=E2=80=9D not =E2=80=9CreadOnly=E2=80=9D.

    =      {
          &nb= sp;"name": "display",
          &nb= sp;"type": "string",
          &nb= sp;"multiValued": false,
          &nb= sp;"description": "A human-readable name for the group member, primarily = used for display purposes.",
          &nb= sp;"required": false,
          &nb= sp;"caseExact": false,
          &nb= sp;"mutability": "readOnly=E2=80=9D,
=E2=80=94>. = should be: 
    =        "mutability": =E2=80=9Cimmutable=E2=80=9D,

         &nb= sp; "returned": "default",
          &nb= sp;"uniqueness": "none"
         }

Phil Hunt
phil.hunt@yahoo.com



On Mar 9, 2020, at 7:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The following errata report = has been submitted for RFC7643,
"System for Cross-domain = Identity Management: Core Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6011
--------------------------------------
Type: = Technical
Reported by: Shelley Baker <randomshelley@gmail.com>

Section: 8.7.1

Original Text
-------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Corrected Text
--------------
=      {
=        "name" : "members",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : "A = list of members of the Group.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "Identifier of the member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI corresponding to a SCIM resource
that is = a member of this Group.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name" = : "type",
=            "type" = : "string",
=            "multiVa= lued" : false,
=            "descrip= tion" : "A label indicating the type of resource,
e.g., = 'User' or 'Group'.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "canonic= alValues" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "mutabil= ity" : "immutable",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
=          {
=            "name": = "display",
=            "type": = "string",
=            "multiVa= lued": false,
=            "descrip= tion": "A human-readable name for the group member, primarily used for = display purposes.",
=            "require= d": false,
=            "caseExa= ct": false,
=            "mutabil= ity": "readOnly",
=            "returne= d": "default",
=            "uniquen= ess": "none"
=          }
=        ],
=        "mutability" : "readWrite",
       "returned" : = "default"
     }
Notes
-----
The group "members" = attribute should define a "display" sub-attribute.

* Section 2.4 defines a standard multi-valued read-only = attribute of "display".
* The Group Representation example = in Section 8.4 also includes the "members.display" sub-attribute.
* This discussion in the SCIM mailing list [1] also indicates = that this should be fixed.

[1] https://mailarchive.ietf.org/arch/msg/scim/EH99Gxn-hDluihMNtWLI= ekuFCs8/

Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to = discuss whether it should be verified or
rejected. When a = decision is reached, the verifying party  
can log in = to change the status and edit the report, if necessary.
--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

_______________________________________________
scim = mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_EBFBD62C-FA93-40E6-99DD-FD3D84E29EC8-- From nobody Tue Mar 10 11:51:44 2020 Return-Path: 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 297833A0863 for ; Tue, 10 Mar 2020 11:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 XLs6aY_4egR0 for ; Tue, 10 Mar 2020 11:51:40 -0700 (PDT) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD9B3A085A for ; Tue, 10 Mar 2020 11:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583866299; bh=6yLM/Pe6a0TXLbtD7ojwmDvzrm2jUUcogJSK02i0YKc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=b60usJ/Im46BZNGbd67GNaJsLlAXJgfkayhMGGooK3jmQv9tmPCYRa+MncYVRPnf48+JbwIG3s3ur0ox5yV9yWo4Gca5n/Yv6NmknWJrHP3Z+mIiBnyZkJqRA//OsuwAdNQ6HcTc0u0sLpehrsttct2DQ4j4BdMR5Rkm9t1pbB8EsacpvxZgQMdm3ChAs+X8SXgP2D0dox41x2bdREgfiTON1QVDLRf2IWdIAC4xGC8DQrh5nyj0N6zr0txar0610T6g0nS11GTXFlDqUbFYMIkHy+KXQIpR2kewSaCniM1q17jejC82QsSTaHTIFQMFvNAbuDW3ETt+jHdFylMk+Q== X-YMail-OSG: D1VpAnQVM1lRvqM_5sIg44XkFgzXGQjqbmw.AjNgu5zEQ3PhQqMYiIXwYI2tApe fXNAjdZyf3qvAvSEIr_GxGbcqLmRM4GuARyzKuPz2pnnTAMCIErHSc0NtROvYUi3M7PL2CEAKCH6 JHSNr7xqXhyJN6Wsot4cymKvXY96Lr4WYFr6HqXoWWvEH6IlmnylHa910WdSaX7wyJw0yweae.Ah Ybw67eIugKkHffzf9iqweXKxjdTwRTMDEIsGUyPBj.MWkpOouYrq6fsNw.meCXJgOnncjLk7Jj_B uPnsWlyLoFgZCBYIi2glR0mE8GFNJ3dTIlNP_ai1kr9bSLqdWeiSbV7T_XnID0q4_v56x3K1dblT GgQIFMSLsBru3I4d4ZtNlxG6cih3ZneziqEsjmUqouOybdEr8hxgghwEMq4bh2Kg36SKQNY7IAVr WQHgcVoQhM19fwv.BS_F8IHVM5G2_KWvWAd5zi6ymPWq3bjC5Is12FgUSLb00BPuwb0NxEJFGPyO NVyT1pSmBgDm6zdq5mVQIeKlzTjnvBEJJf16um8wF2NJ.C03HKVgjPDYX9e5KxAxYIYhYN2yzo0Q 66X6kfAIfb3foHnGyfE0Hgly482VbO_Fqt_32c0qEj0Jt6..nQqRHajGHwCzfZ2_gQk4aoJgX0Nj i8c68tgaesCTIWyF_iI3uKB.GKjrcvQFkaUQC74bZO1GaTkUOU_1ovzSoF1ZWCBfKhq5V_3SaysO 0v2leecOgd2C.NFAOzEp1HBDZYxzESEdC8IIuefcZ2wrGgQI7u4K3EPgZIm8v4LASln1Ws6KXIEb 73jVF5PXFXZhAu8Vv6O0z3yGrMeJshkCyA6boM5z2PB0lpBs89LNv_PPZRRS5ENv1eVxe9hzPWy0 Cr.OKJ2qfJHpT1.ZnCTMIzQcRGQMMQKQ4RLzAKLdpffm9eoQSExYgZ6glK4h34qhov3AjJS0Vj1k ED9HEbyjwczAXEGYL92Osp84F26m94CH.x5aYnERQQeEcz_I7XchX07QlkrQtQ2Gzv9C.qfijZ_V dyJskQeuNYgTcuHL4YPhBwNXVSPpQOCSvdDavCEyDrEXCZydGKNDrawKH7H4e3KInN0P33sfyUkD 02uo1ZfwK2lR3jhvOxsY6_tImkMywsfUHIkS2wklM5VSYnP_9g_Bfh06UTBccAGO5R3jEP2OJSZY a_mBRXMgWhxeufdXMGJjFZpd0gQhYZtseBMY.nDt162IfWGI.W2nbLGp.XRRYGaXcom7dnXnbxa8 7hGsPedmIJxOHYDisgPcf4KgcyTsW3VoRe3jPMhzBrz6DFXkBGlm8uRChqSoXYjp9UNo9ToIaVNa YZtaqjAhUqHgiQE_.ihO5z7EKE71CTveFn1zR2UVglXXbzvn8hg2umPJLv605Niv2EuvE_GonoaP WVSZfZHAaNPBkYxTrZHIu9drPDw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 18:51:39 +0000 Received: by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 09843984940cb9e67b7a3c1c881208f4; Tue, 10 Mar 2020 18:51:38 +0000 (UTC) From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 11:51:36 -0700 In-Reply-To: <20200302171904.01B97F406D7@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org, Shelley To: RFC Errata System References: <20200302171904.01B97F406D7@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:51:42 -0000 --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 VERIFIED This feels like a bit of a =E2=80=98nit=E2=80=99. Note that the examples = are not normative and it is allowed that the schema may be set to = caseExact false. I am ok with the correction going in or staying the same. Phil Hunt phil.hunt@yahoo.com > On Mar 2, 2020, at 9:19 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6001 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page = representing the User's online profile.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' = resource to which the user belongs.", > "required" : false, > "caseExact" : false, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, >=20 > Corrected Text > -------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page = representing the User's online profile.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' = resource to which the user belongs.", > "required" : false, > "caseExact" : true, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, >=20 > Notes > ----- > Section 2.3.7 indicates that "A reference is case exact." Section = 8.7.1 defines a number of "reference" attributes that incorrectly have = the "caseExact" characteristic set to "false"; these should instead be = "true." >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 VERIFIED

This feels like a bit of a =E2=80=98nit=E2=80=99. Note that = the examples are not normative and it is allowed that the schema may be = set to caseExact false.

I am ok with the correction going in or staying the = same.

Phil Hunt



On Mar 2, 2020, at 9:19 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6001
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "profileUrl",
       "type" : = "reference",
=        "referenceTypes" : = ["external"],
=        "multiValued" : false,
       "description" : "A = fully qualified URL pointing to a page representing the User's online = profile.",
=        "required" : false,
       "caseExact" : = false,
=        "mutability" : "readWrite",
       "returned" : = "default",
=        "uniqueness" : "none"
     },


     {
=        "name" : "photos",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : = "URLs of photos of the User.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "reference",
=            "referen= ceTypes" : ["external"],
=            "multiVa= lued" : false,
=            "descrip= tion" : "URL of a photo of the User.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "readWrite",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },

=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI of the corresponding 'Group' resource to which the user = belongs.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "readOnly",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
Corrected Text
--------------
=      {
=        "name" : "profileUrl",
       "type" : = "reference",
=        "referenceTypes" : = ["external"],
=        "multiValued" : false,
       "description" : "A = fully qualified URL pointing to a page representing the User's online = profile.",
=        "required" : false,
       "caseExact" : = true,
=        "mutability" : "readWrite",
       "returned" : = "default",
=        "uniqueness" : "none"
     },


     {
=        "name" : "photos",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : = "URLs of photos of the User.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "reference",
=            "referen= ceTypes" : ["external"],
=            "multiVa= lued" : false,
=            "descrip= tion" : "URL of a photo of the User.",
=            "require= d" : false,
=            "caseExa= ct" : true,
=            "mutabil= ity" : "readWrite",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },

=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI of the corresponding 'Group' resource to which the user = belongs.",
=            "require= d" : false,
=            "caseExa= ct" : true,
=            "mutabil= ity" : "readOnly",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
Notes
-----
Section 2.3.7 = indicates that "A reference is case exact." Section 8.7.1 defines a = number of "reference" attributes that incorrectly have the "caseExact" = characteristic set to "false"; these should instead be "true."

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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

= --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084-- From nobody Tue Mar 10 11:51:47 2020 Return-Path: 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 3382E3A085A for ; Tue, 10 Mar 2020 11:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 qCgWYbHTULhu for ; Tue, 10 Mar 2020 11:51:40 -0700 (PDT) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803AB3A085B for ; Tue, 10 Mar 2020 11:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583866299; bh=6yLM/Pe6a0TXLbtD7ojwmDvzrm2jUUcogJSK02i0YKc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=b60usJ/Im46BZNGbd67GNaJsLlAXJgfkayhMGGooK3jmQv9tmPCYRa+MncYVRPnf48+JbwIG3s3ur0ox5yV9yWo4Gca5n/Yv6NmknWJrHP3Z+mIiBnyZkJqRA//OsuwAdNQ6HcTc0u0sLpehrsttct2DQ4j4BdMR5Rkm9t1pbB8EsacpvxZgQMdm3ChAs+X8SXgP2D0dox41x2bdREgfiTON1QVDLRf2IWdIAC4xGC8DQrh5nyj0N6zr0txar0610T6g0nS11GTXFlDqUbFYMIkHy+KXQIpR2kewSaCniM1q17jejC82QsSTaHTIFQMFvNAbuDW3ETt+jHdFylMk+Q== X-YMail-OSG: D1VpAnQVM1lRvqM_5sIg44XkFgzXGQjqbmw.AjNgu5zEQ3PhQqMYiIXwYI2tApe fXNAjdZyf3qvAvSEIr_GxGbcqLmRM4GuARyzKuPz2pnnTAMCIErHSc0NtROvYUi3M7PL2CEAKCH6 JHSNr7xqXhyJN6Wsot4cymKvXY96Lr4WYFr6HqXoWWvEH6IlmnylHa910WdSaX7wyJw0yweae.Ah Ybw67eIugKkHffzf9iqweXKxjdTwRTMDEIsGUyPBj.MWkpOouYrq6fsNw.meCXJgOnncjLk7Jj_B uPnsWlyLoFgZCBYIi2glR0mE8GFNJ3dTIlNP_ai1kr9bSLqdWeiSbV7T_XnID0q4_v56x3K1dblT GgQIFMSLsBru3I4d4ZtNlxG6cih3ZneziqEsjmUqouOybdEr8hxgghwEMq4bh2Kg36SKQNY7IAVr WQHgcVoQhM19fwv.BS_F8IHVM5G2_KWvWAd5zi6ymPWq3bjC5Is12FgUSLb00BPuwb0NxEJFGPyO NVyT1pSmBgDm6zdq5mVQIeKlzTjnvBEJJf16um8wF2NJ.C03HKVgjPDYX9e5KxAxYIYhYN2yzo0Q 66X6kfAIfb3foHnGyfE0Hgly482VbO_Fqt_32c0qEj0Jt6..nQqRHajGHwCzfZ2_gQk4aoJgX0Nj i8c68tgaesCTIWyF_iI3uKB.GKjrcvQFkaUQC74bZO1GaTkUOU_1ovzSoF1ZWCBfKhq5V_3SaysO 0v2leecOgd2C.NFAOzEp1HBDZYxzESEdC8IIuefcZ2wrGgQI7u4K3EPgZIm8v4LASln1Ws6KXIEb 73jVF5PXFXZhAu8Vv6O0z3yGrMeJshkCyA6boM5z2PB0lpBs89LNv_PPZRRS5ENv1eVxe9hzPWy0 Cr.OKJ2qfJHpT1.ZnCTMIzQcRGQMMQKQ4RLzAKLdpffm9eoQSExYgZ6glK4h34qhov3AjJS0Vj1k ED9HEbyjwczAXEGYL92Osp84F26m94CH.x5aYnERQQeEcz_I7XchX07QlkrQtQ2Gzv9C.qfijZ_V dyJskQeuNYgTcuHL4YPhBwNXVSPpQOCSvdDavCEyDrEXCZydGKNDrawKH7H4e3KInN0P33sfyUkD 02uo1ZfwK2lR3jhvOxsY6_tImkMywsfUHIkS2wklM5VSYnP_9g_Bfh06UTBccAGO5R3jEP2OJSZY a_mBRXMgWhxeufdXMGJjFZpd0gQhYZtseBMY.nDt162IfWGI.W2nbLGp.XRRYGaXcom7dnXnbxa8 7hGsPedmIJxOHYDisgPcf4KgcyTsW3VoRe3jPMhzBrz6DFXkBGlm8uRChqSoXYjp9UNo9ToIaVNa YZtaqjAhUqHgiQE_.ihO5z7EKE71CTveFn1zR2UVglXXbzvn8hg2umPJLv605Niv2EuvE_GonoaP WVSZfZHAaNPBkYxTrZHIu9drPDw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 18:51:39 +0000 Received: by smtp429.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 09843984940cb9e67b7a3c1c881208f4; Tue, 10 Mar 2020 18:51:38 +0000 (UTC) From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 11:51:36 -0700 In-Reply-To: <20200302171904.01B97F406D7@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org, Shelley To: RFC Errata System References: <20200302171904.01B97F406D7@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 18:51:42 -0000 --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 VERIFIED This feels like a bit of a =E2=80=98nit=E2=80=99. Note that the examples = are not normative and it is allowed that the schema may be set to = caseExact false. I am ok with the correction going in or staying the same. Phil Hunt phil.hunt@yahoo.com > On Mar 2, 2020, at 9:19 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6001 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page = representing the User's online profile.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' = resource to which the user belongs.", > "required" : false, > "caseExact" : false, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, >=20 > Corrected Text > -------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page = representing the User's online profile.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, >=20 >=20 > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' = resource to which the user belongs.", > "required" : false, > "caseExact" : true, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, >=20 > Notes > ----- > Section 2.3.7 indicates that "A reference is case exact." Section = 8.7.1 defines a number of "reference" attributes that incorrectly have = the "caseExact" characteristic set to "false"; these should instead be = "true." >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 VERIFIED

This feels like a bit of a =E2=80=98nit=E2=80=99. Note that = the examples are not normative and it is allowed that the schema may be = set to caseExact false.

I am ok with the correction going in or staying the = same.

Phil Hunt



On Mar 2, 2020, at 9:19 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6001
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "profileUrl",
       "type" : = "reference",
=        "referenceTypes" : = ["external"],
=        "multiValued" : false,
       "description" : "A = fully qualified URL pointing to a page representing the User's online = profile.",
=        "required" : false,
       "caseExact" : = false,
=        "mutability" : "readWrite",
       "returned" : = "default",
=        "uniqueness" : "none"
     },


     {
=        "name" : "photos",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : = "URLs of photos of the User.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "reference",
=            "referen= ceTypes" : ["external"],
=            "multiVa= lued" : false,
=            "descrip= tion" : "URL of a photo of the User.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "readWrite",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },

=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI of the corresponding 'Group' resource to which the user = belongs.",
=            "require= d" : false,
=            "caseExa= ct" : false,
=            "mutabil= ity" : "readOnly",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
Corrected Text
--------------
=      {
=        "name" : "profileUrl",
       "type" : = "reference",
=        "referenceTypes" : = ["external"],
=        "multiValued" : false,
       "description" : "A = fully qualified URL pointing to a page representing the User's online = profile.",
=        "required" : false,
       "caseExact" : = true,
=        "mutability" : "readWrite",
       "returned" : = "default",
=        "uniqueness" : "none"
     },


     {
=        "name" : "photos",
       "type" : = "complex",
=        "multiValued" : true,
       "description" : = "URLs of photos of the User.",
=        "required" : false,
       "subAttributes" : = [
=          {
=            "name" = : "value",
=            "type" = : "reference",
=            "referen= ceTypes" : ["external"],
=            "multiVa= lued" : false,
=            "descrip= tion" : "URL of a photo of the User.",
=            "require= d" : false,
=            "caseExa= ct" : true,
=            "mutabil= ity" : "readWrite",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },

=          {
=            "name" = : "$ref",
=            "type" = : "reference",
=            "referen= ceTypes" : [
=             &n= bsp;"User",
=             &n= bsp;"Group"
=            ],
=            "multiVa= lued" : false,
=            "descrip= tion" : "The URI of the corresponding 'Group' resource to which the user = belongs.",
=            "require= d" : false,
=            "caseExa= ct" : true,
=            "mutabil= ity" : "readOnly",
=            "returne= d" : "default",
=            "uniquen= ess" : "none"
=          },
Notes
-----
Section 2.3.7 = indicates that "A reference is case exact." Section 8.7.1 defines a = number of "reference" attributes that incorrectly have the "caseExact" = characteristic set to "false"; these should instead be "true."

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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

= --Apple-Mail=_B926DE2F-74C8-47C1-90A7-812FF9111084-- From nobody Tue Mar 10 13:00:47 2020 Return-Path: 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 D59933A0B31 for ; Tue, 10 Mar 2020 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dfLWVn7GZavk for ; Tue, 10 Mar 2020 13:00:36 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B983A0A2E for ; Tue, 10 Mar 2020 13:00:35 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id 7so9245634vsr.10 for ; Tue, 10 Mar 2020 13:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FdiBb3g8oFof0T+NT5YwW5IKZROKr3DTada6xk0humI=; b=i0CXT9EqwTQ2C9nivYJdKEzzQcWHJ5cT465itAqazkj3KYhpJHyU2UusLg3vFwPQKf 7fd20Vp65g5K1TPatoVKQBxmBV+0CZ8HVMNcjqcanxQEBJ3blVCCJw0F7eRTUvJTvvNj LkQKZ3O3ET8TOH1lnDohg/URDvy74X9LO+edfLVRGdb2tkqqkvC6W1euYByPje2GPlVz zmyrJ+DaeKD2PNZruHJ7YJ51PE/dFG7OGt+sVA1d1B/92IrcwtgKt3oOwEcRh3u9nAA4 2kAztfkSL38lQDGXei9BS1rTj/4DwHJlZJf3VFO0O+Jvkfb2HrXZPNwXWUPR/2iGcCSF rB6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FdiBb3g8oFof0T+NT5YwW5IKZROKr3DTada6xk0humI=; b=XrgdRJOSKwyDLrHBzZJ3Ammkl9XbOtkRxMr73jmhfqg7mjKyxDmTg6fqgnFtg3cEBw 2TzIEShg6hAKbYA9pgZjGqtZOlpRSVEVVrc/suJ9VfPxi82oQ3oVzgFIJXJNMiNS76h8 z+OiuqBJnJbTcDTSKiPbEUXtB9xKgQUq3XQsP3tMSEPhSreWvoMJF92HMIyVXfeJzRAg LQT76yPd41DhSAl0mSTCo7T3J7B8tBzLE6ggoln1+yqm2Mrr1yweqmJc3mK7HMQv96kt +22Ar07nzKjOMh7V24fjcLq6hzgJJylmvKOn2Q/Zdgy1m7My2zZDOiSpHv2YaCLC8Unz XZvA== X-Gm-Message-State: ANhLgQ08DDMW7hbNXYHGz38iIFjjMAwuSRBxZZkqrHdIdtR916CY+xPN eFdVQ7T/VToLz5du4F58qtcxzNNSGhdQMiMYhyc= X-Google-Smtp-Source: ADFU+vuva14MnFAX7lcKIjILlYw24SI7QNzugM3/iBgwqivVxYjgXQ7ZIn/iJikgfGKQBAt6F5gu53yIFoBEWDB96kA= X-Received: by 2002:a67:2dc5:: with SMTP id t188mr877175vst.3.1583870434877; Tue, 10 Mar 2020 13:00:34 -0700 (PDT) MIME-Version: 1.0 References: <20200302171904.01B97F406D7@rfc-editor.org> In-Reply-To: From: Shelley Date: Tue, 10 Mar 2020 15:00:23 -0500 Message-ID: To: Phil Hunt Cc: RFC Errata System , Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4246005a085928b" Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 20:00:44 -0000 --000000000000a4246005a085928b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > it is allowed that the schema may be set to caseExact false Is Section 2.3.7 not normative? If not, perhaps that section should not prescribe a caseExact characteristic for references at all then. On Tue, Mar 10, 2020 at 1:51 PM Phil Hunt wrote: > VERIFIED > > This feels like a bit of a =E2=80=98nit=E2=80=99. Note that the examples = are not normative > and it is allowed that the schema may be set to caseExact false. > > I am ok with the correction going in or staying the same. > > Phil Hunt > phil.hunt@yahoo.com > > > > On Mar 2, 2020, at 9:19 AM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6001 > > -------------------------------------- > Type: Technical > Reported by: Shelley Baker > > Section: 8.7.1 > > Original Text > ------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page > representing the User's online profile.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : false, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' resource > to which the user belongs.", > "required" : false, > "caseExact" : false, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, > > Corrected Text > -------------- > { > "name" : "profileUrl", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "A fully qualified URL pointing to a page > representing the User's online profile.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > { > "name" : "photos", > "type" : "complex", > "multiValued" : true, > "description" : "URLs of photos of the User.", > "required" : false, > "subAttributes" : [ > { > "name" : "value", > "type" : "reference", > "referenceTypes" : ["external"], > "multiValued" : false, > "description" : "URL of a photo of the User.", > "required" : false, > "caseExact" : true, > "mutability" : "readWrite", > "returned" : "default", > "uniqueness" : "none" > }, > > > { > "name" : "$ref", > "type" : "reference", > "referenceTypes" : [ > "User", > "Group" > ], > "multiValued" : false, > "description" : "The URI of the corresponding 'Group' resource > to which the user belongs.", > "required" : false, > "caseExact" : true, > "mutability" : "readOnly", > "returned" : "default", > "uniqueness" : "none" > }, > > Notes > ----- > Section 2.3.7 indicates that "A reference is case exact." Section 8.7.1 > defines a number of "reference" attributes that incorrectly have the > "caseExact" characteristic set to "false"; these should instead be "true.= " > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: Core > Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimo= re > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --000000000000a4246005a085928b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KIGl0IGlzIGFsbG93ZWQgdGhhdCB0aGUgc2NoZW1hIG1h eSBiZSBzZXQgdG8gY2FzZUV4YWN0IGZhbHNlDQoNCjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rp dj48ZGl2PklzIFNlY3Rpb24gMi4zLjcgbm90IG5vcm1hdGl2ZT8gSWYgbm90LCBwZXJoYXBzIHRo YXQgc2VjdGlvbiBzaG91bGQgbm90IHByZXNjcmliZSBhIGNhc2VFeGFjdCBjaGFyYWN0ZXJpc3Rp YyBmb3IgcmVmZXJlbmNlcyBhdCBhbGwgdGhlbi48L2Rpdj48ZGl2PiA8YnI+PC9kaXY+PC9kaXY+ PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxf YXR0ciI+T24gVHVlLCBNYXIgMTAsIDIwMjAgYXQgMTo1MSBQTSBQaGlsIEh1bnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpwaGlsLmh1bnRAeWFob28uY29tIj5waGlsLmh1bnRAeWFob28uY29tPC9hPiZn dDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVh ay13b3JkOyI+VkVSSUZJRUQ8ZGl2Pjxicj48L2Rpdj48ZGl2PlRoaXMgZmVlbHMgbGlrZSBhIGJp dCBvZiBhIOKAmG5pdOKAmS4gTm90ZSB0aGF0IHRoZSBleGFtcGxlcyBhcmUgbm90IG5vcm1hdGl2 ZSBhbmQgaXQgaXMgYWxsb3dlZCB0aGF0IHRoZSBzY2hlbWEgbWF5IGJlIHNldCB0byBjYXNlRXhh Y3QgZmFsc2UuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGFtIG9rIHdpdGggdGhlIGNvcnJl Y3Rpb24gZ29pbmcgaW4gb3Igc3RheWluZyB0aGUgc2FtZS48L2Rpdj48ZGl2Pjxicj48ZGl2Pg0K PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1z aXplOjEycHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQt d2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0 LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1z cGFjaW5nOjBweDt0ZXh0LWRlY29yYXRpb246bm9uZSI+UGhpbCBIdW50PC9kaXY+PGRpdiBzdHls ZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5v cm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDow cHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBw eDt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEB5YWhvby5j b20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAeWFob28uY29tPC9hPjwvZGl2PjxkaXYgc3R5 bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHg7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxicj48L2Rpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gTWFyIDIsIDIwMjAsIGF0IDk6MTkgQU0s IFJGQyBFcnJhdGEgU3lzdGVtICZsdDs8YSBocmVmPSJtYWlsdG86cmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc8L2E+Jmd0 OyB3cm90ZTo8L2Rpdj48YnI+PGRpdj48ZGl2PlRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBo YXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzc2NDMsPGJyPiZxdW90O1N5c3RlbSBmb3IgQ3Jvc3Mt ZG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQ6IENvcmUgU2NoZW1hJnF1b3Q7Ljxicj48YnI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+WW91IG1heSByZXZpZXcgdGhl IHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2VycmF0YS9laWQ2MDAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvZXJyYXRhL2VpZDYwMDE8L2E+PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj5UeXBlOiBUZWNobmljYWw8YnI+UmVwb3J0ZWQgYnk6IFNoZWxsZXkg QmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5kb21zaGVsbGV5QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnJhbmRvbXNoZWxsZXlAZ21haWwuY29tPC9hPiZndDs8YnI+PGJyPlNlY3Rpb246 IDguNy4xPGJyPjxicj5PcmlnaW5hbCBUZXh0PGJyPi0tLS0tLS0tLS0tLS08YnI+IMKgwqDCoMKg wqB7PGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDtwcm9maWxlVXJs JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7IDogJnF1b3Q7cmVmZXJl bmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtyZWZlcmVuY2VUeXBlcyZxdW90OyA6 IFsmcXVvdDtleHRlcm5hbCZxdW90O10sPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O211bHRpVmFs dWVkJnF1b3Q7IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O2Rlc2NyaXB0aW9uJnF1 b3Q7IDogJnF1b3Q7QSBmdWxseSBxdWFsaWZpZWQgVVJMIHBvaW50aW5nIHRvIGEgcGFnZSByZXBy ZXNlbnRpbmcgdGhlIFVzZXImIzM5O3Mgb25saW5lIHByb2ZpbGUuJnF1b3Q7LDxicj4gwqDCoMKg wqDCoMKgwqAmcXVvdDtyZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqAm cXVvdDtjYXNlRXhhY3QmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXV0 YWJpbGl0eSZxdW90OyA6ICZxdW90O3JlYWRXcml0ZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKg JnF1b3Q7cmV0dXJuZWQmcXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxicj4gwqDCoMKgwqDC oMKgwqAmcXVvdDt1bmlxdWVuZXNzJnF1b3Q7IDogJnF1b3Q7bm9uZSZxdW90Ozxicj4gwqDCoMKg wqDCoH0sPGJyPjxicj48YnI+IMKgwqDCoMKgwqB7PGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O25h bWUmcXVvdDsgOiAmcXVvdDtwaG90b3MmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O3R5 cGUmcXVvdDsgOiAmcXVvdDtjb21wbGV4JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtt dWx0aVZhbHVlZCZxdW90OyA6IHRydWUsPGJyPiDCoMKgwqDCoMKgwqDCoCZxdW90O2Rlc2NyaXB0 aW9uJnF1b3Q7IDogJnF1b3Q7VVJMcyBvZiBwaG90b3Mgb2YgdGhlIFVzZXIuJnF1b3Q7LDxicj4g wqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDC oMKgwqAmcXVvdDtzdWJBdHRyaWJ1dGVzJnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDCoMKg ezxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDt2YWx1 ZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7IDogJnF1 b3Q7cmVmZXJlbmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3JlZmVy ZW5jZVR5cGVzJnF1b3Q7IDogWyZxdW90O2V4dGVybmFsJnF1b3Q7XSw8YnI+IMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAmcXVvdDttdWx0aVZhbHVlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCZxdW90O2Rlc2NyaXB0aW9uJnF1b3Q7IDogJnF1b3Q7VVJMIG9mIGEgcGhv dG8gb2YgdGhlIFVzZXIuJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3Jl cXVpcmVkJnF1b3Q7IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7Y2Fz ZUV4YWN0JnF1b3Q7IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXV0 YWJpbGl0eSZxdW90OyA6ICZxdW90O3JlYWRXcml0ZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAmcXVvdDtyZXR1cm5lZCZxdW90OyA6ICZxdW90O2RlZmF1bHQmcXVvdDssPGJyPiDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7dW5pcXVlbmVzcyZxdW90OyA6ICZxdW90O25vbmUm cXVvdDs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoH0sPGJyPjxicj48YnI+IMKgwqDCoMKgwqDCoMKg wqDCoHs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1lJnF1b3Q7IDogJnF1b3Q7 JHJlZiZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt0eXBlJnF1b3Q7IDog JnF1b3Q7cmVmZXJlbmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3Jl ZmVyZW5jZVR5cGVzJnF1b3Q7IDogWzxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVv dDtVc2VyJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtHcm91cCZx dW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoF0sPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgJnF1b3Q7bXVsdGlWYWx1ZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAmcXVvdDtkZXNjcmlwdGlvbiZxdW90OyA6ICZxdW90O1RoZSBVUkkgb2YgdGhlIGNvcnJl c3BvbmRpbmcgJiMzOTtHcm91cCYjMzk7IHJlc291cmNlIHRvIHdoaWNoIHRoZSB1c2VyIGJlbG9u Z3MuJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3JlcXVpcmVkJnF1b3Q7 IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7Y2FzZUV4YWN0JnF1b3Q7 IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7bXV0YWJpbGl0eSZxdW90 OyA6ICZxdW90O3JlYWRPbmx5JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90 O3JldHVybmVkJnF1b3Q7IDogJnF1b3Q7ZGVmYXVsdCZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAmcXVvdDt1bmlxdWVuZXNzJnF1b3Q7IDogJnF1b3Q7bm9uZSZxdW90Ozxicj4gwqDC oMKgwqDCoMKgwqDCoMKgfSw8YnI+PGJyPkNvcnJlY3RlZCBUZXh0PGJyPi0tLS0tLS0tLS0tLS0t PGJyPiDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtuYW1lJnF1b3Q7IDogJnF1 b3Q7cHJvZmlsZVVybCZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7dHlwZSZxdW90OyA6 ICZxdW90O3JlZmVyZW5jZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmVmZXJlbmNl VHlwZXMmcXVvdDsgOiBbJnF1b3Q7ZXh0ZXJuYWwmcXVvdDtdLDxicj4gwqDCoMKgwqDCoMKgwqAm cXVvdDttdWx0aVZhbHVlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtk ZXNjcmlwdGlvbiZxdW90OyA6ICZxdW90O0EgZnVsbHkgcXVhbGlmaWVkIFVSTCBwb2ludGluZyB0 byBhIHBhZ2UgcmVwcmVzZW50aW5nIHRoZSBVc2VyJiMzOTtzIG9ubGluZSBwcm9maWxlLiZxdW90 Oyw8YnI+IMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmVxdWlyZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKg wqDCoMKgwqDCoMKgJnF1b3Q7Y2FzZUV4YWN0JnF1b3Q7IDogdHJ1ZSw8YnI+IMKgwqDCoMKgwqDC oMKgJnF1b3Q7bXV0YWJpbGl0eSZxdW90OyA6ICZxdW90O3JlYWRXcml0ZSZxdW90Oyw8YnI+IMKg wqDCoMKgwqDCoMKgJnF1b3Q7cmV0dXJuZWQmcXVvdDsgOiAmcXVvdDtkZWZhdWx0JnF1b3Q7LDxi cj4gwqDCoMKgwqDCoMKgwqAmcXVvdDt1bmlxdWVuZXNzJnF1b3Q7IDogJnF1b3Q7bm9uZSZxdW90 Ozxicj4gwqDCoMKgwqDCoH0sPGJyPjxicj48YnI+IMKgwqDCoMKgwqB7PGJyPiDCoMKgwqDCoMKg wqDCoCZxdW90O25hbWUmcXVvdDsgOiAmcXVvdDtwaG90b3MmcXVvdDssPGJyPiDCoMKgwqDCoMKg wqDCoCZxdW90O3R5cGUmcXVvdDsgOiAmcXVvdDtjb21wbGV4JnF1b3Q7LDxicj4gwqDCoMKgwqDC oMKgwqAmcXVvdDttdWx0aVZhbHVlZCZxdW90OyA6IHRydWUsPGJyPiDCoMKgwqDCoMKgwqDCoCZx dW90O2Rlc2NyaXB0aW9uJnF1b3Q7IDogJnF1b3Q7VVJMcyBvZiBwaG90b3Mgb2YgdGhlIFVzZXIu JnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtyZXF1aXJlZCZxdW90OyA6IGZhbHNlLDxi cj4gwqDCoMKgwqDCoMKgwqAmcXVvdDtzdWJBdHRyaWJ1dGVzJnF1b3Q7IDogWzxicj4gwqDCoMKg wqDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVvdDsg OiAmcXVvdDt2YWx1ZSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt0eXBl JnF1b3Q7IDogJnF1b3Q7cmVmZXJlbmNlJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCZxdW90O3JlZmVyZW5jZVR5cGVzJnF1b3Q7IDogWyZxdW90O2V4dGVybmFsJnF1b3Q7XSw8YnI+ IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDttdWx0aVZhbHVlZCZxdW90OyA6IGZhbHNlLDxi cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O2Rlc2NyaXB0aW9uJnF1b3Q7IDogJnF1b3Q7 VVJMIG9mIGEgcGhvdG8gb2YgdGhlIFVzZXIuJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCZxdW90O3JlcXVpcmVkJnF1b3Q7IDogZmFsc2UsPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgJnF1b3Q7Y2FzZUV4YWN0JnF1b3Q7IDogdHJ1ZSw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAmcXVvdDttdXRhYmlsaXR5JnF1b3Q7IDogJnF1b3Q7cmVhZFdyaXRlJnF1b3Q7LDxicj4gwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3JldHVybmVkJnF1b3Q7IDogJnF1b3Q7ZGVmYXVsdCZx dW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDt1bmlxdWVuZXNzJnF1b3Q7IDog JnF1b3Q7bm9uZSZxdW90Ozxicj4gwqDCoMKgwqDCoMKgwqDCoMKgfSw8YnI+PGJyPjxicj4gwqDC oMKgwqDCoMKgwqDCoMKgezxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O25hbWUmcXVv dDsgOiAmcXVvdDskcmVmJnF1b3Q7LDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O3R5 cGUmcXVvdDsgOiAmcXVvdDtyZWZlcmVuY2UmcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgJnF1b3Q7cmVmZXJlbmNlVHlwZXMmcXVvdDsgOiBbPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCZxdW90O1VzZXImcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZx dW90O0dyb3VwJnF1b3Q7PGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgXSw8YnI+IMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAmcXVvdDttdWx0aVZhbHVlZCZxdW90OyA6IGZhbHNlLDxicj4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCZxdW90O2Rlc2NyaXB0aW9uJnF1b3Q7IDogJnF1b3Q7VGhlIFVSSSBv ZiB0aGUgY29ycmVzcG9uZGluZyAmIzM5O0dyb3VwJiMzOTsgcmVzb3VyY2UgdG8gd2hpY2ggdGhl IHVzZXIgYmVsb25ncy4mcXVvdDssPGJyPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7cmVx dWlyZWQmcXVvdDsgOiBmYWxzZSw8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAmcXVvdDtjYXNl RXhhY3QmcXVvdDsgOiB0cnVlLDxicj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCZxdW90O211dGFi aWxpdHkmcXVvdDsgOiAmcXVvdDtyZWFkT25seSZxdW90Oyw8YnI+IMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAmcXVvdDtyZXR1cm5lZCZxdW90OyA6ICZxdW90O2RlZmF1bHQmcXVvdDssPGJyPiDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgJnF1b3Q7dW5pcXVlbmVzcyZxdW90OyA6ICZxdW90O25vbmUmcXVv dDs8YnI+IMKgwqDCoMKgwqDCoMKgwqDCoH0sPGJyPjxicj5Ob3Rlczxicj4tLS0tLTxicj5TZWN0 aW9uIDIuMy43IGluZGljYXRlcyB0aGF0ICZxdW90O0EgcmVmZXJlbmNlIGlzIGNhc2UgZXhhY3Qu JnF1b3Q7IFNlY3Rpb24gOC43LjEgZGVmaW5lcyBhIG51bWJlciBvZiAmcXVvdDtyZWZlcmVuY2Um cXVvdDsgYXR0cmlidXRlcyB0aGF0IGluY29ycmVjdGx5IGhhdmUgdGhlICZxdW90O2Nhc2VFeGFj dCZxdW90OyBjaGFyYWN0ZXJpc3RpYyBzZXQgdG8gJnF1b3Q7ZmFsc2UmcXVvdDs7IHRoZXNlIHNo b3VsZCBpbnN0ZWFkIGJlICZxdW90O3RydWUuJnF1b3Q7PGJyPjxicj5JbnN0cnVjdGlvbnM6PGJy Pi0tLS0tLS0tLS0tLS08YnI+VGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1 b3Q7UmVwb3J0ZWQmcXVvdDsuIElmIG5lY2Vzc2FyeSwgcGxlYXNlPGJyPnVzZSAmcXVvdDtSZXBs eSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcjxi cj5yZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFy dHkgwqA8YnI+Y2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVw b3J0LCBpZiBuZWNlc3NhcnkuIDxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+UkZDNzY0MyAoZHJhZnQtaWV0Zi1zY2ltLWNvcmUtc2NoZW1hLTIyKTxicj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj5UaXRsZSDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgOiBTeXN0ZW0gZm9yIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5h Z2VtZW50OiBDb3JlIFNjaGVtYTxicj5QdWJsaWNhdGlvbiBEYXRlIMKgwqDCoDogU2VwdGVtYmVy IDIwMTU8YnI+QXV0aG9yKHMpIMKgwqDCoMKgwqDCoMKgwqDCoMKgOiBQLiBIdW50LCBFZC4sIEsu IEdyaXp6bGUsIEUuIFdhaGxzdHJvZW0sIEMuIE1vcnRpbW9yZTxicj5DYXRlZ29yeSDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgOiBQUk9QT1NFRCBTVEFOREFSRDxicj5Tb3VyY2UgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqA6IFN5c3RlbSBmb3IgQ3Jvc3MtZG9tYWluIElkZW50aXR5IE1hbmFnZW1l bnQ8YnI+QXJlYSDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA6IEFwcGxpY2F0aW9ucyBh bmQgUmVhbC1UaW1lPGJyPlN0cmVhbSDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDogSUVURjxi cj5WZXJpZnlpbmcgUGFydHkgwqDCoMKgwqA6IElFU0c8YnI+PGJyPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnNjaW0gbWFpbGluZyBsaXN0PGJyPjxh IGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9y ZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z Y2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zY2ltPC9hPjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48L2Rpdj4NCg== --000000000000a4246005a085928b-- From nobody Tue Mar 10 14:33:23 2020 Return-Path: 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 01A123A0DF3 for ; Tue, 10 Mar 2020 14:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 88bOSWwMtJ-Y for ; Tue, 10 Mar 2020 14:33:19 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767623A0DFB for ; Tue, 10 Mar 2020 14:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583875998; bh=MQqiqMCxZEfnNEguK+Uz1jfLKo5zZtdAtyv9JeCoBVI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=W4LyrZ/ZgIbtUUyUxsmsCbn4wJZrCu7/hFlvcEBE4NbOZAcAp5PDDkyRT/8gdSc6NNbCVAxe+CwXJfTVAvpE041wABHPXpVJPZNDS1hm2IjeHOudWXMuvl4QaPIWTSsbbVTv1lvWd6t+KUqhdYtGGkE0g9pCa452F919DjMGPrr4AEu86PGj7WeC7tF460f4seVJq+YLMLRjYpLfxzBkO74nzmUMzuqvK3hKvU7aX/JZ6ATJipftrZmoMcD+uZMbquCMoPwTil8ugTvkjxLp1rwMTryu8c6gYiSYUD/5KwTFU6nmAv0CaxBIfZHcH6dl1KXp1eIsfhfnvIo+Yn/WhQ== X-YMail-OSG: K4JhmlcVM1lb30Sf5MujFHpc0y19D_FHoCq9_KO8sBFqeFjoX9rgbCb67q5HAzU _Bps8E9S.CnUxJlwq6MFOYR0JhF5.cObicJW9nBu1YGRKwMTNkXt5fjfraJpueQGAH0xJQSRZF2t d_S2i5If2h2_u.PIPkb21eeLfSnO5gNq6qNltwCnyxpsifrY0F7AOJfmqYr5u5kOj9Q3aPe1lNNg AMso6FTi72CE1rJ04wA0wSpSrV.pW9fkN5lTOLdzq5wOYBdSw6mlTP5tjA7A4DjZ8VhaCoG.T3GN XDvFtU3XqqYLQn9CMzvEXC9dMIPvzs5F5jCVkJproQUrfdWn8cku115UXC3u4ItIfz1w2gVdd3RN fvm.7ah4gGrhnMESXLH8Huog3Hu2NaWEPHewnKfdubg1FcRvATmbGXW3p6QMb6u7BX7X6plMHIgf f8YR.biDz0WoLaD9IhVf30gfG0cSE3g0.HzVWYxHBzTT2F_9kxiD.TU5OhpPx18PwMKKSm52_Z3s F.O3JFwrASoKvLzGqZwlkZh6.61PgAERf1O8YZMEMaQopSjmZwXxiYywdRUC_2FbUFXuo8PSCYyR d0YsZ5Y7FvIAqnrcbWj0vgh1TR3U7kb2.w_0oAOhFqjlvjYhC9qAjqORUKmaAWn4yZdi9fQkH2h3 h_h_N88Ky5G.qAzvFtGZk8zejjd2K9ZAkWc5S.aG5oB_8_UgeNi6ouamOVJ8gJ5vPM4bZXDV6YfF QMaOGiHwa1sH9zu51iW5YCA4E8Ulky913BN0WXPSFyxOeYpHE8u4kycItpWXBp0nLUf1jJ_k5I3R o1.t2jKZxD_1Bd9JRVcn8zw4NuvkpVRoUNKEjkrn_mBLuxlBaJGr5jCPg.vFtJAR3BYUeTBJK7gU f9GlBjpdlC5LIeg5f6keJJXhqtyicOZYbC9oUKmoXByEeVHDLoYHyEtqnwhloYBvs7bGDh1f9M2Y q_6RJ0dzr.4IYouxVgfJluSe_pQn_UH3W.k_zP9.n4S43Hd1qRfVeSF7odnMymeJOWc4BiAtm_TH oAIYN4mjnswjfW3Jkr4KsxyMssuyBXM7Oy98gjKPEiHMUz6blx8Mh8r9HEvAlpjZBG4aPxvqqQ.B LzPLeGmKp8KdPKo0buhVIUUX34Hb8LiUliSiUo69OOo8G_5OfZieFvAEZKONW4KeQwTJgKgmPtML SGLQiKipc3r0v5Jsl3wFvDc0ltA9lkz2ZtrT3nx76C_MgArAx7DXrbX2a3ZTU1A3nUt5f6zyDRlR msfhne72r6IOUJi2XOV0Gwh_6EelTT6eJx02DW7fCf2C40Nc1OpW422lqfphDVgY6DflqX2uusnb edP3sv1a_pnhEbGEE4JWOQ_7guuChrr3QNlBgKfUgraH.2i3.XitVKK5yyRMMPz5868g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 21:33:18 +0000 Received: by smtp421.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 11d75ad166e748449ac4d2ffe3e0d935; Tue, 10 Mar 2020 21:33:15 +0000 (UTC) From: Phil Hunt Message-Id: <4358B9B5-9B09-4EE0-956D-FA27F9A74CBB@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 14:33:13 -0700 In-Reply-To: <20200226191636.EAB5CF40710@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org, Shelley To: RFC Errata System References: <20200226191636.EAB5CF40710@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (5990) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:33:22 -0000 --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii VERIFIED Phil Hunt phil.hunt@yahoo.com > On Feb 26, 2020, at 11:16 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5990 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.2 >=20 > Original Text > ------------- > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ], >=20 > Corrected Text > -------------- > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "US", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "US", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ], >=20 > Notes > ----- > Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format = for the "country" attribute; however, sections 8.2 and 8.3 incorrectly = specify "USA" instead of "US" for the "country" attribute. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii VERIFIED

Phil Hunt



On Feb 26, 2020, at 11:16 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid5990
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.2

Original Text
-------------
 "addresses": [
   {
=      "type": "work",
=      "streetAddress": "100 Universal City = Plaza",
     "locality": = "Hollywood",
     "region": = "CA",
     "postalCode": = "91608",
     "country": = "USA",
     "formatted": "100 = Universal City Plaza\nHollywood, CA 91608 USA",
=      "primary": true
=    },
   {
=      "type": "home",
=      "streetAddress": "456 Hollywood Blvd",
     "locality": "Hollywood",
     "region": "CA",
=      "postalCode": "91608",
=      "country": "USA",
=      "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 USA"
   }
 ],

Corrected Text
--------------
 "addresses": [
   {
=      "type": "work",
=      "streetAddress": "100 Universal City = Plaza",
     "locality": = "Hollywood",
     "region": = "CA",
     "postalCode": = "91608",
     "country": = "US",
     "formatted": "100 = Universal City Plaza\nHollywood, CA 91608 USA",
=      "primary": true
=    },
   {
=      "type": "home",
=      "streetAddress": "456 Hollywood Blvd",
     "locality": "Hollywood",
     "region": "CA",
=      "postalCode": "91608",
=      "country": "US",
=      "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 USA"
   }
 ],

Notes
-----
Section 4.1.2 requires the use of the ISO = 3166-1 "alpha-2" code format for the "country" attribute; however, = sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the = "country" attribute.

Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to = discuss whether it should be verified or
rejected. When a = decision is reached, the verifying party  
can log in = to change the status and edit the report, if necessary.
--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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

= --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6-- From nobody Tue Mar 10 14:33:28 2020 Return-Path: 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 5E61E3A0DF7 for ; Tue, 10 Mar 2020 14:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 wG_IhWbp6EsJ for ; Tue, 10 Mar 2020 14:33:19 -0700 (PDT) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FDB73A0DF8 for ; Tue, 10 Mar 2020 14:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583875998; bh=MQqiqMCxZEfnNEguK+Uz1jfLKo5zZtdAtyv9JeCoBVI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=W4LyrZ/ZgIbtUUyUxsmsCbn4wJZrCu7/hFlvcEBE4NbOZAcAp5PDDkyRT/8gdSc6NNbCVAxe+CwXJfTVAvpE041wABHPXpVJPZNDS1hm2IjeHOudWXMuvl4QaPIWTSsbbVTv1lvWd6t+KUqhdYtGGkE0g9pCa452F919DjMGPrr4AEu86PGj7WeC7tF460f4seVJq+YLMLRjYpLfxzBkO74nzmUMzuqvK3hKvU7aX/JZ6ATJipftrZmoMcD+uZMbquCMoPwTil8ugTvkjxLp1rwMTryu8c6gYiSYUD/5KwTFU6nmAv0CaxBIfZHcH6dl1KXp1eIsfhfnvIo+Yn/WhQ== X-YMail-OSG: K4JhmlcVM1lb30Sf5MujFHpc0y19D_FHoCq9_KO8sBFqeFjoX9rgbCb67q5HAzU _Bps8E9S.CnUxJlwq6MFOYR0JhF5.cObicJW9nBu1YGRKwMTNkXt5fjfraJpueQGAH0xJQSRZF2t d_S2i5If2h2_u.PIPkb21eeLfSnO5gNq6qNltwCnyxpsifrY0F7AOJfmqYr5u5kOj9Q3aPe1lNNg AMso6FTi72CE1rJ04wA0wSpSrV.pW9fkN5lTOLdzq5wOYBdSw6mlTP5tjA7A4DjZ8VhaCoG.T3GN XDvFtU3XqqYLQn9CMzvEXC9dMIPvzs5F5jCVkJproQUrfdWn8cku115UXC3u4ItIfz1w2gVdd3RN fvm.7ah4gGrhnMESXLH8Huog3Hu2NaWEPHewnKfdubg1FcRvATmbGXW3p6QMb6u7BX7X6plMHIgf f8YR.biDz0WoLaD9IhVf30gfG0cSE3g0.HzVWYxHBzTT2F_9kxiD.TU5OhpPx18PwMKKSm52_Z3s F.O3JFwrASoKvLzGqZwlkZh6.61PgAERf1O8YZMEMaQopSjmZwXxiYywdRUC_2FbUFXuo8PSCYyR d0YsZ5Y7FvIAqnrcbWj0vgh1TR3U7kb2.w_0oAOhFqjlvjYhC9qAjqORUKmaAWn4yZdi9fQkH2h3 h_h_N88Ky5G.qAzvFtGZk8zejjd2K9ZAkWc5S.aG5oB_8_UgeNi6ouamOVJ8gJ5vPM4bZXDV6YfF QMaOGiHwa1sH9zu51iW5YCA4E8Ulky913BN0WXPSFyxOeYpHE8u4kycItpWXBp0nLUf1jJ_k5I3R o1.t2jKZxD_1Bd9JRVcn8zw4NuvkpVRoUNKEjkrn_mBLuxlBaJGr5jCPg.vFtJAR3BYUeTBJK7gU f9GlBjpdlC5LIeg5f6keJJXhqtyicOZYbC9oUKmoXByEeVHDLoYHyEtqnwhloYBvs7bGDh1f9M2Y q_6RJ0dzr.4IYouxVgfJluSe_pQn_UH3W.k_zP9.n4S43Hd1qRfVeSF7odnMymeJOWc4BiAtm_TH oAIYN4mjnswjfW3Jkr4KsxyMssuyBXM7Oy98gjKPEiHMUz6blx8Mh8r9HEvAlpjZBG4aPxvqqQ.B LzPLeGmKp8KdPKo0buhVIUUX34Hb8LiUliSiUo69OOo8G_5OfZieFvAEZKONW4KeQwTJgKgmPtML SGLQiKipc3r0v5Jsl3wFvDc0ltA9lkz2ZtrT3nx76C_MgArAx7DXrbX2a3ZTU1A3nUt5f6zyDRlR msfhne72r6IOUJi2XOV0Gwh_6EelTT6eJx02DW7fCf2C40Nc1OpW422lqfphDVgY6DflqX2uusnb edP3sv1a_pnhEbGEE4JWOQ_7guuChrr3QNlBgKfUgraH.2i3.XitVKK5yyRMMPz5868g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 21:33:18 +0000 Received: by smtp421.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 11d75ad166e748449ac4d2ffe3e0d935; Tue, 10 Mar 2020 21:33:15 +0000 (UTC) From: Phil Hunt Message-Id: <4358B9B5-9B09-4EE0-956D-FA27F9A74CBB@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 14:33:13 -0700 In-Reply-To: <20200226191636.EAB5CF40710@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, scim@ietf.org, Shelley To: RFC Errata System References: <20200226191636.EAB5CF40710@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (5990) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:33:22 -0000 --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii VERIFIED Phil Hunt phil.hunt@yahoo.com > On Feb 26, 2020, at 11:16 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5990 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.2 >=20 > Original Text > ------------- > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "USA", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ], >=20 > Corrected Text > -------------- > "addresses": [ > { > "type": "work", > "streetAddress": "100 Universal City Plaza", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "US", > "formatted": "100 Universal City Plaza\nHollywood, CA 91608 USA", > "primary": true > }, > { > "type": "home", > "streetAddress": "456 Hollywood Blvd", > "locality": "Hollywood", > "region": "CA", > "postalCode": "91608", > "country": "US", > "formatted": "456 Hollywood Blvd\nHollywood, CA 91608 USA" > } > ], >=20 > Notes > ----- > Section 4.1.2 requires the use of the ISO 3166-1 "alpha-2" code format = for the "country" attribute; however, sections 8.2 and 8.3 incorrectly = specify "USA" instead of "US" for the "country" attribute. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii VERIFIED

Phil Hunt



On Feb 26, 2020, at 11:16 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid5990
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.2

Original Text
-------------
 "addresses": [
   {
=      "type": "work",
=      "streetAddress": "100 Universal City = Plaza",
     "locality": = "Hollywood",
     "region": = "CA",
     "postalCode": = "91608",
     "country": = "USA",
     "formatted": "100 = Universal City Plaza\nHollywood, CA 91608 USA",
=      "primary": true
=    },
   {
=      "type": "home",
=      "streetAddress": "456 Hollywood Blvd",
     "locality": "Hollywood",
     "region": "CA",
=      "postalCode": "91608",
=      "country": "USA",
=      "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 USA"
   }
 ],

Corrected Text
--------------
 "addresses": [
   {
=      "type": "work",
=      "streetAddress": "100 Universal City = Plaza",
     "locality": = "Hollywood",
     "region": = "CA",
     "postalCode": = "91608",
     "country": = "US",
     "formatted": "100 = Universal City Plaza\nHollywood, CA 91608 USA",
=      "primary": true
=    },
   {
=      "type": "home",
=      "streetAddress": "456 Hollywood Blvd",
     "locality": "Hollywood",
     "region": "CA",
=      "postalCode": "91608",
=      "country": "US",
=      "formatted": "456 Hollywood = Blvd\nHollywood, CA 91608 USA"
   }
 ],

Notes
-----
Section 4.1.2 requires the use of the ISO = 3166-1 "alpha-2" code format for the "country" attribute; however, = sections 8.2 and 8.3 incorrectly specify "USA" instead of "US" for the = "country" attribute.

Instructions:
-------------
This erratum is currently posted = as "Reported". If necessary, please
use "Reply All" to = discuss whether it should be verified or
rejected. When a = decision is reached, the verifying party  
can log in = to change the status and edit the report, if necessary.
--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

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

= --Apple-Mail=_D2BE235A-4936-40D3-839C-D86A8941E3B6-- From nobody Tue Mar 10 14:35:50 2020 Return-Path: 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 A68FE3A0E0F for ; Tue, 10 Mar 2020 14:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 HstKkfV1IjNU for ; Tue, 10 Mar 2020 14:35:47 -0700 (PDT) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC383A0E0C for ; Tue, 10 Mar 2020 14:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583876146; bh=LIALsF2kr5gKDIhisySMsBJOpA3SpTPK0Chf0QprlUI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=XrqOUNzwvdIKHvxukKYYhxUBMLX8fxNr20qCypL3thuuEDxOdIPPPDLCP9zKaDrHvbtHiL+hxjLIjds8Y8gcI7MyRumwb2/OcwGASY2Gbxwgh30CM3Mxtxb6lj192SDA2TILtgh1IanO+2iVWB4BLWsFLWqY23dT2HGl5oBJYWIQJp0lvlt6xpA7qkfsuzWcrAFXmnjvRGqWiAYHAP1STFN/+9/YP76jXW/Ys8ztETbOx+H81ASp84V6Wsn5h3zEW3Lqd61LiixxQnqSQ96cbIwciADsQ9A7cyQpjd0xDvKIhfHrXvEabzt+jqqvZKpij3pxdYcocEZeCJI+D7nbsQ== X-YMail-OSG: QZjgwkQVM1mvFLk3cNd.7cFe1FIvrdG.hNbjhFW4k11zawWRSdjJGiINm3iCB8j e2sTdduq.3KVZPzFnsAryMAfUAZDi4wE2KjdrtAiT3uoFQyFRulhJDlcExrp21HBHVunoSb_lazd 7_fRAhq7asPgn5bseY.Lb0249hbC_v9vLMlvzHhugAetLUW..WAy2ziFOmsh6WxZ6nwtl.cmp07N htoqjYWuWA7CfuOuVWnQjFkNTTM4Z_7AE3LfnRIUiN1KmL0OCDHDWIjFtfEc0MC0xn.OPZL98U7M MQWKcz3vbNBnmBd4ChUtSN5BFQMfNvPlfoCJn2iksCWVLv2aptnG0KoNVWxa5I4hkdJin5RjJna8 WNR4rP30d6fqc9gB6.YA4z0tlkiUjB8tcvkmP59tycOjpIiCBG.wskhTbT10TlDDeIMMPwarG8yF 8Io5B7uyn6oHxmIhxzp7qQrHhVRNzxd9SMQafm.E4UFDbYK6ZN2hc9S23J8QC8.P.VwOT7bT2wJQ BOCyk8ZhkvC0Jt_V.RlEK7bBoNyQkwc0BkA2W8hMEHldsEGcIdlLz0krj593P2c627rM_JSVbrvI 53i5MsKYSjxvO6xiPFGYXVMPwSDPbNH7Dj6_H1TjnvGUud1__tim9KH5Z4etTiR3ky5K_AtHmuaw jz9WMYS6jLOYXiJ9cir0DeO8a9oBENPI5gmOwagyE_gWYSxn1hgHCVJpQfNtuXa6W3hc73gf1ful g4CbTF4Zz6HG0yTzT82Xk5tg4dMC.p_aOEWMWTPEAvsUs8nMBryUXWSlPPRlSWJ5AeiYWjtarZvq ujUgjbthNgnNzbHOC0BZGVVTJX_im27LtqiWy0O9hgx0_1xjd9JTuAJleiZxggYtLvTCe01GBKKT cmb8F5ySrBTXXqNfi2LLzVZg6bZ6GhJv9Wj02PcAVfW5sw17eIVMRrmSrZ6BDrmcQzQFa9hfo7Am Fegq5H3gRhDgvpXaC34QuuBx4Bj0xtgmh2a3lbUVFjYpohkmnpVHMc9xhHyUZEm5.IUDuAj4O2.u _SBR_smgzYOOVvvmO9q4wSnjrfWRQZwYXzhV0u3vL7Ats6FCHMaIFti10g3txFYZBbN5QpE2TNUO CKBWBVEQzv.2Ap1sXGeJHryyAli2lwB66kFtNOXOlwODk.7kjQj557N5z9r92UykKHwUXWthuB4t GTu6dod18cF7cLkn8HeXu_DnuY69kQot5G6jiDik8.E7YMxA2B2Yf1ORGux.KEyCsCb9VirFkHFD ZVHEUpIZvPsWqBjGnXD_BSkMBuvYo20LBCicv468DYmrRFk7CliAF2ICLHucJnrm13wtUqqhPqJ_ VSlpIQwQ.KKUB2A.uWJHPXXOfcZasuFo0L7qf9mbLy0ZN9fg6.kJE6ag_oqXpf9qJbug9BeVEk_Y C.yV2K8.cvxVBNIMF6DIZvvajwyWhXw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 21:35:46 +0000 Received: by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 66c117aabf7a3774ad425654a8298710; Tue, 10 Mar 2020 21:35:41 +0000 (UTC) From: Phil Hunt Message-Id: <34F51C13-3297-4DEE-97E6-6E78DFB74D07@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 14:35:40 -0700 In-Reply-To: <20200303171714.030FCF4071A@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, Shelley , scim@ietf.org To: RFC Errata System References: <20200303171714.030FCF4071A@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6004) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:35:49 -0000 --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii VERIFIED Thanks! Phil Hunt phil.hunt@yahoo.com > On Mar 3, 2020, at 9:17 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6004 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "name", > "type" : "complex", > ... > "uniqueness" : "none" > }, > ... > { > "name" : "emails", > "type" : "complex", > ... > "uniqueness" : "none" > }, > ... > { > "name" : "addresses", > "type" : "complex", > ... > "uniqueness" : "none" > }, >=20 >=20 > Corrected Text > -------------- > { > "name" : "name", > "type" : "complex", > ... > }, > ... > { > "name" : "emails", > "type" : "complex", > ... > }, > ... > { > "name" : "addresses", > "type" : "complex", > ... > }, >=20 >=20 > Notes > ----- > The "emails", "name", and "addresses" complex user attributes have a = "uniqueness" characteristic defined. According to Section 2.3.8, complex = attributes have no uniqueness. No other complex attributes in Section = 8.7.1 specify a "uniqueness" characteristic. For compliance with Section = 2.3.8 and consistency with other attribute definitions, the "uniqueness" = sub-attribute for these complex attributes should be removed. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii VERIFIED

Thanks!

Phil Hunt



On Mar 3, 2020, at 9:17 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6004
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "name",
=        "type" : "complex",
       ...
=        "uniqueness" : "none"
     },
=      ...
=      {
=        "name" : "emails",
       "type" : = "complex",
=        ...
=        "uniqueness" : "none"
     },
=      ...
=      {
=        "name" : "addresses",
       "type" : = "complex",
=        ...
=        "uniqueness" : "none"
     },


Corrected Text
--------------
     {
=        "name" : "name",
=        "type" : "complex",
       ...
=      },
=      ...
=      {
=        "name" : "emails",
       "type" : = "complex",
=        ...
=      },
=      ...
=      {
=        "name" : "addresses",
       "type" : = "complex",
=        ...
=      },


Notes
-----
The "emails", "name", = and "addresses" complex user attributes have a "uniqueness" = characteristic defined. According to Section 2.3.8, complex attributes = have no uniqueness. No other complex attributes in Section 8.7.1 specify = a "uniqueness" characteristic. For compliance with Section 2.3.8 and = consistency with other attribute definitions, the "uniqueness" = sub-attribute for these complex attributes should be removed.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E-- From nobody Tue Mar 10 14:35:57 2020 Return-Path: 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 0EAFE3A0E0C for ; Tue, 10 Mar 2020 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 e_QBv2pu35Ga for ; Tue, 10 Mar 2020 14:35:47 -0700 (PDT) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312B53A0E0D for ; Tue, 10 Mar 2020 14:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583876146; bh=LIALsF2kr5gKDIhisySMsBJOpA3SpTPK0Chf0QprlUI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=XrqOUNzwvdIKHvxukKYYhxUBMLX8fxNr20qCypL3thuuEDxOdIPPPDLCP9zKaDrHvbtHiL+hxjLIjds8Y8gcI7MyRumwb2/OcwGASY2Gbxwgh30CM3Mxtxb6lj192SDA2TILtgh1IanO+2iVWB4BLWsFLWqY23dT2HGl5oBJYWIQJp0lvlt6xpA7qkfsuzWcrAFXmnjvRGqWiAYHAP1STFN/+9/YP76jXW/Ys8ztETbOx+H81ASp84V6Wsn5h3zEW3Lqd61LiixxQnqSQ96cbIwciADsQ9A7cyQpjd0xDvKIhfHrXvEabzt+jqqvZKpij3pxdYcocEZeCJI+D7nbsQ== X-YMail-OSG: QZjgwkQVM1mvFLk3cNd.7cFe1FIvrdG.hNbjhFW4k11zawWRSdjJGiINm3iCB8j e2sTdduq.3KVZPzFnsAryMAfUAZDi4wE2KjdrtAiT3uoFQyFRulhJDlcExrp21HBHVunoSb_lazd 7_fRAhq7asPgn5bseY.Lb0249hbC_v9vLMlvzHhugAetLUW..WAy2ziFOmsh6WxZ6nwtl.cmp07N htoqjYWuWA7CfuOuVWnQjFkNTTM4Z_7AE3LfnRIUiN1KmL0OCDHDWIjFtfEc0MC0xn.OPZL98U7M MQWKcz3vbNBnmBd4ChUtSN5BFQMfNvPlfoCJn2iksCWVLv2aptnG0KoNVWxa5I4hkdJin5RjJna8 WNR4rP30d6fqc9gB6.YA4z0tlkiUjB8tcvkmP59tycOjpIiCBG.wskhTbT10TlDDeIMMPwarG8yF 8Io5B7uyn6oHxmIhxzp7qQrHhVRNzxd9SMQafm.E4UFDbYK6ZN2hc9S23J8QC8.P.VwOT7bT2wJQ BOCyk8ZhkvC0Jt_V.RlEK7bBoNyQkwc0BkA2W8hMEHldsEGcIdlLz0krj593P2c627rM_JSVbrvI 53i5MsKYSjxvO6xiPFGYXVMPwSDPbNH7Dj6_H1TjnvGUud1__tim9KH5Z4etTiR3ky5K_AtHmuaw jz9WMYS6jLOYXiJ9cir0DeO8a9oBENPI5gmOwagyE_gWYSxn1hgHCVJpQfNtuXa6W3hc73gf1ful g4CbTF4Zz6HG0yTzT82Xk5tg4dMC.p_aOEWMWTPEAvsUs8nMBryUXWSlPPRlSWJ5AeiYWjtarZvq ujUgjbthNgnNzbHOC0BZGVVTJX_im27LtqiWy0O9hgx0_1xjd9JTuAJleiZxggYtLvTCe01GBKKT cmb8F5ySrBTXXqNfi2LLzVZg6bZ6GhJv9Wj02PcAVfW5sw17eIVMRrmSrZ6BDrmcQzQFa9hfo7Am Fegq5H3gRhDgvpXaC34QuuBx4Bj0xtgmh2a3lbUVFjYpohkmnpVHMc9xhHyUZEm5.IUDuAj4O2.u _SBR_smgzYOOVvvmO9q4wSnjrfWRQZwYXzhV0u3vL7Ats6FCHMaIFti10g3txFYZBbN5QpE2TNUO CKBWBVEQzv.2Ap1sXGeJHryyAli2lwB66kFtNOXOlwODk.7kjQj557N5z9r92UykKHwUXWthuB4t GTu6dod18cF7cLkn8HeXu_DnuY69kQot5G6jiDik8.E7YMxA2B2Yf1ORGux.KEyCsCb9VirFkHFD ZVHEUpIZvPsWqBjGnXD_BSkMBuvYo20LBCicv468DYmrRFk7CliAF2ICLHucJnrm13wtUqqhPqJ_ VSlpIQwQ.KKUB2A.uWJHPXXOfcZasuFo0L7qf9mbLy0ZN9fg6.kJE6ag_oqXpf9qJbug9BeVEk_Y C.yV2K8.cvxVBNIMF6DIZvvajwyWhXw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Mar 2020 21:35:46 +0000 Received: by smtp423.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 66c117aabf7a3774ad425654a8298710; Tue, 10 Mar 2020 21:35:41 +0000 (UTC) From: Phil Hunt Message-Id: <34F51C13-3297-4DEE-97E6-6E78DFB74D07@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Mar 2020 14:35:40 -0700 In-Reply-To: <20200303171714.030FCF4071A@rfc-editor.org> Cc: Kelly Grizzle , Barry Leiba , Alexey Melnikov , Adam Roach , Morteza Ansari , leifj@sunet.se, Shelley , scim@ietf.org To: RFC Errata System References: <20200303171714.030FCF4071A@rfc-editor.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6004) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 21:35:50 -0000 --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii VERIFIED Thanks! Phil Hunt phil.hunt@yahoo.com > On Mar 3, 2020, at 9:17 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC7643, > "System for Cross-domain Identity Management: Core Schema". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6004 >=20 > -------------------------------------- > Type: Technical > Reported by: Shelley Baker >=20 > Section: 8.7.1 >=20 > Original Text > ------------- > { > "name" : "name", > "type" : "complex", > ... > "uniqueness" : "none" > }, > ... > { > "name" : "emails", > "type" : "complex", > ... > "uniqueness" : "none" > }, > ... > { > "name" : "addresses", > "type" : "complex", > ... > "uniqueness" : "none" > }, >=20 >=20 > Corrected Text > -------------- > { > "name" : "name", > "type" : "complex", > ... > }, > ... > { > "name" : "emails", > "type" : "complex", > ... > }, > ... > { > "name" : "addresses", > "type" : "complex", > ... > }, >=20 >=20 > Notes > ----- > The "emails", "name", and "addresses" complex user attributes have a = "uniqueness" characteristic defined. According to Section 2.3.8, complex = attributes have no uniqueness. No other complex attributes in Section = 8.7.1 specify a "uniqueness" characteristic. For compliance with Section = 2.3.8 and consistency with other attribute definitions, the "uniqueness" = sub-attribute for these complex attributes should be removed. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC7643 (draft-ietf-scim-core-schema-22) > -------------------------------------- > Title : System for Cross-domain Identity Management: = Core Schema > Publication Date : September 2015 > Author(s) : P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. = Mortimore > Category : PROPOSED STANDARD > Source : System for Cross-domain Identity Management > Area : Applications and Real-Time > Stream : IETF > Verifying Party : IESG --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii VERIFIED

Thanks!

Phil Hunt



On Mar 3, 2020, at 9:17 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

The = following errata report has been submitted for RFC7643,
"System for Cross-domain Identity Management: Core = Schema".

--------------------------------------
You may = review the report below and at:
https://www.rfc-editor.org/errata/eid6004
--------------------------------------
Type: = Technical
Reported by: Shelley Baker = <randomshelley@gmail.com>

Section: = 8.7.1

Original Text
-------------
=      {
=        "name" : "name",
=        "type" : "complex",
       ...
=        "uniqueness" : "none"
     },
=      ...
=      {
=        "name" : "emails",
       "type" : = "complex",
=        ...
=        "uniqueness" : "none"
     },
=      ...
=      {
=        "name" : "addresses",
       "type" : = "complex",
=        ...
=        "uniqueness" : "none"
     },


Corrected Text
--------------
     {
=        "name" : "name",
=        "type" : "complex",
       ...
=      },
=      ...
=      {
=        "name" : "emails",
       "type" : = "complex",
=        ...
=      },
=      ...
=      {
=        "name" : "addresses",
       "type" : = "complex",
=        ...
=      },


Notes
-----
The "emails", "name", = and "addresses" complex user attributes have a "uniqueness" = characteristic defined. According to Section 2.3.8, complex attributes = have no uniqueness. No other complex attributes in Section 8.7.1 specify = a "uniqueness" characteristic. For compliance with Section 2.3.8 and = consistency with other attribute definitions, the "uniqueness" = sub-attribute for these complex attributes should be removed.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be = verified or
rejected. When a decision is reached, the = verifying party  
can log in to change the status and = edit the report, if necessary.

--------------------------------------
RFC7643 = (draft-ietf-scim-core-schema-22)
--------------------------------------
Title =             &n= bsp; : System for Cross-domain Identity Management: Core Schema
Publication Date    : September 2015
Author(s) =           : P. Hunt, = Ed., K. Grizzle, E. Wahlstroem, C. Mortimore
Category =            : = PROPOSED STANDARD
Source =             &n= bsp;: System for Cross-domain Identity Management
Area =             &n= bsp;  : Applications and Real-Time
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG

= --Apple-Mail=_5CB7E253-B700-4733-9FB8-B0AC33FAA25E-- From nobody Wed Mar 11 06:26:09 2020 Return-Path: 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 61F063A18D8 for ; Wed, 11 Mar 2020 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UeLTMxSMjfeV for ; Wed, 11 Mar 2020 06:26:05 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C173A18D5 for ; Wed, 11 Mar 2020 06:26:05 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id c18so1285239vsq.7 for ; Wed, 11 Mar 2020 06:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ozeGxwiMyg2T4NNl+qeNrBUMNOy2KoU7dPemwjVWbTA=; b=mi/I1WT3aPpEa2bctNngBm1wgIeaf9zE99dnTdCpCRs867gsO4K12Wv8xe5pn6UpoF tMSPHyRrZBDQnp3EAWNUn/7n0jMqoppleEf11ERbl+MMXwndvNZU5BuNYeJrNHNfmgUM z+RuJgqACCTX9ZCwZ5bVM97dQPJFn9L/eSHaQgUspNka8ECVJGJsVDbBaS0JKjbb0kyb Nn7r7mjQn+E1IVKrS9tWD6ecFbxwicwl8nITkDeLIlUjX4wtxAemNz7cq46pO3wjudXs 9PhQW28rOXoD6sy8P0xtEh+w/xArtDUlfXp+2ARn5Ts8X5nhxXE8sWbI37JGfKfGH7Cq d+oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ozeGxwiMyg2T4NNl+qeNrBUMNOy2KoU7dPemwjVWbTA=; b=eh80yK1dmvIqLb+4QgAUtd21wQq9sige2EhgZ7SIEfCCHQGP3JW5gIiU2Y4NhItO4O 1wrlTXaAHtCDLcRRV4y7xjL4LdvnGoLTymtjxUuIa1pB6Vg0WhzIyl3jEaJ/AjOd42NZ NfHCj75UGFZOscT45oqK1LsY41AKrrMDFsefj4YHNk9zqBHN4rK2iHHAJJ4bF7LWnquI a8bnmDo6jzEOySZ36OrbxOqaseaDZHZrhjpy8ry52bmsfA6s+wgE4r80+JgTzHufDk+G VeptnvMCZx6myPnCOTs9Q3MJf4yJSHHDH8x4gqpCTBLe+4YQt94ZVS17ZT4smf1YAhrU 0jYw== X-Gm-Message-State: ANhLgQ1MH96EG+iJ9KVAvv6+m+xRzC4+J2lPe3cBqnHOrsvJn7FSEXjj jVx0/rwSm+aSBC0VBiFNGnSbof7RshsInbz2NuPlNi6aBvzcKw== X-Google-Smtp-Source: ADFU+vvwxNdhSvT6vt0dX0m5EORXQ/1dTHRBm23XCvbq0arKANoCtE8kgGA4L5TmE51aAoI3x9mxcTMFX/RSXQAKFRY= X-Received: by 2002:a67:b107:: with SMTP id w7mr2035075vsl.128.1583933162791; Wed, 11 Mar 2020 06:26:02 -0700 (PDT) MIME-Version: 1.0 From: Shelley Date: Wed, 11 Mar 2020 08:25:51 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="00000000000084260905a0942d17" Archived-At: Subject: [scim] ExternalId Case Sensitivity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 13:26:07 -0000 --00000000000084260905a0942d17 Content-Type: text/plain; charset="UTF-8" Section 3.1 indicates that "externalId" has "caseExact" as "true". However, I would like our service provider's "externalId" attribute to be *case-insensitive*, but since "externalId" is a "Common Attribute", service providers cannot change its attribute characteristics [1]: For backward compatibility, some existing schema definitions MAY list > common attributes as part of the schema. The attribute > characteristics (see Section 2.2) listed here SHALL take precedence > over older definitions that may be included in existing schemas. > I have a few related questions: - *What was the reasoning behind making externalId caseExact*? - From the perspective of *case preservation*, I can understand the use of "caseExact" for externalIds; however, for *filtering*, it still seems appropriate to search *case-insensitively*. - I've seen some past discussions where "externalId" had "caseExact" as "false" (e.g. [2,3]), but it seems to be "true" in the final RFC, and I was unable to trace that decision back to a discussion. - If I'm not mistaken, externalId was case-insensitive implicitly in SCIM 1.1 as well. - More generally, perhaps future-thinking (unless this has already been discussed), perhaps "caseExact" may be over-simplified? There are potentially 3 different uses for caseExact, and they may not all share a value: - *Case Preservation*: Must the server preserve the case of the attribute? - *Uniqueness*: If the attribute is unique, must it be case-sensitively unique? - *Filtering*: Should the attribute be filtered case-sensitively? (Perhaps allowing clients to specify case-sensitive filter operators may be more appropriate than making this part of the attribute's characteristics?) - Should service providers be allowed to *change the "common attribute" characteristics* to account for cases such as these? The spec currently seems to forbid this. [1] https://tools.ietf.org/html/rfc7643#section-3.1 [2] https://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTtaIam4RmcbhSyCF9xE/ [3] https://mailarchive.ietf.org/arch/msg/scim/NgMipeLaeLlOwpPkrg2Jak7W2-M/ --00000000000084260905a0942d17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 3.1 indicates that "externalId" has &quo= t;caseExact" as "true". However, I would like our service pr= ovider's "externalId" attribute to be case-insensitive= , but since "externalId" is a "Common Attribute", servi= ce providers cannot change its attribute characteristics [1]:

For backward compatibility, som= e existing schema definitions MAY list
common attributes as part of the = schema.=C2=A0 The attribute
characteristics (see Section 2.2) listed her= e SHALL take precedence
over older definitions that may be included in e= xisting schemas.

I have a few related questions:
  • What was the reasoning behind making externalId caseExact?
    • =
    • From the perspective of case preservation, I can understand = the use of "caseExact" for externalIds; however, for filtering= , it still seems appropriate to search case-insensitively.
      • <= li>I've seen some past discussions where "externalId" had &qu= ot;caseExact" as "false" (e.g. [2,3]), but it seems to be &q= uot;true" in the final RFC, and I was unable to trace that decision ba= ck to a discussion.
    • If I'm not mistaken, externalId was case-in= sensitive implicitly in SCIM 1.1 as well.
    • = More generally, perhaps future-thinking (unless this has already been discu= ssed), perhaps "caseExact" may be over-simplified? There are pote= ntially 3 different uses for caseExact, and they may not all share a value:=
      • Case Preservation: Must the server preserve the case of= the attribute?
      • Uniqueness: If the attribute is unique, must= it be case-sensitively unique?
      • Filtering: Should the attrib= ute be filtered case-sensitively? (Perhaps allowing clients to specify case= -sensitive filter operators may be more appropriate than making this part o= f the attribute's characteristics?)
    • Sh= ould service providers be allowed to change the "common attribute&q= uot; characteristics to account for cases such as these? The spec curre= ntly seems to forbid this.
    [1] https://tools.ietf.org/html/rfc7643#section-3.= 1
    [2] https://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTt= aIam4RmcbhSyCF9xE/
    [3] https://mailarchive.ietf.org/arch/ms= g/scim/NgMipeLaeLlOwpPkrg2Jak7W2-M/
    --00000000000084260905a0942d17-- From nobody Wed Mar 11 11:12:06 2020 Return-Path: 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 042343A107C for ; Wed, 11 Mar 2020 11:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 7adJF99FqRM4 for ; Wed, 11 Mar 2020 11:12:02 -0700 (PDT) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6C63A107E for ; Wed, 11 Mar 2020 11:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583950321; bh=iDmSMCH5tOghFJRZ60K2PRRzsVvr32BI4orLXBsxBfc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=t3qU0mSj0gNXmXqXpCfeaNQVgo47uS7iwyQMxZIupa1k3pUatGsxtnTkT9Q28pMnLOOlzoP0Ox79hs149Mea4KRg7uP2qCUunKbKJBOrAtQIPRWhNY4Q5sGWyNSXDacWMQgvQcPd1WNDveoeBq6eqlwbU8q12OcyRQ/8XzpBu3BJUDEXu5Pbj9Bfjkll+DfHzTDGrFXVou3LFiYLN0Ql0RHcZtwSkPiGz8fqlrECaYVFBK3Zya7AFGkjjlQLDxE+Ez5ORg78dZ9CMg+9YqRYtktDO6CyAn68/8G/8IL/l7f8DLilSR3ZsE6YwspIjANqi38W0VJJJLiJL07GH59N1Q== X-YMail-OSG: rRs1b8YVM1lel97ravmY2WHi3f_CHzNgiOnnB2DL1Y5matqHxadZxu9mqObikBa mD_By2YbTiUntqujADr3S8kzarGUBsepS..qjeXpfGG64XhBnIUvsBT9qaCPoxYIv258_PW1xCdO z4jEiqe4NWiaRX1oEolb_KUV3fot70PeepN4H44Ltmz99HwjFfXJl0HHWfIW0HvxM_qdXw_O3fWT 0dB9EilshKafY4WMB5HhcPKq0emPqZDiFS2q_2kwMYVSGCqGaHqQjD.mFyoZbe5SaIu8mJtsJOQg 38xtrKDasi0ubS_VOPhFfsZAHc4ALr3ZgNppl.8o7yFssIWpZwtFa2J7YyDRYF2.bSLvjwXR36UJ uSJTljwOeZlqZft.gkl2dJ2W2al0Msx9qVYVYEfQtqC0Epv4H0P0TRkjaD3PoFc94eg0cCAPpa4e mmBcy83kjVrQNCtkqXp.gey6oxoUBHIs8UlIHGRvK8PHTUWEj5M37zFWgIoonAIPNq7iMJCIU6qR SGO8jfd0IEeWEsdPCyP17aTh.5siK8u1lvnlyz9MWnMAC9orAo0fYZ6m3NsFf7vMbJTLGK81NRYP wP4IuBYIbSGo2VxTu4.9JJAKWoKDn3reOgTrzwnDVye2J1nKsEpnay6HqJ5VQ8gFSqR088U3.AHw lhz4UOBrARPudGr9eLys0lL.10sRsodvtkEyCqxU4Mb0NmaAVw1GoO.BE3.jFWThFfCg31AkZfbn lFpjT.wYRFuwOM10gLjNCtPT.TCsOJHuCmfrrXcGaYJRqWDZDtB82FC.RzE_5jIvlphwcmUSh1a. BfliafkhizjFQ.G12XWcRivrdxo8D1XMRb1FTiOjWnto9ts.RQ9GKTWQQxNwe0ceWZLp0KjoEblA UY1n4BzjCE0u8TI09ALksO9..NhRIdzPNv3eiFocycm4DQHKQSPAsZ2RrA05a67IL56Ikho3B6No XA5ACongm7VRGvx8Uab9roTSx9Iu5TMeIyRylyYxn_.yTzSXsLx_dzcJA8IRSZVjUAgedGt6EnkU _wLnvJCtioq0jT54AvCBstTDzsroxS6kUpaINsx_4AsBa55Juq9dgtsD3xreZRfKj5PU2ia8lzrM eNV7AUbgO3JGGeXaDjOYzvkK_wKo0uiMZ.6YdrfEwpG8B3.cwb6Ug6rFokI73pZ7CMWY99i.5gY9 cwRtol7hwV9AMK5jBOa_h6PyqOd7PfeKy2KkOASJ0GwmBR5cogBylY7sSD1RTq3e2A9ZRNZJhftM EKJq5vFQQFr_TsRC29xtz7YgTyIDBfGNEIBZz4N1OhSuS_uOQrLvFc_tmeXFGN.Terdha6Dj7eCE oEBlfPUz0nRGlO1CAMDNKrmlk52dtZdN7f6Cl_7BF3mrxY98gK4KGnk2iVvScoqTznnAYKqBzvdy YEMyhgAaQwQ5d0LMBOUF8FA_E Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Wed, 11 Mar 2020 18:12:01 +0000 Received: by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1a2d32141e12a49ba9f29e738d9b503d; Wed, 11 Mar 2020 18:11:57 +0000 (UTC) From: Phil Hunt Message-Id: <47F56EB2-8472-49A1-BDC1-37B9F718C379@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 11 Mar 2020 11:11:54 -0700 In-Reply-To: Cc: Leif Johansson , Adam Roach , Alexey Melnikov , leifj@sunet.se, scim@ietf.org, Kelly Grizzle , Barry Leiba , Morteza Ansari To: Shelley References: <20200302171904.01B97F406D7@rfc-editor.org> <8b371853-c39e-4f62-b224-2134aa586bd2@mnt.se> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:12:04 -0000 --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, I agree with Leif=E2=80=99s suggestion that this is the kind of stuff = best deli with in a SCIMbis group. SCIM is badly in need of a certification test that captures common = implementation and normalizes behaviours and best practices. In and of = itself would be a good feed back to any SCIMbis work. I have been = trying to lobby for this, but without a major sponsor and host = organization, I fear this will not happen. Phil Hunt phil.hunt@yahoo.com > On Mar 11, 2020, at 6:48 AM, Shelley wrote: >=20 > The more I think about this, the more I am leaning towards the problem = here being in Section 2.3.7, not 8.7.1. >=20 > As noted here [1], I have some general concerns with "caseExact," = namely that there should be some separation of concerns between = attribute characteristics and filtering capabilities. The fact that = Section 2.3.7 requires all "reference" types to be "case exact" [2] = seems overly-limiting. >=20 > URNs, for instance, are not entirely case-sensitive; they define a = lexical equivalence, in which only some parts of the URN are = case-sensitive [3]. For example, the following two URNs are lexically = equivalent: > urn:ietf:params:scim:schemas:core:2.0:User > URN:IETF:params:scim:schemas:core:2.0:User >=20 > Given this, I would suggest that a filter for a URN attribute should = match on either of the above. However, with the requirements outlined in = Section 2.3.7, a client would need to provide the case-exact equivalent = in order to match. >=20 > Therefore, perhaps Section 2.3.7's requirement that "A reference is = case exact" could/should be removed (in which case my initially proposed = change in Section 8.7.1 is optional)? >=20 > [1] = https://mailarchive.ietf.org/arch/msg/scim/7ElDxpsgHZGRmQrXOTIR1jwuTts/ = > [2] https://tools.ietf.org/html/rfc7643#section-2.3.7 = > [3] https://tools.ietf.org/html/rfc8141#section-3 = > On Wed, Mar 11, 2020 at 4:05 AM Leif Johansson > wrote: >=20 >=20 > On 2020-03-10 21:00, Shelley wrote: > > it is allowed that the schema may be set to caseExact false=20 > >=20 > >=20 > > Is Section 2.3.7 not normative? If not, perhaps that section should = not prescribe a caseExact characteristic for references at all then. > >=20 >=20 > I think Phil meant that the /examples/ are not normative. >=20 > I'm also supportive of going either way on this. There has been talk = of a > 'bis' process for SCIM and if that happens this would certainly get = included. >=20 > Cheers Leif --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

    I = agree with Leif=E2=80=99s suggestion that this is the kind of stuff best = deli with in a SCIMbis group.

    SCIM is badly in need of a = certification test that captures common implementation and normalizes = behaviours and best practices. In and of itself would be a good feed = back to any SCIMbis work.  I have been trying to lobby for this, = but without a major sponsor and host organization, I fear this will not = happen.

    Phil Hunt



    On Mar 11, 2020, at 6:48 AM, Shelley <randomshelley@gmail.com> wrote:

    The more I think about this, the more I am leaning towards = the problem here being in Section 2.3.7, not 8.7.1.

    As noted here [1], I have some general concerns with = "caseExact," namely that there should be some separation of concerns = between attribute characteristics and filtering capabilities. The fact = that Section 2.3.7 requires all "reference" types to be "case exact" [2] = seems overly-limiting.

    URNs, for instance, = are not entirely case-sensitive; they define a lexical equivalence, in = which only some parts of the URN are case-sensitive [3]. For example, = the following two URNs are lexically equivalent:
    • urn:ietf:params:scim:schemas:core:2.0:User
    • URN:IETF:params:scim:schemas:core:2.0:User

    Given this, I would suggest that a filter for a URN attribute = should match on either of the above. However, with the requirements = outlined in Section 2.3.7, a client would need to provide the case-exact = equivalent in order to match.

    Therefore, perhaps = Section 2.3.7's requirement that "A reference is case exact" = could/should be removed (in which case my initially proposed change in = Section 8.7.1 is optional)?

    [1] https://mailarchive.ietf.org/arch/msg/scim/7ElDxpsgHZGRmQrXOTIR= 1jwuTts/
    [2] https://tools.ietf.org/html/rfc7643#section-2.3.7
    [3] https://tools.ietf.org/html/rfc8141#section-3

    On Wed, Mar 11, 2020 at 4:05 AM Leif Johansson = <leifj@mnt.se> = wrote:


    On 2020-03-10 21:00, Shelley wrote:
    >     it is allowed that the schema may be set to = caseExact false
    >
    >
    > Is Section 2.3.7 not normative? If not, perhaps that section should = not prescribe a caseExact characteristic for references at all then.
    >

    I think Phil meant that the /examples/ are not normative.

    I'm also supportive of going either way on this. There has been talk of = a
    'bis' process for SCIM and if that happens this would certainly get = included.

            Cheers Leif

    = --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994-- From nobody Wed Mar 11 11:12:38 2020 Return-Path: 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 7C2853A1088 for ; Wed, 11 Mar 2020 11:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 gX21PKDGLnhb for ; Wed, 11 Mar 2020 11:12:06 -0700 (PDT) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF19A3A1082 for ; Wed, 11 Mar 2020 11:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1583950321; bh=iDmSMCH5tOghFJRZ60K2PRRzsVvr32BI4orLXBsxBfc=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From:Subject; b=t3qU0mSj0gNXmXqXpCfeaNQVgo47uS7iwyQMxZIupa1k3pUatGsxtnTkT9Q28pMnLOOlzoP0Ox79hs149Mea4KRg7uP2qCUunKbKJBOrAtQIPRWhNY4Q5sGWyNSXDacWMQgvQcPd1WNDveoeBq6eqlwbU8q12OcyRQ/8XzpBu3BJUDEXu5Pbj9Bfjkll+DfHzTDGrFXVou3LFiYLN0Ql0RHcZtwSkPiGz8fqlrECaYVFBK3Zya7AFGkjjlQLDxE+Ez5ORg78dZ9CMg+9YqRYtktDO6CyAn68/8G/8IL/l7f8DLilSR3ZsE6YwspIjANqi38W0VJJJLiJL07GH59N1Q== X-YMail-OSG: rRs1b8YVM1lel97ravmY2WHi3f_CHzNgiOnnB2DL1Y5matqHxadZxu9mqObikBa mD_By2YbTiUntqujADr3S8kzarGUBsepS..qjeXpfGG64XhBnIUvsBT9qaCPoxYIv258_PW1xCdO z4jEiqe4NWiaRX1oEolb_KUV3fot70PeepN4H44Ltmz99HwjFfXJl0HHWfIW0HvxM_qdXw_O3fWT 0dB9EilshKafY4WMB5HhcPKq0emPqZDiFS2q_2kwMYVSGCqGaHqQjD.mFyoZbe5SaIu8mJtsJOQg 38xtrKDasi0ubS_VOPhFfsZAHc4ALr3ZgNppl.8o7yFssIWpZwtFa2J7YyDRYF2.bSLvjwXR36UJ uSJTljwOeZlqZft.gkl2dJ2W2al0Msx9qVYVYEfQtqC0Epv4H0P0TRkjaD3PoFc94eg0cCAPpa4e mmBcy83kjVrQNCtkqXp.gey6oxoUBHIs8UlIHGRvK8PHTUWEj5M37zFWgIoonAIPNq7iMJCIU6qR SGO8jfd0IEeWEsdPCyP17aTh.5siK8u1lvnlyz9MWnMAC9orAo0fYZ6m3NsFf7vMbJTLGK81NRYP wP4IuBYIbSGo2VxTu4.9JJAKWoKDn3reOgTrzwnDVye2J1nKsEpnay6HqJ5VQ8gFSqR088U3.AHw lhz4UOBrARPudGr9eLys0lL.10sRsodvtkEyCqxU4Mb0NmaAVw1GoO.BE3.jFWThFfCg31AkZfbn lFpjT.wYRFuwOM10gLjNCtPT.TCsOJHuCmfrrXcGaYJRqWDZDtB82FC.RzE_5jIvlphwcmUSh1a. BfliafkhizjFQ.G12XWcRivrdxo8D1XMRb1FTiOjWnto9ts.RQ9GKTWQQxNwe0ceWZLp0KjoEblA UY1n4BzjCE0u8TI09ALksO9..NhRIdzPNv3eiFocycm4DQHKQSPAsZ2RrA05a67IL56Ikho3B6No XA5ACongm7VRGvx8Uab9roTSx9Iu5TMeIyRylyYxn_.yTzSXsLx_dzcJA8IRSZVjUAgedGt6EnkU _wLnvJCtioq0jT54AvCBstTDzsroxS6kUpaINsx_4AsBa55Juq9dgtsD3xreZRfKj5PU2ia8lzrM eNV7AUbgO3JGGeXaDjOYzvkK_wKo0uiMZ.6YdrfEwpG8B3.cwb6Ug6rFokI73pZ7CMWY99i.5gY9 cwRtol7hwV9AMK5jBOa_h6PyqOd7PfeKy2KkOASJ0GwmBR5cogBylY7sSD1RTq3e2A9ZRNZJhftM EKJq5vFQQFr_TsRC29xtz7YgTyIDBfGNEIBZz4N1OhSuS_uOQrLvFc_tmeXFGN.Terdha6Dj7eCE oEBlfPUz0nRGlO1CAMDNKrmlk52dtZdN7f6Cl_7BF3mrxY98gK4KGnk2iVvScoqTznnAYKqBzvdy YEMyhgAaQwQ5d0LMBOUF8FA_E Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Wed, 11 Mar 2020 18:12:01 +0000 Received: by smtp415.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1a2d32141e12a49ba9f29e738d9b503d; Wed, 11 Mar 2020 18:11:57 +0000 (UTC) From: Phil Hunt Message-Id: <47F56EB2-8472-49A1-BDC1-37B9F718C379@yahoo.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 11 Mar 2020 11:11:54 -0700 In-Reply-To: Cc: Leif Johansson , Adam Roach , Alexey Melnikov , leifj@sunet.se, scim@ietf.org, Kelly Grizzle , Barry Leiba , Morteza Ansari To: Shelley References: <20200302171904.01B97F406D7@rfc-editor.org> <8b371853-c39e-4f62-b224-2134aa586bd2@mnt.se> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:12:08 -0000 --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, I agree with Leif=E2=80=99s suggestion that this is the kind of stuff = best deli with in a SCIMbis group. SCIM is badly in need of a certification test that captures common = implementation and normalizes behaviours and best practices. In and of = itself would be a good feed back to any SCIMbis work. I have been = trying to lobby for this, but without a major sponsor and host = organization, I fear this will not happen. Phil Hunt phil.hunt@yahoo.com > On Mar 11, 2020, at 6:48 AM, Shelley wrote: >=20 > The more I think about this, the more I am leaning towards the problem = here being in Section 2.3.7, not 8.7.1. >=20 > As noted here [1], I have some general concerns with "caseExact," = namely that there should be some separation of concerns between = attribute characteristics and filtering capabilities. The fact that = Section 2.3.7 requires all "reference" types to be "case exact" [2] = seems overly-limiting. >=20 > URNs, for instance, are not entirely case-sensitive; they define a = lexical equivalence, in which only some parts of the URN are = case-sensitive [3]. For example, the following two URNs are lexically = equivalent: > urn:ietf:params:scim:schemas:core:2.0:User > URN:IETF:params:scim:schemas:core:2.0:User >=20 > Given this, I would suggest that a filter for a URN attribute should = match on either of the above. However, with the requirements outlined in = Section 2.3.7, a client would need to provide the case-exact equivalent = in order to match. >=20 > Therefore, perhaps Section 2.3.7's requirement that "A reference is = case exact" could/should be removed (in which case my initially proposed = change in Section 8.7.1 is optional)? >=20 > [1] = https://mailarchive.ietf.org/arch/msg/scim/7ElDxpsgHZGRmQrXOTIR1jwuTts/ = > [2] https://tools.ietf.org/html/rfc7643#section-2.3.7 = > [3] https://tools.ietf.org/html/rfc8141#section-3 = > On Wed, Mar 11, 2020 at 4:05 AM Leif Johansson > wrote: >=20 >=20 > On 2020-03-10 21:00, Shelley wrote: > > it is allowed that the schema may be set to caseExact false=20 > >=20 > >=20 > > Is Section 2.3.7 not normative? If not, perhaps that section should = not prescribe a caseExact characteristic for references at all then. > >=20 >=20 > I think Phil meant that the /examples/ are not normative. >=20 > I'm also supportive of going either way on this. There has been talk = of a > 'bis' process for SCIM and if that happens this would certainly get = included. >=20 > Cheers Leif --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

    I = agree with Leif=E2=80=99s suggestion that this is the kind of stuff best = deli with in a SCIMbis group.

    SCIM is badly in need of a = certification test that captures common implementation and normalizes = behaviours and best practices. In and of itself would be a good feed = back to any SCIMbis work.  I have been trying to lobby for this, = but without a major sponsor and host organization, I fear this will not = happen.

    Phil Hunt



    On Mar 11, 2020, at 6:48 AM, Shelley <randomshelley@gmail.com> wrote:

    The more I think about this, the more I am leaning towards = the problem here being in Section 2.3.7, not 8.7.1.

    As noted here [1], I have some general concerns with = "caseExact," namely that there should be some separation of concerns = between attribute characteristics and filtering capabilities. The fact = that Section 2.3.7 requires all "reference" types to be "case exact" [2] = seems overly-limiting.

    URNs, for instance, = are not entirely case-sensitive; they define a lexical equivalence, in = which only some parts of the URN are case-sensitive [3]. For example, = the following two URNs are lexically equivalent:
    • urn:ietf:params:scim:schemas:core:2.0:User
    • URN:IETF:params:scim:schemas:core:2.0:User

    Given this, I would suggest that a filter for a URN attribute = should match on either of the above. However, with the requirements = outlined in Section 2.3.7, a client would need to provide the case-exact = equivalent in order to match.

    Therefore, perhaps = Section 2.3.7's requirement that "A reference is case exact" = could/should be removed (in which case my initially proposed change in = Section 8.7.1 is optional)?

    [1] https://mailarchive.ietf.org/arch/msg/scim/7ElDxpsgHZGRmQrXOTIR= 1jwuTts/
    [2] https://tools.ietf.org/html/rfc7643#section-2.3.7
    [3] https://tools.ietf.org/html/rfc8141#section-3

    On Wed, Mar 11, 2020 at 4:05 AM Leif Johansson = <leifj@mnt.se> = wrote:


    On 2020-03-10 21:00, Shelley wrote:
    >     it is allowed that the schema may be set to = caseExact false
    >
    >
    > Is Section 2.3.7 not normative? If not, perhaps that section should = not prescribe a caseExact characteristic for references at all then.
    >

    I think Phil meant that the /examples/ are not normative.

    I'm also supportive of going either way on this. There has been talk of = a
    'bis' process for SCIM and if that happens this would certainly get = included.

            Cheers Leif

    = --Apple-Mail=_259B415A-8C01-4AA6-A6B8-433F8766B994-- From nobody Wed Mar 11 11:25:15 2020 Return-Path: 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 3AAD83A10CC for ; Wed, 11 Mar 2020 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com 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 sPK7ltPgIQ1I for ; Wed, 11 Mar 2020 11:25:12 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CD23A0140 for ; Wed, 11 Mar 2020 11:25:08 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id x2so1426831pfn.9 for ; Wed, 11 Mar 2020 11:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jugPT61jKYS8XK+qkrLQyJykeBHqyXkKn2vcjRJY+5Y=; b=XZ7cbMvn5CVai4UBgd4aMY+e5rNApWJpczfeSQk/b2mRfxChBLeCm7LnybTEtapu31 lmtLpb136MBd5Mki8CxaxND8j4DNzWPxw+NZHT2XuAlTg1HQVVwRhgPBRECl/hm9pmsS 83usKOGrbDXLA+ixh2j4UBbGEIF3vtOZHFHVOO055EQGFV/YQfkXROUex/3uQf4kQ7Cy eNnt9OqY6K4ndu9Lo0gWv/wvVti445f6O0gzuKRrNKLWErZbLYmi+DBpZm2tBKSyHkxb XgAFGLQ2UCcYwteSJJ89X0QGhY526rU0pWNoWJqSDm6CfVLtQJK+SKoH6YsFLHC3Vz9r 5snA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jugPT61jKYS8XK+qkrLQyJykeBHqyXkKn2vcjRJY+5Y=; b=Lv6/gpytnzTKGZJkfK4pdHBsHZFUc8fFs+e5+aiAi1LAylxzryn57TBDaa923X/gqO 8/UFzQ6U9dlj5tenB7zicmKJmJSRVHuYV+Qr3A+C5vkcmumxhjurhxtqe9Y0VsdbdJTe +s3Cdvd8O95VAzqSUWuDK8FWymhMuSfBfvYxdWYh8zNGSoQZlMONVgvQwn07IwFIeaVO 8jQZ0c0SbaHFAYOJeZIuzMYjAL82+3h2ftLKv2VuhElWAgz0zXjqP8P/arZNIEPyj01d 4tRtlgirTbikaLqH9+N/SJKIc/3U8capRSN16LDjJcS0CeGqqewtpHYOSNFZqFbBIaXl dg5Q== X-Gm-Message-State: ANhLgQ3T73SJvw279idRj+G8ZiSVDujf4i9XtHKfW8TUWfjRHLIgjeBk dX3Xm7sXqcUb3sHi2SWbiPpZCQ== X-Google-Smtp-Source: ADFU+vscD2okRsV60pULmMVrl+cI5Zq1ACdtLYT1gUKVpKbgPJrb7AGnj7+zPhjIGnP/YanileQspw== X-Received: by 2002:a63:b04f:: with SMTP id z15mr3960118pgo.58.1583951108090; Wed, 11 Mar 2020 11:25:08 -0700 (PDT) Received: from node-1w7jr9qqo6k576qbecgh8vj5m.ipv6.telus.net (node-1w7jr9qqo6k576qbecgh8vj5m.ipv6.telus.net. [2001:569:79bc:100:7c37:eabc:16be:5eba]) by smtp.gmail.com with ESMTPSA id s20sm6051475pfm.154.2020.03.11.11.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 11:25:07 -0700 (PDT) From: Phillip Hunt Message-Id: <4694E06E-1207-4364-8B1B-13A4B1B73764@independentid.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_76AD79FD-1FFF-441E-B180-3FD872FEA7B7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 11 Mar 2020 11:25:06 -0700 In-Reply-To: Cc: scim@ietf.org To: Shelley References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [scim] ExternalId Case Sensitivity X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:25:14 -0000 --Apple-Mail=_76AD79FD-1FFF-441E-B180-3FD872FEA7B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Shelley, This issue and the approach taken had more to do with dealing with = legacy systems where some were case-insensistive. Some of the language = introduced was to heard implementors toward a case exact approach. As a general rule, if you are writing a client query: * if schema says an attribute is caseExact =E2=80=9Cfalse", then you can = expect matches on filters that are not exact matches and the resulting = record may have case differences.=20 Phil Hunt @independentid phil.hunt@independentid.com > On Mar 11, 2020, at 6:25 AM, Shelley wrote: >=20 > Section 3.1 indicates that "externalId" has "caseExact" as "true". = However, I would like our service provider's "externalId" attribute to = be case-insensitive, but since "externalId" is a "Common Attribute", = service providers cannot change its attribute characteristics [1]: >=20 > For backward compatibility, some existing schema definitions MAY list > common attributes as part of the schema. The attribute > characteristics (see Section 2.2) listed here SHALL take precedence > over older definitions that may be included in existing schemas. >=20 > I have a few related questions: > What was the reasoning behind making externalId caseExact? > =46rom the perspective of case preservation, I can understand the use = of "caseExact" for externalIds; however, for filtering, it still seems = appropriate to search case-insensitively. > I've seen some past discussions where "externalId" had "caseExact" as = "false" (e.g. [2,3]), but it seems to be "true" in the final RFC, and I = was unable to trace that decision back to a discussion. > If I'm not mistaken, externalId was case-insensitive implicitly in = SCIM 1.1 as well. > More generally, perhaps future-thinking (unless this has already been = discussed), perhaps "caseExact" may be over-simplified? There are = potentially 3 different uses for caseExact, and they may not all share a = value: > Case Preservation: Must the server preserve the case of the attribute? > Uniqueness: If the attribute is unique, must it be case-sensitively = unique? > Filtering: Should the attribute be filtered case-sensitively? (Perhaps = allowing clients to specify case-sensitive filter operators may be more = appropriate than making this part of the attribute's characteristics?) > Should service providers be allowed to change the "common attribute" = characteristics to account for cases such as these? The spec currently = seems to forbid this. > [1] https://tools.ietf.org/html/rfc7643#section-3.1 = > [2] = https://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTtaIam4RmcbhSyCF9xE/ = > [3] = https://mailarchive.ietf.org/arch/msg/scim/NgMipeLaeLlOwpPkrg2Jak7W2-M/ = > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_76AD79FD-1FFF-441E-B180-3FD872FEA7B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Shelley,

    This issue and the approach taken had more to = do with dealing with legacy systems where some were case-insensistive. = Some of the language introduced was to heard implementors toward a case = exact approach.

    As a general rule, if you are writing a client = query:
    * if schema says an attribute is caseExact = =E2=80=9Cfalse", then you can expect matches on filters that are not = exact matches and the resulting record may have case = differences. 

    Phil = Hunt
    @independentid



    On Mar 11, 2020, at 6:25 AM, Shelley <randomshelley@gmail.com> wrote:

    Section 3.1 indicates that "externalId" has "caseExact" as = "true". However, I would like our service provider's "externalId" = attribute to be case-insensitive, but since = "externalId" is a "Common Attribute", service providers cannot change = its attribute characteristics [1]:

    For = backward compatibility, some existing schema definitions MAY list
    common attributes as part of the schema.  The = attribute
    characteristics (see Section 2.2) listed here = SHALL take precedence
    over older definitions that may be = included in existing schemas.

    I = have a few related questions:
    • What was the reasoning behind making externalId = caseExact?
      • =46rom the perspective = of case preservation, I can understand the use of = "caseExact" for externalIds; however, for filtering, = it still seems appropriate to search case-insensitively.
      • I've seen some = past discussions where "externalId" had "caseExact" as "false" (e.g. = [2,3]), but it seems to be "true" in the final RFC, and I was unable to = trace that decision back to a discussion.
      • If I'm not = mistaken, externalId was case-insensitive implicitly in SCIM 1.1 as = well.
    • More generally, perhaps future-thinking (unless this has = already been discussed), perhaps "caseExact" may be over-simplified? = There are potentially 3 different uses for caseExact, and they may not = all share a value:
      • Case = Preservation: Must the server preserve the case of the = attribute?
      • Uniqueness: If the = attribute is unique, must it be case-sensitively unique?
      • Filtering: Should the attribute be filtered = case-sensitively? (Perhaps allowing clients to specify case-sensitive = filter operators may be more appropriate than making this part of the = attribute's characteristics?)
    • Should service providers be allowed to change the "common attribute" characteristics to account = for cases such as these? The spec currently seems to forbid this.
    [1] https://tools.ietf.org/html/rfc7643#section-3.1
    [2] https://mailarchive.ietf.org/arch/msg/scim/ev7DC2ZUTtaIam4Rmcbh= SyCF9xE/
    [3] https://mailarchive.ietf.org/arch/msg/scim/NgMipeLaeLlOwpPkrg2J= ak7W2-M/
    _______________________________________________
    scim = mailing list
    scim@ietf.org
    https://www.ietf.org/mailman/listinfo/scim

    = --Apple-Mail=_76AD79FD-1FFF-441E-B180-3FD872FEA7B7-- From nobody Wed Mar 11 11:49:49 2020 Return-Path: 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 C0CA13A1140 for ; Wed, 11 Mar 2020 11:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 4yS5mmv7iZH7 for ; Wed, 11 Mar 2020 11:49:45 -0700 (PDT) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D833A1143 for ; Wed, 11 Mar 2020 11:49:44 -0700 (PDT) Received: by mail-il1-f169.google.com with SMTP id d14so2517129ilq.10 for ; Wed, 11 Mar 2020 11:49:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F92TdezWv80m3WzlhYKhueawXGKSlc68f0AmYEYdi/k=; b=VzRV7IZNvPKMc7C037mSk2+09oT1QjRLPy4Sac5UrUttdNZgU/wXVMWuAZB5Ou5Bpy AepHCpHwuQP9hLBbXiRk8IG4phHLNdcwwNPt9vap1Gs7ntnez0th271FamYMs1Itxgig gpCyMgrNIp3FEoVspR9bmRvEo4zdxQBzZqXGb/1G6F0HncCixB1wzIiPYflf/RSFOW1S 9lL3qwsgWGfrMlsSa1n7HoUAcbwQksDsHke91LwlIHb0fPgMGObWq32zvX3hxWXnJlJm MDnZeRCFRZ+QzuaFP9R0xJVqDRj5HjUFUWBDPc9dYF7tberjMRdPkkn1lvGPGFjYq4BB MI6g== X-Gm-Message-State: ANhLgQ1e9Dk67qdnKfCbFq8uUk4TexSBMwwE7cyl9H1n+qRFneSz+MI+ 41CLU5Hy8+OyL8THPPcrVCuRwDykdr76Ksooy2Y= X-Google-Smtp-Source: ADFU+vsdXsXc1KLnubBw0OZmBMLRRaAXkgfOCtnmRwH7T3Dg+f/D5B6IC+zl+Qlbswa7h1FudBof1uqug3DMdMFhM7A= X-Received: by 2002:a92:d60a:: with SMTP id w10mr4604782ilm.107.1583952583462; Wed, 11 Mar 2020 11:49:43 -0700 (PDT) MIME-Version: 1.0 References: <20200302171904.01B97F406D7@rfc-editor.org> <8b371853-c39e-4f62-b224-2134aa586bd2@mnt.se> <47F56EB2-8472-49A1-BDC1-37B9F718C379@yahoo.com> In-Reply-To: <47F56EB2-8472-49A1-BDC1-37B9F718C379@yahoo.com> From: Barry Leiba Date: Wed, 11 Mar 2020 14:49:32 -0400 Message-ID: To: Phil Hunt Cc: Shelley , Leif Johansson , Adam Roach , Alexey Melnikov , Leif Johansson , scim@ietf.org, Kelly Grizzle , Morteza Ansari Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [scim] [Technical Errata Reported] RFC7643 (6001) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:49:47 -0000 Should this then go to "held for document update", rather than "verified"? Barry On Wed, Mar 11, 2020 at 2:12 PM Phil Hunt wrote: > > Shelley, > > I agree with Leif=E2=80=99s suggestion that this is the kind of stuff bes= t deli with in a SCIMbis group. > > SCIM is badly in need of a certification test that captures common implem= entation and normalizes behaviours and best practices. In and of itself wou= ld be a good feed back to any SCIMbis work. I have been trying to lobby fo= r this, but without a major sponsor and host organization, I fear this will= not happen. > > Phil Hunt > phil.hunt@yahoo.com > > > > On Mar 11, 2020, at 6:48 AM, Shelley wrote: > > The more I think about this, the more I am leaning towards the problem he= re being in Section 2.3.7, not 8.7.1. > > As noted here [1], I have some general concerns with "caseExact," namely = that there should be some separation of concerns between attribute characte= ristics and filtering capabilities. The fact that Section 2.3.7 requires al= l "reference" types to be "case exact" [2] seems overly-limiting. > > URNs, for instance, are not entirely case-sensitive; they define a lexica= l equivalence, in which only some parts of the URN are case-sensitive [3]. = For example, the following two URNs are lexically equivalent: > > urn:ietf:params:scim:schemas:core:2.0:User > URN:IETF:params:scim:schemas:core:2.0:User > > > Given this, I would suggest that a filter for a URN attribute should matc= h on either of the above. However, with the requirements outlined in Sectio= n 2.3.7, a client would need to provide the case-exact equivalent in order = to match. > > Therefore, perhaps Section 2.3.7's requirement that "A reference is case = exact" could/should be removed (in which case my initially proposed change = in Section 8.7.1 is optional)? > > [1] https://mailarchive.ietf.org/arch/msg/scim/7ElDxpsgHZGRmQrXOTIR1jwuTt= s/ > [2] https://tools.ietf.org/html/rfc7643#section-2.3.7 > [3] https://tools.ietf.org/html/rfc8141#section-3 > > On Wed, Mar 11, 2020 at 4:05 AM Leif Johansson wrote: >> >> >> >> On 2020-03-10 21:00, Shelley wrote: >> > it is allowed that the schema may be set to caseExact false >> > >> > >> > Is Section 2.3.7 not normative? If not, perhaps that section should no= t prescribe a caseExact characteristic for references at all then. >> > >> >> I think Phil meant that the /examples/ are not normative. >> >> I'm also supportive of going either way on this. There has been talk of = a >> 'bis' process for SCIM and if that happens this would certainly get incl= uded. >> >> Cheers Leif > > From nobody Thu Mar 12 12:29:33 2020 Return-Path: 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 8DA793A07CB for ; Thu, 12 Mar 2020 12:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4_M-ieYQvR2E for ; Thu, 12 Mar 2020 12:29:22 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FB43A074B for ; Thu, 12 Mar 2020 12:29:22 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id l7so2583072uap.8 for ; Thu, 12 Mar 2020 12:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vjNx6Xbe0xkXDYLY5FzHOwdPlwwvn/a2UGavwPU3Mnk=; b=pvdPvKKOJE8jXzS6JPBHQCKhDj8rqMvN3yEZHnR6twZ9bArVYmWk0aldtoQ7HvpLzF KvxE7RnvCIzWUiaIVss1rLrRzjEYBQCaSgo49151/bHsc21UJD0BILwGTyJUSU280RpX vyOq2vjo5q6Sd/phu5ZQMmzCF+pO8zuUjqyKZJwD7n/HoG7kYU1J7KSmZwcWdYWamqqR CXL5jGnX1/uRcfAkC22FSPFudqkLremY9CuXI0WrD3CYRp3VN7l1qsaJxiRfQa+ph4DP 8ahqhZBc7RIyhoDkPobATkyzShzWVueXZFwyESxqbOAekhdmOBm2cPmHpXiQp26fVP1O Df4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vjNx6Xbe0xkXDYLY5FzHOwdPlwwvn/a2UGavwPU3Mnk=; b=ntMwLEbVNiErSNEWpg5FZnvkxVRpv0qlUXfndb7CEvZoeYLYIEJEv+nPmtu8wW47kf XTM0bLz2aS1GFbE1xE33ew+Ty66lRhyEfxwhTH4UaSxLhC17/jgmSE950QFyJ5+DvTTI TvXghpW67DK0vo285YUHwHk5GnBkr/SY+H2hiRHir2I8oBbgX48Gbn11Rx9NzwUxlsm9 1W2GdIectscJgR9dX1NtEIfhWDB7q6hxUfhyodyUsbfZUS/PNAFoCup5kDt8dnSB6RqH gzYAeXo9wQ4meysYVc6pUHoHOaCe1V0lqs+5cYdmW9N2jAkFaB6lvdIFgcO6bA5Kl6dP cWog== X-Gm-Message-State: ANhLgQ36EfVeTJmaFnw6+n7I5g622eqJALVyINYhR/0kqHQvREkiaWzl bUqnPZT8rJxg6+y0rXMw21VrxoIdVl0j2n/Pd3h/fQO1cKw= X-Google-Smtp-Source: ADFU+vuEMBwztqEfJ4TjqupkC8hvjW0UttAeKT7K53ZVSFXHJlunfDd4H5pMqfgx2gZsIIgR//VyxjjF/ztO7/Yz4o0= X-Received: by 2002:ab0:7715:: with SMTP id z21mr5920370uaq.118.1584041361445; Thu, 12 Mar 2020 12:29:21 -0700 (PDT) MIME-Version: 1.0 From: Shelley Date: Thu, 12 Mar 2020 14:29:10 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="000000000000a895d605a0ad5e4c" Archived-At: Subject: [scim] Uniqueness Violation Response Code X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 19:29:32 -0000 --000000000000a895d605a0ad5e4c Content-Type: text/plain; charset="UTF-8" RFC 7643 Section 7 [1] indicates the following: uniqueness A single keyword value that specifies how the service > provider enforces uniqueness of attribute values. > * A server MAY reject an invalid value based on uniqueness by returning > HTTP* > * response code 400 (Bad Request).* > This contradicts the requirements in RFC 7644 Section 3.3 [2] which indicates that service providers "*MUST return HTTP status code 409 (Conflict)*" when the creation of a requested resource would conflict with an existing resource, i.e. by violating an attribute's uniqueness. Therefore, servers *MAY NOT* reject invalid values based on uniqueness with a 400, as RFC 7643 Section 7 currently indicates. I assume 409 is the preferred response here, and so I was initially going to report an errata that proposed 409 instead of 400 in RFC 7643 Section 7; however, to avoid dependencies on specific HTTP response codes from RFC 7644, I would propose the section could be updated as follows instead, such that the HTTP response code is omitted entirely: uniqueness A single keyword value that specifies how the service > provider enforces uniqueness of attribute values. A server MAY > reject an invalid value based on uniqueness. Any feedback is welcome. I'm happy to report the proposed errata if there is consensus; otherwise, I at least wanted to bring awareness to the contradiction between specs here. [1] https://tools.ietf.org/html/rfc7643#section-7 [2] https://tools.ietf.org/html/rfc7644#section-3.3 --000000000000a895d605a0ad5e4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    RFC 7643 Section 7 [1] indicates the following:

    uniqueness =C2=A0A= single keyword value that specifies how the service
    =C2=A0 =C2=A0provid= er enforces uniqueness of attribute values. =C2=A0A server MAY
    =C2=A0= =C2=A0reject an invalid value based on uniqueness by returning HTTP    =C2=A0 =C2=A0response code 400 (Bad Request).

    This contradicts the requirements in RFC 7644 Section = 3.3 [2] which indicates that service providers "MUST return HTTP st= atus code 409 (Conflict)" when the creation of a requested resourc= e would conflict with an existing resource, i.e. by violating an attribute&= #39;s uniqueness. Therefore, servers MAY NOT reject invalid values b= ased on uniqueness with a 400, as RFC 7643 Section 7 currently indicates.

    I assume 409 is the preferred response here, and so I was initially going t= o report an errata that proposed 409 instead of 400 in=20 RFC 7643 Section 7; however, to avoid dependencies on specific HTTP respons= e codes from RFC 7644, I would propose the section could be updated as foll= ows instead, such that the HTTP response code is omitted entirely:
    =
    uniqueness =C2=A0A si= ngle keyword value that specifies how the service
    =C2=A0 =C2=A0provider = enforces uniqueness of attribute values.=C2=A0 A server MAY
    =C2=A0 =C2= =A0reject an invalid value based on uniqueness.

    =
    Any feedback is welcome. I'm happy to report the proposed er= rata if there is consensus; otherwise, I at least wanted to bring awareness= to the contradiction between specs here.
    --000000000000a895d605a0ad5e4c-- From nobody Thu Mar 12 14:02:53 2020 Return-Path: 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 EA7E83A0955 for ; Thu, 12 Mar 2020 14:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com 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 71jOq_Hni9_0 for ; Thu, 12 Mar 2020 14:02:49 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0233A0948 for ; Thu, 12 Mar 2020 14:02:48 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id t3so3145180plz.9 for ; Thu, 12 Mar 2020 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=7a9XznBZwld2kxDf0MztGjQs28p/4HwRS9B0hs2idaQ=; b=ZZWsYRBgSvZLUftt5tkNdp/ss9KQnol6qLqxF+QDLiYyRaEn7OsZKQMPO08Nac5MPK sCV4AAvg2abyJuc5cW1NHdbHiHpQPMwpXKTU2ZDQe4jV2oiSZQzdbE27S45GUaTITmtM HtbuamxXqTKYkfGegbSs6Z15ZD30xDlnDjpybtxXJh4mJNPCtqoAC+8YbQMYAezfELwy s9rY9GEWpfokaONmd2gV9LwA/SpcsVmSI0ZCZHaWAWIpTYoIMBuD9vB8pFeUMpW5pIE8 WoR8GoYysM9HelWanGO5n3SvsyouM0tVWjJGKsDWT5ZXS1slDsMsvviDZ+44Mbl3Ay5s 2W7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=7a9XznBZwld2kxDf0MztGjQs28p/4HwRS9B0hs2idaQ=; b=slQo7pQfNcaRf6xRbT7/oUAPhUPbvtmPBHioXW3lgMIed1yiVkb3ZnAXfz7+Ujcr4J 3slD1IyaSH/Ixlpx8KaD5GfTJUmkyA4GAskzrhjENim5vpfkQVgFiGSlbtucBsgE/DVc fX7iZr5I5zhpkQRIV7oxsjAN3LOOmYddkS0YS2GB8KKngoXTvzSMARb2fnDkJtJEayrf SpVEol/WNfDtVreMbWpDMC9pw4n183bI4CySJrqHzSurLC6crQl6KUUcxRSwjvBKnFHD +Iw1IyVD9bVB4ZCsQ9RWAmtbWRMTVnUv0avn7aPHawBVy2bomIaQGbceU26mhk0J6BMS l1kQ== X-Gm-Message-State: ANhLgQ0iFa9NC3xnd1QBWPc+2bzd6XLMQRkw+TLPhIMq4dSEl1jynF1J xHy/K6Xtb0oooHZp6vf03Io8Lv35Zda/hA== X-Google-Smtp-Source: ADFU+vsQP9xsO0gb8g/yrqYl9Ghdme0+1unOLQ8v7Z3+3UnXbuhRtkf1zwhtNhB7lMRrIPBA0Qlybw== X-Received: by 2002:a17:90a:e7c4:: with SMTP id kb4mr5874282pjb.172.1584046968031; Thu, 12 Mar 2020 14:02:48 -0700 (PDT) Received: from ?IPv6:2001:569:79bc:100:85e3:f52f:b363:343b? (node-1w7jr9qqo6k57c0xs7jzcd263.ipv6.telus.net. [2001:569:79bc:100:85e3:f52f:b363:343b]) by smtp.gmail.com with ESMTPSA id v5sm4944667pff.209.2020.03.12.14.02.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 14:02:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-92AC60A7-C420-4DAE-9ABC-0E5D789D34AC Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Thu, 12 Mar 2020 14:02:47 -0700 Message-Id: <38B447C6-4ACA-45BE-8E15-FEC74299DA38@independentid.com> References: Cc: scim@ietf.org In-Reply-To: To: Shelley X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [scim] Uniqueness Violation Response Code X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 21:02:51 -0000 --Apple-Mail-92AC60A7-C420-4DAE-9ABC-0E5D789D34AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It seems to me that http protocol issues should not be in schema.=20 However it is a MAY and thus 7644 overrides.=20 I don=E2=80=99t think this can be handled as errata but rather a good item f= or a bis.=20 Phil > On Mar 12, 2020, at 12:29 PM, Shelley wrote: >=20 > =EF=BB=BF > RFC 7643 Section 7 [1] indicates the following: >=20 >> uniqueness A single keyword value that specifies how the service >> provider enforces uniqueness of attribute values. A server MAY >> reject an invalid value based on uniqueness by returning HTTP >> response code 400 (Bad Request). >=20 >=20 > This contradicts the requirements in RFC 7644 Section 3.3 [2] which indica= tes that service providers "MUST return HTTP status code 409 (Conflict)" whe= n the creation of a requested resource would conflict with an existing resou= rce, i.e. by violating an attribute's uniqueness. Therefore, servers MAY NOT= reject invalid values based on uniqueness with a 400, as RFC 7643 Section 7= currently indicates. >=20 > I assume 409 is the preferred response here, and so I was initially going t= o report an errata that proposed 409 instead of 400 in RFC 7643 Section 7; h= owever, to avoid dependencies on specific HTTP response codes from RFC 7644,= I would propose the section could be updated as follows instead, such that t= he HTTP response code is omitted entirely: >=20 >> uniqueness A single keyword value that specifies how the service >> provider enforces uniqueness of attribute values. A server MAY >> reject an invalid value based on uniqueness. >=20 >=20 > Any feedback is welcome. I'm happy to report the proposed errata if there i= s consensus; otherwise, I at least wanted to bring awareness to the contradi= ction between specs here. >=20 > [1] https://tools.ietf.org/html/rfc7643#section-7=20 > [2] https://tools.ietf.org/html/rfc7644#section-3.3 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-92AC60A7-C420-4DAE-9ABC-0E5D789D34AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable It seems to me that http protocol issues sh= ould not be in schema. 

    However it is a MAY and thus 7644 overri= des. 

    I don=E2=80=99t think this can be handled as e= rrata but rather a good item for a bis. 

    Phil

    On Mar 12, 2020, a= t 12:29 PM, Shelley <randomshelley@gmail.com> wrote:

    =EF=BB=BF
    RFC 7643 Section 7 [1] indicates the following:

    uniqueness  A single keyword va= lue that specifies how the service
       provider enforces uniquen= ess of attribute values.  A server MAY
       reject an inv= alid value based on uniqueness by returning HTTP
       resp= onse code 400 (Bad Request).

    T= his contradicts the requirements in RFC 7644 Section 3.3 [2] which indicates= that service providers "MUST return HTTP status code 409 (Conflict)"= when the creation of a requested resource would conflict with an existing r= esource, i.e. by violating an attribute's uniqueness. Therefore, servers = MAY NOT reject invalid values based on uniqueness with a 400, as RFC 764= 3 Section 7 currently indicates.

    I assume 409 is the preferred response here, and so I was initially going to= report an errata that proposed 409 instead of 400 in=20 RFC 7643 Section 7; however, to avoid dependencies on specific HTTP response= codes from RFC 7644, I would propose the section could be updated as follow= s instead, such that the HTTP response code is omitted entirely:
    uniqueness  A single k= eyword value that specifies how the service
       provider enforce= s uniqueness of attribute values.  A server MAY
       reject a= n invalid value based on uniqueness.

    A= ny feedback is welcome. I'm happy to report the proposed errata if there is c= onsensus; otherwise, I at least wanted to bring awareness to the contradicti= on between specs here.
    _______________________________________________
    scim m= ailing list
    scim@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/scim
    = --Apple-Mail-92AC60A7-C420-4DAE-9ABC-0E5D789D34AC-- From nobody Fri Mar 13 09:16:40 2020 Return-Path: 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 27D7E3A0D64 for ; Fri, 13 Mar 2020 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RHDBJlhaiAaP for ; Fri, 13 Mar 2020 09:16:36 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A7C3A0D55 for ; Fri, 13 Mar 2020 09:16:36 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id t20so3735963uao.7 for ; Fri, 13 Mar 2020 09:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xZfx7WTLE74pEj3EJdGYZi/fMmRmU5IQXSZaFWDR+H8=; b=AfYNE5f+RMi2vs3iWtaN5p3rFzF8LHSGKW2hzvUWsHyC6Um8TiBZI/j2fdf6zhq0Vn 8J0X35oqAsFiZf0mneSLfalgYaY5cAukPnrXDNGWEVl5vCcBkC0JhSpMGJsaTS0CAbWb yGU1z+Iwc65vTazyi1qDAV0KZA3S0NRXhuoSyO7wMPZCWVaomHnmLLW+tBwaeIEyYcom xNWXA4uBK9UyQ5WTe/yC1pynGYunq5uv/XvDyJ38iNdTVwYwZp8MFUyYaxJhCO6iALCa f/aamHyWtvLugHVupgoV2LcQYul4OlKDFqBerzC/baW0FP+bIYQBrvc/u8heDYMixju4 AB5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xZfx7WTLE74pEj3EJdGYZi/fMmRmU5IQXSZaFWDR+H8=; b=cAVsOafVhhHfnLT7IDYcHqjAu4TguS3ykxWh0S2+ri9/cMqJGcnZWlPK271AVZMKoT CRfLaX8ECMGDTR4L+xBots1CnsLYXci6QMtoLl+y5wZ+8ihZqTkVflXgcMRmWEjOW3Al Z6xSuCQyy39Ewru7A9t253tjFpNl+/WUC5wrSA194AUsNYb+mRkh9SSIjSmR+uEgYp6a 5Hd4ORl9VaD4lWskI6pJpfU8jxgh8KSTize0Vr/4qC3YH/UX5ACw0tVYJupK284UWSX0 LE8UPcXLWmWJWyCSlVkAfaVIrO2UpxWBkJVwcU2Oa1WkXSLQ/B/zDabrBjlwr2h89WZ0 go1g== X-Gm-Message-State: ANhLgQ3nfRST/8uC4Oqr9fTD/9gyqUg1yxK+VuQq4se5/g2DHXXnplZC K5OsnIXowplj8knKqgTBCf1P3vvR+gLCqHTiQ+xHaMxjtGI= X-Google-Smtp-Source: ADFU+vv1HCN3uidWrzKunyCA4nVhKRDG5AGfBLCKiMuaxqMyBtpux18Tvt//mss53l+CiPU6wQ19azuYLyjvc91v7XQ= X-Received: by 2002:ab0:2991:: with SMTP id u17mr8877378uap.35.1584116195278; Fri, 13 Mar 2020 09:16:35 -0700 (PDT) MIME-Version: 1.0 From: Shelley Date: Fri, 13 Mar 2020 11:16:24 -0500 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a489205a0becbf3" Archived-At: Subject: [scim] Common Attribute "schemas" Characteristics X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 16:16:39 -0000 --0000000000001a489205a0becbf3 Content-Type: text/plain; charset="UTF-8" What are the characteristics for the "schemas" [1] attribute? Here is my attempt at defining these characteristics using the Schema definitions: - "type" is "reference" - "referenceTypes" is ["uri"] - "required" is "true" - "multiValued" is "true" - "uniqueness" is "none" - "caseExact" as "true" (since this is a "reference" type) - "mutability" of "immutable" (although none of the mutability values seems like a perfect fit) - "returned" characteristic of "default" Although "schemas" and the "Common Attributes" don't define their own schemas, it would be nice to have all of these attributes' characteristics clearly defined in the spec using the Schema definition to help provide a clear/common definition, particularly, since these characteristics are not intended to be modified/defined by SPs. In particular, in my SCIM implementation, I have been considering whether to evaluate "schemas" in resource representations* case-sensitively* (exact case as defined in the ResourceType),* case-insensitively* (any case allowed), or using *lexical equivalence* (e.g. for URNs, case-insensitive schema and NID, case-sensitive NSS, and some components ignored). The RFC doesn't seem to clearly prescribe this, but based on the fact that the implied type is "reference" which (debatably [2]) has "caseExact" as "true" and the fact that the attribute "MUST only contain values defined as "schema" and "schemaExtensions"", I'm under the assumption that this attribute is *case-sensitive*. Please confirm. Thanks! [1] https://tools.ietf.org/html/rfc7643#section-3 [2] https://mailarchive.ietf.org/arch/msg/scim/05_K_y-V26EOfN2F7fuSO3DXoLw/ --0000000000001a489205a0becbf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    What are the characteristics for the "schemas&qu= ot; [1] attribute?

    Here is my attempt at defining = these characteristics using the Schema definitions:
    • "= ;type" is "reference"
    • "referenceTypes" is ["uri"]
    • "required" is "true"
    • "multiValued= " is "true"
    • "uniqueness" is "none&quo= t;
    • "caseExact" as "true" (since this is a &= quot;reference" type)
    • "mutability" of "immutabl= e" (although none of the mutability values seems like a perfect fit)
    • "returned" characteristic of "default"
      • <= /ul>
    Although "schemas" and the "Common Attributes= " don't define their own schemas, it would be nice to have all of = these attributes' characteristics clearly defined in the spec using the= Schema definition to help provide a clear/common definition, particularly,= since these characteristics are not intended to be modified/defined by SPs= .

    In particular, in my SCIM implementation, I have= been considering whether to evaluate "schemas" in resource repre= sentations case-sensitively (exact case as defined in the ResourceTy= pe), case-insensitively (any case allowed), or using lexical equi= valence (e.g. for URNs, case-insensitive schema and NID, case-sensitive= NSS, and some components ignored). The RFC doesn't seem to clearly pre= scribe this, but based on the fact that the implied type is "reference= " which (debatably [2]) has "caseExact" as "true" = and the fact that the attribute "MUST only contain values defined as &= quot;schema" and "schemaExtensions"", I'm under the= assumption that this attribute is case-sensitive.
    --0000000000001a489205a0becbf3-- From nobody Fri Mar 13 10:10:13 2020 Return-Path: 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 353F43A0D35 for ; Fri, 13 Mar 2020 10:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com 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 KjKDoUPZKCSY for ; Fri, 13 Mar 2020 10:10:08 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA673A0F20 for ; Fri, 13 Mar 2020 10:10:03 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id g2so2044546plo.3 for ; Fri, 13 Mar 2020 10:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=UtERYICu8uzhypDKY0gjy8w5OrQa+FEvDKuBraahatE=; b=b/jZ4fE0+bvtit3mtgbKzJIbB0yRs8fYkkSkzv+EZTalFz61yj8GMmA+0enwcWFrUY LvPQrAbj0nLJEPFeDTJ0BT0Q3Vhl1ERoQGE669jIyl6o14bWH93Wp7EZVZ8W0U2k6MSp Hf+4pSZtsUSsafN1neYCB9lGLIB5l+KsP/qzwWvZtl78g0d9n8jl2GyOjQMxzEsA4BAx Vv8ccIeqqWL60KCDbNZbyWnt3K1Y8Tpp59O7PACzyEY/Uu3q2piquLT1MkF4IJ/S+7bv X82MTlHhKdGchnosCqDfh9/pQKvrL/3qOIIfgwfZLxCA/xF6L48AmRxwcWxMJPuAAP1X 8RtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=UtERYICu8uzhypDKY0gjy8w5OrQa+FEvDKuBraahatE=; b=W5w31/c3Pq7WCmU2K6TH0wQP9O8MQ0NWASG/EWtGGArHR+VhxWrooZL4gfu9m30U57 aX5Oui7G7K+GpiNxiC0eDVMuEt/ea/5jUNHGqEEJRh5V1FfVbeG1Loc2hd3/OFWhp5/k erCxoGad47pcobVE/OkPdBbFMv68YtNApRHpahWna7R/NlghHh60XmcUwcI+aVhQSuEH dUiGfMSBKaRbRpFmSoJ9+eGGBKlSyvPnkS9RugMNfRNox8AtxhQsUm/G7IAtJwPFDQgl F5Q8j4CdbhYd5tw5N39NjqtgaSCXNoiwWOL1e+KKCe8BAPUbuEKl5fSsgO7zeWDqAtfe /NMg== X-Gm-Message-State: ANhLgQ0Ge+3OzwrNGHbaLPxA1VY1XB09CmiYE8z9+ItyBx8K5V/e8OA0 Es+GmMDQdhzTHlMjHa9p6LvAkqeBxpyXYw== X-Google-Smtp-Source: ADFU+vtL1vmaaUxnJ462vDY8lDO+irMvuyh2kZxuqDw09NAvLVFQGbVe5EitwsNcSi4PU7+aGqRU+g== X-Received: by 2002:a17:90a:c301:: with SMTP id g1mr10743101pjt.173.1584119402409; Fri, 13 Mar 2020 10:10:02 -0700 (PDT) Received: from ?IPv6:2001:569:7a71:1d00:2462:8c2f:9c84:faea? (node-1w7jr9qrfoxx82t2v4x3ldqzu.ipv6.telus.net. [2001:569:7a71:1d00:2462:8c2f:9c84:faea]) by smtp.gmail.com with ESMTPSA id d206sm245744pfd.160.2020.03.13.10.10.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2020 10:10:02 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-CD877E00-0EAF-4EC9-887A-0371B1C194F4 Content-Transfer-Encoding: 7bit From: Phillip Hunt Mime-Version: 1.0 (1.0) Date: Fri, 13 Mar 2020 10:10:01 -0700 Message-Id: <0BD1BB04-7957-441C-AB72-C4FACA2C9668@independentid.com> References: Cc: scim@ietf.org In-Reply-To: To: Shelley X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [scim] Common Attribute "schemas" Characteristics X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 17:10:11 -0000 --Apple-Mail-CD877E00-0EAF-4EC9-887A-0371B1C194F4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Shelley In practical/pragmatic terms...case insensitive.=20 I treat as case insensitive since it is unlikely and unwise if two separate s= chemas only differentiated by case.=20 I would also expect iana process to reject =E2=80=9Coverlapping=E2=80=9D reg= istrations differentiated only by case.=20 Phil > On Mar 13, 2020, at 9:16 AM, Shelley wrote: >=20 > =EF=BB=BF > What are the characteristics for the "schemas" [1] attribute? >=20 > Here is my attempt at defining these characteristics using the Schema defi= nitions: > "type" is "reference" > "referenceTypes" is ["uri"] > "required" is "true" > "multiValued" is "true" > "uniqueness" is "none" > "caseExact" as "true" (since this is a "reference" type) > "mutability" of "immutable" (although none of the mutability values seems l= ike a perfect fit) > "returned" characteristic of "default" > Although "schemas" and the "Common Attributes" don't define their own sche= mas, it would be nice to have all of these attributes' characteristics clear= ly defined in the spec using the Schema definition to help provide a clear/c= ommon definition, particularly, since these characteristics are not intended= to be modified/defined by SPs.. >=20 > In particular, in my SCIM implementation, I have been considering whether t= o evaluate "schemas" in resource representations case-sensitively (exact cas= e as defined in the ResourceType), case-insensitively (any case allowed), or= using lexical equivalence (e.g. for URNs, case-insensitive schema and NID, c= ase-sensitive NSS, and some components ignored). The RFC doesn't seem to cle= arly prescribe this, but based on the fact that the implied type is "referen= ce" which (debatably [2]) has "caseExact" as "true" and the fact that the at= tribute "MUST only contain values defined as "schema" and "schemaExtensions"= ", I'm under the assumption that this attribute is case-sensitive. >=20 > Please confirm. Thanks! >=20 > [1] https://tools.ietf.org/html/rfc7643#section-3 > [2] https://mailarchive.ietf.org/arch/msg/scim/05_K_y-V26EOfN2F7fuSO3DXoLw= / > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-CD877E00-0EAF-4EC9-887A-0371B1C194F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Shelley

    In practical/pra= gmatic terms...case insensitive. 

    I treat as c= ase insensitive since it is unlikely and unwise if two separate schemas only= differentiated by case. 

    I would also expect i= ana process to reject =E2=80=9Coverlapping=E2=80=9D registrations differenti= ated only by case. 

    Phil

    On Mar 13, 2020, at 9:16 AM, Shelley <= ;randomshelley@gmail.com> wrote:

    =EF=BB=BF
    What are the cha= racteristics for the "schemas" [1] attribute?

    Here i= s my attempt at defining these characteristics using the Schema definitions:=
    • "type" is "reference"
    • "referenceTypes" is ["uri"]
    • "required" is "true"
    • "multiValued" is "true"
    • "uniqu= eness" is "none"
    • "caseExact" as "true" (since this is a "referen= ce" type)
    • "mutability" of "immutable" (although none of the mutabili= ty values seems like a perfect fit)
    • "returned" characteristic of= "default"
    Although "schemas" and the "Common Attributes= " don't define their own schemas, it would be nice to have all of these attr= ibutes' characteristics clearly defined in the spec using the Schema definit= ion to help provide a clear/common definition, particularly, since these cha= racteristics are not intended to be modified/defined by SPs..

    =
    In particular, in my SCIM implementation, I have been considering= whether to evaluate "schemas" in resource representations case-sensitive= ly (exact case as defined in the ResourceType), case-insensitively (any case allowed), or using lexical equivalence (e.g. for URNs, ca= se-insensitive schema and NID, case-sensitive NSS, and some components ignor= ed). The RFC doesn't seem to clearly prescribe this, but based on the fact t= hat the implied type is "reference" which (debatably [2]) has "caseExact" as= "true" and the fact that the attribute "MUST only contain values defined as= "schema" and "schemaExtensions"", I'm under the assumption that this attrib= ute is case-sensitive.

    Please confirm. Thank= s!

    _______________________________________________
    scim m= ailing list
    scim@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/scim
    = --Apple-Mail-CD877E00-0EAF-4EC9-887A-0371B1C194F4--