From nobody Mon Aug 20 12:12:03 2018 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 D73DC130DC6 for ; Mon, 20 Aug 2018 12:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4YUBoIMfWt0J for ; Mon, 20 Aug 2018 12:12:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A13E130E4A for ; Mon, 20 Aug 2018 12:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18402; q=dns/txt; s=iport; t=1534792315; x=1536001915; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=l3PZDgcyZxZ5VyVeFgRbN40MrPn//+zqbj5fw+lwinM=; b=eLoWeAcFTeP9dL9F8Duvb94JpnzXcGHNL+76oYAWYTSau/QTT7JNFNkx HsitVbftYzZfDq1iP40ENLyySuT+pPL6JhgBYk+04hbW6IXd68A4NQXRu /0xtbZhdvKaJ9HinVTZZX6TsNHE6W9DGCjI79szu8XYHJ+NuV1iyLN4V7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAADFEXtb/4cNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYJXeGN/KAqDZogKjB2BaCWQbIUrgXoLI4RJAheDNiE0GAECAQE?= =?us-ascii?q?CAQECbRwMhTcBAQEBAyNLGwIBCBEDAQIrAgICMB0IAgQBEoMiAYEdZA+ne4E?= =?us-ascii?q?uilgFiRgXgUE/gRInDBOBTlAugxsBAQIBgUg2gmExgiYCiAGEdoFDjEIJAoY?= =?us-ascii?q?niTcVgT6EL4hLiwyHdQIRFIEkHTgmgSxwFTsqAYI+G4p6hT5vAQGNX4EbAQE?= X-IronPort-AV: E=Sophos;i="5.53,266,1531785600"; d="scan'208,217";a="440660237" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Aug 2018 19:11:53 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w7KJBrYZ008936 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Aug 2018 19:11:54 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Aug 2018 14:11:53 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Mon, 20 Aug 2018 14:11:53 -0500 From: "Morteza Ansari (moransar)" To: "Jena, Jayadeba" , "cmortimore@salesforce.com" , "scim@ietf.org" Thread-Topic: SCIM: Questions regarding Error handling for Bulk operations Thread-Index: AQHUNMWbxEGT4Zj+g0Oqro1C/XbJpKTI6DsA Date: Mon, 20 Aug 2018 19:11:53 +0000 Message-ID: <8D8C033A-0429-436E-BB75-25754B74C2D7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.209.82] Content-Type: multipart/alternative; boundary="_000_8D8C033A0429436EBB7525754B74C2D7ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 19:12:02 -0000 --_000_8D8C033A0429436EBB7525754B74C2D7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVuYSwNCg0KQmVzdCBvcHRpb24gZm9yIGdldHRpbmcgY2xhcmlmaWNhdGlvbiBvbiBTQ0lN IHNwZWMgaXMgdG8gcmVhY2ggb3V0IHRvIHRoZSBXRyBtYWlsaW5nIGxpc3Q6IHNjaW1AaWV0Zi5v cmcuIE1hbnkgbW9yZSBleWVzIHdpbGwgc2VlIGl0IHRoZXJlLg0KDQpBcyB0byB5b3VyIHNwZWNp ZmljIHF1ZXN0aW9uLCBJIGFtIGFjdHVhbGx5IG5vdCAxMDAlIHN1cmUuIFJlLXJlYWRpbmcgdGhl IHNwZWMgc2VlbXMgdG8gYmUgYSBiaXQgYW1iaWd1b3VzIHRoZXJlIGFuZCBJIGhhdmVu4oCZdCBh Y3R1YWxseSBpbXBsZW1lbnRlZCBidWxrIG15c2VsZi4gSSBiZWxpZXZlIHRoZSBhbnN3ZXIgdG8g Ym90aCBzY2VuYXJpb3MgaXMgcmV0dXJuaW5nIDIwMCByZXNwb25zZXMgd2l0aCBvcGVyYXRpb24g cmVzcG9uc2VzIG9mIDQwOSBmb3IgdGhlIGZhaWxlZC4NCg0KUGhpbCwgb3RoZXJzLCBkbyB5b3Ug aGF2ZSBhIGJldHRlciBhbnN3ZXI/IEhhdmUgd2UgY2xhcmlmaWVkIHRoaXMgc29tZXdoZXJlIGVs c2UgaW4gdGhlIGRvYyB0aGF0IEkgYW0gbWlzc2luZz8NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQoN CkZyb206ICJKZW5hLCBKYXlhZGViYSIgPGpqZW5hQHBheXBhbC5jb20+DQpEYXRlOiBGcmlkYXks IEF1Z3VzdCAxNywgMjAxOCBhdCA1OjMyIFBNDQpUbzogIm1vcnRlemEuYW5zYXJpQGNpc2NvLmNv bSIgPG1vcnRlemEuYW5zYXJpQGNpc2NvLmNvbT4sIENodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9y ZUBzYWxlc2ZvcmNlLmNvbT4NClN1YmplY3Q6IFNDSU06IFF1ZXN0aW9ucyByZWdhcmRpbmcgRXJy b3IgaGFuZGxpbmcgZm9yIEJ1bGsgb3BlcmF0aW9ucw0KDQpIaSwNCg0KSeKAmW0gZnJvbSBQYXlQ YWwgYW5kIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBTQ0lNIGJ1bGsgc3BlY2lmaWNhdGlvbiBh bmQgaGF2ZSBxdWVzdGlvbnMgYXJvdW5kIHRoZSBlcnJvciBoYW5kbGluZyB3aXRoIOKAnGZhaWxP bkVycm9y4oCdIG5vdCBzcGVjaWZpZWQgaW4gdGhlIHJlcXVlc3QuIEFzIGFuIGV4YW1wbGUsIEkg d2FzIHJlYWRpbmcgdGhyb3VnaCB0aGUgc2VjdGlvbiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc2NDQjc2VjdGlvbi0zLjcuMSkgLSB3aGljaCBzYXlzIHRoYXQgd2UgbmVlZCB0byBy ZXR1cm4gdGhlIGVycm9yIGNvZGUgNDA5IHdoZW4gdGhlIGNpcmN1bGFyIGRlcGVuZGVuY3kgY291 bGRu4oCZdCBiZSByZXNvbHZlZCBieSB0aGUgc2VydmVyLiBUaGUgYmVoYXZpb3Igb2YgdGhlIGJ1 bGsgc2VydmVyIHdydCBpcyBub3QgY2xlYXIgdG8gbWUgd2hlbiB3ZSBoYXZlIHRoZSDigJxGYWls T25FcnJvcuKAnSBmbGFnIGlzIG5vdCBzcGVjaWZpZWQuIFBsZWFzZSBoZWxwIGNsYXJpZnkgaWYg dGhlIGZvbGxvd2luZyBiZWhhdmlvciBpcyBjb3JyZWN0IGFuZCBhcyBwZXIgdGhlIHNwZWNpZmlj YXRpb24uDQoNCg0KICAqICAgU2NlbmFyaW8xOiBXaGVuIHRoZXJl4oCZcyBhIGJ1bGsgcmVxdWVz dCBib2R5IHdpdGggMiBpdGVtcywgZmFpbE9uRXJyb3JzIGZsYWcgaXMgbm90IHNwZWNpZmllZCBp biB0aGUgcmVxdWVzdC0gVGhlIHNlcnZlciB3aGlsZSBwcm9jZXNzaW5nIHRoZSBidWxrIHJlcXVl c3RzLCBkaXNjb3ZlcnMgY2lyY3VsYXIgZGVwZW5kZW5jeSB0aGF0IGl0IGNvdWxkbuKAmXQgcmVz b2x2ZSwgd2hhdCB3b3VsZCBiZSB0aGUgYnVsayByZXNwb25zZT8gU2hvdWxkIHRoZSBidWxrIHNl cnZlciByZXR1cm4gYSB0b3AgbGV2ZWwgNDA5IHJlc3BvbnNlIG9yIGEgMjAwIHJlc3BvbnNlIHdp dGggb3BlcmF0aW9uIHJlc3BvbnNlIGZvciBlYWNoIGZhaWxlZCBpdGVtcyAoaS5lIDIgb3BlcmF0 aW9uIHJlc3BvbnNlcyB3aXRoIDQwOSBhcyB0aGUgY29kZSBmb3IgZWFjaCkuDQogICogICBTY2Vu YXJpbzI6IFdoZW4gdGhlcmXigJlzIGEgYnVsayByZXF1ZXN0IGJvZHkgd2l0aCAzIGl0ZW1zLCBm YWlsT25FcnJvcnMgZmxhZyBpcyBub3Qgc3BlY2lmaWVkIGluIHRoZSByZXF1ZXN0LSBUaGUgc2Vy dmVyIHdoaWxlIHByb2Nlc3NpbmcgdGhlIGJ1bGsgcmVxdWVzdHMsIGRpc2NvdmVycyBjaXJjdWxh ciBkZXBlbmRlbmN5IHRoYXQgaXQgY291bGRu4oCZdCByZXNvbHZlIGZvciB0aGUgZmlyc3QgMiBp dGVtcywgd2hpbGUgdGhlIDNyZCBpdGVtcyBjb3VsZCBiZSBwcm9jZXNzZWQgc3VjY2Vzc2Z1bGx5 LCB3aGF0IHdvdWxkIGJlIHRoZSBidWxrIHJlc3BvbnNlPyBTaG91bGQgaXQgYmUgYSAgMjAwIHJl c3BvbnNlIHdpdGggb3BlcmF0aW9uIHJlc3BvbnNlIGZvciBlYWNoIGZhaWxlZCBpdGVtcyAoaS5l IDIgb3BlcmF0aW9uIHJlc3BvbnNlcyB3aXRoIDQwOSBhcyB0aGUgY29kZSBmb3IgZWFjaCkgYW5k IHRoZW4gaXQgYWxzbyBjb250YWlucyB0aGUgc3VjY2Vzc2Z1bCByZXNwb25zZSBmb3IgdGhlIDNy ZCBpdGVtDQoNClRoYW5rcywNCkpheWFkZWJhDQoNCg== --_000_8D8C033A0429436EBB7525754B74C2D7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A2341189D67534393CF72305530BB26@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NjI2NjI1ODc7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi04NDM1NDQyMTQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTU4NzA5 MTY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzAx ODIyODcwIDE0NjYwOTAyODYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SGkgSmVuYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkJlc3Qgb3B0aW9uIGZvciBnZXR0aW5nIGNsYXJpZmljYXRpb24gb24g U0NJTSBzcGVjIGlzIHRvIHJlYWNoIG91dCB0byB0aGUgV0cgbWFpbGluZyBsaXN0OiBzY2ltQGll dGYub3JnLiBNYW55IG1vcmUgZXllcyB3aWxsIHNlZSBpdCB0aGVyZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHRvIHlvdXIgc3BlY2lmaWMgcXVlc3Rpb24s IEkgYW0gYWN0dWFsbHkgbm90IDEwMCUgc3VyZS4gUmUtcmVhZGluZyB0aGUgc3BlYyBzZWVtcyB0 byBiZSBhIGJpdCBhbWJpZ3VvdXMgdGhlcmUgYW5kIEkgaGF2ZW7igJl0IGFjdHVhbGx5IGltcGxl bWVudGVkIGJ1bGsgbXlzZWxmLiBJIGJlbGlldmUgdGhlIGFuc3dlciB0byBib3RoIHNjZW5hcmlv cyBpcyByZXR1cm5pbmcNCiAyMDAgcmVzcG9uc2VzIHdpdGggb3BlcmF0aW9uIHJlc3BvbnNlcyBv ZiA0MDkgZm9yIHRoZSBmYWlsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5QaGlsLCBvdGhlcnMsIGRvIHlvdSBoYXZlIGEgYmV0dGVyIGFuc3dlcj8gSGF2ZSB3 ZSBjbGFyaWZpZWQgdGhpcyBzb21ld2hlcmUgZWxzZSBpbiB0aGUgZG9jIHRoYXQgSSBhbSBtaXNz aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TW9ydGV6YTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDtKZW5h LCBKYXlhZGViYSZxdW90OyAmbHQ7amplbmFAcGF5cGFsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+RnJpZGF5LCBBdWd1c3QgMTcsIDIwMTggYXQgNTozMiBQTTxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7bW9ydGV6YS5hbnNhcmlAY2lzY28uY29tJnF1b3Q7ICZsdDttb3J0ZXphLmFuc2FyaUBjaXNj by5jb20mZ3Q7LCBDaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlNDSU06IFF1ZXN0aW9ucyByZWdhcmRpbmcgRXJyb3Ig aGFuZGxpbmcgZm9yIEJ1bGsgb3BlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPknigJltIGZyb20gUGF5UGFsIGFuZCB0cnlpbmcg dG8gdW5kZXJzdGFuZCB0aGUgU0NJTSBidWxrIHNwZWNpZmljYXRpb24gYW5kIGhhdmUgcXVlc3Rp b25zIGFyb3VuZCB0aGUgZXJyb3IgaGFuZGxpbmcgd2l0aCDigJxmYWlsT25FcnJvcuKAnSBub3Qg c3BlY2lmaWVkIGluIHRoZSByZXF1ZXN0LiBBcyBhbiBleGFtcGxlLCBJIHdhcyByZWFkaW5nIHRo cm91Z2ggdGhlIHNlY3Rpb24NCiAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc2NDQjc2VjdGlvbi0zLjcuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2 NDQjc2VjdGlvbi0zLjcuMTwvYT4pIC0gd2hpY2ggc2F5cyB0aGF0IHdlIG5lZWQgdG8gcmV0dXJu IHRoZSBlcnJvciBjb2RlIDQwOSB3aGVuIHRoZSBjaXJjdWxhciBkZXBlbmRlbmN5IGNvdWxkbuKA mXQgYmUgcmVzb2x2ZWQgYnkgdGhlIHNlcnZlci4gVGhlIGJlaGF2aW9yIG9mIHRoZQ0KIGJ1bGsg c2VydmVyIHdydCBpcyBub3QgY2xlYXIgdG8gbWUgd2hlbiB3ZSBoYXZlIHRoZSDigJxGYWlsT25F cnJvcuKAnSBmbGFnIGlzIG5vdCBzcGVjaWZpZWQuIFBsZWFzZSBoZWxwIGNsYXJpZnkgaWYgdGhl IGZvbGxvd2luZyBiZWhhdmlvciBpcyBjb3JyZWN0IGFuZCBhcyBwZXIgdGhlIHNwZWNpZmljYXRp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2NlbmFyaW8xPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+OiBXaGVuIHRoZXJl4oCZcyBhIGJ1bGsgcmVxdWVz dCBib2R5IHdpdGggMiBpdGVtcywgZmFpbE9uRXJyb3JzIGZsYWcgaXMgbm90IHNwZWNpZmllZCBp biB0aGUgcmVxdWVzdC0NCiBUaGUgc2VydmVyIHdoaWxlIHByb2Nlc3NpbmcgdGhlIGJ1bGsgcmVx dWVzdHMsIGRpc2NvdmVycyBjaXJjdWxhciBkZXBlbmRlbmN5IHRoYXQgaXQgY291bGRu4oCZdCBy ZXNvbHZlLCB3aGF0IHdvdWxkIGJlIHRoZSBidWxrIHJlc3BvbnNlPyBTaG91bGQgdGhlIGJ1bGsg c2VydmVyIHJldHVybiBhIHRvcCBsZXZlbCA0MDkgcmVzcG9uc2Ugb3IgYSAyMDAgcmVzcG9uc2Ug d2l0aCBvcGVyYXRpb24gcmVzcG9uc2UgZm9yIGVhY2ggZmFpbGVkIGl0ZW1zIChpLmUNCiAyIG9w ZXJhdGlvbiByZXNwb25zZXMgd2l0aCA0MDkgYXMgdGhlIGNvZGUgZm9yIGVhY2gpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+U2NlbmFyaW8yPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+OiBXaGVuIHRoZXJl4oCZcyBhIGJ1bGsgcmVxdWVzdCBib2R5IHdpdGggMyBpdGVtcywg ZmFpbE9uRXJyb3JzIGZsYWcgaXMgbm90IHNwZWNpZmllZCBpbiB0aGUgcmVxdWVzdC0NCiBUaGUg c2VydmVyIHdoaWxlIHByb2Nlc3NpbmcgdGhlIGJ1bGsgcmVxdWVzdHMsIGRpc2NvdmVycyBjaXJj dWxhciBkZXBlbmRlbmN5IHRoYXQgaXQgY291bGRu4oCZdCByZXNvbHZlIGZvciB0aGUgZmlyc3Qg MiBpdGVtcywgd2hpbGUgdGhlIDM8c3VwPnJkPC9zdXA+IGl0ZW1zIGNvdWxkIGJlIHByb2Nlc3Nl ZCBzdWNjZXNzZnVsbHksIHdoYXQgd291bGQgYmUgdGhlIGJ1bGsgcmVzcG9uc2U/IFNob3VsZCBp dCBiZSBhJm5ic3A7IDIwMCByZXNwb25zZSB3aXRoDQogb3BlcmF0aW9uIHJlc3BvbnNlIGZvciBl YWNoIGZhaWxlZCBpdGVtcyAoaS5lIDIgb3BlcmF0aW9uIHJlc3BvbnNlcyB3aXRoIDQwOSBhcyB0 aGUgY29kZSBmb3IgZWFjaCkgYW5kIHRoZW4gaXQgYWxzbyBjb250YWlucyB0aGUgc3VjY2Vzc2Z1 bCByZXNwb25zZSBmb3IgdGhlIDM8c3VwPnJkPC9zdXA+IGl0ZW08L3NwYW4+PG86cD48L286cD48 L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SmF5YWRlYmE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8D8C033A0429436EBB7525754B74C2D7ciscocom_-- From nobody Mon Aug 20 13:40:27 2018 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 89F05128BAC for ; Mon, 20 Aug 2018 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 1Uo-CUtqGpgk for ; Mon, 20 Aug 2018 13:40:25 -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 12D561277CC for ; Mon, 20 Aug 2018 13:40:25 -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 w7KKdK3e021534; Mon, 20 Aug 2018 20:40:19 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-2018-07-02; bh=fmJMf4nOr18KaG71oz7AibZ5sufBmJet9Qg9pH1CYoU=; b=a+W7X0hyWHUG8VUu7oqoZNfHuaL11So8pmlI0oHtbtZqG9ZHv1ch2chvxpvoYtxhxDLW 7yjJkxdI93Ab1vbve0l03+mmp8qO7N4UbEcCuzGDonVLire8IWV0Pyw8/fg+vF9a7pKQ iRI3xx4vV11F0d8CC/nwpcw5iWrWkFag3B1z668fYvs1CU7V9iY9qUxZRkt+BnobsNmr VUKMMDoREfU5EikElJEVqRB8xFmk6Zgu5vicj31NstgPU+1MY49K4vIQQTGDRbu0Se0J GferhRE2sSk52hxcq1YGQrMIpG0gPFcIqcLlIiByEkN6gwynv0NKMWQhrcR1PTgdnxj/ KQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2kxavtgspk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Aug 2018 20:40:19 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w7KKeIWe028731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Aug 2018 20:40:19 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w7KKeIfV022032; Mon, 20 Aug 2018 20:40:18 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Aug 2018 13:40:17 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6CCA92E9-47C1-4646-8C4B-B3B149C0834B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 13:40:15 -0700 In-Reply-To: <8D8C033A-0429-436E-BB75-25754B74C2D7@cisco.com> Cc: "Jena, Jayadeba" , Chuck Mortimore , "scim@ietf.org" To: "Morteza Ansari (moransar)" References: <8D8C033A-0429-436E-BB75-25754B74C2D7@cisco.com> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8991 signatures=668707 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-1807170000 definitions=main-1808200210 Archived-At: Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 20:40:26 -0000 --Apple-Mail=_6CCA92E9-47C1-4646-8C4B-B3B149C0834B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Morteza/Jena, The IDCS (Identity Cloud Service) bulk endpoint returns an overall 200 = and then 409 for each resource operation that failed (due to cycle or = any other reason) and a 200/201 for those that succeed. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = wrote: >=20 > Hi Jena, > =20 > Best option for getting clarification on SCIM spec is to reach out to = the WG mailing list: scim@ietf.org . Many more = eyes will see it there. > =20 > As to your specific question, I am actually not 100% sure. Re-reading = the spec seems to be a bit ambiguous there and I haven=E2=80=99t = actually implemented bulk myself. I believe the answer to both scenarios = is returning 200 responses with operation responses of 409 for the = failed. > =20 > Phil, others, do you have a better answer? Have we clarified this = somewhere else in the doc that I am missing? > =20 > =20 > Cheers, > Morteza > =20 > From: "Jena, Jayadeba" > > Date: Friday, August 17, 2018 at 5:32 PM > To: "morteza.ansari@cisco.com " = >, Chuck = Mortimore > > Subject: SCIM: Questions regarding Error handling for Bulk operations > =20 > Hi, > =20 > I=E2=80=99m from PayPal and trying to understand the SCIM bulk = specification and have questions around the error handling with = =E2=80=9CfailOnError=E2=80=9D not specified in the request. As an = example, I was reading through the section = (https://tools.ietf.org/html/rfc7644#section-3.7.1 = ) - which says that we need to return the error code 409 = when the circular dependency couldn=E2=80=99t be resolved by the server. = The behavior of the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification. > =20 > Scenario1: When there=E2=80=99s a bulk request body with 2 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve, what would be the bulk response? Should the = bulk server return a top level 409 response or a 200 response with = operation response for each failed items (i.e 2 operation responses with = 409 as the code for each). > Scenario2: When there=E2=80=99s a bulk request body with 3 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve for the first 2 items, while the 3rd items = could be processed successfully, what would be the bulk response? Should = it be a 200 response with operation response for each failed items (i.e = 2 operation responses with 409 as the code for each) and then it also = contains the successful response for the 3rd item > =20 > Thanks, > Jayadeba > =20 > _______________________________________________ > 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=3DpyJbcSIML-m5QRPAfMRPW= 1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D= = --Apple-Mail=_6CCA92E9-47C1-4646-8C4B-B3B149C0834B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Morteza/Jena,

The IDCS (Identity Cloud Service) bulk endpoint returns an = overall 200 and then 409 for each resource operation that failed (due to = cycle or any other reason) and a 200/201 for those that = succeed.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = <moransar=3D40cisco.com@dmarc.ietf.org> wrote:

Hi Jena,
 
Best option for = getting clarification on SCIM spec is to reach out to the WG mailing = list: scim@ietf.org. Many more = eyes will see it there.
 
As to your = specific question, I am actually not 100% sure. Re-reading the spec = seems to be a bit ambiguous there and I haven=E2=80=99t actually = implemented bulk myself. I believe the answer to both scenarios is = returning 200 responses with operation responses of 409 for the = failed.
 
Phil, others, do = you have a better answer? Have we clarified this somewhere else in the = doc that I am missing?
 
 
Cheers,
Morteza
 
From: "Jena, Jayadeba" <jjena@paypal.com>
Date: Friday, August 17, = 2018 at 5:32 PM
To: "morteza.ansari@cisco.com" <morteza.ansari@cisco.com>, Chuck Mortimore <cmortimore@salesforce.com>
Subject: SCIM: Questions = regarding Error handling for Bulk operations
 
Hi,
 
I=E2=80=99m from PayPal and trying = to understand the SCIM bulk specification and have questions around the = error handling with =E2=80=9CfailOnError=E2=80=9D not specified in the = request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1) - = which says that we need to return the error code 409 when the circular = dependency couldn=E2=80=99t be resolved by the server. The behavior of = the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the = specification.
 
  • Scenario1: When there=E2=80=99s a bulk request body with 2 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve, what would be the bulk response? Should the = bulk server return a top level 409 response or a 200 response with = operation response for each failed items (i.e 2 operation responses with = 409 as the code for each).
  • Scenario2: When there=E2=80=99s a bulk = request body with 3 items, failOnErrors flag is not specified in the = request- The server while processing the bulk requests, discovers = circular dependency that it couldn=E2=80=99t resolve for the first 2 = items, while the 3rd items could be processed = successfully, what would be the bulk response? Should it be a  200 = response with operation response for each failed items (i.e 2 operation = responses with 409 as the code for each) and then it also contains the = successful response for the 3rd item
 
Thanks,
Jayadeba
 
_______________________________________________
scim mailing list
scim@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_scim&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8= Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&am= p;m=3DpyJbcSIML-m5QRPAfMRPW1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2Y= bFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D

= --Apple-Mail=_6CCA92E9-47C1-4646-8C4B-B3B149C0834B-- From nobody Mon Aug 20 23:34:36 2018 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 8D473126CC7 for ; Mon, 20 Aug 2018 23:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4lkLlWpKUNI1 for ; Mon, 20 Aug 2018 23:34: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 BE52C130E2A for ; Mon, 20 Aug 2018 23:34: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 w7L6XvWY044548; Tue, 21 Aug 2018 06:34:29 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-2018-07-02; bh=h7lOWUNEBqC+VreIpP3s1YORQcH/7RiZaQzIvNX8wmM=; b=lBBffPrb4H7hKGW9uMeUhBVZi3omlc8Ui5reB8oG2vkNihGAUEPgl+Z0zQuNqMI1PWzF g5ketLvFnOwMQeolV9p5mvKwjVFJg6sYFWLaOFb1y3WxV7/KF5uYoLl1qNO1b1GxCIx/ YonCNZtDBfJQ+Rq1iqa2t9VfeSp25dVndFUR3jNhT8UXwJZs28uNzct2lraT0dFMrLq3 /glcaj8aWlFGqmPbs08Pu2h7Xo44+HRBOFPMkeaPL/7/3t3jeDixGAzvXg+WZfYW1w4T ZJWUwOiZFY1cUPvppQe5Kq3Nq23iL5l/QClK1RlUlne4aFdTBWkdhGyuLMNOBb/dseEi JQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2kxavtje8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Aug 2018 06:34:29 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w7L6YR95014739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Aug 2018 06:34:28 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w7L6YRmv002688; Tue, 21 Aug 2018 06:34:27 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Aug 2018 23:34:26 -0700 From: Phil Hunt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A52F0FB6-30C6-44E8-97F9-7D3ED8493AD3" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 23:34:24 -0700 In-Reply-To: <27055788-3ECB-463A-B28E-B7A014ED7221@paypalcorp.com> Cc: "Morteza Ansari (moransar)" , Chuck Mortimore , "scim@ietf.org" To: "Jena, Jayadeba" References: <8D8C033A-0429-436E-BB75-25754B74C2D7@cisco.com> <27055788-3ECB-463A-B28E-B7A014ED7221@paypalcorp.com> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8991 signatures=668707 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-1807170000 definitions=main-1808210069 Archived-At: Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 06:34:33 -0000 --Apple-Mail=_A52F0FB6-30C6-44E8-97F9-7D3ED8493AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jayadeba, I don=E2=80=99t believe I see an issue here. Keep in mind the following = from Sec 3.7: > failOnErrors > An integer specifying the number of errors that the service > provider will accept before the operation is terminated and an > error response is returned. OPTIONAL in a request. Not valid = in > a response. In the processing rules: > The service provider MUST continue performing as many changes as > possible and disregard partial failures. The client MAY override > this behavior by specifying a value for the "failOnErrors" = attribute. > The "failOnErrors" attribute defines the number of errors that the > service provider should accept before failing the remaining > operations returning the response. Thus, unless a fatal error (e.g. like a syntax/parsing error) occurs, a = 200 response is almost always expected with any errors embedded in the = transaction - even if all transactions fail. In each of your scenarios, I would expect 200 responses with individual = transactions indicating correct success/failure as if they were their = own separate HTTP request - e.g. so you would issue 409 for the specific = transaction status. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba wrote: >=20 > Thanks Phil, Morteza! Appreciate your quick response in clarifying = this. > =20 > It would be great if the spec can be updated to clearly describe the = behavior of the bulk server wrt error handling in partial success cases = so anyone implementing the bulk API later doesn=E2=80=99t come across = the same set of questions. It would be great to add some canonical = examples as well. > =20 > Thanks again! > =20 > Jayadeba > =20 > From: Phil Hunt > Date: Monday, August 20, 2018 at 1:40 PM > To: "Morteza Ansari (moransar)" > Cc: "Jena, Jayadeba" , Chuck Mortimore = , "scim@ietf.org" > Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk = operations > =20 > Morteza/Jena,=20 > =20 > The IDCS (Identity Cloud Service) bulk endpoint returns an overall 200 = and then 409 for each resource operation that failed (due to cycle or = any other reason) and a 200/201 for those that succeed. > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = > phil.hunt@oracle.com >=20 >=20 >> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = > wrote: >> =20 >> Hi Jena, >> =20 >> Best option for getting clarification on SCIM spec is to reach out to = the WG mailing list: scim@ietf.org . Many more = eyes will see it there. >> =20 >> As to your specific question, I am actually not 100% sure. Re-reading = the spec seems to be a bit ambiguous there and I haven=E2=80=99t = actually implemented bulk myself. I believe the answer to both scenarios = is returning 200 responses with operation responses of 409 for the = failed. >> =20 >> Phil, others, do you have a better answer? Have we clarified this = somewhere else in the doc that I am missing? >> =20 >> =20 >> Cheers, >> Morteza >> =20 >> From: "Jena, Jayadeba" > >> Date: Friday, August 17, 2018 at 5:32 PM >> To: "morteza.ansari@cisco.com " = >, Chuck = Mortimore > >> Subject: SCIM: Questions regarding Error handling for Bulk operations >> =20 >> Hi, >> =20 >> I=E2=80=99m from PayPal and trying to understand the SCIM bulk = specification and have questions around the error handling with = =E2=80=9CfailOnError=E2=80=9D not specified in the request. As an = example, I was reading through the section = (https://tools.ietf.org/html/rfc7644#section-3.7.1 = ) - which says that we need to return the error code 409 = when the circular dependency couldn=E2=80=99t be resolved by the server. = The behavior of the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification. >> =20 >> Scenario1: When there=E2=80=99s a bulk request body with 2 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve, what would be the bulk response? Should the = bulk server return a top level 409 response or a 200 response with = operation response for each failed items (i.e 2 operation responses with = 409 as the code for each). >> Scenario2: When there=E2=80=99s a bulk request body with 3 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve for the first 2 items, while the 3rd items = could be processed successfully, what would be the bulk response? Should = it be a 200 response with operation response for each failed items (i.e = 2 operation responses with 409 as the code for each) and then it also = contains the successful response for the 3rd item >> =20 >> Thanks, >> Jayadeba >> =20 >> _______________________________________________ >> 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=3DpyJbcSIML-m5QRPAfMRPW= 1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D= = --Apple-Mail=_A52F0FB6-30C6-44E8-97F9-7D3ED8493AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jayadeba,

I= don=E2=80=99t believe I see an issue here. Keep in mind the following = from Sec 3.7:

failOnErrors
      An integer specifying the number of errors that the service
      provider will accept before the operation is terminated and an
      error response is returned.  OPTIONAL in a request.  Not valid in
      a response.

In the processing rules:
   The service provider MUST =
continue performing as many changes as
   possible and disregard partial failures.  The client MAY override
   this behavior by specifying a value for the "failOnErrors" attribute.
   The "failOnErrors" attribute defines the number of errors that the
   service provider should accept before failing the remaining
   operations returning the response.

Thus, unless a = fatal error (e.g. like a syntax/parsing error) occurs, a 200 response is = almost always expected with any errors embedded in the transaction - = even if all transactions fail.

In each of your scenarios, I would = expect 200 responses with individual transactions indicating correct = success/failure as if they were their own separate HTTP request - e.g. = so you would issue 409 for the specific transaction status.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba <jjena@paypal.com> = wrote:

Thanks = Phil, Morteza! Appreciate your quick response in clarifying this.
 
It would = be great if the spec can be updated to clearly describe the behavior of = the bulk server wrt error handling in partial success cases so anyone = implementing the bulk API later doesn=E2=80=99t come across the same set = of questions. It would be great to add some canonical examples as = well.
 
Thanks = again!
 
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, August 20, 2018 = at 1:40 PM
To: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>
Cc: "Jena, Jayadeba" <jjena@paypal.com>, = Chuck Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
Morteza/Jena, 
 
The IDCS (Identity Cloud Service) bulk = endpoint returns an overall 200 and then 409 for each resource operation = that failed (due to cycle or any other reason) and a 200/201 for those = that succeed.
 
Phil
 
Oracle Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com


On Aug 20, 2018, at 12:11 PM, Morteza = Ansari (moransar) <moransar=3D40cisco.com@dmarc.ietf.org> wrote:
 
Hi Jena,
 
Best option for getting clarification on SCIM spec is to = reach out to the WG mailing list: scim@ietf.org. Many more eyes will see it = there.
 
As to your specific question, I am actually not 100% sure. = Re-reading the spec seems to be a bit ambiguous there and I haven=E2=80=99= t actually implemented bulk myself. I believe the answer to both = scenarios is returning 200 responses with operation responses of 409 for = the failed.
 
Phil, others, do you have a better answer? Have we clarified = this somewhere else in the doc that I am missing?
 
 
Cheers,
Morteza
 
From: "Jena, Jayadeba" <jjena@paypal.com>
Date: Friday, August 17, 2018 = at 5:32 PM
To: "morteza.ansari@cisco.com" <morteza.ansari@cisco.com>, Chuck Mortimore <cmortimore@salesforce.com>
Subject: SCIM: Questions = regarding Error handling for Bulk operations
 
Hi,
 
I=E2=80=99m from PayPal and trying to = understand the SCIM bulk specification and have questions around the = error handling with =E2=80=9CfailOnError=E2=80=9D not specified in the = request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1) = - which says that we need to return the error code 409 when the circular = dependency couldn=E2=80=99t be resolved by the server. The behavior of = the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification.
 
  • Scenario1: = When there=E2=80=99s a bulk request body with 2 items, failOnErrors flag = is not specified in the request- The server while processing the bulk = requests, discovers circular dependency that it couldn=E2=80=99t = resolve, what would be the bulk response? Should the bulk server return = a top level 409 response or a 200 response with operation response for = each failed items (i.e 2 operation responses with 409 as the code for = each).
  • Scenario2: When there=E2=80=99s = a bulk request body with 3 items, failOnErrors flag is not specified in = the request- The server while processing the bulk requests, discovers = circular dependency that it couldn=E2=80=99t resolve for the first 2 = items, while the 3rd items could be processed = successfully, what would be the bulk response? Should it be a  200 = response with operation response for each failed items (i.e 2 operation = responses with 409 as the code for each) and then it also contains the = successful response for the 3rd item
 
Thanks,
Jayadeba
 

= --Apple-Mail=_A52F0FB6-30C6-44E8-97F9-7D3ED8493AD3-- From nobody Tue Aug 21 08:14:00 2018 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 4375D130DFE for ; Tue, 21 Aug 2018 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 aGJAEjcm2Va7 for ; Tue, 21 Aug 2018 08:13:57 -0700 (PDT) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 15366130DC5 for ; Tue, 21 Aug 2018 08:13:57 -0700 (PDT) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7LF9Y8d002340 for ; Tue, 21 Aug 2018 11:13:56 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [158.85.210.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2m0k56x830-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 21 Aug 2018 11:13:55 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Tue, 21 Aug 2018 15:13:55 -0000 Received: from us1b3-smtp05.a3dr.sjc01.isc4sb.com (10.122.203.183) by smtp.notes.na.collabserv.com (10.122.47.50) with smtp.notes.na.collabserv.com ESMTP; Tue, 21 Aug 2018 15:13:52 -0000 Received: from us1b3-mail99.a3dr.sjc01.isc4sb.com ([10.122.105.72]) by us1b3-smtp05.a3dr.sjc01.isc4sb.com with ESMTP id 2018082115135179-693976 ; Tue, 21 Aug 2018 15:13:51 +0000 In-Reply-To: From: "Karl KH Cheng" To: scim@ietf.org, phil.hunt@oracle.com Date: Tue, 21 Aug 2018 15:13:52 +0000 Sensitivity: References: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 16007-1287 | IBM Domino Build SCN1812108_20180501T0841 May 01, 2018 at 08:41 X-KeepSent: 1E3B1DBB:98BFDE33-002582F0:0053384D; type=4; name=$KeepSent X-LLNOutbound: False X-Disclaimed: 14647 X-TNEFEvaluated: 1 X-LLNXfer: False x-cbid: 18082115-7769-0000-0000-0000046F9FBC X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.392621; ST=0; TS=0; UL=0; ISC=; MB=0.001739 X-IBM-SpamModules-Versions: BY=3.00009586; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000266; SDB=6.01076776; UDB=6.00555107; IPR=6.00856746; BA=6.00006081; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00022850; XFM=3.00000015; UTC=2018-08-21 15:13:54 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-08-21 15:06:48 - 6.00008862 x-cbparentid: 18082115-7770-0000-0000-000071C0A14E Message-Id: Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-21_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [scim] SCIM: question regarding idevent/ asynchronous scim X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 15:13:59 -0000
Hi Phil,
 
I found this draft on SCIM id event:
 
Is it still active?  I don't see any activities sinc= e '16 and there is no update to the SCIM protocol spec to define how SCIM i= s to be used asynchronously.
 
=
Thanks and regards,

Karl Cheng
Software Enginee= r
IBM Security

From nobody Tue Aug 21 08:27:21 2018 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 4759D130F4A for ; Tue, 21 Aug 2018 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 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, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] 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 E5rRLCzVNoZ1 for ; Tue, 21 Aug 2018 08:27:06 -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 29AB2130F41 for ; Tue, 21 Aug 2018 08:27:06 -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 w7LFO8EL121905; Tue, 21 Aug 2018 15:27:05 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-2018-07-02; bh=aVPfFopQrLslUBQuA8h/Ak2oS6BdAPTppPepE9pzThc=; b=23H5EsCSeCp6UIOArhfA8yr3Hy14I+AovhgCSywta4s4n+FJbNlEmleyQdDMtpfK19bM 2pgLtEJuvZnFXmN6GV6BxlLHRv06kuug99ej3TVelj7BQ5av1QLJyisn3nq0wvl6dp3D p6KnvEg7zCn3Cht4IBKy3ybpgU7gdnm6V+6Y4JdJ6v/ZFfUsg2WfMnVpycn2xQhoh8/m HfOth+mdRn1EEpHmxkHEy4PFunIjAnHpxKijsgKuGtkjkU51XvQVQF5s2Dh4jVtcbRhT sB0UllNNDPrztWCUTzzfL7DZ+xtQBsC5Raqu6mWYBaypcb+SjI3xkBKMw5nXLspPHkS4 9A== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2kxavtn9kw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Aug 2018 15:27:05 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w7LFQxK8030566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Aug 2018 15:26:59 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w7LFQxaA027855; Tue, 21 Aug 2018 15:26:59 GMT Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Aug 2018 08:26:59 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-C63F4FB0-BE1C-465C-8338-8D59B934ABCC Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Tue, 21 Aug 2018 08:26:57 -0700 Cc: scim@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Karl KH Cheng X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8991 signatures=668707 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-1807170000 definitions=main-1808210161 Archived-At: Subject: Re: [scim] SCIM: question regarding idevent/ asynchronous scim X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 15:27:20 -0000 --Apple-Mail-C63F4FB0-BE1C-465C-8338-8D59B934ABCC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It does need to be revised to conform with RFC8417 which it was waiting on.=20= If there is interest in completing it, I would be interested.=20 Phil > On Aug 21, 2018, at 8:13 AM, Karl KH Cheng wrote: >=20 > Hi Phil, > =20 > I found this draft on SCIM id event: > https://tools.ietf.org/html/draft-hunt-idevent-scim-00 > =20 > Is it still active? I don't see any activities since '16 and there is no u= pdate to the SCIM protocol spec to define how SCIM is to be used asynchronou= sly. > =20 > Thanks and regards, >=20 > Karl Cheng > Software Engineer > IBM Security >=20 --Apple-Mail-C63F4FB0-BE1C-465C-8338-8D59B934ABCC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit It does need to be revised to conform with RFC8417 which it was waiting on. 

If there is interest in completing it, I would be interested. 

Phil

On Aug 21, 2018, at 8:13 AM, Karl KH Cheng <karl.cheng@sg.ibm.com> wrote:

Hi Phil,
 
I found this draft on SCIM id event:
 
Is it still active?  I don't see any activities since '16 and there is no update to the SCIM protocol spec to define how SCIM is to be used asynchronously.
 
Thanks and regards,

Karl Cheng
Software Engineer
IBM Security

--Apple-Mail-C63F4FB0-BE1C-465C-8338-8D59B934ABCC-- From nobody Wed Aug 22 14:49:31 2018 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 ADBCB126F72 for ; Wed, 22 Aug 2018 14:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 wWsU6M3nLMcI for ; Wed, 22 Aug 2018 14:49:26 -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 B8C7912D949 for ; Wed, 22 Aug 2018 14:49:26 -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 w7MLcO9O088858; Wed, 22 Aug 2018 21:49:24 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-2018-07-02; bh=covsFVzmjEle3Yr42kDKctSIoa54CfUAEx4UVe8zAvI=; b=CTlg5LJ9Bf4rUbTgBnatZQhqt1unNl53WBCq6j9wENQlaBAkT0YrTSVx6SxebVV6BZW3 osQKaCwqtkndR2Ke8+/wAyQT7rp9hmpI3uy4imhxXqeaP2AvqS2LXxhav6kgWW792xi+ 2Pf9/4gmJWNWz3Phz9bMhiD0NVvfCNiP0vbKfoiNQvK06ouRVIpeXO2/5bTSEza6diXs AG7AnmIBr0toW+TaCfs3GaZYXy+Yu7bDXev4JxGxVKw90UTK47OWC+NXfM2r+VPK+4fB ee2nmFJDnDi02LLy1fl1l8un6fY1FjLKmF+xV0VtQpE6muuw+l2JBQCwjeWI/A2gUd9r dw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2kxavtvsrq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Aug 2018 21:49:24 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w7MLnIur023221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Aug 2018 21:49:18 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w7MLnHK7026099; Wed, 22 Aug 2018 21:49:18 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 22 Aug 2018 14:49:17 -0700 From: Phil Hunt Message-Id: <3B6258FF-DAC1-4950-AA66-A4EDBA7267B4@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D08F708-539D-4D07-B1F0-332C9B3CE4D2" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 Aug 2018 14:49:15 -0700 In-Reply-To: <45F8D6BB-A097-4272-B30A-23F27B27A477@paypalcorp.com> Cc: "Morteza Ansari (moransar)" , Chuck Mortimore , "scim@ietf.org" To: "Jena, Jayadeba" References: <8D8C033A-0429-436E-BB75-25754B74C2D7@cisco.com> <27055788-3ECB-463A-B28E-B7A014ED7221@paypalcorp.com> <45F8D6BB-A097-4272-B30A-23F27B27A477@paypalcorp.com> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8993 signatures=668707 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-1807170000 definitions=main-1808220215 Archived-At: Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk operations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 21:49:30 -0000 --Apple-Mail=_9D08F708-539D-4D07-B1F0-332C9B3CE4D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The service provider response MUST include the result of all > processed operations. =20 I see the poor wording. =E2=80=9Cprocessed=E2=80=9D could be interpreted = in some circles as successful items only.=20 The intent was to be all records processed whether successful or not. = Without a response clients would not know the outcome of the = =E2=80=9Cmissing=E2=80=9D transactions and would be indeterminate. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Aug 21, 2018, at 12:01 AM, Jena, Jayadeba wrote: >=20 > Phil,=20 > =20 > The processing rules behavior is clear but I felt that the bulk = response handling for the partial failure cases is not super clear (or = ambiguous) from the perspective of a implementor- Whether the bulk = response should contain all failed items or the failed items should be = omitted in the response. This is how I and few of my colleagues at = PayPal reading the spec felt so I reached out to you for clarification. = We felt like there=E2=80=99s no authoritative statement. > =20 > Please feel free to consider this as an exception and ignore my = request to add to the documentation. > =20 > Thanks for the details clarification! It helped. > =20 > Thanks, > Jayadeba > =20 > From: Phil Hunt > Date: Monday, August 20, 2018 at 11:34 PM > To: "Jena, Jayadeba" > Cc: "Morteza Ansari (moransar)" ,= Chuck Mortimore , "scim@ietf.org" = > Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk = operations > =20 > Jayadeba,=20 > =20 > I don=E2=80=99t believe I see an issue here. Keep in mind the = following from Sec 3.7: > =20 >> failOnErrors >> An integer specifying the number of errors that the service >> provider will accept before the operation is terminated and an >> error response is returned. OPTIONAL in a request. Not valid = in >> a response. > =20 > In the processing rules: >> The service provider MUST continue performing as many changes as >> possible and disregard partial failures. The client MAY override >> this behavior by specifying a value for the "failOnErrors" = attribute. >> The "failOnErrors" attribute defines the number of errors that the >> service provider should accept before failing the remaining >> operations returning the response. > =20 > Thus, unless a fatal error (e.g. like a syntax/parsing error) occurs, = a 200 response is almost always expected with any errors embedded in the = transaction - even if all transactions fail. > =20 > In each of your scenarios, I would expect 200 responses with = individual transactions indicating correct success/failure as if they = were their own separate HTTP request - e.g. so you would issue 409 for = the specific transaction status. > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = > phil.hunt@oracle.com >=20 >=20 >> On Aug 20, 2018, at 7:09 PM, Jena, Jayadeba > wrote: >> =20 >> Thanks Phil, Morteza! Appreciate your quick response in clarifying = this. >> =20 >> It would be great if the spec can be updated to clearly describe the = behavior of the bulk server wrt error handling in partial success cases = so anyone implementing the bulk API later doesn=E2=80=99t come across = the same set of questions. It would be great to add some canonical = examples as well. >> =20 >> Thanks again! >> =20 >> Jayadeba >> =20 >> From: Phil Hunt > >> Date: Monday, August 20, 2018 at 1:40 PM >> To: "Morteza Ansari (moransar)" > >> Cc: "Jena, Jayadeba" >, = Chuck Mortimore >, "scim@ietf.org = " > >> Subject: Re: [scim] SCIM: Questions regarding Error handling for Bulk = operations >> =20 >> Morteza/Jena,=20 >> =20 >> The IDCS (Identity Cloud Service) bulk endpoint returns an overall = 200 and then 409 for each resource operation that failed (due to cycle = or any other reason) and a 200/201 for those that succeed. >> =20 >> Phil >> =20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com = >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>> On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = > wrote: >>> =20 >>> Hi Jena, >>> =20 >>> Best option for getting clarification on SCIM spec is to reach out = to the WG mailing list: scim@ietf.org . Many more = eyes will see it there. >>> =20 >>> As to your specific question, I am actually not 100% sure. = Re-reading the spec seems to be a bit ambiguous there and I haven=E2=80=99= t actually implemented bulk myself. I believe the answer to both = scenarios is returning 200 responses with operation responses of 409 for = the failed. >>> =20 >>> Phil, others, do you have a better answer? Have we clarified this = somewhere else in the doc that I am missing? >>> =20 >>> =20 >>> Cheers, >>> Morteza >>> =20 >>> From: "Jena, Jayadeba" > >>> Date: Friday, August 17, 2018 at 5:32 PM >>> To: "morteza.ansari@cisco.com " = >, Chuck = Mortimore > >>> Subject: SCIM: Questions regarding Error handling for Bulk = operations >>> =20 >>> Hi, >>> =20 >>> I=E2=80=99m from PayPal and trying to understand the SCIM bulk = specification and have questions around the error handling with = =E2=80=9CfailOnError=E2=80=9D not specified in the request. As an = example, I was reading through the section = (https://tools.ietf.org/html/rfc7644#section-3.7.1 = ) - which says that we need to return the error code 409 = when the circular dependency couldn=E2=80=99t be resolved by the server. = The behavior of the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification. >>> =20 >>> Scenario1: When there=E2=80=99s a bulk request body with 2 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve, what would be the bulk response? Should the = bulk server return a top level 409 response or a 200 response with = operation response for each failed items (i.e 2 operation responses with = 409 as the code for each). >>> Scenario2: When there=E2=80=99s a bulk request body with 3 items, = failOnErrors flag is not specified in the request- The server while = processing the bulk requests, discovers circular dependency that it = couldn=E2=80=99t resolve for the first 2 items, while the 3rd items = could be processed successfully, what would be the bulk response? Should = it be a 200 response with operation response for each failed items (i.e = 2 operation responses with 409 as the code for each) and then it also = contains the successful response for the 3rd item >>> =20 >>> Thanks, >>> Jayadeba >>> =20 >>> _______________________________________________ >>> 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=3DpyJbcSIML-m5QRPAfMRPW= 1D5vOwW3y_KWQo_pX0bJh0&s=3DQd2Np4bHIUk6wz2YbFfR1mQ9xfEPtgGxHm40luqoUjg&e=3D= = --Apple-Mail=_9D08F708-539D-4D07-B1F0-332C9B3CE4D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
 The service provider =
response MUST include the result of all
   processed operations.

I see the poor wording. =E2=80=9Cprocesse= d=E2=80=9D could be interpreted in some circles as successful items = only. 

The = intent was to be all records processed whether successful or not. = Without a response clients would not know the outcome of the = =E2=80=9Cmissing=E2=80=9D transactions and would be = indeterminate.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Aug 21, 2018, at 12:01 AM, Jena, Jayadeba <jjena@paypal.com> = wrote:

Phil, 
 
The = processing rules behavior is clear but I felt that the bulk response = handling for the partial failure cases is not super clear (or ambiguous) = from the perspective of a implementor- Whether the bulk response should = contain all failed items or the failed items should be omitted in the = response. This is how I and few of my colleagues at PayPal reading the = spec felt so I reached out to you for clarification. We felt like = there=E2=80=99s no authoritative statement.
 
Please = feel free to consider this as an exception and ignore my request to add = to the documentation.
 
Thanks for the details clarification! It helped.
 
Thanks,
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, August 20, 2018 = at 11:34 PM
To: "Jena, Jayadeba" <jjena@paypal.com>
Cc: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>, Chuck = Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
Jayadeba, 
 
I don=E2=80=99t believe I see an issue = here. Keep in mind the following from Sec 3.7:
 
failOnErrors
      An =
integer specifying the number of errors that the service
      provider will accept before =
the operation is terminated and an
      =
error response is returned.  OPTIONAL in a request.  Not valid =
in
      a response.
 
In the processing rules:
   The service provider MUST continue performing as =
many changes as
   possible and disregard partial failures.  =
The client MAY override
   this behavior by specifying a value =
for the "failOnErrors" attribute.
   The "failOnErrors" =
attribute defines the number of errors that the
   service provider should accept before failing =
the remaining
   operations returning the response.
 
Thus, unless a fatal error = (e.g. like a syntax/parsing error) occurs, a 200 response is almost = always expected with any errors embedded in the transaction - even if = all transactions fail.
 
In each of your scenarios, I would expect 200 responses with = individual transactions indicating correct success/failure as if they = were their own separate HTTP request - e.g. so you would issue 409 for = the specific transaction status.
 
Phil
 
Oracle = Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com


On Aug 20, 2018, at 7:09 PM, Jena, = Jayadeba <jjena@paypal.com> = wrote:
 
Thanks Phil, Morteza! = Appreciate your quick response in clarifying this.
 
It would be great if the spec can be = updated to clearly describe the behavior of the bulk server wrt error = handling in partial success cases so anyone implementing the bulk API = later doesn=E2=80=99t come across the same set of questions. It would be = great to add some canonical examples as well.
 
Thanks again!
 
Jayadeba
 
From: Phil Hunt <phil.hunt@oracle.com>
Date: Monday, August 20, 2018 = at 1:40 PM
To: "Morteza Ansari = (moransar)" <moransar=3D40cisco.com@dmarc.ietf.org>
Cc: "Jena, Jayadeba" <jjena@paypal.com>, Chuck = Mortimore <cmortimore@salesforce.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM: = Questions regarding Error handling for Bulk operations
 
Morteza/Jena, 
 
The IDCS (Identity Cloud Service) bulk = endpoint returns an overall 200 and then 409 for each resource operation = that failed (due to cycle or any other reason) and a 200/201 for those = that succeed.
 
Phil
 
Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com



On Aug 20, 2018, at 12:11 PM, Morteza Ansari (moransar) = <moransar=3D40cisco.com@dmarc.ietf.org> = wrote:
 
Hi Jena,
 
Best option for getting clarification = on SCIM spec is to reach out to the WG mailing list: scim@ietf.org. Many more eyes will see it = there.
 
As to your specific question, I am = actually not 100% sure. Re-reading the spec seems to be a bit ambiguous = there and I haven=E2=80=99t actually implemented bulk myself. I believe = the answer to both scenarios is returning 200 responses with operation = responses of 409 for the failed.
 
Phil, others, do you have a better = answer? Have we clarified this somewhere else in the doc that I am = missing?
 
 
Cheers,
Morteza
 
From: "Jena, Jayadeba" <jjena@paypal.com>
Date: Friday, August 17, 2018 = at 5:32 PM
To: "morteza.ansari@cisco.com" <morteza.ansari@cisco.com>, Chuck Mortimore <cmortimore@salesforce.com>
Subject: SCIM: Questions = regarding Error handling for Bulk operations
 
Hi,
 
I=E2=80=99m from PayPal and trying to = understand the SCIM bulk specification and have questions around the = error handling with =E2=80=9CfailOnError=E2=80=9D not specified in the = request. As an example, I was reading through the section (https://tools.ietf.org/html/rfc7644#section-3.7.1) = - which says that we need to return the error code 409 when the circular = dependency couldn=E2=80=99t be resolved by the server. The behavior of = the bulk server wrt is not clear to me when we have the = =E2=80=9CFailOnError=E2=80=9D flag is not specified. Please help clarify = if the following behavior is correct and as per the specification.
 
  • Scenario1: = When there=E2=80=99s a bulk request body with 2 items, failOnErrors flag = is not specified in the request- The server while processing the bulk = requests, discovers circular dependency that it couldn=E2=80=99t = resolve, what would be the bulk response? Should the bulk server return = a top level 409 response or a 200 response with operation response for = each failed items (i.e 2 operation responses with 409 as the code for = each).
  • Scenario2: When there=E2=80=99s = a bulk request body with 3 items, failOnErrors flag is not specified in = the request- The server while processing the bulk requests, discovers = circular dependency that it couldn=E2=80=99t resolve for the first 2 = items, while the 3rd items could be processed = successfully, what would be the bulk response? Should it be a  200 = response with operation response for each failed items (i.e 2 operation = responses with 409 as the code for each) and then it also contains the = successful response for the 3rd item
 
Thanks,
Jayadeba
 

= --Apple-Mail=_9D08F708-539D-4D07-B1F0-332C9B3CE4D2--