
From nobody Wed May  9 14:52:20 2018
Return-Path: <olds@vmware.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BCC12DB6E for <scim@ietfa.amsl.com>; Wed,  9 May 2018 14:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.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 ciABgVaUW5me for <scim@ietfa.amsl.com>; Wed,  9 May 2018 14:52:16 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0078.outbound.protection.outlook.com [104.47.33.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574D0129C6B for <scim@ietf.org>; Wed,  9 May 2018 14:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9vtS72tqGnUEBC08G/Z27lNl4k6hgS6t5NMKnWvc/DA=; b=ATNFsR5fuJZ4RHP9zj9/xT+TVvgEMGII2U1bm240M7TVOMyp/71VjzPF4bQGC4fTc7HCQX+mmn/b8MV9Ew2YwcLzOssrsILBbQuzSzRjVC54Oba89UnsYFvRkPMo9lSKzicYA/OzjGjTFwmvz0VnqjnwZtHOP0cD5y3uC2bpuV4=
Received: from [10.33.98.142] (66.170.99.1) by DM5PR05MB3657.namprd05.prod.outlook.com (2603:10b6:4:3d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.755.15; Wed, 9 May 2018 21:52:14 +0000
To: scim@ietf.org
From: Dale Olds <olds@vmware.com>
Message-ID: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com>
Date: Wed, 9 May 2018 14:52:09 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------5AE0E3DCF2A2ED63E7D18D68"
Content-Language: en-US
X-Originating-IP: [66.170.99.1]
X-ClientProxiedBy: CO1PR15CA0090.namprd15.prod.outlook.com (2603:10b6:101:20::34) To DM5PR05MB3657.namprd05.prod.outlook.com (2603:10b6:4:3d::26)
X-MS-PublicTrafficType: Email
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3657; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3657; 3:x49GWQFLM5JNSIekNsW5VaYeS6ie7oZqgNP/YlrGzPG87kyeQ7SPRBpuEKmM0M5pkDWL/h/6eyapBqYxzMjblDHhqyVWMDgVttnL7qxlUJwRD88rRMQLDdU0fwc/4L5eQnETEZZapigouiMhD/VQvOObUGW8+YTFaU+lE18unzZo1nsCXqnd1iJKbryatWyy/Epmgbgq9YMUqYNvaV041a3m+Mk9jXVOTZjxVLsK9Ddvp36CVaq90T2wi0vSG9sZ; 25:XX3WTKA6d6TsraWfjqhQzudAWFSzIcTxj8rDRZbgzMDHCyI8cLabJ3ukYnLz7rzKItQTQeX/2J9MaDLogSAEFXYmWLzNbbFfrwO4X7JmAag5HrmvmGYZtAowWDHJP9OzgIciK+FLF+8lTx98LwxeVOBFmQanW0jkXxwqE8mSII59G54qP34cjKDP6J9KOdyecTd3w/FE5SI1D13EwYhzg4NS6P1FDGtQCW5Hf1aOQHwb7SUtp2JfnD0Hg0wW7bvZpGIjQ/DqtGli426Y6M0ohGev+CeEX4BzxnTwBp6LuljXCE/f9UNB51BlNnW5cW0s8QBwN5j4ZVLIIcg5CpuvRA==; 31:uFHfTkbR2n4SvEjGrzkSzKikWD16uPJjVg6prJs1TPulaTAh0vc0z6IaxLW0v8y641uxWU18PdoRgjT91zyyXdzRD54n1D7ms2+WBBdQf+v5bsiMvR1E8HTxMbHhK/KS2eoRDeKP4HjtDZLCwr744GcuLtz0czqrQadPTDN5whTIatSWZzgOv7NihgCu/gwdpMz9/cUHdHfihgTTS+aUTz15On/gMWKgQazcd8yy5BM=
X-MS-TrafficTypeDiagnostic: DM5PR05MB3657:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=olds@vmware.com; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3657; 20:9jwlY2oANxrFgrLsK5+O1pWdI/jQQpHhQyFORQUXXaFAddW2QJEA58Tay8zZX+4uLotPOmJZnfXade5jnpOy9Nmd2GnBSoJ58zXx+SqOncxeYCL+lO3NOQrsP7O8LCmUo3jrli6Yh4H4fewSECsvB5nN92QSW+GeT3TBH2+sm1ujMrjfs68PWHdUFw5gitUQUn43lyYdQy47mVGN0zzLO5XrNozKSjwteBl8jLq5/3CMrCsId67RwPDd5nuPqLyxXiz7ULCz4aVfqTh7OzUu85qEnWu7vedbaJDxWaLDhmgSqxr8328oWAc/WzB9dzq2TncOwb5jvNcYOvxf7ZY8ZdMFsV5QDv4/VrAz0B7HqYZ6eIhseSUUPqZzFY/d035fMu8TR63YjcbgPqDvGUGidrZdg1Qf0UscinnjuzMUQ1nXo+L464eWT1WQ0VNDxlZyDzgTvaoqXz6MZMKysDjD4my52n8iEVD9o/ftI1Ib6/E6IzFeXD+Ym0LqhxJ3kzZj; 4:w2YSWffuKYdeeEU/2+rlKtp0/Bo8jFt+n+wEVl/fuV7UCE2ee4MQKmzEeqm8K+Fo8vqSpVJrGmXvl1W1EZbd+afDHjhgnsgTn6cGoogyrI53aAUbCotOTa3MzCdfoBtE9wZcPHhsBODusrvz7H4VRSEd+F2zzSGZrxM5M8j8gJQcX7o8AJ2438fgkEjhUP4ZuQXlf7Vc+Y+Bk4Q0bid9XhntZNrvYAyT0ujsNIByQjnWwgeTS0ytohcC2CJu5gLMOmSceGvKR8M6KZXsmSSkSLIvrv/+fWm0DHyz5ZyvR6737ivfI8L6C8Totk0FeiMI
X-Microsoft-Antispam-PRVS: <DM5PR05MB365708F6B72D5CC7D219C7E0BB990@DM5PR05MB3657.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3657; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3657; 
X-Forefront-PRVS: 0667289FF8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(366004)(39860400002)(39380400002)(346002)(376002)(199004)(189003)(2351001)(25786009)(16526019)(77096007)(68736007)(2361001)(8936002)(186003)(37036004)(65956001)(386003)(316002)(66066001)(65806001)(270700001)(26005)(105586002)(33964004)(54896002)(16576012)(59450400001)(58126008)(52116002)(16586007)(84326002)(81156014)(106356001)(81166006)(31686004)(65826007)(8676002)(64126003)(6116002)(2906002)(7736002)(6486002)(956004)(6916009)(97736004)(86362001)(6666003)(478600001)(5660300001)(2616005)(486006)(31696002)(476003)(36756003)(53936002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR05MB3657; H:[10.33.98.142]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
Received-SPF: None (protection.outlook.com: vmware.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3657; 23:ZLBCL6eZKVmEee/9IBHjPI35v2QJT/pu1kIu5x2K3?= =?us-ascii?Q?xQiSTUo/npyu/Yo7HEwUdGM1KuNc6RZpIJbOf2vod4+q/VLxTOBpHj43iYp4?= =?us-ascii?Q?tjEzhTrgPPMYTTewwJ69ZIw+YG7tBtTXiNyav5Us2yzW9DBsE++YaSiCHhg8?= =?us-ascii?Q?RGEQNsxNwCqFxHEMrHvUyQKdQQvzFFjfl6OzhuJxIqasJgm/yYiMawLWH13W?= =?us-ascii?Q?962Ab0TS1Rr+mEk0nOzZcsySbEOliQsvmbdAusE+K7yqZlwV8PO+qT3DXT7E?= =?us-ascii?Q?3ilS3AUXeN/BQZiK5iFp59YxjGNx+qJ6zfWNQNdupkLTxl0oAbbqXbjKgYmV?= =?us-ascii?Q?0wadoKAaEzjBXdlDV96o7/bCtsuZ5b+nZXmkBjsrlzi8j5K5Se0R2OjMKgYu?= =?us-ascii?Q?F3Qo7/DsfCYD0UFnzDH0GON2CpuUL2d6N9+GEcqXXN4CpV398sWteeKQocvk?= =?us-ascii?Q?Lcck4Aeq3iP0AlvlDRQHLeGYzhtnZ7ASZZ5sWh88u8rA/zZ6p8IldoyR2nTA?= =?us-ascii?Q?V+Ptk/+xAezyIy0N+EpHEEPijYZU1OVllYaLbMYBqe/YKRzsk+2Xcda20xZr?= =?us-ascii?Q?o9VXYdgcUk6oXgS+hfqXqThxFd/Nc+XZIHx47DAX527/3ZtKdt+Wp5JVpJbb?= =?us-ascii?Q?7vjCz0j5p4L85TI6LISDV/TG0oNAUOKE4d/YvaC9JHMHo0Z4qXfW1Us2SmZ0?= =?us-ascii?Q?U4fZEvaZkYhKs6VeERvCJdtfXnE6u2fuNfG0zK7OdxQ3xUaoP/I7cifzEGYK?= =?us-ascii?Q?QFlPpZ5SmgxxKwRxpn+qR6/zxOUJFJSdJT+Ysn6pQovkW67jBR+46gTq6IyY?= =?us-ascii?Q?sCsnqq8ZsEUou4d6SgfUs5GUIHcFPDtxZHSjjhWK52hFWL+CD83LNrUFMPup?= =?us-ascii?Q?8N5dN4nLkCNL/u2voJEUUGSxcsYzQd3k7sENr8baD9aiodx3u5iTdyoP5DCA?= =?us-ascii?Q?ccuFVY+rSz4A/mr3OCEFExkwxdeoHIAr3HLcSAm4rw9Y5MAj1V9vrqsD//Fq?= =?us-ascii?Q?gwtyyJFljMxrplzUdQUH4bf326LKBprIp45pySnNgd3XafLKBl9ttXaUoxjK?= =?us-ascii?Q?YS6182WO/TRK7aoVXddbgMqLoGHi+DN58s83FkiDhzKkUz4uwtsQwF+CO8E9?= =?us-ascii?Q?/nuKaWxjgBY/jnUkWZYclPs9LnfzPSOq4mHNvEz+DWE9S7RlgXo7NWNvi8KG?= =?us-ascii?Q?lqiymyKznzWktpFUnjJlIaDlMMpWwta9nKFOLFQbjjkfR6FeH/AvLv1dvDmt?= =?us-ascii?Q?6Q/45ZZzcdGkC1PDpUYgV1jWyRDJKZNMpk5H76t4/5o0NMjl2pOk8ca2CwGD?= =?us-ascii?Q?gs3ahzpZ0lEIJHtc+REUCk=3D?=
X-Microsoft-Antispam-Message-Info: pUt46TBJV9qvknKQUmuh7C1/vr+rKXbg6FNWxUk3Nn+S63gyapg0dNdkqUJXCznF1nNvl4OO8NCFdP/Kjn1SWBSTZqy7mpYZM7IgTfe2EMPGWZSbkGjrMVSWLdxIoeSdHngmTl7GwA+A5o/qfv+yCfr+rLUjssJfJZDDMbjOiOhnY1xUVHKllFQLaq3TS19S
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3657; 6:8jHX18Xrz0yKqWmISqjUPl4Tk6hNgV+0Ns+TWy7P4CS4r1D7rftWCGo+4gtdrmdKIp/xGPpsUkYDfgpbWGLfnVZA1C40UBlf8ywMsHFvnfRzdadFJL/nHRNX3frSq2GaXKQZ7EkS4r1wsDa2zzAzWL9LccgM2AjJ9AiXQUPPP1tO6bxwhUst/zH7PohTSmhR73ImkgClZproRNEMvNezUypeVWemZR4Y3cvCAjsaD0BNYajSc0x3Wgua22IrflbtjorAVHywGOytWoVtG3MJdzBXjJg4DWpbPjTvZA7TxLa8EoK8KdFRQNNJkxF/Jsx+2Tswx3BEiZEfrbJnxYeNIGSVDP6GqGItFYO0J/ZzDA7J8nQstn5JYGtJsNCqrIIM6Pot7MjsUPUB+p23QdKTuVbjTnn8BF4hL6V/GNLlzsd6U4c0OM7H9uDTA7S6QtmqWes4/LlsN+AGQoETljj+Lw==; 5:KafUkzLzRJF4F01Ac0vHyqctwuKqDcU76b/1009IUQq3XOM1NyUCxsTraitjz5iivnrYEQqu0r0oDF2GsCP0wka/6NzN/7fBFsLI7dbeKXusjoN7zE0mh95XhlPPd7xmMuZURW3D3GIe6rKbz/zsIhbHRRlPBaXVGI8LsiIszbY=; 24:ubu241tslw3pXVVfeEs11N293tPmj4t9W+HeRaU/n/JK+TgPOGAXZK5LzGKmPuz3kEMysEUeNeqMA7vVyvC9Tu/dzruG+LU0EZ4rHoLhcXw=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3657; 7:hmXSuyByjQzrhR3j7v0salZJL6Jzg1+IkbI5HsOCObY8Q0nqD66LNFQz8ieok0wDPSqE6kiIhRBJ8gXGhFyVFd9qGtL6zlrOScfqxrtaN1jMcVY7AVyuBdp51M0saf4es0z/MUiGD7SW9GmJz+bcyn8dBpJLVu0EHgwVMQ7X3PtJXT5LwIsLq1Hn/dA9alXmUeIvaerAuciV/VND9Zu3tBJRvYEwUu2WN+LdQL2v2WcOaJgjQsV5d9alicGnC4Ec; 20:EwbnQlIEjylSu+PSlUKf7QmU0rRTPKDSfcQyj1298We4JM9+IVI07wM99PvcE49DwmUMOjM7ijGyKHMIdNqHflL4rcvjzqOuXp0LE4m3p+P+U8wF5LoFDStVqjf8iCNGOPRI+tCnBV+ac4QccfigX3rAH2o4WWgPMSAI+T6VVE4=
X-MS-Office365-Filtering-Correlation-Id: 7b5f8c2f-93c3-4a31-411e-08d5b5f7201f
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2018 21:52:14.1190 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b5f8c2f-93c3-4a31-411e-08d5b5f7201f
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3657
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/8cn3t7Ub9WpUFngL2ZTFVFku_qg>
Subject: [scim] unknown attribute type in attribute selection parameter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2018 21:52:18 -0000

This is a multi-part message in MIME format.
--------------5AE0E3DCF2A2ED63E7D18D68
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I have a question regarding how a SCIM server should handle unknown 
attribute names in an attribute selection parameter. The SCIM 2.0 spec, 
section 3.9, defines the "attributes" parameter. We're seeing an 
implementation that returns an error if one of the given attribute types 
is unknown to that server.

 From previous experience working with directory services it was very 
important that servers not return an error, but simply ignore that 
attribute since resources will not contain a value for it. This allowed 
for requests to be coded in a more portable fashion. If an app really 
needed to know what schema was supported, it could query the schema.

However, in looking over the SCIM 2.0 spec, I can't find anything that 
would directly address this case. It is somewhat indirectly addressed in 
that I can't find an error defined for invalid or undefined attribute type.

Is there an expected behavior for this situation or is it up to the 
server implementation?

--Dale Olds

--------------5AE0E3DCF2A2ED63E7D18D68
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I have a question regarding how a SCIM server should handle unknown
    attribute names in an attribute selection parameter. The SCIM 2.0
    spec, section 3.9, defines the "attributes" parameter. We're seeing
    an implementation that returns an error if one of the given
    attribute types is unknown to that server. <br>
    <br>
    From previous experience working with directory services it was very
    important that servers not return an error, but simply ignore that
    attribute since resources will not contain a value for it. This
    allowed for requests to be coded in a more portable fashion. If an
    app really needed to know what schema was supported, it could query
    the schema.<br>
    <br>
    However, in looking over the SCIM 2.0 spec, I can't find anything
    that would directly address this case. It is somewhat indirectly
    addressed in that I can't find an error defined for invalid or
    undefined attribute type. <br>
    <br>
    Is there an expected behavior for this situation or is it up to the
    server implementation? <br>
    <br>
    --Dale Olds<br>
  </body>
</html>

--------------5AE0E3DCF2A2ED63E7D18D68--


From nobody Thu May 10 19:19:57 2018
Return-Path: <phil.hunt@oracle.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6809A12D7F1 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level: 
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 QmMT4lja2SZ9 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:19:55 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF93D120727 for <scim@ietf.org>; Thu, 10 May 2018 19:19:54 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4B2G2c8148074; Fri, 11 May 2018 02:19:53 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=Ykz8nk9bXC6OE76CRV1tK8GTtxHJ2aYeEns8rbmKhx0=; b=wILu6mcZpA9S7bKdmo9TWb/9e9FPU1J9T7ck29zYB6xRwtwtoCWeVMIvSwMAIoamG6r2 ofWrWgd3lq2D560WcWCsInBnLazervPPtSlvhczOQb2IEmox4bWHJQZ+m2vqgBTeDH4E F8KJOt4pVCsy7Qr7mBqn+whb9PeY1NrJBfnx8gvQlu8Wm9HYaFs36EI9JSZ7E2EOZz9V GfdNC/93+Fj6MNxN5+vss/KbpJRp8XfEYc+FX5g5/SWaLA2/3W9tA6LzuozoTP3d4fXB xtOEQ3qC4KUB5BHgpJwmLaOcWgW5+JVQUL47sXM3zxsAlTK6mqRnsHW3bT7P5OMK9aVo /w== 
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2hvth91yby-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:19:53 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4B2Jrbe020287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:19:53 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4B2JqI0017446; Fri, 11 May 2018 02:19:53 GMT
Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2018 19:19:52 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com>
Date: Thu, 10 May 2018 19:19:51 -0700
Cc: scim@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com>
References: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com>
To: Dale Olds <olds@vmware.com>
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8889 signatures=668698
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110015
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/9-YblfXtFT7VACquMJu64bPN9HQ>
Subject: Re: [scim] unknown attribute type in attribute selection parameter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 02:19:56 -0000

Dale

I believe your view is correct.=20

The spec is a bit weak on the processing rules for the attributes parameter.=
=20

One would expect behavior consistent with the filter rules which say undefin=
ed attributes can be evaluated as null or false etc.=20

Phil

> On May 9, 2018, at 2:52 PM, Dale Olds <olds@vmware.com> wrote:
>=20
> I have a question regarding how a SCIM server should handle unknown attrib=
ute names in an attribute selection parameter. The SCIM 2.0 spec, section 3.=
9, defines the "attributes" parameter. We're seeing an implementation that r=
eturns an error if one of the given attribute types is unknown to that serve=
r.=20
>=20
> =46rom previous experience working with directory services it was very imp=
ortant that servers not return an error, but simply ignore that attribute si=
nce resources will not contain a value for it. This allowed for requests to b=
e coded in a more portable fashion. If an app really needed to know what sch=
ema was supported, it could query the schema.
>=20
> However, in looking over the SCIM 2.0 spec, I can't find anything that wou=
ld directly address this case. It is somewhat indirectly addressed in that I=
 can't find an error defined for invalid or undefined attribute type.=20
>=20
> Is there an expected behavior for this situation or is it up to the server=
 implementation?=20
>=20
> --Dale Olds
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dpb0U4X3Kl2WACP79HHA7FmtCf=
g6YoFmk97APnIwAGrM&s=3D9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&e=3D


From nobody Thu May 10 19:34:26 2018
Return-Path: <olds@vmware.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DD512D80F for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level: 
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.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 yd_ZKRdgcgwi for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:34:21 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0051.outbound.protection.outlook.com [104.47.36.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B99B12D80E for <scim@ietf.org>; Thu, 10 May 2018 19:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HKhiDswTf9brQJDQDCNJZg9chJCekPzxgpc+Mc25mBw=; b=CbUsWfrG+ySdFfbfIG7QuYhz+/r0sgmfVVE+GdDAG17qAOn/bCUlUgTv9ORRciokPKi1VlhorTurRanIJQ6f3oeRCnFi/wQYLoqULAIRjxHE9Sjg0PDTwkvq89mFi/8gqUXLFE2SHk5YbHS95EIvYusfxMJF4MUc5L8xvo9UclY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=olds@vmware.com; 
Received: from [IPv6:2601:646:c103:10ff:21cf:ef2f:8885:d67] (2601:646:c103:10ff:21cf:ef2f:8885:d67) by DM5PR05MB3658.namprd05.prod.outlook.com (2603:10b6:4:3d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.776.4; Fri, 11 May 2018 02:34:19 +0000
To: Phil Hunt <phil.hunt@oracle.com>
Cc: scim@ietf.org
References: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com> <9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com>
From: Dale Olds <olds@vmware.com>
Message-ID: <8d8688e2-cbcd-d6ac-cf45-703794a30354@vmware.com>
Date: Thu, 10 May 2018 19:34:15 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com>
Content-Type: multipart/alternative; boundary="------------F152A866F07CA0D1F31056A4"
Content-Language: en-US
X-Originating-IP: [2601:646:c103:10ff:21cf:ef2f:8885:d67]
X-ClientProxiedBy: BYAPR03CA0035.namprd03.prod.outlook.com (2603:10b6:a02:a8::48) To DM5PR05MB3658.namprd05.prod.outlook.com (2603:10b6:4:3d::27)
X-MS-PublicTrafficType: Email
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3658; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3658; 3:EsN50GEUzqFUuXXiwCYDNAbJyvMFMIURCErZ3Wsu7V9zSEvjo8EY98ZWgRBPBDyCyQXsiD7NEP+Bm4YIVj+Cq10xReDpfLm2mbjopM8WkqF+PQhPS+l9wKRXnS6TgnbT+5FKKuQswU0K+V72TdBW3kTfrX+RsviSFoy8uQmYNtY4PLVHR1lDZBW/SHt4BLEc8sqDOP692xcwc0dH8dI3kF8rdD1LxMGHwY01NFGzE/L4brsb6GTFaAbrP1107XDH; 25:HWhP/Rs0Ns0Yf6dCHqveHnvmdX0hyNyjGerftDAnEAWgeCHLitbSzGfMy9yUnXXNQTvYlveMuJD61cDfEel9XPCAol+bFvTYwLGzzX71xv2nNdftX7NNye7CiqyGhj2k5l8V2upbNJZJtWQdctJ0IUz+9k0lw9IxX834EjjJUwzEjrt4ytofyHp72EbRUcPl4n0pzbJbk8jpRjNcItM1S3y5UutdeqgS4KqF0WswUIovwl8PxSJBIAckUITbPy44vFxURfCmc+hr3ZXbFBbTZKRkRH1g3ZlJWXjPv4Gk9PJzS0wcQhnpc0yL7rvNQ9YjmIGEtVuzaHwdYkWnuNEwCg==; 31:nenAwYRJp/XavjO/E4Z5RDnsTrzDBQhv/QZiQd2fRM3ZWwIEaCmGIicAx3pCQIopmhq7o4LX72fdMKnjmBBVH0aIpFjvaZiJ8Op+qQYWaGJIqfBwIj+Bus79t3bqJ0x3VdB1KnQGDjGXLbCP6XGO+6rQSKdEBoV1z838NJAk+Vv1yoU0EFAmn+J7sd8IDRI/cvB0morzWbw/tEgcpqKm1dfHSeY6OMrMguM1kV91c9o=
X-MS-TrafficTypeDiagnostic: DM5PR05MB3658:
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3658; 20:FkoMZT2nETsjTWH6+pyR7BvTcFetXtx7wn5XAYp2tFW78STXy3V/1VKMan/FAmAY/Ot5EGIQkQ4OKttnIuXe+3xAeVLJhf3IHEdBWrDlOB0BcUY9gXkRGq45MsPvvZyH3Gk+O6+rnkdJ4d4eiJ8TankbJjIoqKcwsbnrt59A7Dr5dhAfxNWgYh/D8bxklg8TUcicFat+aiYZ67d+BV8pBmOI7fcszv2w1goMkzDdO/AlA89gIsKToTw/ZXQM3JPWBIsyq44O1fIgTTePn9OuPicMSHyiUIz6Xq0lC8hbUGo8NZ0qKBMo0Uk316AwqWjZn6W4oI+hLg4+9KElMPyeYy7lHGgdI1/oW7PtUG7RsPNxbgIG7bz3wHahvd4apdH0XElhpCoIigm3T5sVLdAt4Y7M0yJScSEK1cMt0JpS3owozAKOONC0iMBafe+mjTUtVpqqmpHRqgABS9miRdpx+vpjZx/djbiYxrLN+pJB8n7TG/X8d0BrVADee2T/4CbW; 4:lnpGhlajXV/1oJiX927uimbM2VApxlW9uzVAs+0Gu8WTxOtA49NLjMy5E5z2oujnttgDzl70vVAh6bPN60lwzgv+jmDRyTLKo3GI9JLgc0XAvJ296nm3RRKg7ZZIUetv6NeixxMaMfPYOb+qydhOUxf2kqIK1XL/PV77TnbwFcXs7lHVwVvs/QZrMih+HCEOqebcplIpByZNXKz0+Jk3Szr7LZdi07lj6DsXgy6RokSNLaKoierYl6OWQkpt7G0dy18FX6rpYY5Hn2uTLcJnlcrFliSnvqF6f2H2zJJJai10Q9dj3Y4pHpj7OsUeVbj3PtYCHFTsypZ8l7zf5sXat9X77hADG1YKbUNXA4bD+gPhOfl/l7gyjc6GZU0TDXejcO/SOBVXrd5lf8QYjRS1HUp6ND0gjPul2zYgQD1qBG4=
X-Microsoft-Antispam-PRVS: <DM5PR05MB3658CEF53319CDA31DF0AC33BB9F0@DM5PR05MB3658.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(61668805478150)(158342451672863)(10436049006162)(146099531331640); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3658; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3658; 
X-Forefront-PRVS: 06691A4183
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(346002)(366004)(376002)(199004)(189003)(86362001)(966005)(575784001)(31696002)(59450400001)(65806001)(65956001)(386003)(68736007)(33964004)(76176011)(52116002)(53546011)(52396003)(31686004)(7736002)(606006)(6116002)(64126003)(106356001)(105586002)(1706002)(486006)(316002)(11346002)(2906002)(84326002)(6306002)(54896002)(476003)(2616005)(270700001)(236005)(4326008)(53936002)(6246003)(5660300001)(81156014)(58126008)(46003)(478600001)(97736004)(81166006)(446003)(25786009)(8936002)(8676002)(65826007)(36756003)(6916009)(6666003)(186003)(37036004)(229853002)(6486002)(16586007)(16526019); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR05MB3658; H:[IPv6:2601:646:c103:10ff:21cf:ef2f:8885:d67]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
Received-SPF: None (protection.outlook.com: vmware.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB3658; 23:c1Addo5ZvplI4y6RPYkIpbghKfhX5tSg3gpqqUM3v?= =?us-ascii?Q?P6nUOyAhTQSPfSsxtyirOGzUuMf939ZjowFWV7IRss1CU98qC4q4TMGzTK+t?= =?us-ascii?Q?6dkYHa7Tr2ep3oPnFjTxm2BGvh8ELjta03YRmfYbwsLVGLkQ/UAtRWnH55os?= =?us-ascii?Q?kpdcWXWeJJ5gb0DM24xcL1NXQb9kJkz9bGJBvbCs7Tw86ILmWow3nz6KD4aI?= =?us-ascii?Q?c4oNph5cnRBld8u1Ir374XXia045ujuA8OhmRjywL3gWonYqQuBRkXCkcUgT?= =?us-ascii?Q?P+nP+gMsSi/4aEMPl3bEnQ6ClSyUaqviaSQz7WcPq9EyegysqEq3t93dS/VE?= =?us-ascii?Q?/ON3N0a/yfaBlqbgi9l0MH6BGtOyCAapatV49t+inYYrDMnC65y1itFiapNO?= =?us-ascii?Q?d+B5DCyiI+BcWiIUJg3CGgFA8E00GFX0/rf02yueJX+JPWeeVPkrEPZvImtt?= =?us-ascii?Q?r/BiQQXqJugHAlGq5KeHornOdeNKHob//JgFSLZYuVlv41HrX3FYtHODGSA0?= =?us-ascii?Q?XPaiNjWuoWxQHlBIYH4GAiO7Lgy7jUbmi/tHwxKn+dSr3Cgghc4pFddJKooN?= =?us-ascii?Q?FyUDsqFA9OQ0PqU2aBpyX++0mkQX+CiFpu4EHB7turCj82iDWmyJYzDwjYCo?= =?us-ascii?Q?Fme7UmbpqyIUJBZfit3d0Bb78VTm/XGVGyHMnHSkYSPc12/zZd4bY4Zy8Le+?= =?us-ascii?Q?Gqgx+Jw527YRsy6dGxuyWYuxENQhXK7w9+4sbzdB6Uu7IBeOnSQ5r5rrz56j?= =?us-ascii?Q?o0PCD8FllOks6/1q3kmYHIYgvGlaBN4QjaY+1cYZlUWZF3WxO3r/MBhgXNfd?= =?us-ascii?Q?EYoCAKzwjKk6swSiSOAcvvZvufD5JoUHLUGXX3U+3SPlRkEDrL+wya8+5oLf?= =?us-ascii?Q?8shUehPnfXHG+lLEukrWKTQKxnKfTpkZPMd1gaEzvTkSz0RzLQYH3TBM6rUB?= =?us-ascii?Q?fIe3KiaWI//qSGTEoB0Srk3ShoixjwOke7JXoAce/m8r+56TIEWzVIpMzXsu?= =?us-ascii?Q?R+SlYesen+d0akkwKOiZo9AyRAK45NoQLfTLuOVfuivJ1wcYybNaplD3K5ye?= =?us-ascii?Q?rDB3slZs+xzP+mx4PfUmAq2cNX4z8/qJHIofadJYfbG97q4Qu2BqAsIULvZk?= =?us-ascii?Q?UXk+yjkmYnAGQAMb6jvK3klTqpBq5Q/0TtHT2Ap4NJ8NC6+4S/wEool3Bu5n?= =?us-ascii?Q?U2CJB8OrgrRj7DE5Ud4y2JlE+OoBEqluldzI0YCcVAWrsQPDZrTaJ9Ok7aPh?= =?us-ascii?Q?NCoWWnfLYPxTJ1089tnKqo1/2XWllcQPtkhjVN9rJZiiG/Kt46H4jwWkqNV+?= =?us-ascii?Q?pDKs11rbBB54XywQql+6IYNun1YEQDFbYB96ooYpplNy2AXo14AxZYqwDCZv?= =?us-ascii?Q?T+2j2lMUyNc50aYJ0szZdr5SmZsXHlU9tXPrP6BmWfyZ/yhGCCprnff+KNhy?= =?us-ascii?Q?JWez110l26pHP+WroAGZElKANztNDo=3D?=
X-Microsoft-Antispam-Message-Info: lVs4DTFPR2aojaa7tvpRDMrwT1WHNQb7+g7efg04zUUlwmx4ccnPDhmnoB1sHFjryNZn008K7RwRlvKdMFNBJnabagYSrs6v8LT7ad25sBs3IddVlsHGyhn+OiK5Z8rSLZfiZ0WjIaXsnEmyUpun7ra1uYyZzXUNvku/ER+jiwiLsevTDHH0Jm5QkU+ytLeG
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3658; 6:w/rFEFVzZxbFrsyTgZi6NX6KyyxWbf1pKNaLfFo/x95bQQB6sXNkYLfYLeOnAdQ1P/q0LMOg/Au79awSWcBLnCt+plZdRrXPLRZ+goEfh4B008anoCUEAF2kMTvRPkM67ZOSvwy3rswsswXvjhL+freBPw+os6nwT1JFNt4jhjZtoXLkPJ/rcAiVoHSdPruA3Orviuh30Tdi3zuSNG+wxpNVwK30PFPOLPoB62n8uR6stoj0VuiQoG5FrCUWXgE3BNpTWYNa/Dj4Gi3vCMCMNtCVo3cqyJjGJ+s3jfaBxrA8vRYqEYD7mVc/LAgBB+qqIOu38zmSJ36e6UCbqtw0qDcVYDj0NEqIUoT3cfQpkKVzfxH4v8D7kWUoIB/rn6jIXhGd9LpquFdEy2ErhYURxcYEMQ45UCzR/xUC8dnlo2/8IKwzcihqtOaLLPSrX6VPe7p/lv3R3CXeryTv5//+8Q==; 5:/FRih+cHQ9ppD3Xqi0sa4meI4V2w+MpUtvdfhgQrP5ru7nw7j3CT9Bw2OLAmxCs42RAgSUjZbjTcc7aSY5njD3gAYn4bbIc1+fXli/Cpmf351RT8bpgOBjTIgHPl6ah7hezp6K0IrF0E6ga4C+OaCX9zoBxiJXCxOjE7Oq7G8Fg=; 24:n2oVugbIsbfMZdeWW8LMWkdImDmIP40vUVGY6MTnVhgSrvx4SLg5C2zcsVf+T69z7uNsAmZUGRg7V8Nk/7oU/4xRkw1Gyd0GII6RGAIcx7E=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB3658; 7:bfSqV14jF4tgAC8k44Py/9HHXogQMh6n4ihP5v4CSErB/KdPFPV2Gmbq/KbykYhrJx/kwpzefFCEuM1InKyAgxG6KWZVnfEHZMxcw7Ci3F5H6b66UIzbmrQDjDEeBioT7Lrx1wcLYd5dVZq4DBsPNi4HsPNz5mxrDziLb/Zsy4LTO6sulhybLnFN/MMTBZuEwL+9e5RuPN3VR2q8kBFkFW4XTFS101W3UkrPrrK445IB8dsP+QjwbAdriyxa+YuI; 20:VvbHrVP6jZDaqZ3OB1Aw17/9zai/7FdKQiEL/1M9NxQTiu8zosQhpEXhqKNsVG7gdTP5N+Jjj0QfR6B8oX8AYkbOyR6QrVi2sjzDInx1Tq6KIGXksMMX3CmsRFJONm1A+tx0Q8nL82RTW7pR5uEDRT3ebw/e8xzv0r+X7zeu/hg=
X-MS-Office365-Filtering-Correlation-Id: 14af9f8e-fded-4449-75c8-08d5b6e7b2eb
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2018 02:34:19.5947 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 14af9f8e-fded-4449-75c8-08d5b6e7b2eb
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3658
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/e2jQHcV8xaq52XVrmb5UhUCeVP0>
Subject: Re: [scim] unknown attribute type in attribute selection parameter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 02:34:24 -0000

This is a multi-part message in MIME format.
--------------F152A866F07CA0D1F31056A4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks, Phil. I agree that the behavior should be consistent with filter 
rules, but I didn't see where the Filtering section mentioned undefined 
attributes. By searching for "undefined" I see what you describe is 
there, in the Query Endpoints section. Odd, but good enough. Thanks again.

--Dale

On 05/10/2018 07:19 PM, Phil Hunt wrote:
> Dale
>
> I believe your view is correct.
>
> The spec is a bit weak on the processing rules for the attributes parameter.
>
> One would expect behavior consistent with the filter rules which say undefined attributes can be evaluated as null or false etc.
>
> Phil
>
>> On May 9, 2018, at 2:52 PM, Dale Olds <olds@vmware.com> wrote:
>>
>> I have a question regarding how a SCIM server should handle unknown attribute names in an attribute selection parameter. The SCIM 2.0 spec, section 3.9, defines the "attributes" parameter. We're seeing an implementation that returns an error if one of the given attribute types is unknown to that server.
>>
>>  From previous experience working with directory services it was very important that servers not return an error, but simply ignore that attribute since resources will not contain a value for it. This allowed for requests to be coded in a more portable fashion. If an app really needed to know what schema was supported, it could query the schema.
>>
>> However, in looking over the SCIM 2.0 spec, I can't find anything that would directly address this case. It is somewhat indirectly addressed in that I can't find an error defined for invalid or undefined attribute type.
>>
>> Is there an expected behavior for this situation or is it up to the server implementation?
>>
>> --Dale Olds
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=pb0U4X3Kl2WACP79HHA7FmtCfg6YoFmk97APnIwAGrM&s=9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&e=


--------------F152A866F07CA0D1F31056A4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Thanks, Phil. I agree that the behavior should be consistent with
    filter rules, but I didn't see where the Filtering section mentioned
    undefined attributes. By searching for "undefined" I see what you
    describe is there, in the Query Endpoints section. Odd, but good
    enough. Thanks again. <br>
    <br>
    --Dale  <br>
    <br>
    <div class="moz-cite-prefix">On 05/10/2018 07:19 PM, Phil Hunt
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com">
      <pre wrap="">Dale

I believe your view is correct. 

The spec is a bit weak on the processing rules for the attributes parameter. 

One would expect behavior consistent with the filter rules which say undefined attributes can be evaluated as null or false etc. 

Phil

</pre>
      <blockquote type="cite">
        <pre wrap="">On May 9, 2018, at 2:52 PM, Dale Olds <a class="moz-txt-link-rfc2396E" href="mailto:olds@vmware.com">&lt;olds@vmware.com&gt;</a> wrote:

I have a question regarding how a SCIM server should handle unknown attribute names in an attribute selection parameter. The SCIM 2.0 spec, section 3.9, defines the "attributes" parameter. We're seeing an implementation that returns an error if one of the given attribute types is unknown to that server. 

>From previous experience working with directory services it was very important that servers not return an error, but simply ignore that attribute since resources will not contain a value for it. This allowed for requests to be coded in a more portable fashion. If an app really needed to know what schema was supported, it could query the schema.

However, in looking over the SCIM 2.0 spec, I can't find anything that would directly address this case. It is somewhat indirectly addressed in that I can't find an error defined for invalid or undefined attribute type. 

Is there an expected behavior for this situation or is it up to the server implementation? 

--Dale Olds
_______________________________________________
scim mailing list
<a class="moz-txt-link-abbreviated" href="mailto:scim@ietf.org">scim@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&amp;d=DwICAg&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&amp;m=pb0U4X3Kl2WACP79HHA7FmtCfg6YoFmk97APnIwAGrM&amp;s=9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&amp;e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&amp;d=DwICAg&amp;c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&amp;m=pb0U4X3Kl2WACP79HHA7FmtCfg6YoFmk97APnIwAGrM&amp;s=9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&amp;e=</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------F152A866F07CA0D1F31056A4--


From nobody Thu May 10 19:52:35 2018
Return-Path: <phil.hunt@oracle.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD96120727 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level: 
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 PhWQDcofSm24 for <scim@ietfa.amsl.com>; Thu, 10 May 2018 19:52:31 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A85812D82F for <scim@ietf.org>; Thu, 10 May 2018 19:52:31 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4B2pivE170653; Fri, 11 May 2018 02:52:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=EUbbZoyrBRgu9QphpQRpSaiaYUyX0106DV0B6JaghCw=; b=pvhuybCx3cCh2nNYQVTrWPcuQtrF1tq4eawfUCYfYfMjRgiyKUaRQDtW/iWwh4oPkZgO UhAMuSEWEpO+32p/b0daJ2rMR9rpjhuLsDGFzCIDXAOYI8EH7B6tEDAF6P9SC6JqRvqn +lzCIlaQzbrH4sYkGjGDKHHdN7oDGS1wMwjLf6k4B/4D5DY9ZzO7r2iv4Qr3j7u0gFZG rLdXeDHTEB1TJvxnoCgT+jCFvYVtlCQPOY6Yi8XQhRrbhnVRCaDn7X/ps1u0s0f4zoIN r1ZtBm9VIM4ctalu1LzoshNJ3Sn1pfICG+iWi+mlMuZk9ysYyZgX8cieaeyOB/HukB0y hw== 
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2hvth9228b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:52:30 +0000
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4B2qSFb011453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 11 May 2018 02:52:29 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4B2qS30017405; Fri, 11 May 2018 02:52:28 GMT
Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 10 May 2018 19:52:28 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-5B4BFBAE-DD6C-4EAB-ADD3-E30E7D15DE24
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (15E302)
In-Reply-To: <8d8688e2-cbcd-d6ac-cf45-703794a30354@vmware.com>
Date: Thu, 10 May 2018 19:52:26 -0700
Cc: scim@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <F172EEE1-B88B-4A0C-A245-420DD99CE19B@oracle.com>
References: <546bd659-175a-f036-4fa2-0d2575091336@vmware.com> <9F5709A3-FC58-481C-A909-DB526D12D1D7@oracle.com> <8d8688e2-cbcd-d6ac-cf45-703794a30354@vmware.com>
To: Dale Olds <olds@vmware.com>
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8889 signatures=668698
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110021
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/GedTk0MBDW51qVOPina02nKckw0>
Subject: Re: [scim] unknown attribute type in attribute selection parameter
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 02:52:33 -0000

--Apple-Mail-5B4BFBAE-DD6C-4EAB-ADD3-E30E7D15DE24
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Dale

This is what I was thinking of.=20

3.4.2.1
> When processing query operations using endpoints that include more than on=
e SCIM resource type (e.g., a query from the server root endpoint), filters M=
UST be processed as outlined in Section 3.4.2.2. For filtered attributes tha=
t are not part of a particular resource type, the service provider SHALL tre=
at the attribute as if there is no attribute value. For example, a presence o=
r equality filter for an undefined attribute evaluates to false.

Cheers,

Phil

> On May 10, 2018, at 7:34 PM, Dale Olds <olds@vmware.com> wrote:
>=20
> Thanks, Phil. I agree that the behavior should be consistent with filter r=
ules, but I didn't see where the Filtering section mentioned undefined attri=
butes. By searching for "undefined" I see what you describe is there, in the=
 Query Endpoints section. Odd, but good enough. Thanks again.=20
>=20
> --Dale =20
>=20
>> On 05/10/2018 07:19 PM, Phil Hunt wrote:
>> Dale
>>=20
>> I believe your view is correct.=20
>>=20
>> The spec is a bit weak on the processing rules for the attributes paramet=
er.=20
>>=20
>> One would expect behavior consistent with the filter rules which say unde=
fined attributes can be evaluated as null or false etc.=20
>>=20
>> Phil
>>=20
>>> On May 9, 2018, at 2:52 PM, Dale Olds <olds@vmware.com> wrote:
>>>=20
>>> I have a question regarding how a SCIM server should handle unknown attr=
ibute names in an attribute selection parameter. The SCIM 2.0 spec, section 3=
.9, defines the "attributes" parameter. We're seeing an implementation that r=
eturns an error if one of the given attribute types is unknown to that serve=
r.=20
>>>=20
>>> =46rom previous experience working with directory services it was very i=
mportant that servers not return an error, but simply ignore that attribute s=
ince resources will not contain a value for it. This allowed for requests to=
 be coded in a more portable fashion. If an app really needed to know what s=
chema was supported, it could query the schema.
>>>=20
>>> However, in looking over the SCIM 2.0 spec, I can't find anything that w=
ould directly address this case. It is somewhat indirectly addressed in that=
 I can't find an error defined for invalid or undefined attribute type.=20
>>>=20
>>> Is there an expected behavior for this situation or is it up to the serv=
er implementation?=20
>>>=20
>>> --Dale Olds
>>> _______________________________________________
>>> scim mailing list
>>> scim@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
man_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=
&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dpb0U4X3Kl2WACP79HHA7Fmt=
Cfg6YoFmk97APnIwAGrM&s=3D9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&e=3D
>=20

--Apple-Mail-5B4BFBAE-DD6C-4EAB-ADD3-E30E7D15DE24
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Dale</div><div><br></div><div>This is w=
hat I was thinking of.&nbsp;</div><div><br></div>3.4.2.1<div><blockquote typ=
e=3D"cite"><pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0=
px; break-before: page;"><font color=3D"#000000" face=3D"UICTFontTextStyleBo=
dy"><span style=3D"caret-color: rgb(0, 0, 0); white-space: normal; backgroun=
d-color: rgba(255, 255, 255, 0);">   When processing query operations using e=
ndpoints that include more
   than one SCIM resource type (e.g., a query from the server root
   endpoint), filters MUST be processed as outlined in <a href=3D"https://to=
ols.ietf.org/html/rfc7644#section-3.4.2.2">Section 3.4.2.2</a>.
   <u>For filtered attributes that are not part of a particular resource
   type, the service provider SHALL treat the attribute as if there is
   no attribute value.  For example, a presence or equality filter for
   an undefined attribute evaluates to false.</u></span></font></pre></block=
quote><div><br></div>Cheers,</div><div><br><div id=3D"AppleMailSignature">Ph=
il</div><div><br>On May 10, 2018, at 7:34 PM, Dale Olds &lt;<a href=3D"mailt=
o:olds@vmware.com">olds@vmware.com</a>&gt; wrote:<br><br></div><blockquote t=
ype=3D"cite"><div>
 =20
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"=
>
 =20
 =20
    Thanks, Phil. I agree that the behavior should be consistent with
    filter rules, but I didn't see where the Filtering section mentioned
    undefined attributes. By searching for "undefined" I see what you
    describe is there, in the Query Endpoints section. Odd, but good
    enough. Thanks again. <br>
    <br>
    --Dale&nbsp; <br>
    <br>
    <div class=3D"moz-cite-prefix">On 05/10/2018 07:19 PM, Phil Hunt
      wrote:<br>
    </div>
    <blockquote type=3D"cite" cite=3D"mid:9F5709A3-FC58-481C-A909-DB526D12D1=
D7@oracle.com">
      <pre wrap=3D"">Dale

I believe your view is correct.=20

The spec is a bit weak on the processing rules for the attributes parameter.=
=20

One would expect behavior consistent with the filter rules which say undefin=
ed attributes can be evaluated as null or false etc.=20

Phil

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">On May 9, 2018, at 2:52 PM, Dale Olds <a class=3D"moz=
-txt-link-rfc2396E" href=3D"mailto:olds@vmware.com">&lt;olds@vmware.com&gt;<=
/a> wrote:

I have a question regarding how a SCIM server should handle unknown attribut=
e names in an attribute selection parameter. The SCIM 2.0 spec, section 3.9,=
 defines the "attributes" parameter. We're seeing an implementation that ret=
urns an error if one of the given attribute types is unknown to that server.=
=20

=46rom previous experience working with directory services it was very impor=
tant that servers not return an error, but simply ignore that attribute sinc=
e resources will not contain a value for it. This allowed for requests to be=
 coded in a more portable fashion. If an app really needed to know what sche=
ma was supported, it could query the schema.

However, in looking over the SCIM 2.0 spec, I can't find anything that would=
 directly address this case. It is somewhat indirectly addressed in that I c=
an't find an error defined for invalid or undefined attribute type.=20

Is there an expected behavior for this situation or is it up to the server i=
mplementation?=20

--Dale Olds
_______________________________________________
scim mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:scim@ietf.org">scim@iet=
f.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://urldefense.proofpoint.com=
/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_scim&amp;d=3DDwICAg&amp;=
c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=3Dna5FVzBTWmanqWNy4Dpc=
tyXPpuYqPkAI1aLcLN4KZNA&amp;m=3Dpb0U4X3Kl2WACP79HHA7FmtCfg6YoFmk97APnIwAGrM&=
amp;s=3D9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&amp;e=3D">https://urldef=
ense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_scim&=
amp;d=3DDwICAg&amp;c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&amp;r=3Dn=
a5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&amp;m=3Dpb0U4X3Kl2WACP79HHA7FmtCf=
g6YoFmk97APnIwAGrM&amp;s=3D9BqVUKO4TTZGgD7H4U1tHHM7ZvxspP3xipmcFjyfWaE&amp;e=
=3D</a>
</pre>
      </blockquote>
      <pre wrap=3D""></pre>
    </blockquote>
    <br>
 =20

</div></blockquote></div></body></html>=

--Apple-Mail-5B4BFBAE-DD6C-4EAB-ADD3-E30E7D15DE24--


From nobody Mon May 28 12:49:43 2018
Return-Path: <wwwrun@rfc-editor.org>
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 6DD4B12EB12 for <scim@ietfa.amsl.com>; Thu, 24 May 2018 12:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MhaKDpV_UjGA for <scim@ietfa.amsl.com>; Thu, 24 May 2018 12:32:11 -0700 (PDT)
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 B3A5912EB11 for <scim@ietf.org>; Thu, 24 May 2018 12:32:11 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1BD66B83081; Thu, 24 May 2018 12:31:58 -0700 (PDT)
To: phil.hunt@yahoo.com, kelly.grizzle@sailpoint.com, erik.wahlstrom@nexusgroup.com, cmortimore@salesforce.com, ben@nostrum.com, 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 <rfc-editor@rfc-editor.org>
Cc: bmccollam@uchicago.edu, scim@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180524193158.1BD66B83081@rfc-editor.org>
Date: Thu, 24 May 2018 12:31:58 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/hXekZd68LXZ0p-iMWyY2-gp1vE4>
X-Mailman-Approved-At: Mon, 28 May 2018 12:49:41 -0700
Subject: [scim] [Technical Errata Reported] RFC7643 (5368)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 19:32: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:
http://www.rfc-editor.org/errata/eid5368

--------------------------------------
Type: Technical
Reported by: Brendan McCollam <bmccollam@uchicago.edu>

Section: 8.7.1

Original Text
-------------
  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "displayName",
        "type" : "string",
        "multiValued" : false,
        "description" : "A human-readable name for the Group.
REQUIRED.",
        "required" : false,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Corrected Text
--------------
  {
    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
    "name" : "Group",
    "description" : "Group",
    "attributes" : [
      {
        "name" : "displayName",
        "type" : "string",
        "multiValued" : false,
        "description" : "A human-readable name for the Group.
REQUIRED.",
        "required" : true,
        "caseExact" : false,
        "mutability" : "readWrite",
        "returned" : "default",
        "uniqueness" : "none"
      },

Notes
-----
On page 68, in the JSON example schema for the Group resource, the displayName attribute is highlighted as REQUIRED in the "description" but the value of the "required" field is false. Given that section 4.2 also indicates displayName is a required attribute for Group resources, I believe the conflict in section 8.7.1 is best corrected by changing the value of the "required" attribute to 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 May 28 12:49:49 2018
Return-Path: <phil.hunt@oracle.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AD127869 for <scim@ietfa.amsl.com>; Fri, 25 May 2018 13:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 cqsmr847LAbf for <scim@ietfa.amsl.com>; Fri, 25 May 2018 13:11:52 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C87F124BAC for <scim@ietf.org>; Fri, 25 May 2018 13:11:52 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4PK6o6w169140; Fri, 25 May 2018 20:11:44 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=hgGsjahC499S8iO3XIb9HSlR4xK+wqGzy++Y1Y1ZgNY=; b=MhHkqzVLQKfzP5uWFag8biXjkP7kDw3WNb5q/LEZQ6EJIHPPUfCCJq33yip/oY8xSuZm 1MTJVA36OMprHzx9lzknj2zVZHpbRvk6b4f8AjArtdaefUMtNtkPkD+kM5nL+pUhcfva NLmnVjBUxzjm+DYuktgPaZw1IbQ57HrFJhMSEwLpq1KrcIINB8xFuYKQM/nEQJzxbBn5 KTqd78zfDcfrHIaVwOhjudu09pXYHv5NOaHasJtE3Mmps9q5MzYKwA3gMj5oLS3XJl8e qs24ttR0y1LMcEKhZa7pxfZ/5rCvZjpsl3orfyfmlRczXB9pN2SA2zwchTGtDb+J7nM3 Ug== 
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2j6qk5gcv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 May 2018 20:11:44 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w4PKBfjA000965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 May 2018 20:11:41 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w4PKBaKU010303; Fri, 25 May 2018 20:11:36 GMT
Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 May 2018 13:11:36 -0700
From: Phil Hunt <phil.hunt@oracle.com>
Message-Id: <89B8E7CD-BC3B-4B00-91A0-F673DBA8FEC4@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_563D71F9-05C6-456B-AE1B-6E078D417078"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 25 May 2018 13:11:33 -0700
In-Reply-To: <20180524193158.1BD66B83081@rfc-editor.org>
Cc: Kelly Grizzle <kelly.grizzle@sailpoint.com>, erik.wahlstrom@nexusgroup.com, Chuck Mortimore <cmortimore@salesforce.com>, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Morteza Ansari <moransar@cisco.com>, leifj@sunet.se, bmccollam@uchicago.edu, scim@ietf.org
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20180524193158.1BD66B83081@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.6.18)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8904 signatures=668700
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805250208
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/Ad352g6_aP6GNhMNFvZeVvEis1s>
X-Mailman-Approved-At: Mon, 28 May 2018 12:49:41 -0700
Subject: Re: [scim] [Technical Errata Reported] RFC7643 (5368)
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 May 2018 20:11:56 -0000

--Apple-Mail=_563D71F9-05C6-456B-AE1B-6E078D417078
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This errata is verified.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com =
<http://www.independentid.com/>phil.hunt@oracle.com =
<mailto:phil.hunt@oracle.com>

> On May 24, 2018, at 12:31 PM, RFC Errata System =
<rfc-editor@rfc-editor.org> 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:
> http://www.rfc-editor.org/errata/eid5368
>=20
> --------------------------------------
> Type: Technical
> Reported by: Brendan McCollam <bmccollam@uchicago.edu>
>=20
> Section: 8.7.1
>=20
> Original Text
> -------------
>  {
>    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
>    "name" : "Group",
>    "description" : "Group",
>    "attributes" : [
>      {
>        "name" : "displayName",
>        "type" : "string",
>        "multiValued" : false,
>        "description" : "A human-readable name for the Group.
> REQUIRED.",
>        "required" : false,
>        "caseExact" : false,
>        "mutability" : "readWrite",
>        "returned" : "default",
>        "uniqueness" : "none"
>      },
>=20
> Corrected Text
> --------------
>  {
>    "id" : "urn:ietf:params:scim:schemas:core:2.0:Group",
>    "name" : "Group",
>    "description" : "Group",
>    "attributes" : [
>      {
>        "name" : "displayName",
>        "type" : "string",
>        "multiValued" : false,
>        "description" : "A human-readable name for the Group.
> REQUIRED.",
>        "required" : true,
>        "caseExact" : false,
>        "mutability" : "readWrite",
>        "returned" : "default",
>        "uniqueness" : "none"
>      },
>=20
> Notes
> -----
> On page 68, in the JSON example schema for the Group resource, the =
displayName attribute is highlighted as REQUIRED in the "description" =
but the value of the "required" field is false. Given that section 4.2 =
also indicates displayName is a required attribute for Group resources, =
I believe the conflict in section 8.7.1 is best corrected by changing =
the value of the "required" attribute to 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


--Apple-Mail=_563D71F9-05C6-456B-AE1B-6E078D417078
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">This =
errata is verified.<div class=3D""><br class=3D""></div><div =
class=3D"">Thanks,<br class=3D""><div class=3D""><br class=3D""><div =
class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D""><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; line-height: normal; border-spacing: =
0px;"><div class=3D"" style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space;"><div class=3D""><div =
class=3D""><div class=3D"">Phil</div><div class=3D""><br =
class=3D""></div><div class=3D"">Oracle Corporation, Identity Cloud =
Services Architect</div><div class=3D"">@independentid</div><div =
class=3D""><a href=3D"http://www.independentid.com" =
class=3D"">www.independentid.com</a></div></div></div></div></span><a =
href=3D"mailto:phil.hunt@oracle.com" class=3D"" style=3D"orphans: 2; =
widows: =
2;">phil.hunt@oracle.com</a></div></div></div></div></div></div></div></di=
v></div></div></div></div></div>
</div>

<div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On May 24, 2018, at 12:31 PM, RFC Errata System &lt;<a =
href=3D"mailto:rfc-editor@rfc-editor.org" =
class=3D"">rfc-editor@rfc-editor.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">The =
following errata report has been submitted for RFC7643,<br =
class=3D"">"System for Cross-domain Identity Management: Core =
Schema".<br class=3D""><br =
class=3D"">--------------------------------------<br class=3D"">You may =
review the report below and at:<br class=3D""><a =
href=3D"http://www.rfc-editor.org/errata/eid5368" =
class=3D"">http://www.rfc-editor.org/errata/eid5368</a><br class=3D""><br =
class=3D"">--------------------------------------<br class=3D"">Type: =
Technical<br class=3D"">Reported by: Brendan McCollam =
&lt;bmccollam@uchicago.edu&gt;<br class=3D""><br class=3D"">Section: =
8.7.1<br class=3D""><br class=3D"">Original Text<br =
class=3D"">-------------<br class=3D""> &nbsp;{<br class=3D""> =
&nbsp;&nbsp;&nbsp;"id" : =
"urn:ietf:params:scim:schemas:core:2.0:Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"name" : "Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"description" : "Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"attributes" : [<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"name" : "displayName",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"type" : =
"string",<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"multiValued" : false,<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"description" : "A =
human-readable name for the Group.<br class=3D"">REQUIRED.",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"required" : =
false,<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"caseExact" : false,<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"mutability" : =
"readWrite",<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"returned" : "default",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"uniqueness" : =
"none"<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},<br class=3D""><br =
class=3D"">Corrected Text<br class=3D"">--------------<br class=3D""> =
&nbsp;{<br class=3D""> &nbsp;&nbsp;&nbsp;"id" : =
"urn:ietf:params:scim:schemas:core:2.0:Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"name" : "Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"description" : "Group",<br class=3D""> =
&nbsp;&nbsp;&nbsp;"attributes" : [<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"name" : "displayName",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"type" : =
"string",<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"multiValued" : false,<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"description" : "A =
human-readable name for the Group.<br class=3D"">REQUIRED.",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"required" : =
true,<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"caseExact" : false,<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"mutability" : =
"readWrite",<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"returned" : "default",<br =
class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"uniqueness" : =
"none"<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},<br class=3D""><br =
class=3D"">Notes<br class=3D"">-----<br class=3D"">On page 68, in the =
JSON example schema for the Group resource, the displayName attribute is =
highlighted as REQUIRED in the "description" but the value of the =
"required" field is false. Given that section 4.2 also indicates =
displayName is a required attribute for Group resources, I believe the =
conflict in section 8.7.1 is best corrected by changing the value of the =
"required" attribute to true.<br class=3D""><br =
class=3D"">Instructions:<br class=3D"">-------------<br class=3D"">This =
erratum is currently posted as "Reported". If necessary, please<br =
class=3D"">use "Reply All" to discuss whether it should be verified =
or<br class=3D"">rejected. When a decision is reached, the verifying =
party &nbsp;<br class=3D"">can log in to change the status and edit the =
report, if necessary. <br class=3D""><br =
class=3D"">--------------------------------------<br class=3D"">RFC7643 =
(draft-ietf-scim-core-schema-22)<br =
class=3D"">--------------------------------------<br class=3D"">Title =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;: System for Cross-domain Identity Management: Core Schema<br =
class=3D"">Publication Date &nbsp;&nbsp;&nbsp;: September 2015<br =
class=3D"">Author(s) =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: P. Hunt, =
Ed., K. Grizzle, E. Wahlstroem, C. Mortimore<br class=3D"">Category =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
PROPOSED STANDARD<br class=3D"">Source =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;: System for Cross-domain Identity Management<br class=3D"">Area =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;: Applications and Real-Time<br class=3D"">Stream =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;: IETF<br class=3D"">Verifying Party &nbsp;&nbsp;&nbsp;&nbsp;: =
IESG<br class=3D""></div></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_563D71F9-05C6-456B-AE1B-6E078D417078--

