From nobody Mon Mar 2 05:55:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7C1A877F for ; Mon, 2 Mar 2015 05:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 8-fDzWou8EsZ for ; Mon, 2 Mar 2015 05:55:19 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715501A8778 for ; Mon, 2 Mar 2015 05:55:00 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 2 Mar 2015 14:54:58 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Mon, 2 Mar 2015 14:54:58 +0100 From: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= To: Phil Hunt Thread-Topic: Proposed text for schema resources vs. messages Thread-Index: AQHQUrm6VQixwJ/pqk2UqrAEFvoCDJ0JKrkA Date: Mon, 2 Mar 2015 13:54:57 +0000 Message-ID: References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> In-Reply-To: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2070.6) x-originating-ip: [10.75.112.74] Content-Type: multipart/alternative; boundary="_000_C48A4B70E98E4E2D9C12837F5DE2E157nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG , Michael Frost Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 13:55:22 -0000 --_000_C48A4B70E98E4E2D9C12837F5DE2E157nexusgroupcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VlcGluZyBzY2hlbWFzIGluc3RlYWQgb2YgbXNnVHlwZSB3b3JrcyBmb3IgbWUsIGFzIGxvbmcg YXMgd2UgY2xhcmlmeSBpdCBpbiB0aGUgdGV4dCBhcyB5b3UgaGF2ZSBkb25lIHRoZXJlLg0KLyBF cmlrDQoNCk9uIDI3IEZlYiAyMDE1LCBhdCAxOToxNywgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSU1QT1JUQU5U OiAgV2UgbmVlZCB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiBwdWJsaXNoZWQgbmV4dCB3ZWVrIGlm IHdlIGFyZSB0byBtYWtlIHRoZSBEYWxsYXMgbWVldGluZyBkZWFkbGluZS4gUGxlYXNlIHJlc3Bv bmQgYnkgVHVlc2RheSBNYXIgMywgOEFNIFBhY2lmaWMuIEJhc2VkIG9uIGZlZWRiYWNrIEkgd2ls bCBwdWJsaXNoIGEgbWlub3IgcmV2aXNpb24gdG8gc2NoZW1hcyBkb2MgVHVlc2RheSBhZnRlcm5v b24sIGFuZCBvbiBUaHVyc2RheSByZXZpc2lvbnMgdG8gQVBJLg0KDQpJbiBhIHByZXZpb3VzIHRo cmVhZCAoaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQv bXNnMDIxMjguaHRtbCksIEVyaWsgcHJvcG9zZWQgd2UgdXNlIGRpZmZlcmVudCBhdHRyaWJ1dGVz IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gU0NJTSBtZXNzYWdlcyBhbmQgcmVzb3VyY2VzIChtc2dU eXBlIGFuZCBzY2hlbWFzKS4NCg0KSSBoYXZlIHRha2VuIGEgbG9vayBhdCB0aGUgaW1wYWN0IG9u IHRoZSBkb2N1bWVudHMgYW5kIEkgdGhpbmsgdGhlIHNvbHV0aW9uIG1heSBiZSBwZXJjZWl2ZWQg YXMgc29tZXdoYXQgbW9yZSBjb21wbGV4IHRoYW4gY29uc2lzdGVudGx5IHVzaW5nIOKAnHNjaGVt YXPigJ0uICBUaGUgbWFpbiByZWFzb24gaXMgdGhhdCBzb21lb25lIG9wZW5pbmcgYSBKU09OIG9i amVjdCBub3cgaGFzIHRvIGxvb2sgZm9yIHR3byBkaWZmZXJlbnQgYXR0cmlidXRlcyB0byB0ZWxs IGlmIHRoZSBvYmplY3QgaXMgYSBTQ0lNIG9iamVjdCBvZiBhbnkgdHlwZS4gSSBhbSBub3Qgc3Vy ZSB0aGlzIG1hdHRlcnMgaW4gcHJhY3RpY2UsIGJ1dCBpdCBkb2VzIOKAnGZlZWzigJ0gY29tcGxl eCBmcm9tIGEgbWVkaWEgdHlwZSBwZXJzcGVjdGl2ZS4NCg0KRnJvbSBhbiBlZGl0b3JpYWwgYW5k IElBTkEgcGVyc3BlY3RpdmUsIEkgYmVsaWV2ZSB1c2luZyDigJxtc2dUeXBl4oCdIG1lYW5zIHRo YXQgd2UgaGF2ZSB0byBidWlsZCBhIHNlcGFyYXRlIElBTkEgcmVnaXN0cnkgZm9yIG1lc3NhZ2Vz IGRpc3RpbmN0IGZyb20gc2NoZW1hcy4gR2l2ZW4gdGhhdCB0aGUgcmV2aWV3IHByb2Nlc3MgaXMg ZXNzZW50aWFsbHkgdGhlIHNhbWUsIEnigJltIG5vdCBzdXJlIHRoZXJlIGlzIGEgbG90IG9mIGJl bmVmaXQuIEkgd29uZGVyIHRoZW4gaWYgY2xhcmlmeWluZyB0ZXh0IG1pZ2h0IG5vdCB3b3JrIGFz IHdlbGwuDQoNCldoYXQgSSBoYXZlIGRvbmUgaXMgd3JpdHRlbiBhIG5ldyBpbnRyb2R1Y3Rpb24g dG8gc2VjdGlvbiAzIG9mIHRoZSBBUEkgc3BlY2lmaWNhdGlvbi4gTXkgaG9wZSBpcyB0aGF0IHRo aXMgc2V0cyB0aGUgc3RhZ2UgZm9yIGhvdyBTQ0lNIHByb3RvY29sIHdvcmtzIGFuZCBjbGVhcmx5 IGVzdGFibGlzaGVzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFNDSU0gcmVzb3VyY2VzIGFuZCBt ZXNzYWdlcy4NCg0KQWN0aW9uIEl0ZW06ICBQTEVBU0UgSU5ESUNBVEUgKGJ5IG5leHQgVHVlc2Rh eSBtb3JuaW5nIGlmIHBvc3NpYmxlKToNCg0KQS4gIEdpdmVuIHRoZSB0ZXh0IGJlbG93LCBkb2Vz IGFueW9uZSBzdHJvbmdseSBwcmVmZXIgdXNpbmcg4oCcbXNnVHlwZeKAnSBpbnN0ZWFkIChhbmQg Y3JlYXRpbmcgYSBuZXcgcmVnaXN0cnkgZm9yIGl0KT8NCg0KQi4gIENvbW1lbnRzIG9uIHRoZSB0 ZXh0Lg0KDQpUaGFua3MhDQoNClBST1BPU0VEIFRFWFQ6DQoNCjMuICBTQ0lNIFByb3RvY29sDQoN CjMuMS4gIEludHJvZHVjdGlvbg0KDQogICBTQ0lNIGlzIGEgcHJvdG9jb2wgYmFzZWQgb24gSFRU UCBbUkZDNzIzMF0uICBBbG9uZyB3aXRoIEhUVFAgaGVhZGVycw0KICAgYW5kIFVSSXMsIFNDSU0g dXNlcyBKU09OIFtSRkM3MTU5XSBwYXlsb2FkcyB0byBjb252ZXkgYm90aCBTQ0lNDQogICByZXNv dXJjZXMgYXMgd2VsbCBhcyByZXF1ZXN0IHBhcmFtZXRlcnMgYW5kIHJlc3BvbnNlIGluZm9ybWF0 aW9uIHN1Y2gNCiAgIGFzIGVycm9ycyBpbiB0aGUgZm9ybSBvZiBKU09OIGJhc2VkIG1lc3NhZ2Vz LiAgVG8gaWRlbnRpZnkgdGhpcw0KICAgY29udGVudCwgU0NJTSB1c2VzIGEgbWVkaWEgdHlwZSBv ZiAiYXBwbGljYXRpb24vc2NpbStqc29uIiAoc2VlDQogICBTZWN0aW9uIDguMSkuDQoNCiAgIEEg U0NJTSByZXNvdXJjZSBpcyBhIEpTT04gb2JqZWN0IHRoYXQgbWF5IGJlIGNyZWF0ZWQsIG1haW50 YWluZWQsIGFuZA0KICAgcmV0cmlldmVkIHRocm91Z2ggSFRUUCBtZXRob2RzIGFzIGRlc2NyaWJl ZCBpbiB0aGlzIGRvY3VtZW50LiAgRWFjaA0KICAgSlNPTiByZXNvdXJjZSByZXByZXNlbnRhdGlv biBjb250YWlucyBhICJzY2hlbWFzIiBhdHRyaWJ1dGUgdGhhdA0KICAgY29udGFpbnMgYSBsaXN0 IG9mIG9uZSBvciBtb3JlIFVSSXMgdGhhdCBpbmRpY2F0ZSBpbmNsdWRlZCBTQ0lNDQogICBzY2hl bWFzIHRoYXQgbWF5IGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlIGF0dHJpYnV0ZXMgY29udGFpbmVk IHdpdGhpbg0KICAgYSByZXNvdXJjZS4gIFdoZW4gcXVlcnlpbmcgYSBTQ0lNIHNlcnZpY2UgcHJv dmlkZXIncyAiL1NjaGVtYXMiDQogICBlbmRwb2ludCBmb3Igc2NoZW1hIGRlZmluaXRpb24gKHNl ZSBTZWN0aW9uIDguNw0KICAgW0ktRC5pZXRmLXNjaW0tY29yZS1zY2hlbWFdKSwgdGhlIHJlc3Bv bnNlIGRlc2NyaWJlcyBob3cgYSBzZXJ2aWNlDQogICBwcm92aWRlciBzdXBwb3J0cyBhbiBhdHRy aWJ1dGUgaW5jbHVkaW5nIHNjaGVtYSBtZXRhLWF0dHJpYnV0ZXMgc3VjaA0KICAgYXMgY2FzZS1l eGFjdG5lc3MsIG11dGFiaWxpdHksIHVuaXF1ZW5lc3MsIHJldHVybmFiaWxpdHksIGFuZCB3aGV0 aGVyDQogICBpdCBpcyByZXF1aXJlZC4gIFdoaWxlIFNDSU0gc2NoZW1hcyBhbmQgYXNzb2NpYXRl ZCBleHRlbnNpb24gbW9kZWwgaXMNCiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNjaW0tY29yZS1z Y2hlbWFdLCBTQ0lNIGNsaWVudHMgc2hvdWxkIGV4cGVjdA0KICAgdGhhdCBzb21lIGF0dHJpYnV0 ZSBzY2hlbWEgTUFZIGNoYW5nZSBmcm9tIGRlcGxveW1lbnQgdG8gZGVwbG95bWVudC4NCiAgIElu IGNhc2VzIHdoZXJlIFNDSU0gbWF5IGJlIHVzZWQgYXMgYW4gb3BlbiBwcm90b2NvbCBpbiBmcm9u dCBvZiBhbg0KICAgYXBwbGljYXRpb24gc2VydmljZSwgaXQgaXMgcXVpdGUgcmVhc29uYWJsZSB0 byBleHBlY3QgdGhhdCBzb21lDQogICBzZXJ2aWNlIHByb3ZpZGVycyBNQVkgb25seSBzdXBwb3J0 IGEgc3ViLXNldCBvZiB0aGUgc2NoZW1hIGRlZmluZWQgaW4NCiAgIFtJLUQuaWV0Zi1zY2ltLWNv cmUtc2NoZW1hXS4NCg0KICAgQSBTQ0lNIG1lc3NhZ2UgaXMgYSBKU09OIG9iamVjdCB0aGF0IGNv bnZleXMgcHJvdG9jb2wgcGFyYW1ldGVycw0KICAgYWJvdXQgYSBTQ0lNIHJlcXVlc3Qgb3IgcmVz cG9uc2UgdGhhdCBhcmUgZGVmaW5lZCBieSB0aGlzDQogICBzcGVjaWZpY2F0aW9uLiAgQXMgd2l0 aCBhIFNDSU0gcmVzb3VyY2UsIGEgU0NJTSBtZXNzYWdlIGlzIGEgSlNPTg0KICAgb2JqZWN0IHRo YXQgY29udGFpbnMgYSAic2NoZW1hcyIgYXR0cmlidXRlIHdpdGggYSBVUkkgd2hvc2UgbmFtZXNw YWNlDQogICBwcmVmaXggYmVnaW5zIHdpdGggInVybjppZXRmOnBhcmFtczpzY2ltOmFwaToiLiAg QXMgU0NJTSBwcm90b2NvbA0KICAgbWVzc2FnZXMgYXJlIGZpeGVkIGFuZCBkZWZpbmVkIGJ5IFND SU0gc3BlY2lmaWNhdGlvbnMgYW5kIHJlZ2lzdGVyZWQNCiAgIGV4dGVuc2lvbnMsIFNDSU0gbWVz c2FnZSBzY2hlbWFzIHVzaW5nIHRoZSBhYm92ZSBwcmVmaXggVVJOIFNIQUxMIE5PVA0KICAgYmUg ZGlzY292ZXJhYmxlIHVzaW5nIHRoZSAiL1NjaGVtYXMiIGVuZHBvaW50Lg0KDQogICBBcyBTQ0lN IGluIGludGVuZGVkIGZvciB1c2Ugd2l0aGluIGNyb3NzLWRvbWFpbiBlbnZpcm9ubWVudHMgd2hl cmUNCiAgIHNjaGVtYXMgTUFZIHZhcnksIHRlY2huaXF1ZXMgc3VjaCBhcyBkb2N1bWVudCB2YWxp ZGF0aW9uLCBzdWNoIGFzIGluDQogICBbWE1MLVNjaGVtYV0sIGFyZSBub3QgcmVjb21tZW5kZWQu ICBBIFNDSU0gc2VydmljZSBwcm92aWRlcg0KICAgaW50ZXJwcmV0cyBhIHJlcXVlc3QgaW4gdGhl IGNvbnRleHQgb2YgaXRzIG93biBzY2hlbWEgKHdoaWNoIG1heSBiZQ0KICAgZGlmZmVyZW50IGZy b20gdGhlIGNsaWVudCdzIHNjaGVtYSkgYW5kIHRoZSBwcm9jZXNzaW5nIHJ1bGVzDQogICBkZXNj cmliZWQgZm9yIGVhY2ggU0NJTSByZXF1ZXN0LiAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBpbiB0 aGlzDQogICBkb2N1bWVudCBkZWZpbmUgcHJvY2Vzc2luZyBydWxlcyBmb3IgU0NJTSB0aGF0IHBy b3ZpZGUgYWxsb3dhbmNlcyBmb3INCiAgIGRpZmZlcmVuY2VzIHdoZXJlIGFwcHJvcHJpYXRlLiAg Rm9yIGV4YW1wbGUsIGluIGEgU0NJTSBQVVQgcmVxdWVzdCwNCiAgICJyZWFkT25seSIgYXR0cmli dXRlcyBhcmUgaWdub3JlZCwgd2hpbGUgInJlYWRXcml0ZSIgYXR0cmlidXRlcyBhcmUNCiAgIHVw ZGF0ZWQuICBUaGVyZSBpcyBubyBuZWVkIGZvciB0aGUgY2xpZW50IHRvIGRpc2NvdmVyIHdoaWNo DQogICBhdHRyaWJ1dGVzIGFyZSAicmVhZE9ubHkiIGFuZCByZW1vdmUgdGhlbSBmcm9tIHRoZSBQ VVQgcmVxdWVzdCBpbg0KICAgYWR2YW5jZSBpbiBvcmRlciB0byBiZSBhY2NlcHRlZC4gIFNpbWls YXJseSBhIFNDSU0gY2xpZW50IFNIT1VMRCBOT1QNCiAgIGV4cGVjdCBhIHNlcnZpY2UgcHJvdmlk ZXIgdG8gcmV0dXJuIFNDSU0gcmVzb3VyY2VzIHdpdGggZXhhY3RseSB0aGUNCiAgIHNhbWUgc2No ZW1hIGFuZCB2YWx1ZXMgYXMgc3VibWl0dGVkLiAgU0NJTSByZXNwb25zZXMgU0hBTEwgcmVmbGVj dA0KICAgcmVzb3VyY2Ugc3RhdGUgYXMgaW50ZXJwcmV0ZWQgYnkgdGhlIFNDSU0gc2VydmljZSBw cm92aWRlci4NCg0KMy4yLiAgU0NJTSBFbmRwb2ludHMNCg0KICAgVGhlIFNDSU0gcHJvdG9jb2wg c3BlY2lmaWVzIHdlbGwta25vd24gZW5kcG9pbnRzIGFuZCBIVFRQIG1ldGhvZHMgZm9yDQogICBt YW5hZ2luZyByZXNvdXJjZXMgZGVmaW5lZCBpbiB0aGUgY29yZSBzY2hlbWE7IGkuZS4sICJVc2Vy IiBhbmQNCg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208 aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0K --_000_C48A4B70E98E4E2D9C12837F5DE2E157nexusgroupcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5LZWVwaW5n IHNjaGVtYXMgaW5zdGVhZCBvZiBtc2dUeXBlIHdvcmtzIGZvciBtZSwgYXMgbG9uZyBhcyB3ZSBj bGFyaWZ5IGl0IGluIHRoZSB0ZXh0IGFzIHlvdSBoYXZlIGRvbmUgdGhlcmUuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPi8gRXJpazwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyNyBGZWIgMjAxNSwgYXQg MTk6MTcsIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t IiBjbGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj5JTVBPUlRBTlQ6ICZuYnNwO1dlIG5lZWQgdG8gZ2V0IHRoaXMgaW5mb3JtYXRpb24g cHVibGlzaGVkIG5leHQgd2VlayBpZiB3ZSBhcmUgdG8gbWFrZSB0aGUgRGFsbGFzIG1lZXRpbmcg ZGVhZGxpbmUuPGIgY2xhc3M9IiI+IFBsZWFzZSByZXNwb25kIGJ5IFR1ZXNkYXkgTWFyIDMsIDhB TSBQYWNpZmljLg0KPC9iPkJhc2VkIG9uIGZlZWRiYWNrIEkgd2lsbCBwdWJsaXNoIGEgbWlub3Ig cmV2aXNpb24gdG8gc2NoZW1hcyBkb2MgVHVlc2RheSBhZnRlcm5vb24sIGFuZCBvbiBUaHVyc2Rh eSByZXZpc2lvbnMgdG8gQVBJLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCkluIGEgcHJldmlvdXMgdGhyZWFkICg8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NjaW0vY3VycmVudC9tc2cwMjEyOC5odG1sIiBjbGFzcz0iIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NjaW0vY3VycmVudC9tc2cwMjEy OC5odG1sPC9hPiksIEVyaWsgcHJvcG9zZWQgd2UgdXNlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIHRv IGRpc3Rpbmd1aXNoIGJldHdlZW4gU0NJTSBtZXNzYWdlcyBhbmQNCiByZXNvdXJjZXMgKG1zZ1R5 cGUgYW5kIHNjaGVtYXMpLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SSBoYXZlIHRha2VuIGEgbG9vayBhdCB0aGUgaW1wYWN0IG9uIHRoZSBkb2N1 bWVudHMgYW5kIEkgdGhpbmsgdGhlIHNvbHV0aW9uIG1heSBiZSBwZXJjZWl2ZWQgYXMgc29tZXdo YXQgbW9yZSBjb21wbGV4IHRoYW4gY29uc2lzdGVudGx5IHVzaW5nIOKAnHNjaGVtYXPigJ0uICZu YnNwO1RoZSBtYWluIHJlYXNvbiBpcyB0aGF0IHNvbWVvbmUgb3BlbmluZyBhIEpTT04gb2JqZWN0 IG5vdyBoYXMgdG8gbG9vayBmb3IgdHdvIGRpZmZlcmVudCBhdHRyaWJ1dGVzDQogdG8gdGVsbCBp ZiB0aGUgb2JqZWN0IGlzIGEgU0NJTSBvYmplY3Qgb2YgYW55IHR5cGUuIEkgYW0gbm90IHN1cmUg dGhpcyBtYXR0ZXJzIGluIHByYWN0aWNlLCBidXQgaXQgZG9lcyDigJxmZWVs4oCdIGNvbXBsZXgg ZnJvbSBhIG1lZGlhIHR5cGUgcGVyc3BlY3RpdmUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gcm9tIGFuIGVkaXRvcmlhbCBhbmQgSUFO QSBwZXJzcGVjdGl2ZSwgSSBiZWxpZXZlIHVzaW5nIOKAnG1zZ1R5cGXigJ0gbWVhbnMgdGhhdCB3 ZSBoYXZlIHRvIGJ1aWxkIGEgc2VwYXJhdGUgSUFOQSByZWdpc3RyeSBmb3IgbWVzc2FnZXMgZGlz dGluY3QgZnJvbSBzY2hlbWFzLiBHaXZlbiB0aGF0IHRoZSByZXZpZXcgcHJvY2VzcyBpcyBlc3Nl bnRpYWxseSB0aGUgc2FtZSwgSeKAmW0gbm90IHN1cmUgdGhlcmUgaXMgYSBsb3Qgb2YgYmVuZWZp dC4NCiBJIHdvbmRlciB0aGVuIGlmIGNsYXJpZnlpbmcgdGV4dCBtaWdodCBub3Qgd29yayBhcyB3 ZWxsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+V2hhdCBJIGhhdmUgZG9uZSBpcyB3cml0dGVuIGEgbmV3IGludHJvZHVjdGlvbiB0byBz ZWN0aW9uIDMgb2YgdGhlIEFQSSBzcGVjaWZpY2F0aW9uLiBNeSBob3BlIGlzIHRoYXQgdGhpcyBz ZXRzIHRoZSBzdGFnZSBmb3IgaG93IFNDSU0gcHJvdG9jb2wgd29ya3MgYW5kIGNsZWFybHkgZXN0 YWJsaXNoZXMgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gU0NJTSByZXNvdXJjZXMgYW5kIG1lc3Nh Z2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGIgY2xhc3M9IiI+QWN0aW9uIEl0ZW06ICZuYnNwO1BMRUFTRSBJTkRJQ0FURSAoYnkg bmV4dCBUdWVzZGF5IG1vcm5pbmcgaWYgcG9zc2libGUpOjwvYj48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkEuICZuYnNwO0dpdmVuIHRo ZSB0ZXh0IGJlbG93LCBkb2VzIGFueW9uZSBzdHJvbmdseSBwcmVmZXIgdXNpbmcg4oCcbXNnVHlw ZeKAnSBpbnN0ZWFkIChhbmQgY3JlYXRpbmcgYSBuZXcgcmVnaXN0cnkgZm9yIGl0KT88L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkIuICZu YnNwO0NvbW1lbnRzIG9uIHRoZSB0ZXh0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UFJPUE9TRUQgVEVYVDo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRl LXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPjxwcmUgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyIgY2xhc3M9IiI+My4gIFNDSU0gUHJvdG9jb2wN Cg0KMy4xLiAgSW50cm9kdWN0aW9uDQoNCiAgIFNDSU0gaXMgYSBwcm90b2NvbCBiYXNlZCBvbiBI VFRQIFtSRkM3MjMwXS4gIEFsb25nIHdpdGggSFRUUCBoZWFkZXJzDQogICBhbmQgVVJJcywgU0NJ TSB1c2VzIEpTT04gW1JGQzcxNTldIHBheWxvYWRzIHRvIGNvbnZleSBib3RoIFNDSU0NCiAgIHJl c291cmNlcyBhcyB3ZWxsIGFzIHJlcXVlc3QgcGFyYW1ldGVycyBhbmQgcmVzcG9uc2UgaW5mb3Jt YXRpb24gc3VjaA0KICAgYXMgZXJyb3JzIGluIHRoZSBmb3JtIG9mIEpTT04gYmFzZWQgbWVzc2Fn ZXMuICBUbyBpZGVudGlmeSB0aGlzDQogICBjb250ZW50LCBTQ0lNIHVzZXMgYSBtZWRpYSB0eXBl IG9mICZxdW90O2FwcGxpY2F0aW9uL3NjaW0mIzQzO2pzb24mcXVvdDsgKHNlZQ0KICAgU2VjdGlv biA4LjEpLg0KDQogICBBIFNDSU0gcmVzb3VyY2UgaXMgYSBKU09OIG9iamVjdCB0aGF0IG1heSBi ZSBjcmVhdGVkLCBtYWludGFpbmVkLCBhbmQNCiAgIHJldHJpZXZlZCB0aHJvdWdoIEhUVFAgbWV0 aG9kcyBhcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIEVhY2gNCiAgIEpTT04gcmVzb3Vy Y2UgcmVwcmVzZW50YXRpb24gY29udGFpbnMgYSAmcXVvdDtzY2hlbWFzJnF1b3Q7IGF0dHJpYnV0 ZSB0aGF0DQogICBjb250YWlucyBhIGxpc3Qgb2Ygb25lIG9yIG1vcmUgVVJJcyB0aGF0IGluZGlj YXRlIGluY2x1ZGVkIFNDSU0NCiAgIHNjaGVtYXMgdGhhdCBtYXkgYmUgdXNlZCB0byBpbmRpY2F0 ZSB0aGUgYXR0cmlidXRlcyBjb250YWluZWQgd2l0aGluDQogICBhIHJlc291cmNlLiAgV2hlbiBx dWVyeWluZyBhIFNDSU0gc2VydmljZSBwcm92aWRlcidzICZxdW90Oy9TY2hlbWFzJnF1b3Q7DQog ICBlbmRwb2ludCBmb3Igc2NoZW1hIGRlZmluaXRpb24gKHNlZSBTZWN0aW9uIDguNw0KICAgW0kt RC5pZXRmLXNjaW0tY29yZS1zY2hlbWFdKSwgdGhlIHJlc3BvbnNlIGRlc2NyaWJlcyBob3cgYSBz ZXJ2aWNlDQogICBwcm92aWRlciBzdXBwb3J0cyBhbiBhdHRyaWJ1dGUgaW5jbHVkaW5nIHNjaGVt YSBtZXRhLWF0dHJpYnV0ZXMgc3VjaA0KICAgYXMgY2FzZS1leGFjdG5lc3MsIG11dGFiaWxpdHks IHVuaXF1ZW5lc3MsIHJldHVybmFiaWxpdHksIGFuZCB3aGV0aGVyDQogICBpdCBpcyByZXF1aXJl ZC4gIFdoaWxlIFNDSU0gc2NoZW1hcyBhbmQgYXNzb2NpYXRlZCBleHRlbnNpb24gbW9kZWwgaXMN CiAgIGRlZmluZWQgaW4gW0ktRC5pZXRmLXNjaW0tY29yZS1zY2hlbWFdLCBTQ0lNIGNsaWVudHMg c2hvdWxkIGV4cGVjdA0KICAgdGhhdCBzb21lIGF0dHJpYnV0ZSBzY2hlbWEgTUFZIGNoYW5nZSBm cm9tIGRlcGxveW1lbnQgdG8gZGVwbG95bWVudC4NCiAgIEluIGNhc2VzIHdoZXJlIFNDSU0gbWF5 IGJlIHVzZWQgYXMgYW4gb3BlbiBwcm90b2NvbCBpbiBmcm9udCBvZiBhbg0KICAgYXBwbGljYXRp b24gc2VydmljZSwgaXQgaXMgcXVpdGUgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCBzb21lDQog ICBzZXJ2aWNlIHByb3ZpZGVycyBNQVkgb25seSBzdXBwb3J0IGEgc3ViLXNldCBvZiB0aGUgc2No ZW1hIGRlZmluZWQgaW4NCiAgIFtJLUQuaWV0Zi1zY2ltLWNvcmUtc2NoZW1hXS4NCg0KICAgQSBT Q0lNIG1lc3NhZ2UgaXMgYSBKU09OIG9iamVjdCB0aGF0IGNvbnZleXMgcHJvdG9jb2wgcGFyYW1l dGVycw0KICAgYWJvdXQgYSBTQ0lNIHJlcXVlc3Qgb3IgcmVzcG9uc2UgdGhhdCBhcmUgZGVmaW5l ZCBieSB0aGlzDQogICBzcGVjaWZpY2F0aW9uLiAgQXMgd2l0aCBhIFNDSU0gcmVzb3VyY2UsIGEg U0NJTSBtZXNzYWdlIGlzIGEgSlNPTg0KICAgb2JqZWN0IHRoYXQgY29udGFpbnMgYSAmcXVvdDtz Y2hlbWFzJnF1b3Q7IGF0dHJpYnV0ZSB3aXRoIGEgVVJJIHdob3NlIG5hbWVzcGFjZQ0KICAgcHJl Zml4IGJlZ2lucyB3aXRoICZxdW90O3VybjppZXRmOnBhcmFtczpzY2ltOmFwaTomcXVvdDsuICBB cyBTQ0lNIHByb3RvY29sDQogICBtZXNzYWdlcyBhcmUgZml4ZWQgYW5kIGRlZmluZWQgYnkgU0NJ TSBzcGVjaWZpY2F0aW9ucyBhbmQgcmVnaXN0ZXJlZA0KICAgZXh0ZW5zaW9ucywgU0NJTSBtZXNz YWdlIHNjaGVtYXMgdXNpbmcgdGhlIGFib3ZlIHByZWZpeCBVUk4gU0hBTEwgTk9UDQogICBiZSBk aXNjb3ZlcmFibGUgdXNpbmcgdGhlICZxdW90Oy9TY2hlbWFzJnF1b3Q7IGVuZHBvaW50Lg0KDQog ICBBcyBTQ0lNIGluIGludGVuZGVkIGZvciB1c2Ugd2l0aGluIGNyb3NzLWRvbWFpbiBlbnZpcm9u bWVudHMgd2hlcmUNCiAgIHNjaGVtYXMgTUFZIHZhcnksIHRlY2huaXF1ZXMgc3VjaCBhcyBkb2N1 bWVudCB2YWxpZGF0aW9uLCBzdWNoIGFzIGluDQogICBbWE1MLVNjaGVtYV0sIGFyZSBub3QgcmVj b21tZW5kZWQuICBBIFNDSU0gc2VydmljZSBwcm92aWRlcg0KICAgaW50ZXJwcmV0cyBhIHJlcXVl c3QgaW4gdGhlIGNvbnRleHQgb2YgaXRzIG93biBzY2hlbWEgKHdoaWNoIG1heSBiZQ0KICAgZGlm ZmVyZW50IGZyb20gdGhlIGNsaWVudCdzIHNjaGVtYSkgYW5kIHRoZSBwcm9jZXNzaW5nIHJ1bGVz DQogICBkZXNjcmliZWQgZm9yIGVhY2ggU0NJTSByZXF1ZXN0LiAgVGhlIGZvbGxvd2luZyBzZWN0 aW9ucyBpbiB0aGlzDQogICBkb2N1bWVudCBkZWZpbmUgcHJvY2Vzc2luZyBydWxlcyBmb3IgU0NJ TSB0aGF0IHByb3ZpZGUgYWxsb3dhbmNlcyBmb3INCiAgIGRpZmZlcmVuY2VzIHdoZXJlIGFwcHJv cHJpYXRlLiAgRm9yIGV4YW1wbGUsIGluIGEgU0NJTSBQVVQgcmVxdWVzdCwNCiAgICZxdW90O3Jl YWRPbmx5JnF1b3Q7IGF0dHJpYnV0ZXMgYXJlIGlnbm9yZWQsIHdoaWxlICZxdW90O3JlYWRXcml0 ZSZxdW90OyBhdHRyaWJ1dGVzIGFyZQ0KICAgdXBkYXRlZC4gIFRoZXJlIGlzIG5vIG5lZWQgZm9y IHRoZSBjbGllbnQgdG8gZGlzY292ZXIgd2hpY2gNCiAgIGF0dHJpYnV0ZXMgYXJlICZxdW90O3Jl YWRPbmx5JnF1b3Q7IGFuZCByZW1vdmUgdGhlbSBmcm9tIHRoZSBQVVQgcmVxdWVzdCBpbg0KICAg YWR2YW5jZSBpbiBvcmRlciB0byBiZSBhY2NlcHRlZC4gIFNpbWlsYXJseSBhIFNDSU0gY2xpZW50 IFNIT1VMRCBOT1QNCiAgIGV4cGVjdCBhIHNlcnZpY2UgcHJvdmlkZXIgdG8gcmV0dXJuIFNDSU0g cmVzb3VyY2VzIHdpdGggZXhhY3RseSB0aGUNCiAgIHNhbWUgc2NoZW1hIGFuZCB2YWx1ZXMgYXMg c3VibWl0dGVkLiAgU0NJTSByZXNwb25zZXMgU0hBTEwgcmVmbGVjdA0KICAgcmVzb3VyY2Ugc3Rh dGUgYXMgaW50ZXJwcmV0ZWQgYnkgdGhlIFNDSU0gc2VydmljZSBwcm92aWRlci4NCg0KMy4yLiAg U0NJTSBFbmRwb2ludHMNCg0KICAgVGhlIFNDSU0gcHJvdG9jb2wgc3BlY2lmaWVzIHdlbGwta25v d24gZW5kcG9pbnRzIGFuZCBIVFRQIG1ldGhvZHMgZm9yDQogICBtYW5hZ2luZyByZXNvdXJjZXMg ZGVmaW5lZCBpbiB0aGUgY29yZSBzY2hlbWE7IGkuZS4sICZxdW90O1VzZXImcXVvdDsgYW5kPC9w cmU+PHNwYW4gaWQ9IngtYXBwbGUtc2VsZWN0aW9uOmVuZCIgY2xhc3M9IiI+PC9zcGFuPjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjwvcHJlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4 dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog MjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNw YW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXItc3BhY2luZzogMHB4 OyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi Pg0KPHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6 IHNlcGFyYXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3 b3JkLXNwYWNpbmc6IDBweDsgYm9yZGVyLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29y YXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3Jk LXNwYWNpbmc6IDBweDsgYm9yZGVyLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRp b25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHNw YW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFy YXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyBib3JkZXItc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlBoaWw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkBpbmRlcGVuZGVudGlkPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vIiBjbGFzcz0i Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNzPSIiPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C48A4B70E98E4E2D9C12837F5DE2E157nexusgroupcom_-- From nobody Mon Mar 2 07:43:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019C41A1B95 for ; Mon, 2 Mar 2015 07:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 BBCwBrFldxUN for ; Mon, 2 Mar 2015 07:43:28 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17691A008A for ; Mon, 2 Mar 2015 07:43:26 -0800 (PST) Received: by igdh15 with SMTP id h15so18170391igd.4 for ; Mon, 02 Mar 2015 07:43:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4PKiKgluPobKL5536wUKnuySA6tArSxLTCPafrF2mBk=; b=Hv8pUCidM8iWJlYNWO40r4DbkaU1ASndQb9nLfXqq0DugGDlIzL7+vQHMwUJe1gtIg RFlAvCXf6PtpIYIryrq6PHdtwSUHbrwXycLsxm8EyN41jKdDLk8zYf8PGc2EdYakvZSe i/AaMo4SrbFmcAmjJavG+OiyQUk+kND3471SoZnUaz29brHgQrTo30xlMNQCBJy1pQum vDinUW2DdPM//75Up6iU1o6xAxfkpG8f1UnN7MPY0etogYAO3wqWBTSEhjA23FadXdKi Qh6862z6E2YKMdXOTqkxGIZQ1/5HBYdOe58BKTftcmlO8Yxcnj7H3N6eX/yF63UiYLYI Xpmw== X-Gm-Message-State: ALoCoQmerL+F3wekb9YMTkW5Em+5dWoGj/OBCIZR3NBa7moMQlQoGWL2L+qVvx81RFqU/XXQO3AK X-Received: by 10.107.130.25 with SMTP id e25mr37716402iod.49.1425311005791; Mon, 02 Mar 2015 07:43:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.127.141 with HTTP; Mon, 2 Mar 2015 07:43:05 -0800 (PST) In-Reply-To: References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> From: Ian Glazer Date: Mon, 2 Mar 2015 10:43:05 -0500 Message-ID: To: =?UTF-8?Q?Erik_Wahlstr=C3=B6m_neXus?= Content-Type: multipart/alternative; boundary=001a113fb6d63216df0510501454 Archived-At: Cc: SCIM WG , Michael Frost , Phil Hunt Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 15:43:31 -0000 --001a113fb6d63216df0510501454 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm with Erik on this On Mon, Mar 2, 2015 at 8:54 AM, Erik Wahlstr=C3=B6m neXus < erik.wahlstrom@nexusgroup.com> wrote: > Keeping schemas instead of msgType works for me, as long as we clarify > it in the text as you have done there. > / Erik > > On 27 Feb 2015, at 19:17, Phil Hunt wrote: > > IMPORTANT: We need to get this information published next week if we > are to make the Dallas meeting deadline.* Please respond by Tuesday Mar > 3, 8AM Pacific. *Based on feedback I will publish a minor revision to > schemas doc Tuesday afternoon, and on Thursday revisions to API. > > In a previous thread ( > https://www.ietf.org/mail-archive/web/scim/current/msg02128.html), Erik > proposed we use different attributes to distinguish between SCIM messages > and resources (msgType and schemas). > > I have taken a look at the impact on the documents and I think the > solution may be perceived as somewhat more complex than consistently usin= g > =E2=80=9Cschemas=E2=80=9D. The main reason is that someone opening a JSO= N object now has > to look for two different attributes to tell if the object is a SCIM obje= ct > of any type. I am not sure this matters in practice, but it does =E2=80= =9Cfeel=E2=80=9D > complex from a media type perspective. > > From an editorial and IANA perspective, I believe using =E2=80=9CmsgType= =E2=80=9D means > that we have to build a separate IANA registry for messages distinct from > schemas. Given that the review process is essentially the same, I=E2=80= =99m not > sure there is a lot of benefit. I wonder then if clarifying text might no= t > work as well. > > What I have done is written a new introduction to section 3 of the API > specification. My hope is that this sets the stage for how SCIM protocol > works and clearly establishes the differences between SCIM resources and > messages. > > *Action Item: PLEASE INDICATE (by next Tuesday morning if possible):* > > A. Given the text below, does anyone strongly prefer using =E2=80=9Cmsg= Type=E2=80=9D > instead (and creating a new registry for it)? > > B. Comments on the text. > > Thanks! > > PROPOSED TEXT: > > 3. SCIM Protocol > > 3.1. Introduction > > SCIM is a protocol based on HTTP [RFC7230]. Along with HTTP headers > and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM > resources as well as request parameters and response information such > as errors in the form of JSON based messages. To identify this > content, SCIM uses a media type of "application/scim+json" (see > Section 8.1). > > A SCIM resource is a JSON object that may be created, maintained, and > retrieved through HTTP methods as described in this document. Each > JSON resource representation contains a "schemas" attribute that > contains a list of one or more URIs that indicate included SCIM > schemas that may be used to indicate the attributes contained within > a resource. When querying a SCIM service provider's "/Schemas" > endpoint for schema definition (see Section 8.7 > [I-D.ietf-scim-core-schema]), the response describes how a service > provider supports an attribute including schema meta-attributes such > as case-exactness, mutability, uniqueness, returnability, and whether > it is required. While SCIM schemas and associated extension model is > defined in [I-D.ietf-scim-core-schema], SCIM clients should expect > that some attribute schema MAY change from deployment to deployment. > In cases where SCIM may be used as an open protocol in front of an > application service, it is quite reasonable to expect that some > service providers MAY only support a sub-set of the schema defined in > [I-D.ietf-scim-core-schema]. > > A SCIM message is a JSON object that conveys protocol parameters > about a SCIM request or response that are defined by this > specification. As with a SCIM resource, a SCIM message is a JSON > object that contains a "schemas" attribute with a URI whose namespace > prefix begins with "urn:ietf:params:scim:api:". As SCIM protocol > messages are fixed and defined by SCIM specifications and registered > extensions, SCIM message schemas using the above prefix URN SHALL NOT > be discoverable using the "/Schemas" endpoint. > > As SCIM in intended for use within cross-domain environments where > schemas MAY vary, techniques such as document validation, such as in > [XML-Schema], are not recommended. A SCIM service provider > interprets a request in the context of its own schema (which may be > different from the client's schema) and the processing rules > described for each SCIM request. The following sections in this > document define processing rules for SCIM that provide allowances for > differences where appropriate. For example, in a SCIM PUT request, > "readOnly" attributes are ignored, while "readWrite" attributes are > updated. There is no need for the client to discover which > attributes are "readOnly" and remove them from the PUT request in > advance in order to be accepted. Similarly a SCIM client SHOULD NOT > expect a service provider to return SCIM resources with exactly the > same schema and values as submitted. SCIM responses SHALL reflect > resource state as interpreted by the SCIM service provider. > > 3.2. SCIM Endpoints > > The SCIM protocol specifies well-known endpoints and HTTP methods for > managing resources defined in the core schema; i.e., "User" and > > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a113fb6d63216df0510501454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm with Erik on this
=
On Mon, Mar 2, 2015 at 8:54 AM, Erik Wahlstr= =C3=B6m neXus <erik.wahlstrom@nexusgroup.com> wr= ote:
Keeping schemas instead of msgType works for me, as long as we clarify= it in the text as you have done there.
/ Erik

On 27 Feb 2015, at 19:17, Phil Hunt <phil.hunt@oracle.com> wrote:

IMPORTANT: =C2=A0We need to get this information published next week i= f we are to make the Dallas meeting deadline. Please respond by Tuesday = Mar 3, 8AM Pacific. Based on feedback I will publish a minor revision to schemas doc Tuesda= y afternoon, and on Thursday revisions to API.

In a previous thread (https://www.ietf.org/mail-archive= /web/scim/current/msg02128.html), Erik proposed we use different attrib= utes to distinguish between SCIM messages and resources (msgType and schemas).

I have taken a look at the impact on the documents and I think the sol= ution may be perceived as somewhat more complex than consistently using =E2= =80=9Cschemas=E2=80=9D.=C2=A0 The main reason is that someone opening a JSO= N object now has to look for two different attributes to tell if the object is a SCIM object of any type. I am not sure this mat= ters in practice, but it does =E2=80=9Cfeel=E2=80=9D complex from a media t= ype perspective.

From an editorial and IANA perspective, I believe using =E2=80=9CmsgTy= pe=E2=80=9D means that we have to build a separate IANA registry for messag= es distinct from schemas. Given that the review process is essentially the = same, I=E2=80=99m not sure there is a lot of benefit. I wonder then if clarifying text might not work as well.

What I have done is written a new introduction to section 3 of the API= specification. My hope is that this sets the stage for how SCIM protocol w= orks and clearly establishes the differences between SCIM resources and mes= sages.

Action Item: =C2=A0PLEASE INDICATE (by next Tuesday morning if poss= ible):

A.=C2=A0 Given the text below, does anyone strongly prefer using =E2= =80=9CmsgType=E2=80=9D instead (and creating a new registry for it)?

B.=C2=A0 Comments on the text.

Thanks!

PROPOSED TEXT:
3.  SCIM Protocol

3.1.  Introduction

   SCIM is a protocol based on HTTP [RFC7230].  Along with HTTP headers
   and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM
   resources as well as request parameters and response information such
   as errors in the form of JSON based messages.  To identify this
   content, SCIM uses a media type of "application/scim+json" (se=
e
   Section 8.1).

   A SCIM resource is a JSON object that may be created, maintained, and
   retrieved through HTTP methods as described in this document.  Each
   JSON resource representation contains a "schemas" attribute th=
at
   contains a list of one or more URIs that indicate included SCIM
   schemas that may be used to indicate the attributes contained within
   a resource.  When querying a SCIM service provider's "/Schemas&=
quot;
   endpoint for schema definition (see Section 8.7
   [I-D.ietf-scim-core-schema]), the response describes how a service
   provider supports an attribute including schema meta-attributes such
   as case-exactness, mutability, uniqueness, returnability, and whether
   it is required.  While SCIM schemas and associated extension model is
   defined in [I-D.ietf-scim-core-schema], SCIM clients should expect
   that some attribute schema MAY change from deployment to deployment.
   In cases where SCIM may be used as an open protocol in front of an
   application service, it is quite reasonable to expect that some
   service providers MAY only support a sub-set of the schema defined in
   [I-D.ietf-scim-core-schema].

   A SCIM message is a JSON object that conveys protocol parameters
   about a SCIM request or response that are defined by this
   specification.  As with a SCIM resource, a SCIM message is a JSON
   object that contains a "schemas" attribute with a URI whose na=
mespace
   prefix begins with "urn:ietf:params:scim:api:".  As SCIM proto=
col
   messages are fixed and defined by SCIM specifications and registered
   extensions, SCIM message schemas using the above prefix URN SHALL NOT
   be discoverable using the "/Schemas" endpoint.

   As SCIM in intended for use within cross-domain environments where
   schemas MAY vary, techniques such as document validation, such as in
   [XML-Schema], are not recommended.  A SCIM service provider
   interprets a request in the context of its own schema (which may be
   different from the client's schema) and the processing rules
   described for each SCIM request.  The following sections in this
   document define processing rules for SCIM that provide allowances for
   differences where appropriate.  For example, in a SCIM PUT request,
   "readOnly" attributes are ignored, while "readWrite"=
 attributes are
   updated.  There is no need for the client to discover which
   attributes are "readOnly" and remove them from the PUT request=
 in
   advance in order to be accepted.  Similarly a SCIM client SHOULD NOT
   expect a service provider to return SCIM resources with exactly the
   same schema and values as submitted.  SCIM responses SHALL reflect
   resource state as interpreted by the SCIM service provider.

3.2.  SCIM Endpoints

   The SCIM protocol specifies well-known endpoints and HTTP methods for
   managing resources defined in the core schema; i.e., "User" an=
d



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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--001a113fb6d63216df0510501454-- From nobody Mon Mar 2 11:07:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2D1A88E7 for ; Mon, 2 Mar 2015 11:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FhrOAiUaLIYm for ; Mon, 2 Mar 2015 11:07:16 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623521A88D8 for ; Mon, 2 Mar 2015 11:07:16 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t22J7FEX028758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Mar 2015 19:07:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t22J7E3c002695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Mar 2015 19:07:15 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t22J7EL4022543 for ; Mon, 2 Mar 2015 19:07:14 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Mar 2015 11:07:13 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D786CF8D-6EB7-4EF4-B030-C7B23940F5B9" Message-Id: Date: Mon, 2 Mar 2015 11:07:12 -0800 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 19:07:17 -0000 --Apple-Mail=_D786CF8D-6EB7-4EF4-B030-C7B23940F5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was looking through the schema document and cleaning up the data type = characteristics (as discussed previously), I notice that the reference = to XML-Schema is to the October 2004 one and not the 2012 XML Schema. = The IETF will likely require us to reference the current spec, so I = should probably update the reference. Looking at the binary attribute representation, I am wondering if we = should change this to the current IETF specification which is: RFC4648 = rather than reference XML-Schema 3.2.16 (of the 2004 schema spec). Do we want to further clarify that the encoding be: base64url? Not a = javascript expert, but wondering if we need to use url safe encoding? = This may result in a normative clarification for some. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_D786CF8D-6EB7-4EF4-B030-C7B23940F5B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I was looking through = the schema document and cleaning up the data type characteristics (as = discussed previously), I notice that the reference to XML-Schema is to = the October 2004 one and not the 2012 XML Schema.  The IETF will = likely require us to reference the current spec, so I should probably = update the reference.

Looking at the binary attribute representation, I am = wondering if we should change this to the current IETF specification = which is: RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 = schema spec).

Do= we want to further clarify that the encoding be: base64url?   Not = a javascript expert, but wondering if we need to use url safe encoding? = This may result in a normative clarification for some.


= --Apple-Mail=_D786CF8D-6EB7-4EF4-B030-C7B23940F5B9-- From nobody Mon Mar 2 12:07:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48401A8900 for ; Mon, 2 Mar 2015 12:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 dR_ZTs6RaIot for ; Mon, 2 Mar 2015 12:07:15 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164831A1BD7 for ; Mon, 2 Mar 2015 12:07:14 -0800 (PST) Received: by iecat20 with SMTP id at20so51110095iec.12 for ; Mon, 02 Mar 2015 12:07:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5D8wGsRD0wilBjY6czJzK51n7zZCIU4dlauhjsQNsFA=; b=EHj1aPZWjBITURvbn6ECNHcx8dGMU7xHsCufyRCeUtQIO9SYOO2RXJKpytrls9lva+ cLVZBqYGstv7XnoPPLhkfmIRCvkd2YvZ+tPGx9Hx9UJUHdMl+6Quf9ZVh0ZGBJ2fA3lN W6aMDvZbmtTWf175g2HW9jrscuUY16g5jmPffJ6AX8UDoxmvM8D4X3yxGZ6hUgDjIWrk buPSbgypp+u9XkALfebEqAdSwyp9lKMXUe2Hr2CXAsg0rhpKKhrDE9z9Lp/Os0mlidz5 IqNNMdnJiVGt6QOOMOEkBU8U1JVvBa+e6wu9AHZAbFJ7TcUtlyTPt5r4gnW6Etci5aVQ bgVA== X-Gm-Message-State: ALoCoQklup9/+q/BHauxWQ2zPA3uSGM8viJv+Y/MBnaf6Q54oUiVgSD88Wz9BsW5mWXBXUTnL5UP X-Received: by 10.42.154.202 with SMTP id r10mr20331891icw.4.1425326834322; Mon, 02 Mar 2015 12:07:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.127.141 with HTTP; Mon, 2 Mar 2015 12:06:54 -0800 (PST) In-Reply-To: References: From: Ian Glazer Date: Mon, 2 Mar 2015 15:06:54 -0500 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=90e6ba6e8796a627db051053c302 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:07:16 -0000 --90e6ba6e8796a627db051053c302 Content-Type: text/plain; charset=UTF-8 Would this be base64url "required" or "recommended"? Would the encoding type be a declared attribute of the SP? On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > > I was looking through the schema document and cleaning up the data type > characteristics (as discussed previously), I notice that the reference to > XML-Schema is to the October 2004 one and not the 2012 XML Schema. The > IETF will likely require us to reference the current spec, so I should > probably update the reference. > > Looking at the binary attribute representation, I am wondering if we > should change this to the current IETF specification which is: RFC4648 > rather than reference XML-Schema 3.2.16 (of the 2004 schema spec). > > Do we want to further clarify that the encoding be: base64url? Not a > javascript expert, but wondering if we need to use url safe encoding? This > may result in a normative clarification for some. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --90e6ba6e8796a627db051053c302 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would this be base64url "required" or "reco= mmended"?

Would the encoding type be a declared att= ribute of the SP?

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <= ;phil.hunt@oracle= .com> wrote:

I was looking through the schema docum= ent and cleaning up the data type characteristics (as discussed previously)= , I notice that the reference to XML-Schema is to the October 2004 one and = not the 2012 XML Schema.=C2=A0 The IETF will likely require us to reference= the current spec, so I should probably update the reference.

Looking at the binary attribute representation, I am wondering if we = should change this to the current IETF specification which is: RFC4648 rath= er than reference XML-Schema 3.2.16 (of the 2004 schema spec).
Do we want to further clarify that the encoding be: base64url?= =C2=A0 Not a javascript expert, but wondering if we need to use url safe e= ncoding? This may result in a normative clarification for some.
<= br>
=
Phil

@independentid
<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om


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




--
Ian Glazer
Senio= r Director, Identity
+1 202 255 3166
--90e6ba6e8796a627db051053c302-- From nobody Mon Mar 2 12:25:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623EB1A886D for ; Mon, 2 Mar 2015 12:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1bX7ttxN7ftD for ; Mon, 2 Mar 2015 12:25:36 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50CD1A1ABB for ; Mon, 2 Mar 2015 12:25:36 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t22KPZEn030239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Mar 2015 20:25:36 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t22KPZYV019890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2015 20:25:35 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t22KPZbG016814; Mon, 2 Mar 2015 20:25:35 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Mar 2015 12:25:34 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-1551877B-D1D0-478C-A76F-AC4B47EEA4FD Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Mon, 2 Mar 2015 12:25:33 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ian Glazer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 20:25:38 -0000 --Apple-Mail-1551877B-D1D0-478C-A76F-AC4B47EEA4FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think it should be one form.=20 My recommendation would be base64url for max utility. Especially if we start= defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 Phil > On Mar 2, 2015, at 12:06, Ian Glazer wrote: >=20 > Would this be base64url "required" or "recommended"? >=20 > Would the encoding type be a declared attribute of the SP? >=20 >> On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: >>=20 >> I was looking through the schema document and cleaning up the data type c= haracteristics (as discussed previously), I notice that the reference to XML= -Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wi= ll likely require us to reference the current spec, so I should probably upd= ate the reference. >>=20 >> Looking at the binary attribute representation, I am wondering if we shou= ld change this to the current IETF specification which is: RFC4648 rather th= an reference XML-Schema 3.2.16 (of the 2004 schema spec). >>=20 >> Do we want to further clarify that the encoding be: base64url? Not a ja= vascript expert, but wondering if we need to use url safe encoding? This may= result in a normative clarification for some. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer --Apple-Mail-1551877B-D1D0-478C-A76F-AC4B47EEA4FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think it should be one form. 

My recommendation would be base64url for max utility= . Especially if we start defining schema related to JWT keys (JWK) from OAut= h and JOSE. 

Phil

On Mar 2, 2015, at 12:06,= Ian Glazer <iglazer@salesforce= .com> wrote:

Would this be base64url "required" or "recommended"?

Would the encoding type be a declared attribute of the SP?

On Mon, Mar 2, 2015 at 2= :07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I w= as looking through the schema document and cleaning up the data type charact= eristics (as discussed previously), I notice that the reference to XML-Schem= a is to the October 2004 one and not the 2012 XML Schema.  The IETF wil= l likely require us to reference the current spec, so I should probably upda= te the reference.

Looking at the binary attribute represe= ntation, I am wondering if we should change this to the current IETF specifi= cation which is: RFC4648 rather than reference XML-Schema 3.2.16 (of the 200= 4 schema spec).

Do we want to further clarify that t= he encoding be: base64url?   Not a javascript expert, but wondering if w= e need to use url safe encoding? This may result in a normative clarificatio= n for some.


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




--
Ian Glazer
Senior D= irector, Identity
+1 202 255 3166
= --Apple-Mail-1551877B-D1D0-478C-A76F-AC4B47EEA4FD-- From nobody Mon Mar 2 15:50:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEDF1A8AD4 for ; Mon, 2 Mar 2015 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dUZaXzufz8jt for ; Mon, 2 Mar 2015 15:50:21 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F8D1A8ACC for ; Mon, 2 Mar 2015 15:50:21 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t22NoJqw003666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Mar 2015 23:50:20 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t22NoJ9T008568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2015 23:50:19 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t22NoJli020177; Mon, 2 Mar 2015 23:50:19 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Mar 2015 15:50:13 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_F411F05A-FD91-4FEA-8EAA-5BC3F7071E43" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: Date: Mon, 2 Mar 2015 15:50:12 -0800 Message-Id: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> References: To: Ian Glazer X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 23:50:25 -0000 --Apple-Mail=_F411F05A-FD91-4FEA-8EAA-5BC3F7071E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, Michael has reminded me that x509Certificate is DER encoded binary which = is in conflict with our current binary definition. I recommend changing the definition of Binary FROM: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded as a base 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is case-exact and has no uniqueness. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String per Section 2.7 [RFC7159]. TO: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded in Base 64 encoding as specified in Section 4 [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. In JSON representation, the encoded values are represented as a JSON String per Section 7 [RFC7159]. A binary is case-exact and has no uniqueness. Further, I would recommend changing x509certificates FROM: x509Certificates A list of certificates issued to the User. Values are Binary (Section 2.2.6) and DER encoded x509. This value has NO canonical types. TO: x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are Base 64 encoded x509 per Section 4 [RFC4648]. Important: This is a normative change as we are correcting the previous = =E2=80=9CDER=E2=80=9D encoding to be base 64 encoding for consistency = with the definition of binary and JSON compatibility. If possible, please have comments to the list by 5PM Pacific tomorrow = (Tuesday). I would like to publish draft 17 of core-schema in order to = be able to publish the changes to the API draft later in the week. Note = that the proposed changes for tomorrow include expanding section 8.7 to = include schemas for fixed (non-resource) service provider schemas: = ServiceProviderConfig, ResourceType, Schema. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 2, 2015, at 12:25 PM, Phil Hunt wrote: >=20 > I think it should be one form.=20 >=20 > My recommendation would be base64url for max utility. Especially if we = start defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >=20 > Phil >=20 > On Mar 2, 2015, at 12:06, Ian Glazer > wrote: >=20 >> Would this be base64url "required" or "recommended"? >>=20 >> Would the encoding type be a declared attribute of the SP? >>=20 >> On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt > wrote: >>=20 >> I was looking through the schema document and cleaning up the data = type characteristics (as discussed previously), I notice that the = reference to XML-Schema is to the October 2004 one and not the 2012 XML = Schema. The IETF will likely require us to reference the current spec, = so I should probably update the reference. >>=20 >> Looking at the binary attribute representation, I am wondering if we = should change this to the current IETF specification which is: RFC4648 = rather than reference XML-Schema 3.2.16 (of the 2004 schema spec). >>=20 >> Do we want to further clarify that the encoding be: base64url? Not = a javascript expert, but wondering if we need to use url safe encoding? = This may result in a normative clarification for some. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim = >>=20 >>=20 >>=20 >>=20 >> --=20 >> Ian Glazer >> Senior Director, Identity >> +1 202 255 3166 >> @iglazer = _____________________________________________= __ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_F411F05A-FD91-4FEA-8EAA-5BC3F7071E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

Michael has reminded me that x509Certificate is DER encoded = binary which is in conflict with our current binary = definition.

I = recommend changing the definition of Binary FROM:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded as a base
   64 encoding as specified in Section 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniqueness.

   Values represented in JSON MUST conform to the XML constraints above
   and are represented as a JSON String per Section 2.7 [RFC7159].
TO:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded in Base
   64 encoding as specified in Section 4 [RFC4648].  In cases where a
   URL-safe encoding is required, the attribute definition MAY specify
   Base 64 URL encoding MAY be used as per Section 5 [RFC4648].

   In JSON representation, the encoded values are =
represented as a JSON
   String per Section 7 [RFC7159].  A binary is case-exact and has no
   uniqueness.
Further, I would recommend = changing x509certificates FROM:
   =
x509Certificates
      A list of certificates issued to the User.  Values are Binary
      (Section 2.2.6) and DER encoded x509.  This value has NO canonical
      types.
TO:
   =
x509Certificates
      A list of certificates issued to the User.  =
Values are binary
      (Section 2.2.6) and are Base 64 encoded x509 per =
Section 4
      [RFC4648].

Important:  This is a normative change as we are = correcting the previous =E2=80=9CDER=E2=80=9D encoding to be base 64 = encoding for consistency with the definition of binary and JSON = compatibility.

If possible, please have comments = to the list by 5PM Pacific tomorrow (Tuesday).  I would = like to publish draft 17 of core-schema in order to be able to publish = the changes to the API draft later in the week.  Note that the = proposed changes for tomorrow include expanding section 8.7 to include = schemas for fixed (non-resource) service provider schemas: =  ServiceProviderConfig, ResourceType, Schema.

Cheers,


On Mar 2, 2015, at 12:25 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I think it = should be one form. 

My recommendation would be base64url for max utility. = Especially if we start defining schema related to JWT keys (JWK) from = OAuth and JOSE. 

Phil

On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or = "recommended"?

Would = the encoding type be a declared attribute of the SP?

On Mon, = Mar 2, 2015 at 2:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I was looking through the schema document and cleaning = up the data type characteristics (as discussed previously), I notice = that the reference to XML-Schema is to the October 2004 one and not the = 2012 XML Schema.  The IETF will likely require us to reference the = current spec, so I should probably update the reference.

Looking at the binary = attribute representation, I am wondering if we should change this to the = current IETF specification which is: RFC4648 rather than reference = XML-Schema 3.2.16 (of the 2004 schema spec).

Do we want to further clarify that the = encoding be: base64url?   Not a javascript expert, but wondering if = we need to use url safe encoding? This may result in a normative = clarification for some.



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




--
Ian = Glazer
Senior Director, = Identity
+1 202 255 3166
@iglazer
=
_______________________________________________scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

= --Apple-Mail=_F411F05A-FD91-4FEA-8EAA-5BC3F7071E43-- From nobody Mon Mar 2 18:50:07 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF581A0130 for ; Mon, 2 Mar 2015 18:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 teCRz5_-6LDj for ; Mon, 2 Mar 2015 18:50:02 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04431A0122 for ; Mon, 2 Mar 2015 18:50:02 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t232nwwj000353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 02:49:59 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t232nwIU012757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 02:49:58 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t232nvhx020528; Tue, 3 Mar 2015 02:49:57 GMT MIME-Version: 1.0 Message-ID: <95305152-5386-432e-8095-0d4c7a1d319b@default> Date: Mon, 2 Mar 2015 18:49:51 -0800 (PST) From: Michael Frost Sender: Michael Frost To: Phil Hunt , SCIM WG References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> In-Reply-To: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: multipart/alternative; boundary="__142535099212662618abhmp0003.oracle.com" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 02:50:06 -0000 --__142535099212662618abhmp0003.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would have preferred msgType just because it still feels like we are sort= of =E2=80=9Coverloading=E2=80=9D the Schemas attribute based on context (m= essage vs. resource).=C2=A0 So I guess I=E2=80=99m a little at odds with th= e contention that we are using =E2=80=9CSchemas=E2=80=9D consistently.=C2= =A0 However the proposed text changes are quite clear on the use of Schemas= attributes in each context and certainly addresses my earlier concerns. =C2=A0 Just as an aside, is it worth considering placing message type in all messa= ges and only placing schemas in resource objects?=C2=A0 Do we ever anticipa= te the need to carry some data in the payload of PUT/POST that is not part = of the resource and not conveniently encoded into query parameters?=C2=A0 I= t would place a consistent envelope around all requests/responses, but is p= erhaps a bit unRESTful. =C2=A0 Anyway, I noticed one minor type-o with paragraph 4 in section 3.1,=C2=A0 o= pening sentence starts with =E2=80=9CAs SCIM in intended for use=E2=80=9D s= hould probably be =E2=80=9CAs SCIM is intended for use=E2=80=9D. =C2=A0 -mrf =C2=A0 From: Phil Hunt=20 Sent: Friday, February 27, 2015 10:18 AM To: SCIM WG Cc: Erik Wahlstr=C3=B6m neXus; Michael Frost Subject: [scim] Proposed text for schema resources vs. messages =C2=A0 IMPORTANT: =C2=A0We need to get this information published next week if we = are to make the Dallas meeting deadline. Please respond by Tuesday Mar 3, 8= AM Pacific. Based on feedback I will publish a minor revision to schemas do= c Tuesday afternoon, and on Thursday revisions to API. =C2=A0 In a previous thread (https://www.ietf.org/mail-archive/web/scim/current/ms= g02128.html), Erik proposed we use different attributes to distinguish betw= een SCIM messages and resources (msgType and schemas). =C2=A0 I have taken a look at the impact on the documents and I think the solution= may be perceived as somewhat more complex than consistently using =E2=80= =9Cschemas=E2=80=9D. =C2=A0The main reason is that someone opening a JSON o= bject now has to look for two different attributes to tell if the object is= a SCIM object of any type. I am not sure this matters in practice, but it = does =E2=80=9Cfeel=E2=80=9D complex from a media type perspective. =C2=A0 >From an editorial and IANA perspective, I believe using =E2=80=9CmsgType=E2= =80=9D means that we have to build a separate IANA registry for messages di= stinct from schemas. Given that the review process is essentially the same,= I=E2=80=99m not sure there is a lot of benefit. I wonder then if clarifyin= g text might not work as well. =C2=A0 What I have done is written a new introduction to section 3 of the API spec= ification. My hope is that this sets the stage for how SCIM protocol works = and clearly establishes the differences between SCIM resources and messages= . =C2=A0 Action Item: =C2=A0PLEASE INDICATE (by next Tuesday morning if possible): =C2=A0 A. =C2=A0Given the text below, does anyone strongly prefer using =E2=80=9Cm= sgType=E2=80=9D instead (and creating a new registry for it)? =C2=A0 B. =C2=A0Comments on the text. =C2=A0 Thanks! =C2=A0 PROPOSED TEXT: 3.=C2=A0 SCIM Protocol =C2=A0 3.1.=C2=A0 Introduction =C2=A0 =C2=A0=C2=A0 SCIM is a protocol based on HTTP [RFC7230].=C2=A0 Along with H= TTP headers =C2=A0=C2=A0 and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCI= M =C2=A0=C2=A0 resources as well as request parameters and response informati= on such =C2=A0=C2=A0 as errors in the form of JSON based messages.=C2=A0 To identif= y this =C2=A0=C2=A0 content, SCIM uses a media type of "application/scim+json" (se= e =C2=A0=C2=A0 Section 8.1). =C2=A0 =C2=A0=C2=A0 A SCIM resource is a JSON object that may be created, maintain= ed, and =C2=A0=C2=A0 retrieved through HTTP methods as described in this document.= =C2=A0 Each =C2=A0=C2=A0 JSON resource representation contains a "schemas" attribute th= at =C2=A0=C2=A0 contains a list of one or more URIs that indicate included SCI= M =C2=A0=C2=A0 schemas that may be used to indicate the attributes contained = within =C2=A0=C2=A0 a resource.=C2=A0 When querying a SCIM service provider's "/Sc= hemas" =C2=A0=C2=A0 endpoint for schema definition (see Section 8.7 =C2=A0=C2=A0 [I-D.ietf-scim-core-schema]), the response describes how a ser= vice =C2=A0=C2=A0 provider supports an attribute including schema meta-attribute= s such =C2=A0=C2=A0 as case-exactness, mutability, uniqueness, returnability, and = whether =C2=A0=C2=A0 it is required.=C2=A0 While SCIM schemas and associated extens= ion model is =C2=A0=C2=A0 defined in [I-D.ietf-scim-core-schema], SCIM clients should ex= pect =C2=A0=C2=A0 that some attribute schema MAY change from deployment to deplo= yment. =C2=A0=C2=A0 In cases where SCIM may be used as an open protocol in front o= f an =C2=A0=C2=A0 application service, it is quite reasonable to expect that som= e =C2=A0=C2=A0 service providers MAY only support a sub-set of the schema def= ined in =C2=A0=C2=A0 [I-D.ietf-scim-core-schema]. =C2=A0 =C2=A0=C2=A0 A SCIM message is a JSON object that conveys protocol paramete= rs =C2=A0=C2=A0 about a SCIM request or response that are defined by this =C2=A0=C2=A0 specification.=C2=A0 As with a SCIM resource, a SCIM message i= s a JSON =C2=A0=C2=A0 object that contains a "schemas" attribute with a URI whose na= mespace =C2=A0=C2=A0 prefix begins with "urn:ietf:params:scim:api:".=C2=A0 As SCIM = protocol =C2=A0=C2=A0 messages are fixed and defined by SCIM specifications and regi= stered =C2=A0=C2=A0 extensions, SCIM message schemas using the above prefix URN SH= ALL NOT =C2=A0=C2=A0 be discoverable using the "/Schemas" endpoint. =C2=A0 =C2=A0=C2=A0 As SCIM in intended for use within cross-domain environments w= here =C2=A0=C2=A0 schemas MAY vary, techniques such as document validation, such= as in =C2=A0=C2=A0 [XML-Schema], are not recommended.=C2=A0 A SCIM service provid= er =C2=A0=C2=A0 interprets a request in the context of its own schema (which m= ay be =C2=A0=C2=A0 different from the client's schema) and the processing rules =C2=A0=C2=A0 described for each SCIM request.=C2=A0 The following sections = in this =C2=A0=C2=A0 document define processing rules for SCIM that provide allowan= ces for =C2=A0=C2=A0 differences where appropriate.=C2=A0 For example, in a SCIM PU= T request, =C2=A0=C2=A0 "readOnly" attributes are ignored, while "readWrite" attribute= s are =C2=A0=C2=A0 updated.=C2=A0 There is no need for the client to discover whi= ch =C2=A0=C2=A0 attributes are "readOnly" and remove them from the PUT request= in =C2=A0=C2=A0 advance in order to be accepted.=C2=A0 Similarly a SCIM client= SHOULD NOT =C2=A0=C2=A0 expect a service provider to return SCIM resources with exactl= y the =C2=A0=C2=A0 same schema and values as submitted.=C2=A0 SCIM responses SHAL= L reflect =C2=A0=C2=A0 resource state as interpreted by the SCIM service provider. =C2=A0 3.2.=C2=A0 SCIM Endpoints =C2=A0 =C2=A0=C2=A0 The SCIM protocol specifies well-known endpoints and HTTP meth= ods for =C2=A0=C2=A0 managing resources defined in the core schema; i.e., "User" an= d =C2=A0 Phil =C2=A0 @independentid HYPERLINK "http://www.independentid.com"www.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com"phil.hunt@oracle.com =C2=A0 --__142535099212662618abhmp0003.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I would h= ave preferred msgType just because it still feels like we are sort of =E2= =80=9Coverloading=E2=80=9D the Schemas attribute based on context (message = vs. resource).=C2=A0 So I guess I=E2=80=99m a little at odds with the conte= ntion that we are using =E2=80=9CSchemas=E2=80=9D consistently.=C2=A0 Howev= er the proposed text changes are quite clear on the use of Schemas attribut= es in each context and certainly addresses my earlier concerns.<= /span>

 

Just as an aside, is it worth considering placing messa= ge type in all messages and only placing schemas in resource objects?=C2=A0= Do we ever anticipate the need to carry some data in the payload of PUT/PO= ST that is not part of the resource and not conveniently encoded into query= parameters?=C2=A0 It would place a consistent envelope around all requests= /responses, but is perhaps a bit unRESTful.

 

Anyway, I noticed one minor type-o with paragraph 4 in section 3.1,=C2=A0 = opening sentence starts with =E2=80=9CAs SCIM in intended for use=E2=80=9D = should probably be =E2=80=9CAs SCIM is intended for use=E2=80=9D.

 

-mrf

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Phil Hun= t
Sent: Friday, February 27, 2015 10:18 AM
To: SCIM WG=
Cc: Erik Wahlstr=C3=B6m neXus; Michael Frost
Subject: = [scim] Proposed text for schema resources vs. messages

 

IMPORTANT:  We need to get this information published next week = if we are to make the Dallas meeting deadline. Please respond by Tuesday= Mar 3, 8AM Pacific. Based on feedback I will publish a minor revision = to schemas doc Tuesday afternoon, and on Thursday revisions to API.

 

In a previous thread (https://www.ietf.org/mail-archive/web/= scim/current/msg02128.html), Erik proposed we use different attributes = to distinguish between SCIM messages and resources (msgType and schemas).

 

I have taken a look at the impact on the documents and I t= hink the solution may be perceived as somewhat more complex than consistent= ly using =E2=80=9Cschemas=E2=80=9D.  The main reason is that someone o= pening a JSON object now has to look for two different attributes to tell i= f the object is a SCIM object of any type. I am not sure this matters in pr= actice, but it does =E2=80=9Cfeel=E2=80=9D complex from a media type perspe= ctive.

 

<= /div>

From an editorial and IANA perspective, I be= lieve using =E2=80=9CmsgType=E2=80=9D means that we have to build a separat= e IANA registry for messages distinct from schemas. Given that the review p= rocess is essentially the same, I=E2=80=99m not sure there is a lot of bene= fit. I wonder then if clarifying text might not work as well.

 

What I have done is written a new introduction to section 3 of= the API specification. My hope is that this sets the stage for how SCIM pr= otocol works and clearly establishes the differences between SCIM resources= and messages.

 

Action Item:  PLEASE INDICAT= E (by next Tuesday morning if possible):

 

A. &nb= sp;Given the text below, does anyone strongly prefer using =E2=80=9CmsgType= =E2=80=9D instead (and creating a new registry for it)?

 

B.  Comments on the text.

 

Thanks!

 

PROPOSED TEXT:

3.=C2=A0 SCIM Protocol
 
3.1.=C2=A0 Introduction
 
=C2=A0=C2=A0 SCIM is a protocol based on=
 HTTP [RFC7230].=C2=A0 Along with HTTP headers
=C2=A0=
=C2=A0 and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM=

=C2=A0=C2=A0 resources as well as request parameters and r=
esponse information such
=C2=A0=C2=A0 as errors in the=
 form of JSON based messages.=C2=A0 To identify this
=
=C2=A0=C2=A0 content, SCIM uses a media type of "application/scim+json=
" (see
=C2=A0=C2=A0 Section 8.1).
 
=C2=A0=C2=A0 A SCIM resource is a JSON ob=
ject that may be created, maintained, and
=C2=A0=C2=A0=
 retrieved through HTTP methods as described in this document.=C2=A0 Each
=C2=A0=C2=A0 JSON resource representation contains a &q=
uot;schemas" attribute that
=C2=A0=C2=A0 contains=
 a list of one or more URIs that indicate included SCIM
=C2=A0=C2=A0 schemas that may be used to indicate the attributes containe=
d within
=C2=A0=C2=A0 a resource.=C2=A0 When querying =
a SCIM service provider's "/Schemas"
=C2=A0=
=C2=A0 endpoint for schema definition (see Section 8.7
=C2=A0=C2=A0 [I-D.ietf-scim-core-schema]), the response describes how a se=
rvice
=C2=A0=C2=A0 provider supports an attribute incl=
uding schema meta-attributes such
=C2=A0=C2=A0 as case=
-exactness, mutability, uniqueness, returnability, and whether
=C2=A0=C2=A0 it is required.=C2=A0 While SCIM schemas and associat=
ed extension model is
=C2=A0=C2=A0 defined in [I-D.iet=
f-scim-core-schema], SCIM clients should expect
=C2=A0=
=C2=A0 that some attribute schema MAY change from deployment to deployment.=

=C2=A0=C2=A0 In cases where SCIM may be used as an op=
en protocol in front of an
=C2=A0=C2=A0 application se=
rvice, it is quite reasonable to expect that some
=C2=
=A0=C2=A0 service providers MAY only support a sub-set of the schema define=
d in
=C2=A0=C2=A0 [I-D.ietf-scim-core-schema].
 
=C2=A0=C2=A0 A SCIM message is a =
JSON object that conveys protocol parameters
=C2=A0=C2=
=A0 about a SCIM request or response that are defined by this
=C2=A0=C2=A0 specification.=C2=A0 As with a SCIM resource, a SCIM m=
essage is a JSON
=C2=A0=C2=A0 object that contains a &=
quot;schemas" attribute with a URI whose namespace
=C2=A0=C2=A0 prefix begins with "urn:ietf:params:scim:api:".=C2=
=A0 As SCIM protocol
=C2=A0=C2=A0 messages are fixed a=
nd defined by SCIM specifications and registered
=C2=
=A0=C2=A0 extensions, SCIM message schemas using the above prefix URN SHALL=
 NOT
=C2=A0=C2=A0 be discoverable using the "/Sch=
emas" endpoint.
 
=C2=
=A0=C2=A0 As SCIM in intended for use within cross-domain environments wher=
e
=C2=A0=C2=A0 schemas MAY vary, techniques such as do=
cument validation, such as in
=C2=A0=C2=A0 [XML-Schema=
], are not recommended.=C2=A0 A SCIM service provider
=
=C2=A0=C2=A0 interprets a request in the context of its own schema (which m=
ay be
=C2=A0=C2=A0 different from the client's schema)=
 and the processing rules
=C2=A0=C2=A0 described for e=
ach SCIM request.=C2=A0 The following sections in this
=C2=A0=C2=A0 document define processing rules for SCIM that provide allowa=
nces for
=C2=A0=C2=A0 differences where appropriate.=
=C2=A0 For example, in a SCIM PUT request,
=C2=A0=C2=
=A0 "readOnly" attributes are ignored, while "readWrite"=
; attributes are
=C2=A0=C2=A0 updated.=C2=A0 There is =
no need for the client to discover which
=C2=A0=C2=A0 =
attributes are "readOnly" and remove them from the PUT request in=

=C2=A0=C2=A0 advance in order to be accepted.=C2=A0 S=
imilarly a SCIM client SHOULD NOT
=C2=A0=C2=A0 expect =
a service provider to return SCIM resources with exactly the
=C2=A0=C2=A0 same schema and values as submitted.=C2=A0 SCIM respons=
es SHALL reflect
=C2=A0=C2=A0 resource state as interp=
reted by the SCIM service provider.
 <=
/pre>
3.2.=C2=A0 SCIM Endpoints
 <=
/pre>
=C2=A0=C2=A0 The SCIM protocol specifies well-known endpoints and=
 HTTP methods for
=C2=A0=C2=A0 managing resources defi=
ned in the core schema; i.e., "User" and
 

Phil

=

 

@independentid

www.in= dependentid.com

<= span style=3D'font-family:"Helvetica","sans-serif";color:black'>phil.hunt@oracle.com

=

=  

--__142535099212662618abhmp0003.oracle.com-- From nobody Mon Mar 2 20:51:25 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998161A1A03 for ; Mon, 2 Mar 2015 20:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 s6FoKx7gS0zY for ; Mon, 2 Mar 2015 20:51:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4651A1A02 for ; Mon, 2 Mar 2015 20:51:20 -0800 (PST) Received: from BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) by BN1PR04MB073.namprd04.prod.outlook.com (10.255.199.144) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 04:51:00 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 04:50:59 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) with mapi id 15.01.0099.004; Tue, 3 Mar 2015 04:50:59 +0000 From: Kelly Grizzle To: Ian Glazer , =?utf-8?B?RXJpayBXYWhsc3Ryw7ZtIG5lWHVz?= Thread-Topic: [scim] Proposed text for schema resources vs. messages Thread-Index: AQHQUrnIdZz3DYMoxUuOSaTS6tsQEZ0JO3uAgAAeN4CAANwJwA== Date: Tue, 3 Mar 2015 04:50:58 +0000 Message-ID: References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0200A2CE0094AC0200A41B x-originating-ip: [70.114.158.171] authentication-results: salesforce.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB073; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(41574002)(2950100001)(2656002)(15975445007)(62966003)(19625215002)(74316001)(76176999)(54356999)(66066001)(86362001)(87936001)(33656002)(2420400003)(102836002)(76576001)(2900100001)(106116001)(16236675004)(19580395003)(46102003)(19609705001)(19580405001)(19300405004)(92566002)(122556002)(77156002)(19617315012)(50986999)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB392DAE4EC6599D5E3FDFDB7E2110BN1PR04MB392namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 04:50:58.9641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 X-OriginatorOrg: sailpoint.com Archived-At: Cc: SCIM WG , Michael Frost , Phil Hunt Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 04:51:23 -0000 --_000_BN1PR04MB392DAE4EC6599D5E3FDFDB7E2110BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gc3RpY2tpbmcgd2l0aCBzY2hlbWFzIGZvciBtZXNzYWdlcy4NCg0KRnJvbTogc2NpbSBb bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBHbGF6ZXINClNl bnQ6IE1vbmRheSwgTWFyY2ggMDIsIDIwMTUgOTo0MyBBTQ0KVG86IEVyaWsgV2FobHN0csO2bSBu ZVh1cw0KQ2M6IFNDSU0gV0c7IE1pY2hhZWwgRnJvc3Q7IFBoaWwgSHVudA0KU3ViamVjdDogUmU6 IFtzY2ltXSBQcm9wb3NlZCB0ZXh0IGZvciBzY2hlbWEgcmVzb3VyY2VzIHZzLiBtZXNzYWdlcw0K DQpJJ20gd2l0aCBFcmlrIG9uIHRoaXMNCg0KT24gTW9uLCBNYXIgMiwgMjAxNSBhdCA4OjU0IEFN LCBFcmlrIFdhaGxzdHLDtm0gbmVYdXMgPGVyaWsud2FobHN0cm9tQG5leHVzZ3JvdXAuY29tPG1h aWx0bzplcmlrLndhaGxzdHJvbUBuZXh1c2dyb3VwLmNvbT4+IHdyb3RlOg0KS2VlcGluZyBzY2hl bWFzIGluc3RlYWQgb2YgbXNnVHlwZSB3b3JrcyBmb3IgbWUsIGFzIGxvbmcgYXMgd2UgY2xhcmlm eSBpdCBpbiB0aGUgdGV4dCBhcyB5b3UgaGF2ZSBkb25lIHRoZXJlLg0KLyBFcmlrDQoNCk9uIDI3 IEZlYiAyMDE1LCBhdCAxOToxNywgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWls dG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSU1QT1JUQU5UOiAgV2UgbmVlZCB0 byBnZXQgdGhpcyBpbmZvcm1hdGlvbiBwdWJsaXNoZWQgbmV4dCB3ZWVrIGlmIHdlIGFyZSB0byBt YWtlIHRoZSBEYWxsYXMgbWVldGluZyBkZWFkbGluZS4gUGxlYXNlIHJlc3BvbmQgYnkgVHVlc2Rh eSBNYXIgMywgOEFNIFBhY2lmaWMuIEJhc2VkIG9uIGZlZWRiYWNrIEkgd2lsbCBwdWJsaXNoIGEg bWlub3IgcmV2aXNpb24gdG8gc2NoZW1hcyBkb2MgVHVlc2RheSBhZnRlcm5vb24sIGFuZCBvbiBU aHVyc2RheSByZXZpc2lvbnMgdG8gQVBJLg0KDQpJbiBhIHByZXZpb3VzIHRocmVhZCAoaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQvbXNnMDIxMjguaHRt bCksIEVyaWsgcHJvcG9zZWQgd2UgdXNlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIHRvIGRpc3Rpbmd1 aXNoIGJldHdlZW4gU0NJTSBtZXNzYWdlcyBhbmQgcmVzb3VyY2VzIChtc2dUeXBlIGFuZCBzY2hl bWFzKS4NCg0KSSBoYXZlIHRha2VuIGEgbG9vayBhdCB0aGUgaW1wYWN0IG9uIHRoZSBkb2N1bWVu dHMgYW5kIEkgdGhpbmsgdGhlIHNvbHV0aW9uIG1heSBiZSBwZXJjZWl2ZWQgYXMgc29tZXdoYXQg bW9yZSBjb21wbGV4IHRoYW4gY29uc2lzdGVudGx5IHVzaW5nIOKAnHNjaGVtYXPigJ0uICBUaGUg bWFpbiByZWFzb24gaXMgdGhhdCBzb21lb25lIG9wZW5pbmcgYSBKU09OIG9iamVjdCBub3cgaGFz IHRvIGxvb2sgZm9yIHR3byBkaWZmZXJlbnQgYXR0cmlidXRlcyB0byB0ZWxsIGlmIHRoZSBvYmpl Y3QgaXMgYSBTQ0lNIG9iamVjdCBvZiBhbnkgdHlwZS4gSSBhbSBub3Qgc3VyZSB0aGlzIG1hdHRl cnMgaW4gcHJhY3RpY2UsIGJ1dCBpdCBkb2VzIOKAnGZlZWzigJ0gY29tcGxleCBmcm9tIGEgbWVk aWEgdHlwZSBwZXJzcGVjdGl2ZS4NCg0KRnJvbSBhbiBlZGl0b3JpYWwgYW5kIElBTkEgcGVyc3Bl Y3RpdmUsIEkgYmVsaWV2ZSB1c2luZyDigJxtc2dUeXBl4oCdIG1lYW5zIHRoYXQgd2UgaGF2ZSB0 byBidWlsZCBhIHNlcGFyYXRlIElBTkEgcmVnaXN0cnkgZm9yIG1lc3NhZ2VzIGRpc3RpbmN0IGZy b20gc2NoZW1hcy4gR2l2ZW4gdGhhdCB0aGUgcmV2aWV3IHByb2Nlc3MgaXMgZXNzZW50aWFsbHkg dGhlIHNhbWUsIEnigJltIG5vdCBzdXJlIHRoZXJlIGlzIGEgbG90IG9mIGJlbmVmaXQuIEkgd29u ZGVyIHRoZW4gaWYgY2xhcmlmeWluZyB0ZXh0IG1pZ2h0IG5vdCB3b3JrIGFzIHdlbGwuDQoNCldo YXQgSSBoYXZlIGRvbmUgaXMgd3JpdHRlbiBhIG5ldyBpbnRyb2R1Y3Rpb24gdG8gc2VjdGlvbiAz IG9mIHRoZSBBUEkgc3BlY2lmaWNhdGlvbi4gTXkgaG9wZSBpcyB0aGF0IHRoaXMgc2V0cyB0aGUg c3RhZ2UgZm9yIGhvdyBTQ0lNIHByb3RvY29sIHdvcmtzIGFuZCBjbGVhcmx5IGVzdGFibGlzaGVz IHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFNDSU0gcmVzb3VyY2VzIGFuZCBtZXNzYWdlcy4NCg0K QWN0aW9uIEl0ZW06ICBQTEVBU0UgSU5ESUNBVEUgKGJ5IG5leHQgVHVlc2RheSBtb3JuaW5nIGlm IHBvc3NpYmxlKToNCg0KQS4gIEdpdmVuIHRoZSB0ZXh0IGJlbG93LCBkb2VzIGFueW9uZSBzdHJv bmdseSBwcmVmZXIgdXNpbmcg4oCcbXNnVHlwZeKAnSBpbnN0ZWFkIChhbmQgY3JlYXRpbmcgYSBu ZXcgcmVnaXN0cnkgZm9yIGl0KT8NCg0KQi4gIENvbW1lbnRzIG9uIHRoZSB0ZXh0Lg0KDQpUaGFu a3MhDQoNClBST1BPU0VEIFRFWFQ6DQoNCjMuICBTQ0lNIFByb3RvY29sDQoNCg0KDQozLjEuICBJ bnRyb2R1Y3Rpb24NCg0KDQoNCiAgIFNDSU0gaXMgYSBwcm90b2NvbCBiYXNlZCBvbiBIVFRQIFtS RkM3MjMwXS4gIEFsb25nIHdpdGggSFRUUCBoZWFkZXJzDQoNCiAgIGFuZCBVUklzLCBTQ0lNIHVz ZXMgSlNPTiBbUkZDNzE1OV0gcGF5bG9hZHMgdG8gY29udmV5IGJvdGggU0NJTQ0KDQogICByZXNv dXJjZXMgYXMgd2VsbCBhcyByZXF1ZXN0IHBhcmFtZXRlcnMgYW5kIHJlc3BvbnNlIGluZm9ybWF0 aW9uIHN1Y2gNCg0KICAgYXMgZXJyb3JzIGluIHRoZSBmb3JtIG9mIEpTT04gYmFzZWQgbWVzc2Fn ZXMuICBUbyBpZGVudGlmeSB0aGlzDQoNCiAgIGNvbnRlbnQsIFNDSU0gdXNlcyBhIG1lZGlhIHR5 cGUgb2YgImFwcGxpY2F0aW9uL3NjaW0ranNvbiIgKHNlZQ0KDQogICBTZWN0aW9uIDguMSkuDQoN Cg0KDQogICBBIFNDSU0gcmVzb3VyY2UgaXMgYSBKU09OIG9iamVjdCB0aGF0IG1heSBiZSBjcmVh dGVkLCBtYWludGFpbmVkLCBhbmQNCg0KICAgcmV0cmlldmVkIHRocm91Z2ggSFRUUCBtZXRob2Rz IGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LiAgRWFjaA0KDQogICBKU09OIHJlc291cmNl IHJlcHJlc2VudGF0aW9uIGNvbnRhaW5zIGEgInNjaGVtYXMiIGF0dHJpYnV0ZSB0aGF0DQoNCiAg IGNvbnRhaW5zIGEgbGlzdCBvZiBvbmUgb3IgbW9yZSBVUklzIHRoYXQgaW5kaWNhdGUgaW5jbHVk ZWQgU0NJTQ0KDQogICBzY2hlbWFzIHRoYXQgbWF5IGJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlIGF0 dHJpYnV0ZXMgY29udGFpbmVkIHdpdGhpbg0KDQogICBhIHJlc291cmNlLiAgV2hlbiBxdWVyeWlu ZyBhIFNDSU0gc2VydmljZSBwcm92aWRlcidzICIvU2NoZW1hcyINCg0KICAgZW5kcG9pbnQgZm9y IHNjaGVtYSBkZWZpbml0aW9uIChzZWUgU2VjdGlvbiA4LjcNCg0KICAgW0ktRC5pZXRmLXNjaW0t Y29yZS1zY2hlbWFdKSwgdGhlIHJlc3BvbnNlIGRlc2NyaWJlcyBob3cgYSBzZXJ2aWNlDQoNCiAg IHByb3ZpZGVyIHN1cHBvcnRzIGFuIGF0dHJpYnV0ZSBpbmNsdWRpbmcgc2NoZW1hIG1ldGEtYXR0 cmlidXRlcyBzdWNoDQoNCiAgIGFzIGNhc2UtZXhhY3RuZXNzLCBtdXRhYmlsaXR5LCB1bmlxdWVu ZXNzLCByZXR1cm5hYmlsaXR5LCBhbmQgd2hldGhlcg0KDQogICBpdCBpcyByZXF1aXJlZC4gIFdo aWxlIFNDSU0gc2NoZW1hcyBhbmQgYXNzb2NpYXRlZCBleHRlbnNpb24gbW9kZWwgaXMNCg0KICAg ZGVmaW5lZCBpbiBbSS1ELmlldGYtc2NpbS1jb3JlLXNjaGVtYV0sIFNDSU0gY2xpZW50cyBzaG91 bGQgZXhwZWN0DQoNCiAgIHRoYXQgc29tZSBhdHRyaWJ1dGUgc2NoZW1hIE1BWSBjaGFuZ2UgZnJv bSBkZXBsb3ltZW50IHRvIGRlcGxveW1lbnQuDQoNCiAgIEluIGNhc2VzIHdoZXJlIFNDSU0gbWF5 IGJlIHVzZWQgYXMgYW4gb3BlbiBwcm90b2NvbCBpbiBmcm9udCBvZiBhbg0KDQogICBhcHBsaWNh dGlvbiBzZXJ2aWNlLCBpdCBpcyBxdWl0ZSByZWFzb25hYmxlIHRvIGV4cGVjdCB0aGF0IHNvbWUN Cg0KICAgc2VydmljZSBwcm92aWRlcnMgTUFZIG9ubHkgc3VwcG9ydCBhIHN1Yi1zZXQgb2YgdGhl IHNjaGVtYSBkZWZpbmVkIGluDQoNCiAgIFtJLUQuaWV0Zi1zY2ltLWNvcmUtc2NoZW1hXS4NCg0K DQoNCiAgIEEgU0NJTSBtZXNzYWdlIGlzIGEgSlNPTiBvYmplY3QgdGhhdCBjb252ZXlzIHByb3Rv Y29sIHBhcmFtZXRlcnMNCg0KICAgYWJvdXQgYSBTQ0lNIHJlcXVlc3Qgb3IgcmVzcG9uc2UgdGhh dCBhcmUgZGVmaW5lZCBieSB0aGlzDQoNCiAgIHNwZWNpZmljYXRpb24uICBBcyB3aXRoIGEgU0NJ TSByZXNvdXJjZSwgYSBTQ0lNIG1lc3NhZ2UgaXMgYSBKU09ODQoNCiAgIG9iamVjdCB0aGF0IGNv bnRhaW5zIGEgInNjaGVtYXMiIGF0dHJpYnV0ZSB3aXRoIGEgVVJJIHdob3NlIG5hbWVzcGFjZQ0K DQogICBwcmVmaXggYmVnaW5zIHdpdGggInVybjppZXRmOnBhcmFtczpzY2ltOmFwaToiLiAgQXMg U0NJTSBwcm90b2NvbA0KDQogICBtZXNzYWdlcyBhcmUgZml4ZWQgYW5kIGRlZmluZWQgYnkgU0NJ TSBzcGVjaWZpY2F0aW9ucyBhbmQgcmVnaXN0ZXJlZA0KDQogICBleHRlbnNpb25zLCBTQ0lNIG1l c3NhZ2Ugc2NoZW1hcyB1c2luZyB0aGUgYWJvdmUgcHJlZml4IFVSTiBTSEFMTCBOT1QNCg0KICAg YmUgZGlzY292ZXJhYmxlIHVzaW5nIHRoZSAiL1NjaGVtYXMiIGVuZHBvaW50Lg0KDQoNCg0KICAg QXMgU0NJTSBpbiBpbnRlbmRlZCBmb3IgdXNlIHdpdGhpbiBjcm9zcy1kb21haW4gZW52aXJvbm1l bnRzIHdoZXJlDQoNCiAgIHNjaGVtYXMgTUFZIHZhcnksIHRlY2huaXF1ZXMgc3VjaCBhcyBkb2N1 bWVudCB2YWxpZGF0aW9uLCBzdWNoIGFzIGluDQoNCiAgIFtYTUwtU2NoZW1hXSwgYXJlIG5vdCBy ZWNvbW1lbmRlZC4gIEEgU0NJTSBzZXJ2aWNlIHByb3ZpZGVyDQoNCiAgIGludGVycHJldHMgYSBy ZXF1ZXN0IGluIHRoZSBjb250ZXh0IG9mIGl0cyBvd24gc2NoZW1hICh3aGljaCBtYXkgYmUNCg0K ICAgZGlmZmVyZW50IGZyb20gdGhlIGNsaWVudCdzIHNjaGVtYSkgYW5kIHRoZSBwcm9jZXNzaW5n IHJ1bGVzDQoNCiAgIGRlc2NyaWJlZCBmb3IgZWFjaCBTQ0lNIHJlcXVlc3QuICBUaGUgZm9sbG93 aW5nIHNlY3Rpb25zIGluIHRoaXMNCg0KICAgZG9jdW1lbnQgZGVmaW5lIHByb2Nlc3NpbmcgcnVs ZXMgZm9yIFNDSU0gdGhhdCBwcm92aWRlIGFsbG93YW5jZXMgZm9yDQoNCiAgIGRpZmZlcmVuY2Vz IHdoZXJlIGFwcHJvcHJpYXRlLiAgRm9yIGV4YW1wbGUsIGluIGEgU0NJTSBQVVQgcmVxdWVzdCwN Cg0KICAgInJlYWRPbmx5IiBhdHRyaWJ1dGVzIGFyZSBpZ25vcmVkLCB3aGlsZSAicmVhZFdyaXRl IiBhdHRyaWJ1dGVzIGFyZQ0KDQogICB1cGRhdGVkLiAgVGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhl IGNsaWVudCB0byBkaXNjb3ZlciB3aGljaA0KDQogICBhdHRyaWJ1dGVzIGFyZSAicmVhZE9ubHki IGFuZCByZW1vdmUgdGhlbSBmcm9tIHRoZSBQVVQgcmVxdWVzdCBpbg0KDQogICBhZHZhbmNlIGlu IG9yZGVyIHRvIGJlIGFjY2VwdGVkLiAgU2ltaWxhcmx5IGEgU0NJTSBjbGllbnQgU0hPVUxEIE5P VA0KDQogICBleHBlY3QgYSBzZXJ2aWNlIHByb3ZpZGVyIHRvIHJldHVybiBTQ0lNIHJlc291cmNl cyB3aXRoIGV4YWN0bHkgdGhlDQoNCiAgIHNhbWUgc2NoZW1hIGFuZCB2YWx1ZXMgYXMgc3VibWl0 dGVkLiAgU0NJTSByZXNwb25zZXMgU0hBTEwgcmVmbGVjdA0KDQogICByZXNvdXJjZSBzdGF0ZSBh cyBpbnRlcnByZXRlZCBieSB0aGUgU0NJTSBzZXJ2aWNlIHByb3ZpZGVyLg0KDQoNCg0KMy4yLiAg U0NJTSBFbmRwb2ludHMNCg0KDQoNCiAgIFRoZSBTQ0lNIHByb3RvY29sIHNwZWNpZmllcyB3ZWxs LWtub3duIGVuZHBvaW50cyBhbmQgSFRUUCBtZXRob2RzIGZvcg0KDQogICBtYW5hZ2luZyByZXNv dXJjZXMgZGVmaW5lZCBpbiB0aGUgY29yZSBzY2hlbWE7IGkuZS4sICJVc2VyIiBhbmQNCg0KDQpQ aGlsDQoNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5p bmRlcGVuZGVudGlkLmNvbS8+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0K DQoNCi0tDQpJYW4gR2xhemVyDQpTZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5DQorMSAyMDIgMjU1 IDMxNjYNCkBpZ2xhemVyPGh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplcj4NCg== --_000_BN1PR04MB392DAE4EC6599D5E3FDFDB7E2110BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQz OzEgb24gc3RpY2tpbmcgd2l0aCBzY2hlbWFzIGZvciBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPklhbiBHbGF6ZXI8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBNYXJjaCAwMiwgMjAxNSA5OjQzIEFNPGJyPg0KPGI+VG86PC9iPiBFcmlrIFdhaGxz dHLDtm0gbmVYdXM8YnI+DQo8Yj5DYzo8L2I+IFNDSU0gV0c7IE1pY2hhZWwgRnJvc3Q7IFBoaWwg SHVudDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIFByb3Bvc2VkIHRleHQgZm9yIHNj aGVtYSByZXNvdXJjZXMgdnMuIG1lc3NhZ2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSdtIHdpdGggRXJpayBvbiB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyLCAyMDE1IGF0IDg6NTQgQU0sIEVyaWsg V2FobHN0csO2bSBuZVh1cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyaWsud2FobHN0cm9tQG5leHVz Z3JvdXAuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXJpay53YWhsc3Ryb21AbmV4dXNncm91cC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+S2VlcGluZyBzY2hlbWFzIGluc3RlYWQgb2YgbXNnVHlwZSB3b3JrcyBmb3IgbWUs IGFzIGxvbmcgYXMgd2UgY2xhcmlmeSBpdCBpbiB0aGUgdGV4dCBhcyB5b3UgaGF2ZSBkb25lIHRo ZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi8gRXJpazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNyBGZWIg MjAxNSwgYXQgMTk6MTcsIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JTVBPUlRBTlQ6ICZuYnNwO1dlIG5lZWQgdG8gZ2V0IHRoaXMgaW5mb3JtYXRpb24gcHVibGlz aGVkIG5leHQgd2VlayBpZiB3ZSBhcmUgdG8gbWFrZSB0aGUgRGFsbGFzIG1lZXRpbmcgZGVhZGxp bmUuPGI+IFBsZWFzZSByZXNwb25kIGJ5IFR1ZXNkYXkgTWFyIDMsIDhBTSBQYWNpZmljLg0KPC9i PkJhc2VkIG9uIGZlZWRiYWNrIEkgd2lsbCBwdWJsaXNoIGEgbWlub3IgcmV2aXNpb24gdG8gc2No ZW1hcyBkb2MgVHVlc2RheSBhZnRlcm5vb24sIGFuZCBvbiBUaHVyc2RheSByZXZpc2lvbnMgdG8g QVBJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGEg cHJldmlvdXMgdGhyZWFkICg8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NjaW0vY3VycmVudC9tc2cwMjEyOC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zY2ltL2N1cnJlbnQvbXNnMDIxMjguaHRt bDwvYT4pLCBFcmlrIHByb3Bvc2VkIHdlIHVzZSBkaWZmZXJlbnQgYXR0cmlidXRlcyB0byBkaXN0 aW5ndWlzaA0KIGJldHdlZW4gU0NJTSBtZXNzYWdlcyBhbmQgcmVzb3VyY2VzIChtc2dUeXBlIGFu ZCBzY2hlbWFzKS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGhhdmUgdGFrZW4gYSBsb29rIGF0IHRoZSBpbXBhY3Qgb24gdGhlIGRvY3VtZW50cyBhbmQg SSB0aGluayB0aGUgc29sdXRpb24gbWF5IGJlIHBlcmNlaXZlZCBhcyBzb21ld2hhdCBtb3JlIGNv bXBsZXggdGhhbiBjb25zaXN0ZW50bHkgdXNpbmcg4oCcc2NoZW1hc+KAnS4mbmJzcDsgVGhlIG1h aW4gcmVhc29uIGlzIHRoYXQgc29tZW9uZSBvcGVuaW5nIGEgSlNPTiBvYmplY3Qgbm93IGhhcyB0 byBsb29rIGZvciB0d28gZGlmZmVyZW50DQogYXR0cmlidXRlcyB0byB0ZWxsIGlmIHRoZSBvYmpl Y3QgaXMgYSBTQ0lNIG9iamVjdCBvZiBhbnkgdHlwZS4gSSBhbSBub3Qgc3VyZSB0aGlzIG1hdHRl cnMgaW4gcHJhY3RpY2UsIGJ1dCBpdCBkb2VzIOKAnGZlZWzigJ0gY29tcGxleCBmcm9tIGEgbWVk aWEgdHlwZSBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBhbiBlZGl0b3JpYWwgYW5kIElBTkEgcGVyc3BlY3RpdmUs IEkgYmVsaWV2ZSB1c2luZyDigJxtc2dUeXBl4oCdIG1lYW5zIHRoYXQgd2UgaGF2ZSB0byBidWls ZCBhIHNlcGFyYXRlIElBTkEgcmVnaXN0cnkgZm9yIG1lc3NhZ2VzIGRpc3RpbmN0IGZyb20gc2No ZW1hcy4gR2l2ZW4gdGhhdCB0aGUgcmV2aWV3IHByb2Nlc3MgaXMgZXNzZW50aWFsbHkgdGhlIHNh bWUsIEnigJltIG5vdCBzdXJlIHRoZXJlIGlzIGEgbG90DQogb2YgYmVuZWZpdC4gSSB3b25kZXIg dGhlbiBpZiBjbGFyaWZ5aW5nIHRleHQgbWlnaHQgbm90IHdvcmsgYXMgd2VsbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBJIGhhdmUg ZG9uZSBpcyB3cml0dGVuIGEgbmV3IGludHJvZHVjdGlvbiB0byBzZWN0aW9uIDMgb2YgdGhlIEFQ SSBzcGVjaWZpY2F0aW9uLiBNeSBob3BlIGlzIHRoYXQgdGhpcyBzZXRzIHRoZSBzdGFnZSBmb3Ig aG93IFNDSU0gcHJvdG9jb2wgd29ya3MgYW5kIGNsZWFybHkgZXN0YWJsaXNoZXMgdGhlIGRpZmZl cmVuY2VzIGJldHdlZW4gU0NJTSByZXNvdXJjZXMgYW5kIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5BY3Rpb24gSXRlbTog Jm5ic3A7UExFQVNFIElORElDQVRFIChieSBuZXh0IFR1ZXNkYXkgbW9ybmluZyBpZiBwb3NzaWJs ZSk6PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BLiZuYnNwOyBHaXZlbiB0aGUgdGV4dCBiZWxvdywgZG9lcyBhbnlvbmUgc3Ryb25nbHkg cHJlZmVyIHVzaW5nIOKAnG1zZ1R5cGXigJ0gaW5zdGVhZCAoYW5kIGNyZWF0aW5nIGEgbmV3IHJl Z2lzdHJ5IGZvciBpdCk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkIuJm5ic3A7IENvbW1lbnRzIG9uIHRoZSB0ZXh0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBST1BPU0VEIFRF WFQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6 YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+My4mbmJzcDsgU0NJTSBQcm90b2NvbDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMuMS4m bmJzcDsgSW50cm9kdWN0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFNDSU0gaXMgYSBwcm90b2NvbCBiYXNlZCBvbiBI VFRQIFtSRkM3MjMwXS4mbmJzcDsgQWxvbmcgd2l0aCBIVFRQIGhlYWRlcnM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYW5kIFVSSXMsIFNDSU0gdXNlcyBKU09OIFtSRkM3MTU5 XSBwYXlsb2FkcyB0byBjb252ZXkgYm90aCBTQ0lNPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IHJlc291cmNlcyBhcyB3ZWxsIGFzIHJlcXVlc3QgcGFyYW1ldGVycyBhbmQgcmVz cG9uc2UgaW5mb3JtYXRpb24gc3VjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBhcyBlcnJvcnMgaW4gdGhlIGZvcm0gb2YgSlNPTiBiYXNlZCBtZXNzYWdlcy4mbmJzcDsgVG8g aWRlbnRpZnkgdGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb250ZW50 LCBTQ0lNIHVzZXMgYSBtZWRpYSB0eXBlIG9mICZxdW90O2FwcGxpY2F0aW9uL3NjaW0mIzQzO2pz b24mcXVvdDsgKHNlZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTZWN0aW9u IDguMSkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IEEgU0NJTSByZXNvdXJjZSBpcyBhIEpTT04gb2JqZWN0IHRoYXQgbWF5 IGJlIGNyZWF0ZWQsIG1haW50YWluZWQsIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyByZXRyaWV2ZWQgdGhyb3VnaCBIVFRQIG1ldGhvZHMgYXMgZGVzY3JpYmVkIGluIHRo aXMgZG9jdW1lbnQuJm5ic3A7IEVhY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgSlNPTiByZXNvdXJjZSByZXByZXNlbnRhdGlvbiBjb250YWlucyBhICZxdW90O3NjaGVtYXMm cXVvdDsgYXR0cmlidXRlIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg Y29udGFpbnMgYSBsaXN0IG9mIG9uZSBvciBtb3JlIFVSSXMgdGhhdCBpbmRpY2F0ZSBpbmNsdWRl ZCBTQ0lNPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNjaGVtYXMgdGhhdCBt YXkgYmUgdXNlZCB0byBpbmRpY2F0ZSB0aGUgYXR0cmlidXRlcyBjb250YWluZWQgd2l0aGluPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGEgcmVzb3VyY2UuJm5ic3A7IFdoZW4g cXVlcnlpbmcgYSBTQ0lNIHNlcnZpY2UgcHJvdmlkZXIncyAmcXVvdDsvU2NoZW1hcyZxdW90Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBlbmRwb2ludCBmb3Igc2NoZW1hIGRl ZmluaXRpb24gKHNlZSBTZWN0aW9uIDguNzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBbSS1ELmlldGYtc2NpbS1jb3JlLXNjaGVtYV0pLCB0aGUgcmVzcG9uc2UgZGVzY3JpYmVz IGhvdyBhIHNlcnZpY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJvdmlk ZXIgc3VwcG9ydHMgYW4gYXR0cmlidXRlIGluY2x1ZGluZyBzY2hlbWEgbWV0YS1hdHRyaWJ1dGVz IHN1Y2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXMgY2FzZS1leGFjdG5l c3MsIG11dGFiaWxpdHksIHVuaXF1ZW5lc3MsIHJldHVybmFiaWxpdHksIGFuZCB3aGV0aGVyPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGl0IGlzIHJlcXVpcmVkLiZuYnNwOyBX aGlsZSBTQ0lNIHNjaGVtYXMgYW5kIGFzc29jaWF0ZWQgZXh0ZW5zaW9uIG1vZGVsIGlzPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRlZmluZWQgaW4gW0ktRC5pZXRmLXNjaW0t Y29yZS1zY2hlbWFdLCBTQ0lNIGNsaWVudHMgc2hvdWxkIGV4cGVjdDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGF0IHNvbWUgYXR0cmlidXRlIHNjaGVtYSBNQVkgY2hhbmdl IGZyb20gZGVwbG95bWVudCB0byBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBJbiBjYXNlcyB3aGVyZSBTQ0lNIG1heSBiZSB1c2VkIGFzIGFuIG9wZW4gcHJv dG9jb2wgaW4gZnJvbnQgb2YgYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg YXBwbGljYXRpb24gc2VydmljZSwgaXQgaXMgcXVpdGUgcmVhc29uYWJsZSB0byBleHBlY3QgdGhh dCBzb21lPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNlcnZpY2UgcHJvdmlk ZXJzIE1BWSBvbmx5IHN1cHBvcnQgYSBzdWItc2V0IG9mIHRoZSBzY2hlbWEgZGVmaW5lZCBpbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBbSS1ELmlldGYtc2NpbS1jb3JlLXNj aGVtYV0uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IEEgU0NJTSBtZXNzYWdlIGlzIGEgSlNPTiBvYmplY3QgdGhhdCBjb252 ZXlzIHByb3RvY29sIHBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgYWJvdXQgYSBTQ0lNIHJlcXVlc3Qgb3IgcmVzcG9uc2UgdGhhdCBhcmUgZGVmaW5lZCBieSB0 aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24uJm5i c3A7IEFzIHdpdGggYSBTQ0lNIHJlc291cmNlLCBhIFNDSU0gbWVzc2FnZSBpcyBhIEpTT048bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb2JqZWN0IHRoYXQgY29udGFpbnMgYSAm cXVvdDtzY2hlbWFzJnF1b3Q7IGF0dHJpYnV0ZSB3aXRoIGEgVVJJIHdob3NlIG5hbWVzcGFjZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcmVmaXggYmVnaW5zIHdpdGggJnF1 b3Q7dXJuOmlldGY6cGFyYW1zOnNjaW06YXBpOiZxdW90Oy4mbmJzcDsgQXMgU0NJTSBwcm90b2Nv bDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtZXNzYWdlcyBhcmUgZml4ZWQg YW5kIGRlZmluZWQgYnkgU0NJTSBzcGVjaWZpY2F0aW9ucyBhbmQgcmVnaXN0ZXJlZDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBleHRlbnNpb25zLCBTQ0lNIG1lc3NhZ2Ugc2No ZW1hcyB1c2luZyB0aGUgYWJvdmUgcHJlZml4IFVSTiBTSEFMTCBOT1Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgYmUgZGlzY292ZXJhYmxlIHVzaW5nIHRoZSAmcXVvdDsvU2No ZW1hcyZxdW90OyBlbmRwb2ludC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQXMgU0NJTSBpbiBpbnRlbmRlZCBmb3IgdXNl IHdpdGhpbiBjcm9zcy1kb21haW4gZW52aXJvbm1lbnRzIHdoZXJlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IHNjaGVtYXMgTUFZIHZhcnksIHRlY2huaXF1ZXMgc3VjaCBhcyBk b2N1bWVudCB2YWxpZGF0aW9uLCBzdWNoIGFzIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IFtYTUwtU2NoZW1hXSwgYXJlIG5vdCByZWNvbW1lbmRlZC4mbmJzcDsgQSBTQ0lN IHNlcnZpY2UgcHJvdmlkZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW50 ZXJwcmV0cyBhIHJlcXVlc3QgaW4gdGhlIGNvbnRleHQgb2YgaXRzIG93biBzY2hlbWEgKHdoaWNo IG1heSBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgZnJv bSB0aGUgY2xpZW50J3Mgc2NoZW1hKSBhbmQgdGhlIHByb2Nlc3NpbmcgcnVsZXM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZGVzY3JpYmVkIGZvciBlYWNoIFNDSU0gcmVxdWVz dC4mbmJzcDsgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyBpbiB0aGlzPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IGRlZmluZSBwcm9jZXNzaW5nIHJ1bGVzIGZvciBT Q0lNIHRoYXQgcHJvdmlkZSBhbGxvd2FuY2VzIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBkaWZmZXJlbmNlcyB3aGVyZSBhcHByb3ByaWF0ZS4mbmJzcDsgRm9yIGV4YW1w bGUsIGluIGEgU0NJTSBQVVQgcmVxdWVzdCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgJnF1b3Q7cmVhZE9ubHkmcXVvdDsgYXR0cmlidXRlcyBhcmUgaWdub3JlZCwgd2hpbGUg JnF1b3Q7cmVhZFdyaXRlJnF1b3Q7IGF0dHJpYnV0ZXMgYXJlPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHVwZGF0ZWQuJm5ic3A7IFRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBj bGllbnQgdG8gZGlzY292ZXIgd2hpY2g8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgYXR0cmlidXRlcyBhcmUgJnF1b3Q7cmVhZE9ubHkmcXVvdDsgYW5kIHJlbW92ZSB0aGVtIGZy b20gdGhlIFBVVCByZXF1ZXN0IGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGFkdmFuY2UgaW4gb3JkZXIgdG8gYmUgYWNjZXB0ZWQuJm5ic3A7IFNpbWlsYXJseSBhIFNDSU0g Y2xpZW50IFNIT1VMRCBOT1Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZXhw ZWN0IGEgc2VydmljZSBwcm92aWRlciB0byByZXR1cm4gU0NJTSByZXNvdXJjZXMgd2l0aCBleGFj dGx5IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzYW1lIHNjaGVtYSBh bmQgdmFsdWVzIGFzIHN1Ym1pdHRlZC4mbmJzcDsgU0NJTSByZXNwb25zZXMgU0hBTEwgcmVmbGVj dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXNvdXJjZSBzdGF0ZSBhcyBp bnRlcnByZXRlZCBieSB0aGUgU0NJTSBzZXJ2aWNlIHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMuMi4mbmJzcDsgU0NJTSBFbmRw b2ludHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgVGhlIFNDSU0gcHJvdG9jb2wgc3BlY2lmaWVzIHdlbGwta25vd24gZW5k cG9pbnRzIGFuZCBIVFRQIG1ldGhvZHMgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IG1hbmFnaW5nIHJlc291cmNlcyBkZWZpbmVkIGluIHRoZSBjb3JlIHNjaGVtYTsgaS5l LiwgJnF1b3Q7VXNlciZxdW90OyBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0 PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklhbiBHbGF6ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlbmlvciBEaXJlY3RvciwgSWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSAyMDIgMjU1IDMxNjY8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vdHdpdHRlci5jb20vaWdsYXplciIgdGFyZ2V0PSJfYmxhbmsiPkBpZ2xhemVyPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BN1PR04MB392DAE4EC6599D5E3FDFDB7E2110BN1PR04MB392namprd_-- From nobody Tue Mar 3 07:29:44 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E21A8787 for ; Tue, 3 Mar 2015 07:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WuYHq9Co9cbi for ; Tue, 3 Mar 2015 07:29:41 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8901A872F for ; Tue, 3 Mar 2015 07:29:41 -0800 (PST) Received: by iecrp18 with SMTP id rp18so59274116iec.1 for ; Tue, 03 Mar 2015 07:29:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qjXXh9IuVWj90kagy+Nb4iX52PZ2wnIgk1jrTHTLw48=; b=eE0+Q4l+dHNSIxMfO1Yy73x0x1rZE1QR5xd+p0rvegRVXDUDkfefAQdR1Gf6ycHajD n8qlTvBRvK8v/HTQOIQpKTo3rBsyqI+urbH8pPYbrAss8kDqFVJIMClUduXAXBlNE9c6 Mw1JElGx4/vwQnhdahO1FLx8UA+S1+B7s8oXosHfqv0GDnVC7h4A4xLcaGiQK7z4FdbI RgIYZUwtnrlufV9g+pql6PKMGT3B7My6OwYxQPyqbdXomu6iT+qLKJ5iKnoB590t9Kio Qy2pXRRFPgIazH/zcMSmlrTabMCHwB0Sl14oJ/JyHBMZIDhb7wmLM9RnSP399DM3W7xC uFYQ== X-Gm-Message-State: ALoCoQnjL06qyIIydBHu0oJgxvYUJaaY8s9dT04pJNx7WPCXFCy04RLkYnTEJMYP4BVwkazBOT1r X-Received: by 10.107.30.135 with SMTP id e129mr2775618ioe.26.1425396580110; Tue, 03 Mar 2015 07:29:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.127.141 with HTTP; Tue, 3 Mar 2015 07:29:19 -0800 (PST) In-Reply-To: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> From: Ian Glazer Date: Tue, 3 Mar 2015 10:29:19 -0500 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1140f5d2d276880510640076 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 15:29:44 -0000 --001a1140f5d2d276880510640076 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am okay with this change On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt wrote: > All, > > Michael has reminded me that x509Certificate is DER encoded binary which > is in conflict with our current binary definition. > > I recommend changing the definition of Binary FROM: > > 2.2.6. Binary > > Arbitrary binary data. The attribute value MUST be encoded as a base > 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is > case-exact and has no uniqueness. > > Values represented in JSON MUST conform to the XML constraints above > and are represented as a JSON String per Section 2.7 [RFC7159]. > > TO: > > 2.2.6. Binary > > Arbitrary binary data. The attribute value MUST be encoded in* Base > 64 encoding as specified in Section 4 [RFC4648]. In cases where a > URL-safe encoding is required, the attribute definition MAY specify > Base 64 URL encoding MAY be used as per Section 5 [RFC4648]*. > > *In JSON representation, the encoded values are represented as a JSON > String per Section 7 [RFC7159]. A binary is case-exact and has no > uniqueness.* > > Further, I would recommend changing x509certificates FROM: > > x509Certificates > A list of certificates issued to the User. Values are Binary > (Section 2.2.6) and DER encoded x509. This value has NO canonical > types. > > TO: > > x509Certificates > A list of certificates issued to the User. Values are binary > (Section 2.2.6) and* are Base 64 encoded x509 per Section 4 > [RFC4648].* > > > *Important: This is a normative change as we are correcting the previous > =E2=80=9CDER=E2=80=9D encoding to be base 64 encoding for consistency wit= h the definition > of binary and JSON compatibility.* > > *If possible, please have comments to the list by 5PM Pacific tomorrow > (Tuesday)*. I would like to publish draft 17 of core-schema in order to > be able to publish the changes to the API draft later in the week. Note > that the proposed changes for tomorrow include expanding section 8.7 to > include schemas for fixed (non-resource) service provider schemas: > ServiceProviderConfig, ResourceType, Schema. > > Cheers, > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 2, 2015, at 12:25 PM, Phil Hunt wrote: > > I think it should be one form. > > My recommendation would be base64url for max utility. Especially if we > start defining schema related to JWT keys (JWK) from OAuth and JOSE. > > Phil > > On Mar 2, 2015, at 12:06, Ian Glazer wrote: > > Would this be base64url "required" or "recommended"? > > Would the encoding type be a declared attribute of the SP? > > On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > >> >> I was looking through the schema document and cleaning up the data type >> characteristics (as discussed previously), I notice that the reference t= o >> XML-Schema is to the October 2004 one and not the 2012 XML Schema. The >> IETF will likely require us to reference the current spec, so I should >> probably update the reference. >> >> Looking at the binary attribute representation, I am wondering if we >> should change this to the current IETF specification which is: RFC4648 >> rather than reference XML-Schema 3.2.16 (of the 2004 schema spec). >> >> Do we want to further clarify that the encoding be: base64url? Not a >> javascript expert, but wondering if we need to use url safe encoding? Th= is >> may result in a normative clarification for some. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a1140f5d2d276880510640076 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am okay with this change

On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt <= span dir=3D"ltr"><phil.hunt@oracle.com> wrote:
All,

Michael h= as reminded me that x509Certificate is DER encoded binary which is in confl= ict with our current binary definition.

I recommen= d changing the definition of Binary FROM:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded as a base
   64 encoding as specified in Section 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniqueness.

   Values represented in JSON MUST conform to the XML constraints above
   and are represented as a JSON String per Section 2.7 [RFC7159].
TO:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded in Base
   64 encoding as specified in Section 4 [RFC4648].  In cases where a
   URL-safe encoding is required, the attribute definition MAY specify
   Base 64 URL encoding MAY be used as per Section 5 [RFC4648].

   In JSON representation, the encoded values are represented as a JSON
   String per Section 7 [RFC7159].  A binary is case-exact and has no
   uniqueness.
Further, I would recommend changing x509certif= icates FROM:
   x509Certificates
      A list of certificates issued to the User.  Values are Binary
      (Section 2.2.6) and DER encoded x509.  This value has NO canonical
      types.
TO:
   x509Certificates
      A list of certificates issued to the User.  Values are binary
      (Section 2.2.6) and are Base 64 encoded x509 per Section 4
      [RFC4648].

Important: =C2=A0This is a normative cha= nge as we are correcting the previous =E2=80=9CDER=E2=80=9D encoding to be = base 64 encoding for consistency with the definition of binary and JSON com= patibility.

If possible, please have com= ments to the list by 5PM Pacific tomorrow (Tuesday).=C2=A0 I would = like to publish draft 17 of core-schema in order to be able to publish the = changes to the API draft later in the week.=C2=A0 Note that the proposed ch= anges for tomorrow include expanding section 8.7 to include schemas for fix= ed (non-resource) service provider schemas: =C2=A0ServiceProviderConfig, Re= sourceType, Schema.

Cheers,

=
Phil

@independentid
<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om

On Mar 2, 2015, at 12:25 PM, Phil H= unt <phil.hunt= @oracle.com> wrote:

I think it = should be one form.=C2=A0

My recommendation would = be base64url for max utility. Especially if we start defining schema relate= d to JWT keys (JWK) from OAuth and JOSE.=C2=A0

Phil

On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:
Would this be base64= url "required" or "recommended"?

Wou= ld the encoding type be a declared attribute of the SP?

On Mon, Mar 2, 2015 at 2:= 07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

= I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema.=C2=A0 The IE= TF will likely require us to reference the current spec, so I should probab= ly update the reference.

Looking at the binary attribute= representation, I am wondering if we should change this to the current IET= F specification which is: RFC4648 rather than reference XML-Schema 3.2.16 (= of the 2004 schema spec).

Do we want to further cl= arify that the encoding be: base64url? =C2=A0 Not a javascript expert, but = wondering if we need to use url safe encoding? This may result in a normati= ve clarification for some.


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




--
Ian Glazer
Senior Director, Identity
=
_______________________________________________scim mailing list
sc= im@ietf.org
https://www.ietf.org/mailman/listinfo/scim




--
Ian Glazer
Senior Director, Identity
+1 = 202 255 3166
--001a1140f5d2d276880510640076-- From nobody Tue Mar 3 07:53:10 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5D11A87A3 for ; Tue, 3 Mar 2015 07:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 02k4-sQGXSiw for ; Tue, 3 Mar 2015 07:53:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822C31A878E for ; Tue, 3 Mar 2015 07:53:07 -0800 (PST) Received: from BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) by BN1PR04MB121.namprd04.prod.outlook.com (10.255.199.147) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 15:53:06 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB389.namprd04.prod.outlook.com (10.141.60.140) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 15:53:00 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) with mapi id 15.01.0099.004; Tue, 3 Mar 2015 15:53:00 +0000 From: Kelly Grizzle To: Phil Hunt , Ian Glazer Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwdSsyOqgO/b0CsgI/19U41Mp0JnqMAgAAFNYCAAUUCEA== Date: Tue, 3 Mar 2015 15:53:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 045EC1520094C6045EC29F x-originating-ip: [70.114.158.171] authentication-results: oracle.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR04MB389; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB389; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(15975445007)(2656002)(2950100001)(106116001)(62966003)(19625215002)(54356999)(66066001)(74316001)(86362001)(102836002)(2900100001)(87936001)(76576001)(19609705001)(46102003)(16601075003)(19580405001)(19580395003)(33656002)(16236675004)(19300405004)(92566002)(99286002)(122556002)(77156002)(19617315012)(50986999)(76176999)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB389; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB3923BEBEC101EAF4A52FCD2E2110BN1PR04MB392namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 15:53:00.4629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB389 X-OriginatorOrg: sailpoint.com Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 15:53:09 -0000 --_000_BN1PR04MB3923BEBEC101EAF4A52FCD2E2110BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaGF2ZW7igJl0IGZvbGxvd2VkIEpXVC9KV0ssIHNvIGRvbuKAmXQga25vdyBhbGwgb2Yg dGhlIGhpc3RvcnkuDQoNCkhvd2V2ZXIsIGJhc2VkIG9uIHJlYWRpbmcgUkZDIDQ2NDgsIGl0IHNl ZW1zIHRoYXQgYmFzZTY0dXJsIGlzIHByaW1hcmlseSB1c2VkIGlmIHRoZSBlbmNvZGVkIGRhdGEg d2lsbCBhcHBlYXIgaW4gYSBVUkwgb3IgZmlsZW5hbWUuICBHaXZlbiB0aGUgZmFjdCB0aGF0IGlu IFNDSU0gYmFzZTY0IHdpbGwgYWx3YXlzIG9jY3VyIGluIHJlcXVlc3QgYW5kIHJlc3BvbnNlIGJv ZGllcywgSSBkb27igJl0IGtub3cgdGhhdCB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0IGJhc2U2NHVy bC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGlmIG1vc3QgaWRlbnRpdHktcmVsYXRlZCBzdGFuZGFy ZHMgYXJlIHVzaW5nIGJhc2U2NHVybCwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBnbyB3aXRoIHRo aXMgZm9yIGNvbnNpc3RlbmN5Lg0KDQpJbiBlaXRoZXIgY2FzZSwgSSBhZ3JlZSB0aGF0IHdlIHNo b3VsZCBzdGFuZGFyZGl6ZSBvbiBlaXRoZXIgYmFzZTY0IG9yIGJhc2U2NHVybCBhbmQgbm90IGFs bG93IGJvdGguDQoNCi0tS2VsbHkNCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogTW9uZGF5LCBNYXJjaCAwMiwg MjAxNSAyOjI2IFBNDQpUbzogSWFuIEdsYXplcg0KQ2M6IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBb c2NpbV0gQmFzZTY0IEVuY29kaW5nIGZvciBCaW5hcnkgQXR0cmlidXRlcw0KDQpJIHRoaW5rIGl0 IHNob3VsZCBiZSBvbmUgZm9ybS4NCg0KTXkgcmVjb21tZW5kYXRpb24gd291bGQgYmUgYmFzZTY0 dXJsIGZvciBtYXggdXRpbGl0eS4gRXNwZWNpYWxseSBpZiB3ZSBzdGFydCBkZWZpbmluZyBzY2hl bWEgcmVsYXRlZCB0byBKV1Qga2V5cyAoSldLKSBmcm9tIE9BdXRoIGFuZCBKT1NFLg0KDQpQaGls DQoNCk9uIE1hciAyLCAyMDE1LCBhdCAxMjowNiwgSWFuIEdsYXplciA8aWdsYXplckBzYWxlc2Zv cmNlLmNvbTxtYWlsdG86aWdsYXplckBzYWxlc2ZvcmNlLmNvbT4+IHdyb3RlOg0KV291bGQgdGhp cyBiZSBiYXNlNjR1cmwgInJlcXVpcmVkIiBvciAicmVjb21tZW5kZWQiPw0KDQpXb3VsZCB0aGUg ZW5jb2RpbmcgdHlwZSBiZSBhIGRlY2xhcmVkIGF0dHJpYnV0ZSBvZiB0aGUgU1A/DQoNCk9uIE1v biwgTWFyIDIsIDIwMTUgYXQgMjowNyBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSSB3YXMgbG9va2luZyB0 aHJvdWdoIHRoZSBzY2hlbWEgZG9jdW1lbnQgYW5kIGNsZWFuaW5nIHVwIHRoZSBkYXRhIHR5cGUg Y2hhcmFjdGVyaXN0aWNzIChhcyBkaXNjdXNzZWQgcHJldmlvdXNseSksIEkgbm90aWNlIHRoYXQg dGhlIHJlZmVyZW5jZSB0byBYTUwtU2NoZW1hIGlzIHRvIHRoZSBPY3RvYmVyIDIwMDQgb25lIGFu ZCBub3QgdGhlIDIwMTIgWE1MIFNjaGVtYS4gIFRoZSBJRVRGIHdpbGwgbGlrZWx5IHJlcXVpcmUg dXMgdG8gcmVmZXJlbmNlIHRoZSBjdXJyZW50IHNwZWMsIHNvIEkgc2hvdWxkIHByb2JhYmx5IHVw ZGF0ZSB0aGUgcmVmZXJlbmNlLg0KDQpMb29raW5nIGF0IHRoZSBiaW5hcnkgYXR0cmlidXRlIHJl cHJlc2VudGF0aW9uLCBJIGFtIHdvbmRlcmluZyBpZiB3ZSBzaG91bGQgY2hhbmdlIHRoaXMgdG8g dGhlIGN1cnJlbnQgSUVURiBzcGVjaWZpY2F0aW9uIHdoaWNoIGlzOiBSRkM0NjQ4IHJhdGhlciB0 aGFuIHJlZmVyZW5jZSBYTUwtU2NoZW1hIDMuMi4xNiAob2YgdGhlIDIwMDQgc2NoZW1hIHNwZWMp Lg0KDQpEbyB3ZSB3YW50IHRvIGZ1cnRoZXIgY2xhcmlmeSB0aGF0IHRoZSBlbmNvZGluZyBiZTog YmFzZTY0dXJsPyAgIE5vdCBhIGphdmFzY3JpcHQgZXhwZXJ0LCBidXQgd29uZGVyaW5nIGlmIHdl IG5lZWQgdG8gdXNlIHVybCBzYWZlIGVuY29kaW5nPyBUaGlzIG1heSByZXN1bHQgaW4gYSBub3Jt YXRpdmUgY2xhcmlmaWNhdGlvbiBmb3Igc29tZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0K d3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGls Lmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBs aXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9y IERpcmVjdG9yLCBJZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3 aXR0ZXIuY29tL2lnbGF6ZXI+DQo= --_000_BN1PR04MB3923BEBEC101EAF4A52FCD2E2110BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PknigJltIGhhdmVu4oCZdCBmb2xsb3dlZCBKV1QvSldLLCBzbyBkb27igJl0IGtub3cgYWxsIG9m IHRoZSBoaXN0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgYmFzZWQgb24gcmVhZGluZyBSRkMgNDY0 OCwgaXQgc2VlbXMgdGhhdCBiYXNlNjR1cmwgaXMgcHJpbWFyaWx5IHVzZWQgaWYgdGhlIGVuY29k ZWQgZGF0YSB3aWxsIGFwcGVhciBpbiBhIFVSTCBvciBmaWxlbmFtZS4mbmJzcDsgR2l2ZW4gdGhl IGZhY3QgdGhhdCBpbg0KIFNDSU0gYmFzZTY0IHdpbGwgYWx3YXlzIG9jY3VyIGluIHJlcXVlc3Qg YW5kIHJlc3BvbnNlIGJvZGllcywgSSBkb27igJl0IGtub3cgdGhhdCB3ZSBuZWVkIHRvIHdvcnJ5 IGFib3V0IGJhc2U2NHVybC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIG90aGVyIGhhbmQsIGlm IG1vc3QgaWRlbnRpdHktcmVsYXRlZCBzdGFuZGFyZHMgYXJlIHVzaW5nIGJhc2U2NHVybCwgaXQg bWlnaHQgbWFrZSBzZW5zZSB0byBnbyB3aXRoIHRoaXMgZm9yIGNvbnNpc3RlbmN5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SW4gZWl0aGVyIGNhc2UsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc3RhbmRhcmRpemUgb24g ZWl0aGVyIGJhc2U2NCBvciBiYXNlNjR1cmwgYW5kIG5vdCBhbGxvdyBib3RoLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LS1LZWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIE1hcmNoIDAyLCAyMDE1IDI6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IElhbiBHbGF6ZXI8 YnI+DQo8Yj5DYzo8L2I+IFNDSU0gV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBC YXNlNjQgRW5jb2RpbmcgZm9yIEJpbmFyeSBBdHRyaWJ1dGVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgc2hvdWxkIGJlIG9u ZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NeSByZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSBiYXNlNjR1cmwgZm9yIG1heCB1 dGlsaXR5LiBFc3BlY2lhbGx5IGlmIHdlIHN0YXJ0IGRlZmluaW5nIHNjaGVtYSByZWxhdGVkIHRv IEpXVCBrZXlzIChKV0spIGZyb20gT0F1dGggYW5kIEpPU0UuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpQaGlsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAyLCAyMDE1LCBhdCAxMjowNiwgSWFuIEdsYXpl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20iPmlnbGF6ZXJAc2Fs ZXNmb3JjZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHRoaXMgYmUgYmFzZTY0dXJsICZx dW90O3JlcXVpcmVkJnF1b3Q7IG9yICZxdW90O3JlY29tbWVuZGVkJnF1b3Q7PzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgdGhlIGVuY29kaW5nIHR5 cGUgYmUgYSBkZWNsYXJlZCBhdHRyaWJ1dGUgb2YgdGhlIFNQPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyLCAyMDE1IGF0 IDI6MDcgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIGxvb2tp bmcgdGhyb3VnaCB0aGUgc2NoZW1hIGRvY3VtZW50IGFuZCBjbGVhbmluZyB1cCB0aGUgZGF0YSB0 eXBlIGNoYXJhY3RlcmlzdGljcyAoYXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkpLCBJIG5vdGljZSB0 aGF0IHRoZSByZWZlcmVuY2UgdG8gWE1MLVNjaGVtYSBpcyB0byB0aGUgT2N0b2JlciAyMDA0IG9u ZSBhbmQgbm90IHRoZSAyMDEyIFhNTCBTY2hlbWEuJm5ic3A7IFRoZSBJRVRGIHdpbGwgbGlrZWx5 IHJlcXVpcmUNCiB1cyB0byByZWZlcmVuY2UgdGhlIGN1cnJlbnQgc3BlYywgc28gSSBzaG91bGQg cHJvYmFibHkgdXBkYXRlIHRoZSByZWZlcmVuY2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGF0IHRoZSBiaW5hcnkgYXR0cmlidXRlIHJlcHJl c2VudGF0aW9uLCBJIGFtIHdvbmRlcmluZyBpZiB3ZSBzaG91bGQgY2hhbmdlIHRoaXMgdG8gdGhl IGN1cnJlbnQgSUVURiBzcGVjaWZpY2F0aW9uIHdoaWNoIGlzOiBSRkM0NjQ4IHJhdGhlciB0aGFu IHJlZmVyZW5jZSBYTUwtU2NoZW1hIDMuMi4xNiAob2YgdGhlIDIwMDQgc2NoZW1hIHNwZWMpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB3 ZSB3YW50IHRvIGZ1cnRoZXIgY2xhcmlmeSB0aGF0IHRoZSBlbmNvZGluZyBiZTogYmFzZTY0dXJs PyAmbmJzcDsgTm90IGEgamF2YXNjcmlwdCBleHBlcnQsIGJ1dCB3b25kZXJpbmcgaWYgd2UgbmVl ZCB0byB1c2UgdXJsIHNhZmUgZW5jb2Rpbmc/IFRoaXMgbWF5IHJlc3VsdCBpbiBhIG5vcm1hdGl2 ZSBjbGFyaWZpY2F0aW9uIGZvciBzb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xh emVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgMjAyIDI1NSAzMTY2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3R3aXR0 ZXIuY29tL2lnbGF6ZXIiIHRhcmdldD0iX2JsYW5rIj5AaWdsYXplcjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN1PR04MB3923BEBEC101EAF4A52FCD2E2110BN1PR04MB392namprd_-- From nobody Tue Mar 3 08:43:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD201A1A17 for ; Tue, 3 Mar 2015 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FAOTcR-70SOD for ; Tue, 3 Mar 2015 08:43:29 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23011A01FC for ; Tue, 3 Mar 2015 08:43:29 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t23GhSZd031887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 16:43:29 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t23GhRNX025336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 16:43:27 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t23GhRap015641; Tue, 3 Mar 2015 16:43:27 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Mar 2015 08:43:21 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-FDDCF4AF-B43B-4029-B53B-7424E0F7D5CD Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Mar 2015 08:43:21 -0800 Content-Transfer-Encoding: 7bit Message-Id: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> References: To: Kelly Grizzle X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:43:32 -0000 --Apple-Mail-FDDCF4AF-B43B-4029-B53B-7424E0F7D5CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable JWK is JSON web key. They are passable in urls. =20 JWK is the new JSON equivalent of x509. The good news is these are all just strings. So no extra coding to support.= But the client will need to know how it is encoded. I propose the attribute= defn can do this sufficiently. =20 Phil > On Mar 3, 2015, at 07:53, Kelly Grizzle wrot= e: >=20 > I=E2=80=99m haven=E2=80=99t followed JWT/JWK, so don=E2=80=99t know all of= the history. > =20 > However, based on reading RFC 4648, it seems that base64url is primarily u= sed if the encoded data will appear in a URL or filename. Given the fact th= at in SCIM base64 will always occur in request and response bodies, I don=E2= =80=99t know that we need to worry about base64url.=20 > =20 > On the other hand, if most identity-related standards are using base64url,= it might make sense to go with this for consistency. > =20 > In either case, I agree that we should standardize on either base64 or bas= e64url and not allow both. > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Monday, March 02, 2015 2:26 PM > To: Ian Glazer > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > I think it should be one form.=20 > =20 > My recommendation would be base64url for max utility. Especially if we sta= rt defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >=20 > Phil >=20 > On Mar 2, 2015, at 12:06, Ian Glazer wrote: >=20 > Would this be base64url "required" or "recommended"? > =20 > Would the encoding type be a declared attribute of the SP? > =20 > On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > =20 > I was looking through the schema document and cleaning up the data type ch= aracteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wil= l likely require us to reference the current spec, so I should probably upda= te the reference. > =20 > Looking at the binary attribute representation, I am wondering if we shoul= d change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). > =20 > Do we want to further clarify that the encoding be: base64url? Not a jav= ascript expert, but wondering if we need to use url safe encoding? This may r= esult in a normative clarification for some. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-FDDCF4AF-B43B-4029-B53B-7424E0F7D5CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
JWK is JSON web key. They are passable= in urls.  

JWK is the new JSON equivalent of x= 509.

The good news is these are all just strings. &= nbsp;So no extra coding to support. But the client will need to know how it i= s encoded. I propose the attribute defn can do this sufficiently.  
=
Phil

On Mar 3, 2015, at 07:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wro= te:

I=E2=80=99m haven=E2=80=99t= followed JWT/JWK, so don=E2=80=99t know all of the history.

 

However, based on reading R= FC 4648, it seems that base64url is primarily used if the encoded data will a= ppear in a URL or filename.  Given the fact that in SCIM base64 will always occur in request and response bodies, I don=E2=80=99= t know that we need to worry about base64url. 

 

On the other hand, if most i= dentity-related standards are using base64url, it might make sense to go wit= h this for consistency.

 

In either case, I agree tha= t we should standardize on either base64 or base64url and not allow both.

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, March 02, 2015 2:26 PM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes<= /span>

 

I think it should be one form. 

 

My recommendation would be base64url for max utility.= Especially if we start defining schema related to JWT keys (JWK) from OAuth= and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or "recommended"?<= o:p>

 

Would the encoding type be a declared attribute of th= e SP?

 

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <phil.hunt@oracle.com&= gt; wrote:

 

I was looking through the schema document and cleanin= g up the data type characteristics (as discussed previously), I notice that t= he reference to XML-Schema is to the October 2004 one and not the 2012 XML S= chema.  The IETF will likely require us to reference the current spec, so I should probably update the reference= .

 

Looking at the binary attribute representation, I am w= ondering if we should change this to the current IETF specification which is= : RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).=

 

Do we want to further clarify that the encoding be: b= ase64url?   Not a javascript expert, but wondering if we need to use ur= l safe encoding? This may result in a normative clarification for some.=

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-FDDCF4AF-B43B-4029-B53B-7424E0F7D5CD-- From nobody Tue Mar 3 08:54:37 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA071AC3A2 for ; Tue, 3 Mar 2015 08:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 D0OMoOngIc3S for ; Tue, 3 Mar 2015 08:54:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A7B1ABD3D for ; Tue, 3 Mar 2015 08:54:33 -0800 (PST) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 16:54:12 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) with mapi id 15.01.0099.004; Tue, 3 Mar 2015 16:54:12 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwdSsyOqgO/b0CsgI/19U41Mp0JnqMAgAAFNYCAAUUCEIAADz6AgAACViA= Date: Tue, 3 Mar 2015 16:54:11 +0000 Message-ID: References: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> In-Reply-To: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 0496C3650094C60496C4B2 x-originating-ip: [97.79.140.10] authentication-results: oracle.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB392; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR04MB392; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB392; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(110136001)(2950100001)(92566002)(2900100001)(62966003)(76176999)(102836002)(77156002)(76576001)(86362001)(19617315012)(93886004)(50986999)(33656002)(15975445007)(74316001)(16236675004)(19625215002)(2656002)(87936001)(106116001)(122556002)(19580395003)(19580405001)(66066001)(46102003)(19609705001)(16601075003)(19300405004)(54356999)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB392E58EB32CD1CCF1427531E2110BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 16:54:11.9508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB392 Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:54:36 -0000 --_000_BN1PR04MB392E58EB32CD1CCF1427531E2110BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHByb3Bvc2UgdGhlIGF0dHJpYnV0ZSBkZWZuIGNhbiBkbyB0aGlzIHN1ZmZpY2llbnRseS4N Cg0KSeKAmW0gbm90IHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgdGhpcy4gIEFyZSB5b3UganVzdCBz YXlpbmcgdGhhdCB0aGUgYmluYXJ5IGRhdGEgdHlwZSB3aWxsIHNwZWNpZnkgdGhhdCBiYXNlNjR1 cmwgaXMgYWx3YXlzIHVzZWQ/ICBPciBhcmUgeW91IHNheWluZyB0aGF0IHRoZSBhdHRyaWJ1dGUg ZGVmaW5pdGlvbnMgaW4gdGhlIHNjaGVtYSB3aWxsIHNvbWVob3cgaW5kaWNhdGUgd2hpY2ggZW5j b2RpbmcgaXMgdXNlZCAoZWl0aGVyIHRocm91Z2ggYSBkaWZmZXJlbnQgdHlwZSBvciBqdXN0IGlu IHRoZSBkZXNjcmlwdGlvbik/DQoNCg0KRnJvbTogUGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMywgMjAxNSAxMDo0MyBBTQ0KVG86 IEtlbGx5IEdyaXp6bGUNCkNjOiBJYW4gR2xhemVyOyBTQ0lNIFdHDQpTdWJqZWN0OiBSZTogW3Nj aW1dIEJhc2U2NCBFbmNvZGluZyBmb3IgQmluYXJ5IEF0dHJpYnV0ZXMNCg0KSldLIGlzIEpTT04g d2ViIGtleS4gVGhleSBhcmUgcGFzc2FibGUgaW4gdXJscy4NCg0KSldLIGlzIHRoZSBuZXcgSlNP TiBlcXVpdmFsZW50IG9mIHg1MDkuDQoNClRoZSBnb29kIG5ld3MgaXMgdGhlc2UgYXJlIGFsbCBq dXN0IHN0cmluZ3MuICBTbyBubyBleHRyYSBjb2RpbmcgdG8gc3VwcG9ydC4gQnV0IHRoZSBjbGll bnQgd2lsbCBuZWVkIHRvIGtub3cgaG93IGl0IGlzIGVuY29kZWQuIEkgcHJvcG9zZSB0aGUgYXR0 cmlidXRlIGRlZm4gY2FuIGRvIHRoaXMgc3VmZmljaWVudGx5Lg0KDQpQaGlsDQoNCk9uIE1hciAz LCAyMDE1LCBhdCAwNzo1MywgS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQu Y29tPG1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+PiB3cm90ZToNCknigJltIGhh dmVu4oCZdCBmb2xsb3dlZCBKV1QvSldLLCBzbyBkb27igJl0IGtub3cgYWxsIG9mIHRoZSBoaXN0 b3J5Lg0KDQpIb3dldmVyLCBiYXNlZCBvbiByZWFkaW5nIFJGQyA0NjQ4LCBpdCBzZWVtcyB0aGF0 IGJhc2U2NHVybCBpcyBwcmltYXJpbHkgdXNlZCBpZiB0aGUgZW5jb2RlZCBkYXRhIHdpbGwgYXBw ZWFyIGluIGEgVVJMIG9yIGZpbGVuYW1lLiAgR2l2ZW4gdGhlIGZhY3QgdGhhdCBpbiBTQ0lNIGJh c2U2NCB3aWxsIGFsd2F5cyBvY2N1ciBpbiByZXF1ZXN0IGFuZCByZXNwb25zZSBib2RpZXMsIEkg ZG9u4oCZdCBrbm93IHRoYXQgd2UgbmVlZCB0byB3b3JyeSBhYm91dCBiYXNlNjR1cmwuDQoNCk9u IHRoZSBvdGhlciBoYW5kLCBpZiBtb3N0IGlkZW50aXR5LXJlbGF0ZWQgc3RhbmRhcmRzIGFyZSB1 c2luZyBiYXNlNjR1cmwsIGl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gZ28gd2l0aCB0aGlzIGZvciBj b25zaXN0ZW5jeS4NCg0KSW4gZWl0aGVyIGNhc2UsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc3Rh bmRhcmRpemUgb24gZWl0aGVyIGJhc2U2NCBvciBiYXNlNjR1cmwgYW5kIG5vdCBhbGxvdyBib3Ro Lg0KDQotLUtlbGx5DQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IE1vbmRheSwgTWFyY2ggMDIsIDIwMTUgMjoy NiBQTQ0KVG86IElhbiBHbGF6ZXINCkNjOiBTQ0lNIFdHDQpTdWJqZWN0OiBSZTogW3NjaW1dIEJh c2U2NCBFbmNvZGluZyBmb3IgQmluYXJ5IEF0dHJpYnV0ZXMNCg0KSSB0aGluayBpdCBzaG91bGQg YmUgb25lIGZvcm0uDQoNCk15IHJlY29tbWVuZGF0aW9uIHdvdWxkIGJlIGJhc2U2NHVybCBmb3Ig bWF4IHV0aWxpdHkuIEVzcGVjaWFsbHkgaWYgd2Ugc3RhcnQgZGVmaW5pbmcgc2NoZW1hIHJlbGF0 ZWQgdG8gSldUIGtleXMgKEpXSykgZnJvbSBPQXV0aCBhbmQgSk9TRS4NCg0KUGhpbA0KDQpPbiBN YXIgMiwgMjAxNSwgYXQgMTI6MDYsIElhbiBHbGF6ZXIgPGlnbGF6ZXJAc2FsZXNmb3JjZS5jb208 bWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20+PiB3cm90ZToNCldvdWxkIHRoaXMgYmUgYmFz ZTY0dXJsICJyZXF1aXJlZCIgb3IgInJlY29tbWVuZGVkIj8NCg0KV291bGQgdGhlIGVuY29kaW5n IHR5cGUgYmUgYSBkZWNsYXJlZCBhdHRyaWJ1dGUgb2YgdGhlIFNQPw0KDQpPbiBNb24sIE1hciAy LCAyMDE1IGF0IDI6MDcgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgd2FzIGxvb2tpbmcgdGhyb3VnaCB0 aGUgc2NoZW1hIGRvY3VtZW50IGFuZCBjbGVhbmluZyB1cCB0aGUgZGF0YSB0eXBlIGNoYXJhY3Rl cmlzdGljcyAoYXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkpLCBJIG5vdGljZSB0aGF0IHRoZSByZWZl cmVuY2UgdG8gWE1MLVNjaGVtYSBpcyB0byB0aGUgT2N0b2JlciAyMDA0IG9uZSBhbmQgbm90IHRo ZSAyMDEyIFhNTCBTY2hlbWEuICBUaGUgSUVURiB3aWxsIGxpa2VseSByZXF1aXJlIHVzIHRvIHJl ZmVyZW5jZSB0aGUgY3VycmVudCBzcGVjLCBzbyBJIHNob3VsZCBwcm9iYWJseSB1cGRhdGUgdGhl IHJlZmVyZW5jZS4NCg0KTG9va2luZyBhdCB0aGUgYmluYXJ5IGF0dHJpYnV0ZSByZXByZXNlbnRh dGlvbiwgSSBhbSB3b25kZXJpbmcgaWYgd2Ugc2hvdWxkIGNoYW5nZSB0aGlzIHRvIHRoZSBjdXJy ZW50IElFVEYgc3BlY2lmaWNhdGlvbiB3aGljaCBpczogUkZDNDY0OCByYXRoZXIgdGhhbiByZWZl cmVuY2UgWE1MLVNjaGVtYSAzLjIuMTYgKG9mIHRoZSAyMDA0IHNjaGVtYSBzcGVjKS4NCg0KRG8g d2Ugd2FudCB0byBmdXJ0aGVyIGNsYXJpZnkgdGhhdCB0aGUgZW5jb2RpbmcgYmU6IGJhc2U2NHVy bD8gICBOb3QgYSBqYXZhc2NyaXB0IGV4cGVydCwgYnV0IHdvbmRlcmluZyBpZiB3ZSBuZWVkIHRv IHVzZSB1cmwgc2FmZSBlbmNvZGluZz8gVGhpcyBtYXkgcmVzdWx0IGluIGEgbm9ybWF0aXZlIGNs YXJpZmljYXRpb24gZm9yIHNvbWUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRl cGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzY2ltIG1haWxpbmcgbGlzdA0Kc2Np bUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2NpbQ0KDQoNCg0KLS0NCklhbiBHbGF6ZXINClNlbmlvciBEaXJlY3Rv ciwgSWRlbnRpdHkNCisxIDIwMiAyNTUgMzE2Ng0KQGlnbGF6ZXI8aHR0cHM6Ly90d2l0dGVyLmNv bS9pZ2xhemVyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQo= --_000_BN1PR04MB392E58EB32CD1CCF1427531E2110BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZndDsNCjwvc3Bhbj5JIHByb3Bvc2UgdGhlIGF0dHJpYnV0ZSBkZWZuIGNhbiBk byB0aGlzIHN1ZmZpY2llbnRseS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJlt IG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHRoaXMuJm5ic3A7IEFyZSB5b3UganVzdCBzYXlp bmcgdGhhdCB0aGUgYmluYXJ5IGRhdGEgdHlwZSB3aWxsIHNwZWNpZnkgdGhhdCBiYXNlNjR1cmwg aXMgYWx3YXlzIHVzZWQ/Jm5ic3A7IE9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIGF0dHJpYnV0 ZSBkZWZpbml0aW9ucyBpbiB0aGUgc2NoZW1hIHdpbGwgc29tZWhvdyBpbmRpY2F0ZSB3aGljaCBl bmNvZGluZyBpcyB1c2VkDQogKGVpdGhlciB0aHJvdWdoIGEgZGlmZmVyZW50IHR5cGUgb3IganVz dCBpbiB0aGUgZGVzY3JpcHRpb24pPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDAzLCAyMDE1IDEwOjQzIEFNPGJyPg0K PGI+VG86PC9iPiBLZWxseSBHcml6emxlPGJyPg0KPGI+Q2M6PC9iPiBJYW4gR2xhemVyOyBTQ0lN IFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gQmFzZTY0IEVuY29kaW5nIGZvciBC aW5hcnkgQXR0cmlidXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5KV0sgaXMgSlNPTiB3ZWIga2V5LiBUaGV5IGFyZSBwYXNzYWJsZSBpbiB1 cmxzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SldLIGlzIHRoZSBuZXcgSlNPTiBlcXVpdmFsZW50IG9mIHg1MDkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBnb29kIG5l d3MgaXMgdGhlc2UgYXJlIGFsbCBqdXN0IHN0cmluZ3MuICZuYnNwO1NvIG5vIGV4dHJhIGNvZGlu ZyB0byBzdXBwb3J0LiBCdXQgdGhlIGNsaWVudCB3aWxsIG5lZWQgdG8ga25vdyBob3cgaXQgaXMg ZW5jb2RlZC4gSSBwcm9wb3NlIHRoZSBhdHRyaWJ1dGUgZGVmbiBjYW4gZG8gdGhpcyBzdWZmaWNp ZW50bHkuICZuYnNwOzxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KT24gTWFyIDMsIDIwMTUsIGF0IDA3OjUzLCBLZWxseSBHcml6emxlICZsdDs8YSBocmVmPSJt YWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIj5rZWxseS5ncml6emxlQHNhaWxwb2lu dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPknigJltIGhhdmVu4oCZdCBmb2xsb3dlZCBKV1QvSldLLCBzbyBkb27igJl0IGtub3cgYWxs IG9mIHRoZSBoaXN0b3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgYmFzZWQgb24gcmVhZGluZyBSRkMg NDY0OCwgaXQgc2VlbXMgdGhhdCBiYXNlNjR1cmwgaXMgcHJpbWFyaWx5IHVzZWQgaWYgdGhlIGVu Y29kZWQgZGF0YSB3aWxsIGFwcGVhciBpbiBhIFVSTCBvciBmaWxlbmFtZS4mbmJzcDsgR2l2ZW4g dGhlIGZhY3QgdGhhdCBpbg0KIFNDSU0gYmFzZTY0IHdpbGwgYWx3YXlzIG9jY3VyIGluIHJlcXVl c3QgYW5kIHJlc3BvbnNlIGJvZGllcywgSSBkb27igJl0IGtub3cgdGhhdCB3ZSBuZWVkIHRvIHdv cnJ5IGFib3V0IGJhc2U2NHVybC4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T24gdGhlIG90aGVyIGhhbmQs IGlmIG1vc3QgaWRlbnRpdHktcmVsYXRlZCBzdGFuZGFyZHMgYXJlIHVzaW5nIGJhc2U2NHVybCwg aXQgbWlnaHQgbWFrZSBzZW5zZSB0byBnbyB3aXRoIHRoaXMgZm9yIGNvbnNpc3RlbmN5Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SW4gZWl0aGVyIGNhc2UsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc3RhbmRhcmRpemUg b24gZWl0aGVyIGJhc2U2NCBvciBiYXNlNjR1cmwgYW5kIG5vdCBhbGxvdyBib3RoLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LS1LZWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gWzxhIGhyZWY9Im1haWx0bzpzY2lt LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJj aCAwMiwgMjAxNSAyOjI2IFBNPGJyPg0KPGI+VG86PC9iPiBJYW4gR2xhemVyPGJyPg0KPGI+Q2M6 PC9iPiBTQ0lNIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gQmFzZTY0IEVuY29k aW5nIGZvciBCaW5hcnkgQXR0cmlidXRlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IHNob3VsZCBiZSBvbmUgZm9ybS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TXkgcmVjb21tZW5kYXRpb24gd291bGQgYmUgYmFzZTY0dXJsIGZvciBtYXggdXRpbGl0eS4gRXNw ZWNpYWxseSBpZiB3ZSBzdGFydCBkZWZpbmluZyBzY2hlbWEgcmVsYXRlZCB0byBKV1Qga2V5cyAo SldLKSBmcm9tIE9BdXRoIGFuZCBKT1NFLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpPbiBNYXIgMiwgMjAxNSwgYXQgMTI6MDYsIElhbiBHbGF6ZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzppZ2xhemVyQHNhbGVzZm9yY2UuY29tIj5pZ2xhemVyQHNhbGVzZm9yY2UuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB0aGlzIGJlIGJhc2U2NHVybCAmcXVvdDtyZXF1aXJl ZCZxdW90OyBvciAmcXVvdDtyZWNvbW1lbmRlZCZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHRoZSBlbmNvZGluZyB0eXBlIGJlIGEgZGVj bGFyZWQgYXR0cmlidXRlIG9mIHRoZSBTUD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMiwgMjAxNSBhdCAyOjA3IFBNLCBQ aGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBsb29raW5nIHRocm91Z2gg dGhlIHNjaGVtYSBkb2N1bWVudCBhbmQgY2xlYW5pbmcgdXAgdGhlIGRhdGEgdHlwZSBjaGFyYWN0 ZXJpc3RpY3MgKGFzIGRpc2N1c3NlZCBwcmV2aW91c2x5KSwgSSBub3RpY2UgdGhhdCB0aGUgcmVm ZXJlbmNlIHRvIFhNTC1TY2hlbWEgaXMgdG8gdGhlIE9jdG9iZXIgMjAwNCBvbmUgYW5kIG5vdCB0 aGUgMjAxMiBYTUwgU2NoZW1hLiZuYnNwOyBUaGUgSUVURiB3aWxsIGxpa2VseSByZXF1aXJlDQog dXMgdG8gcmVmZXJlbmNlIHRoZSBjdXJyZW50IHNwZWMsIHNvIEkgc2hvdWxkIHByb2JhYmx5IHVw ZGF0ZSB0aGUgcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TG9va2luZyBhdCB0aGUgYmluYXJ5IGF0dHJpYnV0ZSByZXByZXNlbnRhdGlvbiwg SSBhbSB3b25kZXJpbmcgaWYgd2Ugc2hvdWxkIGNoYW5nZSB0aGlzIHRvIHRoZSBjdXJyZW50IElF VEYgc3BlY2lmaWNhdGlvbiB3aGljaCBpczogUkZDNDY0OCByYXRoZXIgdGhhbiByZWZlcmVuY2Ug WE1MLVNjaGVtYSAzLjIuMTYgKG9mIHRoZSAyMDA0IHNjaGVtYSBzcGVjKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8gd2Ugd2FudCB0byBm dXJ0aGVyIGNsYXJpZnkgdGhhdCB0aGUgZW5jb2RpbmcgYmU6IGJhc2U2NHVybD8gJm5ic3A7IE5v dCBhIGphdmFzY3JpcHQgZXhwZXJ0LCBidXQgd29uZGVyaW5nIGlmIHdlIG5lZWQgdG8gdXNlIHVy bCBzYWZlIGVuY29kaW5nPyBUaGlzIG1heSByZXN1bHQgaW4gYSBub3JtYXRpdmUgY2xhcmlmaWNh dGlvbiBmb3Igc29tZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGhpbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz Y2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuIEdsYXplcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VuaW9yIERpcmVj dG9yLCBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JiM0MzsxIDIwMiAyNTUgMzE2NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9pZ2xh emVyIiB0YXJnZXQ9Il9ibGFuayI+QGlnbGF6ZXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB392E58EB32CD1CCF1427531E2110BN1PR04MB392namprd_-- From nobody Tue Mar 3 09:18:22 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97C21A0366 for ; Tue, 3 Mar 2015 09:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vq0qP-mTMjmj for ; Tue, 3 Mar 2015 09:18:17 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C7B1A0266 for ; Tue, 3 Mar 2015 09:18:17 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t23HIGnI019802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 17:18:16 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t23HIFds022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2015 17:18:16 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t23HIFtK002951; Tue, 3 Mar 2015 17:18:15 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Mar 2015 09:18:15 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-EB6306EC-FC4A-413A-B617-E950DBFADDC7 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Mar 2015 09:18:15 -0800 Content-Transfer-Encoding: 7bit Message-Id: <1C9F4101-0133-446E-9008-CD11CCB2C0EA@oracle.com> References: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> To: Kelly Grizzle X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:18:20 -0000 --Apple-Mail-EB6306EC-FC4A-413A-B617-E950DBFADDC7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No. Base64 is proposed as the default because we wouldn't pass by url.=20 However some things we will want to store must be url encoded by their own s= pecification such as json keys. =20 We could make binary a complex type where encoding can be specified, but it o= nly make sense if you expected the encoding to dynamically change. That isn'= t the case here. Eg A JWK must always be base64url.=20 AFAIK x509 would always be base64.=20 Phil > On Mar 3, 2015, at 08:54, Kelly Grizzle wrot= e: >=20 > > I propose the attribute defn can do this sufficiently. =20 > =20 > I=E2=80=99m not sure that I understand this. Are you just saying that the= binary data type will specify that base64url is always used? Or are you sa= ying that the attribute definitions in the schema will somehow indicate whic= h encoding is used (either through a different type or just in the descripti= on)? > =20 > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, March 03, 2015 10:43 AM > To: Kelly Grizzle > Cc: Ian Glazer; SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > JWK is JSON web key. They are passable in urls. =20 > =20 > JWK is the new JSON equivalent of x509. > =20 > The good news is these are all just strings. So no extra coding to suppor= t. But the client will need to know how it is encoded. I propose the attribu= te defn can do this sufficiently. =20 >=20 > Phil >=20 > On Mar 3, 2015, at 07:53, Kelly Grizzle wrot= e: >=20 > I=E2=80=99m haven=E2=80=99t followed JWT/JWK, so don=E2=80=99t know all of= the history. > =20 > However, based on reading RFC 4648, it seems that base64url is primarily u= sed if the encoded data will appear in a URL or filename. Given the fact th= at in SCIM base64 will always occur in request and response bodies, I don=E2= =80=99t know that we need to worry about base64url.=20 > =20 > On the other hand, if most identity-related standards are using base64url,= it might make sense to go with this for consistency. > =20 > In either case, I agree that we should standardize on either base64 or bas= e64url and not allow both. > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Monday, March 02, 2015 2:26 PM > To: Ian Glazer > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > I think it should be one form.=20 > =20 > My recommendation would be base64url for max utility. Especially if we sta= rt defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >=20 > Phil >=20 > On Mar 2, 2015, at 12:06, Ian Glazer wrote: >=20 > Would this be base64url "required" or "recommended"? > =20 > Would the encoding type be a declared attribute of the SP? > =20 > On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > =20 > I was looking through the schema document and cleaning up the data type ch= aracteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wil= l likely require us to reference the current spec, so I should probably upda= te the reference. > =20 > Looking at the binary attribute representation, I am wondering if we shoul= d change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). > =20 > Do we want to further clarify that the encoding be: base64url? Not a jav= ascript expert, but wondering if we need to use url safe encoding? This may r= esult in a normative clarification for some. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-EB6306EC-FC4A-413A-B617-E950DBFADDC7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No. Base64 is proposed as the default b= ecause we wouldn't pass by url. 

However some t= hings we will want to store must be url encoded by their own specification s= uch as json keys.  

We could make binary a com= plex type where encoding can be specified, but it only make sense if you exp= ected the encoding to dynamically change. That isn't the case here.  Eg= A JWK must always be base64url. 

AFAIK x509 w= ould always be base64. 

Phil

On Mar 3, 2015= , at 08:54, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

> I propose the attribute defn can do this sufficiently.  

 

I=E2=80=99m not sure that I understand this.  Ar= e you just saying that the binary data type will specify that base64url is a= lways used?  Or are you saying that the attribute definitions in the sc= hema will somehow indicate which encoding is used (either through a different type or just in the description)?

 

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Tuesday, March 03, 2015 10:43 AM
To: Kelly Grizzle
Cc: Ian Glazer; SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes<= /span>

 

JWK is JSON web key. They are passable in urls.  = ;

 

JWK is the new JSON equivalent of x509.

 

The good news is these are all just strings.  So= no extra coding to support. But the client will need to know how it is enco= ded. I propose the attribute defn can do this sufficiently.  

Phil


On Mar 3, 2015, at 07:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I=E2=80=99m haven=E2=80=99t= followed JWT/JWK, so don=E2=80=99t know all of the history.

 

However, based on reading R= FC 4648, it seems that base64url is primarily used if the encoded data will a= ppear in a URL or filename.  Given the fact that in SCIM base64 will always occur in request and response bodies, I don=E2=80=99= t know that we need to worry about base64url. 

 

On the other hand, if most i= dentity-related standards are using base64url, it might make sense to go wit= h this for consistency.

 

In either case, I agree tha= t we should standardize on either base64 or base64url and not allow both.

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, March 02, 2015 2:26 PM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

I think it should be one form. 

 

My recommendation would be base64url for max utility.= Especially if we start defining schema related to JWT keys (JWK) from OAuth= and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or "recommended"?<= o:p>

 

Would the encoding type be a declared attribute of th= e SP?

 

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <phil.hunt@oracle.com&= gt; wrote:

 

I was looking through the schema document and cleanin= g up the data type characteristics (as discussed previously), I notice that t= he reference to XML-Schema is to the October 2004 one and not the 2012 XML S= chema.  The IETF will likely require us to reference the current spec, so I should probably update the reference= .

 

Looking at the binary attribute representation, I am w= ondering if we should change this to the current IETF specification which is= : RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).=

 

Do we want to further clarify that the encoding be: b= ase64url?   Not a javascript expert, but wondering if we need to use ur= l safe encoding? This may result in a normative clarification for some.=

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

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

= --Apple-Mail-EB6306EC-FC4A-413A-B617-E950DBFADDC7-- From nobody Tue Mar 3 09:39:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F081AC420 for ; Tue, 3 Mar 2015 09:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 HB5LwiJHr3Wv for ; Tue, 3 Mar 2015 09:38:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A481AC407 for ; Tue, 3 Mar 2015 09:38:57 -0800 (PST) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 17:38:56 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.199]) with mapi id 15.01.0099.004; Tue, 3 Mar 2015 17:38:56 +0000 From: Kelly Grizzle To: Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwdSsyOqgO/b0CsgI/19U41Mp0JnqMAgAAFNYCAAUUCEIAADz6AgAACViCAAAdrgIAAAnIQ Date: Tue, 3 Mar 2015 17:38:55 +0000 Message-ID: References: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> <1C9F4101-0133-446E-9008-CD11CCB2C0EA@oracle.com> In-Reply-To: <1C9F4101-0133-446E-9008-CD11CCB2C0EA@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 04BFB7C30094C604BFB910 x-originating-ip: [97.79.140.10] authentication-results: oracle.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB392; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR04MB392; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB392; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(2656002)(122556002)(106116001)(87936001)(74316001)(16236675004)(19625215002)(19609705001)(19300405004)(16601075003)(46102003)(40100003)(54356999)(66066001)(19580405001)(19580395003)(76176999)(62966003)(77156002)(76576001)(102836002)(2900100001)(2950100001)(110136001)(92566002)(33656002)(15975445007)(50986999)(86362001)(19617315012)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB392; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN1PR04MB39200BE98F928C214563846E2110BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 17:38:56.0723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB392 Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:39:01 -0000 --_000_BN1PR04MB39200BE98F928C214563846E2110BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWgg4oCmIEkgdW5kZXJzdGFuZCB3aGF0IHlvdeKAmXJlIHNheWluZyBub3cuICBUaGF0IG1ha2Vz IHNlbnNlIHRvIG1lLg0KDQpTbyB0aGUgdHlwZSB3b3VsZCBiZSDigJxiaW5hcnnigJ0gd2hpY2gg d291bGQgdXN1YWxseSBiZSBiYXNlNjQsIGJ1dCBjb3VsZCBvcHRpb25hbGx5IGJlIGJhc2U2NHVy bCBpZiB0aGUgYXR0cmlidXRlIGRlZmluaXRpb24gc3BlY2lmaWVzIHRoaXM/DQoNCg0KRnJvbTog UGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBN YXJjaCAwMywgMjAxNSAxMToxOCBBTQ0KVG86IEtlbGx5IEdyaXp6bGUNCkNjOiBJYW4gR2xhemVy OyBTQ0lNIFdHDQpTdWJqZWN0OiBSZTogW3NjaW1dIEJhc2U2NCBFbmNvZGluZyBmb3IgQmluYXJ5 IEF0dHJpYnV0ZXMNCg0KTm8uIEJhc2U2NCBpcyBwcm9wb3NlZCBhcyB0aGUgZGVmYXVsdCBiZWNh dXNlIHdlIHdvdWxkbid0IHBhc3MgYnkgdXJsLg0KDQpIb3dldmVyIHNvbWUgdGhpbmdzIHdlIHdp bGwgd2FudCB0byBzdG9yZSBtdXN0IGJlIHVybCBlbmNvZGVkIGJ5IHRoZWlyIG93biBzcGVjaWZp Y2F0aW9uIHN1Y2ggYXMganNvbiBrZXlzLg0KDQpXZSBjb3VsZCBtYWtlIGJpbmFyeSBhIGNvbXBs ZXggdHlwZSB3aGVyZSBlbmNvZGluZyBjYW4gYmUgc3BlY2lmaWVkLCBidXQgaXQgb25seSBtYWtl IHNlbnNlIGlmIHlvdSBleHBlY3RlZCB0aGUgZW5jb2RpbmcgdG8gZHluYW1pY2FsbHkgY2hhbmdl LiBUaGF0IGlzbid0IHRoZSBjYXNlIGhlcmUuICBFZyBBIEpXSyBtdXN0IGFsd2F5cyBiZSBiYXNl NjR1cmwuDQoNCkFGQUlLIHg1MDkgd291bGQgYWx3YXlzIGJlIGJhc2U2NC4NCg0KUGhpbA0KDQpP biBNYXIgMywgMjAxNSwgYXQgMDg6NTQsIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVAc2Fp bHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6DQo+ IEkgcHJvcG9zZSB0aGUgYXR0cmlidXRlIGRlZm4gY2FuIGRvIHRoaXMgc3VmZmljaWVudGx5Lg0K DQpJ4oCZbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB0aGlzLiAgQXJlIHlvdSBqdXN0IHNh eWluZyB0aGF0IHRoZSBiaW5hcnkgZGF0YSB0eXBlIHdpbGwgc3BlY2lmeSB0aGF0IGJhc2U2NHVy bCBpcyBhbHdheXMgdXNlZD8gIE9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIGF0dHJpYnV0ZSBk ZWZpbml0aW9ucyBpbiB0aGUgc2NoZW1hIHdpbGwgc29tZWhvdyBpbmRpY2F0ZSB3aGljaCBlbmNv ZGluZyBpcyB1c2VkIChlaXRoZXIgdGhyb3VnaCBhIGRpZmZlcmVudCB0eXBlIG9yIGp1c3QgaW4g dGhlIGRlc2NyaXB0aW9uKT8NCg0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDAzLCAyMDE1IDEwOjQzIEFNDQpUbzog S2VsbHkgR3JpenpsZQ0KQ2M6IElhbiBHbGF6ZXI7IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBbc2Np bV0gQmFzZTY0IEVuY29kaW5nIGZvciBCaW5hcnkgQXR0cmlidXRlcw0KDQpKV0sgaXMgSlNPTiB3 ZWIga2V5LiBUaGV5IGFyZSBwYXNzYWJsZSBpbiB1cmxzLg0KDQpKV0sgaXMgdGhlIG5ldyBKU09O IGVxdWl2YWxlbnQgb2YgeDUwOS4NCg0KVGhlIGdvb2QgbmV3cyBpcyB0aGVzZSBhcmUgYWxsIGp1 c3Qgc3RyaW5ncy4gIFNvIG5vIGV4dHJhIGNvZGluZyB0byBzdXBwb3J0LiBCdXQgdGhlIGNsaWVu dCB3aWxsIG5lZWQgdG8ga25vdyBob3cgaXQgaXMgZW5jb2RlZC4gSSBwcm9wb3NlIHRoZSBhdHRy aWJ1dGUgZGVmbiBjYW4gZG8gdGhpcyBzdWZmaWNpZW50bHkuDQoNClBoaWwNCg0KT24gTWFyIDMs IDIwMTUsIGF0IDA3OjUzLCBLZWxseSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxwb2ludC5j b208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+IHdyb3RlOg0KSeKAmW0gaGF2 ZW7igJl0IGZvbGxvd2VkIEpXVC9KV0ssIHNvIGRvbuKAmXQga25vdyBhbGwgb2YgdGhlIGhpc3Rv cnkuDQoNCkhvd2V2ZXIsIGJhc2VkIG9uIHJlYWRpbmcgUkZDIDQ2NDgsIGl0IHNlZW1zIHRoYXQg YmFzZTY0dXJsIGlzIHByaW1hcmlseSB1c2VkIGlmIHRoZSBlbmNvZGVkIGRhdGEgd2lsbCBhcHBl YXIgaW4gYSBVUkwgb3IgZmlsZW5hbWUuICBHaXZlbiB0aGUgZmFjdCB0aGF0IGluIFNDSU0gYmFz ZTY0IHdpbGwgYWx3YXlzIG9jY3VyIGluIHJlcXVlc3QgYW5kIHJlc3BvbnNlIGJvZGllcywgSSBk b27igJl0IGtub3cgdGhhdCB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0IGJhc2U2NHVybC4NCg0KT24g dGhlIG90aGVyIGhhbmQsIGlmIG1vc3QgaWRlbnRpdHktcmVsYXRlZCBzdGFuZGFyZHMgYXJlIHVz aW5nIGJhc2U2NHVybCwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBnbyB3aXRoIHRoaXMgZm9yIGNv bnNpc3RlbmN5Lg0KDQpJbiBlaXRoZXIgY2FzZSwgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBzdGFu ZGFyZGl6ZSBvbiBlaXRoZXIgYmFzZTY0IG9yIGJhc2U2NHVybCBhbmQgbm90IGFsbG93IGJvdGgu DQoNCi0tS2VsbHkNCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogTW9uZGF5LCBNYXJjaCAwMiwgMjAxNSAyOjI2 IFBNDQpUbzogSWFuIEdsYXplcg0KQ2M6IFNDSU0gV0cNClN1YmplY3Q6IFJlOiBbc2NpbV0gQmFz ZTY0IEVuY29kaW5nIGZvciBCaW5hcnkgQXR0cmlidXRlcw0KDQpJIHRoaW5rIGl0IHNob3VsZCBi ZSBvbmUgZm9ybS4NCg0KTXkgcmVjb21tZW5kYXRpb24gd291bGQgYmUgYmFzZTY0dXJsIGZvciBt YXggdXRpbGl0eS4gRXNwZWNpYWxseSBpZiB3ZSBzdGFydCBkZWZpbmluZyBzY2hlbWEgcmVsYXRl ZCB0byBKV1Qga2V5cyAoSldLKSBmcm9tIE9BdXRoIGFuZCBKT1NFLg0KDQpQaGlsDQoNCk9uIE1h ciAyLCAyMDE1LCBhdCAxMjowNiwgSWFuIEdsYXplciA8aWdsYXplckBzYWxlc2ZvcmNlLmNvbTxt YWlsdG86aWdsYXplckBzYWxlc2ZvcmNlLmNvbT4+IHdyb3RlOg0KV291bGQgdGhpcyBiZSBiYXNl NjR1cmwgInJlcXVpcmVkIiBvciAicmVjb21tZW5kZWQiPw0KDQpXb3VsZCB0aGUgZW5jb2Rpbmcg dHlwZSBiZSBhIGRlY2xhcmVkIGF0dHJpYnV0ZSBvZiB0aGUgU1A/DQoNCk9uIE1vbiwgTWFyIDIs IDIwMTUgYXQgMjowNyBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSSB3YXMgbG9va2luZyB0aHJvdWdoIHRo ZSBzY2hlbWEgZG9jdW1lbnQgYW5kIGNsZWFuaW5nIHVwIHRoZSBkYXRhIHR5cGUgY2hhcmFjdGVy aXN0aWNzIChhcyBkaXNjdXNzZWQgcHJldmlvdXNseSksIEkgbm90aWNlIHRoYXQgdGhlIHJlZmVy ZW5jZSB0byBYTUwtU2NoZW1hIGlzIHRvIHRoZSBPY3RvYmVyIDIwMDQgb25lIGFuZCBub3QgdGhl IDIwMTIgWE1MIFNjaGVtYS4gIFRoZSBJRVRGIHdpbGwgbGlrZWx5IHJlcXVpcmUgdXMgdG8gcmVm ZXJlbmNlIHRoZSBjdXJyZW50IHNwZWMsIHNvIEkgc2hvdWxkIHByb2JhYmx5IHVwZGF0ZSB0aGUg cmVmZXJlbmNlLg0KDQpMb29raW5nIGF0IHRoZSBiaW5hcnkgYXR0cmlidXRlIHJlcHJlc2VudGF0 aW9uLCBJIGFtIHdvbmRlcmluZyBpZiB3ZSBzaG91bGQgY2hhbmdlIHRoaXMgdG8gdGhlIGN1cnJl bnQgSUVURiBzcGVjaWZpY2F0aW9uIHdoaWNoIGlzOiBSRkM0NjQ4IHJhdGhlciB0aGFuIHJlZmVy ZW5jZSBYTUwtU2NoZW1hIDMuMi4xNiAob2YgdGhlIDIwMDQgc2NoZW1hIHNwZWMpLg0KDQpEbyB3 ZSB3YW50IHRvIGZ1cnRoZXIgY2xhcmlmeSB0aGF0IHRoZSBlbmNvZGluZyBiZTogYmFzZTY0dXJs PyAgIE5vdCBhIGphdmFzY3JpcHQgZXhwZXJ0LCBidXQgd29uZGVyaW5nIGlmIHdlIG5lZWQgdG8g dXNlIHVybCBzYWZlIGVuY29kaW5nPyBUaGlzIG1heSByZXN1bHQgaW4gYSBub3JtYXRpdmUgY2xh cmlmaWNhdGlvbiBmb3Igc29tZS4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVw ZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2lt QGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zY2ltDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERpcmVjdG9y LCBJZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3aXR0ZXIuY29t L2lnbGF6ZXI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg== --_000_BN1PR04MB39200BE98F928C214563846E2110BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5B aCDigKYgSSB1bmRlcnN0YW5kIHdoYXQgeW914oCZcmUgc2F5aW5nIG5vdy4mbmJzcDsgVGhhdCBt YWtlcyBzZW5zZSB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHRoZSB0eXBlIHdvdWxkIGJlIOKAnGJpbmFy eeKAnSB3aGljaCB3b3VsZCB1c3VhbGx5IGJlIGJhc2U2NCwgYnV0IGNvdWxkIG9wdGlvbmFsbHkg YmUgYmFzZTY0dXJsIGlmIHRoZSBhdHRyaWJ1dGUgZGVmaW5pdGlvbiBzcGVjaWZpZXMgdGhpcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g UGhpbCBIdW50IFttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgTWFyY2ggMDMsIDIwMTUgMTE6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IEtlbGx5 IEdyaXp6bGU8YnI+DQo8Yj5DYzo8L2I+IElhbiBHbGF6ZXI7IFNDSU0gV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzY2ltXSBCYXNlNjQgRW5jb2RpbmcgZm9yIEJpbmFyeSBBdHRyaWJ1dGVz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5v LiBCYXNlNjQgaXMgcHJvcG9zZWQgYXMgdGhlIGRlZmF1bHQgYmVjYXVzZSB3ZSB3b3VsZG4ndCBw YXNzIGJ5IHVybC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SG93ZXZlciBzb21lIHRoaW5ncyB3ZSB3aWxsIHdhbnQgdG8gc3RvcmUg bXVzdCBiZSB1cmwgZW5jb2RlZCBieSB0aGVpciBvd24gc3BlY2lmaWNhdGlvbiBzdWNoIGFzIGpz b24ga2V5cy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIGNvdWxkIG1ha2UgYmluYXJ5IGEgY29tcGxleCB0eXBlIHdoZXJlIGVu Y29kaW5nIGNhbiBiZSBzcGVjaWZpZWQsIGJ1dCBpdCBvbmx5IG1ha2Ugc2Vuc2UgaWYgeW91IGV4 cGVjdGVkIHRoZSBlbmNvZGluZyB0byBkeW5hbWljYWxseSBjaGFuZ2UuIFRoYXQgaXNuJ3QgdGhl IGNhc2UgaGVyZS4gJm5ic3A7RWcgQSBKV0sgbXVzdCBhbHdheXMgYmUgYmFzZTY0dXJsLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B RkFJSyB4NTA5IHdvdWxkIGFsd2F5cyBiZSBiYXNlNjQuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpQaGlsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAzLCAyMDE1LCBhdCAwODo1NCwgS2VsbHkgR3Jpenps ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+a2VsbHku Z3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7DQo8L3NwYW4+SSBwcm9wb3NlIHRoZSBhdHRyaWJ1dGUg ZGVmbiBjYW4gZG8gdGhpcyBzdWZmaWNpZW50bHkuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5J4oCZbSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB0aGlzLiZuYnNwOyBBcmUgeW91 IGp1c3Qgc2F5aW5nIHRoYXQgdGhlIGJpbmFyeSBkYXRhIHR5cGUgd2lsbCBzcGVjaWZ5IHRoYXQg YmFzZTY0dXJsIGlzIGFsd2F5cyB1c2VkPyZuYnNwOyBPciBhcmUgeW91IHNheWluZyB0aGF0IHRo ZSBhdHRyaWJ1dGUgZGVmaW5pdGlvbnMgaW4gdGhlIHNjaGVtYSB3aWxsIHNvbWVob3cgaW5kaWNh dGUgd2hpY2ggZW5jb2RpbmcgaXMgdXNlZA0KIChlaXRoZXIgdGhyb3VnaCBhIGRpZmZlcmVudCB0 eXBlIG9yIGp1c3QgaW4gdGhlIGRlc2NyaXB0aW9uKT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBQaGlsIEh1bnQgWzxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSI+bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAwMywgMjAxNSAxMDo0MyBBTTxicj4NCjxiPlRv OjwvYj4gS2VsbHkgR3JpenpsZTxicj4NCjxiPkNjOjwvYj4gSWFuIEdsYXplcjsgU0NJTSBXRzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIEJhc2U2NCBFbmNvZGluZyBmb3IgQmluYXJ5 IEF0dHJpYnV0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SldLIGlzIEpTT04gd2ViIGtleS4gVGhleSBhcmUgcGFzc2FibGUgaW4gdXJscy4g Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkpXSyBpcyB0aGUgbmV3IEpTT04gZXF1aXZhbGVudCBvZiB4NTA5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ29vZCBuZXdzIGlz IHRoZXNlIGFyZSBhbGwganVzdCBzdHJpbmdzLiAmbmJzcDtTbyBubyBleHRyYSBjb2RpbmcgdG8g c3VwcG9ydC4gQnV0IHRoZSBjbGllbnQgd2lsbCBuZWVkIHRvIGtub3cgaG93IGl0IGlzIGVuY29k ZWQuIEkgcHJvcG9zZSB0aGUgYXR0cmlidXRlIGRlZm4gY2FuIGRvIHRoaXMgc3VmZmljaWVudGx5 LiAmbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9u IE1hciAzLCAyMDE1LCBhdCAwNzo1MywgS2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J 4oCZbSBoYXZlbuKAmXQgZm9sbG93ZWQgSldUL0pXSywgc28gZG9u4oCZdCBrbm93IGFsbCBvZiB0 aGUgaGlzdG9yeS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGJhc2VkIG9uIHJlYWRpbmcgUkZDIDQ2NDgs IGl0IHNlZW1zIHRoYXQgYmFzZTY0dXJsIGlzIHByaW1hcmlseSB1c2VkIGlmIHRoZSBlbmNvZGVk IGRhdGEgd2lsbCBhcHBlYXIgaW4gYSBVUkwgb3IgZmlsZW5hbWUuJm5ic3A7IEdpdmVuIHRoZSBm YWN0IHRoYXQgaW4NCiBTQ0lNIGJhc2U2NCB3aWxsIGFsd2F5cyBvY2N1ciBpbiByZXF1ZXN0IGFu ZCByZXNwb25zZSBib2RpZXMsIEkgZG9u4oCZdCBrbm93IHRoYXQgd2UgbmVlZCB0byB3b3JyeSBh Ym91dCBiYXNlNjR1cmwuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uIHRoZSBvdGhlciBoYW5kLCBpZiBt b3N0IGlkZW50aXR5LXJlbGF0ZWQgc3RhbmRhcmRzIGFyZSB1c2luZyBiYXNlNjR1cmwsIGl0IG1p Z2h0IG1ha2Ugc2Vuc2UgdG8gZ28gd2l0aCB0aGlzIGZvciBjb25zaXN0ZW5jeS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkluIGVpdGhlciBjYXNlLCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIHN0YW5kYXJkaXplIG9uIGVp dGhlciBiYXNlNjQgb3IgYmFzZTY0dXJsIGFuZCBub3QgYWxsb3cgYm90aC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0t S2VsbHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzY2ltIFs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJl aGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMDIs IDIwMTUgMjoyNiBQTTxicj4NCjxiPlRvOjwvYj4gSWFuIEdsYXplcjxicj4NCjxiPkNjOjwvYj4g U0NJTSBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIEJhc2U2NCBFbmNvZGluZyBm b3IgQmluYXJ5IEF0dHJpYnV0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBzaG91bGQgYmUgb25lIGZvcm0uJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHJl Y29tbWVuZGF0aW9uIHdvdWxkIGJlIGJhc2U2NHVybCBmb3IgbWF4IHV0aWxpdHkuIEVzcGVjaWFs bHkgaWYgd2Ugc3RhcnQgZGVmaW5pbmcgc2NoZW1hIHJlbGF0ZWQgdG8gSldUIGtleXMgKEpXSykg ZnJvbSBPQXV0aCBhbmQgSk9TRS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClBoaWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gTWFyIDIsIDIwMTUsIGF0IDEyOjA2LCBJYW4gR2xhemVyICZsdDs8YSBocmVmPSJt YWlsdG86aWdsYXplckBzYWxlc2ZvcmNlLmNvbSI+aWdsYXplckBzYWxlc2ZvcmNlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V291bGQgdGhpcyBiZSBiYXNlNjR1cmwgJnF1b3Q7cmVxdWlyZWQmcXVv dDsgb3IgJnF1b3Q7cmVjb21tZW5kZWQmcXVvdDs/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB0aGUgZW5jb2RpbmcgdHlwZSBiZSBhIGRlY2xhcmVk IGF0dHJpYnV0ZSBvZiB0aGUgU1A/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDIsIDIwMTUgYXQgMjowNyBQTSwgUGhpbCBI dW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgbG9va2luZyB0aHJvdWdoIHRoZSBz Y2hlbWEgZG9jdW1lbnQgYW5kIGNsZWFuaW5nIHVwIHRoZSBkYXRhIHR5cGUgY2hhcmFjdGVyaXN0 aWNzIChhcyBkaXNjdXNzZWQgcHJldmlvdXNseSksIEkgbm90aWNlIHRoYXQgdGhlIHJlZmVyZW5j ZSB0byBYTUwtU2NoZW1hIGlzIHRvIHRoZSBPY3RvYmVyIDIwMDQgb25lIGFuZCBub3QgdGhlIDIw MTIgWE1MIFNjaGVtYS4mbmJzcDsgVGhlIElFVEYgd2lsbCBsaWtlbHkgcmVxdWlyZQ0KIHVzIHRv IHJlZmVyZW5jZSB0aGUgY3VycmVudCBzcGVjLCBzbyBJIHNob3VsZCBwcm9iYWJseSB1cGRhdGUg dGhlIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkxvb2tpbmcgYXQgdGhlIGJpbmFyeSBhdHRyaWJ1dGUgcmVwcmVzZW50YXRpb24sIEkgYW0g d29uZGVyaW5nIGlmIHdlIHNob3VsZCBjaGFuZ2UgdGhpcyB0byB0aGUgY3VycmVudCBJRVRGIHNw ZWNpZmljYXRpb24gd2hpY2ggaXM6IFJGQzQ2NDggcmF0aGVyIHRoYW4gcmVmZXJlbmNlIFhNTC1T Y2hlbWEgMy4yLjE2IChvZiB0aGUgMjAwNCBzY2hlbWEgc3BlYykuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHdlIHdhbnQgdG8gZnVydGhl ciBjbGFyaWZ5IHRoYXQgdGhlIGVuY29kaW5nIGJlOiBiYXNlNjR1cmw/ICZuYnNwOyBOb3QgYSBq YXZhc2NyaXB0IGV4cGVydCwgYnV0IHdvbmRlcmluZyBpZiB3ZSBuZWVkIHRvIHVzZSB1cmwgc2Fm ZSBlbmNvZGluZz8gVGhpcyBtYXkgcmVzdWx0IGluIGEgbm9ybWF0aXZlIGNsYXJpZmljYXRpb24g Zm9yIHNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2Js YW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklhbiBHbGF6ZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmlvciBEaXJlY3Rvciwg SWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiYjNDM7MSAyMDIgMjU1IDMxNjY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplciIg dGFyZ2V0PSJfYmxhbmsiPkBpZ2xhemVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BN1PR04MB39200BE98F928C214563846E2110BN1PR04MB392namprd_-- From nobody Tue Mar 3 09:41:45 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7469A1A1A22 for ; Tue, 3 Mar 2015 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 tPj-83JmfihE for ; Tue, 3 Mar 2015 09:41:41 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7C61A036E for ; Tue, 3 Mar 2015 09:41:40 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t23Hfd1V013788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 17:41:39 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t23Hfc2S026085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 17:41:39 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t23Hfcxt028158; Tue, 3 Mar 2015 17:41:38 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Mar 2015 09:41:33 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-887DFA3B-6E44-4638-9DFC-C5F9B4D61005 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Mar 2015 09:41:33 -0800 Content-Transfer-Encoding: 7bit Message-Id: <14379070-169C-4114-B6F2-C6B885D4D8C8@oracle.com> References: <694CD471-9C1B-4B3B-92FD-2C7BC15D9418@oracle.com> <1C9F4101-0133-446E-9008-CD11CCB2C0EA@oracle.com> To: Kelly Grizzle X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:41:43 -0000 --Apple-Mail-887DFA3B-6E44-4638-9DFC-C5F9B4D61005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes. =F0=9F=98=84 Phil > On Mar 3, 2015, at 09:38, Kelly Grizzle wrot= e: >=20 > Ah =E2=80=A6 I understand what you=E2=80=99re saying now. That makes sens= e to me. > =20 > So the type would be =E2=80=9Cbinary=E2=80=9D which would usually be base6= 4, but could optionally be base64url if the attribute definition specifies t= his? > =20 > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, March 03, 2015 11:18 AM > To: Kelly Grizzle > Cc: Ian Glazer; SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > No. Base64 is proposed as the default because we wouldn't pass by url.=20 > =20 > However some things we will want to store must be url encoded by their own= specification such as json keys. =20 > =20 > We could make binary a complex type where encoding can be specified, but i= t only make sense if you expected the encoding to dynamically change. That i= sn't the case here. Eg A JWK must always be base64url.=20 > =20 > AFAIK x509 would always be base64.=20 >=20 > Phil >=20 > On Mar 3, 2015, at 08:54, Kelly Grizzle wrot= e: >=20 > > I propose the attribute defn can do this sufficiently. =20 > =20 > I=E2=80=99m not sure that I understand this. Are you just saying that the= binary data type will specify that base64url is always used? Or are you sa= ying that the attribute definitions in the schema will somehow indicate whic= h encoding is used (either through a different type or just in the descripti= on)? > =20 > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, March 03, 2015 10:43 AM > To: Kelly Grizzle > Cc: Ian Glazer; SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > JWK is JSON web key. They are passable in urls. =20 > =20 > JWK is the new JSON equivalent of x509. > =20 > The good news is these are all just strings. So no extra coding to suppor= t. But the client will need to know how it is encoded. I propose the attribu= te defn can do this sufficiently. =20 >=20 > Phil >=20 > On Mar 3, 2015, at 07:53, Kelly Grizzle wrot= e: >=20 > I=E2=80=99m haven=E2=80=99t followed JWT/JWK, so don=E2=80=99t know all of= the history. > =20 > However, based on reading RFC 4648, it seems that base64url is primarily u= sed if the encoded data will appear in a URL or filename. Given the fact th= at in SCIM base64 will always occur in request and response bodies, I don=E2= =80=99t know that we need to worry about base64url.=20 > =20 > On the other hand, if most identity-related standards are using base64url,= it might make sense to go with this for consistency. > =20 > In either case, I agree that we should standardize on either base64 or bas= e64url and not allow both. > =20 > --Kelly > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Monday, March 02, 2015 2:26 PM > To: Ian Glazer > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > I think it should be one form.=20 > =20 > My recommendation would be base64url for max utility. Especially if we sta= rt defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >=20 > Phil >=20 > On Mar 2, 2015, at 12:06, Ian Glazer wrote: >=20 > Would this be base64url "required" or "recommended"? > =20 > Would the encoding type be a declared attribute of the SP? > =20 > On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > =20 > I was looking through the schema document and cleaning up the data type ch= aracteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wil= l likely require us to reference the current spec, so I should probably upda= te the reference. > =20 > Looking at the binary attribute representation, I am wondering if we shoul= d change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). > =20 > Do we want to further clarify that the encoding be: base64url? Not a jav= ascript expert, but wondering if we need to use url safe encoding? This may r= esult in a normative clarification for some. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-887DFA3B-6E44-4638-9DFC-C5F9B4D61005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes. =F0=9F=98=84

Phil

On Mar 3, 2015, at 09:38, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Ah =E2=80=A6 I understand w= hat you=E2=80=99re saying now.  That makes sense to me.

 

So the type would be =E2=80= =9Cbinary=E2=80=9D which would usually be base64, but could optionally be ba= se64url if the attribute definition specifies this?

 

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Tuesday, March 03, 2015 11:18 AM
To: Kelly Grizzle
Cc: Ian Glazer; SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes<= /span>

 

No. Base64 is proposed as the default because we woul= dn't pass by url. 

 

However some things we will want to store must be url= encoded by their own specification such as json keys.  

=

 

We could make binary a complex type where encoding ca= n be specified, but it only make sense if you expected the encoding to dynam= ically change. That isn't the case here.  Eg A JWK must always be base6= 4url. 

 

AFAIK x509 would always be base64. 


Phil


On Mar 3, 2015, at 08:54, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

> I propose the attribute defn can do this sufficiently.  

 

I=E2=80=99m not sure that I understand this.  Ar= e you just saying that the binary data type will specify that base64url is a= lways used?  Or are you saying that the attribute definitions in the sc= hema will somehow indicate which encoding is used (either through a different type or just in the description)?

 

 

From: Phil Hunt [= mailto:phil.hunt@oracle.com]
Sent: Tuesday, March 03, 2015 10:43 AM
To: Kelly Grizzle
Cc: Ian Glazer; SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

JWK is JSON web key. They are passable in urls.  = ;

 

JWK is the new JSON equivalent of x509.

 

The good news is these are all just strings.  So= no extra coding to support. But the client will need to know how it is enco= ded. I propose the attribute defn can do this sufficiently.  

Phil


On Mar 3, 2015, at 07:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

I=E2=80=99m haven=E2=80=99t= followed JWT/JWK, so don=E2=80=99t know all of the history.

 

However, based on reading R= FC 4648, it seems that base64url is primarily used if the encoded data will a= ppear in a URL or filename.  Given the fact that in SCIM base64 will always occur in request and response bodies, I don=E2=80=99= t know that we need to worry about base64url. 

 

On the other hand, if most i= dentity-related standards are using base64url, it might make sense to go wit= h this for consistency.

 

In either case, I agree tha= t we should standardize on either base64 or base64url and not allow both.

 

--Kelly

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, March 02, 2015 2:26 PM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

I think it should be one form. 

 

My recommendation would be base64url for max utility.= Especially if we start defining schema related to JWT keys (JWK) from OAuth= and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or "recommended"?<= o:p>

 

Would the encoding type be a declared attribute of th= e SP?

 

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <phil.hunt@oracle.com&= gt; wrote:

 

I was looking through the schema document and cleanin= g up the data type characteristics (as discussed previously), I notice that t= he reference to XML-Schema is to the October 2004 one and not the 2012 XML S= chema.  The IETF will likely require us to reference the current spec, so I should probably update the reference= .

 

Looking at the binary attribute representation, I am w= ondering if we should change this to the current IETF specification which is= : RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).=

 

Do we want to further clarify that the encoding be: b= ase64url?   Not a javascript expert, but wondering if we need to use ur= l safe encoding? This may result in a normative clarification for some.=

 

 


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



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

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

= --Apple-Mail-887DFA3B-6E44-4638-9DFC-C5F9B4D61005-- From nobody Tue Mar 3 11:23:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD9B1AC44E for ; Tue, 3 Mar 2015 11:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 PbPs3N-OmAej for ; Tue, 3 Mar 2015 11:23:18 -0800 (PST) Received: from smtp.nexusgroup.com (smtp.nexusgroup.com [83.241.133.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4CE1AC449 for ; Tue, 3 Mar 2015 11:23:17 -0800 (PST) Received: from NG-EX01.ad.nexusgroup.com (10.75.28.40) by NG-EX02.ad.nexusgroup.com (10.75.28.43) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Mar 2015 20:23:15 +0100 Received: from NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab]) by NG-EX01.ad.nexusgroup.com ([fe80::1d3d:b319:f020:2bab%12]) with mapi id 15.00.0995.032; Tue, 3 Mar 2015 20:23:15 +0100 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m_neXus?= To: Phil Hunt , Ian Glazer Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwesDc9xBTxLUajV/ypkhqQR50Jjd8AgAAFNoCAADkuAIABV/x7 Date: Tue, 3 Mar 2015 19:23:14 +0000 Message-ID: <1425410593935.58911@nexusgroup.com> References: , <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> In-Reply-To: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.101.1] Content-Type: multipart/alternative; boundary="_000_142541059393558911nexusgroupcom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 19:23:22 -0000 --_000_142541059393558911nexusgroupcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would prefer to keep DER in there. To ease interop. x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are DER encoded x509 certificates that's Base 64 = encoded x509 per Section 4 [RFC4648].? / Erik ________________________________ From: scim on behalf of Phil Hunt Sent: Tuesday, March 3, 2015 12:50 AM To: Ian Glazer Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes All, Michael has reminded me that x509Certificate is DER encoded binary which is= in conflict with our current binary definition. I recommend changing the definition of Binary FROM: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded as a base 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is case-exact and has no uniqueness. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String per Section 2.7 [RFC7159]. TO: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded in Base 64 encoding as specified in Section 4 [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. In JSON representation, the encoded values are represented as a JSON String per Section 7 [RFC7159]. A binary is case-exact and has no uniqueness. Further, I would recommend changing x509certificates FROM: x509Certificates A list of certificates issued to the User. Values are Binary (Section 2.2.6) and DER encoded x509. This value has NO canonical types. TO: x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are Base 64 encoded x509 per Section 4 [RFC4648]. Important: This is a normative change as we are correcting the previous "D= ER" encoding to be base 64 encoding for consistency with the definition of = binary and JSON compatibility. If possible, please have comments to the list by 5PM Pacific tomorrow (Tues= day). I would like to publish draft 17 of core-schema in order to be able = to publish the changes to the API draft later in the week. Note that the p= roposed changes for tomorrow include expanding section 8.7 to include schem= as for fixed (non-resource) service provider schemas: ServiceProviderConfi= g, ResourceType, Schema. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Mar 2, 2015, at 12:25 PM, Phil Hunt > wrote: I think it should be one form. My recommendation would be base64url for max utility. Especially if we star= t defining schema related to JWT keys (JWK) from OAuth and JOSE. Phil On Mar 2, 2015, at 12:06, Ian Glazer > wrote: Would this be base64url "required" or "recommended"? Would the encoding type be a declared attribute of the SP? On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt > wrote: I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wi= ll likely require us to reference the current spec, so I should probably up= date the reference. Looking at the binary attribute representation, I am wondering if we should= change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). Do we want to further clarify that the encoding be: base64url? Not a java= script expert, but wondering if we need to use url safe encoding? This may = result in a normative clarification for some. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_142541059393558911nexusgroupcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 

I would prefer to keep =
DER in there. To ease interop.

x509Certificates=0A=
      A list of certificates issued to the User.  Values a=
re binary=0A=
      (Section 2.2.6) and are DER encoded x509 certificates that's Base 64 =
encoded x509 per Section 4 [RFC4648].​


/ Erik


From: scim <scim-bounces= @ietf.org> on behalf of Phil Hunt <phil.hunt@oracle.com>
Sent: Tuesday, March 3, 2015 12:50 AM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes
 
All,

Michael has reminded me that x509Certificate is DER encoded= binary which is in conflict with our current binary definition.

I recommend changing the definition of Binary FROM:
2.2.6.=
  Binary=0A=
=0A=
   Arbitrary binary data.  The attribute value MUST be encoded as a base=0A=
   64 encoding as specified in Section 3.2.16 [XML-Schema].  A binary is=0A=
   case-exact and has no uniqueness.=0A=
=0A=
   Values represented in JSON MUST conform to the XML constraints above=0A=
   and are represented as a JSON String per Section 2.7 [RFC7159].=0A=
TO:
2.2.6.=
  Binary=0A=
=0A=
   Arbitrary binary data.  The attribute value MUST be encoded in Base=0A=
   64 encoding as specified in Section 4 [RFC4648].  In cases where a=0A=
   URL-safe encoding is required, the attribute definition MAY specify=0A=
   Base 64 URL encoding MAY be used as per Section 5 [RFC4648].=0A=
=0A=
   In JSON representation, the encoded values are represented=
 as a JSON=0A=
   String per Section 7 [RFC7159].  A binary is case-exact and has no=0A=
   uniqueness.
Further, I would recommend changing x509certificates FROM:<= /div> 
   x50=
9Certificates=0A=
      A list of certificates issued to the User.  Values are Binary=0A=
      (Section 2.2.6) and DER encoded x509.  This value has NO canonical=0A=
      types.
TO:
   x50=
9Certificates=0A=
      A list of certificates issued to the User.  Values =
are binary=0A=
      (Section 2.2.6) and are Base 64 encoded x509 per Sectio=
n 4=0A=
      [RFC4648].=0A=

Important:  This is a normative change a= s we are correcting the previous “DER” encoding to be base 64 e= ncoding for consistency with the definition of binary and JSON compatibilit= y.

If possible, please have commen= ts to the list by 5PM Pacific tomorrow (Tuesday).  I would lik= e to publish draft 17 of core-schema in order to be able to publish the cha= nges to the API draft later in the week.  Note that the proposed changes for tomorrow include expanding section 8.7 to in= clude schemas for fixed (non-resource) service provider schemas:  Serv= iceProviderConfig, ResourceType, Schema.

Cheers,

Phil

@independentid
www.ind= ependentid.com
phil.hunt@oracle.= com

On Mar 2, 2015, at 12:25 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I think it should be one form. 

My recommendation would be base64url for max utility. Espec= ially if we start defining schema related to JWT keys (JWK) from OAuth and = JOSE. 

Phil

On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or= "recommended"?

Would the encoding type be a declared attribute of the SP?<= /div>

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <ph= il.hunt@oracle.com> wrote:

I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema.  The IE= TF will likely require us to reference the current spec, so I should probably update the reference.

Looking at the binary attribute representation, I am wonder= ing if we should change this to the current IETF specification which is: RF= C4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).

Do we want to further clarify that the encoding be: base64u= rl?   Not a javascript expert, but wondering if we need to use url saf= e encoding? This may result in a normative clarification for some.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com


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




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--_000_142541059393558911nexusgroupcom_-- From nobody Tue Mar 3 11:45:47 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55CC1A0070 for ; Tue, 3 Mar 2015 11:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.909 X-Spam-Level: X-Spam-Status: No, score=-3.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-C4NC1AugZp for ; Tue, 3 Mar 2015 11:45:43 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBDF1A6EF4 for ; Tue, 3 Mar 2015 11:45:43 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t23Jje1x025907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 19:45:41 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t23JjdWj008567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2015 19:45:40 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t23Jjdnr001941; Tue, 3 Mar 2015 19:45:39 GMT Received: from [10.97.79.183] (/24.244.23.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Mar 2015 11:45:38 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-55F8AEF3-9626-4FB0-B7BD-01578BB2B9F4 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: <1425410593935.58911@nexusgroup.com> Date: Tue, 3 Mar 2015 11:45:37 -0800 Content-Transfer-Encoding: 7bit Message-Id: <8FA504DF-B7B9-4FF7-857C-1EBBB218CB25@oracle.com> References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> <1425410593935.58911@nexusgroup.com> To: =?utf-8?Q?Erik_Wahlstr=C3=B6m_neXus?= X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: Cc: SCIM WG , Ian Glazer Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 19:45:46 -0000 --Apple-Mail-55F8AEF3-9626-4FB0-B7BD-01578BB2B9F4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Afaik der is not compatible with UTF8 as it is asn1. Not sure. Can someone f= ind a reference? Phil > On Mar 3, 2015, at 11:23, Erik Wahlstr=C3=B6m neXus wrote: >=20 > I would prefer to keep DER in there. To ease interop. >=20 > x509Certificates > A list of certificates issued to the User. Values are binary > (Section 2.2.6) and are DER encoded x509 certificates that's Base 64= encoded x509 per Section 4 [RFC4648].=E2=80=8B >=20 > / Erik >=20 > =20 > From: scim on behalf of Phil Hunt > Sent: Tuesday, March 3, 2015 12:50 AM > To: Ian Glazer > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > All, >=20 > Michael has reminded me that x509Certificate is DER encoded binary which i= s in conflict with our current binary definition. >=20 > I recommend changing the definition of Binary FROM: > 2.2.6. Binary >=20 > Arbitrary binary data. The attribute value MUST be encoded as a base > 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is > case-exact and has no uniqueness. >=20 > Values represented in JSON MUST conform to the XML constraints above > and are represented as a JSON String per Section 2.7 [RFC7159]. > TO: > 2.2.6. Binary >=20 > Arbitrary binary data. The attribute value MUST be encoded in Base > 64 encoding as specified in Section 4 [RFC4648]. In cases where a > URL-safe encoding is required, the attribute definition MAY specify > Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. >=20 > In JSON representation, the encoded values are represented as a JSON > String per Section 7 [RFC7159]. A binary is case-exact and has no > uniqueness. > Further, I would recommend changing x509certificates FROM: > x509Certificates > A list of certificates issued to the User. Values are Binary > (Section 2.2.6) and DER encoded x509. This value has NO canonical > types. > TO: > x509Certificates > A list of certificates issued to the User. Values are binary > (Section 2.2.6) and are Base 64 encoded x509 per Section 4 > [RFC4648]. >=20 > Important: This is a normative change as we are correcting the previous =E2= =80=9CDER=E2=80=9D encoding to be base 64 encoding for consistency with the d= efinition of binary and JSON compatibility. >=20 > If possible, please have comments to the list by 5PM Pacific tomorrow (Tue= sday). I would like to publish draft 17 of core-schema in order to be able t= o publish the changes to the API draft later in the week. Note that the pro= posed changes for tomorrow include expanding section 8.7 to include schemas f= or fixed (non-resource) service provider schemas: ServiceProviderConfig, Re= sourceType, Schema. >=20 > Cheers, >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >> On Mar 2, 2015, at 12:25 PM, Phil Hunt wrote: >>=20 >> I think it should be one form.=20 >>=20 >> My recommendation would be base64url for max utility. Especially if we st= art defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >>=20 >> Phil >>=20 >> On Mar 2, 2015, at 12:06, Ian Glazer wrote: >>=20 >>> Would this be base64url "required" or "recommended"? >>>=20 >>> Would the encoding type be a declared attribute of the SP? >>>=20 >>>> On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote:= >>>>=20 >>>> I was looking through the schema document and cleaning up the data type= characteristics (as discussed previously), I notice that the reference to X= ML-Schema is to the October 2004 one and not the 2012 XML Schema. The IETF w= ill likely require us to reference the current spec, so I should probably up= date the reference. >>>>=20 >>>> Looking at the binary attribute representation, I am wondering if we sh= ould change this to the current IETF specification which is: RFC4648 rather t= han reference XML-Schema 3.2.16 (of the 2004 schema spec). >>>>=20 >>>> Do we want to further clarify that the encoding be: base64url? Not a j= avascript expert, but wondering if we need to use url safe encoding? This ma= y result in a normative clarification for some. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>>=20 >>>=20 >>> --=20 >>> Ian Glazer >>> Senior Director, Identity >>> +1 202 255 3166 >>> @iglazer >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail-55F8AEF3-9626-4FB0-B7BD-01578BB2B9F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Afaik der is not compatible with UTF8 a= s it is asn1.  Not sure. Can someone find a reference?

Phil

On Mar 3, 2015, at 11:23, Erik Wahlstr=C3=B6m neXus <erik.wahlstrom@nexusgroup.com>= wrote:

I would prefer to keep DE=
R in there. To ease interop.

x509Certificates
      A list of certificates issued to the User.  Values ar=
e binary
      (Section 2.2.6) and are DER encoded x509 certificates that's Base 64 e=
ncoded x509 per Section 4 [RFC4648].=E2=80=8B


/ Erik


From: scim <scim-bounces@ietf.org> on behalf of Phil H= unt <phil.hunt@oracle.com>=
Sent: Tuesday, March 3, 2015 12:50 AM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes
 
All,

Michael has reminded me that x509Certificate is DER encoded b= inary which is in conflict with our current binary definition.

I recommend changing the definition of Binary FROM:
2.2.6. =
 Binary

   Arbitrary binary data.  The attribute value MUST be encoded as a base
   64 encoding as specified in Section 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniqueness.

   Values represented in JSON MUST conform to the XML constraints above
   and are represented as a JSON String per Section 2.7 [RFC7159].
TO:
2.2.6. =
 Binary

   Arbitrary binary data.  The attribute value MUST be encoded in Base
   64 encoding as specified in Section 4 [RFC4648].  In cases where a
   URL-safe encoding is required, the attribute definition MAY specify
   Base 64 URL encoding MAY be used as per Section 5 [RFC4648].

   In JSON representation, the encoded values are represented a=
s a JSON
   String per Section 7 [RFC7159].  A binary is case-exact and has no
   uniqueness.
Further, I would recommend changing x509certificates FROM: 
   x509=
Certificates
      A list of certificates issued to the User.  Values are Binary
      (Section 2.2.6) and DER encoded x509.  This value has NO canonical
      types.
TO:
   x509=
Certificates
      A list of certificates issued to the User.  Values a=
re binary
      (Section 2.2.6) and are Base 64 encoded x509 per Section=
 4
      [RFC4648].

Important:  This is a normative change as= we are correcting the previous =E2=80=9CDER=E2=80=9D encoding to be base 64= encoding for consistency with the definition of binary and JSON compatibili= ty.

If possible, please have comment= s to the list by 5PM Pacific tomorrow (Tuesday).  I would like t= o publish draft 17 of core-schema in order to be able to publish the changes= to the API draft later in the week.  Note that the proposed changes for tomorrow include expanding section 8.7 to inc= lude schemas for fixed (non-resource) service provider schemas:  Servic= eProviderConfig, ResourceType, Schema.

Cheers,

Phil

@independentid
www.inde= pendentid.com
phil.hunt@oracle.c= om

On Mar 2, 2015, at 12:25 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I think it should be one form. 

My recommendation would be base64url for max utility. Especi= ally if we start defining schema related to JWT keys (JWK) from OAuth and JO= SE. 

Phil

On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "required" or "recommend= ed"?

Would the encoding type be a declared attribute of the SP?

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <phi= l.hunt@oracle.com> wrote:

I was looking through the schema document and cleaning up the data type char= acteristics (as discussed previously), I notice that the reference to XML-Sc= hema is to the October 2004 one and not the 2012 XML Schema.  The IETF w= ill likely require us to reference the current spec, so I should probably update the reference.

Looking at the binary attribute representation, I am wonderi= ng if we should change this to the current IETF specification which is: RFC4= 648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).
=

Do we want to further clarify that the encoding be: base64ur= l?   Not a javascript expert, but wondering if we need to use url safe e= ncoding? This may result in a normative clarification for some.

Phil

@independentid
www.independentid.com
= phil.hunt@oracle.com


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




--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer
_______________________________________________
scim mailing list
scim@ietf.org
= https://www.ietf.org/= mailman/listinfo/scim

= --Apple-Mail-55F8AEF3-9626-4FB0-B7BD-01578BB2B9F4-- From nobody Tue Mar 3 12:13:04 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521DB1A88E2 for ; Tue, 3 Mar 2015 12:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vfYNvaHsad0y for ; Tue, 3 Mar 2015 12:12:51 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817141A88E0 for ; Tue, 3 Mar 2015 12:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25178; q=dns/txt; s=iport; t=1425413571; x=1426623171; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=18qoaaLI+CDiW3iqX0pljSkWVKB2BA1I/gy8u2KvhSU=; b=cFYuLLH/3CJY0Ab9BCRfW6Yc3+Svq/e6dtcHZLMHOvA+dHZ4SIB0cm9F E4IP74qfbP0xTyGAile8yLlUJ78NcrNfAnUHFk/E9d0lKX4mIL2hOEp+J KuGSGA3QkSAGjv7grMVroOqjQP/epk3b678q4x8infTe2hpJk1cwOyTj0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3BgADFfZU/4MNJK1QCoI/Q1JaBL8WgjCFcAKBK00BAQEBAQF8hA8BAQEELRwrBRACAQgRAwEBASEHBzIUCQgCBAENBRuIFA3WIAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLEoQSCwEBPg0BAwYBBgOEIgWNfIF9hXiDUYEagyKCU4kSgz4jg25vAYEDBxcGHH8BAQE X-IronPort-AV: E=Sophos;i="5.09,683,1418083200"; d="scan'208,217";a="128567599" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 03 Mar 2015 20:12:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t23KCn8Q017060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 20:12:49 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 14:12:49 -0600 From: "Morteza Ansari (moransar)" To: Michael Frost , Phil Hunt , SCIM WG Thread-Topic: [scim] Proposed text for schema resources vs. messages Thread-Index: AQHQUrnIR/UTrLRuV0CCGnssMGLR450KeJKAgACdSIA= Date: Tue, 3 Mar 2015 20:12:49 +0000 Message-ID: References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> <95305152-5386-432e-8095-0d4c7a1d319b@default> In-Reply-To: <95305152-5386-432e-8095-0d4c7a1d319b@default> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.84.34] Content-Type: multipart/alternative; boundary="_000_D11B540711E5C4moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 20:12:58 -0000 --_000_D11B540711E5C4moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, I am reading this as you are OK with Phil=92s proposed text and agree it ad= dresses the potential confusion on the use of schema in the messages but yo= u prefer a different attribute name (e.g. msgType) over schema. Is that a c= orrect read of your first paragraph? On your second point, I don=92t think we have ever had a use case for addin= g non-resource type of data to the payload of messages so this has never co= me up as a requirement or even as an extensibility option. I personally thi= nk a change like that will have much bigger impact on the overall design of= the API and modeling of the objects. And finally good catch on the typo. Phil, can you please fix that in the n= ext revision? Cheers, Morteza From: Michael Frost > Date: Monday, March 2, 2015 at 6:49 PM To: Phil Hunt >, "scim@ie= tf.org" > Cc: Erik Wahlstr=F6m neXus >, Morteza Ansari > Subject: RE: [scim] Proposed text for schema resources vs. messages I would have preferred msgType just because it still feels like we are sort= of =93overloading=94 the Schemas attribute based on context (message vs. r= esource). So I guess I=92m a little at odds with the contention that we ar= e using =93Schemas=94 consistently. However the proposed text changes are = quite clear on the use of Schemas attributes in each context and certainly = addresses my earlier concerns. Just as an aside, is it worth considering placing message type in all messa= ges and only placing schemas in resource objects? Do we ever anticipate th= e need to carry some data in the payload of PUT/POST that is not part of th= e resource and not conveniently encoded into query parameters? It would pl= ace a consistent envelope around all requests/responses, but is perhaps a b= it unRESTful. Anyway, I noticed one minor type-o with paragraph 4 in section 3.1, openin= g sentence starts with =93As SCIM in intended for use=94 should probably be= =93As SCIM is intended for use=94. -mrf From: Phil Hunt Sent: Friday, February 27, 2015 10:18 AM To: SCIM WG Cc: Erik Wahlstr=F6m neXus; Michael Frost Subject: [scim] Proposed text for schema resources vs. messages IMPORTANT: We need to get this information published next week if we are t= o make the Dallas meeting deadline. Please respond by Tuesday Mar 3, 8AM Pa= cific. Based on feedback I will publish a minor revision to schemas doc Tue= sday afternoon, and on Thursday revisions to API. In a previous thread (https://www.ietf.org/mail-archive/web/scim/current/ms= g02128.html), Erik proposed we use different attributes to distinguish betw= een SCIM messages and resources (msgType and schemas). I have taken a look at the impact on the documents and I think the solution= may be perceived as somewhat more complex than consistently using =93schem= as=94. The main reason is that someone opening a JSON object now has to lo= ok for two different attributes to tell if the object is a SCIM object of a= ny type. I am not sure this matters in practice, but it does =93feel=94 com= plex from a media type perspective. >From an editorial and IANA perspective, I believe using =93msgType=94 means= that we have to build a separate IANA registry for messages distinct from = schemas. Given that the review process is essentially the same, I=92m not s= ure there is a lot of benefit. I wonder then if clarifying text might not w= ork as well. What I have done is written a new introduction to section 3 of the API spec= ification. My hope is that this sets the stage for how SCIM protocol works = and clearly establishes the differences between SCIM resources and messages= . Action Item: PLEASE INDICATE (by next Tuesday morning if possible): A. Given the text below, does anyone strongly prefer using =93msgType=94 i= nstead (and creating a new registry for it)? B. Comments on the text. Thanks! PROPOSED TEXT: 3. SCIM Protocol 3.1. Introduction SCIM is a protocol based on HTTP [RFC7230]. Along with HTTP headers and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM resources as well as request parameters and response information such as errors in the form of JSON based messages. To identify this content, SCIM uses a media type of "application/scim+json" (see Section 8.1). A SCIM resource is a JSON object that may be created, maintained, and retrieved through HTTP methods as described in this document. Each JSON resource representation contains a "schemas" attribute that contains a list of one or more URIs that indicate included SCIM schemas that may be used to indicate the attributes contained within a resource. When querying a SCIM service provider's "/Schemas" endpoint for schema definition (see Section 8.7 [I-D.ietf-scim-core-schema]), the response describes how a service provider supports an attribute including schema meta-attributes such as case-exactness, mutability, uniqueness, returnability, and whether it is required. While SCIM schemas and associated extension model is defined in [I-D.ietf-scim-core-schema], SCIM clients should expect that some attribute schema MAY change from deployment to deployment. In cases where SCIM may be used as an open protocol in front of an application service, it is quite reasonable to expect that some service providers MAY only support a sub-set of the schema defined in [I-D.ietf-scim-core-schema]. A SCIM message is a JSON object that conveys protocol parameters about a SCIM request or response that are defined by this specification. As with a SCIM resource, a SCIM message is a JSON object that contains a "schemas" attribute with a URI whose namespace prefix begins with "urn:ietf:params:scim:api:". As SCIM protocol messages are fixed and defined by SCIM specifications and registered extensions, SCIM message schemas using the above prefix URN SHALL NOT be discoverable using the "/Schemas" endpoint. As SCIM in intended for use within cross-domain environments where schemas MAY vary, techniques such as document validation, such as in [XML-Schema], are not recommended. A SCIM service provider interprets a request in the context of its own schema (which may be different from the client's schema) and the processing rules described for each SCIM request. The following sections in this document define processing rules for SCIM that provide allowances for differences where appropriate. For example, in a SCIM PUT request, "readOnly" attributes are ignored, while "readWrite" attributes are updated. There is no need for the client to discover which attributes are "readOnly" and remove them from the PUT request in advance in order to be accepted. Similarly a SCIM client SHOULD NOT expect a service provider to return SCIM resources with exactly the same schema and values as submitted. SCIM responses SHALL reflect resource state as interpreted by the SCIM service provider. 3.2. SCIM Endpoints The SCIM protocol specifies well-known endpoints and HTTP methods for managing resources defined in the core schema; i.e., "User" and Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_D11B540711E5C4moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6CF411C5F1CD11439F2A62AFF4D06C1C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Michael,

I am reading this as you are OK with Phil=92s proposed text and agree = it addresses the potential confusion on the use of schema in the messages b= ut you prefer a different attribute name (e.g. msgType) over schema. Is tha= t a correct read of your first paragraph?

On your second point, I don=92t think we have ever had a use case for = adding non-resource type of data to the payload of messages so this has nev= er come up as a requirement or even as an extensibility option. I personall= y think a change like that will have much bigger impact on the overall design of the API and modeling of the ob= jects. 

And finally good catch on the typo.  Phil, can you please fix tha= t in the next revision?


Cheers,
Morteza

From: Michael Frost <michael.frost@oracle.com>
Date: Monday, March 2, 2015 at 6:49= PM
To: Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Cc: Erik Wahlstr=F6m neXus <erik.wahlstrom@nexusgroup.com<= /a>>, Morteza Ansari <moransar@= cisco.com>
Subject: RE: [scim] Proposed text f= or schema resources vs. messages

I would have preferred msgType just= because it still feels like we are sort of =93overloading=94 the Schemas a= ttribute based on context (message vs. resource).  So I guess I=92m a little at odds with the contention that we are using = =93Schemas=94 consistently.  However the proposed text changes are qui= te clear on the use of Schemas attributes in each context and certainly add= resses my earlier concerns.

 

Just as an aside, is it worth consi= dering placing message type in all messages and only placing schemas in res= ource objects?  Do we ever anticipate the need to carry some data in the payload of PUT/POST that is not part of= the resource and not conveniently encoded into query parameters?  It = would place a consistent envelope around all requests/responses, but is per= haps a bit unRESTful.

 

Anyway, I noticed one minor type-o = with paragraph 4 in section 3.1,  opening sentence starts with =93As S= CIM in intended for use=94 should probably be =93As SCIM is intended for use=94.

 

-mrf

 

From: Phil Hunt
Sent: Friday, February 27, 2015 10:18 AM
To: SCIM WG
Cc: Erik Wahlstr=F6m neXus; Michael Frost
Subject: [scim] Proposed text for schema resources vs. messages=

 

IMPORTANT:  We need to get this information pub= lished next week if we are to make the Dallas meeting deadline. Please r= espond by Tuesday Mar 3, 8AM Pacific. Based on feedback I will publish a minor revision to schemas doc Tuesda= y afternoon, and on Thursday revisions to API.

 

In a previous thread (https://www.ietf.org/mail-ar= chive/web/scim/current/msg02128.html), Erik proposed we use different a= ttributes to distinguish between SCIM messages and resources (msgType and schemas).

 

I have taken a look at the impact on the documents a= nd I think the solution may be perceived as somewhat more complex than cons= istently using =93schemas=94.  The main reason is that someone opening= a JSON object now has to look for two different attributes to tell if the object is a SCIM object of any type. I am not su= re this matters in practice, but it does =93feel=94 complex from a media ty= pe perspective.

 

From an editorial and IANA perspective, I believe us= ing =93msgType=94 means that we have to build a separate IANA registry for = messages distinct from schemas. Given that the review process is essentiall= y the same, I=92m not sure there is a lot of benefit. I wonder then if clarifying text might not work as well.<= /o:p>

 

What I have done is written a new introduction to se= ction 3 of the API specification. My hope is that this sets the stage for h= ow SCIM protocol works and clearly establishes the differences between SCIM= resources and messages.

 

Action Item:  PLEASE INDICATE (by next Tuesd= ay morning if possible):

 

A.  Given the text below, does anyone strongly = prefer using =93msgType=94 instead (and creating a new registry for it)?

 

B.  Comments on the text.

 

Thanks!

 

PROPOSED TEXT:

3.  SCIM Pro=
tocol
 
3.1.  Introduction
 
   SCIM is a protocol based on HTTP [RFC7230].  Along w=
ith HTTP headers
   and URIs, SCIM uses JSON [RFC7159] payloads to convey bot=
h SCIM
   resources as well as request parameters and response info=
rmation such
   as errors in the form of JSON based messages.  To id=
entify this
   content, SCIM uses a media type of "application/scim=
+json" (see
   Section 8.1).
 
   A SCIM resource is a JSON object that may be created, mai=
ntained, and
   retrieved through HTTP methods as described in this docum=
ent.  Each
   JSON resource representation contains a "schemas&quo=
t; attribute that
   contains a list of one or more URIs that indicate include=
d SCIM
   schemas that may be used to indicate the attributes conta=
ined within
   a resource.  When querying a SCIM service provider's=
 "/Schemas"
   endpoint for schema definition (see Section 8.7
   [I-D.ietf-scim-core-schema]), the response describes how =
a service
   provider supports an attribute including schema meta-attr=
ibutes such
   as case-exactness, mutability, uniqueness, returnability,=
 and whether
   it is required.  While SCIM schemas and associated e=
xtension model is
   defined in [I-D.ietf-scim-core-schema], SCIM clients shou=
ld expect
   that some attribute schema MAY change from deployment to =
deployment.
   In cases where SCIM may be used as an open protocol in fr=
ont of an
   application service, it is quite reasonable to expect tha=
t some
   service providers MAY only support a sub-set of the schem=
a defined in
   [I-D.ietf-scim-core-schema].
 
   A SCIM message is a JSON object that conveys protocol par=
ameters
   about a SCIM request or response that are defined by this=

   specification.  As with a SCIM resource, a SCIM mess=
age is a JSON
   object that contains a "schemas" attribute with=
 a URI whose namespace
   prefix begins with "urn:ietf:params:scim:api:".=
  As SCIM protocol
   messages are fixed and defined by SCIM specifications and=
 registered
   extensions, SCIM message schemas using the above prefix U=
RN SHALL NOT
   be discoverable using the "/Schemas" endpoint.<=
o:p>
 
   As SCIM in intended for use within cross-domain environme=
nts where
   schemas MAY vary, techniques such as document validation,=
 such as in
   [XML-Schema], are not recommended.  A SCIM service p=
rovider
   interprets a request in the context of its own schema (wh=
ich may be
   different from the client's schema) and the processing ru=
les
   described for each SCIM request.  The following sect=
ions in this
   document define processing rules for SCIM that provide al=
lowances for
   differences where appropriate.  For example, in a SC=
IM PUT request,
   "readOnly" attributes are ignored, while "=
readWrite" attributes are
   updated.  There is no need for the client to discove=
r which
   attributes are "readOnly" and remove them from =
the PUT request in
   advance in order to be accepted.  Similarly a SCIM c=
lient SHOULD NOT
   expect a service provider to return SCIM resources with e=
xactly the
   same schema and values as submitted.  SCIM responses=
 SHALL reflect
   resource state as interpreted by the SCIM service provide=
r.
 
3.2.  SCIM Endpoints
 
   The SCIM protocol specifies well-known endpoints and HTTP=
 methods for
   managing resources defined in the core schema; i.e., &quo=
t;User" and
 
 --_000_D11B540711E5C4moransarciscocom_-- From nobody Tue Mar 3 12:14:47 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3971A88E0 for ; Tue, 3 Mar 2015 12:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GPiyUApOHfMg for ; Tue, 3 Mar 2015 12:14:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709351A88A1 for ; Tue, 3 Mar 2015 12:14:42 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 20:12:50 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Tue, 3 Mar 2015 20:12:50 +0000 From: Anthony Nadalin To: Ian Glazer , Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwd+8eoLMUuT02ylZLB3DAVWJ0JnqMAgAAFNYCAADkuAIABBmOAgABO9TA= Date: Tue, 3 Mar 2015 20:12:49 +0000 Message-ID: References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: salesforce.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19617315012)(19625215002)(16236675004)(74316001)(2656002)(122556002)(19609705001)(46102003)(106116001)(19300405004)(19580395003)(54356999)(19580405001)(16601075003)(87936001)(40100003)(77156002)(102836002)(62966003)(50986999)(92566002)(86362001)(2900100001)(2950100001)(33656002)(76576001)(76176999)(93886004)(15975445007)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234F6CEA951219CE1455A2DA6110BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 20:12:49.9597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 20:14:46 -0000 --_000_BN3PR0301MB1234F6CEA951219CE1455A2DA6110BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gY29uZnVzZWQsIHdoeSB3b3VsZCB3ZSBub3QganVzdCB1c2Ugd2hhdCBKT1NFIHVzZWQg Zm9yIEJpbmFyeSBFbmNvZGluZyA/DQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gR2xhemVyDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAz LCAyMDE1IDc6MjkgQU0NClRvOiBQaGlsIEh1bnQNCkNjOiBTQ0lNIFdHDQpTdWJqZWN0OiBSZTog W3NjaW1dIEJhc2U2NCBFbmNvZGluZyBmb3IgQmluYXJ5IEF0dHJpYnV0ZXMNCg0KSSBhbSBva2F5 IHdpdGggdGhpcyBjaGFuZ2UNCg0KT24gTW9uLCBNYXIgMiwgMjAxNSBhdCA2OjUwIFBNLCBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+ IHdyb3RlOg0KQWxsLA0KDQpNaWNoYWVsIGhhcyByZW1pbmRlZCBtZSB0aGF0IHg1MDlDZXJ0aWZp Y2F0ZSBpcyBERVIgZW5jb2RlZCBiaW5hcnkgd2hpY2ggaXMgaW4gY29uZmxpY3Qgd2l0aCBvdXIg Y3VycmVudCBiaW5hcnkgZGVmaW5pdGlvbi4NCg0KSSByZWNvbW1lbmQgY2hhbmdpbmcgdGhlIGRl ZmluaXRpb24gb2YgQmluYXJ5IEZST006DQoNCjIuMi42LiAgQmluYXJ5DQoNCg0KDQogICBBcmJp dHJhcnkgYmluYXJ5IGRhdGEuICBUaGUgYXR0cmlidXRlIHZhbHVlIE1VU1QgYmUgZW5jb2RlZCBh cyBhIGJhc2UNCg0KICAgNjQgZW5jb2RpbmcgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMy4yLjE2 IFtYTUwtU2NoZW1hXS4gIEEgYmluYXJ5IGlzDQoNCiAgIGNhc2UtZXhhY3QgYW5kIGhhcyBubyB1 bmlxdWVuZXNzLg0KDQoNCg0KICAgVmFsdWVzIHJlcHJlc2VudGVkIGluIEpTT04gTVVTVCBjb25m b3JtIHRvIHRoZSBYTUwgY29uc3RyYWludHMgYWJvdmUNCg0KICAgYW5kIGFyZSByZXByZXNlbnRl ZCBhcyBhIEpTT04gU3RyaW5nIHBlciBTZWN0aW9uIDIuNyBbUkZDNzE1OV0uDQpUTzoNCg0KMi4y LjYuICBCaW5hcnkNCg0KDQoNCiAgIEFyYml0cmFyeSBiaW5hcnkgZGF0YS4gIFRoZSBhdHRyaWJ1 dGUgdmFsdWUgTVVTVCBiZSBlbmNvZGVkIGluIEJhc2UNCg0KICAgNjQgZW5jb2RpbmcgYXMgc3Bl Y2lmaWVkIGluIFNlY3Rpb24gNCBbUkZDNDY0OF0uICBJbiBjYXNlcyB3aGVyZSBhDQoNCiAgIFVS TC1zYWZlIGVuY29kaW5nIGlzIHJlcXVpcmVkLCB0aGUgYXR0cmlidXRlIGRlZmluaXRpb24gTUFZ IHNwZWNpZnkNCg0KICAgQmFzZSA2NCBVUkwgZW5jb2RpbmcgTUFZIGJlIHVzZWQgYXMgcGVyIFNl Y3Rpb24gNSBbUkZDNDY0OF0uDQoNCg0KDQogICBJbiBKU09OIHJlcHJlc2VudGF0aW9uLCB0aGUg ZW5jb2RlZCB2YWx1ZXMgYXJlIHJlcHJlc2VudGVkIGFzIGEgSlNPTg0KDQogICBTdHJpbmcgcGVy IFNlY3Rpb24gNyBbUkZDNzE1OV0uICBBIGJpbmFyeSBpcyBjYXNlLWV4YWN0IGFuZCBoYXMgbm8N Cg0KICAgdW5pcXVlbmVzcy4NCkZ1cnRoZXIsIEkgd291bGQgcmVjb21tZW5kIGNoYW5naW5nIHg1 MDljZXJ0aWZpY2F0ZXMgRlJPTToNCg0KICAgeDUwOUNlcnRpZmljYXRlcw0KDQogICAgICBBIGxp c3Qgb2YgY2VydGlmaWNhdGVzIGlzc3VlZCB0byB0aGUgVXNlci4gIFZhbHVlcyBhcmUgQmluYXJ5 DQoNCiAgICAgIChTZWN0aW9uIDIuMi42KSBhbmQgREVSIGVuY29kZWQgeDUwOS4gIFRoaXMgdmFs dWUgaGFzIE5PIGNhbm9uaWNhbA0KDQogICAgICB0eXBlcy4NClRPOg0KDQogICB4NTA5Q2VydGlm aWNhdGVzDQoNCiAgICAgIEEgbGlzdCBvZiBjZXJ0aWZpY2F0ZXMgaXNzdWVkIHRvIHRoZSBVc2Vy LiAgVmFsdWVzIGFyZSBiaW5hcnkNCg0KICAgICAgKFNlY3Rpb24gMi4yLjYpIGFuZCBhcmUgQmFz ZSA2NCBlbmNvZGVkIHg1MDkgcGVyIFNlY3Rpb24gNA0KDQogICAgICBbUkZDNDY0OF0uDQoNCklt cG9ydGFudDogIFRoaXMgaXMgYSBub3JtYXRpdmUgY2hhbmdlIGFzIHdlIGFyZSBjb3JyZWN0aW5n IHRoZSBwcmV2aW91cyDigJxERVLigJ0gZW5jb2RpbmcgdG8gYmUgYmFzZSA2NCBlbmNvZGluZyBm b3IgY29uc2lzdGVuY3kgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiBiaW5hcnkgYW5kIEpTT04gY29t cGF0aWJpbGl0eS4NCg0KSWYgcG9zc2libGUsIHBsZWFzZSBoYXZlIGNvbW1lbnRzIHRvIHRoZSBs aXN0IGJ5IDVQTSBQYWNpZmljIHRvbW9ycm93IChUdWVzZGF5KS4gIEkgd291bGQgbGlrZSB0byBw dWJsaXNoIGRyYWZ0IDE3IG9mIGNvcmUtc2NoZW1hIGluIG9yZGVyIHRvIGJlIGFibGUgdG8gcHVi bGlzaCB0aGUgY2hhbmdlcyB0byB0aGUgQVBJIGRyYWZ0IGxhdGVyIGluIHRoZSB3ZWVrLiAgTm90 ZSB0aGF0IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGZvciB0b21vcnJvdyBpbmNsdWRlIGV4cGFuZGlu ZyBzZWN0aW9uIDguNyB0byBpbmNsdWRlIHNjaGVtYXMgZm9yIGZpeGVkIChub24tcmVzb3VyY2Up IHNlcnZpY2UgcHJvdmlkZXIgc2NoZW1hczogIFNlcnZpY2VQcm92aWRlckNvbmZpZywgUmVzb3Vy Y2VUeXBlLCBTY2hlbWEuDQoNCkNoZWVycywNCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3 LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1 bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCk9uIE1hciAyLCAy MDE1LCBhdCAxMjoyNSBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KSSB0aGluayBpdCBzaG91bGQgYmUgb25l IGZvcm0uDQoNCk15IHJlY29tbWVuZGF0aW9uIHdvdWxkIGJlIGJhc2U2NHVybCBmb3IgbWF4IHV0 aWxpdHkuIEVzcGVjaWFsbHkgaWYgd2Ugc3RhcnQgZGVmaW5pbmcgc2NoZW1hIHJlbGF0ZWQgdG8g SldUIGtleXMgKEpXSykgZnJvbSBPQXV0aCBhbmQgSk9TRS4NCg0KUGhpbA0KDQpPbiBNYXIgMiwg MjAxNSwgYXQgMTI6MDYsIElhbiBHbGF6ZXIgPGlnbGF6ZXJAc2FsZXNmb3JjZS5jb208bWFpbHRv OmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20+PiB3cm90ZToNCldvdWxkIHRoaXMgYmUgYmFzZTY0dXJs ICJyZXF1aXJlZCIgb3IgInJlY29tbWVuZGVkIj8NCg0KV291bGQgdGhlIGVuY29kaW5nIHR5cGUg YmUgYSBkZWNsYXJlZCBhdHRyaWJ1dGUgb2YgdGhlIFNQPw0KDQpPbiBNb24sIE1hciAyLCAyMDE1 IGF0IDI6MDcgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgd2FzIGxvb2tpbmcgdGhyb3VnaCB0aGUgc2No ZW1hIGRvY3VtZW50IGFuZCBjbGVhbmluZyB1cCB0aGUgZGF0YSB0eXBlIGNoYXJhY3RlcmlzdGlj cyAoYXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkpLCBJIG5vdGljZSB0aGF0IHRoZSByZWZlcmVuY2Ug dG8gWE1MLVNjaGVtYSBpcyB0byB0aGUgT2N0b2JlciAyMDA0IG9uZSBhbmQgbm90IHRoZSAyMDEy IFhNTCBTY2hlbWEuICBUaGUgSUVURiB3aWxsIGxpa2VseSByZXF1aXJlIHVzIHRvIHJlZmVyZW5j ZSB0aGUgY3VycmVudCBzcGVjLCBzbyBJIHNob3VsZCBwcm9iYWJseSB1cGRhdGUgdGhlIHJlZmVy ZW5jZS4NCg0KTG9va2luZyBhdCB0aGUgYmluYXJ5IGF0dHJpYnV0ZSByZXByZXNlbnRhdGlvbiwg SSBhbSB3b25kZXJpbmcgaWYgd2Ugc2hvdWxkIGNoYW5nZSB0aGlzIHRvIHRoZSBjdXJyZW50IElF VEYgc3BlY2lmaWNhdGlvbiB3aGljaCBpczogUkZDNDY0OCByYXRoZXIgdGhhbiByZWZlcmVuY2Ug WE1MLVNjaGVtYSAzLjIuMTYgKG9mIHRoZSAyMDA0IHNjaGVtYSBzcGVjKS4NCg0KRG8gd2Ugd2Fu dCB0byBmdXJ0aGVyIGNsYXJpZnkgdGhhdCB0aGUgZW5jb2RpbmcgYmU6IGJhc2U2NHVybD8gICBO b3QgYSBqYXZhc2NyaXB0IGV4cGVydCwgYnV0IHdvbmRlcmluZyBpZiB3ZSBuZWVkIHRvIHVzZSB1 cmwgc2FmZSBlbmNvZGluZz8gVGhpcyBtYXkgcmVzdWx0IGluIGEgbm9ybWF0aXZlIGNsYXJpZmlj YXRpb24gZm9yIHNvbWUuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVu dGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0 Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NjaW0NCg0KDQoNCi0tDQpJYW4gR2xhemVyDQpTZW5pb3IgRGlyZWN0b3IsIElk ZW50aXR5DQorMSAyMDIgMjU1IDMxNjY8dGVsOiUyQjElMjAyMDIlMjAyNTUlMjAzMTY2Pg0KQGln bGF6ZXI8aHR0cHM6Ly90d2l0dGVyLmNvbS9pZ2xhemVyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYu b3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zY2ltDQoNCg0KDQoNCi0tDQpJYW4gR2xhemVyDQpTZW5pb3IgRGlyZWN0b3IsIElk ZW50aXR5DQorMSAyMDIgMjU1IDMxNjYNCkBpZ2xhemVyPGh0dHBzOi8vdHdpdHRlci5jb20vaWds YXplcj4NCg== --_000_BN3PR0301MB1234F6CEA951219CE1455A2DA6110BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJltIGNvbmZ1c2VkLCB3 aHkgd291bGQgd2Ugbm90IGp1c3QgdXNlIHdoYXQgSk9TRSB1c2VkIGZvciBCaW5hcnkgRW5jb2Rp bmcgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzY2ltIFttYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5JYW4gR2xhemVyPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDMsIDIwMTUgNzoyOSBBTTxicj4NCjxiPlRv OjwvYj4gUGhpbCBIdW50PGJyPg0KPGI+Q2M6PC9iPiBTQ0lNIFdHPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbc2NpbV0gQmFzZTY0IEVuY29kaW5nIGZvciBCaW5hcnkgQXR0cmlidXRlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gb2theSB3aXRoIHRoaXMgY2hh bmdlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IE1hciAyLCAyMDE1IGF0IDY6NTAgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TWljaGFlbCBoYXMgcmVtaW5kZWQgbWUgdGhhdCB4NTA5Q2VydGlmaWNhdGUgaXMg REVSIGVuY29kZWQgYmluYXJ5IHdoaWNoIGlzIGluIGNvbmZsaWN0IHdpdGggb3VyIGN1cnJlbnQg YmluYXJ5IGRlZmluaXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgcmVjb21tZW5kIGNoYW5naW5nIHRoZSBkZWZpbml0aW9uIG9mIEJp bmFyeSBGUk9NOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjIuMi42LiZuYnNwOyBCaW5h cnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgQXJiaXRyYXJ5IGJpbmFyeSBkYXRhLiZuYnNwOyBUaGUgYXR0cmlidXRlIHZh bHVlIE1VU1QgYmUgZW5jb2RlZCBhcyBhIGJhc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgNjQgZW5jb2RpbmcgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMy4yLjE2IFtYTUwt U2NoZW1hXS4mbmJzcDsgQSBiaW5hcnkgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgY2FzZS1leGFjdCBhbmQgaGFzIG5vIHVuaXF1ZW5lc3MuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFZhbHVlcyBy ZXByZXNlbnRlZCBpbiBKU09OIE1VU1QgY29uZm9ybSB0byB0aGUgWE1MIGNvbnN0cmFpbnRzIGFi b3ZlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFuZCBhcmUgcmVwcmVzZW50 ZWQgYXMgYSBKU09OIFN0cmluZyBwZXIgU2VjdGlvbiAyLjcgW1JGQzcxNTldLjxvOnA+PC9vOnA+ PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VE86PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+Mi4yLjYuJm5ic3A7IEJpbmFyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBBcmJpdHJhcnkgYmluYXJ5 IGRhdGEuJm5ic3A7IFRoZSBhdHRyaWJ1dGUgdmFsdWUgTVVTVCBiZSBlbmNvZGVkIGluPGI+IEJh c2U8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7IDY0IGVuY29kaW5n IGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDQgW1JGQzQ2NDhdLiZuYnNwOyBJbiBjYXNlcyB3aGVy ZSBhPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyBVUkwtc2FmZSBl bmNvZGluZyBpcyByZXF1aXJlZCwgdGhlIGF0dHJpYnV0ZSBkZWZpbml0aW9uIE1BWSBzcGVjaWZ5 PG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyBCYXNlIDY0IFVSTCBl bmNvZGluZyBNQVkgYmUgdXNlZCBhcyBwZXIgU2VjdGlvbiA1IFtSRkM0NjQ4XTwvYj4uPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IDxiPkluIEpTT04gcmVwcmVzZW50YXRpb24sIHRoZSBlbmNvZGVkIHZhbHVlcyBhcmUgcmVw cmVzZW50ZWQgYXMgYSBKU09OPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZu YnNwOyBTdHJpbmcgcGVyIFNlY3Rpb24gNyBbUkZDNzE1OV0uJm5ic3A7IEEgYmluYXJ5IGlzIGNh c2UtZXhhY3QgYW5kIGhhcyBubzxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsm bmJzcDsgdW5pcXVlbmVzcy48L2I+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5GdXJ0aGVyLCBJIHdvdWxkIHJlY29tbWVuZCBjaGFuZ2luZyB4NTA5Y2VydGlm aWNhdGVzIEZST006PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDsm bmJzcDsgeDUwOUNlcnRpZmljYXRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBIGxpc3Qgb2YgY2VydGlmaWNhdGVzIGlzc3VlZCB0byB0aGUg VXNlci4mbmJzcDsgVmFsdWVzIGFyZSBCaW5hcnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKFNlY3Rpb24gMi4yLjYpIGFuZCBERVIgZW5jb2Rl ZCB4NTA5LiZuYnNwOyBUaGlzIHZhbHVlIGhhcyBOTyBjYW5vbmljYWw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZXMuPG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRPOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hp dGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyB4NTA5Q2VydGlmaWNhdGVzPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgbGlzdCBvZiBj ZXJ0aWZpY2F0ZXMgaXNzdWVkIHRvIHRoZSBVc2VyLjxiPiA8L2I+Jm5ic3A7VmFsdWVzIGFyZSBi aW5hcnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKFNlY3Rpb24gMi4yLjYpIGFuZDxiPiBhcmUgQmFzZSA2NCBlbmNvZGVkIHg1MDkgcGVyIFNl Y3Rpb24gNDxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgW1JGQzQ2NDhdLjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5JbXBvcnRhbnQ6ICZuYnNwO1RoaXMgaXMgYSBu b3JtYXRpdmUgY2hhbmdlIGFzIHdlIGFyZSBjb3JyZWN0aW5nIHRoZSBwcmV2aW91cyDigJxERVLi gJ0gZW5jb2RpbmcgdG8gYmUgYmFzZSA2NCBlbmNvZGluZyBmb3IgY29uc2lzdGVuY3kgd2l0aCB0 aGUgZGVmaW5pdGlvbiBvZiBiaW5hcnkgYW5kIEpTT04gY29tcGF0aWJpbGl0eS48L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPklm IHBvc3NpYmxlLCBwbGVhc2UgaGF2ZSBjb21tZW50cyB0byB0aGUgbGlzdCBieSA1UE0gUGFjaWZp YyB0b21vcnJvdyAoVHVlc2RheSk8L2k+PC9iPi4mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIHB1Ymxp c2ggZHJhZnQgMTcgb2YgY29yZS1zY2hlbWEgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBwdWJsaXNo IHRoZSBjaGFuZ2VzIHRvIHRoZSBBUEkgZHJhZnQgbGF0ZXIgaW4gdGhlIHdlZWsuJm5ic3A7IE5v dGUgdGhhdCB0aGUNCiBwcm9wb3NlZCBjaGFuZ2VzIGZvciB0b21vcnJvdyBpbmNsdWRlIGV4cGFu ZGluZyBzZWN0aW9uIDguNyB0byBpbmNsdWRlIHNjaGVtYXMgZm9yIGZpeGVkIChub24tcmVzb3Vy Y2UpIHNlcnZpY2UgcHJvdmlkZXIgc2NoZW1hczogJm5ic3A7U2VydmljZVByb3ZpZGVyQ29uZmln LCBSZXNvdXJjZVR5cGUsIFNjaGVtYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyLCAy MDE1LCBhdCAxMjoyNSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgaXQgc2hvdWxkIGJlIG9uZSBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSByZWNvbW1lbmRhdGlvbiB3 b3VsZCBiZSBiYXNlNjR1cmwgZm9yIG1heCB1dGlsaXR5LiBFc3BlY2lhbGx5IGlmIHdlIHN0YXJ0 IGRlZmluaW5nIHNjaGVtYSByZWxhdGVkIHRvIEpXVCBrZXlzIChKV0spIGZyb20gT0F1dGggYW5k IEpPU0UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAy LCAyMDE1LCBhdCAxMjowNiwgSWFuIEdsYXplciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnbGF6ZXJA c2FsZXNmb3JjZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZ2xhemVyQHNhbGVzZm9yY2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB0aGlzIGJlIGJhc2U2NHVybCAmcXVvdDtyZXF1aXJlZCZx dW90OyBvciAmcXVvdDtyZWNvbW1lbmRlZCZxdW90Oz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHRoZSBlbmNvZGluZyB0eXBlIGJlIGEgZGVjbGFy ZWQgYXR0cmlidXRlIG9mIHRoZSBTUD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMiwgMjAxNSBhdCAyOjA3IFBNLCBQaGls IEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgbG9va2lu ZyB0aHJvdWdoIHRoZSBzY2hlbWEgZG9jdW1lbnQgYW5kIGNsZWFuaW5nIHVwIHRoZSBkYXRhIHR5 cGUgY2hhcmFjdGVyaXN0aWNzIChhcyBkaXNjdXNzZWQgcHJldmlvdXNseSksIEkgbm90aWNlIHRo YXQgdGhlIHJlZmVyZW5jZSB0byBYTUwtU2NoZW1hIGlzIHRvIHRoZSBPY3RvYmVyIDIwMDQgb25l IGFuZCBub3QgdGhlIDIwMTIgWE1MIFNjaGVtYS4mbmJzcDsgVGhlIElFVEYgd2lsbCBsaWtlbHkg cmVxdWlyZQ0KIHVzIHRvIHJlZmVyZW5jZSB0aGUgY3VycmVudCBzcGVjLCBzbyBJIHNob3VsZCBw cm9iYWJseSB1cGRhdGUgdGhlIHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgYXQgdGhlIGJpbmFyeSBhdHRyaWJ1dGUgcmVwcmVz ZW50YXRpb24sIEkgYW0gd29uZGVyaW5nIGlmIHdlIHNob3VsZCBjaGFuZ2UgdGhpcyB0byB0aGUg Y3VycmVudCBJRVRGIHNwZWNpZmljYXRpb24gd2hpY2ggaXM6IFJGQzQ2NDggcmF0aGVyIHRoYW4g cmVmZXJlbmNlIFhNTC1TY2hlbWEgMy4yLjE2IChvZiB0aGUgMjAwNCBzY2hlbWEgc3BlYykuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHdl IHdhbnQgdG8gZnVydGhlciBjbGFyaWZ5IHRoYXQgdGhlIGVuY29kaW5nIGJlOiBiYXNlNjR1cmw/ ICZuYnNwOyBOb3QgYSBqYXZhc2NyaXB0IGV4cGVydCwgYnV0IHdvbmRlcmluZyBpZiB3ZSBuZWVk IHRvIHVzZSB1cmwgc2FmZSBlbmNvZGluZz8gVGhpcyBtYXkgcmVzdWx0IGluIGEgbm9ybWF0aXZl IGNsYXJpZmljYXRpb24gZm9yIHNvbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmluZGVwZW5kZW50aWQu Y29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWFuIEdsYXplcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VuaW9yIERpcmVjdG9yLCBJZGVudGl0eTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0idGVs OiUyQjElMjAyMDIlMjAyNTUlMjAzMTY2IiB0YXJnZXQ9Il9ibGFuayI+JiM0MzsxIDIwMiAyNTUg MzE2NjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vaWdsYXplciIgdGFyZ2V0PSJfYmxhbmsi PkBpZ2xhemVyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2lt IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuIEdsYXplcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VuaW9yIERp cmVjdG9yLCBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzsxIDIwMiAyNTUgMzE2NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9p Z2xhemVyIiB0YXJnZXQ9Il9ibGFuayI+QGlnbGF6ZXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB1234F6CEA951219CE1455A2DA6110BN3PR0301MB1234_-- From nobody Tue Mar 3 14:11:36 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9830E1A89AD for ; Tue, 3 Mar 2015 14:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 BbuYHkAsj66v for ; Tue, 3 Mar 2015 14:11:29 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C501A8780 for ; Tue, 3 Mar 2015 14:11:29 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t23MBQkJ030313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 22:11:27 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t23MBQ8L017193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2015 22:11:26 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t23MBPfh025397; Tue, 3 Mar 2015 22:11:25 GMT MIME-Version: 1.0 Message-ID: <822a9e17-7e5f-46f2-8a85-88386195c31e@default> Date: Tue, 3 Mar 2015 14:11:25 -0800 (PST) From: Michael Frost Sender: Michael Frost To: "Morteza Ansari (moransar)" , Phil Hunt , SCIM WG References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> <95305152-5386-432e-8095-0d4c7a1d319b@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] Content-Type: multipart/alternative; boundary="__1425420685596117784abhmp0014.oracle.com" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: =?iso-8859-1?B?RXJpayBXYWhsc3Ry9m0gbmVYdXM=?= Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 22:11:35 -0000 --__1425420685596117784abhmp0014.oracle.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Indeed Morteza, you are correct.=A0 I would have preferred a different attr= ibute name, but even if we keep the same name, the proposed text changes ar= e very clear in addressing the issue I initially raised.=A0 Thanks. =A0 -mrf =A0 From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]=20 Sent: Tuesday, March 03, 2015 12:13 PM To: Michael Frost; Phil Hunt; SCIM WG Cc: Erik Wahlstr=F6m neXus Subject: Re: [scim] Proposed text for schema resources vs. messages =A0 Michael, =A0 I am reading this as you are OK with Phil's proposed text and agree it addr= esses the potential confusion on the use of schema in the messages but you = prefer a different attribute name (e.g. msgType) over schema. Is that a cor= rect read of your first paragraph? =A0 On your second point, I don't think we have ever had a use case for adding = non-resource type of data to the payload of messages so this has never come= up as a requirement or even as an extensibility option. I personally think= a change like that will have much bigger impact on the overall design of t= he API and modeling of the objects.=A0 =A0 And finally good catch on the typo. =A0Phil, can you please fix that in the= next revision? =A0 =A0 Cheers, Morteza =A0 From: Michael Frost Date: Monday, March 2, 2015 at 6:49 PM To: Phil Hunt = , "HYPERLINK "mailto:scim@ietf.org"scim@ietf.org" Cc: Erik Wahlstr=F6m neXus Subject: RE: [scim] Proposed text for schema resources vs. messages =A0 I would have preferred msgType just because it still feels like we are sort= of "overloading" the Schemas attribute based on context (message vs. resou= rce).=A0 So I guess I'm a little at odds with the contention that we are us= ing "Schemas" consistently.=A0 However the proposed text changes are quite = clear on the use of Schemas attributes in each context and certainly addres= ses my earlier concerns. =A0 Just as an aside, is it worth considering placing message type in all messa= ges and only placing schemas in resource objects?=A0 Do we ever anticipate = the need to carry some data in the payload of PUT/POST that is not part of = the resource and not conveniently encoded into query parameters?=A0 It woul= d place a consistent envelope around all requests/responses, but is perhaps= a bit unRESTful. =A0 Anyway, I noticed one minor type-o with paragraph 4 in section 3.1,=A0 open= ing sentence starts with "As SCIM in intended for use" should probably be "= As SCIM is intended for use". =A0 -mrf =A0 From: Phil Hunt=20 Sent: Friday, February 27, 2015 10:18 AM To: SCIM WG Cc: Erik Wahlstr=F6m neXus; Michael Frost Subject: [scim] Proposed text for schema resources vs. messages =A0 IMPORTANT: =A0We need to get this information published next week if we are= to make the Dallas meeting deadline. Please respond by Tuesday Mar 3, 8AM = Pacific. Based on feedback I will publish a minor revision to schemas doc T= uesday afternoon, and on Thursday revisions to API. =A0 In a previous thread (https://www.ietf.org/mail-archive/web/scim/current/ms= g02128.html), Erik proposed we use different attributes to distinguish betw= een SCIM messages and resources (msgType and schemas). =A0 I have taken a look at the impact on the documents and I think the solution= may be perceived as somewhat more complex than consistently using "schemas= ". =A0The main reason is that someone opening a JSON object now has to look= for two different attributes to tell if the object is a SCIM object of any= type. I am not sure this matters in practice, but it does "feel" complex f= rom a media type perspective. =A0 >From an editorial and IANA perspective, I believe using "msgType" means tha= t we have to build a separate IANA registry for messages distinct from sche= mas. Given that the review process is essentially the same, I'm not sure th= ere is a lot of benefit. I wonder then if clarifying text might not work as= well. =A0 What I have done is written a new introduction to section 3 of the API spec= ification. My hope is that this sets the stage for how SCIM protocol works = and clearly establishes the differences between SCIM resources and messages= . =A0 Action Item: =A0PLEASE INDICATE (by next Tuesday morning if possible): =A0 A. =A0Given the text below, does anyone strongly prefer using "msgType" ins= tead (and creating a new registry for it)? =A0 B. =A0Comments on the text. =A0 Thanks! =A0 PROPOSED TEXT: 3.=A0 SCIM Protocol =A0 3.1.=A0 Introduction =A0 =A0=A0 SCIM is a protocol based on HTTP [RFC7230].=A0 Along with HTTP heade= rs =A0=A0 and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM =A0=A0 resources as well as request parameters and response information suc= h =A0=A0 as errors in the form of JSON based messages.=A0 To identify this =A0=A0 content, SCIM uses a media type of "application/scim+json" (see =A0=A0 Section 8.1). =A0 =A0=A0 A SCIM resource is a JSON object that may be created, maintained, an= d =A0=A0 retrieved through HTTP methods as described in this document.=A0 Eac= h =A0=A0 JSON resource representation contains a "schemas" attribute that =A0=A0 contains a list of one or more URIs that indicate included SCIM =A0=A0 schemas that may be used to indicate the attributes contained within =A0=A0 a resource.=A0 When querying a SCIM service provider's "/Schemas" =A0=A0 endpoint for schema definition (see Section 8.7 =A0=A0 [I-D.ietf-scim-core-schema]), the response describes how a service =A0=A0 provider supports an attribute including schema meta-attributes such =A0=A0 as case-exactness, mutability, uniqueness, returnability, and whethe= r =A0=A0 it is required.=A0 While SCIM schemas and associated extension model= is =A0=A0 defined in [I-D.ietf-scim-core-schema], SCIM clients should expect =A0=A0 that some attribute schema MAY change from deployment to deployment. =A0=A0 In cases where SCIM may be used as an open protocol in front of an =A0=A0 application service, it is quite reasonable to expect that some =A0=A0 service providers MAY only support a sub-set of the schema defined i= n =A0=A0 [I-D.ietf-scim-core-schema]. =A0 =A0=A0 A SCIM message is a JSON object that conveys protocol parameters =A0=A0 about a SCIM request or response that are defined by this =A0=A0 specification.=A0 As with a SCIM resource, a SCIM message is a JSON =A0=A0 object that contains a "schemas" attribute with a URI whose namespac= e =A0=A0 prefix begins with "urn:ietf:params:scim:api:".=A0 As SCIM protocol =A0=A0 messages are fixed and defined by SCIM specifications and registered =A0=A0 extensions, SCIM message schemas using the above prefix URN SHALL NO= T =A0=A0 be discoverable using the "/Schemas" endpoint. =A0 =A0=A0 As SCIM in intended for use within cross-domain environments where =A0=A0 schemas MAY vary, techniques such as document validation, such as in =A0=A0 [XML-Schema], are not recommended.=A0 A SCIM service provider =A0=A0 interprets a request in the context of its own schema (which may be =A0=A0 different from the client's schema) and the processing rules =A0=A0 described for each SCIM request.=A0 The following sections in this =A0=A0 document define processing rules for SCIM that provide allowances fo= r =A0=A0 differences where appropriate.=A0 For example, in a SCIM PUT request= , =A0=A0 "readOnly" attributes are ignored, while "readWrite" attributes are =A0=A0 updated.=A0 There is no need for the client to discover which =A0=A0 attributes are "readOnly" and remove them from the PUT request in =A0=A0 advance in order to be accepted.=A0 Similarly a SCIM client SHOULD N= OT =A0=A0 expect a service provider to return SCIM resources with exactly the =A0=A0 same schema and values as submitted.=A0 SCIM responses SHALL reflect =A0=A0 resource state as interpreted by the SCIM service provider. =A0 3.2.=A0 SCIM Endpoints =A0 =A0=A0 The SCIM protocol specifies well-known endpoints and HTTP methods fo= r =A0=A0 managing resources defined in the core schema; i.e., "User" and =A0 Phil =A0 @independentid HYPERLINK "http://www.independentid.com"www.independentid.com HYPERLINK "mailto:phil.hunt@oracle.com"phil.hunt@oracle.com =A0 --__1425420685596117784abhmp0014.oracle.com Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Indeed Mo= rteza, you are correct.=A0 I would have preferred a different attribute nam= e, but even if we keep the same name, the proposed text changes are very cl= ear in addressing the issue I initially raised.=A0 Thanks.

 

-mrf

&n= bsp;

From: Morteza Ansari = (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 03, = 2015 12:13 PM
To: Michael Frost; Phil Hunt; SCIM WG
Cc:= Erik Wahlstr=F6m neXus
Subject: Re: [scim] Proposed text for sch= ema resources vs. messages

 

Michael,

 <= /p>

I am reading this as you are OK wit= h Phil’s proposed text and agree it addresses the potential confusion= on the use of schema in the messages but you prefer a different attribute = name (e.g. msgType) over schema. Is that a correct read of your first parag= raph?

 =

On your second point,= I don’t think we have ever had a use case for adding non-resource ty= pe of data to the payload of messages so this has never come up as a requir= ement or even as an extensibility option. I personally think a change like = that will have much bigger impact on the overall design of the API and mode= ling of the objects. 

 

= And finally good catch on the typo.  Phil, can you please fix that in = the next revision?

 

&= nbsp;

Cheers,

Morteza=

 

=

From: Michael Frost &= lt;michael.frost@oracle.com= >
Date: Monday, March 2, 2015 at 6:49 PM
To: Phil Hu= nt <phil.hunt@oracle.com>= , "scim@ietf.org" <scim@ietf.org>
Cc: Erik Wahlstr= =F6m neXus <erik.wahlst= rom@nexusgroup.com>, Morteza Ansari <moransar@cisco.com>
Subject: RE: [scim] Proposed= text for schema resources vs. messages

 

I would have preferred msgType just because it still fe= els like we are sort of “overloading” the Schemas attribute bas= ed on context (message vs. resource).  So I guess I’m a little a= t odds with the contention that we are using “Schemas” consiste= ntly.  However the proposed text changes are quite clear on the use of= Schemas attributes in each context and certainly addresses my earlier conc= erns.

 <= /p>

Just as an aside, is it worth considering pl= acing message type in all messages and only placing schemas in resource obj= ects?  Do we ever anticipate the need to carry some data in the payloa= d of PUT/POST that is not part of the resource and not conveniently encoded= into query parameters?  It would place a consistent envelope around a= ll requests/responses, but is perhaps a bit unRESTful.

 

Anyway, I noticed one minor type-o with paragraph 4 in section 3.1,&nb= sp; opening sentence starts with “As SCIM in intended for use” = should probably be “As SCIM is intended for use”.

&nbs= p;

-mrf

 

From: Phil Hunt
Sent: Friday, February 27, 2015 10:18 AM
To: SCIM WG
Cc: Erik Wahlstr=F6m neXus; Michael Frost
Subjec= t: [scim] Proposed text for schema resources vs. messages

 

IMPORTANT:  We need to get this in= formation published next week if we are to make the Dallas meeting deadline= . Please respond by Tuesday Mar 3, 8AM Pacific. Based on feedback I = will publish a minor revision to schemas doc Tuesday afternoon, and on Thur= sday revisions to API.

 

In a previous thread (https://www.ie= tf.org/mail-archive/web/scim/current/msg02128.html), Erik proposed we u= se different attributes to distinguish between SCIM messages and resources = (msgType and schemas).

 

I have taken a look at the impact on th= e documents and I think the solution may be perceived as somewhat more comp= lex than consistently using “schemas”.  The main reason is= that someone opening a JSON object now has to look for two different attri= butes to tell if the object is a SCIM object of any type. I am not sure thi= s matters in practice, but it does “feel” complex from a media = type perspective.

 

From an editorial and IANA perspective= , I believe using “msgType” means that we have to build a separ= ate IANA registry for messages distinct from schemas. Given that the review= process is essentially the same, I’m not sure there is a lot of bene= fit. I wonder then if clarifying text might not work as well.

 <= o:p>

What I have done is written a new introduction to section 3 of the AP= I specification. My hope is that this sets the stage for how SCIM protocol = works and clearly establishes the differences between SCIM resources and me= ssages.

 

<= b>Action Item:  PLEASE INDICATE (by next T= uesday morning if possible):

&= nbsp;

A.  Given the text below, does anyone strongly prefer usin= g “msgType” instead (and creating a new registry for it)?<= /o:p>

 

B.  Comments on the text.

 =

Thanks!

 

PROPOSED TEXT:

3.  SCIM Protocol
 
3.1.&nb=
sp; Introduction
&n=
bsp;
   S=
CIM is a protocol based on HTTP [RFC7230].  Along with HTTP headers
   and URIs=
, SCIM uses JSON [RFC7159] payloads to convey both SCIM
   resources as well as requ=
est parameters and response information such
   as errors in the form of JSON based =
messages.  To identify this
   content, SCIM uses a media type of "applica=
tion/scim+json" (see
   Section 8.1).
 
   A SCIM resource is a JSON object that may be created, mai=
ntained, and
 =
  retrieved through HTTP methods as described in this document.  =
Each
   J=
SON resource representation contains a "schemas" attribute that
   contain=
s a list of one or more URIs that indicate included SCIM<=
/pre>
   schemas that may be used=
 to indicate the attributes contained within
   a resource.  When querying a SC=
IM service provider's "/Schemas"
   endpoint for schema definition (see Se=
ction 8.7
 &nb=
sp; [I-D.ietf-scim-core-schema]), the response describes how a service=

   provider s=
upports an attribute including schema meta-attributes such
   as case-exactness, mut=
ability, uniqueness, returnability, and whether
   it is required.  While SCIM =
schemas and associated extension model is
   defined in [I-D.ietf-scim-core-schema],=
 SCIM clients should expect
   that some attribute schema MAY change from deployment=
 to deployment.
&nb=
sp;  In cases where SCIM may be used as an open protocol in front of a=
n
   appl=
ication service, it is quite reasonable to expect that some
   service providers MAY=
 only support a sub-set of the schema defined in
   [I-D.ietf-scim-core-schema].
 
   A SCIM message is a J=
SON object that conveys protocol parameters
   about a SCIM request or response that=
 are defined by this
   specification.  As with a SCIM resource, a SCIM message=
 is a JSON
 &n=
bsp; object that contains a "schemas" attribute with a URI whose =
namespace
 &nb=
sp; prefix begins with "urn:ietf:params:scim:api:".  As SCIM=
 protocol
 &nb=
sp; messages are fixed and defined by SCIM specifications and registered
   extensio=
ns, SCIM message schemas using the above prefix URN SHALL NOT
   be discoverable usi=
ng the "/Schemas" endpoint.
 
   As SCIM in intended for use within cross-domain environ=
ments where
 &=
nbsp; schemas MAY vary, techniques such as document validation, such as in<=
o:p>
   [XML-S=
chema], are not recommended.  A SCIM service provider
   interprets a request i=
n the context of its own schema (which may be
<=
span style=3D'color:black'>   different from the client's schema)=
 and the processing rules
   described for each SCIM request.  The following se=
ctions in this
&nbs=
p;  document define processing rules for SCIM that provide allowances =
for
   di=
fferences where appropriate.  For example, in a SCIM PUT request,=

   "read=
Only" attributes are ignored, while "readWrite" attributes a=
re
   upd=
ated.  There is no need for the client to discover which
   attributes are &quo=
t;readOnly" and remove them from the PUT request in<=
/pre>
   advance in order to be a=
ccepted.  Similarly a SCIM client SHOULD NOT
   expect a service provider to re=
turn SCIM resources with exactly the
   same schema and values as submitted.  S=
CIM responses SHALL reflect
   resource state as interpreted by the SCIM service pro=
vider.
 <=
/o:p>
3.2.  SCIM Endpoint=
s
 =

   The SCIM protoco=
l specifies well-known endpoints and HTTP methods for
   managing resources defined =
in the core schema; i.e., "User" and
=

 
=
--__1425420685596117784abhmp0014.oracle.com-- From nobody Wed Mar 4 00:38:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DEF1A1B2B for ; Wed, 4 Mar 2015 00:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Zpwuho0Kteig for ; Wed, 4 Mar 2015 00:38:23 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42EB1A1AAE for ; Wed, 4 Mar 2015 00:38:22 -0800 (PST) Received: by labgm9 with SMTP id gm9so3294733lab.7 for ; Wed, 04 Mar 2015 00:38:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vehMvh8PK0Ki4iPrrpHuh88MeAIFN195oroMfgYRWG4=; b=Y0ZtALTMdVmKDqjJa8dDhBl5cI94Ls0ajzoIEOdKhQcksQDNNUp6g9ScRyBiHrYxA5 LgEOVxhAzvaA8sLBRt/AVLp2u0MYr+naHkJy35fTAIr62JmCe0+hFPzdzSt+EYl5jU/m S4QA4KWGCb0LU/zkq3bWPMulJVIbgKbTHLh5gqlTFWpp191c5znvy/nqXTyth/ChwQmJ iItF+acTnuO8lenb6v7aB14IOP2igC7YqnYSWLkk4EHnoJg7kNoJFwmz7KsFzEZ3czGP X3VQ7n3GlQxF5VWdKFYNSykNeN7UEFTLSDXTQlvslGPRMMoHFThk03Tfz3G4XR4GcegA +Gmg== X-Gm-Message-State: ALoCoQkQfYOYS/BOmP4Zj8F19vk6H2SKFrXlx+m2hPXgdBA6Y8C4FyopCcFGM5TVONvqK/7IgilX X-Received: by 10.112.92.66 with SMTP id ck2mr2244514lbb.105.1425458301378; Wed, 04 Mar 2015 00:38:21 -0800 (PST) Received: from [109.105.104.222] (dhcp87.se-tug.nordu.net. [109.105.104.222]) by mx.google.com with ESMTPSA id ay12sm637473lab.6.2015.03.04.00.38.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 00:38:20 -0800 (PST) Message-ID: <54F6C47B.9060405@mnt.se> Date: Wed, 04 Mar 2015 09:38:19 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: scim@ietf.org, Phil Hunt References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> <95305152-5386-432e-8095-0d4c7a1d319b@default> <822a9e17-7e5f-46f2-8a85-88386195c31e@default> In-Reply-To: <822a9e17-7e5f-46f2-8a85-88386195c31e@default> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 08:38:24 -0000 On 03/03/2015 11:11 PM, Michael Frost wrote: > Indeed Morteza, you are correct. I would have preferred a different > attribute name, but even if we keep the same name, the proposed text > changes are very clear in addressing the issue I initially raised. Thanks. > OK by my account that means we are passed our second WGLC with no outstanding issues. Phil - if you cut a new version we'll stick it in the IESG inbox. Thx everyone for your great work getting us to this point! Cheers Leif From nobody Wed Mar 4 09:20:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5691A9106 for ; Wed, 4 Mar 2015 09:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tRrEWLWD774t for ; Wed, 4 Mar 2015 09:20:45 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78AF1A9105 for ; Wed, 4 Mar 2015 09:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34568; q=dns/txt; s=iport; t=1425489644; x=1426699244; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MvDqN0Wo5r3cO1e9//YLCBAyAQ0pSaKa1BV1E87xxBI=; b=jiPdEGs6uTXBlWF3N+NCfbqtY1e8oRKS5UAt/e8FrrDuG17u6AffXZsQ 1u6LKzpEDNRAfxu2JJV9K08ycH8O8+Lwvf9mqJcS8ptaKNC5I79+o/Nh4 KMTvdFlxsfTLDTb0b+jG/03N+4kU4PU3HzzIWTybKUe/t9oH1NBYpZvSA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSBwCYPvdU/4cNJK1QCoI/Q1JaBL5ogjGFcQKBLU0BAQEBAQF8hA8BAQEELRwrBRACAQgRAwEBASEBBgcyFAkIAgQBDQUbiBQN134BAQEBAQEBAQEBAQEBAQEBAQEBAQEXixKEEgsBAT4NAQMGAQYDhCIFjgCBf4V7g1GBGoMlglOJFoNAI4NubwGBAwcXBhx/AQEB X-IronPort-AV: E=Sophos;i="5.09,688,1418083200"; d="scan'208,217";a="128851654" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 04 Mar 2015 17:20:31 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t24HKV6m007329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 17:20:31 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 11:20:31 -0600 From: "Morteza Ansari (moransar)" To: Michael Frost , Phil Hunt , SCIM WG Thread-Topic: [scim] Proposed text for schema resources vs. messages Thread-Index: AQHQUrnIR/UTrLRuV0CCGnssMGLR450KeJKAgACdSICAAKdBgIAABNcA Date: Wed, 4 Mar 2015 17:20:30 +0000 Message-ID: References: <1C26F231-77F8-4DE9-B5BA-E62D88A3AE71@oracle.com> <95305152-5386-432e-8095-0d4c7a1d319b@default> <822a9e17-7e5f-46f2-8a85-88386195c31e@default> In-Reply-To: <822a9e17-7e5f-46f2-8a85-88386195c31e@default> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.84.85] Content-Type: multipart/alternative; boundary="_000_D11BE60111E940moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: =?Windows-1252?Q?Erik_Wahlstr=F6m_neXus?= Subject: Re: [scim] Proposed text for schema resources vs. messages X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:20:49 -0000 --_000_D11BE60111E940moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Michael. Cheers, Morteza From: Michael Frost > Date: Tuesday, March 3, 2015 at 2:11 PM To: Morteza Ansari >, Phil Hu= nt >, "scim@ietf.org" > Cc: Erik Wahlstr=F6m neXus > Subject: RE: [scim] Proposed text for schema resources vs. messages Indeed Morteza, you are correct. I would have preferred a different attrib= ute name, but even if we keep the same name, the proposed text changes are = very clear in addressing the issue I initially raised. Thanks. -mrf From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 03, 2015 12:13 PM To: Michael Frost; Phil Hunt; SCIM WG Cc: Erik Wahlstr=F6m neXus Subject: Re: [scim] Proposed text for schema resources vs. messages Michael, I am reading this as you are OK with Phil=92s proposed text and agree it ad= dresses the potential confusion on the use of schema in the messages but yo= u prefer a different attribute name (e.g. msgType) over schema. Is that a c= orrect read of your first paragraph? On your second point, I don=92t think we have ever had a use case for addin= g non-resource type of data to the payload of messages so this has never co= me up as a requirement or even as an extensibility option. I personally thi= nk a change like that will have much bigger impact on the overall design of= the API and modeling of the objects. And finally good catch on the typo. Phil, can you please fix that in the n= ext revision? Cheers, Morteza From: Michael Frost > Date: Monday, March 2, 2015 at 6:49 PM To: Phil Hunt >, "scim@ie= tf.org" > Cc: Erik Wahlstr=F6m neXus >, Morteza Ansari > Subject: RE: [scim] Proposed text for schema resources vs. messages I would have preferred msgType just because it still feels like we are sort= of =93overloading=94 the Schemas attribute based on context (message vs. r= esource). So I guess I=92m a little at odds with the contention that we ar= e using =93Schemas=94 consistently. However the proposed text changes are = quite clear on the use of Schemas attributes in each context and certainly = addresses my earlier concerns. Just as an aside, is it worth considering placing message type in all messa= ges and only placing schemas in resource objects? Do we ever anticipate th= e need to carry some data in the payload of PUT/POST that is not part of th= e resource and not conveniently encoded into query parameters? It would pl= ace a consistent envelope around all requests/responses, but is perhaps a b= it unRESTful. Anyway, I noticed one minor type-o with paragraph 4 in section 3.1, openin= g sentence starts with =93As SCIM in intended for use=94 should probably be= =93As SCIM is intended for use=94. -mrf From: Phil Hunt Sent: Friday, February 27, 2015 10:18 AM To: SCIM WG Cc: Erik Wahlstr=F6m neXus; Michael Frost Subject: [scim] Proposed text for schema resources vs. messages IMPORTANT: We need to get this information published next week if we are t= o make the Dallas meeting deadline. Please respond by Tuesday Mar 3, 8AM Pa= cific. Based on feedback I will publish a minor revision to schemas doc Tue= sday afternoon, and on Thursday revisions to API. In a previous thread (https://www.ietf.org/mail-archive/web/scim/current/ms= g02128.html), Erik proposed we use different attributes to distinguish betw= een SCIM messages and resources (msgType and schemas). I have taken a look at the impact on the documents and I think the solution= may be perceived as somewhat more complex than consistently using =93schem= as=94. The main reason is that someone opening a JSON object now has to lo= ok for two different attributes to tell if the object is a SCIM object of a= ny type. I am not sure this matters in practice, but it does =93feel=94 com= plex from a media type perspective. >From an editorial and IANA perspective, I believe using =93msgType=94 means= that we have to build a separate IANA registry for messages distinct from = schemas. Given that the review process is essentially the same, I=92m not s= ure there is a lot of benefit. I wonder then if clarifying text might not w= ork as well. What I have done is written a new introduction to section 3 of the API spec= ification. My hope is that this sets the stage for how SCIM protocol works = and clearly establishes the differences between SCIM resources and messages= . Action Item: PLEASE INDICATE (by next Tuesday morning if possible): A. Given the text below, does anyone strongly prefer using =93msgType=94 i= nstead (and creating a new registry for it)? B. Comments on the text. Thanks! PROPOSED TEXT: 3. SCIM Protocol 3.1. Introduction SCIM is a protocol based on HTTP [RFC7230]. Along with HTTP headers and URIs, SCIM uses JSON [RFC7159] payloads to convey both SCIM resources as well as request parameters and response information such as errors in the form of JSON based messages. To identify this content, SCIM uses a media type of "application/scim+json" (see Section 8.1). A SCIM resource is a JSON object that may be created, maintained, and retrieved through HTTP methods as described in this document. Each JSON resource representation contains a "schemas" attribute that contains a list of one or more URIs that indicate included SCIM schemas that may be used to indicate the attributes contained within a resource. When querying a SCIM service provider's "/Schemas" endpoint for schema definition (see Section 8.7 [I-D.ietf-scim-core-schema]), the response describes how a service provider supports an attribute including schema meta-attributes such as case-exactness, mutability, uniqueness, returnability, and whether it is required. While SCIM schemas and associated extension model is defined in [I-D.ietf-scim-core-schema], SCIM clients should expect that some attribute schema MAY change from deployment to deployment. In cases where SCIM may be used as an open protocol in front of an application service, it is quite reasonable to expect that some service providers MAY only support a sub-set of the schema defined in [I-D.ietf-scim-core-schema]. A SCIM message is a JSON object that conveys protocol parameters about a SCIM request or response that are defined by this specification. As with a SCIM resource, a SCIM message is a JSON object that contains a "schemas" attribute with a URI whose namespace prefix begins with "urn:ietf:params:scim:api:". As SCIM protocol messages are fixed and defined by SCIM specifications and registered extensions, SCIM message schemas using the above prefix URN SHALL NOT be discoverable using the "/Schemas" endpoint. As SCIM in intended for use within cross-domain environments where schemas MAY vary, techniques such as document validation, such as in [XML-Schema], are not recommended. A SCIM service provider interprets a request in the context of its own schema (which may be different from the client's schema) and the processing rules described for each SCIM request. The following sections in this document define processing rules for SCIM that provide allowances for differences where appropriate. For example, in a SCIM PUT request, "readOnly" attributes are ignored, while "readWrite" attributes are updated. There is no need for the client to discover which attributes are "readOnly" and remove them from the PUT request in advance in order to be accepted. Similarly a SCIM client SHOULD NOT expect a service provider to return SCIM resources with exactly the same schema and values as submitted. SCIM responses SHALL reflect resource state as interpreted by the SCIM service provider. 3.2. SCIM Endpoints The SCIM protocol specifies well-known endpoints and HTTP methods for managing resources defined in the core schema; i.e., "User" and Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_D11BE60111E940moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <48383523258DF643B9925AB1E5A62D0A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Michael.


Cheers,
Morteza

From: Michael Frost <michael.frost@oracle.com>
Date: Tuesday, March 3, 2015 at 2:1= 1 PM
To: Morteza Ansari <moransar@cisco.com>, Phil Hunt <phil.hunt@oracle.com>, "scim@ietf.org" <scim@ietf.org>
Cc: Erik Wahlstr=F6m neXus <erik.wahlstrom@nexusgroup.com<= /a>>
Subject: RE: [scim] Proposed text f= or schema resources vs. messages

Indeed Morteza, you are correct.&nb= sp; I would have preferred a different attribute name, but even if we keep = the same name, the proposed text changes are very clear in addressing the issue I initially raised.  Thanks.

 

-mrf

 

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 03, 2015 12:13 PM
To: Michael Frost; Phil Hunt; SCIM WG
Cc: Erik Wahlstr=F6m neXus
Subject: Re: [scim] Proposed text for schema resources vs. messages<= o:p>

 

Michael,

 

I am reading this as you are OK with Phil=92= s proposed text and agree it addresses the potential confusion on the use o= f schema in the messages but you prefer a different attribute name (e.g. msgType) over schema. Is that a correct r= ead of your first paragraph?

 

On your second point, I don=92t think we hav= e ever had a use case for adding non-resource type of data to the payload o= f messages so this has never come up as a requirement or even as an extensibility option. I personally think a cha= nge like that will have much bigger impact on the overall design of the API= and modeling of the objects. 

 

And finally good catch on the typo.  Ph= il, can you please fix that in the next revision?

 

 

Cheers,

Morteza

 

From: Michael Frost <michael.frost@oracle.com>
Date: Monday, March 2, 2015 at 6:49 PM
To: Phil Hunt <phil.hunt@= oracle.com>, "scim@ietf.org" <scim@ietf.org>
Cc: Erik Wahlstr=F6m neXus <erik.wahlstrom@nexusgroup.com>, Morteza Ansari <moransar@cisco.com>
Subject: RE: [scim] Proposed text for schema resources vs. messages<= o:p>

 

I would have preferred msgType just= because it still feels like we are sort of =93overloading=94 the Schemas a= ttribute based on context (message vs. resource).  So I guess I=92m a little at odds with the contention that we are using = =93Schemas=94 consistently.  However the proposed text changes are qui= te clear on the use of Schemas attributes in each context and certainly add= resses my earlier concerns.

 

Just as an aside, is it worth consi= dering placing message type in all messages and only placing schemas in res= ource objects?  Do we ever anticipate the need to carry some data in the payload of PUT/POST that is not part of= the resource and not conveniently encoded into query parameters?  It = would place a consistent envelope around all requests/responses, but is per= haps a bit unRESTful.<= /p>

 

Anyway, I noticed one minor type-o = with paragraph 4 in section 3.1,  opening sentence starts with =93As S= CIM in intended for use=94 should probably be =93As SCIM is intended for use=94.=

 

-mrf

 

From: Phil Hunt
Sent: Friday, February 27, 2015 10:18 AM
To: SCIM WG
Cc: Erik Wahlstr=F6m neXus; Michael Frost
Subject: [scim] Proposed text for schema resources vs. messages

 =

IMPORTANT:  We need= to get this information published next week if we are to make the Dallas m= eeting deadline. Please respond by Tuesday Mar 3, 8AM Pacific. Based on feedback I will publish a minor revision to schemas doc Tuesda= y afternoon, and on Thursday revisions to API.

 =

In a previous thread (= https://www.ietf.org/mail-archive/web/scim/current/msg02128.html), Erik= proposed we use different attributes to distinguish between SCIM messages and resources (msgType and schemas).<= o:p>

 =

I have taken a look at t= he impact on the documents and I think the solution may be perceived as som= ewhat more complex than consistently using =93schemas=94.  The main re= ason is that someone opening a JSON object now has to look for two different attributes to tell if the object is a SCIM o= bject of any type. I am not sure this matters in practice, but it does =93f= eel=94 complex from a media type perspective.

 =

From an editorial and IA= NA perspective, I believe using =93msgType=94 means that we have to build a= separate IANA registry for messages distinct from schemas. Given that the = review process is essentially the same, I=92m not sure there is a lot of benefit. I wonder then if clarifying text= might not work as well.

 =

What I have done is writ= ten a new introduction to section 3 of the API specification. My hope is th= at this sets the stage for how SCIM protocol works and clearly establishes = the differences between SCIM resources and messages.

 =

Action Item:  PL= EASE INDICATE (by next Tuesday morning if possible):

 =

A.  Given the text = below, does anyone strongly prefer using =93msgType=94 instead (and creatin= g a new registry for it)?

 =

B.  Comments on the= text.

 =

Thanks!

 =

PROPOSED TEXT:

3.  SCIM Protocol
 
3.1.  Introduction<=
/pre>

 


   SCIM is a protocol based on H=
TTP [RFC7230].  Along with HTTP headers


   and URIs, SCIM uses JSON [RFC=
7159] payloads to convey both SCIM


   resources as well as request =
parameters and response information such


   as errors in the form of JSON=
 based messages.  To identify this


   content, SCIM uses a media ty=
pe of "application/scim+json" (see


   Section 8.1).


 


   A SCIM resource is a JSON obj=
ect that may be created, maintained, and


   retrieved through HTTP method=
s as described in this document.  Each


   JSON resource representation =
contains a "schemas" attribute that


   contains a list of one or mor=
e URIs that indicate included SCIM


   schemas that may be used to i=
ndicate the attributes contained within


   a resource.  When queryi=
ng a SCIM service provider's "/Schemas"


   endpoint for schema definitio=
n (see Section 8.7


   [I-D.ietf-scim-core-schema]),=
 the response describes how a service


   provider supports an attribut=
e including schema meta-attributes such


   as case-exactness, mutability=
, uniqueness, returnability, and whether


   it is required.  While S=
CIM schemas and associated extension model is


   defined in [I-D.ietf-scim-cor=
e-schema], SCIM clients should expect


   that some attribute schema MA=
Y change from deployment to deployment.


   In cases where SCIM may be us=
ed as an open protocol in front of an


   application service, it is qu=
ite reasonable to expect that some


   service providers MAY only su=
pport a sub-set of the schema defined in


   [I-D.ietf-scim-core-schema].<=
o:p>


 


   A SCIM message is a JSON obje=
ct that conveys protocol parameters


   about a SCIM request or respo=
nse that are defined by this


   specification.  As with =
a SCIM resource, a SCIM message is a JSON


   object that contains a "=
schemas" attribute with a URI whose namespace


   prefix begins with "urn:=
ietf:params:scim:api:".  As SCIM protocol


   messages are fixed and define=
d by SCIM specifications and registered


   extensions, SCIM message sche=
mas using the above prefix URN SHALL NOT


   be discoverable using the &qu=
ot;/Schemas" endpoint.


 


   As SCIM in intended for use w=
ithin cross-domain environments where


   schemas MAY vary, techniques =
such as document validation, such as in


   [XML-Schema], are not recomme=
nded.  A SCIM service provider


   interprets a request in the c=
ontext of its own schema (which may be


   different from the client's s=
chema) and the processing rules


   described for each SCIM reque=
st.  The following sections in this


   document define processing ru=
les for SCIM that provide allowances for


   differences where appropriate=
.  For example, in a SCIM PUT request,


   "readOnly" attribut=
es are ignored, while "readWrite" attributes are


   updated.  There is no ne=
ed for the client to discover which


   attributes are "readOnly=
" and remove them from the PUT request in


   advance in order to be accept=
ed.  Similarly a SCIM client SHOULD NOT


   expect a service provider to =
return SCIM resources with exactly the


   same schema and values as sub=
mitted.  SCIM responses SHALL reflect


   resource state as interpreted=
 by the SCIM service provider.


 


3.2.  SCIM Endpoints


 


   The SCIM protocol specifies w=
ell-known endpoints and HTTP methods for


   managing resources defined in=
 the core schema; i.e., "User" and




 
--_000_D11BE60111E940moransarciscocom_-- From nobody Wed Mar 4 12:17:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C31ACE4E for ; Wed, 4 Mar 2015 12:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2n4NfMt_1BmH for ; Wed, 4 Mar 2015 12:17:35 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44AD1AC7E7 for ; Wed, 4 Mar 2015 12:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23782; q=dns/txt; s=iport; t=1425500255; x=1426709855; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HTlNymRvTd50M/gH4ggH0+CNZOLtv4UXCjw3RhA2Qso=; b=enVMLmofgox5s0gQQ+oMx6YZ3cMY0sDm44QXZ4oxdOW5ybYOmrYfUgwY z7Fk9kDF4AaaS63E0NInTlkdgMBDqGaOjI6Fz/96gTZffi3pzL4ExUn13 9WU33SKlJm8UZZ63DNRh0oTDHNMlEWr6dicCJQuFZW2zEQvf6EI0uG3Da U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DSBwDRZ/dU/4MNJK1RBgOCP0NSWgS+aYInAQmFcQKBLk0BAQEBAQF8hA8BAQEEAQEBKhwiAwsQAgEIBwcDAwEBASEHBycLFAkIAgQBCQQFiC8N12UBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixKEARJKAQwEBgEJCIQaBYRsgTuHXYF/g2OCGIFXgXuBGhGDFYhPhlsjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,689,1418083200"; d="scan'208,217";a="400997216" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 04 Mar 2015 20:17:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t24KHYmu006230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 20:17:34 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 14:17:34 -0600 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , Ian Glazer , Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwcLF9uj8C5JEKG/kSpC8hqkZ0KAzgAgAAFNoCAADktAIABBmOAgABPNoCAAQ2IgA== Date: Wed, 4 Mar 2015 20:17:33 +0000 Message-ID: References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.84.85] Content-Type: multipart/alternative; boundary="_000_D11CA14811EC6Cmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:17:38 -0000 --_000_D11CA14811EC6Cmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Wearing individual contributor hat: I think there is some confusion here on= the x509Certificate attribute. The definition for this attribute comes mo= re or less directly from SCIM 1.1 spec. The idea is that certificates are s= tored as DER encoded using SCIM binary data type which is base64 encoded st= rings. As such I don=92t believe there is any issues with representing any= type of certificate given DER encoding handles that fully and base64 encod= ing is only done for transferring the DER encoded certs over SCIM API. And = given the attribute is plural, we can have many certificate values (each DE= R encoded and then base64 encoded). As chair: Given the confusion, I certainly think we should as minimum adjus= t the text for this attribute to be more precise and clear about the intent= ion. Phil, can you propose some text for that clarification. Also, given = this definition does anyone think this is something that should be revisite= d? Cheers, Morteza From: Anthony Nadalin > Date: Tuesday, March 3, 2015 at 12:12 PM To: Ian Glazer >, Phi= l Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Base64 Encoding for Binary Attributes I=92m confused, why would we not just use what JOSE used for Binary Encodin= g ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer Sent: Tuesday, March 3, 2015 7:29 AM To: Phil Hunt Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes I am okay with this change On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt > wrote: All, Michael has reminded me that x509Certificate is DER encoded binary which is= in conflict with our current binary definition. I recommend changing the definition of Binary FROM: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded as a base 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is case-exact and has no uniqueness. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String per Section 2.7 [RFC7159]. TO: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded in Base 64 encoding as specified in Section 4 [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. In JSON representation, the encoded values are represented as a JSON String per Section 7 [RFC7159]. A binary is case-exact and has no uniqueness. Further, I would recommend changing x509certificates FROM: x509Certificates A list of certificates issued to the User. Values are Binary (Section 2.2.6) and DER encoded x509. This value has NO canonical types. TO: x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are Base 64 encoded x509 per Section 4 [RFC4648]. Important: This is a normative change as we are correcting the previous = =93DER=94 encoding to be base 64 encoding for consistency with the definiti= on of binary and JSON compatibility. If possible, please have comments to the list by 5PM Pacific tomorrow (Tues= day). I would like to publish draft 17 of core-schema in order to be able = to publish the changes to the API draft later in the week. Note that the p= roposed changes for tomorrow include expanding section 8.7 to include schem= as for fixed (non-resource) service provider schemas: ServiceProviderConfi= g, ResourceType, Schema. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Mar 2, 2015, at 12:25 PM, Phil Hunt > wrote: I think it should be one form. My recommendation would be base64url for max utility. Especially if we star= t defining schema related to JWT keys (JWK) from OAuth and JOSE. Phil On Mar 2, 2015, at 12:06, Ian Glazer > wrote: Would this be base64url "required" or "recommended"? Would the encoding type be a declared attribute of the SP? On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt > wrote: I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wi= ll likely require us to reference the current spec, so I should probably up= date the reference. Looking at the binary attribute representation, I am wondering if we should= change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). Do we want to further clarify that the encoding be: base64url? Not a java= script expert, but wondering if we need to use url safe encoding? This may = result in a normative clarification for some. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D11CA14811EC6Cmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5236E3BB4EE4E945B4692C3E299F66F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Wearing individual contributor hat: I think there is some confusion he= re on the x509Certificate attribute.  The definition for this attribut= e comes more or less directly from SCIM 1.1 spec. The idea is that certific= ates are stored as DER encoded using SCIM binary data type which is base64 encoded strings.  As such I don= =92t believe there is any issues with representing any type of certificate = given DER encoding handles that fully and base64 encoding is only done for = transferring the DER encoded certs over SCIM API. And given the attribute is plural, we can have many certificate = values (each DER encoded and then base64 encoded).

As chair: Given the confusion, I certainly think we should as minimum = adjust the text for this attribute to be more precise and clear about the i= ntention.  Phil, can you propose some text for that clarification. &nb= sp;Also, given this definition does anyone think this is something that should be revisited?


Cheers,
Morteza

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 3, 2015 at 12:= 12 PM
To: Ian Glazer <iglazer@salesforce.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: Re: [scim] Base64 Encoding= for Binary Attributes

I=92m confused, why would we not ju= st use what JOSE used for Binary Encoding ?

&n= bsp;

From: scim [m= ailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer
Sent: Tuesday, March 3, 2015 7:29 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

I am okay with this change

 

On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

All,

 

Michael has reminded me that x509Certificate is DER = encoded binary which is in conflict with our current binary definition.

 

I recommend changing the definition of Binary FROM:<= o:p>

2.2.6.  Binar=
y
 
   Arbitrary binary data.  The attribute value MUST be =
encoded as a base
   64 encoding as specified in Section 3.2.16 [XML-Schema].&=
nbsp; A binary is
   case-exact and has no uniqueness.
 
   Values represented in JSON MUST conform to the XML constr=
aints above
   and are represented as a JSON String per Section 2.7 [RFC=
7159].

TO:

2.2.6.  Binar=
y
 
   Arbitrary binary data.  The attribute value MUST be =
encoded in Base
   64 encoding as specified in Section 4 [RFC4648]. =
 In cases where a
   URL-safe encoding is required, the attribute definitio=
n MAY specify
   Base 64 URL encoding MAY be used as per Section 5 [RFC=
4648].
 
   In JSON representation, the encoded values are represe=
nted as a JSON
   String per Section 7 [RFC7159].  A binary is case=
-exact and has no
   uniqueness.

Further, I would recommend changing x509certificates= FROM:

   x509C=
ertificates
      A list of certificates issued to the Us=
er.  Values are Binary
      (Section 2.2.6) and DER encoded x509.&n=
bsp; This value has NO canonical
      types.

TO:

   x509C=
ertificates
      A list of certificates issued to the Us=
er.  Values are binary
      (Section 2.2.6) and are Base 64 enco=
ded x509 per Section 4
      [RFC4648].

 

Important:  This is a normative change as we= are correcting the previous =93DER=94 encoding to be base 64 encoding for = consistency with the definition of binary and JSON compatibility.<= /o:p>

 

If possible, please have comments to the list = by 5PM Pacific tomorrow (Tuesday).  I would like to publish dr= aft 17 of core-schema in order to be able to publish the changes to the API= draft later in the week.  Note that the proposed changes for tomorrow include expanding section 8.7 to include sch= emas for fixed (non-resource) service provider schemas:  ServiceProvid= erConfig, ResourceType, Schema.

 

Cheers,

 

 

On Mar 2, 2015, at 12:25 PM, Phil Hunt <phil.hunt@oracle.com= > wrote:

 

I think it should be one form. 

 

My recommendation would be base64url for max utility= . Especially if we start defining schema related to JWT keys (JWK) from OAu= th and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:<= /p>

Would this be base64url "required" or &quo= t;recommended"?

 

Would the encoding type be a declared attribute of t= he SP?

 

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 

I was looking through the schema document and cleani= ng up the data type characteristics (as discussed previously), I notice tha= t the reference to XML-Schema is to the October 2004 one and not the 2012 X= ML Schema.  The IETF will likely require us to reference the current spec, so I should probably update the referenc= e.

 

Looking at the binary attribute representation, I am= wondering if we should change this to the current IETF specification which= is: RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema sp= ec).

 

Do we want to further clarify that the encoding be: = base64url?   Not a javascript expert, but wondering if we need to use = url safe encoding? This may result in a normative clarification for some.

 


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



 

--

Ian Glazer

Senior Director, Identity

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

 



 

--

Ian Glazer

Senior Director, Identity

+1 202 255 3166

--_000_D11CA14811EC6Cmoransarciscocom_-- From nobody Wed Mar 4 12:20:42 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31EB1ACE5C for ; Wed, 4 Mar 2015 12:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aCHwPaKrBTql for ; Wed, 4 Mar 2015 12:20:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5291ACE5A for ; Wed, 4 Mar 2015 12:20:31 -0800 (PST) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.99.14; Wed, 4 Mar 2015 20:20:06 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0099.004; Wed, 4 Mar 2015 20:20:07 +0000 From: Anthony Nadalin To: "Morteza Ansari (moransar)" , Ian Glazer , Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwd+8eoLMUuT02ylZLB3DAVWJ0JnqMAgAAFNYCAADkuAIABBmOAgABO9TCAAZPogIAAADbw Date: Wed, 4 Mar 2015 20:20:06 +0000 Message-ID: References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(76576001)(86362001)(76176999)(33656002)(2900100001)(2950100001)(15975445007)(584604001)(93886004)(74316001)(16236675004)(19580405001)(2656002)(19617315012)(16601075003)(19300405004)(62966003)(50986999)(54356999)(46102003)(102836002)(40100003)(19625215002)(92566002)(122556002)(77156002)(87936001)(99286002)(106116001)(19580395003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12341B2218492D1581D31262A61E0BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2015 20:20:07.0740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:20:41 -0000 --_000_BN3PR0301MB12341B2218492D1581D31262A61E0BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should just take the text from JWK on x5c or x5u From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Wednesday, March 4, 2015 12:18 PM To: Anthony Nadalin; Ian Glazer; Phil Hunt Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes Wearing individual contributor hat: I think there is some confusion here on= the x509Certificate attribute. The definition for this attribute comes mo= re or less directly from SCIM 1.1 spec. The idea is that certificates are s= tored as DER encoded using SCIM binary data type which is base64 encoded st= rings. As such I don't believe there is any issues with representing any t= ype of certificate given DER encoding handles that fully and base64 encodin= g is only done for transferring the DER encoded certs over SCIM API. And gi= ven the attribute is plural, we can have many certificate values (each DER = encoded and then base64 encoded). As chair: Given the confusion, I certainly think we should as minimum adjus= t the text for this attribute to be more precise and clear about the intent= ion. Phil, can you propose some text for that clarification. Also, given = this definition does anyone think this is something that should be revisite= d? Cheers, Morteza From: Anthony Nadalin > Date: Tuesday, March 3, 2015 at 12:12 PM To: Ian Glazer >, Phi= l Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Base64 Encoding for Binary Attributes I'm confused, why would we not just use what JOSE used for Binary Encoding = ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer Sent: Tuesday, March 3, 2015 7:29 AM To: Phil Hunt Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes I am okay with this change On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt > wrote: All, Michael has reminded me that x509Certificate is DER encoded binary which is= in conflict with our current binary definition. I recommend changing the definition of Binary FROM: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded as a base 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is case-exact and has no uniqueness. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String per Section 2.7 [RFC7159]. TO: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded in Base 64 encoding as specified in Section 4 [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. In JSON representation, the encoded values are represented as a JSON String per Section 7 [RFC7159]. A binary is case-exact and has no uniqueness. Further, I would recommend changing x509certificates FROM: x509Certificates A list of certificates issued to the User. Values are Binary (Section 2.2.6) and DER encoded x509. This value has NO canonical types. TO: x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are Base 64 encoded x509 per Section 4 [RFC4648]. Important: This is a normative change as we are correcting the previous "D= ER" encoding to be base 64 encoding for consistency with the definition of = binary and JSON compatibility. If possible, please have comments to the list by 5PM Pacific tomorrow (Tues= day). I would like to publish draft 17 of core-schema in order to be able = to publish the changes to the API draft later in the week. Note that the p= roposed changes for tomorrow include expanding section 8.7 to include schem= as for fixed (non-resource) service provider schemas: ServiceProviderConfi= g, ResourceType, Schema. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Mar 2, 2015, at 12:25 PM, Phil Hunt > wrote: I think it should be one form. My recommendation would be base64url for max utility. Especially if we star= t defining schema related to JWT keys (JWK) from OAuth and JOSE. Phil On Mar 2, 2015, at 12:06, Ian Glazer > wrote: Would this be base64url "required" or "recommended"? Would the encoding type be a declared attribute of the SP? On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt > wrote: I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wi= ll likely require us to reference the current spec, so I should probably up= date the reference. Looking at the binary attribute representation, I am wondering if we should= change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). Do we want to further clarify that the encoding be: base64url? Not a java= script expert, but wondering if we need to use url safe encoding? This may = result in a normative clarification for some. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_BN3PR0301MB12341B2218492D1581D31262A61E0BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should just take the text from JWK= on x5c or x5u

&nbs= p;

From: Morteza Ansari (moransar) [mai= lto:moransar@cisco.com]
Sent: Wednesday, March 4, 2015 12:18 PM
To: Anthony Nadalin; Ian Glazer; Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

Wearing individual contributor hat: I t= hink there is some confusion here on the x509Certificate attribute.  T= he definition for this attribute comes more or less directly from SCIM 1.1 spec. The idea is that certificates are stored as D= ER encoded using SCIM binary data type which is base64 encoded strings. &nb= sp;As such I don’t believe there is any issues with representing any = type of certificate given DER encoding handles that fully and base64 encoding is only done for transferring the DER encod= ed certs over SCIM API. And given the attribute is plural, we can have many= certificate values (each DER encoded and then base64 encoded).<= /span>

 

As chair: Given the confusion, I certai= nly think we should as minimum adjust the text for this attribute to be mor= e precise and clear about the intention.  Phil, can you propose some text for that clarification.  Also, given this d= efinition does anyone think this is something that should be revisited?

 

 

Cheers,

Morteza

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 3, 2015 at 12:12 PM
To: Ian Glazer <iglazer= @salesforce.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

I’m confused, why would we not = just use what JOSE used for Binary Encoding ?

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer
Sent: Tuesday, March 3, 2015 7:29 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

 =

I am okay with this chan= ge

 =

On Mon, Mar 2, 2015 at 6= :50 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

All,

 =

Michael has reminded me = that x509Certificate is DER encoded binary which is in conflict with our cu= rrent binary definition.

 =

I recommend changing the= definition of Binary FROM:

2.2.6.  Binary
 
   Arbitrary binary data.  =
The attribute value MUST be encoded as a base
   64 encoding as specified in S=
ection 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniquen=
ess.
 
   Values represented in JSON MU=
ST conform to the XML constraints above
   and are represented as a JSON=
 String per Section 2.7 [RFC7159].

TO: 

2.2.6.  Binary
 
   Arbitrary binary data.  =
The attribute value MUST be encoded in Base
   64 encoding as specified i=
n Section 4 [RFC4648].  In cases where a
   URL-safe encoding is requi=
red, the attribute definition MAY specify
   Base 64 URL encoding MAY b=
e used as per Section 5 [RFC4648].
 
   In JSON representation, th=
e encoded values are represented as a JSON
   String per Section 7 [RFC7=
159].  A binary is case-exact and has no
   uniqueness.

Further, I would recomme= nd changing x509certificates FROM:

   x509Certificates
      A list of c=
ertificates issued to the User.  Values are Binary

      (Section 2.=
2.6) and DER encoded x509.  This value has NO canonical


      types.=

TO: 

   x509Certificates
      A list of c=
ertificates issued to the User.  Values are binary
      (Section 2.=
2.6) and are Base 64 encoded x509 per Section 4

      [RFC4648=
].

 =

Important:  This= is a normative change as we are correcting the previous “DER” = encoding to be base 64 encoding for consistency with the definition of bina= ry and JSON compatibility.

 =

If possible, pleas= e have comments to the list by 5PM Pacific tomorrow (Tuesday).  I would like to publish draft 17 of co= re-schema in order to be able to publish the changes to the API draft later in the week.  Note that the proposed c= hanges for tomorrow include expanding section 8.7 to include schemas for fi= xed (non-resource) service provider schemas:  ServiceProviderConfig, R= esourceType, Schema.

 =

Cheers,

 =

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 =

On Mar 2, 2015, at 12:25= PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 =

I think it should be one= form. 

 =

My recommendation would = be base64url for max utility. Especially if we start defining schema relate= d to JWT keys (JWK) from OAuth and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:<= /span>

Would this be base64url = "required" or "recommended"?

 =

Would the encoding type = be a declared attribute of the SP?

 =

On Mon, Mar 2, 2015 at 2= :07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 =

I was looking through th= e schema document and cleaning up the data type characteristics (as discuss= ed previously), I notice that the reference to XML-Schema is to the October= 2004 one and not the 2012 XML Schema.  The IETF will likely require us to reference the current spec, so I should= probably update the reference.

 =

Looking at the binary at= tribute representation, I am wondering if we should change this to the curr= ent IETF specification which is: RFC4648 rather than reference XML-Schema 3= .2.16 (of the 2004 schema spec).

 =

Do we want to further cl= arify that the encoding be: base64url?   Not a javascript expert, but = wondering if we need to use url safe encoding? This may result in a normati= ve clarification for some.

 =

Phil

 

@independentid

phil.hunt@oracle.com<= /span>

 =


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



 =

--

Ian Glazer

Senior Director, Identit= y

________________________= _______________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

 =



 =

--

Ian Glazer

Senior Director, Identit= y

+1 202 255 3166=

--_000_BN3PR0301MB12341B2218492D1581D31262A61E0BN3PR0301MB1234_-- From nobody Wed Mar 4 12:44:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276A51ACED4 for ; Wed, 4 Mar 2015 12:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 2i6ahgk3NGAx for ; Wed, 4 Mar 2015 12:44:19 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E361ACED2 for ; Wed, 4 Mar 2015 12:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32620; q=dns/txt; s=iport; t=1425501859; x=1426711459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VoXFxXy75jjpRcLGW6HeMFSfqtRPX6L7glrcXe841dc=; b=MluyvHxTSbycZ3rVse1HIn1EuEw5iHGSp4qRPZZbaTOMQLFN5ItnFsmy NFiN7WVLImwYcrANqOuQ1AlHKDmVZ7yX8I9yq2thDNY7/UL9ZKl/09bwH 9iqJsu/d9vCdCgHE7AJPjFrq/oHS+nzDGfUzBWk0waYjiKaE6vMq2OG+X Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DTBwB4bfdU/4kNJK1RBgOCP0NSWgS+aYIOGQEJhXECgS5NAQEBAQEBfIQPAQEBBAEBASocIgMLEAIBCAcHAwMBAQEhAQYHJwsUCQgCBAEJBAWILw3XdAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLEoQBEkoBDAQGAQkIhBoFhGyBO4ddgX+DY4IYgVeBe4EaEYMViE+GWyODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,689,1418083200"; d="scan'208,217";a="400933668" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 04 Mar 2015 20:44:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t24KiHQY012019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 20:44:17 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 14:44:17 -0600 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , Ian Glazer , Phil Hunt Thread-Topic: [scim] Base64 Encoding for Binary Attributes Thread-Index: AQHQVRwcLF9uj8C5JEKG/kSpC8hqkZ0KAzgAgAAFNoCAADktAIABBmOAgABPNoCAAQ2IgIAAhtYA//+Ao4A= Date: Wed, 4 Mar 2015 20:44:17 +0000 Message-ID: References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.84.85] Content-Type: multipart/alternative; boundary="_000_D11CAE4511ED8Bmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:44:22 -0000 --_000_D11CAE4511ED8Bmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We certainly should take as much of it as possible from x5c in JWK. The on= ly part that might not apply to us is the array part given this attribute i= s multivalued which means the array is probably not needed. I believe Phil= is planning on reaching out to Mike Jones to confirm that. Cheers, Morteza From: Anthony Nadalin > Date: Wednesday, March 4, 2015 at 12:20 PM To: Morteza Ansari >, Ian Gla= zer >, Phil Hunt > Cc: "scim@ietf.org" > Subject: RE: [scim] Base64 Encoding for Binary Attributes We should just take the text from JWK on x5c or x5u From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Wednesday, March 4, 2015 12:18 PM To: Anthony Nadalin; Ian Glazer; Phil Hunt Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes Wearing individual contributor hat: I think there is some confusion here on= the x509Certificate attribute. The definition for this attribute comes mo= re or less directly from SCIM 1.1 spec. The idea is that certificates are s= tored as DER encoded using SCIM binary data type which is base64 encoded st= rings. As such I don=92t believe there is any issues with representing any= type of certificate given DER encoding handles that fully and base64 encod= ing is only done for transferring the DER encoded certs over SCIM API. And = given the attribute is plural, we can have many certificate values (each DE= R encoded and then base64 encoded). As chair: Given the confusion, I certainly think we should as minimum adjus= t the text for this attribute to be more precise and clear about the intent= ion. Phil, can you propose some text for that clarification. Also, given = this definition does anyone think this is something that should be revisite= d? Cheers, Morteza From: Anthony Nadalin > Date: Tuesday, March 3, 2015 at 12:12 PM To: Ian Glazer >, Phi= l Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Base64 Encoding for Binary Attributes I=92m confused, why would we not just use what JOSE used for Binary Encodin= g ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer Sent: Tuesday, March 3, 2015 7:29 AM To: Phil Hunt Cc: SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes I am okay with this change On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt > wrote: All, Michael has reminded me that x509Certificate is DER encoded binary which is= in conflict with our current binary definition. I recommend changing the definition of Binary FROM: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded as a base 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is case-exact and has no uniqueness. Values represented in JSON MUST conform to the XML constraints above and are represented as a JSON String per Section 2.7 [RFC7159]. TO: 2.2.6. Binary Arbitrary binary data. The attribute value MUST be encoded in Base 64 encoding as specified in Section 4 [RFC4648]. In cases where a URL-safe encoding is required, the attribute definition MAY specify Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. In JSON representation, the encoded values are represented as a JSON String per Section 7 [RFC7159]. A binary is case-exact and has no uniqueness. Further, I would recommend changing x509certificates FROM: x509Certificates A list of certificates issued to the User. Values are Binary (Section 2.2.6) and DER encoded x509. This value has NO canonical types. TO: x509Certificates A list of certificates issued to the User. Values are binary (Section 2.2.6) and are Base 64 encoded x509 per Section 4 [RFC4648]. Important: This is a normative change as we are correcting the previous = =93DER=94 encoding to be base 64 encoding for consistency with the definiti= on of binary and JSON compatibility. If possible, please have comments to the list by 5PM Pacific tomorrow (Tues= day). I would like to publish draft 17 of core-schema in order to be able = to publish the changes to the API draft later in the week. Note that the p= roposed changes for tomorrow include expanding section 8.7 to include schem= as for fixed (non-resource) service provider schemas: ServiceProviderConfi= g, ResourceType, Schema. Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com On Mar 2, 2015, at 12:25 PM, Phil Hunt > wrote: I think it should be one form. My recommendation would be base64url for max utility. Especially if we star= t defining schema related to JWT keys (JWK) from OAuth and JOSE. Phil On Mar 2, 2015, at 12:06, Ian Glazer > wrote: Would this be base64url "required" or "recommended"? Would the encoding type be a declared attribute of the SP? On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt > wrote: I was looking through the schema document and cleaning up the data type cha= racteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wi= ll likely require us to reference the current spec, so I should probably up= date the reference. Looking at the binary attribute representation, I am wondering if we should= change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). Do we want to further clarify that the encoding be: base64url? Not a java= script expert, but wondering if we need to use url safe encoding? This may = result in a normative clarification for some. Phil @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D11CAE4511ED8Bmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3FD42D3917B79340AA345D66359E815C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
We certainly should take as much of it as possible from x5c in JWK. &n= bsp;The only part that might not apply to us is the array part given this a= ttribute is multivalued which means the array is probably not needed.  = ;I believe Phil is planning on reaching out to Mike Jones to confirm that.


Cheers,
Morteza

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Wednesday, March 4, 2015 at 1= 2:20 PM
To: Morteza Ansari <moransar@cisco.com>, Ian Glazer <iglazer@salesforce.com>, Phil Hu= nt <phil.hunt@oracle.com>=
Cc: "scim@ietf.org" <scim@i= etf.org>
Subject: RE: [scim] Base64 Encoding= for Binary Attributes

We should just take the text from J= WK on x5c or x5u

&n= bsp;

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Wednesday, March 4, 2015 12:18 PM
To: Anthony Nadalin; Ian Glazer; Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

Wearing individual contributor hat: I think = there is some confusion here on the x509Certificate attribute.  The de= finition for this attribute comes more or less directly from SCIM 1.1 spec. The idea is that certificates are stored= as DER encoded using SCIM binary data type which is base64 encoded strings= .  As such I don=92t believe there is any issues with representing any= type of certificate given DER encoding handles that fully and base64 encoding is only done for transferring the D= ER encoded certs over SCIM API. And given the attribute is plural, we can h= ave many certificate values (each DER encoded and then base64 encoded).

 

As chair: Given the confusion, I certainly t= hink we should as minimum adjust the text for this attribute to be more pre= cise and clear about the intention.  Phil, can you propose some text for that clarification.  Also, = given this definition does anyone think this is something that should be re= visited?

 

 

Cheers,

Morteza

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 3, 2015 at 12:12 PM
To: Ian Glazer <iglazer= @salesforce.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" &= lt;scim@ietf.org>
Subject: Re: [scim] Base64 Encoding for Binary Attributes=

 

I=92m confused, why would we not ju= st use what JOSE used for Binary Encoding ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer
Sent: Tuesday, March 3, 2015 7:29 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

 =

I am okay with this chan= ge

 =

On Mon, Mar 2, 2015 at 6= :50 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

All,

 =

Michael has reminded me = that x509Certificate is DER encoded binary which is in conflict with our cu= rrent binary definition.

 =

I recommend changing the= definition of Binary FROM:

2.2.6.  Binary
 
   Arbitrary binary data.  =
The attribute value MUST be encoded as a base
   64 encoding as specified in S=
ection 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniquen=
ess.
 
   Values represented in JSON MU=
ST conform to the XML constraints above
   and are represented as a JSON=
 String per Section 2.7 [RFC7159].

TO: 

2.2.6.  Binary
 
   Arbitrary binary data.  =
The attribute value MUST be encoded in Base
   64 encoding as specified i=
n Section 4 [RFC4648].  In cases where a
   URL-safe encoding is requi=
red, the attribute definition MAY specify
   Base 64 URL encoding MAY b=
e used as per Section 5 [RFC4648].
 
   In JSON representation, th=
e encoded values are represented as a JSON
   String per Section 7 [RFC7=
159].  A binary is case-exact and has no
   uniqueness.

Further, I would recomme= nd changing x509certificates FROM:

   x509Certificates
      A list of c=
ertificates issued to the User.  Values are Binary

      (Section 2.=
2.6) and DER encoded x509.  This value has NO canonical


      types.=

TO: 

   x509Certificates
      A list of c=
ertificates issued to the User.  Values are binary
      (Section 2.=
2.6) and are Base 64 encoded x509 per Section 4

      [RFC4648=
].

 =

Important:  This= is a normative change as we are correcting the previous =93DER=94 encoding= to be base 64 encoding for consistency with the definition of binary and J= SON compatibility.=

 =

If possible, pleas= e have comments to the list by 5PM Pacific tomorrow (Tuesday).  I would like to publish draft 17 of co= re-schema in order to be able to publish the changes to the API draft later in the week.  Note that the proposed c= hanges for tomorrow include expanding section 8.7 to include schemas for fi= xed (non-resource) service provider schemas:  ServiceProviderConfig, R= esourceType, Schema.

 =

Cheers,

 =

Phil<= /o:p>

 

@independentid

phi= l.hunt@oracle.com<= /p>

 =

On Mar 2, 2015, at 12:25= PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 =

I think it should be one= form. 

 =

My recommendation would = be base64url for max utility. Especially if we start defining schema relate= d to JWT keys (JWK) from OAuth and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:<= /span>

Would this be base64url = "required" or "recommended"?

 =

Would the encoding type = be a declared attribute of the SP?

 =

On Mon, Mar 2, 2015 at 2= :07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 =

I was looking through th= e schema document and cleaning up the data type characteristics (as discuss= ed previously), I notice that the reference to XML-Schema is to the October= 2004 one and not the 2012 XML Schema.  The IETF will likely require us to reference the current spec, so I should= probably update the reference.

 =

Looking at the binary at= tribute representation, I am wondering if we should change this to the curr= ent IETF specification which is: RFC4648 rather than reference XML-Schema 3= .2.16 (of the 2004 schema spec).

 =

Do we want to further cl= arify that the encoding be: base64url?   Not a javascript expert, but = wondering if we need to use url safe encoding? This may result in a normati= ve clarification for some.

 =

Phil<= /o:p>

 

@independentid

phi= l.hunt@oracle.com<= /p>

 =


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



 =

--

Ian Glazer

Senior Director, Identit= y

________________________= _______________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim

 =



 =

--

Ian Glazer

Senior Director, Identit= y

+1 202 255 3166=

--_000_D11CAE4511ED8Bmoransarciscocom_-- From nobody Wed Mar 4 12:57:37 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391FB1ACEE0 for ; Wed, 4 Mar 2015 12:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aMbxBt3FudXM for ; Wed, 4 Mar 2015 12:57:33 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F98B1ACEF3 for ; Wed, 4 Mar 2015 12:57:27 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t24KvPmK013154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Mar 2015 20:57:26 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t24KvP2F016872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Mar 2015 20:57:25 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t24KvOUe012938; Wed, 4 Mar 2015 20:57:24 GMT Received: from [10.0.1.18] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Mar 2015 12:57:24 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-8FA64688-5F88-4FDA-9838-B98D3D731389 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Wed, 4 Mar 2015 12:57:21 -0800 Content-Transfer-Encoding: 7bit Message-Id: <80153FE5-4ACE-42F2-903C-D4E82F0EBE29@oracle.com> References: <23963BBA-1C03-4CD5-B7DB-852642FB345E@oracle.com> To: "Morteza Ansari (moransar)" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Cc: Anthony Nadalin , Ian Glazer , Mike Jones , SCIM WG Subject: Re: [scim] Base64 Encoding for Binary Attributes X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:57:36 -0000 --Apple-Mail-8FA64688-5F88-4FDA-9838-B98D3D731389 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The array in jwk x5c is an array representing a certificate chain.=20 While the array in scim x509certificates is for multiple different certs rep= resenting a user.=20 Mike...any reason why a certificate chain wasn't encoded directly at the DER= encoding level? For SCIM the worry is having an array that needs to contain arrays of certif= icate chains.=20 Phil > On Mar 4, 2015, at 12:44, Morteza Ansari (moransar) w= rote: >=20 > We certainly should take as much of it as possible from x5c in JWK. The o= nly part that might not apply to us is the array part given this attribute i= s multivalued which means the array is probably not needed. I believe Phil i= s planning on reaching out to Mike Jones to confirm that. >=20 >=20 > Cheers, > Morteza >=20 > From: Anthony Nadalin > Date: Wednesday, March 4, 2015 at 12:20 PM > To: Morteza Ansari , Ian Glazer , Phil Hunt > Cc: "scim@ietf.org" > Subject: RE: [scim] Base64 Encoding for Binary Attributes >=20 > We should just take the text from JWK on x5c or x5u > =20 > From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]=20 > Sent: Wednesday, March 4, 2015 12:18 PM > To: Anthony Nadalin; Ian Glazer; Phil Hunt > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > Wearing individual contributor hat: I think there is some confusion here o= n the x509Certificate attribute. The definition for this attribute comes mo= re or less directly from SCIM 1.1 spec. The idea is that certificates are st= ored as DER encoded using SCIM binary data type which is base64 encoded stri= ngs. As such I don=E2=80=99t believe there is any issues with representing a= ny type of certificate given DER encoding handles that fully and base64 enco= ding is only done for transferring the DER encoded certs over SCIM API. And g= iven the attribute is plural, we can have many certificate values (each DER e= ncoded and then base64 encoded). > =20 > As chair: Given the confusion, I certainly think we should as minimum adju= st the text for this attribute to be more precise and clear about the intent= ion. Phil, can you propose some text for that clarification. Also, given t= his definition does anyone think this is something that should be revisited?= > =20 > =20 > Cheers, > Morteza > =20 > From: Anthony Nadalin > Date: Tuesday, March 3, 2015 at 12:12 PM > To: Ian Glazer , Phil Hunt > Cc: "scim@ietf.org" > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > I=E2=80=99m confused, why would we not just use what JOSE used for Binary E= ncoding ? > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer > Sent: Tuesday, March 3, 2015 7:29 AM > To: Phil Hunt > Cc: SCIM WG > Subject: Re: [scim] Base64 Encoding for Binary Attributes > =20 > I am okay with this change > =20 > On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt wrote: > All, > =20 > Michael has reminded me that x509Certificate is DER encoded binary which i= s in conflict with our current binary definition. > =20 > I recommend changing the definition of Binary FROM: > 2.2.6. Binary > =20 > Arbitrary binary data. The attribute value MUST be encoded as a base > 64 encoding as specified in Section 3.2.16 [XML-Schema]. A binary is > case-exact and has no uniqueness. > =20 > Values represented in JSON MUST conform to the XML constraints above > and are represented as a JSON String per Section 2.7 [RFC7159]. > TO: > 2.2.6. Binary > =20 > Arbitrary binary data. The attribute value MUST be encoded in Base > 64 encoding as specified in Section 4 [RFC4648]. In cases where a > URL-safe encoding is required, the attribute definition MAY specify > Base 64 URL encoding MAY be used as per Section 5 [RFC4648]. > =20 > In JSON representation, the encoded values are represented as a JSON > String per Section 7 [RFC7159]. A binary is case-exact and has no > uniqueness. > Further, I would recommend changing x509certificates FROM: > x509Certificates > A list of certificates issued to the User. Values are Binary > (Section 2.2.6) and DER encoded x509. This value has NO canonical > types. > TO: > x509Certificates > A list of certificates issued to the User. Values are binary > (Section 2.2.6) and are Base 64 encoded x509 per Section 4 > [RFC4648]. > =20 > Important: This is a normative change as we are correcting the previous =E2= =80=9CDER=E2=80=9D encoding to be base 64 encoding for consistency with the d= efinition of binary and JSON compatibility. > =20 > If possible, please have comments to the list by 5PM Pacific tomorrow (Tue= sday). I would like to publish draft 17 of core-schema in order to be able t= o publish the changes to the API draft later in the week. Note that the pro= posed changes for tomorrow include expanding section 8.7 to include schemas f= or fixed (non-resource) service provider schemas: ServiceProviderConfig, Re= sourceType, Schema. > =20 > Cheers, > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 > On Mar 2, 2015, at 12:25 PM, Phil Hunt wrote: > =20 > I think it should be one form.=20 > =20 > My recommendation would be base64url for max utility. Especially if we sta= rt defining schema related to JWT keys (JWK) from OAuth and JOSE.=20 >=20 > Phil >=20 > On Mar 2, 2015, at 12:06, Ian Glazer wrote: >=20 > Would this be base64url "required" or "recommended"? > =20 > Would the encoding type be a declared attribute of the SP? > =20 > On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt wrote: > =20 > I was looking through the schema document and cleaning up the data type ch= aracteristics (as discussed previously), I notice that the reference to XML-= Schema is to the October 2004 one and not the 2012 XML Schema. The IETF wil= l likely require us to reference the current spec, so I should probably upda= te the reference. > =20 > Looking at the binary attribute representation, I am wondering if we shoul= d change this to the current IETF specification which is: RFC4648 rather tha= n reference XML-Schema 3.2.16 (of the 2004 schema spec). > =20 > Do we want to further clarify that the encoding be: base64url? Not a jav= ascript expert, but wondering if we need to use url safe encoding? This may r= esult in a normative clarification for some. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com > =20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > =20 >=20 >=20 > =20 > -- > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-8FA64688-5F88-4FDA-9838-B98D3D731389 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The array in jwk x5c is an array repre= senting a certificate chain. 

While the array i= n scim x509certificates is for multiple different certs representing a user.=  

Mike...any reason why a certificate chain wa= sn't encoded directly at the DER encoding level?

Fo= r SCIM the worry is having an array that needs to contain arrays of certific= ate chains. 

Phil

On Mar 4, 2015, at 12:44, Mortez= a Ansari (moransar) <moransar@cisco= .com> wrote:

We certainly should take as much of it as possible from x5c in JWK. &nb= sp;The only part that might not apply to us is the array part given this att= ribute is multivalued which means the array is probably not needed.  I b= elieve Phil is planning on reaching out to Mike Jones to confirm that.


Cheers,
Morteza

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Wednesday, March 4, 2015 at 12= :20 PM
To: Morteza Ansari <moransar@cisco.com>, Ian Glazer <iglazer@salesforce.com>, Phil Hunt &l= t;phil.hunt@oracle.com>
Cc: "scim@ietf.org" <scim@ietf.org&= gt;
Subject: RE: [scim] Base64 Encoding f= or Binary Attributes

We should just take the text from JWK= on x5c or x5u

&nbs= p;

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Wednesday, March 4, 2015 12:18 PM
To: Anthony Nadalin; Ian Glazer; Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes<= /span>

 

Wearing individual contributor hat: I think th= ere is some confusion here on the x509Certificate attribute.  The defin= ition for this attribute comes more or less directly from SCIM 1.1 spec. The idea is that certificates are stored a= s DER encoded using SCIM binary data type which is base64 encoded strings. &= nbsp;As such I don=E2=80=99t believe there is any issues with representing a= ny type of certificate given DER encoding handles that fully and base64 encoding is only done for transferring the DE= R encoded certs over SCIM API. And given the attribute is plural, we can hav= e many certificate values (each DER encoded and then base64 encoded).

 

As chair: Given the confusion, I certainly thi= nk we should as minimum adjust the text for this attribute to be more precis= e and clear about the intention.  Phil, can you propose some text for that clarification.  Also, g= iven this definition does anyone think this is something that should be revi= sited?

 

 

Cheers,

Morteza

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 3, 2015 at 12:12 PM
To: Ian Glazer <iglazer@= salesforce.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Base64 Encoding for Binary Attributes<= /span>

 

I=E2=80=99m confused, why would we no= t just use what JOSE used for Binary Encoding ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Ian Glazer
Sent: Tuesday, March 3, 2015 7:29 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

 <= /p>

I am okay with this chang= e

 <= /p>

On Mon, Mar 2, 2015 at 6:= 50 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

All,

 <= /p>

Michael has reminded me t= hat x509Certificate is DER encoded binary which is in conflict with our curr= ent binary definition.

 <= /p>

I recommend changing the d= efinition of Binary FROM:

2.2.6.  Binary
 
   Arbitrary binary data.  T=
he attribute value MUST be encoded as a base
   64 encoding as specified in Se=
ction 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniquene=
ss.
 
   Values represented in JSON MUS=
T conform to the XML constraints above
   and are represented as a JSON S=
tring per Section 2.7 [RFC7159].

TO:

= 
2.2.6.  Binary
 
   Arbitrary binary data.  T=
he attribute value MUST be encoded in Base
   64 encoding as specified in=
 Section 4 [RFC4648].  In cases where a
   URL-safe encoding is requir=
ed, the attribute definition MAY specify
   Base 64 URL encoding MAY be=
 used as per Section 5 [RFC4648].
 
   In JSON representation, the=
 encoded values are represented as a JSON
   String per Section 7 [RFC71=
59].  A binary is case-exact and has no
   uniqueness.

Further, I would recommen= d changing x509certificates FROM:

   x509Certificates
      A list of ce=
rtificates issued to the User.  Values are Binary

      (Section 2.2=
.6) and DER encoded x509.  This value has NO canonical


      types.<=
/o:p>

TO:

= 
   x509Certificates
      A list of ce=
rtificates issued to the User.  Values are binary
      (Section 2.2=
.6) and are Base 64 encoded x509 per Section 4

      [RFC4648]=
.

 <= /p>

Important:  This i= s a normative change as we are correcting the previous =E2=80=9CDER=E2=80=9D= encoding to be base 64 encoding for consistency with the definition of bina= ry and JSON compatibility.=

 <= /p>

If possible, please= have comments to the list by 5PM Pacific tomorrow (Tuesday)<= span style=3D"color:black">.  I would like to publish draft 17 of core-= schema in order to be able to publish the changes to the API draft later in the week.  Note that the proposed ch= anges for tomorrow include expanding section 8.7 to include schemas for fixe= d (non-resource) service provider schemas:  ServiceProviderConfig, Reso= urceType, Schema.

 <= /p>

Cheers,=

 <= /p>

Phil

 <= /o:p>

@independentid

phil.= hunt@oracle.com

=

 <= /p>

On Mar 2, 2015, at 12:25 P= M, Phil Hunt <p= hil.hunt@oracle.com> wrote:

 <= /p>

I think it should be one f= orm. 

 <= /p>

My recommendation would b= e base64url for max utility. Especially if we start defining schema related t= o JWT keys (JWK) from OAuth and JOSE. 


Phil


On Mar 2, 2015, at 12:06, Ian Glazer <iglazer@salesforce.com> wrote:

Would this be base64url "= required" or "recommended"?

 <= /p>

Would the encoding type b= e a declared attribute of the SP?

 <= /p>

On Mon, Mar 2, 2015 at 2:= 07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

 <= /p>

I was looking through the= schema document and cleaning up the data type characteristics (as discussed= previously), I notice that the reference to XML-Schema is to the October 20= 04 one and not the 2012 XML Schema.  The IETF will likely require us to reference the current spec, so I should p= robably update the reference.

 <= /p>

Looking at the binary att= ribute representation, I am wondering if we should change this to the curren= t IETF specification which is: RFC4648 rather than reference XML-Schema 3.2.= 16 (of the 2004 schema spec).

 <= /p>

Do we want to further cla= rify that the encoding be: base64url?   Not a javascript expert, but wo= ndering if we need to use url safe encoding? This may result in a normative c= larification for some.

 <= /p>

Phil

 <= /o:p>

@independentid

phil.= hunt@oracle.com

=

 <= /p>


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



 <= /p>

--

=

Ian Glazer

Senior Director, Identity=

_________________________= ______________________
scim mailing list
scim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/scim

 <= /p>



 <= /p>

--

=

Ian Glazer

Senior Director, Identity=

+1 202 255 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-8FA64688-5F88-4FDA-9838-B98D3D731389-- From nobody Wed Mar 4 22:50:04 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4ED1B29E5; Wed, 4 Mar 2015 22:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 283cXKGYzN3D; Wed, 4 Mar 2015 22:50:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5321A1AD9; Wed, 4 Mar 2015 22:50:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305065000.8595.27409.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 22:50:00 -0800 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-17.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:50:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Authors : Phil Hunt Kelly Grizzle Erik Wahlstroem Chuck Mortimore Filename : draft-ietf-scim-core-schema-17.txt Pages : 86 Date : 2015-03-04 Abstract: The System for Cross-Domain Identity Management (SCIM) specifications are designed to make identity management in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using HTTP protocol. This document provides a platform neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-core-schema-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-core-schema-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 4 22:58:45 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEC31B29E6 for ; Wed, 4 Mar 2015 22:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E3axWx4cm53i for ; Wed, 4 Mar 2015 22:58:38 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190511B29F8 for ; Wed, 4 Mar 2015 22:58:38 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t256wbbQ013227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Mar 2015 06:58:37 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t256wagG007348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Mar 2015 06:58:36 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t256waQL007337 for ; Thu, 5 Mar 2015 06:58:36 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Mar 2015 22:58:35 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: <20150305065000.8595.27409.idtracker@ietfa.amsl.com> Date: Wed, 4 Mar 2015 22:58:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <676CF1CC-B8B0-4058-BFC0-8C397A0D3FFE@oracle.com> References: <20150305065000.8595.27409.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: Re: [scim] I-D Action: draft-ietf-scim-core-schema-17.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:58:44 -0000 As requested by the chairs earlier, I have posted draft 17 of = core-schema. This draft includes the following updates based on feedback during the = WGLC period. * Updated reference for XML-Schema to the 5 April 2012 XML Schema 1.1 = draft * Added clarifications on attribute characteristics and Schema usage * Added schema in section 8.7 for Schema, ServiceProviderConfig, and = ResourceType * Fixed nit in service provider config. * Clarified binary attribute may be base 64 or base 64 url encoding per = RFC4648. x509certificates are now base64 encoded. * Clarified x509certificates values are DER certificates that are then = base64 encoded * Corrected "reference" attribute to use the "referenceTypes=E2=80=9D = meta-attribute that says what type of reference an attribute is. As I mentioned previously, there will also be an update to the API draft = posted sometime after Friday and before the deadline on Monday. The API = update will include the resource schema vs. message schema = clarifications that has been discussed on the list. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 4, 2015, at 10:50 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Core Schema > Authors : Phil Hunt > Kelly Grizzle > Erik Wahlstroem > Chuck Mortimore > Filename : draft-ietf-scim-core-schema-17.txt > Pages : 86 > Date : 2015-03-04 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) = specifications > are designed to make identity management in cloud based applications > and services easier. The specification suite builds upon experience > with existing schemas and deployments, placing specific emphasis on > simplicity of development and integration, while applying existing > authentication, authorization, and privacy models. Its intent is to > reduce the cost and complexity of user management operations by > providing a common user schema and extension model, as well as > binding documents to provide patterns for exchanging this schema > using HTTP protocol. >=20 > This document provides a platform neutral schema and extension model > for representing users and groups and other resource types in JSON > format. This schema is intended for exchange and use with cloud > service providers. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-core-schema-17 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-core-schema-17 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Thu Mar 5 08:28:55 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4EE1A1BA2; Thu, 5 Mar 2015 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 WEtTDQKAFhl9; Thu, 5 Mar 2015 08:28:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0011A1BEA; Thu, 5 Mar 2015 08:23:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305162307.10114.46498.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 08:23:07 -0800 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-04.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:28:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : SCIM Use Cases Authors : Phil Hunt Bhumip Khasnabish Anthony Nadalin Kepeng LI Zachary Zeltsan Filename : draft-ietf-scim-use-cases-04.txt Pages : 18 Date : 2015-03-05 Abstract: This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-use-cases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 8 12:39:59 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F421A00FE; Sun, 8 Mar 2015 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 BDic3oghZftG; Sun, 8 Mar 2015 12:39:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77271A00D8; Sun, 8 Mar 2015 12:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308193956.24112.80828.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 12:39:56 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-16.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-Domain Identity Management: Protocol Authors : Phil Hunt Kelly Grizzle Morteza Ansari Erik Wahlstroem Technology Nexus Chuck Mortimore Filename : draft-ietf-scim-api-16.txt Pages : 84 Date : 2015-03-08 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is an HTTP based protocol that makes managing identities in multi- domain scenarios easier to support through a standardized services. Examples include but are not limited to enterprise to cloud service providers, and inter-cloud based scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model and a service protocol defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-api/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-api-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-api-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 8 12:44:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871931A0119 for ; Sun, 8 Mar 2015 12:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wErj7D9hGbXz for ; Sun, 8 Mar 2015 12:44:23 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34911A00D8 for ; Sun, 8 Mar 2015 12:44:22 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t28JiMs3002127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 8 Mar 2015 19:44:22 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t28JiLN5000891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 Mar 2015 19:44:21 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t28JiLe2000886 for ; Sun, 8 Mar 2015 19:44:21 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2015 12:44:20 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: <20150308193956.24112.80828.idtracker@ietfa.amsl.com> Date: Sun, 8 Mar 2015 12:44:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42306D31-A831-4C82-95C3-96AE3DC8C6C6@oracle.com> References: <20150308193956.24112.80828.idtracker@ietfa.amsl.com> To: SCIM WG X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Subject: Re: [scim] I-D Action: draft-ietf-scim-api-16.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:44:24 -0000 This draft includes the clarifications on schema handling of resources = vs. messages that was discussed and agreed to this week. I did make some minor changes to proposed text for 3.1 that was = previously posted to the list to improve readability. Thanks for everyone=E2=80=99s input! Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 8, 2015, at 12:39 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the System for Cross-domain Identity = Management Working Group of the IETF. >=20 > Title : System for Cross-Domain Identity Management: = Protocol > Authors : Phil Hunt > Kelly Grizzle > Morteza Ansari > Erik Wahlstroem > Technology Nexus > Chuck Mortimore > Filename : draft-ietf-scim-api-16.txt > Pages : 84 > Date : 2015-03-08 >=20 > Abstract: > The System for Cross-Domain Identity Management (SCIM) specification > is an HTTP based protocol that makes managing identities in multi- > domain scenarios easier to support through a standardized services. > Examples include but are not limited to enterprise to cloud service > providers, and inter-cloud based scenarios. The specification suite > seeks to build upon experience with existing schemas and = deployments, > placing specific emphasis on simplicity of development and > integration, while applying existing authentication, authorization, > and privacy models. SCIM's intent is to reduce the cost and > complexity of user management operations by providing a common user > schema and extension model and a service protocol defined by this > document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-scim-api/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-scim-api-16 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-api-16 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sun Mar 8 16:33:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088D1A020B for ; Sun, 8 Mar 2015 16:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QYP7RVyPsemj for ; Sun, 8 Mar 2015 16:32:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3791A0100 for ; Sun, 8 Mar 2015 16:32:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t28NWwWI013594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 8 Mar 2015 23:32:58 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t28NWve1009086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 Mar 2015 23:32:57 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t28NWvQ4006239 for ; Sun, 8 Mar 2015 23:32:57 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Mar 2015 16:32:56 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_50BF5A61-3956-4652-A062-14DACBA45C35" Message-Id: <0835327E-A7D4-423A-939D-C62D6CE4DF6F@oracle.com> Date: Sun, 8 Mar 2015 16:32:55 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: Subject: [scim] SCIM Notify Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 23:33:04 -0000 --Apple-Mail=_50BF5A61-3956-4652-A062-14DACBA45C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On behalf of Ian Glazer, Morteza Ansari, and myself, I have submitted an = individual draft contribution for comments and consideration. The draft = is available here: https://tools.ietf.org/html/draft-hunt-scim-notify-00 The draft follows up from the presentation made at IETF91 in Honolulu = and defines SCIM events and messages used to notify subscribers of = events from a publishing service provider via a distribution service = known as a notification hub. The hub should have the capability to = deliver event messages securely via simple HTTP POST, WebPUSH, and other = messaging protocols where useful. =20 I would like to request that we add this as a discussion item for the = Dallas agenda. At the meeting I propose we discuss: 1. What are the intended benefits and uses for Notify in SCIM = environments 2. What are the scalability, information, and technical problems being = addressed 3. What is left to define and finally, 4. Is there enough interest in the working group to add Notify to the = SCIM charter. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_50BF5A61-3956-4652-A062-14DACBA45C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On behalf of Ian Glazer, Morteza Ansari, and myself, I have = submitted an individual draft contribution for comments and = consideration. The draft is available here:
https://tools.ietf.org/html/draft-hunt-scim-notify-00

The = draft follows up from the presentation made at IETF91 in Honolulu and = defines SCIM events and messages used to notify subscribers of events = from a publishing service provider via a distribution service known as a = notification hub.  The hub should have the capability to deliver = event messages securely via simple HTTP POST, WebPUSH, and other = messaging protocols where useful.  

I would like to request that we add = this as a discussion item for the Dallas agenda.

At the meeting I propose we = discuss:

1. =  What are the intended benefits and uses for Notify in SCIM = environments
2.  What are the scalability, = information, and technical problems being addressed
3.  What is left to define
and = finally,
4.  Is there enough interest in the = working group to add Notify to the SCIM charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_50BF5A61-3956-4652-A062-14DACBA45C35-- From nobody Mon Mar 9 17:50:17 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCA51ACE78 for ; Mon, 9 Mar 2015 17:50:16 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 etoM6uIEK0Za for ; Mon, 9 Mar 2015 17:50:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E481ACE4E for ; Mon, 9 Mar 2015 17:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2083; q=dns/txt; s=iport; t=1425948616; x=1427158216; h=from:to:subject:date:message-id:mime-version; bh=I49PijaFPj/DGTL8KzmF2+C35e/7bWlompCseZsYoXE=; b=EijSstx6X7ouk/9DDA7W1C/g5BUBQFCTefDKfMYDoXDwoeHBRtscI3re AJGkbyTWLFP4FfpiZK21RoaG8/Hz0XPhfziK1gTqh9CImjFqj8uMa3QAy 84y284XS2wJlZZEfywvypgd0ubYIRdbjOQeNhu70fjEpu0D/teqbxLC7f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BlGwDePv5U/5pdJa1cgkNDUl68coNIgjaFcIEtTQEBAQEBAXyEFoELAQwBcycELIgWDZY/q0gBAQEHAgEbBJABhDgFkA+DZIVvk3Qjg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,371,1422921600"; d="scan'208,217";a="402225960" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 10 Mar 2015 00:50:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2A0oDsK028480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Mar 2015 00:50:13 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 19:50:13 -0500 From: "Morteza Ansari (moransar)" To: "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJQ== Date: Tue, 10 Mar 2015 00:50:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.73.172] Content-Type: multipart/alternative; boundary="_000_D1238DD31201A4moransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:50:16 -0000 --_000_D1238DD31201A4moransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_D1238DD31201A4moransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Phil Hunt and I put together a very very very rough draft for SCIM sof= t delete semantics. The draft is missing a lot of details and require a lot= more thinking but we wanted to put the basic concept out there for discuss= ion at Dallas. The idea of soft delete/undelete has come up many times in various forums and I personally = think it is a very important aspect of real life operationalizing SCIM.

https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/

I would like a slot on the agenda to discuss this draft and get feedba= ck from the WG.


Cheers,
Morteza
--_000_D1238DD31201A4moransarciscocom_-- From nobody Tue Mar 10 03:15:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B601A873C for ; Tue, 10 Mar 2015 03:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 du888LO8fEGd for ; Tue, 10 Mar 2015 03:15:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111571A6F05 for ; Tue, 10 Mar 2015 03:15:29 -0700 (PDT) Received: by lbdu14 with SMTP id u14so616669lbd.0 for ; Tue, 10 Mar 2015 03:15:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7cUcR7OEV34/OAlBzleHn/TuoMBeRLvR4WK+1sWIVoE=; b=ATX1RCpwGn28RiHgMyHpVNmXtVUoZc3XLX/Gnhz+ePIpO0XkZoTiFmrPzm3xQABfa0 1PAelGHkwsV+8tjxW1kkblUS/Oqw+iXmP5MYFMALrr3dZomeV/vkoy3zL2euLMGJRriW NGYVkTp7I8RrNsvV5sQPvme2eAygS6ZlI7UU1JG0Re75LVtTWXP0VXyQDYsUoXWRYA6R y8nH+GOoFsJBrGhNHrTrz0DYIyLrdB0jGitmPnhq9s7lgUMDh3UB9CWvF4daxztqdmi+ RZTHh75wUQRZg2q/v9Ui/9Z2v/f7xsXYSrYROaAyNIoC2dWbas9irhYVWW7Rqg3H0VR6 yr5g== X-Gm-Message-State: ALoCoQn8Jo/Ye/4SdXSrKHEXb+Ty3DGz2RpChAeArrcAkfgIc7NSIY8KQQhmVDJ90fXGzOCMRaep X-Received: by 10.152.19.228 with SMTP id i4mr30361914lae.77.1425982527442; Tue, 10 Mar 2015 03:15:27 -0700 (PDT) Received: from [109.105.104.226] (dhcp91.se-tug.nordu.net. [109.105.104.226]) by mx.google.com with ESMTPSA id en12sm23951lbc.11.2015.03.10.03.15.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2015 03:15:26 -0700 (PDT) Message-ID: <54FEC43D.7030004@mnt.se> Date: Tue, 10 Mar 2015 11:15:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 10:15:31 -0000 On 03/10/2015 01:50 AM, Morteza Ansari (moransar) wrote: > Phil Hunt and I put together a very very very rough draft for SCIM soft > delete semantics. The draft is missing a lot of details and require a > lot more thinking but we wanted to put the basic concept out there for > discussion at Dallas. The idea of soft delete/undelete has come up many > times in various forums and I personally think it is a very important > aspect of real life operationalizing SCIM. > > https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ > > I would like a slot on the agenda to discuss this draft and get feedback > from the WG. Sounds like a plan! From nobody Tue Mar 10 12:14:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0631F1A8731 for ; Tue, 10 Mar 2015 12:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ipzOG7WaY7ZN for ; Tue, 10 Mar 2015 12:14:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342911A8726 for ; Tue, 10 Mar 2015 12:14:20 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (25.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 19:14:16 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 19:14:15 +0000 From: Anthony Nadalin To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA Date: Tue, 10 Mar 2015 19:14:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(99286002)(106116001)(16236675004)(86362001)(86612001)(33656002)(19625215002)(76576001)(107886001)(2501003)(46102003)(74316001)(19580395003)(19580405001)(19300405004)(19609705001)(62966003)(122556002)(77156002)(102836002)(2900100001)(2950100001)(2656002)(54356999)(50986999)(76176999)(87936001)(19617315012)(40100003)(15975445007)(92566002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 051158ECBB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12346AA2B39C512E3A75EE18A6180BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 19:14:15.6689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:14:22 -0000 --_000_BN3PR0301MB12346AA2B39C512E3A75EE18A6180BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_BN3PR0301MB12346AA2B39C512E3A75EE18A6180BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So if I delete (soft) an object and t= hen add a new object with the same name, and then I undelete the object I d= eleted would the undelete fail ?

&nbs= p;

From: scim [mailto:scim-bounces@ietf= .org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 

Phil Hunt and I put together a very ver= y very rough draft for SCIM soft delete semantics. The draft is missing a l= ot of details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to di= scuss this draft and get feedback from the WG.

 

 

Cheers,

Morteza

--_000_BN3PR0301MB12346AA2B39C512E3A75EE18A6180BN3PR0301MB1234_-- From nobody Tue Mar 10 12:26:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAD31A1B51 for ; Tue, 10 Mar 2015 12:26:55 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yMnBexleW6Ke for ; Tue, 10 Mar 2015 12:26:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4BA1A01AA for ; Tue, 10 Mar 2015 12:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9645; q=dns/txt; s=iport; t=1426015613; x=1427225213; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=goAWpXAtpwQzLk4WsKkdlyJ1zyQHIqX0ab21wZ7FH4s=; b=P6hBAgUgpt4x8WULvFkXw9XHThfRn/5/o+yx5SyrqQL4wfik1EYPDxQF /177MaY60ltTQjMJVrjkApLA5W9dfpv25qcvYgmIywuztWV9eZh8G3gjF 5xgPtc7CxrgeehXZPXbCBKM0Lb021+M2D1Xculu4rImqr3kq7pIwieKKV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4GwDcRP9U/4cNJK1cgkNDUloEvSmDSII2hXACgTdNAQEBAQEBfIQPAQEBBC1cAgEIDgMDAQEBKAcyFAkIAgQBEhkCiBQNxUUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsXhF0NCgGELQWEcIE+iWGDZIVvk3Qjg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,376,1422921600"; d="scan'208,217";a="130658598" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 10 Mar 2015 19:26:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2AJQr7O022554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 19:26:53 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 14:26:53 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoA= Date: Tue, 10 Mar 2015 19:26:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.73.213] Content-Type: multipart/alternative; boundary="_000_D124922812032Bmoransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:26:56 -0000 --_000_D124922812032Bmoransarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_D124922812032Bmoransarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <44F1E72623C50A43AEBA26383E2CE722@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Yes. There is a very short blurb about the fact you could provide addi= tional attributes to resolve any potential namespace conflicts. For example= if you are undeleting a user you could send a new userName as part of the = modify request so you undelete the user object and resolve the conflict.

The more interesting case is the references and what to do in those ca= ses. References should not be visible in cases of soft deleted objects, the= question is how expensive is to maintain that information and add the link= s after the object is undeleted.

In a prototype I have done of this, I took the easy route and just del= eted references and they need to be re-created. Obviously it works, but it = is not the most useful solution. Then again if this is a provisioning case = and essentially a slave of another IDM solution, it can easily be recreated. The real problem is preserving t= he ID of the user and reinstating it rather than getting a new ID.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12= :14 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft=

So if I delete (soft) an object and= then add a new object with the same name, and then I undelete the object I= deleted would the undelete fail ?

&n= bsp;

From: scim [m= ailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 

Phil Hunt and I put together a very very ver= y rough draft for SCIM soft delete semantics. The draft is missing a lot of= details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to discuss= this draft and get feedback from the WG.

 

 

Cheers,

Morteza

 --_000_D124922812032Bmoransarciscocom_-- From nobody Tue Mar 10 14:15:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B794A1A8A29 for ; Tue, 10 Mar 2015 14:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 r2K_wFL6Y8QC for ; Tue, 10 Mar 2015 14:15:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278111A8A28 for ; Tue, 10 Mar 2015 14:15:44 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 21:15:28 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 21:15:28 +0000 From: Anthony Nadalin To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAA== Date: Tue, 10 Mar 2015 21:15:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::5] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(99286002)(106116001)(2501003)(86362001)(16236675004)(33656002)(19625215002)(86612001)(107886001)(2900100001)(2656002)(74316001)(76576001)(46102003)(19617315012)(19300405004)(87936001)(19580395003)(19580405001)(19609705001)(62966003)(122556002)(92566002)(77156002)(102836002)(2950100001)(76176999)(54356999)(50986999)(40100003)(15975445007)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 051158ECBB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12342C8642B8836B531CB730A6180BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 21:15:28.1065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:15:50 -0000 --_000_BN3PR0301MB12342C8642B8836B531CB730A6180BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why no "soft create" ? From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_BN3PR0301MB12342C8642B8836B531CB730A6180BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why no “soft create” ?

&nbs= p;

From: Morteza Ansari (moransar) [mai= lto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft

 

Yes. There is a very short blurb about = the fact you could provide additional attributes to resolve any potential n= amespace conflicts. For example if you are undeleting a user you could send a new userName as part of the modify request so you = undelete the user object and resolve the conflict.

 

The more interesting case is the refere= nces and what to do in those cases. References should not be visible in cas= es of soft deleted objects, the question is how expensive is to maintain that information and add the links after the obje= ct is undeleted.

 

In a prototype I have done of this, I t= ook the easy route and just deleted references and they need to be re-creat= ed. Obviously it works, but it is not the most useful solution. Then again if this is a provisioning case and essentially= a slave of another IDM solution, it can easily be recreated. The real prob= lem is preserving the ID of the user and reinstating it rather than getting= a new ID.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

So if I delete (soft) an object and t= hen add a new object with the same name, and then I undelete the object I d= eleted would the undelete fail ?

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 =

Phil Hunt and I put together a very ver= y very rough draft for SCIM soft delete semantics. The draft is missing a l= ot of details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to di= scuss this draft and get feedback from the WG.

 

 

Cheers,

Morteza

--_000_BN3PR0301MB12342C8642B8836B531CB730A6180BN3PR0301MB1234_-- From nobody Tue Mar 10 14:17:12 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0C1A8A29 for ; Tue, 10 Mar 2015 14:17:10 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Qwrm_bbehhD3 for ; Tue, 10 Mar 2015 14:17:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956321A8A05 for ; Tue, 10 Mar 2015 14:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13988; q=dns/txt; s=iport; t=1426022224; x=1427231824; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aKOxYGIjxceFFxyMAgPqJYVaOditu359lSO9h/j1Pto=; b=RR+Y53a7EAYygIV4cA3t8bGqqFB8zW1o+OYPztEuETRHwMqyC520hJbC qyJc04tn2TNxXa0T0OaKkqGiBDAwNH2bvl2vm5QOscQyUH7r2hK3KuTlu PpHlXe1MQuysw0KMIKIQiMAZu70X1Lwic7qF5FlSsMjXnC1nofiE+/6H0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DDDgAJXv9U/5hdJa1cgkNDUloEvS2DSII3hXACgTBNAQEBAQEBfIQPAQEBBC1cAgEIDgMDAQEBKAcyFAkIAgQBEhkCiBQNxXgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsXhF0NCgGELQWEd4E9iWWDZ4V0gRqDKI81I4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208,217";a="130749714" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 10 Mar 2015 21:17:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALH32I028552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:17:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:17:03 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8A Date: Tue, 10 Mar 2015 21:17:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.73.213] Content-Type: multipart/alternative; boundary="_000_D124AD33120524moransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:17:11 -0000 --_000_D124AD33120524moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Because I hadn=92t thought of it and didn=92t have a use case for it :) Can you please explain? Might be interesting. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:15 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft Why no =93soft create=94 ? From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_D124AD33120524moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <43B98D71590CC944859EDC7CB315C20E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Because I hadn=92t thought of it and didn=92t have a use case for it := )

Can you please explain?  Might be interesting.

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:= 15 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft=

Why no =93soft create=94 ?

&n= bsp;

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org<= /a>
Subject: Re: SCIM Soft Delete Draft

 

Yes. There is a very short blurb about the f= act you could provide additional attributes to resolve any potential namesp= ace conflicts. For example if you are undeleting a user you could send a new userName as part of the modify requ= est so you undelete the user object and resolve the conflict.

 

The more interesting case is the references = and what to do in those cases. References should not be visible in cases of= soft deleted objects, the question is how expensive is to maintain that information and add the links after t= he object is undeleted.

 

In a prototype I have done of this, I took t= he easy route and just deleted references and they need to be re-created. O= bviously it works, but it is not the most useful solution. Then again if this is a provisioning case and essent= ially a slave of another IDM solution, it can easily be recreated. The real= problem is preserving the ID of the user and reinstating it rather than ge= tting a new ID.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

So if I delete (soft) an object and= then add a new object with the same name, and then I undelete the object I= deleted would the undelete fail ?<= /o:p>

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 =

Phil Hunt and I put together a very very ver= y rough draft for SCIM soft delete semantics. The draft is missing a lot of= details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to discuss= this draft and get feedback from the WG.

 

 

Cheers,

Morteza

 --_000_D124AD33120524moransarciscocom_-- From nobody Tue Mar 10 14:23:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9BC1A8A50 for ; Tue, 10 Mar 2015 14:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tWuHkpyGgiKr for ; Tue, 10 Mar 2015 14:23:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A26C1A8A67 for ; Tue, 10 Mar 2015 14:23:10 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (25.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 21:22:55 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 21:22:55 +0000 From: Anthony Nadalin To: "Morteza Ansari (moransar)" , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgAAiqYA= Date: Tue, 10 Mar 2015 21:22:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::5] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(122556002)(62966003)(2900100001)(2950100001)(102836002)(77156002)(19580395003)(19609705001)(19580405001)(19300405004)(40100003)(92566002)(15975445007)(76176999)(2656002)(19617315012)(50986999)(87936001)(54356999)(86362001)(19625215002)(86612001)(33656002)(16236675004)(106116001)(99286002)(93886004)(74316001)(46102003)(76576001)(2501003)(107886001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 051158ECBB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234DDB46A13EE98E518324FA6180BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 21:22:55.2826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:23:18 -0000 --_000_BN3PR0301MB1234DDB46A13EE98E518324FA6180BN3PR0301MB1234_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Case is where an new employee has not started work yet, I go through the pr= ocess, get registered, etc. and links to things I need and just like delete= when I do the hard create everything works, up until then I get same resul= ts as soft delete From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 2:17 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Because I hadn't thought of it and didn't have a use case for it :) Can you please explain? Might be interesting. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:15 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft Why no "soft create" ? From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_BN3PR0301MB1234DDB46A13EE98E518324FA6180BN3PR0301MB1234_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Case is where an new employee has not= started work yet, I go through the process, get registered, etc. and links= to things I need and just like delete when I do the hard create everything works, up until then I get same results as s= oft delete

&nbs= p;

From: Morteza Ansari (moransar) [mai= lto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 2:17 PM
To: Anthony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft

 

Because I hadn’t thought of it an= d didn’t have a use case for it :)

 

Can you please explain?  Might be = interesting.

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:15 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

Why no “soft create” ?

 

From: Mortez= a Ansari (moransar) [mailto:moransar@= cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org<= /a>
Subject: Re: SCIM Soft Delete Draft

 =

Yes. There is a very short blurb about = the fact you could provide additional attributes to resolve any potential n= amespace conflicts. For example if you are undeleting a user you could send a new userName as part of the modify request so you = undelete the user object and resolve the conflict.

 

The more interesting case is the refere= nces and what to do in those cases. References should not be visible in cas= es of soft deleted objects, the question is how expensive is to maintain that information and add the links after the obje= ct is undeleted.

 

In a prototype I have done of this, I t= ook the easy route and just deleted references and they need to be re-creat= ed. Obviously it works, but it is not the most useful solution. Then again if this is a provisioning case and essentially= a slave of another IDM solution, it can easily be recreated. The real prob= lem is preserving the ID of the user and reinstating it rather than getting= a new ID.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

So if I delete (soft) an object and t= hen add a new object with the same name, and then I undelete the object I d= eleted would the undelete fail ?

 

From: scim [= mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 =

Phil Hunt and I put together a very ver= y very rough draft for SCIM soft delete semantics. The draft is missing a l= ot of details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to di= scuss this draft and get feedback from the WG.

 

 

Cheers,

Morteza

--_000_BN3PR0301MB1234DDB46A13EE98E518324FA6180BN3PR0301MB1234_-- From nobody Tue Mar 10 14:30:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEC51A8A8E for ; Tue, 10 Mar 2015 14:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 6fJO_ZCQx2TF for ; Tue, 10 Mar 2015 14:30:37 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D8B1A8A92 for ; Tue, 10 Mar 2015 14:30:36 -0700 (PDT) Received: by wesp10 with SMTP id p10so4761465wes.11 for ; Tue, 10 Mar 2015 14:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3YnItJRlsmBjLgQ1qF813EpQILsBPtFW6215yR2yQA0=; b=ZLSEl9aRm1LKcnffR8lGORve1wb0JhfVX20wjJdcmikmnpZLf1xehQrmLyFx9WmX7G 6+W+0JWLNwyCkiDimRH5KPOViPviOZ1vouMNIQt9u7wj6jwD8PRiOaCTcrWLnalgVuz5 j693FV9LcOgLsVFJ3Au+YffE9nUpsb/qeMpvBz9jpRAAwtAiC3RdeM9nL7yxkeG30elU 7IfyzeT/cMh7VC3S8436+M6gcFTIZ/GNpR35mtXmgSgjoviZm3OK6oHdSFardojyv35W VZQ6Gk7elHDIrkQj8IycJEV3Loc0MZpm4OLZf1TvSGcTy0EXZlB3r/ZDYCOuQLGRmz1r z2hQ== MIME-Version: 1.0 X-Received: by 10.180.207.227 with SMTP id lz3mr114927930wic.47.1426023035051; Tue, 10 Mar 2015 14:30:35 -0700 (PDT) Sender: grahameg@gmail.com Received: by 10.27.6.130 with HTTP; Tue, 10 Mar 2015 14:30:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Mar 2015 08:30:34 +1100 X-Google-Sender-Auth: RucpGKNc30sDk4UxykaWj1xFEqo Message-ID: From: Grahame Grieve To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a11c3f7f07224290510f5dc67 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:30:39 -0000 --001a11c3f7f07224290510f5dc67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is a status active =3D true|false, not a soft create Grahame On Wed, Mar 11, 2015 at 8:22 AM, Anthony Nadalin wrote: > Case is where an new employee has not started work yet, I go through the > process, get registered, etc. and links to things I need and just like > delete when I do the hard create everything works, up until then I get sa= me > results as soft delete > > > > *From:* Morteza Ansari (moransar) [mailto:moransar@cisco.com] > *Sent:* Tuesday, March 10, 2015 2:17 PM > > *To:* Anthony Nadalin; scim@ietf.org > *Subject:* Re: SCIM Soft Delete Draft > > > > Because I hadn=E2=80=99t thought of it and didn=E2=80=99t have a use case= for it :) > > > > Can you please explain? Might be interesting. > > > > *From: *Anthony Nadalin > *Date: *Tuesday, March 10, 2015 at 2:15 PM > *To: *Morteza Ansari , "scim@ietf.org" > *Subject: *RE: SCIM Soft Delete Draft > > > > Why no =E2=80=9Csoft create=E2=80=9D ? > > > > *From:* Morteza Ansari (moransar) [mailto:moransar@cisco.com > ] > *Sent:* Tuesday, March 10, 2015 12:27 PM > *To:* Anthony Nadalin; scim@ietf.org > *Subject:* Re: SCIM Soft Delete Draft > > > > Yes. There is a very short blurb about the fact you could provide > additional attributes to resolve any potential namespace conflicts. For > example if you are undeleting a user you could send a new userName as par= t > of the modify request so you undelete the user object and resolve the > conflict. > > > > The more interesting case is the references and what to do in those cases= . > References should not be visible in cases of soft deleted objects, the > question is how expensive is to maintain that information and add the lin= ks > after the object is undeleted. > > > > In a prototype I have done of this, I took the easy route and just delete= d > references and they need to be re-created. Obviously it works, but it is > not the most useful solution. Then again if this is a provisioning case a= nd > essentially a slave of another IDM solution, it can easily be recreated. > The real problem is preserving the ID of the user and reinstating it rath= er > than getting a new ID. > > > > > > *From: *Anthony Nadalin > *Date: *Tuesday, March 10, 2015 at 12:14 PM > *To: *Morteza Ansari , "scim@ietf.org" > *Subject: *RE: SCIM Soft Delete Draft > > > > So if I delete (soft) an object and then add a new object with the same > name, and then I undelete the object I deleted would the undelete fail ? > > > > *From:* scim [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Morteza Ansari (moransar) > *Sent:* Monday, March 9, 2015 5:50 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Soft Delete Draft > > > > Phil Hunt and I put together a very very very rough draft for SCIM soft > delete semantics. The draft is missing a lot of details and require a lot > more thinking but we wanted to put the basic concept out there for > discussion at Dallas. The idea of soft delete/undelete has come up many > times in various forums and I personally think it is a very important > aspect of real life operationalizing SCIM. > > > > https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ > > > > I would like a slot on the agenda to discuss this draft and get feedback > from the WG. > > > > > > Cheers, > > Morteza > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --=20 ----- http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065 --001a11c3f7f07224290510f5dc67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a status active =3D true|false, not a soft create= =C2=A0

Grahame


On Wed, Mar 11, 2015 at 8:22 AM,= Anthony Nadalin <tonynad@microsoft.com> wrote:

Case is where an new employee has not= started work yet, I go through the process, get registered, etc. and links= to things I need and just like delete when I do the hard create everything works, up until then I get same results as s= oft delete

=C2=A0

From: Morteza Ansari (moransar) [mai= lto:moransar@cisco.= com]
Sent: Tuesday, March 10, 2015 2:17 PM


To: Anthony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft

=C2=A0

Because I hadn=E2=80=99t thought of it = and didn=E2=80=99t have a use case for it :)

=C2=A0

Can you please explain?=C2=A0 Might be = interesting.

=C2=A0

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:15 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

=C2=A0

Why no =E2=80=9Csoft create=E2=80=9D = ?

=C2=A0

From: Mortez= a Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft

=C2=A0

Yes. There is a very short blurb about = the fact you could provide additional attributes to resolve any potential n= amespace conflicts. For example if you are undeleting a user you could send a new userName as part of the modify request so you = undelete the user object and resolve the conflict.

=C2=A0

The more interesting case is the refere= nces and what to do in those cases. References should not be visible in cas= es of soft deleted objects, the question is how expensive is to maintain that information and add the links after the obje= ct is undeleted.

=C2=A0

In a prototype I have done of this, I t= ook the easy route and just deleted references and they need to be re-creat= ed. Obviously it works, but it is not the most useful solution. Then again if this is a provisioning case and essentially= a slave of another IDM solution, it can easily be recreated. The real prob= lem is preserving the ID of the user and reinstating it rather than getting= a new ID.

=C2=A0

=C2=A0

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

=C2=A0

So if I delete (soft) an object and t= hen add a new object with the same name, and then I undelete the object I d= eleted would the undelete fail ?<= u>

=C2=A0

From: scim [= mailto:scim-boun= ces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org=
Subject: [scim] SCIM Soft Delete Draft

=C2=A0

Phil Hunt and I put together a very ver= y very rough draft for SCIM soft delete semantics. The draft is missing a l= ot of details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

=C2=A0

=C2=A0

I would like a slot on the agenda to di= scuss this draft and get feedback from the WG.

=C2=A0

=C2=A0

Cheers,

Morteza


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




--
--001a11c3f7f07224290510f5dc67-- From nobody Tue Mar 10 14:40:00 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436801A8A6A for ; Tue, 10 Mar 2015 14:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 wj2wUOvQVh-T for ; Tue, 10 Mar 2015 14:39:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729C61A87AC for ; Tue, 10 Mar 2015 14:39:55 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 21:39:35 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 21:39:35 +0000 From: Anthony Nadalin To: Grahame Grieve Thread-Topic: [scim] SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgAAiqYCAAAKmAIAAAkHA Date: Tue, 10 Mar 2015 21:39:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::5] authentication-results: healthintersections.com.au; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(122556002)(62966003)(77156002)(92566002)(87936001)(19580395003)(19300405004)(19580405001)(16601075003)(19609705001)(40100003)(15975445007)(2950100001)(76176999)(102836002)(54356999)(50986999)(86362001)(19625215002)(86612001)(33656002)(16236675004)(106116001)(99286002)(110136001)(74316001)(2656002)(2900100001)(19617315012)(46102003)(76576001)(93886004)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 051158ECBB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234121E967DA9D89226C510A6180BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 21:39:35.2216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:39:58 -0000 --_000_BN3PR0301MB1234121E967DA9D89226C510A6180BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIGFjdGl2ZSBtZWFucyBqdXN0IHRoYXQsIEnigJltIG5vdCBhbiBlbXBsb3llZSB5ZXQsIHRo dXMgaXTigJlzIGEgc29mdCBjcmVhdGUNCg0KRnJvbTogZ3JhaGFtZWdAZ21haWwuY29tIFttYWls dG86Z3JhaGFtZWdAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgR3JhaGFtZSBHcmlldmUNClNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IDI6MzEgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNj OiBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpOyBzY2ltQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3NjaW1dIFNDSU0gU29mdCBEZWxldGUgRHJhZnQNCg0KVGhpcyBpcyBhIHN0YXR1cyBhY3RpdmUg PSB0cnVlfGZhbHNlLCBub3QgYSBzb2Z0IGNyZWF0ZQ0KDQpHcmFoYW1lDQoNCg0KT24gV2VkLCBN YXIgMTEsIDIwMTUgYXQgODoyMiBBTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29m dC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KQ2FzZSBpcyB3aGVy ZSBhbiBuZXcgZW1wbG95ZWUgaGFzIG5vdCBzdGFydGVkIHdvcmsgeWV0LCBJIGdvIHRocm91Z2gg dGhlIHByb2Nlc3MsIGdldCByZWdpc3RlcmVkLCBldGMuIGFuZCBsaW5rcyB0byB0aGluZ3MgSSBu ZWVkIGFuZCBqdXN0IGxpa2UgZGVsZXRlIHdoZW4gSSBkbyB0aGUgaGFyZCBjcmVhdGUgZXZlcnl0 aGluZyB3b3JrcywgdXAgdW50aWwgdGhlbiBJIGdldCBzYW1lIHJlc3VsdHMgYXMgc29mdCBkZWxl dGUNCg0KRnJvbTogTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSBbbWFpbHRvOm1vcmFuc2FyQGNp c2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPl0NClNlbnQ6IFR1ZXNkYXksIE1hcmNo IDEwLCAyMDE1IDI6MTcgUE0NCg0KVG86IEFudGhvbnkgTmFkYWxpbjsgc2NpbUBpZXRmLm9yZzxt YWlsdG86c2NpbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0 DQoNCkJlY2F1c2UgSSBoYWRu4oCZdCB0aG91Z2h0IG9mIGl0IGFuZCBkaWRu4oCZdCBoYXZlIGEg dXNlIGNhc2UgZm9yIGl0IDopDQoNCkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4/ICBNaWdodCBiZSBp bnRlcmVzdGluZy4NCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5j b208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAx MCwgMjAxNSBhdCAyOjE1IFBNDQpUbzogTW9ydGV6YSBBbnNhcmkgPG1vcmFuc2FyQGNpc2NvLmNv bTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4sICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2lt QGlldGYub3JnPiIgPHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KU3ViamVj dDogUkU6IFNDSU0gU29mdCBEZWxldGUgRHJhZnQNCg0KV2h5IG5vIOKAnHNvZnQgY3JlYXRl4oCd ID8NCg0KRnJvbTogTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKSBbbWFpbHRvOm1vcmFuc2FyQGNp c2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IDEyOjI3IFBNDQpUbzogQW50 aG9ueSBOYWRhbGluOyBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFNDSU0gU29mdCBEZWxldGUgRHJhZnQNCg0KWWVzLiBUaGVyZSBpcyBhIHZlcnkgc2hv cnQgYmx1cmIgYWJvdXQgdGhlIGZhY3QgeW91IGNvdWxkIHByb3ZpZGUgYWRkaXRpb25hbCBhdHRy aWJ1dGVzIHRvIHJlc29sdmUgYW55IHBvdGVudGlhbCBuYW1lc3BhY2UgY29uZmxpY3RzLiBGb3Ig ZXhhbXBsZSBpZiB5b3UgYXJlIHVuZGVsZXRpbmcgYSB1c2VyIHlvdSBjb3VsZCBzZW5kIGEgbmV3 IHVzZXJOYW1lIGFzIHBhcnQgb2YgdGhlIG1vZGlmeSByZXF1ZXN0IHNvIHlvdSB1bmRlbGV0ZSB0 aGUgdXNlciBvYmplY3QgYW5kIHJlc29sdmUgdGhlIGNvbmZsaWN0Lg0KDQpUaGUgbW9yZSBpbnRl cmVzdGluZyBjYXNlIGlzIHRoZSByZWZlcmVuY2VzIGFuZCB3aGF0IHRvIGRvIGluIHRob3NlIGNh c2VzLiBSZWZlcmVuY2VzIHNob3VsZCBub3QgYmUgdmlzaWJsZSBpbiBjYXNlcyBvZiBzb2Z0IGRl bGV0ZWQgb2JqZWN0cywgdGhlIHF1ZXN0aW9uIGlzIGhvdyBleHBlbnNpdmUgaXMgdG8gbWFpbnRh aW4gdGhhdCBpbmZvcm1hdGlvbiBhbmQgYWRkIHRoZSBsaW5rcyBhZnRlciB0aGUgb2JqZWN0IGlz IHVuZGVsZXRlZC4NCg0KSW4gYSBwcm90b3R5cGUgSSBoYXZlIGRvbmUgb2YgdGhpcywgSSB0b29r IHRoZSBlYXN5IHJvdXRlIGFuZCBqdXN0IGRlbGV0ZWQgcmVmZXJlbmNlcyBhbmQgdGhleSBuZWVk IHRvIGJlIHJlLWNyZWF0ZWQuIE9idmlvdXNseSBpdCB3b3JrcywgYnV0IGl0IGlzIG5vdCB0aGUg bW9zdCB1c2VmdWwgc29sdXRpb24uIFRoZW4gYWdhaW4gaWYgdGhpcyBpcyBhIHByb3Zpc2lvbmlu ZyBjYXNlIGFuZCBlc3NlbnRpYWxseSBhIHNsYXZlIG9mIGFub3RoZXIgSURNIHNvbHV0aW9uLCBp dCBjYW4gZWFzaWx5IGJlIHJlY3JlYXRlZC4gVGhlIHJlYWwgcHJvYmxlbSBpcyBwcmVzZXJ2aW5n IHRoZSBJRCBvZiB0aGUgdXNlciBhbmQgcmVpbnN0YXRpbmcgaXQgcmF0aGVyIHRoYW4gZ2V0dGlu ZyBhIG5ldyBJRC4NCg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0 LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1hcmNo IDEwLCAyMDE1IGF0IDEyOjE0IFBNDQpUbzogTW9ydGV6YSBBbnNhcmkgPG1vcmFuc2FyQGNpc2Nv LmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4sICJzY2ltQGlldGYub3JnPG1haWx0bzpz Y2ltQGlldGYub3JnPiIgPHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUkU6IFNDSU0gU29mdCBEZWxldGUgRHJhZnQNCg0KU28gaWYgSSBkZWxldGUgKHNvZnQp IGFuIG9iamVjdCBhbmQgdGhlbiBhZGQgYSBuZXcgb2JqZWN0IHdpdGggdGhlIHNhbWUgbmFtZSwg YW5kIHRoZW4gSSB1bmRlbGV0ZSB0aGUgb2JqZWN0IEkgZGVsZXRlZCB3b3VsZCB0aGUgdW5kZWxl dGUgZmFpbCA/DQoNCkZyb206IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpDQpTZW50OiBNb25kYXksIE1hcmNo IDksIDIwMTUgNTo1MCBQTQ0KVG86IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbc2NpbV0gU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdA0KDQpQaGlsIEh1bnQgYW5k IEkgcHV0IHRvZ2V0aGVyIGEgdmVyeSB2ZXJ5IHZlcnkgcm91Z2ggZHJhZnQgZm9yIFNDSU0gc29m dCBkZWxldGUgc2VtYW50aWNzLiBUaGUgZHJhZnQgaXMgbWlzc2luZyBhIGxvdCBvZiBkZXRhaWxz IGFuZCByZXF1aXJlIGEgbG90IG1vcmUgdGhpbmtpbmcgYnV0IHdlIHdhbnRlZCB0byBwdXQgdGhl IGJhc2ljIGNvbmNlcHQgb3V0IHRoZXJlIGZvciBkaXNjdXNzaW9uIGF0IERhbGxhcy4gVGhlIGlk ZWEgb2Ygc29mdCBkZWxldGUvdW5kZWxldGUgaGFzIGNvbWUgdXAgbWFueSB0aW1lcyBpbiB2YXJp b3VzIGZvcnVtcyBhbmQgSSBwZXJzb25hbGx5IHRoaW5rIGl0IGlzIGEgdmVyeSBpbXBvcnRhbnQg YXNwZWN0IG9mIHJlYWwgbGlmZSBvcGVyYXRpb25hbGl6aW5nIFNDSU0uDQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFuc2FyaS1zY2ltLXNvZnQtZGVsZXRlLw0KDQpJ IHdvdWxkIGxpa2UgYSBzbG90IG9uIHRoZSBhZ2VuZGEgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0IGFu ZCBnZXQgZmVlZGJhY2sgZnJvbSB0aGUgV0cuDQoNCg0KQ2hlZXJzLA0KTW9ydGV6YQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5n IGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KDQoNCi0tDQotLS0tLQ0KaHR0cDovL3d3 dy5oZWFsdGhpbnRlcnNlY3Rpb25zLmNvbS5hdSAvIGdyYWhhbWVAaGVhbHRoaW50ZXJzZWN0aW9u cy5jb20uYXU8bWFpbHRvOmdyYWhhbWVAaGVhbHRoaW50ZXJzZWN0aW9ucy5jb20uYXU+IC8gKzYx IDQxMSA4NjcgMDY1DQo= --_000_BN3PR0301MB1234121E967DA9D89226C510A6180BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm8sIGFjdGl2ZSBt ZWFucyBqdXN0IHRoYXQsIEnigJltIG5vdCBhbiBlbXBsb3llZSB5ZXQsIHRodXMgaXTigJlzIGEg c29mdCBjcmVhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gZ3JhaGFt ZWdAZ21haWwuY29tIFttYWlsdG86Z3JhaGFtZWdAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5HcmFoYW1lIEdyaWV2ZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAxMCwg MjAxNSAyOjMxIFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8 L2I+IE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcik7IHNjaW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzY2ltXSBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIHN0YXR1cyBhY3RpdmUgPSB0cnVlfGZh bHNlLCBub3QgYSBzb2Z0IGNyZWF0ZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+R3JhaGFtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDExLCAyMDE1IGF0IDg6MjIgQU0s IEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2FzZSBpcyB3aGVyZSBhbiBu ZXcgZW1wbG95ZWUgaGFzIG5vdCBzdGFydGVkIHdvcmsgeWV0LCBJIGdvIHRocm91Z2ggdGhlIHBy b2Nlc3MsIGdldCByZWdpc3RlcmVkLCBldGMuDQogYW5kIGxpbmtzIHRvIHRoaW5ncyBJIG5lZWQg YW5kIGp1c3QgbGlrZSBkZWxldGUgd2hlbiBJIGRvIHRoZSBoYXJkIGNyZWF0ZSBldmVyeXRoaW5n IHdvcmtzLCB1cCB1bnRpbCB0aGVuIEkgZ2V0IHNhbWUgcmVzdWx0cyBhcyBzb2Z0IGRlbGV0ZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0iMTRj MDU5MjFkNWJhOGZhZV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTW9ydGV6YSBBbnNhcmkgKG1vcmFu c2FyKSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5tb3JhbnNhckBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIE1hcmNoIDEwLCAyMDE1IDI6MTcgUE08L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRh bGluOyA8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1A aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTQ0lNIFNvZnQgRGVsZXRlIERy YWZ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ QmVjYXVzZSBJIGhhZG7igJl0IHRob3VnaHQgb2YgaXQgYW5kIGRpZG7igJl0IGhhdmUgYSB1c2Ug Y2FzZSBmb3IgaXQgOik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4/Jm5i c3A7IE1pZ2h0IGJlIGludGVyZXN0aW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFu dGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IGF0IDI6MTUgUE08YnI+DQo8Yj5UbzogPC9i Pk1vcnRlemEgQW5zYXJpICZsdDs8YSBocmVmPSJtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+bW9yYW5zYXJAY2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBTQ0lNIFNvZnQg RGVsZXRlIERyYWZ0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaHkgbm8g4oCcc29mdCBjcmVh dGXigJ0gPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+IE1vcnRlemENCiBBbnNhcmkgKG1vcmFuc2FyKSBbPGEgaHJl Zj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptb3Jh bnNhckBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDEw LCAyMDE1IDEyOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IDxhIGhyZWY9 Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNDSU0gU29mdCBEZWxldGUgRHJhZnQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+WWVz LiBUaGVyZSBpcyBhIHZlcnkgc2hvcnQgYmx1cmIgYWJvdXQgdGhlIGZhY3QgeW91IGNvdWxkIHBy b3ZpZGUgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHRvIHJlc29sdmUgYW55DQogcG90ZW50aWFsIG5h bWVzcGFjZSBjb25mbGljdHMuIEZvciBleGFtcGxlIGlmIHlvdSBhcmUgdW5kZWxldGluZyBhIHVz ZXIgeW91IGNvdWxkIHNlbmQgYSBuZXcgdXNlck5hbWUgYXMgcGFydCBvZiB0aGUgbW9kaWZ5IHJl cXVlc3Qgc28geW91IHVuZGVsZXRlIHRoZSB1c2VyIG9iamVjdCBhbmQgcmVzb2x2ZSB0aGUgY29u ZmxpY3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgbW9yZSBpbnRlcmVzdGluZyBjYXNlIGlzIHRoZSBy ZWZlcmVuY2VzIGFuZCB3aGF0IHRvIGRvIGluIHRob3NlIGNhc2VzLiBSZWZlcmVuY2VzIHNob3Vs ZCBub3QgYmUgdmlzaWJsZQ0KIGluIGNhc2VzIG9mIHNvZnQgZGVsZXRlZCBvYmplY3RzLCB0aGUg cXVlc3Rpb24gaXMgaG93IGV4cGVuc2l2ZSBpcyB0byBtYWludGFpbiB0aGF0IGluZm9ybWF0aW9u IGFuZCBhZGQgdGhlIGxpbmtzIGFmdGVyIHRoZSBvYmplY3QgaXMgdW5kZWxldGVkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+SW4gYSBwcm90b3R5cGUgSSBoYXZlIGRvbmUgb2YgdGhpcywgSSB0b29rIHRoZSBl YXN5IHJvdXRlIGFuZCBqdXN0IGRlbGV0ZWQgcmVmZXJlbmNlcyBhbmQgdGhleSBuZWVkIHRvDQog YmUgcmUtY3JlYXRlZC4gT2J2aW91c2x5IGl0IHdvcmtzLCBidXQgaXQgaXMgbm90IHRoZSBtb3N0 IHVzZWZ1bCBzb2x1dGlvbi4gVGhlbiBhZ2FpbiBpZiB0aGlzIGlzIGEgcHJvdmlzaW9uaW5nIGNh c2UgYW5kIGVzc2VudGlhbGx5IGEgc2xhdmUgb2YgYW5vdGhlciBJRE0gc29sdXRpb24sIGl0IGNh biBlYXNpbHkgYmUgcmVjcmVhdGVkLiBUaGUgcmVhbCBwcm9ibGVtIGlzIHByZXNlcnZpbmcgdGhl IElEIG9mIHRoZSB1c2VyIGFuZCByZWluc3RhdGluZw0KIGl0IHJhdGhlciB0aGFuIGdldHRpbmcg YSBuZXcgSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IGF0 IDEyOjE0IFBNPGJyPg0KPGI+VG86IDwvYj5Nb3J0ZXphIEFuc2FyaSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vcmFuc2FyQGNpc2NvLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SRTogU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+U28gaWYgSSBkZWxldGUgKHNvZnQpIGFuIG9iamVjdCBhbmQgdGhlbiBhZGQgYSBuZXcg b2JqZWN0IHdpdGggdGhlIHNhbWUgbmFtZSwgYW5kIHRoZW4gSSB1bmRlbGV0ZSB0aGUNCiBvYmpl Y3QgSSBkZWxldGVkIHdvdWxkIHRoZSB1bmRlbGV0ZSBmYWlsID88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBzY2lt DQogWzxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ TW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNo IDksIDIwMTUgNTo1MCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBbc2NpbV0gU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5QaGlsIEh1bnQgYW5kIEkg cHV0IHRvZ2V0aGVyIGEgdmVyeSB2ZXJ5IHZlcnkgcm91Z2ggZHJhZnQgZm9yIFNDSU0gc29mdCBk ZWxldGUgc2VtYW50aWNzLiBUaGUgZHJhZnQgaXMNCiBtaXNzaW5nIGEgbG90IG9mIGRldGFpbHMg YW5kIHJlcXVpcmUgYSBsb3QgbW9yZSB0aGlua2luZyBidXQgd2Ugd2FudGVkIHRvIHB1dCB0aGUg YmFzaWMgY29uY2VwdCBvdXQgdGhlcmUgZm9yIGRpc2N1c3Npb24gYXQgRGFsbGFzLiBUaGUgaWRl YSBvZiBzb2Z0IGRlbGV0ZS91bmRlbGV0ZSBoYXMgY29tZSB1cCBtYW55IHRpbWVzIGluIHZhcmlv dXMgZm9ydW1zIGFuZCBJIHBlcnNvbmFsbHkgdGhpbmsgaXQgaXMgYSB2ZXJ5IGltcG9ydGFudCBh c3BlY3QNCiBvZiByZWFsIGxpZmUgb3BlcmF0aW9uYWxpemluZyBTQ0lNLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYW5zYXJp LXNjaW0tc29mdC1kZWxldGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYW5zYXJpLXNjaW0tc29mdC1kZWxldGUvPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+SSB3b3VsZCBsaWtlIGEgc2xvdCBvbiB0aGUgYWdlbmRhIHRvIGRpc2N1c3MgdGhpcyBk cmFmdCBhbmQgZ2V0IGZlZWRiYWNrIGZyb20gdGhlIFdHLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNoZWVycyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+TW9ydGV6YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5z Y2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2NpbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5o ZWFsdGhpbnRlcnNlY3Rpb25zLmNvbS5hdSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaGVh bHRoaW50ZXJzZWN0aW9ucy5jb20uYXU8L2E+IC8NCjxhIGhyZWY9Im1haWx0bzpncmFoYW1lQGhl YWx0aGludGVyc2VjdGlvbnMuY29tLmF1IiB0YXJnZXQ9Il9ibGFuayI+Z3JhaGFtZUBoZWFsdGhp bnRlcnNlY3Rpb25zLmNvbS5hdTwvYT4gLyAmIzQzOzYxIDQxMSA4NjcgMDY1PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR0301MB1234121E967DA9D89226C510A6180BN3PR0301MB1234_-- From nobody Tue Mar 10 14:44:45 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393011A8AD7 for ; Tue, 10 Mar 2015 14:44:44 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hcagOMPrgABL for ; Tue, 10 Mar 2015 14:44:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3661A8ACC for ; Tue, 10 Mar 2015 14:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19369; q=dns/txt; s=iport; t=1426023881; x=1427233481; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=70BW+3MLHeAyF6DXniago8W2tL63acMZtjRgjwFEndc=; b=TJ5R8gmmHE+0Tpi1PeV14l66B5yMWNyD0FUoLb+1Kgtqk+eZhKE551J3 /fOH2m9KpS/TAnW5IrpjD4f2+Y9ggo+Ern8gvJXGyKH0T8+woM6FDTgfT PXw7TymQXsyAci0IcSHEkEGiGIwRgrYFDjUaap91vtoEniIhfsb1mYPKA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfBgCqaeJU/4UNJK1bgkNDUloEwBKCKoVxAoEYQwEBAQEBAXyEDAEBAQQtXAIBCA4DAwEBARYSBzIUCQgCBAESGQKIEg3OKAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiwyECxEBPw0KAQqEIAWEVoE3iSuDV4VggRiDDY5oIoNub4EEBxcGHH8BAQE X-IronPort-AV: E=Sophos;i="5.11,377,1422921600"; d="scan'208,217";a="402297632" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 10 Mar 2015 21:44:41 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2ALie51023934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 21:44:40 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 16:44:40 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , "scim@ietf.org" Thread-Topic: SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgAAiqYD//+UNAA== Date: Tue, 10 Mar 2015 21:44:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.73.213] Content-Type: multipart/alternative; boundary="_000_D124B17C120576moransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:44:44 -0000 --_000_D124B17C120576moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Not sure if these two are similar. In case of new employee provisioning, I = would actually want to =93reserve=94 the userName and that is already in th= e core spec. You can create users marking them disabled using the =93active= =94 attribute. A similar use case exist for self provisioning when there is work flow asso= ciated with it. For example user self registers for a service but the accou= nt is not finalize until the user validates an email address or an admin ap= prove the account creation. In both these cases the username needs to be re= served until the account is actually validated or rejected. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:22 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft Case is where an new employee has not started work yet, I go through the pr= ocess, get registered, etc. and links to things I need and just like delete= when I do the hard create everything works, up until then I get same resul= ts as soft delete From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 2:17 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Because I hadn=92t thought of it and didn=92t have a use case for it :) Can you please explain? Might be interesting. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:15 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft Why no =93soft create=94 ? From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza --_000_D124B17C120576moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Not sure if these two are similar. In case of new employee provisionin= g, I would actually want to =93reserve=94 the userName and that is already = in the core spec. You can create users marking them disabled using the =93a= ctive=94 attribute.

A similar use case exist for self provisioning when there is work flow= associated with it. For example user self registers for a service but the = account is not finalize until the user validates an email address or an adm= in approve the account creation. In both these cases the username needs to be reserved until the account is= actually validated or rejected.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:= 22 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft=

Case is where an new employee has n= ot started work yet, I go through the process, get registered, etc. and lin= ks to things I need and just like delete when I do the hard create everything works, up until then I get same resul= ts as soft delete

&n= bsp;

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 2:17 PM
To: Anthony Nadalin; scim@ietf.org<= /a>
Subject: Re: SCIM Soft Delete Draft

 

Because I hadn=92t thought of it and didn=92= t have a use case for it :)

 

Can you please explain?  Might be inter= esting.

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:15 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

Why no =93soft create=94 ?

 

From: Morteza Ansari (mora= nsar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org<= /a>
Subject: Re: SCIM Soft Delete Draft

 =

Yes. There is a very short blurb about the f= act you could provide additional attributes to resolve any potential namesp= ace conflicts. For example if you are undeleting a user you could send a new userName as part of the modify requ= est so you undelete the user object and resolve the conflict.

 

The more interesting case is the references = and what to do in those cases. References should not be visible in cases of= soft deleted objects, the question is how expensive is to maintain that information and add the links after t= he object is undeleted.

 

In a prototype I have done of this, I took t= he easy route and just deleted references and they need to be re-created. O= bviously it works, but it is not the most useful solution. Then again if this is a provisioning case and essent= ially a slave of another IDM solution, it can easily be recreated. The real= problem is preserving the ID of the user and reinstating it rather than ge= tting a new ID.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransa= r@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

So if I delete (soft) an object and= then add a new object with the same name, and then I undelete the object I= deleted would the undelete fail ?<= /o:p>

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 =

Phil Hunt and I put together a very very ver= y rough draft for SCIM soft delete semantics. The draft is missing a lot of= details and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas.= The idea of soft delete/undelete has come up many times in various forums = and I personally think it is a very important aspect of real life operation= alizing SCIM.

 

 

I would like a slot on the agenda to discuss= this draft and get feedback from the WG.

 

 

Cheers,

Morteza

 --_000_D124B17C120576moransarciscocom_-- From nobody Tue Mar 10 14:52:27 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3D1A8BC5 for ; Tue, 10 Mar 2015 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 0fX_helWBtKx for ; Tue, 10 Mar 2015 14:52:24 -0700 (PDT) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3AA1A8AF7 for ; Tue, 10 Mar 2015 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426024343; bh=JbCTrixex34TSf3Wzo0OphQndiSKaD3eAifw+cAUqPM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=t50xMicGZqoLvPCyJ53/2PWK5KVxhfZIUIH+9ebSX3hJEwp4KxnZdBSp7FOOx+BDoFWVR54qjCBdXUKyMxt5kzkswGkCD2o6e6tI/txmdO1wXH5DDzmADyPMJqpnVmENadoObeMQuksyRfZXulPdMkCtPcoe24hCxFfBtTOPl4T+bMK1YtQkVSKeYJIsRez6kMWk+fNFZXUP2M1GdfoR5JP5NklmTw1oUpfyq9SnSWHTiAjMvM6mKbKgGUNPjoiF5NdDt8AME5Un67OoTC087zlHXaZ7sHjAVFJgK/PEFS6P8I/xstek6Basq90df1h4p4on+q3JJK2mSM0Py0+aSg== Received: from [66.196.81.170] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 10 Mar 2015 21:52:23 -0000 Received: from [98.139.212.193] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 10 Mar 2015 21:52:19 -0000 Received: from [127.0.0.1] by omp1002.mail.bf1.yahoo.com with NNFMP; 10 Mar 2015 21:45:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 631552.73049.bm@omp1002.mail.bf1.yahoo.com X-YMail-OSG: e0iC6HMVM1nSAPujK.9i12BkCHx3XATLqb8kff4whL0eVCh4jFeSJ.U.ITew7pn ZxRzqOPWtS_UuFhYcfnlS53Rzy4kJx1agaT38jqdJ8YLUGAQOynm3EfS7dXooknzobMd2wY_070B p3oQEM6q2yXcl145KeMgDRg13TVaoXLlsoD0nIMumg8rc6__.1mvxvOuVoFNY7Exap3TsUJwfay4 UNLSAyRXhYdkg4fhzYTXl1g.Y_th2l2Kv3XYpfcG5yBYYe0l2Fzb702FbORGl2QoHlFLqPVG3Kgt hDwyR4JEucd0iP5MZE1J7sr7m82C0t3aqXsS4YL9CDhtsU3eHFpS4Fxs1nk_JC2RCrk._A8osoP3 xA_jL_KBIgyLGHLHH7JZhsNiz9WAA9uKtUmGQHUm7Gf4qAXOxnpaxq1Fvidbrxj4KgBcEe7bSAy9 63ugzEgttpk0PN12ftQPy5L15QSEmy_UUvTSqf.e7DYXx5BVU1PPGPNigc90BFf_BVNuVuD5rtMo 4cTiIGCsfTjcNjq5CUuw1yPPIfgCsFzunRhB3EfHh8v9pkXJCQW4JhArasPpl7Km6HJ1XxUh2Uzs uZvx3LDKGAW1xNV1JcKHPGhiPgrc7gqzrSA-- Received: by 66.196.81.104; Tue, 10 Mar 2015 21:45:56 +0000 Date: Tue, 10 Mar 2015 21:45:55 +0000 (UTC) From: Bill Mills To: Anthony Nadalin , Grahame Grieve Message-ID: <1848782557.3119799.1426023955805.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3119798_300578459.1426023955782" Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:52:26 -0000 ------=_Part_3119798_300578459.1426023955782 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also perhaps useful for reserving an identifier for later use. =C2=A0I don'= t know if I would go farther than that because you have top make sure that = downstream systems don't automatically act based on the presence of the rec= ord. =20 On Tuesday, March 10, 2015 2:40 PM, Anthony Nadalin wrote: =20 #yiv4426703768 #yiv4426703768 -- _filtered #yiv4426703768 {panose-1:2 4 5 = 3 5 4 6 3 2 4;} _filtered #yiv4426703768 {font-family:Calibri;panose-1:2 15= 5 2 2 2 4 3 2 4;}#yiv4426703768 #yiv4426703768 p.yiv4426703768MsoNormal, #= yiv4426703768 li.yiv4426703768MsoNormal, #yiv4426703768 div.yiv4426703768Ms= oNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv4426703768 = a:link, #yiv4426703768 span.yiv4426703768MsoHyperlink {color:blue;text-deco= ration:underline;}#yiv4426703768 a:visited, #yiv4426703768 span.yiv44267037= 68MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv4426703= 768 p {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv4426703768 sp= an.yiv4426703768EmailStyle18 {color:#1F497D;}#yiv4426703768 .yiv4426703768M= soChpDefault {} _filtered #yiv4426703768 {margin:1.0in 1.0in 1.0in 1.0in;}#= yiv4426703768 div.yiv4426703768WordSection1 {}#yiv4426703768 No, active mea= ns just that, I=E2=80=99m not an employee yet, thus it=E2=80=99s a soft cre= ate =C2=A0 From: grahameg@gmail.com [mailto:grahameg@gmail.com]On Behalf O= f Grahame Grieve Sent: Tuesday, March 10, 2015 2:31 PM To: Anthony Nadalin Cc: Morteza Ansari (moransar); scim@ietf.org Subject: Re: [scim] SCIM Soft Delete Draft =C2=A0 This is a status active = =3D true|false, not a soft create=C2=A0 =C2=A0 Grahame =C2=A0 =C2=A0 On = Wed, Mar 11, 2015 at 8:22 AM, Anthony Nadalin wrote= :=20 Case is where an new employee has not started work yet, I go through the pr= ocess, get registered, etc. and links to things I need and just like delete= when I do the hard create everything works, up until then I get same resul= ts as soft delete =C2=A0 From: Morteza Ansari (moransar) [mailto:moransar@c= isco.com] Sent: Tuesday, March 10, 2015 2:17 PM=20 To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft =C2=A0 Because I hadn=E2=80=99t thought= of it and didn=E2=80=99t have a use case for it :) =C2=A0 Can you please e= xplain?=C2=A0 Might be interesting. =C2=A0 From:Anthony Nadalin Date: Tuesday, March 10, 2015 at 2:15 PM To: Morteza Ansari , "scim@ietf.org" Subject: RE: SCIM Soft Delete Draft =C2=A0 Why no =E2=80=9Csoft create=E2= =80=9D ? =C2=A0 From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft =C2=A0 Yes. There is a very short blurb= about the fact you could provide additional attributes to resolve any pote= ntial namespace conflicts. For example if you are undeleting a user you cou= ld send a new userName as part of the modify request so you undelete the us= er object and resolve the conflict. =C2=A0 The more interesting case is the= references and what to do in those cases. References should not be visible= in cases of soft deleted objects, the question is how expensive is to main= tain that information and add the links after the object is undeleted. =C2= =A0 In a prototype I have done of this, I took the easy route and just dele= ted references and they need to be re-created. Obviously it works, but it i= s not the most useful solution. Then again if this is a provisioning case a= nd essentially a slave of another IDM solution, it can easily be recreated.= The real problem is preserving the ID of the user and reinstating it rathe= r than getting a new ID. =C2=A0 =C2=A0 From:Anthony Nadalin Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari , "scim@ietf.org" Subject: RE: SCIM Soft Delete Draft =C2=A0 So if I delete (soft) an object = and then add a new object with the same name, and then I undelete the objec= t I deleted would the undelete fail ? =C2=A0 From: scim [mailto:scim-bounce= s@ietf.org]On Behalf Of Morteza Ansari (moransar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft =C2=A0 Phil Hunt and I put together = a very very very rough draft for SCIM soft delete semantics. The draft is m= issing a lot of details and require a lot more thinking but we wanted to pu= t the basic concept out there for discussion at Dallas. The idea of soft de= lete/undelete has come up many times in various forums and I personally thi= nk it is a very important aspect of real life operationalizing SCIM. =C2=A0= https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ =C2=A0 I w= ould like a slot on the agenda to discuss this draft and get feedback from = the WG. =C2=A0 =C2=A0 Cheers, Morteza=20 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim=20 =C2=A0 -- ----- http://www.healthintersections.com.au /grahame@healthintersections.com.au /= +61 411 867 065=20 _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_Part_3119798_300578459.1426023955782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also perhaps useful for reserving= an identifier for later use.  I don't know if I would go farther than= that because you have top make sure that downstream systems don't automati= cally act based on the presence of the record.




On Tuesday, March 10, 2015 2:40 PM, Anthony Nadalin <= ;tonynad@microsoft.com> wrote:


No, active means just that, I=E2=80=99m not an employee yet, thus it=E2= =80=99s a soft create
=20 =20
<= b>From: grahameg@gmail.com [mai= lto:grahameg@gmail.com] On Behalf Of Grahame Grieve
Sent: Tuesday, March 10, 2015 2:31 PM
To: Anthony Nadalin
Cc: Morteza Ansari (moransar); scim@ietf.org
Subject: Re: [scim] SCIM Soft Delete Draft
=20
 
=20
This is a status active =3D true|false, not a soft create 
=20
 
=20
Grahame
=20
 
=20
 
=20
On Wed, Mar 11, 2015 at 8:22 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:<= /div>=20
Case is where an new employee has not started work yet, I go t= hrough the process, get registered, etc. and links to things I need and just like delete when I do the hard create = everything works, up until then I get same results as soft delete=20 =20
=20

To: Anthony Nadalin; scim@i= etf.org
Subject: Re: SCIM Soft Delete Draft
=20
 
=20
Because I hadn=E2=80=99t thought of it and didn=E2=80=99t have= a use case for it :)
=20
 
=20
Can you please explain?  Might be interesting.=20
 
=20
From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 201= 5 at 2:15 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.= org>
Subject: RE: SCIM Soft Delet= e Draft
=20
 
=20
Why no =E2=80=9Csoft create=E2=80=9D ?
=20
 
=20
From: Morteza Ansari (moransar) [mail= to:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@i= etf.org
Subject: Re: SCIM Soft Delete Draft
=20
 
=20
Yes. There is a very short blurb about the fact you could provide a= dditional attributes to resolve any potential namespace conflicts. For example if you are undeleting a user yo= u could send a new userName as part of the modify request so you undelete t= he user object and resolve the conflict.
=20
 
=20
The more interesting case is the references and what to do in = those cases. References should not be visible in cases of soft deleted objects, the question is how expensive is to main= tain that information and add the links after the object is undeleted.
=20
 
=20
In a prototype I have done of this, I took the easy route and just = deleted references and they need to be re-created. Obviously it works, but it is not the most useful solution.= Then again if this is a provisioning case and essentially a slave of anoth= er IDM solution, it can easily be recreated. The real problem is preserving= the ID of the user and reinstating it rather than getting a new ID.
=20
 
=20
 
=20
From: Anthony Nadalin <tonynad@microsoft.com>= ;
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.= org>
Subject: RE: SCIM Soft Delete Draft
=20
 
=20
So if I delete (soft) an object and then add a new object with= the same name, and then I undelete the object I deleted would the undelete fail ?
=20
 
=20
From: scim [mailto:scim-boun= ces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft
=20
 
=20
Phil Hunt and I put together a very very very rough draft for SCIM = soft delete semantics. The draft is missing a lot of details and require a lot more thinking but we wanted to = put the basic concept out there for discussion at Dallas. The idea of soft = delete/undelete has come up many times in various forums and I personally t= hink it is a very important aspect of real life operationalizing SCIM.
=20
 
=20
 
=20
I would like a slot on the agenda to discuss this draft and get fee= dback from the WG.
=20
 
=20
 
=20
Cheers,
=20
Morteza
=20

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


=20
 
=20
--
=20

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


------=_Part_3119798_300578459.1426023955782-- From nobody Tue Mar 10 14:56:07 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC581A8F42 for ; Tue, 10 Mar 2015 14:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uIJu-YuqUvKd for ; Tue, 10 Mar 2015 14:56:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281851A8F3D for ; Tue, 10 Mar 2015 14:56:03 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2ALu1A4024784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Mar 2015 21:56:02 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2ALu0da027971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2015 21:56:00 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2ALtxiW024810; Tue, 10 Mar 2015 21:55:59 GMT Received: from [25.111.143.51] (/24.114.74.112) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Mar 2015 14:55:58 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-AC5562A9-EB06-4D61-9489-F58B5E6CA323 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 10 Mar 2015 14:55:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8567D035-16D0-4668-B1A7-5D7D1A36835D@oracle.com> References: To: "Morteza Ansari (moransar)" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: Anthony Nadalin , "scim@ietf.org" Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 21:56:05 -0000 --Apple-Mail-AC5562A9-EB06-4D61-9489-F58B5E6CA323 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wasn't the original perspective an issue of tombstoning? I do think this would be a great opportunity to discuss the relationship to a= ctivation and deactivation.=20 Phil > On Mar 10, 2015, at 14:17, Morteza Ansari (moransar) w= rote: >=20 > Because I hadn=E2=80=99t thought of it and didn=E2=80=99t have a use case f= or it :) >=20 > Can you please explain? Might be interesting. >=20 > From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:15 PM > To: Morteza Ansari , "scim@ietf.org" > Subject: RE: SCIM Soft Delete Draft >=20 > Why no =E2=80=9Csoft create=E2=80=9D ? > =20 > From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]=20 > Sent: Tuesday, March 10, 2015 12:27 PM > To: Anthony Nadalin; scim@ietf.org > Subject: Re: SCIM Soft Delete Draft > =20 > Yes. There is a very short blurb about the fact you could provide addition= al attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. > =20 > The more interesting case is the references and what to do in those cases.= References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links afte= r the object is undeleted. > =20 > In a prototype I have done of this, I took the easy route and just deleted= references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and es= sentially a slave of another IDM solution, it can easily be recreated. The r= eal problem is preserving the ID of the user and reinstating it rather than g= etting a new ID. > =20 > =20 > From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM > To: Morteza Ansari , "scim@ietf.org" > Subject: RE: SCIM Soft Delete Draft > =20 > So if I delete (soft) an object and then add a new object with the same na= me, and then I undelete the object I deleted would the undelete fail ? > =20 > From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mor= ansar) > Sent: Monday, March 9, 2015 5:50 PM > To: scim@ietf.org > Subject: [scim] SCIM Soft Delete Draft > =20 > Phil Hunt and I put together a very very very rough draft for SCIM soft de= lete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in various= forums and I personally think it is a very important aspect of real life op= erationalizing SCIM. > =20 > https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ > =20 > I would like a slot on the agenda to discuss this draft and get feedback f= rom the WG. > =20 > =20 > Cheers, > Morteza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-AC5562A9-EB06-4D61-9489-F58B5E6CA323 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Wasn't the original perspective an iss= ue of tombstoning?

I do think this would be a great= opportunity to discuss the relationship to activation and deactivation.&nbs= p;

Phil

On Mar 10, 2015, at 14:17, Morteza Ansari (mora= nsar) <moransar@cisco.com> w= rote:

Because I hadn=E2=80=99t thought of it and didn=E2=80=99t have a use ca= se for it :)

Can you please explain?  Might be interesting.

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 2:1= 5 PM
To: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf= .org>
Subject: RE: SCIM Soft Delete Draft<= br>

Why no =E2=80=9Csoft create=E2=80=9D ?=

&nbs= p;

From: Morteza Ansari (moransar) [mailto:moransar@cisco.com]
Sent: Tuesday, March 10, 2015 12:27 PM
To: Anthony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft

 

Yes. There is a very short blurb about the fac= t you could provide additional attributes to resolve any potential namespace= conflicts. For example if you are undeleting a user you could send a new userName as part of the modify reque= st so you undelete the user object and resolve the conflict.

 

The more interesting case is the references an= d what to do in those cases. References should not be visible in cases of so= ft deleted objects, the question is how expensive is to maintain that information and add the links after th= e object is undeleted.

 

In a prototype I have done of this, I took the= easy route and just deleted references and they need to be re-created. Obvi= ously it works, but it is not the most useful solution. Then again if this is a provisioning case and essenti= ally a slave of another IDM solution, it can easily be recreated. The real p= roblem is preserving the ID of the user and reinstating it rather than getti= ng a new ID.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Tuesday, March 10, 2015 at 12:14 PM
To: Morteza Ansari <moransar= @cisco.com>, "scim@ietf.org" <= ;scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft

 

So if I delete (soft) an object and t= hen add a new object with the same name, and then I undelete the object I de= leted would the undelete fail ?

 

From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (moransar)
Sent: Monday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft

 <= /p>

Phil Hunt and I put together a very very very r= ough draft for SCIM soft delete semantics. The draft is missing a lot of det= ails and require a lot more thinking but we wanted to put the basic concept out there for discussion at Dallas. T= he idea of soft delete/undelete has come up many times in various forums and= I personally think it is a very important aspect of real life operationaliz= ing SCIM.

 =

 =

I would like a slot on the agenda to discuss t= his draft and get feedback from the WG.

 =

 =

Cheers,

Morteza
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-AC5562A9-EB06-4D61-9489-F58B5E6CA323-- From nobody Tue Mar 10 15:28:46 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7665F1A8AF8 for ; Tue, 10 Mar 2015 15:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cumcT0c8o30X for ; Tue, 10 Mar 2015 15:28:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956181A9062 for ; Tue, 10 Mar 2015 15:28:40 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 22:28:39 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0106.007; Tue, 10 Mar 2015 22:28:39 +0000 From: Anthony Nadalin To: Phil Hunt , "Morteza Ansari (moransar)" Thread-Topic: [scim] SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgAAsYoCAAAkUUA== Date: Tue, 10 Mar 2015 22:28:39 +0000 Message-ID: References: <8567D035-16D0-4668-B1A7-5D7D1A36835D@oracle.com> In-Reply-To: <8567D035-16D0-4668-B1A7-5D7D1A36835D@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::5] authentication-results: oracle.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(122556002)(77156002)(92566002)(62966003)(19580395003)(19300405004)(87936001)(19580405001)(19609705001)(40100003)(15975445007)(76176999)(102836002)(2950100001)(54356999)(50986999)(19625215002)(86362001)(86612001)(33656002)(16236675004)(106116001)(99286002)(74316001)(2656002)(2900100001)(46102003)(19617315012)(76576001)(93886004)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 051158ECBB Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123450F6B82BC92412CC66E7A6180BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 22:28:39.0774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 22:28:43 -0000 --_000_BN3PR0301MB123450F6B82BC92412CC66E7A6180BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBzZWVtcyBzbw0KDQpGcm9tOiBQaGlsIEh1bnQgW21haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IDI6NTYgUE0NClRvOiBNb3J0ZXph IEFuc2FyaSAobW9yYW5zYXIpDQpDYzogQW50aG9ueSBOYWRhbGluOyBzY2ltQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3NjaW1dIFNDSU0gU29mdCBEZWxldGUgRHJhZnQNCg0KV2Fzbid0IHRoZSBv cmlnaW5hbCBwZXJzcGVjdGl2ZSBhbiBpc3N1ZSBvZiB0b21ic3RvbmluZz8NCg0KSSBkbyB0aGlu ayB0aGlzIHdvdWxkIGJlIGEgZ3JlYXQgb3Bwb3J0dW5pdHkgdG8gZGlzY3VzcyB0aGUgcmVsYXRp b25zaGlwIHRvIGFjdGl2YXRpb24gYW5kIGRlYWN0aXZhdGlvbi4NCg0KUGhpbA0KDQpPbiBNYXIg MTAsIDIwMTUsIGF0IDE0OjE3LCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIDxtb3JhbnNhckBj aXNjby5jb208bWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbT4+IHdyb3RlOg0KQmVjYXVzZSBJIGhh ZG7igJl0IHRob3VnaHQgb2YgaXQgYW5kIGRpZG7igJl0IGhhdmUgYSB1c2UgY2FzZSBmb3IgaXQg OikNCg0KQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8gIE1pZ2h0IGJlIGludGVyZXN0aW5nLg0KDQpG cm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IGF0IDI6MTUg UE0NClRvOiBNb3J0ZXphIEFuc2FyaSA8bW9yYW5zYXJAY2lzY28uY29tPG1haWx0bzptb3JhbnNh ckBjaXNjby5jb20+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+IiA8c2Np bUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogU0NJTSBTb2Z0 IERlbGV0ZSBEcmFmdA0KDQpXaHkgbm8g4oCcc29mdCBjcmVhdGXigJ0gPw0KDQpGcm9tOiBNb3J0 ZXphIEFuc2FyaSAobW9yYW5zYXIpIFttYWlsdG86bW9yYW5zYXJAY2lzY28uY29tXQ0KU2VudDog VHVlc2RheSwgTWFyY2ggMTAsIDIwMTUgMTI6MjcgUE0NClRvOiBBbnRob255IE5hZGFsaW47IHNj aW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU0NJTSBTb2Z0 IERlbGV0ZSBEcmFmdA0KDQpZZXMuIFRoZXJlIGlzIGEgdmVyeSBzaG9ydCBibHVyYiBhYm91dCB0 aGUgZmFjdCB5b3UgY291bGQgcHJvdmlkZSBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgdG8gcmVzb2x2 ZSBhbnkgcG90ZW50aWFsIG5hbWVzcGFjZSBjb25mbGljdHMuIEZvciBleGFtcGxlIGlmIHlvdSBh cmUgdW5kZWxldGluZyBhIHVzZXIgeW91IGNvdWxkIHNlbmQgYSBuZXcgdXNlck5hbWUgYXMgcGFy dCBvZiB0aGUgbW9kaWZ5IHJlcXVlc3Qgc28geW91IHVuZGVsZXRlIHRoZSB1c2VyIG9iamVjdCBh bmQgcmVzb2x2ZSB0aGUgY29uZmxpY3QuDQoNClRoZSBtb3JlIGludGVyZXN0aW5nIGNhc2UgaXMg dGhlIHJlZmVyZW5jZXMgYW5kIHdoYXQgdG8gZG8gaW4gdGhvc2UgY2FzZXMuIFJlZmVyZW5jZXMg c2hvdWxkIG5vdCBiZSB2aXNpYmxlIGluIGNhc2VzIG9mIHNvZnQgZGVsZXRlZCBvYmplY3RzLCB0 aGUgcXVlc3Rpb24gaXMgaG93IGV4cGVuc2l2ZSBpcyB0byBtYWludGFpbiB0aGF0IGluZm9ybWF0 aW9uIGFuZCBhZGQgdGhlIGxpbmtzIGFmdGVyIHRoZSBvYmplY3QgaXMgdW5kZWxldGVkLg0KDQpJ biBhIHByb3RvdHlwZSBJIGhhdmUgZG9uZSBvZiB0aGlzLCBJIHRvb2sgdGhlIGVhc3kgcm91dGUg YW5kIGp1c3QgZGVsZXRlZCByZWZlcmVuY2VzIGFuZCB0aGV5IG5lZWQgdG8gYmUgcmUtY3JlYXRl ZC4gT2J2aW91c2x5IGl0IHdvcmtzLCBidXQgaXQgaXMgbm90IHRoZSBtb3N0IHVzZWZ1bCBzb2x1 dGlvbi4gVGhlbiBhZ2FpbiBpZiB0aGlzIGlzIGEgcHJvdmlzaW9uaW5nIGNhc2UgYW5kIGVzc2Vu dGlhbGx5IGEgc2xhdmUgb2YgYW5vdGhlciBJRE0gc29sdXRpb24sIGl0IGNhbiBlYXNpbHkgYmUg cmVjcmVhdGVkLiBUaGUgcmVhbCBwcm9ibGVtIGlzIHByZXNlcnZpbmcgdGhlIElEIG9mIHRoZSB1 c2VyIGFuZCByZWluc3RhdGluZyBpdCByYXRoZXIgdGhhbiBnZXR0aW5nIGEgbmV3IElELg0KDQoN CkZyb206IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMTAsIDIwMTUgYXQgMTI6 MTQgUE0NClRvOiBNb3J0ZXphIEFuc2FyaSA8bW9yYW5zYXJAY2lzY28uY29tPG1haWx0bzptb3Jh bnNhckBjaXNjby5jb20+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+IiA8 c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogU0NJTSBT b2Z0IERlbGV0ZSBEcmFmdA0KDQpTbyBpZiBJIGRlbGV0ZSAoc29mdCkgYW4gb2JqZWN0IGFuZCB0 aGVuIGFkZCBhIG5ldyBvYmplY3Qgd2l0aCB0aGUgc2FtZSBuYW1lLCBhbmQgdGhlbiBJIHVuZGVs ZXRlIHRoZSBvYmplY3QgSSBkZWxldGVkIHdvdWxkIHRoZSB1bmRlbGV0ZSBmYWlsID8NCg0KRnJv bTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1vcnRl emEgQW5zYXJpIChtb3JhbnNhcikNClNlbnQ6IE1vbmRheSwgTWFyY2ggOSwgMjAxNSA1OjUwIFBN DQpUbzogc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NClN1YmplY3Q6IFtzY2lt XSBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0DQoNClBoaWwgSHVudCBhbmQgSSBwdXQgdG9nZXRoZXIg YSB2ZXJ5IHZlcnkgdmVyeSByb3VnaCBkcmFmdCBmb3IgU0NJTSBzb2Z0IGRlbGV0ZSBzZW1hbnRp Y3MuIFRoZSBkcmFmdCBpcyBtaXNzaW5nIGEgbG90IG9mIGRldGFpbHMgYW5kIHJlcXVpcmUgYSBs b3QgbW9yZSB0aGlua2luZyBidXQgd2Ugd2FudGVkIHRvIHB1dCB0aGUgYmFzaWMgY29uY2VwdCBv dXQgdGhlcmUgZm9yIGRpc2N1c3Npb24gYXQgRGFsbGFzLiBUaGUgaWRlYSBvZiBzb2Z0IGRlbGV0 ZS91bmRlbGV0ZSBoYXMgY29tZSB1cCBtYW55IHRpbWVzIGluIHZhcmlvdXMgZm9ydW1zIGFuZCBJ IHBlcnNvbmFsbHkgdGhpbmsgaXQgaXMgYSB2ZXJ5IGltcG9ydGFudCBhc3BlY3Qgb2YgcmVhbCBs aWZlIG9wZXJhdGlvbmFsaXppbmcgU0NJTS4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtYW5zYXJpLXNjaW0tc29mdC1kZWxldGUvDQoNCkkgd291bGQgbGlrZSBhIHNs b3Qgb24gdGhlIGFnZW5kYSB0byBkaXNjdXNzIHRoaXMgZHJhZnQgYW5kIGdldCBmZWVkYmFjayBm cm9tIHRoZSBXRy4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5v cmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NjaW0NCg== --_000_BN3PR0301MB123450F6B82BC92412CC66E7A6180BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgc2VlbXMg c288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJf TWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IDI6NTYgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcik8YnI+DQo8Yj5DYzo8L2I+IEFu dGhvbnkgTmFkYWxpbjsgc2NpbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nj aW1dIFNDSU0gU29mdCBEZWxldGUgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Fzbid0IHRoZSBvcmlnaW5hbCBwZXJzcGVjdGl2ZSBh biBpc3N1ZSBvZiB0b21ic3RvbmluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyB0aGluayB0aGlzIHdvdWxkIGJlIGEgZ3JlYXQgb3Bw b3J0dW5pdHkgdG8gZGlzY3VzcyB0aGUgcmVsYXRpb25zaGlwIHRvIGFjdGl2YXRpb24gYW5kIGRl YWN0aXZhdGlvbi4mbmJzcDs8YnI+DQo8YnI+DQpQaGlsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCk9uIE1hciAxMCwgMjAxNSwgYXQgMTQ6MTcsIE1vcnRlemEgQW5zYXJpIChtb3JhbnNh cikgJmx0OzxhIGhyZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iPm1vcmFuc2FyQGNpc2Nv LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVjYXVzZSBJIGhhZG7igJl0IHRob3VnaHQgb2YgaXQg YW5kIGRpZG7igJl0IGhhdmUgYSB1c2UgY2FzZSBmb3IgaXQgOik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBwbGVhc2UgZXhwbGFp bj8gJm5ic3A7TWlnaHQgYmUgaW50ZXJlc3RpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRA bWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgTWFyY2ggMTAsIDIwMTUgYXQgMjoxNSBQTTxicj4NCjxiPlRvOiA8L2I+ TW9ydGV6YSBBbnNhcmkgJmx0OzxhIGhyZWY9Im1haWx0bzptb3JhbnNhckBjaXNjby5jb20iPm1v cmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRm Lm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2ltQGll dGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFND SU0gU29mdCBEZWxldGUgRHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+V2h5IG5vIOKAnHNvZnQgY3JlYXRl4oCdID88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgWzxhIGhyZWY9Im1h aWx0bzptb3JhbnNhckBjaXNjby5jb20iPm1haWx0bzptb3JhbnNhckBjaXNjby5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDEwLCAyMDE1IDEyOjI3IFBNPGJyPg0K PGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3Jn Ij5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU0NJTSBTb2Z0IERl bGV0ZSBEcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlllcy4gVGhlcmUgaXMgYSB2ZXJ5 IHNob3J0IGJsdXJiIGFib3V0IHRoZSBmYWN0IHlvdSBjb3VsZCBwcm92aWRlIGFkZGl0aW9uYWwg YXR0cmlidXRlcyB0byByZXNvbHZlIGFueSBwb3RlbnRpYWwgbmFtZXNwYWNlIGNvbmZsaWN0cy4g Rm9yIGV4YW1wbGUgaWYgeW91IGFyZSB1bmRlbGV0aW5nDQogYSB1c2VyIHlvdSBjb3VsZCBzZW5k IGEgbmV3IHVzZXJOYW1lIGFzIHBhcnQgb2YgdGhlIG1vZGlmeSByZXF1ZXN0IHNvIHlvdSB1bmRl bGV0ZSB0aGUgdXNlciBvYmplY3QgYW5kIHJlc29sdmUgdGhlIGNvbmZsaWN0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5UaGUgbW9yZSBpbnRlcmVzdGluZyBjYXNlIGlzIHRoZSByZWZlcmVuY2VzIGFuZCB3aGF0IHRv IGRvIGluIHRob3NlIGNhc2VzLiBSZWZlcmVuY2VzIHNob3VsZCBub3QgYmUgdmlzaWJsZSBpbiBj YXNlcyBvZiBzb2Z0IGRlbGV0ZWQgb2JqZWN0cywgdGhlIHF1ZXN0aW9uIGlzIGhvdw0KIGV4cGVu c2l2ZSBpcyB0byBtYWludGFpbiB0aGF0IGluZm9ybWF0aW9uIGFuZCBhZGQgdGhlIGxpbmtzIGFm dGVyIHRoZSBvYmplY3QgaXMgdW5kZWxldGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JbiBhIHByb3RvdHlwZSBJ IGhhdmUgZG9uZSBvZiB0aGlzLCBJIHRvb2sgdGhlIGVhc3kgcm91dGUgYW5kIGp1c3QgZGVsZXRl ZCByZWZlcmVuY2VzIGFuZCB0aGV5IG5lZWQgdG8gYmUgcmUtY3JlYXRlZC4gT2J2aW91c2x5IGl0 IHdvcmtzLCBidXQgaXQgaXMgbm90IHRoZSBtb3N0DQogdXNlZnVsIHNvbHV0aW9uLiBUaGVuIGFn YWluIGlmIHRoaXMgaXMgYSBwcm92aXNpb25pbmcgY2FzZSBhbmQgZXNzZW50aWFsbHkgYSBzbGF2 ZSBvZiBhbm90aGVyIElETSBzb2x1dGlvbiwgaXQgY2FuIGVhc2lseSBiZSByZWNyZWF0ZWQuIFRo ZSByZWFsIHByb2JsZW0gaXMgcHJlc2VydmluZyB0aGUgSUQgb2YgdGhlIHVzZXIgYW5kIHJlaW5z dGF0aW5nIGl0IHJhdGhlciB0aGFuIGdldHRpbmcgYSBuZXcgSUQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFudGhvbnkgTmFk YWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBt aWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTWFyY2ggMTAs IDIwMTUgYXQgMTI6MTQgUE08YnI+DQo8Yj5UbzogPC9iPk1vcnRlemEgQW5zYXJpICZsdDs8YSBo cmVmPSJtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tIj5tb3JhbnNhckBjaXNjby5jb208L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlNvIGlmIEkgZGVsZXRlIChzb2Z0KSBhbiBvYmplY3QgYW5kIHRo ZW4gYWRkIGEgbmV3IG9iamVjdCB3aXRoIHRoZSBzYW1lIG5hbWUsIGFuZCB0aGVuIEkgdW5kZWxl dGUgdGhlIG9iamVjdCBJIGRlbGV0ZWQgd291bGQgdGhlIHVuZGVsZXRlIGZhaWwgPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4gc2NpbSBbPGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNj aW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1vcnRlemEgQW5z YXJpIChtb3JhbnNhcik8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCA5LCAyMDE1IDU6 NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2lt QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2NpbV0gU0NJTSBTb2Z0IERlbGV0 ZSBEcmFmdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlBoaWwgSHVudCBhbmQgSSBwdXQgdG9nZXRoZXIgYSB2ZXJ5IHZlcnkgdmVyeSBy b3VnaCBkcmFmdCBmb3IgU0NJTSBzb2Z0IGRlbGV0ZSBzZW1hbnRpY3MuIFRoZSBkcmFmdCBpcyBt aXNzaW5nIGEgbG90IG9mIGRldGFpbHMgYW5kIHJlcXVpcmUgYSBsb3QgbW9yZSB0aGlua2luZw0K IGJ1dCB3ZSB3YW50ZWQgdG8gcHV0IHRoZSBiYXNpYyBjb25jZXB0IG91dCB0aGVyZSBmb3IgZGlz Y3Vzc2lvbiBhdCBEYWxsYXMuIFRoZSBpZGVhIG9mIHNvZnQgZGVsZXRlL3VuZGVsZXRlIGhhcyBj b21lIHVwIG1hbnkgdGltZXMgaW4gdmFyaW91cyBmb3J1bXMgYW5kIEkgcGVyc29uYWxseSB0aGlu ayBpdCBpcyBhIHZlcnkgaW1wb3J0YW50IGFzcGVjdCBvZiByZWFsIGxpZmUgb3BlcmF0aW9uYWxp emluZyBTQ0lNLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1hbnNhcmktc2NpbS1zb2Z0LWRlbGV0ZS8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFuc2FyaS1zY2ltLXNvZnQtZGVsZXRlLzwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+SSB3b3VsZCBsaWtlIGEgc2xvdCBvbiB0aGUgYWdlbmRhIHRvIGRpc2N1c3MgdGhpcyBk cmFmdCBhbmQgZ2V0IGZlZWRiYWNrIGZyb20gdGhlIFdHLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPk1vcnRlemE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNj aW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB123450F6B82BC92412CC66E7A6180BN3PR0301MB1234_-- From nobody Thu Mar 12 12:26:58 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCD91A0107 for ; Thu, 12 Mar 2015 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 LEllypu_a6Lj for ; Thu, 12 Mar 2015 12:26:54 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E531A013B for ; Thu, 12 Mar 2015 12:26:54 -0700 (PDT) Received: by labgq15 with SMTP id gq15so18128595lab.4 for ; Thu, 12 Mar 2015 12:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=m2HaMLBN/kd55jSK+UYAS29gqueBM64tEx184RgzHiw=; b=NK+4V9H7XxOJC4aNGMjVGv7pl2m/U4Y3BewX53agGjwA3VJEm72N4oS5p4I2v77ufZ hbH2f2I/5hRygYsi/xq4aq0RIUawyUhzag46o0sgBYsqY5k1h/bDFBq4G6xf5SjI1fwJ GwH9QBgfmB+cIEiR0yxYXelBJ4fINPYpvLvqEVXLAhfu+wIQZ3p9w4ecdGbePMMBKVYD Otd/5QpgqXDTMlqsZp+UYBL1FCXIad+znVYRWsOgABxR75iG+FdzpRIY7Ykp4yDbUzUH 1xZ/BPDEphnuE0+AXrIr3IJNZbTjig6xzfLTopX6eBsR7m6Q3hp6T7b17J8xJSAz1rqx YUfQ== MIME-Version: 1.0 X-Received: by 10.152.1.194 with SMTP id 2mr16241244lao.38.1426188412639; Thu, 12 Mar 2015 12:26:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.183.34 with HTTP; Thu, 12 Mar 2015 12:26:52 -0700 (PDT) Date: Thu, 12 Mar 2015 15:26:52 -0400 X-Google-Sender-Auth: y3JkJ1YTxYX8tQQfJY_-4WxdJUI Message-ID: From: Barry Leiba To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 19:26:56 -0000 I like this document, and I think it's about ready to go. I just have two issues I'd like to discuss with the editors and working group: 1. I think the security considerations section is too brief, and would be better fleshed out a bit. There are going to be details that'll be left to the schema and api documents -- details that have to do with the schema and api, of course. But this document could and should talk about the general security considerations for what SCIM is doing. What are the general threats and privacy issues, and how do you expect them to be dealt with? Let the security considerations in this document form the basis on which the other documents with expand when the protocol details are in place. 2. The IESG has been strongly questioning the value of publishing use-case documents as RFCs. The question is whether they really have archival value, or whether no one will read them in six months or so, when the protocols they informed have been published. Often, it would be better to publish collections of use cases and related discussion in the working group's wiki, rather than going for RFC publication. I very much support that questioning. But... This document is more than a use-cases document, and it sells itself short by burying that, by making the reader figure that out. It's really definitions and overview, flows, use cases, and requirements. As such, I think it *does* have value as an RFC. Let's not make the rest of the IESG wonder about that, and perhaps take a different view. I suggest you retitle the document something like this: OLD SCIM Use Cases NEW System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows END (That also expands SCIM, which the RFC Editor will insist on, so you might as well do it now.) Then for the abstract: OLD This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). NEW This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's modes and flows, and includes user scenarios, use cases, and requirements. END And then tweak the Introduction accordingly. Do those points sound reasonable? (I will put the document into "AD Evaluation: Revised I-D Needed" state.) Barry From nobody Thu Mar 12 20:12:21 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DE61A89A3 for ; Thu, 12 Mar 2015 20:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 GrVywDkpJVBB for ; Thu, 12 Mar 2015 20:12:19 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8887D1AC3BE for ; Thu, 12 Mar 2015 20:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426216337; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Fq3cVKwdcJYDPJUMhLeUOQU9oeghjz+GX6g+uhcpEds=; b=LWN1jyNv3frMYqQoqu7PgYc3F3dqq/AgaG6n3cqpkz8Mhmbuu8/IrF4gvh7nGdoYGP9CGj/HMz6en3G7gT3xBlcc1K4lh6U6ymnkk+fqMyYtXz+odhnFIV6513GHZxldrPn5RKY7iYUTI6XuQDFWz95v/HcOBhkY3R/tDcLCeZI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05022; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.148.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.187) by smtp.aliyun-inc.com(127.0.0.1); Fri, 13 Mar 2015 11:12:08 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 13 Mar 2015 11:12:02 +0800 From: "Kepeng Li" To: Barry Leiba , "scim@ietf.org" Message-ID: Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 03:12:20 -0000 Hi Barry, Thanks for the review and evaluation. >But this document could and should talk about the general security >considerations for what SCIM is doing. OK, will add that. >Do those points sound reasonable? Sounds reasonable to me. Kind Regards Kepeng =D4=DA 13/3/15 3:26 am=A3=AC "Barry Leiba" =D0=B4=C8=EB: >I like this document, and I think it's about ready to go. I just have >two issues I'd like to discuss with the editors and working group: > >1. I think the security considerations section is too brief, and would >be better fleshed out a bit. There are going to be details that'll be >left to the schema and api documents -- details that have to do with >the schema and api, of course. But this document could and should >talk about the general security considerations for what SCIM is doing. >What are the general threats and privacy issues, and how do you expect >them to be dealt with? Let the security considerations in this >document form the basis on which the other documents with expand when >the protocol details are in place. > >2. The IESG has been strongly questioning the value of publishing >use-case documents as RFCs. The question is whether they really have >archival value, or whether no one will read them in six months or so, >when the protocols they informed have been published. Often, it would >be better to publish collections of use cases and related discussion >in the working group's wiki, rather than going for RFC publication. I >very much support that questioning. But... > >This document is more than a use-cases document, and it sells itself >short by burying that, by making the reader figure that out. It's >really definitions and overview, flows, use cases, and requirements. >As such, I think it *does* have value as an RFC. Let's not make the >rest of the IESG wonder about that, and perhaps take a different view. >I suggest you retitle the document something like this: > >OLD >SCIM Use Cases > >NEW >System for Cross-domain Identity Management (SCIM) Definitions, >Overview, and Flows > >END > >(That also expands SCIM, which the RFC Editor will insist on, so you >might as well do it now.) > >Then for the abstract: > >OLD > This document lists the user scenarios and use cases of System for > Cross-domain Identity Management (SCIM). > >NEW > This document provides definitions and an overview of the System > for Cross-domain Identity Management (SCIM). It lays out the > system's modes and flows, and includes user scenarios, use cases, > and requirements. > >END > >And then tweak the Introduction accordingly. > >Do those points sound reasonable? >(I will put the document into "AD Evaluation: Revised I-D Needed" state.) > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Fri Mar 13 09:36:40 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F471A1EEC for ; Fri, 13 Mar 2015 09:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sFDjR-6sinKO for ; Fri, 13 Mar 2015 09:36:37 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941231A010F for ; Fri, 13 Mar 2015 09:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3623; q=dns/txt; s=iport; t=1426264597; x=1427474197; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=edjvYBTjytKKxemVfBCODxvXfaF/i1h/syt25eCiUc0=; b=HUYpDKQs1oztwhbEBLB1VdrrqzJ8H344rmDJ2MRzzZD4BxYlmrIw513U +fyuARfCxLV/4QzP9fBxczULwVN4kx7mDqST9Ss/UaiY+kVVZxpuHIKID p9k+4BMex+LQ+xvQv3NezKxMyGIMLWi1MKzV/WvN4QHuD+ICsyPiaZz8T 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtBgDFEQNV/40NJK1RCYMGUloEwTKCLQqFcAKBLkwBAQEBAQF9hBABAQQBAQFrGwIBCEYnCyUCBAESiC8NzkgBAQEBAQEBAQEBAQEBAQEBAQEBFQSLF4QWYoQtBYpGg1iCBolhgRqFfIxnI4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,395,1422921600"; d="scan'208";a="400323506" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 13 Mar 2015 16:36:17 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2DGaHpG026008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 16:36:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 13 Mar 2015 11:36:17 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Thread-Index: AQHQXPqF14ndZd68F0WH+7QX3QdDep0afCmA Date: Fri, 13 Mar 2015 16:36:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.232.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5CB5DBF968D4724F91B2DB4F6F457A24@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 16:36:39 -0000 Thanks for the review Barry. My comment as WG members and definitely not as Chair: Do we really need to publish the use cases as an RFC, even if we modify it to =B3definitions, overview, and flows=B2 as Barry suggested? I think the biggest value of the use cases doc was to the WG during development of the core spec, and now that the core spec are pretty much final or close to final its value for the most part is superseded by the core spec. I certainly think it still has historical value helping someone new to SCIM understand why some decisions were made. It also could help with the overall overview of SCIM. However, I think there might be other potentially more suitable mechanisms for capture that as opposed to turning this into an Informational RFC. For example we could publish it on =B3simplecloud.info=B2 site along with other implementation/testing/guide articles & presentations. Thoughts? Cheers, Morteza=20 On 3/12/15, 12:26 PM, "Barry Leiba" wrote: >I like this document, and I think it's about ready to go. I just have >two issues I'd like to discuss with the editors and working group: > >1. I think the security considerations section is too brief, and would >be better fleshed out a bit. There are going to be details that'll be >left to the schema and api documents -- details that have to do with >the schema and api, of course. But this document could and should >talk about the general security considerations for what SCIM is doing. >What are the general threats and privacy issues, and how do you expect >them to be dealt with? Let the security considerations in this >document form the basis on which the other documents with expand when >the protocol details are in place. > >2. The IESG has been strongly questioning the value of publishing >use-case documents as RFCs. The question is whether they really have >archival value, or whether no one will read them in six months or so, >when the protocols they informed have been published. Often, it would >be better to publish collections of use cases and related discussion >in the working group's wiki, rather than going for RFC publication. I >very much support that questioning. But... > >This document is more than a use-cases document, and it sells itself >short by burying that, by making the reader figure that out. It's >really definitions and overview, flows, use cases, and requirements. >As such, I think it *does* have value as an RFC. Let's not make the >rest of the IESG wonder about that, and perhaps take a different view. >I suggest you retitle the document something like this: > >OLD >SCIM Use Cases > >NEW >System for Cross-domain Identity Management (SCIM) Definitions, >Overview, and Flows > >END > >(That also expands SCIM, which the RFC Editor will insist on, so you >might as well do it now.) > >Then for the abstract: > >OLD > This document lists the user scenarios and use cases of System for > Cross-domain Identity Management (SCIM). > >NEW > This document provides definitions and an overview of the System > for Cross-domain Identity Management (SCIM). It lays out the > system's modes and flows, and includes user scenarios, use cases, > and requirements. > >END > >And then tweak the Introduction accordingly. > >Do those points sound reasonable? >(I will put the document into "AD Evaluation: Revised I-D Needed" state.) > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Fri Mar 13 09:58:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98B1A88D7 for ; Fri, 13 Mar 2015 09:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Xe1YxKfTtcJz for ; Fri, 13 Mar 2015 09:58:48 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62DC1A8715 for ; Fri, 13 Mar 2015 09:58:48 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so115447927iec.2 for ; Fri, 13 Mar 2015 09:58:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JJPQibWPqnpT4RGHqqEcQ5w6JaycwE6bYBE22eHrs/M=; b=hcI8eijXBJxivD7Zj62/S706kpDa9oM7PmK5rA4DOHT/3WeSGnrEJsRsPqidtuOh5c 5JLIZ9X0uFuFxiGu82ecsH29m/jW0Vnkm9C8kZG+WtdbVcK8tLgyyImIXLMyBZLZfjA2 9dqLrLRatxam502uHzfkIgMjLK3i5bvr0MdRwgwMGnG55xrlYkVcxxnws7D9PZaiQopG loNTVb6GZGLfvbW9mYlwRIcWUtzGF8vHtfSLDz3rd4IFIs0ghHMcvWeEvJpMchElQSWk ZYBABTrL2x75mecVcr8JM2XXi6H1rQ2Lx0GxhsinCtGi89Hl2g6W5blPaa5z6SQb5tjz iAQA== X-Gm-Message-State: ALoCoQndnfn0+7b4BBygcUOVIs3ekn7yH60CRN1dWaue3XD/AAFBxCnCOJjcPKXls9l3xVzLASwx X-Received: by 10.107.134.9 with SMTP id i9mr51531786iod.90.1426265910752; Fri, 13 Mar 2015 09:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.127.22 with HTTP; Fri, 13 Mar 2015 09:58:10 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Fri, 13 Mar 2015 12:58:10 -0400 Message-ID: To: "Morteza Ansari (moransar)" Content-Type: multipart/alternative; boundary=001a113ecae0f7482705112e68f0 Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 16:58:51 -0000 --001a113ecae0f7482705112e68f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't have a strong opinion one way or another but lean slightly towards publishing it on scimplecloud.info On Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (moransar) < moransar@cisco.com> wrote: > Thanks for the review Barry. > > My comment as WG members and definitely not as Chair: > > Do we really need to publish the use cases as an RFC, even if we modify i= t > to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I thi= nk the > biggest value of the use cases doc was to the WG during development of th= e > core spec, and now that the core spec are pretty much final or close to > final its value for the most part is superseded by the core spec. > > I certainly think it still has historical value helping someone new to > SCIM understand why some decisions were made. It also could help with the > overall overview of SCIM. However, I think there might be other > potentially more suitable mechanisms for capture that as opposed to > turning this into an Informational RFC. For example we could publish it o= n > =C2=B3simplecloud.info=C2=B2 site along with other implementation/testing= /guide > articles & presentations. > > Thoughts? > > > Cheers, > Morteza > > On 3/12/15, 12:26 PM, "Barry Leiba" wrote: > > >I like this document, and I think it's about ready to go. I just have > >two issues I'd like to discuss with the editors and working group: > > > >1. I think the security considerations section is too brief, and would > >be better fleshed out a bit. There are going to be details that'll be > >left to the schema and api documents -- details that have to do with > >the schema and api, of course. But this document could and should > >talk about the general security considerations for what SCIM is doing. > >What are the general threats and privacy issues, and how do you expect > >them to be dealt with? Let the security considerations in this > >document form the basis on which the other documents with expand when > >the protocol details are in place. > > > >2. The IESG has been strongly questioning the value of publishing > >use-case documents as RFCs. The question is whether they really have > >archival value, or whether no one will read them in six months or so, > >when the protocols they informed have been published. Often, it would > >be better to publish collections of use cases and related discussion > >in the working group's wiki, rather than going for RFC publication. I > >very much support that questioning. But... > > > >This document is more than a use-cases document, and it sells itself > >short by burying that, by making the reader figure that out. It's > >really definitions and overview, flows, use cases, and requirements. > >As such, I think it *does* have value as an RFC. Let's not make the > >rest of the IESG wonder about that, and perhaps take a different view. > >I suggest you retitle the document something like this: > > > >OLD > >SCIM Use Cases > > > >NEW > >System for Cross-domain Identity Management (SCIM) Definitions, > >Overview, and Flows > > > >END > > > >(That also expands SCIM, which the RFC Editor will insist on, so you > >might as well do it now.) > > > >Then for the abstract: > > > >OLD > > This document lists the user scenarios and use cases of System for > > Cross-domain Identity Management (SCIM). > > > >NEW > > This document provides definitions and an overview of the System > > for Cross-domain Identity Management (SCIM). It lays out the > > system's modes and flows, and includes user scenarios, use cases, > > and requirements. > > > >END > > > >And then tweak the Introduction accordingly. > > > >Do those points sound reasonable? > >(I will put the document into "AD Evaluation: Revised I-D Needed" state.= ) > > > >Barry > > > >_______________________________________________ > >scim mailing list > >scim@ietf.org > >https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --001a113ecae0f7482705112e68f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't have a strong opinion one way or another but l= ean slightly towards publishing it on = scimplecloud.info

On Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (moransar) <mo= ransar@cisco.com> wrote:
Th= anks for the review Barry.

My comment as WG members and definitely not as Chair:

Do we really need to publish the use cases as an RFC, even if we modify it<= br> to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I think= the
biggest value of the use cases doc was to the WG during development of the<= br> core spec, and now that the core spec are pretty much final or close to
final its value for the most part is superseded by the core spec.

I certainly think it still has historical value helping someone new to
SCIM understand why some decisions were made. It also could help with the overall overview of SCIM. However, I think there might be other
potentially more suitable mechanisms for capture that as opposed to
turning this into an Informational RFC. For example we could publish it on<= br> =C2=B3simplecloud.inf= o=C2=B2 site along with other implementation/testing/guide
articles & presentations.

Thoughts?


Cheers,
Morteza

On 3/12/15, 12:26 PM, "Barry Leiba" <barryleiba@computer.org> wrote:

>I like this document, and I think it's about ready to go.=C2=A0 I j= ust have
>two issues I'd like to discuss with the editors and working group:<= br> >
>1. I think the security considerations section is too brief, and would<= br> >be better fleshed out a bit.=C2=A0 There are going to be details that&#= 39;ll be
>left to the schema and api documents -- details that have to do with >the schema and api, of course.=C2=A0 But this document could and should=
>talk about the general security considerations for what SCIM is doing.<= br> >What are the general threats and privacy issues, and how do you expect<= br> >them to be dealt with?=C2=A0 Let the security considerations in this >document form the basis on which the other documents with expand when >the protocol details are in place.
>
>2. The IESG has been strongly questioning the value of publishing
>use-case documents as RFCs.=C2=A0 The question is whether they really h= ave
>archival value, or whether no one will read them in six months or so, >when the protocols they informed have been published.=C2=A0 Often, it w= ould
>be better to publish collections of use cases and related discussion >in the working group's wiki, rather than going for RFC publication.= =C2=A0 I
>very much support that questioning.=C2=A0 But...
>
>This document is more than a use-cases document, and it sells itself >short by burying that, by making the reader figure that out.=C2=A0 It&#= 39;s
>really definitions and overview, flows, use cases, and requirements. >As such, I think it *does* have value as an RFC.=C2=A0 Let's not ma= ke the
>rest of the IESG wonder about that, and perhaps take a different view.<= br> >I suggest you retitle the document something like this:
>
>OLD
>SCIM Use Cases
>
>NEW
>System for Cross-domain Identity Management (SCIM) Definitions,
>Overview, and Flows
>
>END
>
>(That also expands SCIM, which the RFC Editor will insist on, so you >might as well do it now.)
>
>Then for the abstract:
>
>OLD
>=C2=A0 =C2=A0This document lists the user scenarios and use cases of Sy= stem for
>=C2=A0 =C2=A0Cross-domain Identity Management (SCIM).
>
>NEW
>=C2=A0 =C2=A0This document provides definitions and an overview of the = System
>=C2=A0 =C2=A0for Cross-domain Identity Management (SCIM).=C2=A0 It lays= out the
>=C2=A0 =C2=A0system's modes and flows, and includes user scenarios,= use cases,
>=C2=A0 =C2=A0and requirements.
>
>END
>
>And then tweak the Introduction accordingly.
>
>Do those points sound reasonable?
>(I will put the document into "AD Evaluation: Revised I-D Needed&q= uot; state.)
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>https://www.ietf.org/mailman/listinfo/scim

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



--
=
Ian Glazer
Senior Director, Identity
+1 202 255 3166
--001a113ecae0f7482705112e68f0-- From nobody Fri Mar 13 10:42:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1617D1A0024 for ; Fri, 13 Mar 2015 10:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7lgkTNQ4mc9q for ; Fri, 13 Mar 2015 10:42:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB541A8931 for ; Fri, 13 Mar 2015 10:42:20 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2DHgI0w019325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Mar 2015 17:42:19 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2DHgH7X027006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Mar 2015 17:42:18 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2DHgHOv028376; Fri, 13 Mar 2015 17:42:17 GMT Received: from [192.168.1.27] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Mar 2015 10:42:17 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-4F4F40B0-8568-49C1-AC68-420F34AA7174 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Fri, 13 Mar 2015 10:42:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <30CBC74A-73E9-413A-96AA-EE5E38720505@oracle.com> References: To: Ian Glazer X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: Cc: "scim@ietf.org" , Barry Leiba , "Morteza Ansari \(moransar\)" Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:42:31 -0000 --Apple-Mail-4F4F40B0-8568-49C1-AC68-420F34AA7174 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. It has informed the development of the WG drafts but I am not sure it i= s needed as RFC. Phil > On Mar 13, 2015, at 09:58, Ian Glazer wrote: >=20 > I don't have a strong opinion one way or another but lean slightly towards= publishing it on scimplecloud.info >=20 >> On Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (moransar) wrote: >> Thanks for the review Barry. >>=20 >> My comment as WG members and definitely not as Chair: >>=20 >> Do we really need to publish the use cases as an RFC, even if we modify i= t >> to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I thi= nk the >> biggest value of the use cases doc was to the WG during development of th= e >> core spec, and now that the core spec are pretty much final or close to >> final its value for the most part is superseded by the core spec. >>=20 >> I certainly think it still has historical value helping someone new to >> SCIM understand why some decisions were made. It also could help with the= >> overall overview of SCIM. However, I think there might be other >> potentially more suitable mechanisms for capture that as opposed to >> turning this into an Informational RFC. For example we could publish it o= n >> =C2=B3simplecloud.info=C2=B2 site along with other implementation/testing= /guide >> articles & presentations. >>=20 >> Thoughts? >>=20 >>=20 >> Cheers, >> Morteza >>=20 >> On 3/12/15, 12:26 PM, "Barry Leiba" wrote: >>=20 >> >I like this document, and I think it's about ready to go. I just have >> >two issues I'd like to discuss with the editors and working group: >> > >> >1. I think the security considerations section is too brief, and would >> >be better fleshed out a bit. There are going to be details that'll be >> >left to the schema and api documents -- details that have to do with >> >the schema and api, of course. But this document could and should >> >talk about the general security considerations for what SCIM is doing. >> >What are the general threats and privacy issues, and how do you expect >> >them to be dealt with? Let the security considerations in this >> >document form the basis on which the other documents with expand when >> >the protocol details are in place. >> > >> >2. The IESG has been strongly questioning the value of publishing >> >use-case documents as RFCs. The question is whether they really have >> >archival value, or whether no one will read them in six months or so, >> >when the protocols they informed have been published. Often, it would >> >be better to publish collections of use cases and related discussion >> >in the working group's wiki, rather than going for RFC publication. I >> >very much support that questioning. But... >> > >> >This document is more than a use-cases document, and it sells itself >> >short by burying that, by making the reader figure that out. It's >> >really definitions and overview, flows, use cases, and requirements. >> >As such, I think it *does* have value as an RFC. Let's not make the >> >rest of the IESG wonder about that, and perhaps take a different view. >> >I suggest you retitle the document something like this: >> > >> >OLD >> >SCIM Use Cases >> > >> >NEW >> >System for Cross-domain Identity Management (SCIM) Definitions, >> >Overview, and Flows >> > >> >END >> > >> >(That also expands SCIM, which the RFC Editor will insist on, so you >> >might as well do it now.) >> > >> >Then for the abstract: >> > >> >OLD >> > This document lists the user scenarios and use cases of System for >> > Cross-domain Identity Management (SCIM). >> > >> >NEW >> > This document provides definitions and an overview of the System >> > for Cross-domain Identity Management (SCIM). It lays out the >> > system's modes and flows, and includes user scenarios, use cases, >> > and requirements. >> > >> >END >> > >> >And then tweak the Introduction accordingly. >> > >> >Do those points sound reasonable? >> >(I will put the document into "AD Evaluation: Revised I-D Needed" state.= ) >> > >> >Barry >> > >> >_______________________________________________ >> >scim mailing list >> >scim@ietf.org >> >https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 > --=20 > Ian Glazer > Senior Director, Identity > +1 202 255 3166 > @iglazer > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-4F4F40B0-8568-49C1-AC68-420F34AA7174 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1.  It has informed the developm= ent of the WG drafts but I am not sure it is needed as RFC.

Phil

On Mar 13, 2015, at 09:58, Ian Glazer <iglazer@salesforce.com> wrote:

I don't have a strong opinion one w= ay or another but lean slightly towards publishing it on scimplecloud.info

=
On Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (= moransar) <moransar@cisco.com> wrote:
Thanks for the review Barry.

My comment as WG members and definitely not as Chair:

Do we really need to publish the use cases as an RFC, even if we modify it to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I think t= he
biggest value of the use cases doc was to the WG during development of the core spec, and now that the core spec are pretty much final or close to
final its value for the most part is superseded by the core spec.

I certainly think it still has historical value helping someone new to
SCIM understand why some decisions were made. It also could help with the overall overview of SCIM. However, I think there might be other
potentially more suitable mechanisms for capture that as opposed to
turning this into an Informational RFC. For example we could publish it on =C2=B3simplecloud.info= =C2=B2 site along with other implementation/testing/guide
articles & presentations.

Thoughts?


Cheers,
Morteza

On 3/12/15, 12:26 PM, "Barry Leiba" <barryleiba@computer.org> wrote:

>I like this document, and I think it's about ready to go.  I just h= ave
>two issues I'd like to discuss with the editors and working group:
>
>1. I think the security considerations section is too brief, and would >be better fleshed out a bit.  There are going to be details that'll= be
>left to the schema and api documents -- details that have to do with
= >the schema and api, of course.  But this document could and should<= br> >talk about the general security considerations for what SCIM is doing. >What are the general threats and privacy issues, and how do you expect >them to be dealt with?  Let the security considerations in this
= >document form the basis on which the other documents with expand when >the protocol details are in place.
>
>2. The IESG has been strongly questioning the value of publishing
>use-case documents as RFCs.  The question is whether they really ha= ve
>archival value, or whether no one will read them in six months or so, >when the protocols they informed have been published.  Often, it wo= uld
>be better to publish collections of use cases and related discussion
= >in the working group's wiki, rather than going for RFC publication. = ; I
>very much support that questioning.  But...
>
>This document is more than a use-cases document, and it sells itself
= >short by burying that, by making the reader figure that out.  It's<= br> >really definitions and overview, flows, use cases, and requirements.
= >As such, I think it *does* have value as an RFC.  Let's not make th= e
>rest of the IESG wonder about that, and perhaps take a different view. >I suggest you retitle the document something like this:
>
>OLD
>SCIM Use Cases
>
>NEW
>System for Cross-domain Identity Management (SCIM) Definitions,
>Overview, and Flows
>
>END
>
>(That also expands SCIM, which the RFC Editor will insist on, so you
= >might as well do it now.)
>
>Then for the abstract:
>
>OLD
>   This document lists the user scenarios and use cases of Sys= tem for
>   Cross-domain Identity Management (SCIM).
>
>NEW
>   This document provides definitions and an overview of the S= ystem
>   for Cross-domain Identity Management (SCIM).  It lays o= ut the
>   system's modes and flows, and includes user scenarios, use c= ases,
>   and requirements.
>
>END
>
>And then tweak the Introduction accordingly.
>
>Do those points sound reasonable?
>(I will put the document into "AD Evaluation: Revised I-D Needed" state.= )
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>https://www.ietf.org/mailman/listinfo/scim

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



--
<= div class=3D"gmail_signature">
Ian Glazer
Senior Director, Identity
+1 202 255 3166
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-4F4F40B0-8568-49C1-AC68-420F34AA7174-- From nobody Fri Mar 13 14:29:20 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79931A879E for ; Fri, 13 Mar 2015 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vXGJhz6N4quN for ; Fri, 13 Mar 2015 14:29:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBCF1A0092 for ; Fri, 13 Mar 2015 14:29:17 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2DLTF04020774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Mar 2015 21:29:16 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2DLTF3J006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Mar 2015 21:29:15 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t2DLTEX8001295 for ; Fri, 13 Mar 2015 21:29:14 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Mar 2015 14:29:14 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_FBCDDE48-FE38-48AB-9791-7EBA3AEE9D04" Message-Id: <4DA8CB7A-7B01-4D8D-9548-4B316DA68B37@oracle.com> Date: Fri, 13 Mar 2015 14:29:13 -0700 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: [scim] SCIM Specification Repository Files - Updates X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:29:18 -0000 --Apple-Mail=_FBCDDE48-FE38-48AB-9791-7EBA3AEE9D04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As Google is shutting down the code.google.com site soon, I thought I = better update all the information I have prior to migration. I=E2=80=99ve put copies of the information for SCIM API and Core-Schema = that are also tracked in IETF to the site. More importantly, I=E2=80=99ve added =E2=80=9CscimFixedSchema.json=E2=80=9D= and =E2=80=9CscimResourceSchema.json=E2=80=9D which are valid JSON = versions of the JSON published in SCIM Core Schema-17, Section 8.7. = This will probably be helpful to developers looking to jump start their = SCIM schema configurations. You can browse the files here: https://code.google.com/p/scim/source/browse/#svn%2Ftrunk%2Fspecs%2Fietf Cheers, Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_FBCDDE48-FE38-48AB-9791-7EBA3AEE9D04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As Google is shutting down the code.google.com site = soon, I thought I better update all the information I have prior to = migration.

I=E2=80=99v= e put copies of the information for SCIM API and Core-Schema that are = also tracked in IETF to the site.

More importantly, I=E2=80=99ve added = =E2=80=9CscimFixedSchema.json=E2=80=9D and =E2=80=9CscimResourceSchema.jso= n=E2=80=9D which are valid JSON versions of the JSON published in SCIM = Core Schema-17, Section 8.7.  This will probably be helpful to = developers looking to jump start their SCIM schema = configurations.

You can browse the files here:
https://code.google.com/p/scim/source/browse/#svn%2Ftrunk%2Fspe= cs%2Fietf

Cheers,


= --Apple-Mail=_FBCDDE48-FE38-48AB-9791-7EBA3AEE9D04-- From nobody Sat Mar 14 10:04:00 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D41A026A for ; Sat, 14 Mar 2015 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 Pd2T4b6QFkCv for ; Sat, 14 Mar 2015 10:03:57 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 628561A000A for ; Sat, 14 Mar 2015 10:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426352635; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Khl7fyDktpWxKkc1T5JpV4803en6vw5aQb9PKmECQlI=; b=PuEHTt/EXfAg6IEIjqQEVxWsZK/LqlOy6hC+/RGZ7B2WAmd28QWdDItUQrhSPOAkMpkCUbEDzqLZALljqOBTfgZHymy6NWrSv0S9GBot/vnFoxhJf51UM4b2l2aNiqgfXalBEjx3/GR8CRedhAEkGigZip1zJi+PQelOLvkfV7A= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03022; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 192.168.3.5(mailfrom:kepeng.lkp@alibaba-inc.com ip:115.196.72.102) by smtp.aliyun-inc.com(127.0.0.1); Sun, 15 Mar 2015 01:03:49 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 15 Mar 2015 01:02:55 +0800 From: "Kepeng Li" To: "Morteza Ansari (moransar)" , Barry Leiba , "scim@ietf.org" Message-ID: Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:03:58 -0000 I believe this document has value and worth publishing as RFC. It contains more than use cases, and also definitions, overview, scenarios, flows, and requirements. It can help the readers to understand the background, scenarios and use cases, and make better use of the API/core specs. Putting it somewhere else will decrease the value of the document. Thanks, Kind Regards Kepeng =E5=9C=A8 14/3/15 12:36 am=EF=BC=8C "Morteza Ansari (moransar)" =E5=86= =99=E5=85=A5: >Thanks for the review Barry. > >My comment as WG members and definitely not as Chair: > >Do we really need to publish the use cases as an RFC, even if we modify it >to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I think the >biggest value of the use cases doc was to the WG during development of the >core spec, and now that the core spec are pretty much final or close to >final its value for the most part is superseded by the core spec. > >I certainly think it still has historical value helping someone new to >SCIM understand why some decisions were made. It also could help with the >overall overview of SCIM. However, I think there might be other >potentially more suitable mechanisms for capture that as opposed to >turning this into an Informational RFC. For example we could publish it on >=C2=B3simplecloud.info=C2=B2 site along with other implementation/testing/guide >articles & presentations. > >Thoughts? > > >Cheers, >Morteza=20 > >On 3/12/15, 12:26 PM, "Barry Leiba" wrote: > >>I like this document, and I think it's about ready to go. I just have >>two issues I'd like to discuss with the editors and working group: >> >>1. I think the security considerations section is too brief, and would >>be better fleshed out a bit. There are going to be details that'll be >>left to the schema and api documents -- details that have to do with >>the schema and api, of course. But this document could and should >>talk about the general security considerations for what SCIM is doing. >>What are the general threats and privacy issues, and how do you expect >>them to be dealt with? Let the security considerations in this >>document form the basis on which the other documents with expand when >>the protocol details are in place. >> >>2. The IESG has been strongly questioning the value of publishing >>use-case documents as RFCs. The question is whether they really have >>archival value, or whether no one will read them in six months or so, >>when the protocols they informed have been published. Often, it would >>be better to publish collections of use cases and related discussion >>in the working group's wiki, rather than going for RFC publication. I >>very much support that questioning. But... >> >>This document is more than a use-cases document, and it sells itself >>short by burying that, by making the reader figure that out. It's >>really definitions and overview, flows, use cases, and requirements. >>As such, I think it *does* have value as an RFC. Let's not make the >>rest of the IESG wonder about that, and perhaps take a different view. >>I suggest you retitle the document something like this: >> >>OLD >>SCIM Use Cases >> >>NEW >>System for Cross-domain Identity Management (SCIM) Definitions, >>Overview, and Flows >> >>END >> >>(That also expands SCIM, which the RFC Editor will insist on, so you >>might as well do it now.) >> >>Then for the abstract: >> >>OLD >> This document lists the user scenarios and use cases of System for >> Cross-domain Identity Management (SCIM). >> >>NEW >> This document provides definitions and an overview of the System >> for Cross-domain Identity Management (SCIM). It lays out the >> system's modes and flows, and includes user scenarios, use cases, >> and requirements. >> >>END >> >>And then tweak the Introduction accordingly. >> >>Do those points sound reasonable? >>(I will put the document into "AD Evaluation: Revised I-D Needed" state.) >> >>Barry >> >>_______________________________________________ >>scim mailing list >>scim@ietf.org >>https://www.ietf.org/mailman/listinfo/scim > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Sat Mar 14 17:55:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADD91A0469 for ; Sat, 14 Mar 2015 17:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EJ0h3aM95phG for ; Sat, 14 Mar 2015 17:55:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FACF1A0461 for ; Sat, 14 Mar 2015 17:55:24 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.106.15; Sun, 15 Mar 2015 00:55:07 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0112.000; Sun, 15 Mar 2015 00:55:06 +0000 From: Anthony Nadalin To: Phil Hunt , Ian Glazer Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Thread-Index: AQHQXPqGDdxcZHo6MkKPejnqkSn72Z0anbEAgAAGHwCAAAxRgIACCphg Date: Sun, 15 Mar 2015 00:55:06 +0000 Message-ID: References: <30CBC74A-73E9-413A-96AA-EE5E38720505@oracle.com> In-Reply-To: <30CBC74A-73E9-413A-96AA-EE5E38720505@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.168.40.226] authentication-results: oracle.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(209900001)(479174004)(51914003)(24454002)(377454003)(51704005)(33656002)(19625215002)(86612001)(16236675004)(86362001)(40100003)(122556002)(230783001)(66066001)(74316001)(76576001)(19617315012)(50986999)(46102003)(54356999)(76176999)(16601075003)(92566002)(2900100001)(77156002)(62966003)(19609705001)(19580405001)(19580395003)(19300405004)(93886004)(99286002)(2950100001)(2656002)(15975445007)(87936001)(106116001)(102836002)(42262002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 05168A3970 Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234763E9A9EFFEDA8CC686EA6050BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2015 00:55:06.7150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: "scim@ietf.org" , Barry Leiba , "Morteza Ansari \(moransar\)" Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 00:55:28 -0000 --_000_BN3PR0301MB1234763E9A9EFFEDA8CC686EA6050BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG1tbSwgdGhlIGlzc3VlIGlzIHRoYXQgdGhlc2UgbmVlZCB0byBzdGljayBhcm91bmQgYW5kIGJl IHRpZWQgdG8gdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGFuZCBmdXR1cmUgc3BlY2lmaWNh dGlvbnMgc28gZm9sa3MgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbXMgYmVpbmcgc29sdmVkLCBzbyBJ IGRvbuKAmXQgc3VwcG9ydCBwdWJsaXNoaW5nIG9uIHNjaW1wbGVjbG91ZC5pbmZvDQoNCkZyb206 IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1 bnQNClNlbnQ6IEZyaWRheSwgTWFyY2ggMTMsIDIwMTUgMTA6NDIgQU0NClRvOiBJYW4gR2xhemVy DQpDYzogc2NpbUBpZXRmLm9yZzsgQmFycnkgTGVpYmE7IE1vcnRlemEgQW5zYXJpIChtb3JhbnNh cikNClN1YmplY3Q6IFJlOiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2NpbS11c2Ut Y2FzZXMtMDQNCg0KKzEuICBJdCBoYXMgaW5mb3JtZWQgdGhlIGRldmVsb3BtZW50IG9mIHRoZSBX RyBkcmFmdHMgYnV0IEkgYW0gbm90IHN1cmUgaXQgaXMgbmVlZGVkIGFzIFJGQy4NCg0KUGhpbA0K DQpPbiBNYXIgMTMsIDIwMTUsIGF0IDA5OjU4LCBJYW4gR2xhemVyIDxpZ2xhemVyQHNhbGVzZm9y Y2UuY29tPG1haWx0bzppZ2xhemVyQHNhbGVzZm9yY2UuY29tPj4gd3JvdGU6DQpJIGRvbid0IGhh dmUgYSBzdHJvbmcgb3BpbmlvbiBvbmUgd2F5IG9yIGFub3RoZXIgYnV0IGxlYW4gc2xpZ2h0bHkg dG93YXJkcyBwdWJsaXNoaW5nIGl0IG9uIHNjaW1wbGVjbG91ZC5pbmZvPGh0dHA6Ly9zY2ltcGxl Y2xvdWQuaW5mbz4NCg0KT24gRnJpLCBNYXIgMTMsIDIwMTUgYXQgMTI6MzYgUE0sIE1vcnRlemEg QW5zYXJpIChtb3JhbnNhcikgPG1vcmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lz Y28uY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHRoZSByZXZpZXcgQmFycnkuDQoNCk15IGNvbW1l bnQgYXMgV0cgbWVtYmVycyBhbmQgZGVmaW5pdGVseSBub3QgYXMgQ2hhaXI6DQoNCkRvIHdlIHJl YWxseSBuZWVkIHRvIHB1Ymxpc2ggdGhlIHVzZSBjYXNlcyBhcyBhbiBSRkMsIGV2ZW4gaWYgd2Ug bW9kaWZ5IGl0DQp0byDCs2RlZmluaXRpb25zLCBvdmVydmlldywgYW5kIGZsb3dzwrIgYXMgQmFy cnkgc3VnZ2VzdGVkPyBJIHRoaW5rIHRoZQ0KYmlnZ2VzdCB2YWx1ZSBvZiB0aGUgdXNlIGNhc2Vz IGRvYyB3YXMgdG8gdGhlIFdHIGR1cmluZyBkZXZlbG9wbWVudCBvZiB0aGUNCmNvcmUgc3BlYywg YW5kIG5vdyB0aGF0IHRoZSBjb3JlIHNwZWMgYXJlIHByZXR0eSBtdWNoIGZpbmFsIG9yIGNsb3Nl IHRvDQpmaW5hbCBpdHMgdmFsdWUgZm9yIHRoZSBtb3N0IHBhcnQgaXMgc3VwZXJzZWRlZCBieSB0 aGUgY29yZSBzcGVjLg0KDQpJIGNlcnRhaW5seSB0aGluayBpdCBzdGlsbCBoYXMgaGlzdG9yaWNh bCB2YWx1ZSBoZWxwaW5nIHNvbWVvbmUgbmV3IHRvDQpTQ0lNIHVuZGVyc3RhbmQgd2h5IHNvbWUg ZGVjaXNpb25zIHdlcmUgbWFkZS4gSXQgYWxzbyBjb3VsZCBoZWxwIHdpdGggdGhlDQpvdmVyYWxs IG92ZXJ2aWV3IG9mIFNDSU0uIEhvd2V2ZXIsIEkgdGhpbmsgdGhlcmUgbWlnaHQgYmUgb3RoZXIN CnBvdGVudGlhbGx5IG1vcmUgc3VpdGFibGUgbWVjaGFuaXNtcyBmb3IgY2FwdHVyZSB0aGF0IGFz IG9wcG9zZWQgdG8NCnR1cm5pbmcgdGhpcyBpbnRvIGFuIEluZm9ybWF0aW9uYWwgUkZDLiBGb3Ig ZXhhbXBsZSB3ZSBjb3VsZCBwdWJsaXNoIGl0IG9uDQrCs3NpbXBsZWNsb3VkLmluZm88aHR0cDov L3NpbXBsZWNsb3VkLmluZm8+wrIgc2l0ZSBhbG9uZyB3aXRoIG90aGVyIGltcGxlbWVudGF0aW9u L3Rlc3RpbmcvZ3VpZGUNCmFydGljbGVzICYgcHJlc2VudGF0aW9ucy4NCg0KVGhvdWdodHM/DQoN Cg0KQ2hlZXJzLA0KTW9ydGV6YQ0KDQpPbiAzLzEyLzE1LCAxMjoyNiBQTSwgIkJhcnJ5IExlaWJh IiA8YmFycnlsZWliYUBjb21wdXRlci5vcmc8bWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3Jn Pj4gd3JvdGU6DQoNCj5JIGxpa2UgdGhpcyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgaXQncyBhYm91 dCByZWFkeSB0byBnby4gIEkganVzdCBoYXZlDQo+dHdvIGlzc3VlcyBJJ2QgbGlrZSB0byBkaXNj dXNzIHdpdGggdGhlIGVkaXRvcnMgYW5kIHdvcmtpbmcgZ3JvdXA6DQo+DQo+MS4gSSB0aGluayB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0b28gYnJpZWYsIGFuZCB3b3Vs ZA0KPmJlIGJldHRlciBmbGVzaGVkIG91dCBhIGJpdC4gIFRoZXJlIGFyZSBnb2luZyB0byBiZSBk ZXRhaWxzIHRoYXQnbGwgYmUNCj5sZWZ0IHRvIHRoZSBzY2hlbWEgYW5kIGFwaSBkb2N1bWVudHMg LS0gZGV0YWlscyB0aGF0IGhhdmUgdG8gZG8gd2l0aA0KPnRoZSBzY2hlbWEgYW5kIGFwaSwgb2Yg Y291cnNlLiAgQnV0IHRoaXMgZG9jdW1lbnQgY291bGQgYW5kIHNob3VsZA0KPnRhbGsgYWJvdXQg dGhlIGdlbmVyYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHdoYXQgU0NJTSBpcyBkb2lu Zy4NCj5XaGF0IGFyZSB0aGUgZ2VuZXJhbCB0aHJlYXRzIGFuZCBwcml2YWN5IGlzc3VlcywgYW5k IGhvdyBkbyB5b3UgZXhwZWN0DQo+dGhlbSB0byBiZSBkZWFsdCB3aXRoPyAgTGV0IHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGlzDQo+ZG9jdW1lbnQgZm9ybSB0aGUgYmFzaXMgb24g d2hpY2ggdGhlIG90aGVyIGRvY3VtZW50cyB3aXRoIGV4cGFuZCB3aGVuDQo+dGhlIHByb3RvY29s IGRldGFpbHMgYXJlIGluIHBsYWNlLg0KPg0KPjIuIFRoZSBJRVNHIGhhcyBiZWVuIHN0cm9uZ2x5 IHF1ZXN0aW9uaW5nIHRoZSB2YWx1ZSBvZiBwdWJsaXNoaW5nDQo+dXNlLWNhc2UgZG9jdW1lbnRz IGFzIFJGQ3MuICBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGV5IHJlYWxseSBoYXZlDQo+YXJj aGl2YWwgdmFsdWUsIG9yIHdoZXRoZXIgbm8gb25lIHdpbGwgcmVhZCB0aGVtIGluIHNpeCBtb250 aHMgb3Igc28sDQo+d2hlbiB0aGUgcHJvdG9jb2xzIHRoZXkgaW5mb3JtZWQgaGF2ZSBiZWVuIHB1 Ymxpc2hlZC4gIE9mdGVuLCBpdCB3b3VsZA0KPmJlIGJldHRlciB0byBwdWJsaXNoIGNvbGxlY3Rp b25zIG9mIHVzZSBjYXNlcyBhbmQgcmVsYXRlZCBkaXNjdXNzaW9uDQo+aW4gdGhlIHdvcmtpbmcg Z3JvdXAncyB3aWtpLCByYXRoZXIgdGhhbiBnb2luZyBmb3IgUkZDIHB1YmxpY2F0aW9uLiAgSQ0K PnZlcnkgbXVjaCBzdXBwb3J0IHRoYXQgcXVlc3Rpb25pbmcuICBCdXQuLi4NCj4NCj5UaGlzIGRv Y3VtZW50IGlzIG1vcmUgdGhhbiBhIHVzZS1jYXNlcyBkb2N1bWVudCwgYW5kIGl0IHNlbGxzIGl0 c2VsZg0KPnNob3J0IGJ5IGJ1cnlpbmcgdGhhdCwgYnkgbWFraW5nIHRoZSByZWFkZXIgZmlndXJl IHRoYXQgb3V0LiAgSXQncw0KPnJlYWxseSBkZWZpbml0aW9ucyBhbmQgb3ZlcnZpZXcsIGZsb3dz LCB1c2UgY2FzZXMsIGFuZCByZXF1aXJlbWVudHMuDQo+QXMgc3VjaCwgSSB0aGluayBpdCAqZG9l cyogaGF2ZSB2YWx1ZSBhcyBhbiBSRkMuICBMZXQncyBub3QgbWFrZSB0aGUNCj5yZXN0IG9mIHRo ZSBJRVNHIHdvbmRlciBhYm91dCB0aGF0LCBhbmQgcGVyaGFwcyB0YWtlIGEgZGlmZmVyZW50IHZp ZXcuDQo+SSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVudCBzb21ldGhpbmcgbGlrZSB0 aGlzOg0KPg0KPk9MRA0KPlNDSU0gVXNlIENhc2VzDQo+DQo+TkVXDQo+U3lzdGVtIGZvciBDcm9z cy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgRGVmaW5pdGlvbnMsDQo+T3ZlcnZp ZXcsIGFuZCBGbG93cw0KPg0KPkVORA0KPg0KPihUaGF0IGFsc28gZXhwYW5kcyBTQ0lNLCB3aGlj aCB0aGUgUkZDIEVkaXRvciB3aWxsIGluc2lzdCBvbiwgc28geW91DQo+bWlnaHQgYXMgd2VsbCBk byBpdCBub3cuKQ0KPg0KPlRoZW4gZm9yIHRoZSBhYnN0cmFjdDoNCj4NCj5PTEQNCj4gICBUaGlz IGRvY3VtZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzIG9mIFN5c3Rl bSBmb3INCj4gICBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkuDQo+DQo+ TkVXDQo+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBkZWZpbml0aW9ucyBhbmQgYW4gb3ZlcnZp ZXcgb2YgdGhlIFN5c3RlbQ0KPiAgIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVu dCAoU0NJTSkuICBJdCBsYXlzIG91dCB0aGUNCj4gICBzeXN0ZW0ncyBtb2RlcyBhbmQgZmxvd3Ms IGFuZCBpbmNsdWRlcyB1c2VyIHNjZW5hcmlvcywgdXNlIGNhc2VzLA0KPiAgIGFuZCByZXF1aXJl bWVudHMuDQo+DQo+RU5EDQo+DQo+QW5kIHRoZW4gdHdlYWsgdGhlIEludHJvZHVjdGlvbiBhY2Nv cmRpbmdseS4NCj4NCj5EbyB0aG9zZSBwb2ludHMgc291bmQgcmVhc29uYWJsZT8NCj4oSSB3aWxs IHB1dCB0aGUgZG9jdW1lbnQgaW50byAiQUQgRXZhbHVhdGlvbjogUmV2aXNlZCBJLUQgTmVlZGVk IiBzdGF0ZS4pDQo+DQo+QmFycnkNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnNjaW0gbWFpbGluZyBsaXN0DQo+c2NpbUBpZXRmLm9yZzxtYWls dG86c2NpbUBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NjaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg0KDQotLQ0KSWFu IEdsYXplcg0KU2VuaW9yIERpcmVjdG9yLCBJZGVudGl0eQ0KKzEgMjAyIDI1NSAzMTY2DQpAaWds YXplcjxodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5v cmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NjaW0NCg== --_000_BN3PR0301MB1234763E9A9EFFEDA8CC686EA6050BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SG1tbSwgdGhlIGlzc3VlIGlzIHRoYXQgdGhlc2UgbmVlZCB0byBzdGlj ayBhcm91bmQgYW5kIGJlIHRpZWQgdG8gdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGFuZCBm dXR1cmUgc3BlY2lmaWNhdGlvbnMgc28gZm9sa3MgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbXMgYmVp bmcNCiBzb2x2ZWQsIHNvIEkgZG9u4oCZdCBzdXBwb3J0IHB1Ymxpc2hpbmcgb24gc2NpbXBsZWNs b3VkLmluZm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNjaW0gW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIE1hcmNoIDEzLCAyMDE1IDEwOjQyIEFNPGJyPg0KPGI+VG86PC9iPiBJYW4gR2xhemVyPGJy Pg0KPGI+Q2M6PC9iPiBzY2ltQGlldGYub3JnOyBCYXJyeSBMZWliYTsgTW9ydGV6YSBBbnNhcmkg KG1vcmFuc2FyKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NjaW1dIEFEIHJldmlldyBvZiBk cmFmdC1pZXRmLXNjaW0tdXNlLWNhc2VzLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MS4gJm5ic3A7SXQgaGFzIGluZm9ybWVkIHRo ZSBkZXZlbG9wbWVudCBvZiB0aGUgV0cgZHJhZnRzIGJ1dCBJIGFtIG5vdCBzdXJlIGl0IGlzIG5l ZWRlZCBhcyBSRkMuPGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpPbiBNYXIgMTMsIDIwMTUsIGF0IDA5OjU4LCBJYW4gR2xhemVyICZsdDs8YSBocmVmPSJtYWls dG86aWdsYXplckBzYWxlc2ZvcmNlLmNvbSI+aWdsYXplckBzYWxlc2ZvcmNlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gb25lIHdheSBvciBhbm90 aGVyIGJ1dCBsZWFuIHNsaWdodGx5IHRvd2FyZHMgcHVibGlzaGluZyBpdCBvbg0KPGEgaHJlZj0i aHR0cDovL3NjaW1wbGVjbG91ZC5pbmZvIj5zY2ltcGxlY2xvdWQuaW5mbzwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEzLCAyMDE1 IGF0IDEyOjM2IFBNLCBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpICZsdDs8YSBocmVmPSJtYWls dG86bW9yYW5zYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9yYW5zYXJAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzIGZvciB0aGUgcmV2aWV3IEJhcnJ5Ljxicj4NCjxicj4NCk15IGNvbW1l bnQgYXMgV0cgbWVtYmVycyBhbmQgZGVmaW5pdGVseSBub3QgYXMgQ2hhaXI6PGJyPg0KPGJyPg0K RG8gd2UgcmVhbGx5IG5lZWQgdG8gcHVibGlzaCB0aGUgdXNlIGNhc2VzIGFzIGFuIFJGQywgZXZl biBpZiB3ZSBtb2RpZnkgaXQ8YnI+DQp0byDCs2RlZmluaXRpb25zLCBvdmVydmlldywgYW5kIGZs b3dzwrIgYXMgQmFycnkgc3VnZ2VzdGVkPyBJIHRoaW5rIHRoZTxicj4NCmJpZ2dlc3QgdmFsdWUg b2YgdGhlIHVzZSBjYXNlcyBkb2Mgd2FzIHRvIHRoZSBXRyBkdXJpbmcgZGV2ZWxvcG1lbnQgb2Yg dGhlPGJyPg0KY29yZSBzcGVjLCBhbmQgbm93IHRoYXQgdGhlIGNvcmUgc3BlYyBhcmUgcHJldHR5 IG11Y2ggZmluYWwgb3IgY2xvc2UgdG88YnI+DQpmaW5hbCBpdHMgdmFsdWUgZm9yIHRoZSBtb3N0 IHBhcnQgaXMgc3VwZXJzZWRlZCBieSB0aGUgY29yZSBzcGVjLjxicj4NCjxicj4NCkkgY2VydGFp bmx5IHRoaW5rIGl0IHN0aWxsIGhhcyBoaXN0b3JpY2FsIHZhbHVlIGhlbHBpbmcgc29tZW9uZSBu ZXcgdG88YnI+DQpTQ0lNIHVuZGVyc3RhbmQgd2h5IHNvbWUgZGVjaXNpb25zIHdlcmUgbWFkZS4g SXQgYWxzbyBjb3VsZCBoZWxwIHdpdGggdGhlPGJyPg0Kb3ZlcmFsbCBvdmVydmlldyBvZiBTQ0lN LiBIb3dldmVyLCBJIHRoaW5rIHRoZXJlIG1pZ2h0IGJlIG90aGVyPGJyPg0KcG90ZW50aWFsbHkg bW9yZSBzdWl0YWJsZSBtZWNoYW5pc21zIGZvciBjYXB0dXJlIHRoYXQgYXMgb3Bwb3NlZCB0bzxi cj4NCnR1cm5pbmcgdGhpcyBpbnRvIGFuIEluZm9ybWF0aW9uYWwgUkZDLiBGb3IgZXhhbXBsZSB3 ZSBjb3VsZCBwdWJsaXNoIGl0IG9uPGJyPg0KwrM8YSBocmVmPSJodHRwOi8vc2ltcGxlY2xvdWQu aW5mbyIgdGFyZ2V0PSJfYmxhbmsiPnNpbXBsZWNsb3VkLmluZm88L2E+wrIgc2l0ZSBhbG9uZyB3 aXRoIG90aGVyIGltcGxlbWVudGF0aW9uL3Rlc3RpbmcvZ3VpZGU8YnI+DQphcnRpY2xlcyAmYW1w OyBwcmVzZW50YXRpb25zLjxicj4NCjxicj4NClRob3VnaHRzPzxicj4NCjxicj4NCjxicj4NCkNo ZWVycyw8YnI+DQpNb3J0ZXphPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCk9uIDMvMTIvMTUsIDEyOjI2IFBNLCAmcXVvdDtCYXJyeSBMZWli YSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJy eWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtJIGxpa2Ug dGhpcyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgaXQncyBhYm91dCByZWFkeSB0byBnby4mbmJzcDsg SSBqdXN0IGhhdmU8YnI+DQomZ3Q7dHdvIGlzc3VlcyBJJ2QgbGlrZSB0byBkaXNjdXNzIHdpdGgg dGhlIGVkaXRvcnMgYW5kIHdvcmtpbmcgZ3JvdXA6PGJyPg0KJmd0Ozxicj4NCiZndDsxLiBJIHRo aW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvbyBicmllZiwgYW5k IHdvdWxkPGJyPg0KJmd0O2JlIGJldHRlciBmbGVzaGVkIG91dCBhIGJpdC4mbmJzcDsgVGhlcmUg YXJlIGdvaW5nIHRvIGJlIGRldGFpbHMgdGhhdCdsbCBiZTxicj4NCiZndDtsZWZ0IHRvIHRoZSBz Y2hlbWEgYW5kIGFwaSBkb2N1bWVudHMgLS0gZGV0YWlscyB0aGF0IGhhdmUgdG8gZG8gd2l0aDxi cj4NCiZndDt0aGUgc2NoZW1hIGFuZCBhcGksIG9mIGNvdXJzZS4mbmJzcDsgQnV0IHRoaXMgZG9j dW1lbnQgY291bGQgYW5kIHNob3VsZDxicj4NCiZndDt0YWxrIGFib3V0IHRoZSBnZW5lcmFsIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB3aGF0IFNDSU0gaXMgZG9pbmcuPGJyPg0KJmd0O1do YXQgYXJlIHRoZSBnZW5lcmFsIHRocmVhdHMgYW5kIHByaXZhY3kgaXNzdWVzLCBhbmQgaG93IGRv IHlvdSBleHBlY3Q8YnI+DQomZ3Q7dGhlbSB0byBiZSBkZWFsdCB3aXRoPyZuYnNwOyBMZXQgdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoaXM8YnI+DQomZ3Q7ZG9jdW1lbnQgZm9ybSB0 aGUgYmFzaXMgb24gd2hpY2ggdGhlIG90aGVyIGRvY3VtZW50cyB3aXRoIGV4cGFuZCB3aGVuPGJy Pg0KJmd0O3RoZSBwcm90b2NvbCBkZXRhaWxzIGFyZSBpbiBwbGFjZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OzIuIFRoZSBJRVNHIGhhcyBiZWVuIHN0cm9uZ2x5IHF1ZXN0aW9uaW5nIHRoZSB2YWx1ZSBv ZiBwdWJsaXNoaW5nPGJyPg0KJmd0O3VzZS1jYXNlIGRvY3VtZW50cyBhcyBSRkNzLiZuYnNwOyBU aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGV5IHJlYWxseSBoYXZlPGJyPg0KJmd0O2FyY2hpdmFs IHZhbHVlLCBvciB3aGV0aGVyIG5vIG9uZSB3aWxsIHJlYWQgdGhlbSBpbiBzaXggbW9udGhzIG9y IHNvLDxicj4NCiZndDt3aGVuIHRoZSBwcm90b2NvbHMgdGhleSBpbmZvcm1lZCBoYXZlIGJlZW4g cHVibGlzaGVkLiZuYnNwOyBPZnRlbiwgaXQgd291bGQ8YnI+DQomZ3Q7YmUgYmV0dGVyIHRvIHB1 Ymxpc2ggY29sbGVjdGlvbnMgb2YgdXNlIGNhc2VzIGFuZCByZWxhdGVkIGRpc2N1c3Npb248YnI+ DQomZ3Q7aW4gdGhlIHdvcmtpbmcgZ3JvdXAncyB3aWtpLCByYXRoZXIgdGhhbiBnb2luZyBmb3Ig UkZDIHB1YmxpY2F0aW9uLiZuYnNwOyBJPGJyPg0KJmd0O3ZlcnkgbXVjaCBzdXBwb3J0IHRoYXQg cXVlc3Rpb25pbmcuJm5ic3A7IEJ1dC4uLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhpcyBkb2N1bWVu dCBpcyBtb3JlIHRoYW4gYSB1c2UtY2FzZXMgZG9jdW1lbnQsIGFuZCBpdCBzZWxscyBpdHNlbGY8 YnI+DQomZ3Q7c2hvcnQgYnkgYnVyeWluZyB0aGF0LCBieSBtYWtpbmcgdGhlIHJlYWRlciBmaWd1 cmUgdGhhdCBvdXQuJm5ic3A7IEl0J3M8YnI+DQomZ3Q7cmVhbGx5IGRlZmluaXRpb25zIGFuZCBv dmVydmlldywgZmxvd3MsIHVzZSBjYXNlcywgYW5kIHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7QXMg c3VjaCwgSSB0aGluayBpdCAqZG9lcyogaGF2ZSB2YWx1ZSBhcyBhbiBSRkMuJm5ic3A7IExldCdz IG5vdCBtYWtlIHRoZTxicj4NCiZndDtyZXN0IG9mIHRoZSBJRVNHIHdvbmRlciBhYm91dCB0aGF0 LCBhbmQgcGVyaGFwcyB0YWtlIGEgZGlmZmVyZW50IHZpZXcuPGJyPg0KJmd0O0kgc3VnZ2VzdCB5 b3UgcmV0aXRsZSB0aGUgZG9jdW1lbnQgc29tZXRoaW5nIGxpa2UgdGhpczo8YnI+DQomZ3Q7PGJy Pg0KJmd0O09MRDxicj4NCiZndDtTQ0lNIFVzZSBDYXNlczxicj4NCiZndDs8YnI+DQomZ3Q7TkVX PGJyPg0KJmd0O1N5c3RlbSBmb3IgQ3Jvc3MtZG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQgKFND SU0pIERlZmluaXRpb25zLDxicj4NCiZndDtPdmVydmlldywgYW5kIEZsb3dzPGJyPg0KJmd0Ozxi cj4NCiZndDtFTkQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyhUaGF0IGFsc28gZXhwYW5kcyBTQ0lNLCB3 aGljaCB0aGUgUkZDIEVkaXRvciB3aWxsIGluc2lzdCBvbiwgc28geW91PGJyPg0KJmd0O21pZ2h0 IGFzIHdlbGwgZG8gaXQgbm93Lik8YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZW4gZm9yIHRoZSBhYnN0 cmFjdDo8YnI+DQomZ3Q7PGJyPg0KJmd0O09MRDxicj4NCiZndDsmbmJzcDsgJm5ic3A7VGhpcyBk b2N1bWVudCBsaXN0cyB0aGUgdXNlciBzY2VuYXJpb3MgYW5kIHVzZSBjYXNlcyBvZiBTeXN0ZW0g Zm9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVu dCAoU0NJTSkuPGJyPg0KJmd0Ozxicj4NCiZndDtORVc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO1Ro aXMgZG9jdW1lbnQgcHJvdmlkZXMgZGVmaW5pdGlvbnMgYW5kIGFuIG92ZXJ2aWV3IG9mIHRoZSBT eXN0ZW08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2ZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFu YWdlbWVudCAoU0NJTSkuJm5ic3A7IEl0IGxheXMgb3V0IHRoZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7c3lzdGVtJ3MgbW9kZXMgYW5kIGZsb3dzLCBhbmQgaW5jbHVkZXMgdXNlciBzY2VuYXJpb3Ms IHVzZSBjYXNlcyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO2FuZCByZXF1aXJlbWVudHMuPGJyPg0K Jmd0Ozxicj4NCiZndDtFTkQ8YnI+DQomZ3Q7PGJyPg0KJmd0O0FuZCB0aGVuIHR3ZWFrIHRoZSBJ bnRyb2R1Y3Rpb24gYWNjb3JkaW5nbHkuPGJyPg0KJmd0Ozxicj4NCiZndDtEbyB0aG9zZSBwb2lu dHMgc291bmQgcmVhc29uYWJsZT88YnI+DQomZ3Q7KEkgd2lsbCBwdXQgdGhlIGRvY3VtZW50IGlu dG8gJnF1b3Q7QUQgRXZhbHVhdGlvbjogUmV2aXNlZCBJLUQgTmVlZGVkJnF1b3Q7IHN0YXRlLik8 YnI+DQomZ3Q7PGJyPg0KJmd0O0JhcnJ5PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDtzY2ltIG1haWxpbmcg bGlzdDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zY2ltIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zY2ltPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4gR2xhemVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW5pb3IgRGlyZWN0b3IsIElkZW50aXR5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgMjAy IDI1NSAzMTY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXIiIHRhcmdldD0iX2JsYW5r Ij5AaWdsYXplcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNj aW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1A aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_BN3PR0301MB1234763E9A9EFFEDA8CC686EA6050BN3PR0301MB1234_-- From nobody Mon Mar 16 15:20:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994B1AC3BC for ; Mon, 16 Mar 2015 15:20:33 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hCmufi65IDXJ for ; Mon, 16 Mar 2015 15:20:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0D41ABD36 for ; Mon, 16 Mar 2015 15:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23874; q=dns/txt; s=iport; t=1426544429; x=1427754029; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=28grJrCnozQjZvIhlSYVG9RTDvhkE9izEBKkDN/3qMc=; b=KctlbeFduRn5QbWmbqTQAgTSgwAmrY2LeSkGqdghwuSIwJSSM9ddm/S0 34knfajUTjL9Zyn9YsImw8hPrc6FeAuWsavXZaRah/9R/elpKQ5+Fpxtq HVRXbVQ6cFTDvvkF4xsvIsxdcdu4E35psiCxulnMkJ+M/lHgiaShxv5sz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUBwDrVgdV/4wNJK1SBgOCQ0NSWgSDCLIJC40iPIFzAQmFdQIcgRxMAQEBAQEBfYQPAQEBBAEBASpBCxACAQgOAwMBAQEoBQICJQsUCQgCBAENBYgvDZAmnGYGm04BAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEFkAKAQwEBgEJCIJRgUsFhQKBQYduggmDa4V7gRs5gnKCVIx6I4Nub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,412,1422921600"; d="scan'208,217";a="404101587" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 16 Mar 2015 22:20:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2GMKONg002645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Mar 2015 22:20:24 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 16 Mar 2015 17:20:23 -0500 From: "Morteza Ansari (moransar)" To: Anthony Nadalin , Phil Hunt , Ian Glazer Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Thread-Index: AQHQXPqF14ndZd68F0WH+7QX3QdDep0afCmAgAB7eACAAAxRgIACC0UAgAKEF4A= Date: Mon, 16 Mar 2015 22:20:23 +0000 Message-ID: References: <30CBC74A-73E9-413A-96AA-EE5E38720505@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.155.85.138] Content-Type: multipart/alternative; boundary="_000_D12CA3F912090Dmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 22:20:33 -0000 --_000_D12CA3F912090Dmoransarciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 U291bmRzIGxpa2UgdGhlcmUgaXMgV0cgaW50ZXJlc3QgaW4gcHVibGlzaGluZyB0aGlzIGFzIGFu IEluZm9ybWF0aW9uYWwgUkZDLg0KDQpEb2N1bWVudCBlZGl0b3JzLCBjYW4geW91IHBsZWFzZSBj b25zaWRlciBCYXJyeaGvcyBmZWVkYmFjayBhbmQgc3VnZ2VzdCB0ZXh0IHVwZGF0ZXMgdG8gdGhl IFdHPw0KDQoNCkNoZWVycywNCk1vcnRlemENCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIDx0b255 bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBT YXR1cmRheSwgTWFyY2ggMTQsIDIwMTUgYXQgNTo1NSBQTQ0KVG86IFBoaWwgSHVudCA8cGhpbC5o dW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4sIElhbiBHbGF6ZXIg PGlnbGF6ZXJAc2FsZXNmb3JjZS5jb208bWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20+Pg0K Q2M6ICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPiIgPHNjaW1AaWV0Zi5vcmc8 bWFpbHRvOnNjaW1AaWV0Zi5vcmc+PiwgIkJhcnJ5IG9yZz4iIDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiwgTW9ydGV6YSBBbnNhcmkgPG1v cmFuc2FyQGNpc2NvLmNvbTxtYWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4NClN1YmplY3Q6IFJF OiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2NpbS11c2UtY2FzZXMtMDQNCg0KSG1t bSwgdGhlIGlzc3VlIGlzIHRoYXQgdGhlc2UgbmVlZCB0byBzdGljayBhcm91bmQgYW5kIGJlIHRp ZWQgdG8gdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb25zIGFuZCBmdXR1cmUgc3BlY2lmaWNhdGlv bnMgc28gZm9sa3MgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbXMgYmVpbmcgc29sdmVkLCBzbyBJIGRv bqGvdCBzdXBwb3J0IHB1Ymxpc2hpbmcgb24gc2NpbXBsZWNsb3VkLmluZm8NCg0KRnJvbTogc2Np bSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0K U2VudDogRnJpZGF5LCBNYXJjaCAxMywgMjAxNSAxMDo0MiBBTQ0KVG86IElhbiBHbGF6ZXINCkNj OiBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPjsgQmFycnkgTGVpYmE7IE1vcnRl emEgQW5zYXJpIChtb3JhbnNhcikNClN1YmplY3Q6IFJlOiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtc2NpbS11c2UtY2FzZXMtMDQNCg0KKzEuICBJdCBoYXMgaW5mb3JtZWQgdGhlIGRl dmVsb3BtZW50IG9mIHRoZSBXRyBkcmFmdHMgYnV0IEkgYW0gbm90IHN1cmUgaXQgaXMgbmVlZGVk IGFzIFJGQy4NCg0KUGhpbA0KDQpPbiBNYXIgMTMsIDIwMTUsIGF0IDA5OjU4LCBJYW4gR2xhemVy IDxpZ2xhemVyQHNhbGVzZm9yY2UuY29tPG1haWx0bzppZ2xhemVyQHNhbGVzZm9yY2UuY29tPj4g d3JvdGU6DQpJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbmUgd2F5IG9yIGFub3RoZXIg YnV0IGxlYW4gc2xpZ2h0bHkgdG93YXJkcyBwdWJsaXNoaW5nIGl0IG9uIHNjaW1wbGVjbG91ZC5p bmZvPGh0dHA6Ly9zY2ltcGxlY2xvdWQuaW5mbz4NCg0KT24gRnJpLCBNYXIgMTMsIDIwMTUgYXQg MTI6MzYgUE0sIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikgPG1vcmFuc2FyQGNpc2NvLmNvbTxt YWlsdG86bW9yYW5zYXJAY2lzY28uY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHRoZSByZXZpZXcg QmFycnkuDQoNCk15IGNvbW1lbnQgYXMgV0cgbWVtYmVycyBhbmQgZGVmaW5pdGVseSBub3QgYXMg Q2hhaXI6DQoNCkRvIHdlIHJlYWxseSBuZWVkIHRvIHB1Ymxpc2ggdGhlIHVzZSBjYXNlcyBhcyBh biBSRkMsIGV2ZW4gaWYgd2UgbW9kaWZ5IGl0DQp0byCp+GRlZmluaXRpb25zLCBvdmVydmlldywg YW5kIGZsb3dzqfcgYXMgQmFycnkgc3VnZ2VzdGVkPyBJIHRoaW5rIHRoZQ0KYmlnZ2VzdCB2YWx1 ZSBvZiB0aGUgdXNlIGNhc2VzIGRvYyB3YXMgdG8gdGhlIFdHIGR1cmluZyBkZXZlbG9wbWVudCBv ZiB0aGUNCmNvcmUgc3BlYywgYW5kIG5vdyB0aGF0IHRoZSBjb3JlIHNwZWMgYXJlIHByZXR0eSBt dWNoIGZpbmFsIG9yIGNsb3NlIHRvDQpmaW5hbCBpdHMgdmFsdWUgZm9yIHRoZSBtb3N0IHBhcnQg aXMgc3VwZXJzZWRlZCBieSB0aGUgY29yZSBzcGVjLg0KDQpJIGNlcnRhaW5seSB0aGluayBpdCBz dGlsbCBoYXMgaGlzdG9yaWNhbCB2YWx1ZSBoZWxwaW5nIHNvbWVvbmUgbmV3IHRvDQpTQ0lNIHVu ZGVyc3RhbmQgd2h5IHNvbWUgZGVjaXNpb25zIHdlcmUgbWFkZS4gSXQgYWxzbyBjb3VsZCBoZWxw IHdpdGggdGhlDQpvdmVyYWxsIG92ZXJ2aWV3IG9mIFNDSU0uIEhvd2V2ZXIsIEkgdGhpbmsgdGhl cmUgbWlnaHQgYmUgb3RoZXINCnBvdGVudGlhbGx5IG1vcmUgc3VpdGFibGUgbWVjaGFuaXNtcyBm b3IgY2FwdHVyZSB0aGF0IGFzIG9wcG9zZWQgdG8NCnR1cm5pbmcgdGhpcyBpbnRvIGFuIEluZm9y bWF0aW9uYWwgUkZDLiBGb3IgZXhhbXBsZSB3ZSBjb3VsZCBwdWJsaXNoIGl0IG9uDQqp+HNpbXBs ZWNsb3VkLmluZm88aHR0cDovL3NpbXBsZWNsb3VkLmluZm8+qfcgc2l0ZSBhbG9uZyB3aXRoIG90 aGVyIGltcGxlbWVudGF0aW9uL3Rlc3RpbmcvZ3VpZGUNCmFydGljbGVzICYgcHJlc2VudGF0aW9u cy4NCg0KVGhvdWdodHM/DQoNCg0KQ2hlZXJzLA0KTW9ydGV6YQ0KDQpPbiAzLzEyLzE1LCAxMjoy NiBQTSwgIkJhcnJ5IExlaWJhIiA8YmFycnlsZWliYUBjb21wdXRlci5vcmc8bWFpbHRvOmJhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnPj4gd3JvdGU6DQoNCj5JIGxpa2UgdGhpcyBkb2N1bWVudCwgYW5k IEkgdGhpbmsgaXQncyBhYm91dCByZWFkeSB0byBnby4gIEkganVzdCBoYXZlDQo+dHdvIGlzc3Vl cyBJJ2QgbGlrZSB0byBkaXNjdXNzIHdpdGggdGhlIGVkaXRvcnMgYW5kIHdvcmtpbmcgZ3JvdXA6 DQo+DQo+MS4gSSB0aGluayB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0 b28gYnJpZWYsIGFuZCB3b3VsZA0KPmJlIGJldHRlciBmbGVzaGVkIG91dCBhIGJpdC4gIFRoZXJl IGFyZSBnb2luZyB0byBiZSBkZXRhaWxzIHRoYXQnbGwgYmUNCj5sZWZ0IHRvIHRoZSBzY2hlbWEg YW5kIGFwaSBkb2N1bWVudHMgLS0gZGV0YWlscyB0aGF0IGhhdmUgdG8gZG8gd2l0aA0KPnRoZSBz Y2hlbWEgYW5kIGFwaSwgb2YgY291cnNlLiAgQnV0IHRoaXMgZG9jdW1lbnQgY291bGQgYW5kIHNo b3VsZA0KPnRhbGsgYWJvdXQgdGhlIGdlbmVyYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9y IHdoYXQgU0NJTSBpcyBkb2luZy4NCj5XaGF0IGFyZSB0aGUgZ2VuZXJhbCB0aHJlYXRzIGFuZCBw cml2YWN5IGlzc3VlcywgYW5kIGhvdyBkbyB5b3UgZXhwZWN0DQo+dGhlbSB0byBiZSBkZWFsdCB3 aXRoPyAgTGV0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGlzDQo+ZG9jdW1lbnQg Zm9ybSB0aGUgYmFzaXMgb24gd2hpY2ggdGhlIG90aGVyIGRvY3VtZW50cyB3aXRoIGV4cGFuZCB3 aGVuDQo+dGhlIHByb3RvY29sIGRldGFpbHMgYXJlIGluIHBsYWNlLg0KPg0KPjIuIFRoZSBJRVNH IGhhcyBiZWVuIHN0cm9uZ2x5IHF1ZXN0aW9uaW5nIHRoZSB2YWx1ZSBvZiBwdWJsaXNoaW5nDQo+ dXNlLWNhc2UgZG9jdW1lbnRzIGFzIFJGQ3MuICBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGV5 IHJlYWxseSBoYXZlDQo+YXJjaGl2YWwgdmFsdWUsIG9yIHdoZXRoZXIgbm8gb25lIHdpbGwgcmVh ZCB0aGVtIGluIHNpeCBtb250aHMgb3Igc28sDQo+d2hlbiB0aGUgcHJvdG9jb2xzIHRoZXkgaW5m b3JtZWQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4gIE9mdGVuLCBpdCB3b3VsZA0KPmJlIGJldHRlciB0 byBwdWJsaXNoIGNvbGxlY3Rpb25zIG9mIHVzZSBjYXNlcyBhbmQgcmVsYXRlZCBkaXNjdXNzaW9u DQo+aW4gdGhlIHdvcmtpbmcgZ3JvdXAncyB3aWtpLCByYXRoZXIgdGhhbiBnb2luZyBmb3IgUkZD IHB1YmxpY2F0aW9uLiAgSQ0KPnZlcnkgbXVjaCBzdXBwb3J0IHRoYXQgcXVlc3Rpb25pbmcuICBC dXQuLi4NCj4NCj5UaGlzIGRvY3VtZW50IGlzIG1vcmUgdGhhbiBhIHVzZS1jYXNlcyBkb2N1bWVu dCwgYW5kIGl0IHNlbGxzIGl0c2VsZg0KPnNob3J0IGJ5IGJ1cnlpbmcgdGhhdCwgYnkgbWFraW5n IHRoZSByZWFkZXIgZmlndXJlIHRoYXQgb3V0LiAgSXQncw0KPnJlYWxseSBkZWZpbml0aW9ucyBh bmQgb3ZlcnZpZXcsIGZsb3dzLCB1c2UgY2FzZXMsIGFuZCByZXF1aXJlbWVudHMuDQo+QXMgc3Vj aCwgSSB0aGluayBpdCAqZG9lcyogaGF2ZSB2YWx1ZSBhcyBhbiBSRkMuICBMZXQncyBub3QgbWFr ZSB0aGUNCj5yZXN0IG9mIHRoZSBJRVNHIHdvbmRlciBhYm91dCB0aGF0LCBhbmQgcGVyaGFwcyB0 YWtlIGEgZGlmZmVyZW50IHZpZXcuDQo+SSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVu dCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPg0KPk9MRA0KPlNDSU0gVXNlIENhc2VzDQo+DQo+TkVX DQo+U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgRGVm aW5pdGlvbnMsDQo+T3ZlcnZpZXcsIGFuZCBGbG93cw0KPg0KPkVORA0KPg0KPihUaGF0IGFsc28g ZXhwYW5kcyBTQ0lNLCB3aGljaCB0aGUgUkZDIEVkaXRvciB3aWxsIGluc2lzdCBvbiwgc28geW91 DQo+bWlnaHQgYXMgd2VsbCBkbyBpdCBub3cuKQ0KPg0KPlRoZW4gZm9yIHRoZSBhYnN0cmFjdDoN Cj4NCj5PTEQNCj4gICBUaGlzIGRvY3VtZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQg dXNlIGNhc2VzIG9mIFN5c3RlbSBmb3INCj4gICBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdl bWVudCAoU0NJTSkuDQo+DQo+TkVXDQo+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBkZWZpbml0 aW9ucyBhbmQgYW4gb3ZlcnZpZXcgb2YgdGhlIFN5c3RlbQ0KPiAgIGZvciBDcm9zcy1kb21haW4g SWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkuICBJdCBsYXlzIG91dCB0aGUNCj4gICBzeXN0ZW0n cyBtb2RlcyBhbmQgZmxvd3MsIGFuZCBpbmNsdWRlcyB1c2VyIHNjZW5hcmlvcywgdXNlIGNhc2Vz LA0KPiAgIGFuZCByZXF1aXJlbWVudHMuDQo+DQo+RU5EDQo+DQo+QW5kIHRoZW4gdHdlYWsgdGhl IEludHJvZHVjdGlvbiBhY2NvcmRpbmdseS4NCj4NCj5EbyB0aG9zZSBwb2ludHMgc291bmQgcmVh c29uYWJsZT8NCj4oSSB3aWxsIHB1dCB0aGUgZG9jdW1lbnQgaW50byAiQUQgRXZhbHVhdGlvbjog UmV2aXNlZCBJLUQgTmVlZGVkIiBzdGF0ZS4pDQo+DQo+QmFycnkNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNjaW0gbWFpbGluZyBsaXN0DQo+ c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0 bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z Y2ltDQoNCg0KDQotLQ0KSWFuIEdsYXplcg0KU2VuaW9yIERpcmVjdG9yLCBJZGVudGl0eQ0KKzEg MjAyIDI1NSAzMTY2DQpAaWdsYXplcjxodHRwczovL3R3aXR0ZXIuY29tL2lnbGF6ZXI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5n IGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg== --_000_D12CA3F912090Dmoransarciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+U291bmRzIGxp a2UgdGhlcmUgaXMgV0cgaW50ZXJlc3QgaW4gcHVibGlzaGluZyB0aGlzIGFzIGFuIEluZm9ybWF0 aW9uYWwgUkZDLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9jdW1lbnQgZWRpdG9y cywgY2FuIHlvdSBwbGVhc2UgY29uc2lkZXIgQmFycnmhr3MgZmVlZGJhY2sgYW5kIHN1Z2dlc3Qg dGV4dCB1cGRhdGVzIHRvIHRoZSBXRz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2Pk1vcnRlemE8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86 dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+U2F0dXJkYXksIE1h cmNoIDE0LCAyMDE1IGF0IDU6NTUgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj5QaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OywgSWFuIEdsYXplciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20iPmlnbGF6ZXJAc2FsZXNmb3JjZS5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFu PiZxdW90OzxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+ Jmd0OywgJnF1b3Q7QmFycnkgb3JnJmd0OyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7LCBNb3J0 ZXphIEFuc2FyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSI+bW9yYW5z YXJAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDogPC9zcGFuPlJFOiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2NpbS11 c2UtY2FzZXMtMDQ8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2Zm aWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAi Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmls dGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SG1tbSwgdGhlIGlzc3VlIGlzIHRoYXQgdGhl c2UgbmVlZCB0byBzdGljayBhcm91bmQgYW5kIGJlIHRpZWQgdG8gdGhlIGV4aXN0aW5nIHNwZWNp ZmljYXRpb25zIGFuZCBmdXR1cmUgc3BlY2lmaWNhdGlvbnMgc28gZm9sa3MgdW5kZXJzdGFuZCB0 aGUgcHJvYmxlbXMNCiBiZWluZyBzb2x2ZWQsIHNvIEkgZG9uoa90IHN1cHBvcnQgcHVibGlzaGlu ZyBvbiBzY2ltcGxlY2xvdWQuaW5mbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPiBzY2ltIFs8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMTMsIDIw MTUgMTA6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IElhbiBHbGF6ZXI8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjsgQmFycnkgTGVp YmE7IE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtz Y2ltXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0wNDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEuICZuYnNw O0l0IGhhcyBpbmZvcm1lZCB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIFdHIGRyYWZ0cyBidXQgSSBh bSBub3Qgc3VyZSBpdCBpcyBuZWVkZWQgYXMgUkZDLjxicj4NCjxicj4NClBoaWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWFyIDEzLCAyMDE1LCBhdCAwOTo1OCwgSWFuIEdsYXpl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnbGF6ZXJAc2FsZXNmb3JjZS5jb20iPmlnbGF6ZXJAc2Fs ZXNmb3JjZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGlu aW9uIG9uZSB3YXkgb3IgYW5vdGhlciBidXQgbGVhbiBzbGlnaHRseSB0b3dhcmRzIHB1Ymxpc2hp bmcgaXQgb24NCjxhIGhyZWY9Imh0dHA6Ly9zY2ltcGxlY2xvdWQuaW5mbyI+c2NpbXBsZWNsb3Vk LmluZm88L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBGcmksIE1hciAxMywgMjAxNSBhdCAxMjozNiBQTSwgTW9ydGV6YSBBbnNhcmkgKG1vcmFuc2Fy KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHJldmlldyBCYXJyeS48 YnI+DQo8YnI+DQpNeSBjb21tZW50IGFzIFdHIG1lbWJlcnMgYW5kIGRlZmluaXRlbHkgbm90IGFz IENoYWlyOjxicj4NCjxicj4NCkRvIHdlIHJlYWxseSBuZWVkIHRvIHB1Ymxpc2ggdGhlIHVzZSBj YXNlcyBhcyBhbiBSRkMsIGV2ZW4gaWYgd2UgbW9kaWZ5IGl0PGJyPg0KdG8gqfhkZWZpbml0aW9u cywgb3ZlcnZpZXcsIGFuZCBmbG93c6n3IGFzIEJhcnJ5IHN1Z2dlc3RlZD8gSSB0aGluayB0aGU8 YnI+DQpiaWdnZXN0IHZhbHVlIG9mIHRoZSB1c2UgY2FzZXMgZG9jIHdhcyB0byB0aGUgV0cgZHVy aW5nIGRldmVsb3BtZW50IG9mIHRoZTxicj4NCmNvcmUgc3BlYywgYW5kIG5vdyB0aGF0IHRoZSBj b3JlIHNwZWMgYXJlIHByZXR0eSBtdWNoIGZpbmFsIG9yIGNsb3NlIHRvPGJyPg0KZmluYWwgaXRz IHZhbHVlIGZvciB0aGUgbW9zdCBwYXJ0IGlzIHN1cGVyc2VkZWQgYnkgdGhlIGNvcmUgc3BlYy48 YnI+DQo8YnI+DQpJIGNlcnRhaW5seSB0aGluayBpdCBzdGlsbCBoYXMgaGlzdG9yaWNhbCB2YWx1 ZSBoZWxwaW5nIHNvbWVvbmUgbmV3IHRvPGJyPg0KU0NJTSB1bmRlcnN0YW5kIHdoeSBzb21lIGRl Y2lzaW9ucyB3ZXJlIG1hZGUuIEl0IGFsc28gY291bGQgaGVscCB3aXRoIHRoZTxicj4NCm92ZXJh bGwgb3ZlcnZpZXcgb2YgU0NJTS4gSG93ZXZlciwgSSB0aGluayB0aGVyZSBtaWdodCBiZSBvdGhl cjxicj4NCnBvdGVudGlhbGx5IG1vcmUgc3VpdGFibGUgbWVjaGFuaXNtcyBmb3IgY2FwdHVyZSB0 aGF0IGFzIG9wcG9zZWQgdG88YnI+DQp0dXJuaW5nIHRoaXMgaW50byBhbiBJbmZvcm1hdGlvbmFs IFJGQy4gRm9yIGV4YW1wbGUgd2UgY291bGQgcHVibGlzaCBpdCBvbjxicj4NCqn4PGEgaHJlZj0i aHR0cDovL3NpbXBsZWNsb3VkLmluZm8iIHRhcmdldD0iX2JsYW5rIj5zaW1wbGVjbG91ZC5pbmZv PC9hPqn3IHNpdGUgYWxvbmcgd2l0aCBvdGhlciBpbXBsZW1lbnRhdGlvbi90ZXN0aW5nL2d1aWRl PGJyPg0KYXJ0aWNsZXMgJmFtcDsgcHJlc2VudGF0aW9ucy48YnI+DQo8YnI+DQpUaG91Z2h0cz88 YnI+DQo8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KTW9ydGV6YTxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPbiAzLzEyLzE1LCAxMjoyNiBQ TSwgJnF1b3Q7QmFycnkgTGVpYmEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiYXJyeWxlaWJh QGNvbXB1dGVyLm9yZyI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQomZ3Q7SSBsaWtlIHRoaXMgZG9jdW1lbnQsIGFuZCBJIHRoaW5rIGl0J3MgYWJvdXQg cmVhZHkgdG8gZ28uJm5ic3A7IEkganVzdCBoYXZlPGJyPg0KJmd0O3R3byBpc3N1ZXMgSSdkIGxp a2UgdG8gZGlzY3VzcyB3aXRoIHRoZSBlZGl0b3JzIGFuZCB3b3JraW5nIGdyb3VwOjxicj4NCiZn dDs8YnI+DQomZ3Q7MS4gSSB0aGluayB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBpcyB0b28gYnJpZWYsIGFuZCB3b3VsZDxicj4NCiZndDtiZSBiZXR0ZXIgZmxlc2hlZCBvdXQg YSBiaXQuJm5ic3A7IFRoZXJlIGFyZSBnb2luZyB0byBiZSBkZXRhaWxzIHRoYXQnbGwgYmU8YnI+ DQomZ3Q7bGVmdCB0byB0aGUgc2NoZW1hIGFuZCBhcGkgZG9jdW1lbnRzIC0tIGRldGFpbHMgdGhh dCBoYXZlIHRvIGRvIHdpdGg8YnI+DQomZ3Q7dGhlIHNjaGVtYSBhbmQgYXBpLCBvZiBjb3Vyc2Uu Jm5ic3A7IEJ1dCB0aGlzIGRvY3VtZW50IGNvdWxkIGFuZCBzaG91bGQ8YnI+DQomZ3Q7dGFsayBh Ym91dCB0aGUgZ2VuZXJhbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3Igd2hhdCBTQ0lNIGlz IGRvaW5nLjxicj4NCiZndDtXaGF0IGFyZSB0aGUgZ2VuZXJhbCB0aHJlYXRzIGFuZCBwcml2YWN5 IGlzc3VlcywgYW5kIGhvdyBkbyB5b3UgZXhwZWN0PGJyPg0KJmd0O3RoZW0gdG8gYmUgZGVhbHQg d2l0aD8mbmJzcDsgTGV0IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGlzPGJyPg0K Jmd0O2RvY3VtZW50IGZvcm0gdGhlIGJhc2lzIG9uIHdoaWNoIHRoZSBvdGhlciBkb2N1bWVudHMg d2l0aCBleHBhbmQgd2hlbjxicj4NCiZndDt0aGUgcHJvdG9jb2wgZGV0YWlscyBhcmUgaW4gcGxh Y2UuPGJyPg0KJmd0Ozxicj4NCiZndDsyLiBUaGUgSUVTRyBoYXMgYmVlbiBzdHJvbmdseSBxdWVz dGlvbmluZyB0aGUgdmFsdWUgb2YgcHVibGlzaGluZzxicj4NCiZndDt1c2UtY2FzZSBkb2N1bWVu dHMgYXMgUkZDcy4mbmJzcDsgVGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhleSByZWFsbHkgaGF2 ZTxicj4NCiZndDthcmNoaXZhbCB2YWx1ZSwgb3Igd2hldGhlciBubyBvbmUgd2lsbCByZWFkIHRo ZW0gaW4gc2l4IG1vbnRocyBvciBzbyw8YnI+DQomZ3Q7d2hlbiB0aGUgcHJvdG9jb2xzIHRoZXkg aW5mb3JtZWQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4mbmJzcDsgT2Z0ZW4sIGl0IHdvdWxkPGJyPg0K Jmd0O2JlIGJldHRlciB0byBwdWJsaXNoIGNvbGxlY3Rpb25zIG9mIHVzZSBjYXNlcyBhbmQgcmVs YXRlZCBkaXNjdXNzaW9uPGJyPg0KJmd0O2luIHRoZSB3b3JraW5nIGdyb3VwJ3Mgd2lraSwgcmF0 aGVyIHRoYW4gZ29pbmcgZm9yIFJGQyBwdWJsaWNhdGlvbi4mbmJzcDsgSTxicj4NCiZndDt2ZXJ5 IG11Y2ggc3VwcG9ydCB0aGF0IHF1ZXN0aW9uaW5nLiZuYnNwOyBCdXQuLi48YnI+DQomZ3Q7PGJy Pg0KJmd0O1RoaXMgZG9jdW1lbnQgaXMgbW9yZSB0aGFuIGEgdXNlLWNhc2VzIGRvY3VtZW50LCBh bmQgaXQgc2VsbHMgaXRzZWxmPGJyPg0KJmd0O3Nob3J0IGJ5IGJ1cnlpbmcgdGhhdCwgYnkgbWFr aW5nIHRoZSByZWFkZXIgZmlndXJlIHRoYXQgb3V0LiZuYnNwOyBJdCdzPGJyPg0KJmd0O3JlYWxs eSBkZWZpbml0aW9ucyBhbmQgb3ZlcnZpZXcsIGZsb3dzLCB1c2UgY2FzZXMsIGFuZCByZXF1aXJl bWVudHMuPGJyPg0KJmd0O0FzIHN1Y2gsIEkgdGhpbmsgaXQgKmRvZXMqIGhhdmUgdmFsdWUgYXMg YW4gUkZDLiZuYnNwOyBMZXQncyBub3QgbWFrZSB0aGU8YnI+DQomZ3Q7cmVzdCBvZiB0aGUgSUVT RyB3b25kZXIgYWJvdXQgdGhhdCwgYW5kIHBlcmhhcHMgdGFrZSBhIGRpZmZlcmVudCB2aWV3Ljxi cj4NCiZndDtJIHN1Z2dlc3QgeW91IHJldGl0bGUgdGhlIGRvY3VtZW50IHNvbWV0aGluZyBsaWtl IHRoaXM6PGJyPg0KJmd0Ozxicj4NCiZndDtPTEQ8YnI+DQomZ3Q7U0NJTSBVc2UgQ2FzZXM8YnI+ DQomZ3Q7PGJyPg0KJmd0O05FVzxicj4NCiZndDtTeXN0ZW0gZm9yIENyb3NzLWRvbWFpbiBJZGVu dGl0eSBNYW5hZ2VtZW50IChTQ0lNKSBEZWZpbml0aW9ucyw8YnI+DQomZ3Q7T3ZlcnZpZXcsIGFu ZCBGbG93czxicj4NCiZndDs8YnI+DQomZ3Q7RU5EPGJyPg0KJmd0Ozxicj4NCiZndDsoVGhhdCBh bHNvIGV4cGFuZHMgU0NJTSwgd2hpY2ggdGhlIFJGQyBFZGl0b3Igd2lsbCBpbnNpc3Qgb24sIHNv IHlvdTxicj4NCiZndDttaWdodCBhcyB3ZWxsIGRvIGl0IG5vdy4pPGJyPg0KJmd0Ozxicj4NCiZn dDtUaGVuIGZvciB0aGUgYWJzdHJhY3Q6PGJyPg0KJmd0Ozxicj4NCiZndDtPTEQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgbGlzdHMgdGhlIHVzZXIgc2NlbmFyaW9zIGFuZCB1 c2UgY2FzZXMgb2YgU3lzdGVtIGZvcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7Q3Jvc3MtZG9tYWlu IElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pLjxicj4NCiZndDs8YnI+DQomZ3Q7TkVXPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGRlZmluaXRpb25zIGFuZCBh biBvdmVydmlldyBvZiB0aGUgU3lzdGVtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtmb3IgQ3Jvc3Mt ZG9tYWluIElkZW50aXR5IE1hbmFnZW1lbnQgKFNDSU0pLiZuYnNwOyBJdCBsYXlzIG91dCB0aGU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3N5c3RlbSdzIG1vZGVzIGFuZCBmbG93cywgYW5kIGluY2x1 ZGVzIHVzZXIgc2NlbmFyaW9zLCB1c2UgY2FzZXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthbmQg cmVxdWlyZW1lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7RU5EPGJyPg0KJmd0Ozxicj4NCiZndDtB bmQgdGhlbiB0d2VhayB0aGUgSW50cm9kdWN0aW9uIGFjY29yZGluZ2x5Ljxicj4NCiZndDs8YnI+ DQomZ3Q7RG8gdGhvc2UgcG9pbnRzIHNvdW5kIHJlYXNvbmFibGU/PGJyPg0KJmd0OyhJIHdpbGwg cHV0IHRoZSBkb2N1bWVudCBpbnRvICZxdW90O0FEIEV2YWx1YXRpb246IFJldmlzZWQgSS1EIE5l ZWRlZCZxdW90OyBzdGF0ZS4pPGJyPg0KJmd0Ozxicj4NCiZndDtCYXJyeTxicj4NCiZndDs8YnI+ DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7c2NpbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0 Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNjaW0gbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z Y2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWFuIEdsYXplcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VuaW9yIERpcmVj dG9yLCBJZGVudGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JiM0MzsxIDIwMiAyNTUgMzE2NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9pZ2xh emVyIiB0YXJnZXQ9Il9ibGFuayI+QGlnbGF6ZXI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz Y2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D12CA3F912090Dmoransarciscocom_-- From nobody Mon Mar 16 22:26:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED41A1A0025 for ; Mon, 16 Mar 2015 22:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_LOTTO_NAME=0.747, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 f1jd59DqpBXf for ; Mon, 16 Mar 2015 22:26:50 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AB91A0022 for ; Mon, 16 Mar 2015 22:26:50 -0700 (PDT) Received: by igbue6 with SMTP id ue6so61904602igb.1 for ; Mon, 16 Mar 2015 22:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=GQgofcEisFm0lrHa0nRVwsV/jxZADTQ5H2Po59YfQuY=; b=zNQfpPr8wCrXs6hJRRBP6xPz4/prSo5vkdviJZGV2mgFQzNIedOhReAbsAEj3+5CcS W66L75ex07ppjZ9CMfC4hXn3pb3PLptkXUFSrZDIksi/QYFGiBhPN0o9pfzMB/YPK6OF ugkmtwJsY/PWmHLe+N/7g11cxpjA1ny6zeyAJtZ36BisNaeGYREKqYoKB6GL6i/16J8x snVUbqMd1qvZrddfHBK1ZxPiayqpEF6RnDe4yEsERy7vuMgRlI7t3DFQWtLq3EwPMLon 6PpQESrUAB1h5g1WvthSfGdvGK6JunMMUjiuJr9phmvc7inJBkgf+eFO/PGVf1zLp1As HMiQ== X-Received: by 10.42.187.7 with SMTP id cu7mr25747594icb.71.1426570010003; Mon, 16 Mar 2015 22:26:50 -0700 (PDT) MIME-Version: 1.0 From: Darshana Gunawardana Date: Tue, 17 Mar 2015 05:26:49 +0000 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=20cf3040e536b19275051175361c Archived-At: Subject: [scim] Why does SCIM specification restrict to update group list of user only from the group endpoint X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 05:26:52 -0000 --20cf3040e536b19275051175361c Content-Type: text/plain; charset=UTF-8 Hi all, We have several customer queries to add groups while creating the users from SCIM user endpoint, without doing a second request to group endpoint. In the spec its defined as "group membership changes MUST be applied via the Group Resource" so we have to do two requests to create user with some groups. We thought to implement SCIM group endpoint to support to add groups as well but as mentioned above, specification strongly restricting of doing that. I would like to know what are the reasons of restricting all group related operations only from group endpoint. Or is there any other optimal way to do this. Thanks, Darshana. --20cf3040e536b19275051175361c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We have several customer querie= s to add groups while creating the users from SCIM user endpoint, without d= oing a second request to group endpoint.

In th= e spec its defined as "group membership changes MUST be applied via th= e Group Resource" so we have to do two requests to create user with so= me groups.

We thought to implement SCIM group endp= oint to support to add groups as well but as mentioned above, specification= strongly restricting of doing that.

I would = like to know what are the reasons of restricting all group related operatio= ns only from group endpoint. Or is there any other optimal way to do this.<= /div>

Thanks,
Darshana.
--20cf3040e536b19275051175361c-- From nobody Mon Mar 16 23:23:02 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BE61A008B for ; Mon, 16 Mar 2015 23:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 3ErunYxNBcJx for ; Mon, 16 Mar 2015 23:22:48 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8533C1A0089 for ; Mon, 16 Mar 2015 23:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426573365; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=fuI6SntbDazXFBFYVJL+mE/rL3fJEjpeBjSFr7ViK+o=; b=AdBO0j52+ctlxa49krylPszdOGi1iuzU9yviUDJhS+rs5XZn8EgXJC7m09lzqPVnv+z6FjxciKzHC52ag64gK7TXt1nuSoQ+TpP1iWqqcwGI9j+X7McyUxxX/ULwPlk7KmhFE/p+rVZ+hvhz+gBHoZ/Ajf0ElEl/YiOdDPTLjkk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R821e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08151; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=6; RT=6; SR=0; Received: from 10.1.148.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.160) by smtp.aliyun-inc.com(127.0.0.1); Tue, 17 Mar 2015 14:22:35 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 17 Mar 2015 14:22:31 +0800 From: "Kepeng Li" To: "Morteza Ansari (moransar)" , Anthony Nadalin , Phil Hunt , Ian Glazer Message-ID: Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 References: <30CBC74A-73E9-413A-96AA-EE5E38720505@oracle.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3509446955_3540271" Archived-At: Cc: "scim@ietf.org" , Barry Leiba Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 06:22:55 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3509446955_3540271 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable >Document editors, can you please consider Barry=E2=80=99s feedback and suggest t= ext updates to the WG? Yes, will do. Thanks, Kind Regards Kepeng =E5=8F=91=E4=BB=B6=E4=BA=BA: "Morteza Ansari (moransar)" =E6=97=A5=E6=9C=9F: Tuesday, 17 March, 2015 6:20 am =E8=87=B3: Anthony Nadalin , Phil Hunt , Ian Glazer =E6=8A=84=E9=80=81: "scim@ietf.org" , Barry Leiba =E4=B8=BB=E9=A2=98: Re: [scim] AD review of draft-ietf-scim-use-cases-04 Sounds like there is WG interest in publishing this as an Informational RFC= . Document editors, can you please consider Barry=E2=80=99s feedback and suggest te= xt updates to the WG? Cheers, Morteza From: Anthony Nadalin Date: Saturday, March 14, 2015 at 5:55 PM To: Phil Hunt , Ian Glazer Cc: "scim@ietf.org" , "Barry org>" = , Morteza Ansari Subject: RE: [scim] AD review of draft-ietf-scim-use-cases-04 Hmmm, the issue is that these need to stick around and be tied to the existing specifications and future specifications so folks understand the problems being solved, so I don=E2=80=99t support publishing on scimplecloud.info =20 From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, March 13, 2015 10:42 AM To: Ian Glazer Cc: scim@ietf.org; Barry Leiba; Morteza Ansari (moransar) Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 =20 +1. It has informed the development of the WG drafts but I am not sure it is needed as RFC. Phil On Mar 13, 2015, at 09:58, Ian Glazer wrote: >=20 > I don't have a strong opinion one way or another but lean slightly toward= s > publishing it on scimplecloud.info >=20 > =20 >=20 > On Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (moransar) > wrote: >> Thanks for the review Barry. >>=20 >> My comment as WG members and definitely not as Chair: >>=20 >> Do we really need to publish the use cases as an RFC, even if we modify = it >> to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I think the >> biggest value of the use cases doc was to the WG during development of t= he >> core spec, and now that the core spec are pretty much final or close to >> final its value for the most part is superseded by the core spec. >>=20 >> I certainly think it still has historical value helping someone new to >> SCIM understand why some decisions were made. It also could help with th= e >> overall overview of SCIM. However, I think there might be other >> potentially more suitable mechanisms for capture that as opposed to >> turning this into an Informational RFC. For example we could publish it = on >> =C2=B3simplecloud.info =C2=B2 site along with other >> implementation/testing/guide >> articles & presentations. >>=20 >> Thoughts? >>=20 >>=20 >> Cheers, >> Morteza >>=20 >>=20 >> On 3/12/15, 12:26 PM, "Barry Leiba" wrote: >>=20 >>> >I like this document, and I think it's about ready to go. I just have >>> >two issues I'd like to discuss with the editors and working group: >>> > >>> >1. I think the security considerations section is too brief, and would >>> >be better fleshed out a bit. There are going to be details that'll be >>> >left to the schema and api documents -- details that have to do with >>> >the schema and api, of course. But this document could and should >>> >talk about the general security considerations for what SCIM is doing. >>> >What are the general threats and privacy issues, and how do you expect >>> >them to be dealt with? Let the security considerations in this >>> >document form the basis on which the other documents with expand when >>> >the protocol details are in place. >>> > >>> >2. The IESG has been strongly questioning the value of publishing >>> >use-case documents as RFCs. The question is whether they really have >>> >archival value, or whether no one will read them in six months or so, >>> >when the protocols they informed have been published. Often, it would >>> >be better to publish collections of use cases and related discussion >>> >in the working group's wiki, rather than going for RFC publication. I >>> >very much support that questioning. But... >>> > >>> >This document is more than a use-cases document, and it sells itself >>> >short by burying that, by making the reader figure that out. It's >>> >really definitions and overview, flows, use cases, and requirements. >>> >As such, I think it *does* have value as an RFC. Let's not make the >>> >rest of the IESG wonder about that, and perhaps take a different view. >>> >I suggest you retitle the document something like this: >>> > >>> >OLD >>> >SCIM Use Cases >>> > >>> >NEW >>> >System for Cross-domain Identity Management (SCIM) Definitions, >>> >Overview, and Flows >>> > >>> >END >>> > >>> >(That also expands SCIM, which the RFC Editor will insist on, so you >>> >might as well do it now.) >>> > >>> >Then for the abstract: >>> > >>> >OLD >>> > This document lists the user scenarios and use cases of System for >>> > Cross-domain Identity Management (SCIM). >>> > >>> >NEW >>> > This document provides definitions and an overview of the System >>> > for Cross-domain Identity Management (SCIM). It lays out the >>> > system's modes and flows, and includes user scenarios, use cases, >>> > and requirements. >>> > >>> >END >>> > >>> >And then tweak the Introduction accordingly. >>> > >>> >Do those points sound reasonable? >>> >(I will put the document into "AD Evaluation: Revised I-D Needed" stat= e.) >>> > >>> >Barry >>> > >>> >_______________________________________________ >>> >scim mailing list >>> >scim@ietf.org >>> >https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > =20 > --=20 >=20 > Ian Glazer >=20 > Senior Director, Identity >=20 > +1 202 255 3166 >=20 > @iglazer >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --B_3509446955_3540271 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
>Document editors, can you please consider Barry’= s feedback and suggest text updates to the WG?

Yes, will do.

Thanks,

Kind Regards
Kepeng

=E5=8F=91=E4=BB=B6=E4=BA=BA: "Morteza Ansari (moransar)" <moransar@cisco.com>
=E6=97=A5=E6=9C=9F: Tuesday, 17 March, 2015 6:20 am
=E8=87=B3: Anthony Nadalin <tonynad@microsoft.com>, Phil Hunt <phil.hunt@oracle.com>, Ian Glazer <iglazer@salesforce.com>
=E6=8A=84=E9=80=81: "scim@ietf.org" = <scim@ietf.org>, Barry Leiba <barryleiba@computer.org>
=E4=B8=BB=E9=A2=98: Re: [scim] AD review of draft-i= etf-scim-use-cases-04

Sounds = like there is WG interest in publishing this as an Informational RFC.
<= div>
Document editors, can you please consider Barry’s f= eedback and suggest text updates to the WG?


Cheers,
Morteza

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Saturday, March 14, 2015 at 5:55 PM
To:= Phil Hunt <phil.hunt@oracle= .com>, Ian Glazer <iglazer= @salesforce.com>
Cc: "scim@ietf.org" <scim@ietf.org>, "Barry org>" <barryleiba@computer.org>, Morteza Ansari <moransar@cisco.com>
Subject: RE: [scim] AD review of draft-ietf-scim-use-cases-04=

Hmmm, the i= ssue is that these need to stick around and be tied to the existing specific= ations and future specifications so folks understand the problems being solved, so I don’t support publishing on scimplecloud.info

 

From:<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;"> scim [mailto:scim-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, March 13, 2015 10:42 = AM
To: Ian Glazer
Cc: sci= m@ietf.org; Barry Leiba; Morteza Ansari (moransar)
Subject: Re= : [scim] AD review of draft-ietf-scim-use-cases-04

 

= +1.  It has informed the development of the WG drafts but I am not sure= it is needed as RFC.

Phil


On Mar 13, 2015, at 09:58, Ian Glazer <iglazer@salesforce.com> wrote:

I don't have a strong opinion one way or another but lean slightly towards = publishing it on scimplecloud.info

 

O= n Fri, Mar 13, 2015 at 12:36 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

Thanks for the review Barry.

My comment as WG members and definitely not as Chair:

Do we really need to publish the use cases as an RFC, even if we modify it<= br> to =C2=B3definitions, overview, and flows=C2=B2 as Barry suggested? I think the
= biggest value of the use cases doc was to the WG during development of the<= br> core spec, and now that the core spec are pretty much final or close to
= final its value for the most part is superseded by the core spec.

I certainly think it still has historical value helping someone new to
SCIM understand why some decisions were made. It also could help with the overall overview of SCIM. However, I think there might be other
potentially more suitable mechanisms for capture that as opposed to
turning this into an Informational RFC. For example we could publish it on<= br> =C2=B3simplecloud.info=C2=B2 = site along with other implementation/testing/guide
articles & presentations.

Thoughts?


Cheers,
Morteza


On 3/12/15, 12:26 PM, "Barry Leiba" <barryleiba@computer.org> wrote:

>I like this document, and I think it's about ready to go.  I just = have
>two issues I'd like to discuss with the editors and working group:
>
>1. I think the security considerations section is too brief, and would<= br> >be better fleshed out a bit.  There are going to be details that'l= l be
>left to the schema and api documents -- details that have to do with >the schema and api, of course.  But this document could and should=
>talk about the general security considerations for what SCIM is doing.<= br> >What are the general threats and privacy issues, and how do you expect<= br> >them to be dealt with?  Let the security considerations in this >document form the basis on which the other documents with expand when >the protocol details are in place.
>
>2. The IESG has been strongly questioning the value of publishing
>use-case documents as RFCs.  The question is whether they really h= ave
>archival value, or whether no one will read them in six months or so, >when the protocols they informed have been published.  Often, it w= ould
>be better to publish collections of use cases and related discussion >in the working group's wiki, rather than going for RFC publication.&nbs= p; I
>very much support that questioning.  But...
>
>This document is more than a use-cases document, and it sells itself >short by burying that, by making the reader figure that out.  It's=
>really definitions and overview, flows, use cases, and requirements. >As such, I think it *does* have value as an RFC.  Let's not make t= he
>rest of the IESG wonder about that, and perhaps take a different view.<= br> >I suggest you retitle the document something like this:
>
>OLD
>SCIM Use Cases
>
>NEW
>System for Cross-domain Identity Management (SCIM) Definitions,
>Overview, and Flows
>
>END
>
>(That also expands SCIM, which the RFC Editor will insist on, so you >might as well do it now.)
>
>Then for the abstract:
>
>OLD
>   This document lists the user scenarios and use cases of Sy= stem for
>   Cross-domain Identity Management (SCIM).
>
>NEW
>   This document provides definitions and an overview of the = System
>   for Cross-domain Identity Management (SCIM).  It lays= out the
>   system's modes and flows, and includes user scenarios, use= cases,
>   and requirements.
>
>END
>
>And then tweak the Introduction accordingly.
>
>Do those points sound reasonable?
>(I will put the document into "AD Evaluation: Revised I-D Needed" state= .)
>
>Barry
>
>_______________________________________________
>scim mailing list
>scim@ietf.org
>ht= tps://www.ietf.org/mailman/listinfo/scim

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



 

-- <= /p>

Ian Glazer

<= p class=3D"MsoNormal">Senior Director, Identity

+1 202 255 3166

___________________= ____________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mail= man/listinfo/scim

_______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/m= ailman/listinfo/scim --B_3509446955_3540271-- From nobody Tue Mar 17 00:12:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F7D1A00DB for ; Tue, 17 Mar 2015 00:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 wov_y9rhf_Eh for ; Tue, 17 Mar 2015 00:11:52 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 26D561A00D6 for ; Tue, 17 Mar 2015 00:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426576307; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=EEH/PuzjFJFh0t1F/zEKlykcyIyOcW5DKZh3ZIL2q5M=; b=mHPLqBU74BKlB3hqLlU/tJsrSRS0ublK5y745MNMtKk4Nj/YzaPeJcn1sPmCRRKmGFSUyfDlYtpxLAVoFZWsxIabF59s+bmXV7hTbZL6PuvlRMqWg6cvDfjWXF9/ytPoDb5svkOWncHgBYCvLrcdW5b0PgAu36wIJHzOh5DkSg0= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02008; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.148.174(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.183) by smtp.aliyun-inc.com(127.0.0.1); Tue, 17 Mar 2015 15:11:39 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 17 Mar 2015 15:11:31 +0800 From: "Kepeng Li" To: Barry Leiba , "scim@ietf.org" Message-ID: Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3509449899_3711030" Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 07:11:54 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3509449899_3711030 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable > I think the security considerations section is too brief, and would be better fleshed out a bit. How about this: OLD: SCIM resources (e.g., Users and Groups) can contain sensitive information. Therefore, authentication and authorization must be guaranteed for the SCIM operations. Also, private information of the SCIM resources must be kept confidential and protected. NEW: Authentication and authorization must be guaranteed for the SCIM operations. Because SCIM builds on the Hypertext Transfer Protocol and thus subject to the security considerations of HTTP Section 9 [RFC7230] and its relate= d specifications. SCIM depends on standard HTTP authentication schemes. Implementers SHOUL= D support existing authentication/authorization schemes. In particular, OAuth2 (see [RFC6749 ], [RFC6750 ]) is RECOMMENDED. Appropriate security considerations of the selected authentication and authorization schemes SHOULD be taken. SCIM resources (e.g., Users and Groups) can contain sensitive information. Thus, data confidentiality MUST be guaranteed at the transport layer. TLS MUST be implemented by SCIM clients and service providers. TLS version 1.0 [RFC5246 ] or TLS version 1.2 [RFC5246 ] can be chosen depending on the widespread deployment and known security vulnerabilities at the time of implementation.=20 The SCIM attributes MAY contain personally identifiable information as well as other sensitive data. Thus private information of the SCIM resources MUST be protected. Industry best practices SHOULD be undertaken to protect the storage of credentials and in particular SHOULD follow recommendations outlines in Section 5.1.4.1 [RFC6819] . END In the new text, we talked about authentication, authorization, data confidentiality, privacy protection. Then the details about how to achieve that can be specified in API spec and Schema spec. Comments or suggestions are welcome. Thanks, Kind Regards Kepeng =D4=DA 13/3/15 3:26 am=A3=AC "Barry Leiba" =D0=B4=C8=EB: > I like this document, and I think it's about ready to go. I just have > two issues I'd like to discuss with the editors and working group: >=20 > 1. I think the security considerations section is too brief, and would > be better fleshed out a bit. There are going to be details that'll be > left to the schema and api documents -- details that have to do with > the schema and api, of course. But this document could and should > talk about the general security considerations for what SCIM is doing. > What are the general threats and privacy issues, and how do you expect > them to be dealt with? Let the security considerations in this > document form the basis on which the other documents with expand when > the protocol details are in place. >=20 > 2. The IESG has been strongly questioning the value of publishing > use-case documents as RFCs. The question is whether they really have > archival value, or whether no one will read them in six months or so, > when the protocols they informed have been published. Often, it would > be better to publish collections of use cases and related discussion > in the working group's wiki, rather than going for RFC publication. I > very much support that questioning. But... >=20 > This document is more than a use-cases document, and it sells itself > short by burying that, by making the reader figure that out. It's > really definitions and overview, flows, use cases, and requirements. > As such, I think it *does* have value as an RFC. Let's not make the > rest of the IESG wonder about that, and perhaps take a different view. > I suggest you retitle the document something like this: >=20 > OLD > SCIM Use Cases >=20 > NEW > System for Cross-domain Identity Management (SCIM) Definitions, > Overview, and Flows >=20 > END >=20 > (That also expands SCIM, which the RFC Editor will insist on, so you > might as well do it now.) >=20 > Then for the abstract: >=20 > OLD > This document lists the user scenarios and use cases of System for > Cross-domain Identity Management (SCIM). >=20 > NEW > This document provides definitions and an overview of the System > for Cross-domain Identity Management (SCIM). It lays out the > system's modes and flows, and includes user scenarios, use cases, > and requirements. >=20 > END >=20 > And then tweak the Introduction accordingly. >=20 > Do those points sound reasonable? > (I will put the document into "AD Evaluation: Revised I-D Needed" state.) >=20 > Barry >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 --B_3509449899_3711030 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
> I t= hink the security considerations section is too brief, and would
be better fleshed out a bit. 
<= div>

How about this:

OLD:

=

   SCIM resources (e.g., Users and Gr=
oups) can contain sensitive
   information.  Therefore, authentication and authorization must be
   guaranteed for the SCIM operations.

   Also, private information of the SCIM resources must be kept
   confidential and protected.

NEW:

   Authentication and authori=
zation must be
   guaranteed for the SCIM operations.
   Because SCIM builds on the Hypertext Transfer Protocol and
   thus subject to the security considerations of HTTP Section 9
   [RFC7230] and its related specifications.

   SCIM depends on standard HTTP authenti=
cation schemes. Implementers SHOULD support
   existing authentication/authorization schemes.  In particular, OAuth2
   (see [RFC6749], [RFC6750]) is RECOMMENDED.  Appropriate security
   considerations of the selected authentication and authorization
   schemes SHOULD be taken.  

=

   SCIM resources (e.g., Users and Groups) can contain s=
ensitive
   information. Thus, =
data confidentiality MUST be guaranteed at the=
 transport layer.
   TLS MUST be implemented by SCIM clients and servi=
ce providers.  
   TLS version 1.=
0 [RFC5246] or TLS version 1.2 [RFC5246=
] can be chosen depending on
   the widespread deployment and known security =
vulnerabilities at the time of implemen=
tation. 


   The SCIM attributes MAY co=
ntain personally
   identifiable information as well as other sensitive data.  
   Thus private information of the SCIM resou=
rces MUST be protected.

  =
; Industry best practices SHOULD be und=
ertaken to protect
   the stora=
ge of credentials and in particular SHOULD follow

   rec=
ommendations outlines in Section 5.1.4.1 [RFC6819]<=
span style=3D"font-size: 1em;">.

END

In = the new text, we talked about authentication, authorization, data confidenti= ality, privacy protection. 
Then the details about how to achieve that can be specified in API spe= c and Schema spec.

Comments or suggestions are we= lcome.

Thanks,

Kind Re= gards
Kepeng

=D4=DA 13/3/15 3:26 am=A3=AC "Barry Leiba" <barryleiba@computer.org> =D0=B4=C8=EB:

I like this document, and I think it's a= bout ready to go.  I just have
two issues I'd like to discuss with the editor= s and working group:

1. I think the security considerations section is too brief, and would
be better fl= eshed out a bit.  There are going to be details that'll be
left to the schema= and api documents -- details that have to do with
the schema and api, of course. =  But this document could and should
talk about the general security considerations= for what SCIM is doing.
What are the general threats and privacy issues, and how do yo= u expect
th= em to be dealt with?  Let the security considerations in this
document form t= he basis on which the other documents with expand when
the protocol details are in plac= e.

2. The IESG ha= s been strongly questioning the value of publishing
use-case documents as RFCs. &n= bsp;The question is whether they really have
archival value, or whether no one will rea= d them in six months or so,
when the protocols they informed have been published. =  Often, it would
be better to publish collections of use cases and related discuss= ion
in the = working group's wiki, rather than going for RFC publication.  I
very much sup= port that questioning.  But...

This document is more than a use-cases document, and= it sells itself
short by burying that, by making the reader figure that out. &nbs= p;It's
real= ly definitions and overview, flows, use cases, and requirements.
As such, I think it *d= oes* have value as an RFC.  Let's not make the
rest of the IESG wonder about = that, and perhaps take a different view.
I suggest you retitle the document something l= ike this:
<= br>
OLD
SCIM Use Cases=

=
NEW
System for Cross-domain= Identity Management (SCIM) Definitions,
Overview, and Flows

END

(That also expands SCIM, which the RFC Editor will insis= t on, so you

Then for the abstract:

OLD
   This document lists the user scenarios and use cases = of System for
   Cross-domain Identity Management (SCIM).

NEW
   This document provides definit= ions and an overview of the System
   for Cross-domain Identity Management (S= CIM).  It lays out the
   system's modes and flows, and includes us= er scenarios, use cases,
   and requirements.

END

And then tweak the Introduction accordingly.

Do those points sound reasonable?=
(I will pu= t the document into "AD Evaluation: Revised I-D Needed" state.)

Barry

________________________________________= _______
sci= m mailing list
=
--B_3509449899_3711030-- From nobody Tue Mar 17 03:53:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EE61A0263 for ; Tue, 17 Mar 2015 03:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 JLQwalN_31W5 for ; Tue, 17 Mar 2015 03:53:29 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AB31A0195 for ; Tue, 17 Mar 2015 03:53:28 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so3982130lbc.3 for ; Tue, 17 Mar 2015 03:53:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7W6K+t/dM8BEuOS5ruayOSUfAy/pW4CbDS7ZZdMoLeg=; b=KQRmYPNya8Qt9obuWtTRnBLCbnLGsvZcKWBiVtDbztTI1rAflF+bzkSWiJqe0/x7zJ txlvWmj5cOvII03Dag0I8YUa3Pz8R2GouJuoIQWmnnkpUmi8Ha3DqcXbjjUoBIrnyWUO hcWB6cQb9xyV5EzaDoizJdCF2k6bqiIB7lUqzqipZ51TCuLhepGQuMUC55sAZTr16eIh TWVlhmQD3LDHN/8yVeGJDIMgpSavpe4FVC/DZrlrE/+muO5FGVYPRaA8JegafWVVb56N MKvyXvtU8X8zJtpRKvM15KOHTp/i2STTNhAE+yfI502JR+3p8pFMcX8b9N6T8N1RkoQd 7XXA== X-Gm-Message-State: ALoCoQluyMtbEpzyApPHXKyxKsNjUWiG8VqQ9fGdpBNA6g4J0QFR5MBOQ53EinHxj06PwhRUq2f2 X-Received: by 10.152.234.108 with SMTP id ud12mr39692281lac.81.1426589607143; Tue, 17 Mar 2015 03:53:27 -0700 (PDT) Received: from [109.105.104.214] (dhcp79.se-tug.nordu.net. [109.105.104.214]) by mx.google.com with ESMTPSA id lf1sm2724158lab.42.2015.03.17.03.53.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 03:53:26 -0700 (PDT) Message-ID: <550807A5.90506@mnt.se> Date: Tue, 17 Mar 2015 11:53:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [scim] schema and api drafts submitted to IESG X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:53:30 -0000 A major milestone for us. See you all in Dallas! Cheers Leif & Morteza From nobody Tue Mar 17 05:32:59 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635B81A008A for ; Tue, 17 Mar 2015 05:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ki4j9LDLaIis for ; Tue, 17 Mar 2015 05:32:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B020C1A012D for ; Tue, 17 Mar 2015 05:32:43 -0700 (PDT) Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (25.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 17 Mar 2015 12:32:24 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0112.000; Tue, 17 Mar 2015 12:32:23 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] schema and api drafts submitted to IESG Thread-Index: AQHQYKCf07bygm65Tk25sdkuPeas0Z0gm5Xa Date: Tue, 17 Mar 2015 12:32:23 +0000 Message-ID: References: <550807A5.90506@mnt.se> In-Reply-To: <550807A5.90506@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.170.54.178] authentication-results: mnt.se; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(40100003)(122556002)(16236675004)(66066001)(2656002)(87936001)(19625215002)(33656002)(92566002)(76576001)(86612001)(2900100001)(2950100001)(74316001)(76176999)(54356999)(50986999)(102836002)(99286002)(77156002)(15975445007)(19617315012)(106116001)(62966003)(107886001)(19580395003)(19580405001)(2501003)(46102003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 0518EEFB48 Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234760375A36602433E5432A6030BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2015 12:32:23.7051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Subject: Re: [scim] schema and api drafts submitted to IESG X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:32:48 -0000 --_000_BN3PR0301MB1234760375A36602433E5432A6030BN3PR0301MB1234_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Finally ! Sent from my Windows Phone ________________________________ From: Leif Johansson Sent: =FD3/=FD17/=FD2015 11:53 AM To: scim@ietf.org Subject: [scim] schema and api drafts submitted to IESG A major milestone for us. See you all in Dallas! Cheers Leif & Morteza _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_BN3PR0301MB1234760375A36602433E5432A6030BN3PR0301MB1234_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Finally !

Sent from my Windows Phone
From: Leif Johansson
Sent: =FD3/= =FD17/=FD2015 11:53 AM
To: scim@ietf.org
Subject: [scim= ] schema and api drafts submitted to IESG


A major milestone for us. See you all in Dallas!

        Cheers Leif & Morteza

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim
 --_000_BN3PR0301MB1234760375A36602433E5432A6030BN3PR0301MB1234_-- From nobody Thu Mar 19 10:04:37 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5629D1A1EFF for ; Thu, 19 Mar 2015 10:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.529 X-Spam-Level: X-Spam-Status: No, score=-13.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 U3dke-FLcKiw for ; Thu, 19 Mar 2015 10:04:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E720B1A6EEC for ; Thu, 19 Mar 2015 10:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30918; q=dns/txt; s=iport; t=1426784658; x=1427994258; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xhgSNqs7mimqLG4P9Jo1BFF37xbEqUfsipBZSFfhc7k=; b=JyJb1joDVT8Z1XTuDmidYdRVqTrZmmgxr/VwWXGSQOrieMvxy48bRYsU chOI4XL0dp4q1sks8kmi2v5Or7Xb3Xkz8GtzJSE1US0ysDUw4demyrLTl VnpArBW/J+fP1j1cIoC8mNwEtX7YLYHJyMzs9kNCw5cgzPQP9hipwxDtX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ChCgBlAAtV/5RdJa1TCYJDQ1JaBIMJwF88gXQBCYV1AhyBMEwBAQEBAQF9hA8BAQEDAQEBASBLEAsCAQYCEQMBAiEHAwICAiULFAkIAgQBCQmIJwgNlSycdpwBAQEBAQYBAQEBAR2KGH+EFhI4DQuCaIFFBY47gg6DboV/gRs6gnaCWYk9g0cig25vAQEBgQBBfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208,217";a="405015438" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 19 Mar 2015 17:04:17 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2JH4Gi2023481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:04:16 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:04:16 -0500 From: "Morteza Ansari (moransar)" To: Kepeng Li , Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Thread-Index: AQHQYIGX14ndZd68F0WH+7QX3QdDep0j6ukA Date: Thu, 19 Mar 2015 17:04:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.189.203] Content-Type: multipart/alternative; boundary="_000_D1304F451209DCmoransarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:04:35 -0000 --_000_D1304F451209DCmoransarciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEtlcGVuZy4gIFdHLCBwbGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRiYWNrL3Rob3VnaHRz IG9uIHRoZSBzdWdnZXN0ZWQgdGV4dC4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQoNCkZyb206IEtl cGVuZyBMaSA8a2VwZW5nLmxrcEBhbGliYWJhLWluYy5jb208bWFpbHRvOmtlcGVuZy5sa3BAYWxp YmFiYS1pbmMuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDE1IGF0IDEyOjExIEFN DQpUbzogIkJhcnJ5IG9yZz4iIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzxtYWlsdG86YmFycnls ZWliYUBjb21wdXRlci5vcmc+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+ IiA8c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Nj aW1dIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXNjaW0tdXNlLWNhc2VzLTA0DQoNCj4gSSB0aGlu ayB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0b28gYnJpZWYsIGFuZCB3 b3VsZA0KYmUgYmV0dGVyIGZsZXNoZWQgb3V0IGEgYml0Lg0KDQpIb3cgYWJvdXQgdGhpczoNCg0K DQpPTEQ6DQoNCg0KICAgU0NJTSByZXNvdXJjZXMgKGUuZy4sIFVzZXJzIGFuZCBHcm91cHMpIGNh biBjb250YWluIHNlbnNpdGl2ZQ0KICAgaW5mb3JtYXRpb24uICBUaGVyZWZvcmUsIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG11c3QgYmUNCiAgIGd1YXJhbnRlZWQgZm9yIHRoZSBT Q0lNIG9wZXJhdGlvbnMuDQoNCiAgIEFsc28sIHByaXZhdGUgaW5mb3JtYXRpb24gb2YgdGhlIFND SU0gcmVzb3VyY2VzIG11c3QgYmUga2VwdA0KICAgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQu DQoNCg0KTkVXOg0KDQoNCiAgIEF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG11c3Qg YmUNCiAgIGd1YXJhbnRlZWQgZm9yIHRoZSBTQ0lNIG9wZXJhdGlvbnMuDQoNCiAgIEJlY2F1c2Ug U0NJTSBidWlsZHMgb24gdGhlIEh5cGVydGV4dCBUcmFuc2ZlciBQcm90b2NvbCBhbmQNCg0KICAg dGh1cyBzdWJqZWN0IHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiBIVFRQIFNlY3Rp b24gOQ0KICAgW1JGQzcyMzBdPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzAjc2Vj dGlvbi05PiBhbmQgaXRzIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbnMuDQoNCg0KICAgU0NJTSBkZXBl bmRzIG9uIHN0YW5kYXJkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcy4gSW1wbGVtZW50ZXJz IFNIT1VMRCBzdXBwb3J0DQogICBleGlzdGluZyBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9u IHNjaGVtZXMuICBJbiBwYXJ0aWN1bGFyLCBPQXV0aDINCiAgIChzZWUgW1JGQzY3NDk8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT5dLCBbUkZDNjc1MDxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2NzUwPl0pIGlzIFJFQ09NTUVOREVELiAgQXBwcm9wcmlhdGUgc2VjdXJp dHkNCiAgIGNvbnNpZGVyYXRpb25zIG9mIHRoZSBzZWxlY3RlZCBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbg0KICAgc2NoZW1lcyBTSE9VTEQgYmUgdGFrZW4uDQoNCg0KICAgU0NJTSBy ZXNvdXJjZXMgKGUuZy4sIFVzZXJzIGFuZCBHcm91cHMpIGNhbiBjb250YWluIHNlbnNpdGl2ZQ0K DQogICBpbmZvcm1hdGlvbi4gVGh1cywgZGF0YSBjb25maWRlbnRpYWxpdHkgTVVTVCBiZSBndWFy YW50ZWVkIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQoNCiAgIFRMUyBNVVNUIGJlIGltcGxlbWVu dGVkIGJ5IFNDSU0gY2xpZW50cyBhbmQgc2VydmljZSBwcm92aWRlcnMuDQoNCiAgIFRMUyB2ZXJz aW9uIDEuMCBbUkZDNTI0NjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2Pl0gb3Ig VExTIHZlcnNpb24gMS4yIFtSRkM1MjQ2PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUy NDY+XSBjYW4gYmUgY2hvc2VuIGRlcGVuZGluZyBvbg0KDQogICB0aGUgd2lkZXNwcmVhZCBkZXBs b3ltZW50IGFuZCBrbm93biBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgYXQgdGhlIHRpbWUgb2Yg aW1wbGVtZW50YXRpb24uDQoNCiAgIFRoZSBTQ0lNIGF0dHJpYnV0ZXMgTUFZIGNvbnRhaW4gcGVy c29uYWxseQ0KICAgaWRlbnRpZmlhYmxlIGluZm9ybWF0aW9uIGFzIHdlbGwgYXMgb3RoZXIgc2Vu c2l0aXZlIGRhdGEuDQoNCiAgIFRodXMgcHJpdmF0ZSBpbmZvcm1hdGlvbiBvZiB0aGUgU0NJTSBy ZXNvdXJjZXMgTVVTVCBiZSBwcm90ZWN0ZWQuDQoNCg0KICAgSW5kdXN0cnkgYmVzdCBwcmFjdGlj ZXMgU0hPVUxEIGJlIHVuZGVydGFrZW4gdG8gcHJvdGVjdA0KDQogICB0aGUgc3RvcmFnZSBvZiBj cmVkZW50aWFscyBhbmQgaW4gcGFydGljdWxhciBTSE9VTEQgZm9sbG93DQoNCg0KICAgcmVjb21t ZW5kYXRpb25zIG91dGxpbmVzIGluIFNlY3Rpb24gNS4xLjQuMSBbUkZDNjgxOV08aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjgxOSNzZWN0aW9uLTUuMS40LjE+Lg0KDQoNCkVORA0KDQpJ biB0aGUgbmV3IHRleHQsIHdlIHRhbGtlZCBhYm91dCBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXph dGlvbiwgZGF0YSBjb25maWRlbnRpYWxpdHksIHByaXZhY3kgcHJvdGVjdGlvbi4NClRoZW4gdGhl IGRldGFpbHMgYWJvdXQgaG93IHRvIGFjaGlldmUgdGhhdCBjYW4gYmUgc3BlY2lmaWVkIGluIEFQ SSBzcGVjIGFuZCBTY2hlbWEgc3BlYy4NCg0KQ29tbWVudHMgb3Igc3VnZ2VzdGlvbnMgYXJlIHdl bGNvbWUuDQoNClRoYW5rcywNCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K5ZyoIDEzLzMvMTUg MzoyNiBhbe+8jCAiQmFycnkgTGVpYmEiIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzxtYWlsdG86 YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiDlhpnlhaU6DQoNCkkgbGlrZSB0aGlzIGRvY3VtZW50 LCBhbmQgSSB0aGluayBpdCdzIGFib3V0IHJlYWR5IHRvIGdvLiAgSSBqdXN0IGhhdmUNCnR3byBp c3N1ZXMgSSdkIGxpa2UgdG8gZGlzY3VzcyB3aXRoIHRoZSBlZGl0b3JzIGFuZCB3b3JraW5nIGdy b3VwOg0KDQoxLiBJIHRoaW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlz IHRvbyBicmllZiwgYW5kIHdvdWxkDQpiZSBiZXR0ZXIgZmxlc2hlZCBvdXQgYSBiaXQuICBUaGVy ZSBhcmUgZ29pbmcgdG8gYmUgZGV0YWlscyB0aGF0J2xsIGJlDQpsZWZ0IHRvIHRoZSBzY2hlbWEg YW5kIGFwaSBkb2N1bWVudHMgLS0gZGV0YWlscyB0aGF0IGhhdmUgdG8gZG8gd2l0aA0KdGhlIHNj aGVtYSBhbmQgYXBpLCBvZiBjb3Vyc2UuICBCdXQgdGhpcyBkb2N1bWVudCBjb3VsZCBhbmQgc2hv dWxkDQp0YWxrIGFib3V0IHRoZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB3 aGF0IFNDSU0gaXMgZG9pbmcuDQpXaGF0IGFyZSB0aGUgZ2VuZXJhbCB0aHJlYXRzIGFuZCBwcml2 YWN5IGlzc3VlcywgYW5kIGhvdyBkbyB5b3UgZXhwZWN0DQp0aGVtIHRvIGJlIGRlYWx0IHdpdGg/ ICBMZXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoaXMNCmRvY3VtZW50IGZvcm0g dGhlIGJhc2lzIG9uIHdoaWNoIHRoZSBvdGhlciBkb2N1bWVudHMgd2l0aCBleHBhbmQgd2hlbg0K dGhlIHByb3RvY29sIGRldGFpbHMgYXJlIGluIHBsYWNlLg0KDQoyLiBUaGUgSUVTRyBoYXMgYmVl biBzdHJvbmdseSBxdWVzdGlvbmluZyB0aGUgdmFsdWUgb2YgcHVibGlzaGluZw0KdXNlLWNhc2Ug ZG9jdW1lbnRzIGFzIFJGQ3MuICBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGV5IHJlYWxseSBo YXZlDQphcmNoaXZhbCB2YWx1ZSwgb3Igd2hldGhlciBubyBvbmUgd2lsbCByZWFkIHRoZW0gaW4g c2l4IG1vbnRocyBvciBzbywNCndoZW4gdGhlIHByb3RvY29scyB0aGV5IGluZm9ybWVkIGhhdmUg YmVlbiBwdWJsaXNoZWQuICBPZnRlbiwgaXQgd291bGQNCmJlIGJldHRlciB0byBwdWJsaXNoIGNv bGxlY3Rpb25zIG9mIHVzZSBjYXNlcyBhbmQgcmVsYXRlZCBkaXNjdXNzaW9uDQppbiB0aGUgd29y a2luZyBncm91cCdzIHdpa2ksIHJhdGhlciB0aGFuIGdvaW5nIGZvciBSRkMgcHVibGljYXRpb24u ICBJDQp2ZXJ5IG11Y2ggc3VwcG9ydCB0aGF0IHF1ZXN0aW9uaW5nLiAgQnV0Li4uDQoNClRoaXMg ZG9jdW1lbnQgaXMgbW9yZSB0aGFuIGEgdXNlLWNhc2VzIGRvY3VtZW50LCBhbmQgaXQgc2VsbHMg aXRzZWxmDQpzaG9ydCBieSBidXJ5aW5nIHRoYXQsIGJ5IG1ha2luZyB0aGUgcmVhZGVyIGZpZ3Vy ZSB0aGF0IG91dC4gIEl0J3MNCnJlYWxseSBkZWZpbml0aW9ucyBhbmQgb3ZlcnZpZXcsIGZsb3dz LCB1c2UgY2FzZXMsIGFuZCByZXF1aXJlbWVudHMuDQpBcyBzdWNoLCBJIHRoaW5rIGl0ICpkb2Vz KiBoYXZlIHZhbHVlIGFzIGFuIFJGQy4gIExldCdzIG5vdCBtYWtlIHRoZQ0KcmVzdCBvZiB0aGUg SUVTRyB3b25kZXIgYWJvdXQgdGhhdCwgYW5kIHBlcmhhcHMgdGFrZSBhIGRpZmZlcmVudCB2aWV3 Lg0KSSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVudCBzb21ldGhpbmcgbGlrZSB0aGlz Og0KDQpPTEQNClNDSU0gVXNlIENhc2VzDQoNCk5FVw0KU3lzdGVtIGZvciBDcm9zcy1kb21haW4g SWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgRGVmaW5pdGlvbnMsDQpPdmVydmlldywgYW5kIEZs b3dzDQoNCkVORA0KDQooVGhhdCBhbHNvIGV4cGFuZHMgU0NJTSwgd2hpY2ggdGhlIFJGQyBFZGl0 b3Igd2lsbCBpbnNpc3Qgb24sIHNvIHlvdQ0KbWlnaHQgYXMgd2VsbCBkbyBpdCBub3cuKQ0KDQpU aGVuIGZvciB0aGUgYWJzdHJhY3Q6DQoNCk9MRA0KICAgVGhpcyBkb2N1bWVudCBsaXN0cyB0aGUg dXNlciBzY2VuYXJpb3MgYW5kIHVzZSBjYXNlcyBvZiBTeXN0ZW0gZm9yDQogICBDcm9zcy1kb21h aW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkuDQoNCk5FVw0KICAgVGhpcyBkb2N1bWVudCBw cm92aWRlcyBkZWZpbml0aW9ucyBhbmQgYW4gb3ZlcnZpZXcgb2YgdGhlIFN5c3RlbQ0KICAgZm9y IENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKS4gIEl0IGxheXMgb3V0IHRo ZQ0KICAgc3lzdGVtJ3MgbW9kZXMgYW5kIGZsb3dzLCBhbmQgaW5jbHVkZXMgdXNlciBzY2VuYXJp b3MsIHVzZSBjYXNlcywNCiAgIGFuZCByZXF1aXJlbWVudHMuDQoNCkVORA0KDQpBbmQgdGhlbiB0 d2VhayB0aGUgSW50cm9kdWN0aW9uIGFjY29yZGluZ2x5Lg0KDQpEbyB0aG9zZSBwb2ludHMgc291 bmQgcmVhc29uYWJsZT8NCihJIHdpbGwgcHV0IHRoZSBkb2N1bWVudCBpbnRvICJBRCBFdmFsdWF0 aW9uOiBSZXZpc2VkIEktRCBOZWVkZWQiIHN0YXRlLikNCg0KQmFycnkNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpz Y2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_D1304F451209DCmoransarciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8C412B723DF60249BCA93DE8643B1E4D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGFua3MgS2Vw ZW5nLiAmbmJzcDtXRywgcGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFjay90aG91Z2h0cyBvbiB0 aGUgc3VnZ2VzdGVkIHRleHQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2Pg0KPGRpdj5Nb3J0ZXphPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPktlcGVuZyBMaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlcGVuZy5sa3BA YWxpYmFiYS1pbmMuY29tIj5rZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJj aCAxNywgMjAxNSBhdCAxMjoxMSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPiZxdW90O0JhcnJ5IG9yZyZndDsmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZyI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bh bj5SZTogW3NjaW1dIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXNjaW0tdXNlLWNhc2VzLTA0PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiDlrovkvZMsIHNhbnMtc2VyaWY7Ij4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiDlrovkvZMsIHNhbnMtc2VyaWY7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IOWu i+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij4mZ3Q7IEkgdGhpbmsgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgdG9vIGJyaWVmLCBhbmQgd291bGQ8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJw eDsiPmJlIGJldHRlciBmbGVzaGVkIG91dCBhIGJpdC4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48 Zm9udCBmYWNlPSLlrovkvZMsc2Fucy1zZXJpZiI+PC9mb250PkhvdyBhYm91dCB0aGlzOjwvcHJl Pg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9w OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxi cj48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdh eXM7Ij5PTEQ6PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAx ZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9y ZTogYWx3YXlzOyI+PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQt c2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsiPiAgIFNDSU0gcmVzb3VyY2VzIChlLmcuLCBVc2VycyBhbmQgR3Jv dXBzKSBjYW4gY29udGFpbiBzZW5zaXRpdmUNCiAgIGluZm9ybWF0aW9uLiAgVGhlcmVmb3JlLCBh dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtdXN0IGJlDQogICBndWFyYW50ZWVkIGZv ciB0aGUgU0NJTSBvcGVyYXRpb25zLg0KDQogICBBbHNvLCBwcml2YXRlIGluZm9ybWF0aW9uIG9m IHRoZSBTQ0lNIHJlc291cmNlcyBtdXN0IGJlIGtlcHQNCiAgIGNvbmZpZGVudGlhbCBhbmQgcHJv dGVjdGVkLjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVt OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6 IGFsd2F5czsiPjxicj48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNp emU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWst YmVmb3JlOiBhbHdheXM7Ij5ORVc6PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0i Zm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIg c3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiAgIEF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIG11c3QgYmUNCiAgIGd1YXJhbnRlZWQgZm9yIHRoZSBTQ0lNIG9wZXJhdGlvbnMu PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+PGZvbnQgZmFjZT0iQ291cmllciI+ICAgQmVjYXVzZSBTQ0lNIGJ1aWxkcyBvbiB0aGUmbmJz cDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07Ij5IeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9j b2wgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiPmFuZDwvc3Bhbj48L2ZvbnQ+ PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+PGZvbnQgZmFjZT0iQ291cmllciI+ICAgdGh1cyBzdWJqZWN0IHRvIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBvZiBIVFRQIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcyMzAjc2VjdGlvbi05Ij5TZWN0aW9uJm5ic3A7OQ0KICAgW1JGQzcyMzBdPC9hPiBhbmQg aXRzIHJlbGF0ZWQgc3BlY2lmaWNhdGlvbnMuPC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3 cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPjxmb250IGZhY2U9IkNvdXJpZXIi Pjxicj48L2ZvbnQ+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXpl OiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJl Zm9yZTogYWx3YXlzOyI+PGZvbnQgZmFjZT0iQ291cmllciI+ICAgU0NJTSBkZXBlbmRzIG9uIHN0 YW5kYXJkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcy4gSW1wbGVtZW50ZXJzIFNIT1VMRCBz dXBwb3J0DQogICBleGlzdGluZyBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHNjaGVtZXMu ICBJbiBwYXJ0aWN1bGFyLCBPQXV0aDINCiAgIChzZWUgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkiIHRpdGxlPSImcXVvdDtUaGUgT0F1dGggMi4wIEF1dGhvcml6 YXRpb24gRnJhbWV3b3JrJnF1b3Q7Ij5SRkM2NzQ5PC9hPl0sIFs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzUwIiB0aXRsZT0iJnF1b3Q7VGhlIE9BdXRoIDIuMCBBdXRo b3JpemF0aW9uIEZyYW1ld29yazogQmVhcmVyIFRva2VuIFVzYWdlJnF1b3Q7Ij5SRkM2NzUwPC9h Pl0pIGlzIFJFQ09NTUVOREVELiAgQXBwcm9wcmlhdGUgc2VjdXJpdHkNCiAgIGNvbnNpZGVyYXRp b25zIG9mIHRoZSBzZWxlY3RlZCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0KICAg c2NoZW1lcyBTSE9VTEQgYmUgdGFrZW4uICZuYnNwOzwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9 Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48Zm9udCBmYWNlPSJDb3Vy aWVyIj48YnI+PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQt c2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czsiPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6 IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVm b3JlOiBhbHdheXM7Ij48Zm9udCBmYWNlPSJDb3VyaWVyIj4gICZuYnNwOzwvZm9udD48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxZW07Ij5TQ0lNIHJlc291cmNlcyAoZS5nLiwgVXNlcnMgYW5kIEdy b3VwcykgY2FuIGNvbnRhaW4gc2Vuc2l0aXZlPC9zcGFuPjwvcHJlPjxwcmUgY2xhc3M9Im5ld3Bh Z2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij4gICBpbmZvcm1hdGlvbi4gVGh1cywg ZGF0YSBjb25maWRlbnRpYWxpdHkgTVVTVCBiZSA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07 Ij5ndWFyYW50ZWVkIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMWVtOyI+Ljwvc3Bhbj48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0i Zm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdl LWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ICAgVExTIE1VU1QgYmUgaW1wbGVtZW50ZWQgYnkgU0NJ TSBjbGllbnRzIGFuZCBzZXJ2aWNlIHByb3ZpZGVycy4gJm5ic3A7PC9wcmU+PHByZSBjbGFzcz0i bmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6IGFsd2F5czsiPiAgIFRMUyB2ZXJzaW9uIDEu MCBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NiIgdGl0bGU9IiZx dW90O1RoZSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAx LjImcXVvdDsiPlJGQzUyNDY8L2E+XSBvciA8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07Ij5U TFMgdmVyc2lvbiAxLjIgWzwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1MjQ2IiB0aXRsZT0iJnF1b3Q7VGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExT KSBQcm90b2NvbCBWZXJzaW9uIDEuMiZxdW90OyIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+UkZD NTI0NjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07Ij5dIGNhbiBiZSBjaG9zZW4gZGVw ZW5kaW5nIG9uPC9zcGFuPjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNp emU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWst YmVmb3JlOiBhbHdheXM7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07Ij4gICB0aGUgd2lk ZXNwcmVhZCBkZXBsb3ltZW50IGFuZCBrbm93biBzZWN1cml0eSA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMWVtOyI+dnVsbmVyYWJpbGl0aWVzIGF0IHRoZSB0aW1lIG9mIGltcGxlbWVu dGF0aW9uLiZuYnNwOzwvc3Bhbj48L3ByZT48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0 eWxlPSJmb250LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7 IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7Ij48Zm9udCBmYWNlPSJDb3VyaWVyIj48L2ZvbnQ+ PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlz OyI+ICAgVGhlIFNDSU0gYXR0cmlidXRlcyBNQVkgY29udGFpbiBwZXJzb25hbGx5DQogICBpZGVu dGlmaWFibGUgaW5mb3JtYXRpb24gYXMgd2VsbCBhcyBvdGhlciBzZW5zaXRpdmUgZGF0YS4gJm5i c3A7PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3 YXlzOyI+ICAgVGh1cyBwcml2YXRlIGluZm9ybWF0aW9uIG9mIHRoZSBTQ0lNIHJlc291cmNlcyBN VVNUIGJlIHByb3RlY3RlZC4NCjwvcHJlPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZv bnQtc2l6ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1i cmVhay1iZWZvcmU6IGFsd2F5czsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiPiAmbmJz cDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiPkluZHVzdHJ5IGJlc3QgcHJh Y3RpY2VzIFNIT1VMRCBiZSB1bmRlcnRha2VuIHRvIHByb3RlY3Q8L3NwYW4+PC9wcmU+DQo8cHJl IGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ICAgdGhlIHN0 b3JhZ2Ugb2YgY3JlZGVudGlhbHMgYW5kIGluIHBhcnRpY3VsYXIgU0hPVUxEIGZvbGxvdw0KPC9w cmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+ICAgcmVjb21tZW5kYXRpb25zIG91dGxpbmVz IGluIDwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODE5I3Nl Y3Rpb24tNS4xLjQuMSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+U2VjdGlvbiZuYnNwOzUuMS40 LjEgW1JGQzY4MTldPC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiPi4gPC9zcGFuPjxm b250IGZhY2U9IkNvdXJpZXIiPiAgIA0KPC9mb250PjwvcHJlPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+RU5EPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+SW4gdGhlIG5ldyB0ZXh0 LCB3ZSB0YWxrZWQgYWJvdXQgYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sIGRhdGEgY29u ZmlkZW50aWFsaXR5LCBwcml2YWN5IHByb3RlY3Rpb24uJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTog5a6L5L2TLCBzYW5zLXNlcmlmOyI+VGhlbiB0aGUgZGV0YWlscyBhYm91 dCBob3cgdG8gYWNoaWV2ZSB0aGF0IGNhbiBiZSBzcGVjaWZpZWQgaW4gQVBJIHNwZWMgYW5kIFNj aGVtYSBzcGVjLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgc2Fucy1z ZXJpZjsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgc2Fu cy1zZXJpZjsiPkNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgc2Fucy1zZXJpZjsiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgc2Fucy1zZXJpZjsiPlRoYW5rcyw8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIHNhbnMtc2VyaWY7Ij48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIHNhbnMtc2VyaWY7Ij5LaW5k IFJlZ2FyZHM8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIHNhbnMtc2Vy aWY7Ij5LZXBlbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIHNhbnMt c2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIHNh bnMtc2VyaWY7Ij4NCjxkaXY+5ZyoIDEzLzMvMTUgMzoyNiBhbe+8jCAmcXVvdDtCYXJyeSBMZWli YSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJy eWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7IOWGmeWFpTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIg c3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1sZWZ0 LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBweCAw cHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5JIGxpa2UgdGhpcyBkb2N1 bWVudCwgYW5kIEkgdGhpbmsgaXQncyBhYm91dCByZWFkeSB0byBnby4mbmJzcDsmbmJzcDtJIGp1 c3QgaGF2ZTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNl OyBmb250LXNpemU6IDEycHg7Ij50d28gaXNzdWVzIEknZCBsaWtlIHRvIGRpc2N1c3Mgd2l0aCB0 aGUgZWRpdG9ycyBhbmQgd29ya2luZyBncm91cDo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJw eDsiPjEuIEkgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgdG9v IGJyaWVmLCBhbmQgd291bGQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMs IG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+YmUgYmV0dGVyIGZsZXNoZWQgb3V0IGEgYml0 LiZuYnNwOyZuYnNwO1RoZXJlIGFyZSBnb2luZyB0byBiZSBkZXRhaWxzIHRoYXQnbGwgYmU8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXpl OiAxMnB4OyI+bGVmdCB0byB0aGUgc2NoZW1hIGFuZCBhcGkgZG9jdW1lbnRzIC0tIGRldGFpbHMg dGhhdCBoYXZlIHRvIGRvIHdpdGg8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovk vZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+dGhlIHNjaGVtYSBhbmQgYXBpLCBvZiBj b3Vyc2UuJm5ic3A7Jm5ic3A7QnV0IHRoaXMgZG9jdW1lbnQgY291bGQgYW5kIHNob3VsZDwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6 IDEycHg7Ij50YWxrIGFib3V0IHRoZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZv ciB3aGF0IFNDSU0gaXMgZG9pbmcuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L 5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPldoYXQgYXJlIHRoZSBnZW5lcmFsIHRo cmVhdHMgYW5kIHByaXZhY3kgaXNzdWVzLCBhbmQgaG93IGRvIHlvdSBleHBlY3Q8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4 OyI+dGhlbSB0byBiZSBkZWFsdCB3aXRoPyZuYnNwOyZuYnNwO0xldCB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgaW4gdGhpczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9 kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5kb2N1bWVudCBmb3JtIHRoZSBiYXNpcyBv biB3aGljaCB0aGUgb3RoZXIgZG9jdW1lbnRzIHdpdGggZXhwYW5kIHdoZW48L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+ dGhlIHByb3RvY29sIGRldGFpbHMgYXJlIGluIHBsYWNlLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXpl OiAxMnB4OyI+Mi4gVGhlIElFU0cgaGFzIGJlZW4gc3Ryb25nbHkgcXVlc3Rpb25pbmcgdGhlIHZh bHVlIG9mIHB1Ymxpc2hpbmc8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMs IG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+dXNlLWNhc2UgZG9jdW1lbnRzIGFzIFJGQ3Mu Jm5ic3A7Jm5ic3A7VGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhleSByZWFsbHkgaGF2ZTwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6 IDEycHg7Ij5hcmNoaXZhbCB2YWx1ZSwgb3Igd2hldGhlciBubyBvbmUgd2lsbCByZWFkIHRoZW0g aW4gc2l4IG1vbnRocyBvciBzbyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovk vZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+d2hlbiB0aGUgcHJvdG9jb2xzIHRoZXkg aW5mb3JtZWQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4mbmJzcDsmbmJzcDtPZnRlbiwgaXQgd291bGQ8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1z aXplOiAxMnB4OyI+YmUgYmV0dGVyIHRvIHB1Ymxpc2ggY29sbGVjdGlvbnMgb2YgdXNlIGNhc2Vz IGFuZCByZWxhdGVkIGRpc2N1c3Npb248L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDl rovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+aW4gdGhlIHdvcmtpbmcgZ3JvdXAn cyB3aWtpLCByYXRoZXIgdGhhbiBnb2luZyBmb3IgUkZDIHB1YmxpY2F0aW9uLiZuYnNwOyZuYnNw O0k8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9u dC1zaXplOiAxMnB4OyI+dmVyeSBtdWNoIHN1cHBvcnQgdGhhdCBxdWVzdGlvbmluZy4mbmJzcDsm bmJzcDtCdXQuLi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9z cGFjZTsgZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPlRoaXMgZG9jdW1lbnQg aXMgbW9yZSB0aGFuIGEgdXNlLWNhc2VzIGRvY3VtZW50LCBhbmQgaXQgc2VsbHMgaXRzZWxmPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6 ZTogMTJweDsiPnNob3J0IGJ5IGJ1cnlpbmcgdGhhdCwgYnkgbWFraW5nIHRoZSByZWFkZXIgZmln dXJlIHRoYXQgb3V0LiZuYnNwOyZuYnNwO0l0J3M8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+cmVhbGx5IGRlZmluaXRp b25zIGFuZCBvdmVydmlldywgZmxvd3MsIHVzZSBjYXNlcywgYW5kIHJlcXVpcmVtZW50cy48L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXpl OiAxMnB4OyI+QXMgc3VjaCwgSSB0aGluayBpdCAqZG9lcyogaGF2ZSB2YWx1ZSBhcyBhbiBSRkMu Jm5ic3A7Jm5ic3A7TGV0J3Mgbm90IG1ha2UgdGhlPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPnJlc3Qgb2YgdGhlIElF U0cgd29uZGVyIGFib3V0IHRoYXQsIGFuZCBwZXJoYXBzIHRha2UgYSBkaWZmZXJlbnQgdmlldy48 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1z aXplOiAxMnB4OyI+SSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVudCBzb21ldGhpbmcg bGlrZSB0aGlzOjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3Nw YWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+T0xEPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsi PlNDSU0gVXNlIENhc2VzPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBt b25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5ORVc8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAx MnB4OyI+U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkg RGVmaW5pdGlvbnMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25v c3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPk92ZXJ2aWV3LCBhbmQgRmxvd3M8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7 IGZvbnQtc2l6ZTogMTJweDsiPkVORDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWu i+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+KFRo YXQgYWxzbyBleHBhbmRzIFNDSU0sIHdoaWNoIHRoZSBSRkMgRWRpdG9yIHdpbGwgaW5zaXN0IG9u LCBzbyB5b3U8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFj ZTsgZm9udC1zaXplOiAxMnB4OyI+bWlnaHQgYXMgd2VsbCBkbyBpdCBub3cuKTwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFj ZTsgZm9udC1zaXplOiAxMnB4OyI+VGhlbiBmb3IgdGhlIGFic3RyYWN0OjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsg Zm9udC1zaXplOiAxMnB4OyI+T0xEPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L 5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3Vt ZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzIG9mIFN5c3RlbSBmb3I8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1z aXplOiAxMnB4OyI+Jm5ic3A7Jm5ic3A7IENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50 IChTQ0lNKS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFj ZTsgZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPk5FVzwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij4m bmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBkZWZpbml0aW9ucyBhbmQgYW4gb3Zl cnZpZXcgb2YgdGhlIFN5c3RlbTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9 kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij4mbmJzcDsmbmJzcDsgZm9yIENyb3NzLWRv bWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKS4mbmJzcDsmbmJzcDtJdCBsYXlzIG91dCB0 aGU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9u dC1zaXplOiAxMnB4OyI+Jm5ic3A7Jm5ic3A7IHN5c3RlbSdzIG1vZGVzIGFuZCBmbG93cywgYW5k IGluY2x1ZGVzIHVzZXIgc2NlbmFyaW9zLCB1c2UgY2FzZXMsPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPiZuYnNwOyZu YnNwOyBhbmQgcmVxdWlyZW1lbnRzLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWu i+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+RU5E PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQt c2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9 kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5BbmQgdGhlbiB0d2VhayB0aGUgSW50cm9k dWN0aW9uIGFjY29yZGluZ2x5LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9 kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+RG8gdGhv c2UgcG9pbnRzIHNvdW5kIHJlYXNvbmFibGU/PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsiPihJIHdpbGwgcHV0IHRoZSBk b2N1bWVudCBpbnRvICZxdW90O0FEIEV2YWx1YXRpb246IFJldmlzZWQgSS1EIE5lZWRlZCZxdW90 OyBzdGF0ZS4pPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3Bh Y2U7IGZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7Ij5CYXJyeTwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFj ZTsgZm9udC1zaXplOiAxMnB4OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9z cGFjZTsgZm9udC1zaXplOiAxMnB4OyI+c2NpbSBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiDlrovkvZMsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyI+PGEg aHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsi PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1304F451209DCmoransarciscocom_-- From nobody Fri Mar 20 07:44:28 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF21B2E2B for ; Fri, 20 Mar 2015 07:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LC_A9K8jLZYz for ; Fri, 20 Mar 2015 07:44:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7501B2E2A for ; Fri, 20 Mar 2015 07:44:22 -0700 (PDT) Received: from BN1PR04MB392.namprd04.prod.outlook.com (10.141.60.151) by BN1PR04MB391.namprd04.prod.outlook.com (10.141.60.150) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 20 Mar 2015 14:44:00 +0000 Received: from BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.87]) by BN1PR04MB392.namprd04.prod.outlook.com ([169.254.10.87]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 14:44:00 +0000 From: Kelly Grizzle To: "Morteza Ansari (moransar)" , Kepeng Li , Barry Leiba , "scim@ietf.org" Thread-Topic: [scim] AD review of draft-ietf-scim-use-cases-04 Thread-Index: AQHQYIGXZCvg1Btmn0+tjeRd4CKttJ0kDHMAgAFq5TA= Date: Fri, 20 Mar 2015 14:44:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-vipre-scanned: 004706290096C200470776 x-originating-ip: [97.79.140.10] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR04MB391; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(479174004)(377454003)(164054003)(71364002)(87936001)(74316001)(230783001)(2656002)(50986999)(66066001)(19625215002)(54356999)(76176999)(76576001)(62966003)(102836002)(86362001)(16236675004)(33656002)(19300405004)(19617315012)(19609705001)(19580395003)(19580405001)(2950100001)(2900100001)(77156002)(40100003)(92566002)(15975445007)(2501003)(107886001)(46102003)(99286002)(106116001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR04MB391; H:BN1PR04MB392.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR04MB391; BCL:0; PCL:0; RULEID:; SRVR:BN1PR04MB391; x-forefront-prvs: 05214FD68E Content-Type: multipart/alternative; boundary="_000_BN1PR04MB39256583F31958A7ECC6DE3E20E0BN1PR04MB392namprd_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 14:44:00.3952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c848b2a-49ba-4c39-9749-118d06717a84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR04MB391 Archived-At: Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 14:44:27 -0000 --_000_BN1PR04MB39256583F31958A7ECC6DE3E20E0BN1PR04MB392namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgbGlrZSBtdWNoIG9mIHRoaXMgdGV4dCBpcyBjb3BpZWQgYW5kIGNoYW5nZWQgc2xp Z2h0bHkgZnJvbSB0aGUgQVBJIGRvYy4gIFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8ganVzdCBsaW5r IHRvIHNlY3Rpb24gNyBvZiB0aGUgQVBJIGRvYyBpbnN0ZWFkPw0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zY2ltLWFwaS0xNiNzZWN0aW9uLTcNCg0KLS1LZWxseQ0K DQpGcm9tOiBzY2ltIFttYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE5LCAyMDE1 IDEyOjA0IFBNDQpUbzogS2VwZW5nIExpOyBCYXJyeSBMZWliYTsgc2NpbUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtzY2ltXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zY2ltLXVzZS1jYXNlcy0w NA0KDQpUaGFua3MgS2VwZW5nLiAgV0csIHBsZWFzZSBwcm92aWRlIHlvdXIgZmVlZGJhY2svdGhv dWdodHMgb24gdGhlIHN1Z2dlc3RlZCB0ZXh0Lg0KDQoNCkNoZWVycywNCk1vcnRlemENCg0KRnJv bTogS2VwZW5nIExpIDxrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbTxtYWlsdG86a2VwZW5nLmxr cEBhbGliYWJhLWluYy5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMTcsIDIwMTUgYXQgMTI6 MTEgQU0NClRvOiAiQmFycnkgb3JnPiIgPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpi YXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4+LCAic2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRm Lm9yZz4iIDxzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2NpbS11c2UtY2FzZXMtMDQNCg0KPiBJ IHRoaW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGlzIHRvbyBicmllZiwg YW5kIHdvdWxkDQpiZSBiZXR0ZXIgZmxlc2hlZCBvdXQgYSBiaXQuDQoNCkhvdyBhYm91dCB0aGlz Og0KDQoNCk9MRDoNCg0KDQogICBTQ0lNIHJlc291cmNlcyAoZS5nLiwgVXNlcnMgYW5kIEdyb3Vw cykgY2FuIGNvbnRhaW4gc2Vuc2l0aXZlDQoNCiAgIGluZm9ybWF0aW9uLiAgVGhlcmVmb3JlLCBh dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtdXN0IGJlDQoNCiAgIGd1YXJhbnRlZWQg Zm9yIHRoZSBTQ0lNIG9wZXJhdGlvbnMuDQoNCg0KDQogICBBbHNvLCBwcml2YXRlIGluZm9ybWF0 aW9uIG9mIHRoZSBTQ0lNIHJlc291cmNlcyBtdXN0IGJlIGtlcHQNCg0KICAgY29uZmlkZW50aWFs IGFuZCBwcm90ZWN0ZWQuDQoNCg0KTkVXOg0KDQoNCiAgIEF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIG11c3QgYmUNCg0KICAgZ3VhcmFudGVlZCBmb3IgdGhlIFNDSU0gb3BlcmF0aW9u cy4NCg0KICAgQmVjYXVzZSBTQ0lNIGJ1aWxkcyBvbiB0aGUgSHlwZXJ0ZXh0IFRyYW5zZmVyIFBy b3RvY29sIGFuZA0KDQogICB0aHVzIHN1YmplY3QgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIG9mIEhUVFAgU2VjdGlvbiA5PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzAj c2VjdGlvbi05Pg0KDQogICBbUkZDNzIzMF08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzIzMCNzZWN0aW9uLTk+IGFuZCBpdHMgcmVsYXRlZCBzcGVjaWZpY2F0aW9ucy4NCg0KDQogICBT Q0lNIGRlcGVuZHMgb24gc3RhbmRhcmQgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLiBJbXBs ZW1lbnRlcnMgU0hPVUxEIHN1cHBvcnQNCg0KICAgZXhpc3RpbmcgYXV0aGVudGljYXRpb24vYXV0 aG9yaXphdGlvbiBzY2hlbWVzLiAgSW4gcGFydGljdWxhciwgT0F1dGgyDQoNCiAgIChzZWUgW1JG QzY3NDk8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OT5dLCBbUkZDNjc1MDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzUwPl0pIGlzIFJFQ09NTUVOREVELiAgQXBwcm9w cmlhdGUgc2VjdXJpdHkNCg0KICAgY29uc2lkZXJhdGlvbnMgb2YgdGhlIHNlbGVjdGVkIGF1dGhl bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uDQoNCiAgIHNjaGVtZXMgU0hPVUxEIGJlIHRha2Vu Lg0KDQoNCiAgIFNDSU0gcmVzb3VyY2VzIChlLmcuLCBVc2VycyBhbmQgR3JvdXBzKSBjYW4gY29u dGFpbiBzZW5zaXRpdmUNCg0KICAgaW5mb3JtYXRpb24uIFRodXMsIGRhdGEgY29uZmlkZW50aWFs aXR5IE1VU1QgYmUgZ3VhcmFudGVlZCBhdCB0aGUgdHJhbnNwb3J0IGxheWVyLg0KDQogICBUTFMg TVVTVCBiZSBpbXBsZW1lbnRlZCBieSBTQ0lNIGNsaWVudHMgYW5kIHNlcnZpY2UgcHJvdmlkZXJz Lg0KDQogICBUTFMgdmVyc2lvbiAxLjAgW1JGQzUyNDY8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTI0Nj5dIG9yIFRMUyB2ZXJzaW9uIDEuMiBbUkZDNTI0NjxodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1MjQ2Pl0gY2FuIGJlIGNob3NlbiBkZXBlbmRpbmcgb24NCg0KICAgdGhl IHdpZGVzcHJlYWQgZGVwbG95bWVudCBhbmQga25vd24gc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVz IGF0IHRoZSB0aW1lIG9mIGltcGxlbWVudGF0aW9uLg0KDQogICBUaGUgU0NJTSBhdHRyaWJ1dGVz IE1BWSBjb250YWluIHBlcnNvbmFsbHkNCg0KICAgaWRlbnRpZmlhYmxlIGluZm9ybWF0aW9uIGFz IHdlbGwgYXMgb3RoZXIgc2Vuc2l0aXZlIGRhdGEuDQoNCiAgIFRodXMgcHJpdmF0ZSBpbmZvcm1h dGlvbiBvZiB0aGUgU0NJTSByZXNvdXJjZXMgTVVTVCBiZSBwcm90ZWN0ZWQuDQoNCiAgIEluZHVz dHJ5IGJlc3QgcHJhY3RpY2VzIFNIT1VMRCBiZSB1bmRlcnRha2VuIHRvIHByb3RlY3QNCg0KICAg dGhlIHN0b3JhZ2Ugb2YgY3JlZGVudGlhbHMgYW5kIGluIHBhcnRpY3VsYXIgU0hPVUxEIGZvbGxv dw0KDQogICByZWNvbW1lbmRhdGlvbnMgb3V0bGluZXMgaW4gU2VjdGlvbiA1LjEuNC4xIFtSRkM2 ODE5XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2ODE5I3NlY3Rpb24tNS4xLjQuMT4u DQoNCkVORA0KDQpJbiB0aGUgbmV3IHRleHQsIHdlIHRhbGtlZCBhYm91dCBhdXRoZW50aWNhdGlv biwgYXV0aG9yaXphdGlvbiwgZGF0YSBjb25maWRlbnRpYWxpdHksIHByaXZhY3kgcHJvdGVjdGlv bi4NClRoZW4gdGhlIGRldGFpbHMgYWJvdXQgaG93IHRvIGFjaGlldmUgdGhhdCBjYW4gYmUgc3Bl Y2lmaWVkIGluIEFQSSBzcGVjIGFuZCBTY2hlbWEgc3BlYy4NCg0KQ29tbWVudHMgb3Igc3VnZ2Vz dGlvbnMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcywNCg0KS2luZCBSZWdhcmRzDQpLZXBlbmcNCg0K 5ZyoIDEzLzMvMTUgMzoyNiBhbe+8jCAiQmFycnkgTGVpYmEiIDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiDlhpnlhaU6DQoNCkkgbGlrZSB0 aGlzIGRvY3VtZW50LCBhbmQgSSB0aGluayBpdCdzIGFib3V0IHJlYWR5IHRvIGdvLiAgSSBqdXN0 IGhhdmUNCnR3byBpc3N1ZXMgSSdkIGxpa2UgdG8gZGlzY3VzcyB3aXRoIHRoZSBlZGl0b3JzIGFu ZCB3b3JraW5nIGdyb3VwOg0KDQoxLiBJIHRoaW5rIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uIGlzIHRvbyBicmllZiwgYW5kIHdvdWxkDQpiZSBiZXR0ZXIgZmxlc2hlZCBvdXQg YSBiaXQuICBUaGVyZSBhcmUgZ29pbmcgdG8gYmUgZGV0YWlscyB0aGF0J2xsIGJlDQpsZWZ0IHRv IHRoZSBzY2hlbWEgYW5kIGFwaSBkb2N1bWVudHMgLS0gZGV0YWlscyB0aGF0IGhhdmUgdG8gZG8g d2l0aA0KdGhlIHNjaGVtYSBhbmQgYXBpLCBvZiBjb3Vyc2UuICBCdXQgdGhpcyBkb2N1bWVudCBj b3VsZCBhbmQgc2hvdWxkDQp0YWxrIGFib3V0IHRoZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIGZvciB3aGF0IFNDSU0gaXMgZG9pbmcuDQpXaGF0IGFyZSB0aGUgZ2VuZXJhbCB0aHJl YXRzIGFuZCBwcml2YWN5IGlzc3VlcywgYW5kIGhvdyBkbyB5b3UgZXhwZWN0DQp0aGVtIHRvIGJl IGRlYWx0IHdpdGg/ICBMZXQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRoaXMNCmRv Y3VtZW50IGZvcm0gdGhlIGJhc2lzIG9uIHdoaWNoIHRoZSBvdGhlciBkb2N1bWVudHMgd2l0aCBl eHBhbmQgd2hlbg0KdGhlIHByb3RvY29sIGRldGFpbHMgYXJlIGluIHBsYWNlLg0KDQoyLiBUaGUg SUVTRyBoYXMgYmVlbiBzdHJvbmdseSBxdWVzdGlvbmluZyB0aGUgdmFsdWUgb2YgcHVibGlzaGlu Zw0KdXNlLWNhc2UgZG9jdW1lbnRzIGFzIFJGQ3MuICBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciB0 aGV5IHJlYWxseSBoYXZlDQphcmNoaXZhbCB2YWx1ZSwgb3Igd2hldGhlciBubyBvbmUgd2lsbCBy ZWFkIHRoZW0gaW4gc2l4IG1vbnRocyBvciBzbywNCndoZW4gdGhlIHByb3RvY29scyB0aGV5IGlu Zm9ybWVkIGhhdmUgYmVlbiBwdWJsaXNoZWQuICBPZnRlbiwgaXQgd291bGQNCmJlIGJldHRlciB0 byBwdWJsaXNoIGNvbGxlY3Rpb25zIG9mIHVzZSBjYXNlcyBhbmQgcmVsYXRlZCBkaXNjdXNzaW9u DQppbiB0aGUgd29ya2luZyBncm91cCdzIHdpa2ksIHJhdGhlciB0aGFuIGdvaW5nIGZvciBSRkMg cHVibGljYXRpb24uICBJDQp2ZXJ5IG11Y2ggc3VwcG9ydCB0aGF0IHF1ZXN0aW9uaW5nLiAgQnV0 Li4uDQoNClRoaXMgZG9jdW1lbnQgaXMgbW9yZSB0aGFuIGEgdXNlLWNhc2VzIGRvY3VtZW50LCBh bmQgaXQgc2VsbHMgaXRzZWxmDQpzaG9ydCBieSBidXJ5aW5nIHRoYXQsIGJ5IG1ha2luZyB0aGUg cmVhZGVyIGZpZ3VyZSB0aGF0IG91dC4gIEl0J3MNCnJlYWxseSBkZWZpbml0aW9ucyBhbmQgb3Zl cnZpZXcsIGZsb3dzLCB1c2UgY2FzZXMsIGFuZCByZXF1aXJlbWVudHMuDQpBcyBzdWNoLCBJIHRo aW5rIGl0ICpkb2VzKiBoYXZlIHZhbHVlIGFzIGFuIFJGQy4gIExldCdzIG5vdCBtYWtlIHRoZQ0K cmVzdCBvZiB0aGUgSUVTRyB3b25kZXIgYWJvdXQgdGhhdCwgYW5kIHBlcmhhcHMgdGFrZSBhIGRp ZmZlcmVudCB2aWV3Lg0KSSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVudCBzb21ldGhp bmcgbGlrZSB0aGlzOg0KDQpPTEQNClNDSU0gVXNlIENhc2VzDQoNCk5FVw0KU3lzdGVtIGZvciBD cm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkgRGVmaW5pdGlvbnMsDQpPdmVy dmlldywgYW5kIEZsb3dzDQoNCkVORA0KDQooVGhhdCBhbHNvIGV4cGFuZHMgU0NJTSwgd2hpY2gg dGhlIFJGQyBFZGl0b3Igd2lsbCBpbnNpc3Qgb24sIHNvIHlvdQ0KbWlnaHQgYXMgd2VsbCBkbyBp dCBub3cuKQ0KDQpUaGVuIGZvciB0aGUgYWJzdHJhY3Q6DQoNCk9MRA0KICAgVGhpcyBkb2N1bWVu dCBsaXN0cyB0aGUgdXNlciBzY2VuYXJpb3MgYW5kIHVzZSBjYXNlcyBvZiBTeXN0ZW0gZm9yDQog ICBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdlbWVudCAoU0NJTSkuDQoNCk5FVw0KICAgVGhp cyBkb2N1bWVudCBwcm92aWRlcyBkZWZpbml0aW9ucyBhbmQgYW4gb3ZlcnZpZXcgb2YgdGhlIFN5 c3RlbQ0KICAgZm9yIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChTQ0lNKS4gIEl0 IGxheXMgb3V0IHRoZQ0KICAgc3lzdGVtJ3MgbW9kZXMgYW5kIGZsb3dzLCBhbmQgaW5jbHVkZXMg dXNlciBzY2VuYXJpb3MsIHVzZSBjYXNlcywNCiAgIGFuZCByZXF1aXJlbWVudHMuDQoNCkVORA0K DQpBbmQgdGhlbiB0d2VhayB0aGUgSW50cm9kdWN0aW9uIGFjY29yZGluZ2x5Lg0KDQpEbyB0aG9z ZSBwb2ludHMgc291bmQgcmVhc29uYWJsZT8NCihJIHdpbGwgcHV0IHRoZSBkb2N1bWVudCBpbnRv ICJBRCBFdmFsdWF0aW9uOiBSZXZpc2VkIEktRCBOZWVkZWQiIHN0YXRlLikNCg0KQmFycnkNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFp bGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_BN1PR04MB39256583F31958A7ECC6DE3E20E0BN1PR04MB392namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRh aG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyBsaWtlIG11Y2gg b2YgdGhpcyB0ZXh0IGlzIGNvcGllZCBhbmQgY2hhbmdlZCBzbGlnaHRseSBmcm9tIHRoZSBBUEkg ZG9jLiZuYnNwOyBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGp1c3QgbGluayB0byBzZWN0aW9uIDcg b2YgdGhlIEFQSSBkb2MgaW5zdGVhZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNjaW0tYXBpLTE2I3NlY3Rpb24tNyI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2NpbS1hcGktMTYjc2VjdGlvbi03PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LS1LZWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNjaW0gW21haWx0bzpzY2ltLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1vcnRlemEgQW5zYXJpIChtb3Jh bnNhcik8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE5LCAyMDE1IDEyOjA0IFBN PGJyPg0KPGI+VG86PC9iPiBLZXBlbmcgTGk7IEJhcnJ5IExlaWJhOyBzY2ltQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2Np bS11c2UtY2FzZXMtMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFu a3MgS2VwZW5nLiAmbmJzcDtXRywgcGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkYmFjay90aG91Z2h0 cyBvbiB0aGUgc3VnZ2VzdGVkIHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TW9ydGV6YTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+S2VwZW5nIExpICZsdDs8YSBocmVmPSJtYWlsdG86a2VwZW5nLmxrcEBhbGliYWJhLWluYy5j b20iPmtlcGVuZy5sa3BAYWxpYmFiYS1pbmMuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgTWFyY2ggMTcsIDIwMTUgYXQgMTI6MTEgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90 O0JhcnJ5IG9yZyZndDsmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiYXJyeWxlaWJhQGNvbXB1 dGVyLm9yZyI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDogPC9iPlJlOiBbc2NpbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2NpbS11c2UtY2Fz ZXMtMDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPiZndDsgSSB0aGluayB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBpcyB0b28gYnJpZWYsIGFuZCB3b3VsZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+YmUgYmV0dGVyIGZsZXNoZWQgb3V0IGEgYml0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SG93IGFi b3V0IHRoaXM6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+T0xE OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBTQ0lNIHJlc291cmNlcyAoZS5nLiwgVXNlcnMgYW5kIEdyb3VwcykgY2FuIGNvbnRhaW4gc2Vu c2l0aXZlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgaW5mb3JtYXRpb24uJm5ic3A7IFRoZXJlZm9yZSwgYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24gbXVzdCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGd1YXJhbnRlZWQgZm9yIHRoZSBTQ0lNIG9w ZXJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBBbHNvLCBwcml2YXRlIGluZm9ybWF0aW9uIG9mIHRoZSBTQ0lNIHJlc291 cmNlcyBtdXN0IGJlIGtlcHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb25maWRlbnRpYWwgYW5kIHByb3RlY3RlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5ORVc6PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9z cGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIG11c3QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBndWFyYW50ZWVkIGZvciB0aGUgU0NJTSBv cGVyYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQmVjYXVzZSBTQ0lNIGJ1aWxkcyBv biB0aGUmbmJzcDtIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgYW5kPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHRodXMgc3ViamVjdCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgSFRUUCA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjMwI3NlY3Rpb24tOSI+U2Vj dGlvbiZuYnNwOzk8bzpwPjwvbzpwPjwvYT48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzAjc2VjdGlvbi05Ij4mbmJzcDsmbmJzcDsgW1JG QzcyMzBdPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+IGFuZCBpdHMgcmVsYXRlZCBzcGVjaWZpY2F0 aW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFu Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgU0NJTSBkZXBlbmRzIG9uIHN0YW5kYXJkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcy4g SW1wbGVtZW50ZXJzIFNIT1VMRCBzdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBleGlz dGluZyBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHNjaGVtZXMuJm5ic3A7IEluIHBhcnRp Y3VsYXIsIE9BdXRoMjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgKHNlZSBbPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSIgdGl0bGU9IiZxdW90O1RoZSBPQXV0aCAy LjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsmcXVvdDsiPlJGQzY3NDk8L2E+XSwgWzxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NTAiIHRpdGxlPSImcXVvdDtUaGUgT0F1 dGggMi4wIEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBCZWFyZXIgVG9rZW4gVXNhZ2UmcXVvdDsi PlJGQzY3NTA8L2E+XSkgaXMgUkVDT01NRU5ERUQuJm5ic3A7IEFwcHJvcHJpYXRlIHNlY3VyaXR5 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb25zaWRlcmF0aW9ucyBvZiB0aGUgc2VsZWN0ZWQg YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHNjaGVtZXMgU0hPVUxEIGJlIHRha2VuLiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb3Vy aWVyO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TQ0lNIHJlc291cmNlcyAoZS5nLiwgVXNlcnMgYW5kIEdy b3VwcykgY2FuIGNvbnRhaW4gc2Vuc2l0aXZlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb24uIFRodXMsIGRhdGEg Y29uZmlkZW50aWFsaXR5IE1VU1QgYmUgZ3VhcmFudGVlZCBhdCB0aGUgdHJhbnNwb3J0IGxheWVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IFRMUyBNVVNUIGJlIGltcGxlbWVudGVkIGJ5IFNDSU0gY2xpZW50cyBhbmQgc2Vydmlj ZSBwcm92aWRlcnMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRMUyB2ZXJzaW9uIDEuMCBbPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NiIgdGl0bGU9IiZxdW90O1RoZSBUcmFuc3BvcnQg TGF5ZXIgU2VjdXJpdHkgKFRMUykgUHJvdG9jb2wgVmVyc2lvbiAxLjImcXVvdDsiPlJGQzUyNDY8 L2E+XSBvciBUTFMgdmVyc2lvbiAxLjIgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzUyNDYiIHRpdGxlPSImcXVvdDtUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChU TFMpIFByb3RvY29sIFZlcnNpb24gMS4yJnF1b3Q7Ij5SRkM1MjQ2PC9hPl0gY2FuIGJlIGNob3Nl biBkZXBlbmRpbmcgb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgd2lkZXNwcmVhZCBkZXBsb3ltZW50IGFuZCBrbm93biBz ZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgYXQgdGhlIHRpbWUgb2YgaW1wbGVtZW50YXRpb24uJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgVGhlIFNDSU0gYXR0cmlidXRlcyBNQVkgY29udGFpbiBwZXJzb25hbGx5PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg aWRlbnRpZmlhYmxlIGluZm9ybWF0aW9uIGFzIHdlbGwgYXMgb3RoZXIgc2Vuc2l0aXZlIGRhdGEu ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IFRodXMgcHJpdmF0ZSBpbmZvcm1hdGlvbiBvZiB0aGUgU0NJTSByZXNvdXJj ZXMgTVVTVCBiZSBwcm90ZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj4gJm5ic3A7IEluZHVzdHJ5IGJlc3QgcHJhY3RpY2VzIFNIT1VMRCBiZSB1 bmRlcnRha2VuIHRvIHByb3RlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgc3RvcmFnZSBvZiBjcmVkZW50aWFscyBhbmQg aW4gcGFydGljdWxhciBTSE9VTEQgZm9sbG93PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVjb21tZW5kYXRpb25zIG91dGxpbmVz IGluIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4MTkjc2VjdGlvbi01 LjEuNC4xIj5TZWN0aW9uJm5ic3A7NS4xLjQuMSBbUkZDNjgxOV08L2E+LiA8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q291cmllcjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+RU5EPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29s b3I6YmxhY2siPkluIHRoZSBuZXcgdGV4dCwgd2UgdGFsa2VkIGFib3V0IGF1dGhlbnRpY2F0aW9u LCBhdXRob3JpemF0aW9uLCBkYXRhIGNvbmZpZGVudGlhbGl0eSwgcHJpdmFjeSBwcm90ZWN0aW9u LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1 bjtjb2xvcjpibGFjayI+VGhlbiB0aGUgZGV0YWlscyBhYm91dCBob3cgdG8gYWNoaWV2ZSB0aGF0 IGNhbiBiZSBzcGVjaWZpZWQgaW4gQVBJIHNwZWMgYW5kIFNjaGVtYSBzcGVjLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj5Db21tZW50cyBvciBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5LaW5kIFJlZ2FyZHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPktlcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNp bVN1bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5ZyoIDEzLzMvMTUgMzoyNiBh be+8jCAmcXVvdDtCYXJyeSBMZWliYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVp YmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7IOWGmeWFpTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj5JIGxpa2UgdGhpcyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgaXQncyBh Ym91dCByZWFkeSB0byBnby4mbmJzcDsmbmJzcDtJIGp1c3QgaGF2ZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj50d28gaXNzdWVz IEknZCBsaWtlIHRvIGRpc2N1c3Mgd2l0aCB0aGUgZWRpdG9ycyBhbmQgd29ya2luZyBncm91cDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPjEuIEkgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gaXMgdG9vIGJyaWVmLCBhbmQgd291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+YmUgYmV0dGVyIGZsZXNoZWQg b3V0IGEgYml0LiZuYnNwOyZuYnNwO1RoZXJlIGFyZSBnb2luZyB0byBiZSBkZXRhaWxzIHRoYXQn bGwgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjpibGFjayI+bGVmdCB0byB0aGUgc2NoZW1hIGFuZCBhcGkgZG9jdW1lbnRzIC0tIGRldGFp bHMgdGhhdCBoYXZlIHRvIGRvIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+dGhlIHNjaGVtYSBhbmQgYXBpLCBvZiBjb3Vy c2UuJm5ic3A7Jm5ic3A7QnV0IHRoaXMgZG9jdW1lbnQgY291bGQgYW5kIHNob3VsZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj50 YWxrIGFib3V0IHRoZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciB3aGF0IFND SU0gaXMgZG9pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPldoYXQgYXJlIHRoZSBnZW5lcmFsIHRocmVhdHMgYW5kIHByaXZh Y3kgaXNzdWVzLCBhbmQgaG93IGRvIHlvdSBleHBlY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+dGhlbSB0byBiZSBkZWFsdCB3 aXRoPyZuYnNwOyZuYnNwO0xldCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhpczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj5kb2N1bWVudCBmb3JtIHRoZSBiYXNpcyBvbiB3aGljaCB0aGUgb3RoZXIgZG9jdW1lbnRz IHdpdGggZXhwYW5kIHdoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OlNpbVN1bjtjb2xvcjpibGFjayI+dGhlIHByb3RvY29sIGRldGFpbHMgYXJlIGluIHBsYWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjpibGFjayI+Mi4gVGhlIElFU0cgaGFzIGJlZW4gc3Ryb25nbHkgcXVlc3Rp b25pbmcgdGhlIHZhbHVlIG9mIHB1Ymxpc2hpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+dXNlLWNhc2UgZG9jdW1lbnRzIGFz IFJGQ3MuJm5ic3A7Jm5ic3A7VGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhleSByZWFsbHkgaGF2 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj5hcmNoaXZhbCB2YWx1ZSwgb3Igd2hldGhlciBubyBvbmUgd2lsbCByZWFkIHRoZW0g aW4gc2l4IG1vbnRocyBvciBzbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+d2hlbiB0aGUgcHJvdG9jb2xzIHRoZXkgaW5mb3Jt ZWQgaGF2ZSBiZWVuIHB1Ymxpc2hlZC4mbmJzcDsmbmJzcDtPZnRlbiwgaXQgd291bGQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+ YmUgYmV0dGVyIHRvIHB1Ymxpc2ggY29sbGVjdGlvbnMgb2YgdXNlIGNhc2VzIGFuZCByZWxhdGVk IGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNp bVN1bjtjb2xvcjpibGFjayI+aW4gdGhlIHdvcmtpbmcgZ3JvdXAncyB3aWtpLCByYXRoZXIgdGhh biBnb2luZyBmb3IgUkZDIHB1YmxpY2F0aW9uLiZuYnNwOyZuYnNwO0k8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+dmVyeSBtdWNo IHN1cHBvcnQgdGhhdCBxdWVzdGlvbmluZy4mbmJzcDsmbmJzcDtCdXQuLi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6 YmxhY2siPlRoaXMgZG9jdW1lbnQgaXMgbW9yZSB0aGFuIGEgdXNlLWNhc2VzIGRvY3VtZW50LCBh bmQgaXQgc2VsbHMgaXRzZWxmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPnNob3J0IGJ5IGJ1cnlpbmcgdGhhdCwgYnkgbWFraW5n IHRoZSByZWFkZXIgZmlndXJlIHRoYXQgb3V0LiZuYnNwOyZuYnNwO0l0J3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+cmVhbGx5 IGRlZmluaXRpb25zIGFuZCBvdmVydmlldywgZmxvd3MsIHVzZSBjYXNlcywgYW5kIHJlcXVpcmVt ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjpibGFjayI+QXMgc3VjaCwgSSB0aGluayBpdCAqZG9lcyogaGF2ZSB2YWx1ZSBhcyBhbiBS RkMuJm5ic3A7Jm5ic3A7TGV0J3Mgbm90IG1ha2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPnJlc3Qgb2YgdGhlIElFU0cg d29uZGVyIGFib3V0IHRoYXQsIGFuZCBwZXJoYXBzIHRha2UgYSBkaWZmZXJlbnQgdmlldy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+SSBzdWdnZXN0IHlvdSByZXRpdGxlIHRoZSBkb2N1bWVudCBzb21ldGhpbmcgbGlrZSB0aGlz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjpibGFjayI+T0xEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPlNDSU0gVXNlIENhc2VzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNp bVN1bjtjb2xvcjpibGFjayI+U3lzdGVtIGZvciBDcm9zcy1kb21haW4gSWRlbnRpdHkgTWFuYWdl bWVudCAoU0NJTSkgRGVmaW5pdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPk92ZXJ2aWV3LCBhbmQgRmxvd3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47 Y29sb3I6YmxhY2siPkVORDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+KFRoYXQgYWxzbyBleHBhbmRzIFND SU0sIHdoaWNoIHRoZSBSRkMgRWRpdG9yIHdpbGwgaW5zaXN0IG9uLCBzbyB5b3U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+bWln aHQgYXMgd2VsbCBkbyBpdCBub3cuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+VGhlbiBmb3IgdGhlIGFi c3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+T0xEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGlzIGRv Y3VtZW50IGxpc3RzIHRoZSB1c2VyIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzIG9mIFN5c3RlbSBm b3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChT Q0lNKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPk5FVzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1 bWVudCBwcm92aWRlcyBkZWZpbml0aW9ucyBhbmQgYW4gb3ZlcnZpZXcgb2YgdGhlIFN5c3RlbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgZm9yIENyb3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50IChT Q0lNKS4mbmJzcDsmbmJzcDtJdCBsYXlzIG91dCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN5c3Rl bSdzIG1vZGVzIGFuZCBmbG93cywgYW5kIGluY2x1ZGVzIHVzZXIgc2NlbmFyaW9zLCB1c2UgY2Fz ZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+RU5EPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj5BbmQgdGhlbiB0d2VhayB0aGUgSW50cm9kdWN0aW9u IGFjY29yZGluZ2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 U2ltU3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+RG8gdGhvc2UgcG9pbnRzIHNvdW5kIHJl YXNvbmFibGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1T dW47Y29sb3I6YmxhY2siPihJIHdpbGwgcHV0IHRoZSBkb2N1bWVudCBpbnRvICZxdW90O0FEIEV2 YWx1YXRpb246IFJldmlzZWQgSS1EIE5lZWRlZCZxdW90OyBzdGF0ZS4pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj5CYXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+c2NpbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN1PR04MB39256583F31958A7ECC6DE3E20E0BN1PR04MB392namprd_-- From nobody Sat Mar 21 12:33:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59161A8748 for ; Sat, 21 Mar 2015 12:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 bj2wLQfnJndl for ; Sat, 21 Mar 2015 12:33:00 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 44CDE1A1A7E for ; Sat, 21 Mar 2015 12:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1426966375; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=Km3elYJQp/86JGt3TzfdZWRdW4yxBGClnNiWf3RdpCQ=; b=CMBwb6r6/kyjYnIr0biSzT/Rec8uTAUgfkyxc55dyu/pOtt5mnUHGfi5QPgdOnWcXBx/o6fFOFMFh0Yx8k0nGdEJbb8tehQaoxAjKdYo78UeOTYaF1d4jb7nygc4wdh/n8BiOkgOQRsnN2ILIzsOl80HkX0nZI8+C1QRsn8/HFk= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05021; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=4; RT=4; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.136.216]) by r41g03016.xy2.aliyun.com at Sun, 22 Mar 2015 03:32:48 +0800 Date: Sun, 22 Mar 2015 03:32:48 +0800 From: "Kepeng Li" To: "=?UTF-8?B?TW9ydGV6YSBBbnNhcmkgKG1vcmFuc2FyKQ==?=" , "Barry Leiba" , "scim@ietf.org" , "Kelly Grizzle" Message-ID: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2684282 MIME-Version: 1.0 References: , BN1PR04MB39256583F31958A7ECC6DE3E20E0@BN1PR04MB392.namprd04.prod.outlook.com In-Reply-To: BN1PR04MB39256583F31958A7ECC6DE3E20E0@BN1PR04MB392.namprd04.prod.outlook.com Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_11098_4d8c2940_550dc760_6fdf3" Archived-At: Subject: [scim] =?utf-8?q?Re=EF=BC=9A_AD_review_of_draft-ietf-scim-use-cas?= =?utf-8?q?es-04?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 19:33:03 -0000 ------=ALIBOUNDARY_11098_4d8c2940_550dc760_6fdf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >It seems like much of this text is copied and changed slightly from the API d= oc. Yes, but I just copied the general part, and the details are left in the A= PI doc.As Barry mentioned:=C2=A0There are going to be details that'll be=C2=A0= left to the schema and api documents -- details that have to do with=C2=A0the = schema and api, of course. But this document could and should=C2=A0talk about = the general security considerations for what SCIM is doing.I hope my copied te= xts have followed that guidance.>Would it make sense to just link to section 7= of the API doc instead?=0AI would prefer to keep some general texts in this d= ocument, and leave the details in the API spec.But I am open to other people's= thoughts.Thanks,Kind RegardsKepeng-------------------------------------------= -----------------------=0A=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AKelly Grizzle =0A=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A201= 5=E5=B9=B43=E6=9C=8820=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=94) 22:44=0A=E6=94=B6= =E4=BB=B6=E4=BA=BA=EF=BC=9AMorteza Ansari (moransar) ; =E6= =9D=8E=E5=85=8B=E9=B9=8F(=E6=98=93=E6=B7=B1) ; Bar= ry Leiba ; scim@ietf.org =0A=E4=B8=BB=E3= =80=80=E9=A2=98=EF=BC=9ARe: [scim] AD review of draft-ietf-scim-use-cases-04=0A= =0A=0A=0A=0Afont-family: Courier;panose-1: 2 7 4 9 2 2 5 2 4 4;font-family: Si= mSun;panose-1: 2 1 6 0 3 1 1 1 1 1;font-family: Cambria Math;panose-1: 2 4 5 3= 5 4 6 3 2 4;font-family: Calibri;panose-1: 2 15 5 2 2 2 4 3 2 4;font-family: = Tahoma;panose-1: 2 11 6 4 3 5 4 4 2 4;font-family: Consolas;panose-1: 2 11 6 9= 2 2 4 3 2 4;font-family: \@SimSun;panose-1: 2 1 6 0 3 1 1 1 1 1;p.MsoNormal, = li.MsoNormal, div.MsoNormal {margin: 0.0in;margin-bottom: 1.0E-4pt;font-size: = 12.0pt;font-family: Times New Roman , serif;}=0Aa:link, span.MsoHyperlink {mso= -style-priority: 99;color: blue;text-decoration: underline;}=0Aa:visited, span= .MsoHyperlinkFollowed {mso-style-priority: 99;color: purple;text-decoration: u= nderline;}=0Apre {mso-style-priority: 99;mso-style-link: HTML Preformatted Cha= r;margin: 0.0in;margin-bottom: 1.0E-4pt;font-size: 10.0pt;font-family: Courier= New;}=0Ap.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority: 99;m= so-style-link: Balloon Text Char;margin: 0.0in;margin-bottom: 1.0E-4pt;font-si= ze: 8.0pt;font-family: Tahoma , sans-serif;}=0Aspan.HTMLPreformattedChar {mso-= style-name: HTML Preformatted Char;mso-style-priority: 99;mso-style-link: HTML= Preformatted;font-family: Consolas;}=0Aspan.EmailStyle19 {mso-style-type: per= sonal-reply;font-family: Calibri , sans-serif;color: #1f497d;}=0Aspan.BalloonT= extChar {mso-style-name: Balloon Text Char;mso-style-priority: 99;mso-style-li= nk: Balloon Text;font-family: Tahoma , sans-serif;}=0A*.MsoChpDefault {mso-sty= le-type: export-only;font-size: 10.0pt;}=0Asize: 8.5in 11.0in;margin: 1.0in 1.= 0in 1.0in 1.0in;div.WordSection1 {page: WordSection1;}=0A=0A=0A=0A=0AIt seems = like much of this text is copied and changed slightly from the API doc.=C2=A0 = Would it make sense to just link to section 7 of the API doc instead?=0A=C2=A0= =0Ahttps://tools.ietf.org/html/draft-ietf-scim-api-16#section-7=0A=C2=A0=0A--K= elly=0A=C2=A0=0A=0A=0AFrom: scim [mailto:scim-bounces@ietf.org]=0AOn Behalf Of= Morteza Ansari (moransar)=0A=0ASent: Thursday, March 19, 2015 12:04 PM=0A=0AT= o: Kepeng Li; Barry Leiba; scim@ietf.org=0A=0ASubject: Re: [scim] AD review of= draft-ietf-scim-use-cases-04=0A=0A=0A=C2=A0=0A=0AThanks Kepeng. =C2=A0WG, ple= ase provide your feedback/thoughts on the suggested text.=0A=0A=0A=C2=A0=0A=0A= =0A=C2=A0=0A=0A=0ACheers,=0A=0A=0AMorteza=0A=0A=0A=C2=A0=0A=0A=0AFrom:=0AKepen= g Li =0A=0ADate: Tuesday, March 17, 2015 at 12:11 = AM=0A=0ATo: "Barry org>" , "scim@ietf.org" =0A=0ASubject: Re: [scim] AD review of draft-ietf-scim-use-cases-04=0A=0A= =0A=C2=A0=0A=0A=0A=0A=0A> I think the security considerations section is too b= rief, and would=0A=0A=0A=0Abe better fleshed out a bit.=C2=A0=0A=0A=0A=0AHow a= bout this:=0A=0A=0AOLD:=0A=0A=0A=C2=A0=C2=A0 SCIM resources (e.g., Users and G= roups) can contain sensitive=0A=C2=A0=C2=A0 information.=C2=A0 Therefore, auth= entication and authorization must be=0A=C2=A0=C2=A0 guaranteed for the SCIM op= erations.=0A=C2=A0=0A=C2=A0=C2=A0 Also, private information of the SCIM resour= ces must be kept=0A=C2=A0=C2=A0 confidential and protected.=0A=0A=0ANEW:=0A=0A= =0A=C2=A0=C2=A0 Authentication and authorization must be=0A=C2=A0=C2=A0 guaran= teed for the SCIM operations.=0A=C2=A0=C2=A0 Because SCIM builds on the=C2=A0H= ypertext Transfer Protocol and=0A=C2=A0=C2=A0 thus subject to the security con= siderations of HTTP Section=C2=A09=0A=C2=A0=C2=A0 [RFC7230] and its related sp= ecifications.=0A=0A=0A=C2=A0=C2=A0 SCIM depends on standard HTTP authenticatio= n schemes. Implementers SHOULD support=0A=C2=A0=C2=A0 existing authentication/= authorization schemes.=C2=A0 In particular, OAuth2=0A=C2=A0=C2=A0 (see [RFC674= 9], [RFC6750]) is RECOMMENDED.=C2=A0 Appropriate security=0A=C2=A0=C2=A0 consi= derations of the selected authentication and authorization=0A=C2=A0=C2=A0 sche= mes SHOULD be taken. =C2=A0=0A=0A=0A=C2=A0 =C2=A0SCIM resources (e.g., Users a= nd Groups) can contain sensitive=0A=C2=A0=C2=A0 information. Thus, data confid= entiality MUST be guaranteed at the transport layer.=0A=C2=A0=C2=A0 TLS MUST b= e implemented by SCIM clients and service providers. =C2=A0=0A=C2=A0=C2=A0 TLS= version 1.0 [RFC5246] or TLS version 1.2 [RFC5246] can be chosen depending on= =0A=C2=A0=C2=A0 the widespread deployment and known security vulnerabilities a= t the time of implementation.=C2=A0=0A=C2=A0=C2=A0 The SCIM attributes MAY con= tain personally=0A=C2=A0=C2=A0 identifiable information as well as other sensi= tive data. =C2=A0=0A=C2=A0=C2=A0 Thus private information of the SCIM resource= s MUST be protected.=0A =C2=A0 Industry best practices SHOULD be undertaken to= protect=0A=C2=A0=C2=A0 the storage of credentials and in particular SHOULD fo= llow=0A=C2=A0=C2=A0 recommendations outlines in Section=C2=A05.1.4.1 [RFC6819]= . =C2=A0=C2=A0=C2=A0=0A=0A=0A=C2=A0=0A=0A=0AEND=0A=0A=0A=C2=A0=0A=0A=0AIn the = new text, we talked about authentication, authorization, data confidentiality,= privacy protection.=C2=A0=0A=0A=0AThen the details about how to achieve that = can be specified in API spec and Schema spec.=0A=0A=0A=C2=A0=0A=0A=0AComments = or suggestions are welcome.=0A=0A=0A=C2=A0=0A=0A=0AThanks,=0A=0A=0A=C2=A0=0A=0A= =0AKind Regards=0A=0A=0AKepeng=0A=0A=0A=C2=A0=0A=0A=0A=0A=E5=9C=A8 13/3/15 3:2= 6 am=EF=BC=8C "Barry Leiba" =E5=86=99=E5=85=A5:=0A=0A= =0A=C2=A0=0A=0A=0A=0AI like this document, and I think it's about ready to go.= =C2=A0=C2=A0I just have=0A=0A=0Atwo issues I'd like to discuss with the editor= s and working group:=0A=0A=0A=C2=A0=0A=0A=0A1. I think the security considerat= ions section is too brief, and would=0A=0A=0Abe better fleshed out a bit.=C2=A0= =C2=A0There are going to be details that'll be=0A=0A=0Aleft to the schema and = api documents -- details that have to do with=0A=0A=0Athe schema and api, of c= ourse.=C2=A0=C2=A0But this document could and should=0A=0A=0Atalk about the ge= neral security considerations for what SCIM is doing.=0A=0A=0AWhat are the gen= eral threats and privacy issues, and how do you expect=0A=0A=0Athem to be deal= t with?=C2=A0=C2=A0Let the security considerations in this=0A=0A=0Adocument fo= rm the basis on which the other documents with expand when=0A=0A=0Athe protoco= l details are in place.=0A=0A=0A=C2=A0=0A=0A=0A2. The IESG has been strongly q= uestioning the value of publishing=0A=0A=0Ause-case documents as RFCs.=C2=A0=C2= =A0The question is whether they really have=0A=0A=0Aarchival value, or whether= no one will read them in six months or so,=0A=0A=0Awhen the protocols they in= formed have been published.=C2=A0=C2=A0Often, it would=0A=0A=0Abe better to pu= blish collections of use cases and related discussion=0A=0A=0Ain the working g= roup's wiki, rather than going for RFC publication.=C2=A0=C2=A0I=0A=0A=0Avery = much support that questioning.=C2=A0=C2=A0But...=0A=0A=0A=C2=A0=0A=0A=0AThis d= ocument is more than a use-cases document, and it sells itself=0A=0A=0Ashort b= y burying that, by making the reader figure that out.=C2=A0=C2=A0It's=0A=0A=0A= really definitions and overview, flows, use cases, and requirements.=0A=0A=0AA= s such, I think it *does* have value as an RFC.=C2=A0=C2=A0Let's not make the=0A= =0A=0Arest of the IESG wonder about that, and perhaps take a different view.=0A= =0A=0AI suggest you retitle the document something like this:=0A=0A=0A=C2=A0=0A= =0A=0AOLD=0A=0A=0ASCIM Use Cases=0A=0A=0A=C2=A0=0A=0A=0ANEW=0A=0A=0ASystem for= Cross-domain Identity Management (SCIM) Definitions,=0A=0A=0AOverview, and Fl= ows=0A=0A=0A=C2=A0=0A=0A=0AEND=0A=0A=0A=C2=A0=0A=0A=0A(That also expands SCIM,= which the RFC Editor will insist on, so you=0A=0A=0Amight as well do it now.)= =0A=0A=0A=C2=A0=0A=0A=0AThen for the abstract:=0A=0A=0A=C2=A0=0A=0A=0AOLD=0A=0A= =0A=C2=A0=C2=A0 This document lists the user scenarios and use cases of System= for=0A=0A=0A=C2=A0=C2=A0 Cross-domain Identity Management (SCIM).=0A=0A=0A=C2= =A0=0A=0A=0ANEW=0A=0A=0A=C2=A0=C2=A0 This document provides definitions and an= overview of the System=0A=0A=0A=C2=A0=C2=A0 for Cross-domain Identity Managem= ent (SCIM).=C2=A0=C2=A0It lays out the=0A=0A=0A=C2=A0=C2=A0 system's modes and= flows, and includes user scenarios, use cases,=0A=0A=0A=C2=A0=C2=A0 and requi= rements.=0A=0A=0A=C2=A0=0A=0A=0AEND=0A=0A=0A=C2=A0=0A=0A=0AAnd then tweak the = Introduction accordingly.=0A=0A=0A=C2=A0=0A=0A=0ADo those points sound reasona= ble?=0A=0A=0A(I will put the document into "AD Evaluation: Revised I-D Needed"= state.)=0A=0A=0A=C2=A0=0A=0A=0ABarry=0A=0A=0A=C2=A0=0A=0A=0A_________________= ______________________________=0A=0A=0Ascim mailing list=0A=0A=0Ascim@ietf.org= =0A=0A=0Ahttps://www.ietf.org/mailman/listinfo/scim=0A=0A=0A=C2=A0=0A=0A=0A=0A= =0A=0A ------=ALIBOUNDARY_11098_4d8c2940_550dc760_6fdf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>It seems like much of this= text is copied and changed slightly from the API doc.

Yes, but I just copied the general part, and the d= etails are left in the API doc.

As Barry mentioned: There are going to be details that'll be lef= t to the schema and api documents -- details that have to do with the sch= ema and api, of course. But this document could and should talk about the= general security considerations for what SCIM is doing.

I hope my copied texts have followed that guidanc= e.

>Would it make sense t= o just link to section 7 of the API doc instead?

I would prefer to keep some general texts in this document,= and leave the details in the API spec.

Bu= t I am open to other people's thoughts.

Th= anks,

Kind Regards
Kepeng

--= ----------------------------------------------------------------
=E5=8F=91=E4= =BB=B6=E4=BA=BA=EF=BC=9AKelly Grizzle <kelly.grizzle@sailpoint.com>
=E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015=E5=B9=B43=E6=9C=8820=E6=97=A5(=E6= =98=9F=E6=9C=9F=E4=BA=94) 22:44
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AMorteza= Ansari (moransar) <moransar@cisco.com>; =E6=9D=8E=E5=85=8B=E9=B9=8F(=E6= =98=93=E6=B7=B1) <kepeng.lkp@alibaba-inc.com>; Barry Leiba <barryleib= a@computer.org>; scim@ietf.org <scim@ietf.org>
=E4=B8=BB=E3=80=80=E9= =A2=98=EF=BC=9ARe: [scim] AD review of draft-ietf-scim-use-cases-04

=0A=0A=0A=0A=0A= =0A
=0A

It seems like m= uch of this text is copied and changed slightly from the API doc.  Would = it make sense to just link to section 7 of the API doc instead?

=0A<= p class=3D"MsoNormal"> 

=0A

<= a href=3D"https://tools.ietf.org/html/draft-ietf-scim-api-16#section-7" target= =3D"_blank">https://tools.ietf.org/html/draft-ietf-scim-api-16#section-7

=0A

 

=0A

--Kelly

=0A

 =0A

=0A
=0A

From: scim [mailto:scim-bounce= s@ietf.org]=0AOn Behalf Of Morteza Ansari (moransar)
=0ASent:= Thursday, March 19, 2015 12:04 PM
=0ATo: Kepeng Li; Barry Leiba; sc= im@ietf.org
=0ASubject: Re: [scim] AD review of draft-ietf-scim-use-= cases-04

=0A
=0A
=0A

 

=0A

=0A

Thanks Kepeng.  WG, please provid= e your feedback/thoughts on the suggested text.

=0A
=0A
=0A=

 

=0A
=0A
=0A

 

=0A
=0A
=0A

C= heers,

=0A
=0A
=0A

Morteza=

=0A
=0A
=0A

 

=0A
=0A=
=0A

From:=0AKepeng= Li <kepeng= .lkp@alibaba-inc.com>
=0ADate: Tuesday, March 17, 2015 at 12:= 11 AM
=0ATo: "Barry org>" <barryleiba@computer.org>, "scim@ietf.org" <scim@ietf.org>
=0ASubject: Re: [= scim] AD review of draft-ietf-scim-use-cases-04

=0A
=0A
=0A=

 

=0A
=0A
=0A
=0A
=0A=

> I think the security considerations section is too brief, and= would

=0A
=0A
=0A
=0A

be better fleshed out a b= it. 

=0A
=0A
=0A
=0A
How about this:
=0A
=0A=0A
OLD:
=0A
=0A=0A
   SCIM resources (e.g., Users and Groups) can contain sensiti=
ve
=0A
   information.  Therefore, authe=
ntication and authorization must be
=0A
   gu=
aranteed for the SCIM operations.
=0A
 =0A
   Also, private information of the SCIM resources =
must be kept
=0A
   confidential and protecte=
d.
=0A
=0A=0A
NEW:
=0A
=0A=0A   Authentication and authorization must be
=0A= 
   guaranteed for the SCIM operations.
=0A   Because SCIM builds on the Hy= pertext Transfer Protocol and=0A
   thus subje=
ct to the security considerations of HTTP Section 9
=0A   [RFC7230] and = its related specifications.=0A
=0A=0A
   SCI=
M depends on standard HTTP authentication schemes. Implementers SHOULD support=
=0A
   existing authent=
ication/authorization schemes.  In particular, OAuth2
=0A   (see [RFC6749], [RFC6750]) is RECOMMENDED.  Appropriate security<= /span>=0A
   considerations of=
 the selected authentication and authorization
=0A
   schemes SHOULD be taken.  
=0A
=0A=0A
   SCIM resources (e.g., Users and Groups) can contain sensitive=0A
   information. Thus, data confidentiality MUST b=
e guaranteed at the transport layer.
=0A
   T=
LS MUST be implemented by SCIM clients and service providers.  =0A
   TLS version 1.0 [RFC5246] or TLS version 1.2 [RFC5246] can be cho=
sen depending on
=0A
   the widespread deploy=
ment and known security vulnerabilities at the time of implementation. 
=0A
   The SCIM attributes MAY contain persona=
lly
=0A
   identifiable information as well a=
s other sensitive data.  
=0A
   Thus pr=
ivate information of the SCIM resources MUST be protected.
=0A   Industry best practices SHOULD be undertaken to protect=

=0A
   the storage of credentials and in particular=
 SHOULD follow
=0A
   recommendations outline=
s in Section 5.1.4.1 [RFC6819].    
=0A=0A
=0A
 
=0A
=0A
=0A
=
END
=0A
=0A
=0A
 
=0A
=0A=0A
In the new text, we talked about authentication, authorizat=
ion, data confidentiality, privacy protection. 
=0A
=0A=0A

Then the details about how to achieve that can be specified = in API spec and Schema spec.

=0A
=0A
=0A

 =

=0A
=0A
=0A

Comments or suggestions are welcom= e.

=0A
=0A
=0A

 

=0A
=0A=0A

Thanks,

=0A
=0A
=0A

 

=0A
=0A
=0A

Kind Regards

=0A
=0A=0A

Kepeng

=0A
=0A
=0A

 

=0A
=0A
=0A
=0A

=E5=9C=A8 13/3/15 3:26 am=EF=BC= =8C "Barry Leiba" <barryleiba@computer.org> =E5=86=99=E5=85=A5:

=0A
=0A=
=0A

 

=0A
=0A
= =0A
=0A

I like this document, and I think it's about ready to g= o.  I just have

=0A
=0A
=0A

two issues= I'd like to discuss with the editors and working group:

=0A
=0A=
=0A

 

=0A
=0A
=0A

1. I thin= k the security considerations section is too brief, and would

=0A=0A
=0A

be better fleshed out a bit.  There are go= ing to be details that'll be

=0A
=0A
=0A

left to= the schema and api documents -- details that have to do with

=0A=0A
=0A

the schema and api, of course.  But this d= ocument could and should

=0A
=0A
=0A

= talk about = the general security considerations for what SCIM is doing.

=0A=0A
=0A

What are the general threats and privacy issues, and h= ow do you expect

=0A
=0A
=0A

them to be dealt wi= th?  Let the security considerations in this

=0A
=0A<= div>=0A

document form the basis on which the other documents with e= xpand when

=0A
=0A
=0A

the protocol details are = in place.

=0A
=0A
=0A

 

=0A
= =0A
=0A

2. The IESG has been strongly questioning the value of = publishing

=0A
=0A
=0A

use-case documents as RFC= s.  The question is whether they really have

=0A
=0A<= div>=0A

archival value, or whether no one will read them in six mon= ths or so,

=0A
=0A
=0A

when the protocols they i= nformed have been published.  Often, it would

=0A
=0A=
=0A

be better to publish collections of use cases and related = discussion

=0A
=0A
=0A

in the working group's wi= ki, rather than going for RFC publication.  I

=0A
=0A=
=0A

very much support that questioning.  But...

=0A
=0A
=0A

 

=0A
=0A
=0A

This document is more than a use-cases document, and it sells itself<= /span>

=0A
=0A
=0A

short by burying that, by making the= reader figure that out.  It's

=0A
=0A
=0A

really definitions and overview, flows, use cases, and requirements.

=0A
=0A
=0A

As such, I think it *does* have value as= an RFC.  Let's not make the

=0A
=0A
=0A

rest of the IESG wonder about that, and perhaps take a different view.=

=0A
=0A
=0A

I suggest you retitle the document somethi= ng like this:

=0A
=0A
=0A

 

=0A=0A
=0A

OLD

=0A
=0A
=0A

SCIM = Use Cases

=0A
=0A
=0A

 

=0A
= =0A
=0A

NEW

=0A
=0A
=0A

System fo= r Cross-domain Identity Management (SCIM) Definitions,

=0A
=0A<= div>=0A

Overview, and Flows

=0A
=0A
=0A

 

=0A
=0A
=0A

END

=0A
=0A=0A

 

=0A
=0A
=0A

= (That also = expands SCIM, which the RFC Editor will insist on, so you

=0A
=0A=
=0A

might as well do it now.)

=0A
=0A
=0A 

=0A
=0A
=0A

Then for the abstra= ct:

=0A
=0A
=0A

 

=0A
=0A=0A

OLD

=0A
=0A
=0A

   Th= is document lists the user scenarios and use cases of System for

=0A=
=0A
=0A

   Cross-domain Identity Management (SC= IM).

=0A
=0A
=0A

 

=0A
=0A=0A

NEW

=0A
=0A
=0A

   T= his document provides definitions and an overview of the System

=0A<= /div>=0A
=0A

   for Cross-domain Identity Management = (SCIM).  It lays out the

=0A
=0A
=0A

&= nbsp;  system's modes and flows, and includes user scenarios, use cases,<= /span>

=0A
=0A
=0A

   and requirements.

=0A
=0A
=0A

 

=0A
=0A
=0A

END

=0A
=0A
=0A

 

=0A=0A
=0A

And then tweak the Introduction accordingly.=0A

=0A
=0A

 

=0A
=0A
=0A

Do those points sound reasonable?

=0A
=0A
=0A

(I will put the document into "AD Evaluation: Revised I-D Needed" state.)

=0A
=0A
=0A

 

=0A
=0A
=0ABarry

=0A
=0A
=0A

 

=0A=
=0A
=0A

_______________________________________________

=0A
=0A
=0A

scim mailing list

=0A
= =0A=0A=0A
=0A

 =0A

=0A=0A
=0A
=0A
=0A
------=ALIBOUNDARY_11098_4d8c2940_550dc760_6fdf3-- From nobody Sat Mar 21 12:41:23 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A8C1A8781 for ; Sat, 21 Mar 2015 12:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PBPe9Phzz3OB for ; Sat, 21 Mar 2015 12:41:20 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8898A1A8778 for ; Sat, 21 Mar 2015 12:41:19 -0700 (PDT) Received: by wixw10 with SMTP id w10so11001558wix.0 for ; Sat, 21 Mar 2015 12:41:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d3T7tTBtmomVLENC2PIA+OtRuKVwQAxXTjb2OT/eicM=; b=M/aowYfLj1Ha5Xlto0eh+ZMzW79Ttamba1hkwJpRDLGd7c2S0WlRHlrIa20nrG7Ivo bb1lnjdEuB6+mwQj2GDgGKJnsZ3NKgA8ctfTStaW4rEe1muGm1+/p0y39dEFDPLxBmIx n4+Z1IfA9ssgnipBGajzB5q9wEg0vyMHjjBM1vHjbrJq1b3z1HDdJqoI4c7mRMtpSdsn CWeASjyP8I+09R9UVg2niIKUPSuN2LhxRmpY/9KjgDeD8QTp445KqvgvMSxgk3izZ3uA VOAlXcz13py8B0fDxnY+0ASvB3kh+I2tgmWeE7NUVqzHPEsaA3kBbNajuteLXadCEhGa kvrg== X-Gm-Message-State: ALoCoQkN/jSKJEA9pcx5nLY4DdgLnF6xOyydU/sazfK4+/9ko3lbYh6WwIt0XqK0i9nTGcqjxkHN X-Received: by 10.180.205.233 with SMTP id lj9mr6561467wic.74.1426966878309; Sat, 21 Mar 2015 12:41:18 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:41d2:d297:f46d:1719? ([2001:67c:370:152:41d2:d297:f46d:1719]) by mx.google.com with ESMTPSA id n6sm11893184wjy.8.2015.03.21.12.41.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 12:41:17 -0700 (PDT) Message-ID: <550DC95B.1040202@mnt.se> Date: Sat, 21 Mar 2015 20:41:15 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: scim@ietf.org References: , BN1PR04MB39256583F31958A7ECC6DE3E20E0@BN1PR04MB392.namprd04.prod.outlook.com <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> In-Reply-To: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] =?utf-8?q?Re=EF=BC=9A_AD_review_of_draft-ietf-scim-use-cas?= =?utf-8?q?es-04?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 19:41:22 -0000 On 03/21/2015 08:32 PM, Kepeng Li wrote: >>It seems like much of this text is copied and changed slightly from the > API doc. > > Yes, but I just copied the general part, and the details are left in the > API doc. > > As Barry mentioned: There are going to be details that'll be left to the > schema and api documents -- details that have to do with the schema and > api, of course. But this document could and should talk about the > general security considerations for what SCIM is doing. > > I hope my copied texts have followed that guidance. > >>Would it make sense to just link to section 7 of the API doc instead? > > I would prefer to keep some general texts in this document, and leave > the details in the API spec. > > But I am open to other people's thoughts. > I don't think it matters that much what we do here and we should avoid bikeshedding if we can... From nobody Sat Mar 21 13:31:57 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1DD1A87E6 for ; Sat, 21 Mar 2015 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dqDIcXZLuXJH for ; Sat, 21 Mar 2015 13:31:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561331A87D7 for ; Sat, 21 Mar 2015 13:31:55 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2LKVrJU011378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Mar 2015 20:31:54 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2LKVq19030439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 21 Mar 2015 20:31:53 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2LKVqxr004962; Sat, 21 Mar 2015 20:31:52 GMT Received: from [192.168.1.122] (/207.81.223.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Mar 2015 13:31:52 -0700 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Phil Hunt Mime-Version: 1.0 (1.0) Date: Sat, 21 Mar 2015 13:14:30 -0700 Message-Id: <629A4499-3D48-4A9C-9428-C76FF71C4804@oracle.com> References: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> <550DC95B.1040202@mnt.se> In-Reply-To: <550DC95B.1040202@mnt.se> To: Leif Johansson X-Mailer: iPhone Mail (12B466) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] =?utf-8?q?Re=EF=BC=9A_AD_review_of_draft-ietf-scim-use-cas?= =?utf-8?q?es-04?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 20:31:56 -0000 I don't have good network access at the moment (or I would check) but it mig= ht be good to double check for any editorial conflicts/sync issues between d= ocuments.=20 In the last couple of api and core-schema revs we made some subtle clarifica= tions that I have not double checked against the use cases.=20 Phil > On Mar 21, 2015, at 12:41, Leif Johansson wrote: >=20 > On 03/21/2015 08:32 PM, Kepeng Li wrote: >>> It seems like much of this text is copied and changed slightly from the >> API doc. >>=20 >> Yes, but I just copied the general part, and the details are left in the >> API doc. >>=20 >> As Barry mentioned: There are going to be details that'll be left to the >> schema and api documents -- details that have to do with the schema and >> api, of course. But this document could and should talk about the >> general security considerations for what SCIM is doing. >>=20 >> I hope my copied texts have followed that guidance. >>=20 >>> Would it make sense to just link to section 7 of the API doc instead? >>=20 >> I would prefer to keep some general texts in this document, and leave >> the details in the API spec. >>=20 >> But I am open to other people's thoughts. >=20 > I don't think it matters that much what we do here and we should avoid > bikeshedding if we can... >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Sat Mar 21 13:34:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5342A1A882D for ; Sat, 21 Mar 2015 13:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 N7Kr1ZKeCp_P for ; Sat, 21 Mar 2015 13:34:48 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E8B1A8820 for ; Sat, 21 Mar 2015 13:34:48 -0700 (PDT) Received: by wetk59 with SMTP id k59so107326652wet.3 for ; Sat, 21 Mar 2015 13:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wOVDiJrV+kGoB93UhoWup0fo4aIPmI84x9lNw5LsE+E=; b=ajuEBHWtBgDzjlZ7Yuq8lcIXcQSu+oow3OkUcbjdwYGJsRn+Q1QhZRhay0Zqsz+A+A s/Rtg2eQjreUiakKgKEk2mbKvBbiKk3BXUps5NY9PuNw+9iDA7QzD5r6DyHZcaFCWfkL 5Ngm/sKWfz+ecMz1liREaGuh/jygmZ+EhhPgC9HlqAyTouYcXOaBEdUbqWKSZ/YIdG8S zAq6J11O8FTfKbZQupZg7K10jJvzRt80/2tm/RG3L9fcUAYZLEcGWQjUoGbtPR19JYDs PiTWFPFeOQVpOVoUuE0U0i/uTAZyXoJh2X8Rdm0oQd/FEsqi+kgpQR/kpkW4EnM3Bj7b cDWg== X-Gm-Message-State: ALoCoQkf3A4b76FpqRyZ7ZwFssk/4Y/nvr6bduqnyHM+T3gSicVbWVq4LzE9qklMpQBYSl4mCOs6 X-Received: by 10.180.208.33 with SMTP id mb1mr6782669wic.69.1426970086826; Sat, 21 Mar 2015 13:34:46 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:41d2:d297:f46d:1719? ([2001:67c:370:152:41d2:d297:f46d:1719]) by mx.google.com with ESMTPSA id w3sm3853863wiz.5.2015.03.21.13.34.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 13:34:46 -0700 (PDT) Message-ID: <550DD5E4.7020602@mnt.se> Date: Sat, 21 Mar 2015 21:34:44 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Phil Hunt References: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> <550DC95B.1040202@mnt.se> <629A4499-3D48-4A9C-9428-C76FF71C4804@oracle.com> In-Reply-To: <629A4499-3D48-4A9C-9428-C76FF71C4804@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] =?utf-8?q?Re=EF=BC=9A_AD_review_of_draft-ietf-scim-use-cas?= =?utf-8?q?es-04?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 20:34:49 -0000 On 03/21/2015 09:14 PM, Phil Hunt wrote: > I don't have good network access at the moment (or I would check) but it might be good to double check for any editorial conflicts/sync issues between documents. > > In the last couple of api and core-schema revs we made some subtle clarifications that I have not double checked against the use cases. > Can you review when you get bits? From nobody Sat Mar 21 13:52:03 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834411ACDAE for ; Sat, 21 Mar 2015 13:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mz3xKb3bFlB1 for ; Sat, 21 Mar 2015 13:52:00 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 DC0DE1ACDA7 for ; Sat, 21 Mar 2015 13:51:58 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2LKpvlb018804 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Mar 2015 20:51:58 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2LKpvgJ021862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 21 Mar 2015 20:51:57 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2LKpvXO011240; Sat, 21 Mar 2015 20:51:57 GMT Received: from [25.89.209.151] (/72.143.227.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Mar 2015 13:51:57 -0700 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Phil Hunt Mime-Version: 1.0 (1.0) Date: Sat, 21 Mar 2015 13:40:24 -0700 Message-Id: <1130833C-212F-4AEA-A4B5-B17528B1017C@oracle.com> References: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> <550DC95B.1040202@mnt.se> In-Reply-To: <550DC95B.1040202@mnt.se> To: Leif Johansson X-Mailer: iPhone Mail (12B466) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] =?utf-8?q?Re=EF=BC=9A_AD_review_of_draft-ietf-scim-use-cas?= =?utf-8?q?es-04?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 20:52:01 -0000 I don't have good network access at the moment (or I would check) but it mig= ht be good to double check for any editorial conflicts/sync issues between d= ocuments.=20 In the last couple of api and core-schema revs we made some subtle clarifica= tions that I have not double checked against the use cases.=20 Phil > On Mar 21, 2015, at 12:41, Leif Johansson wrote: >=20 > On 03/21/2015 08:32 PM, Kepeng Li wrote: >>> It seems like much of this text is copied and changed slightly from the >> API doc. >>=20 >> Yes, but I just copied the general part, and the details are left in the >> API doc. >>=20 >> As Barry mentioned: There are going to be details that'll be left to the >> schema and api documents -- details that have to do with the schema and >> api, of course. But this document could and should talk about the >> general security considerations for what SCIM is doing. >>=20 >> I hope my copied texts have followed that guidance. >>=20 >>> Would it make sense to just link to section 7 of the API doc instead? >>=20 >> I would prefer to keep some general texts in this document, and leave >> the details in the API spec. >>=20 >> But I am open to other people's thoughts. >=20 > I don't think it matters that much what we do here and we should avoid > bikeshedding if we can... >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Mon Mar 23 07:45:16 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9D1A8AD8 for ; Mon, 23 Mar 2015 07:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 7-u7DMDYEX0Z for ; Mon, 23 Mar 2015 07:45:14 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAF31A8AAA for ; Mon, 23 Mar 2015 07:45:14 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2NEjCwD013136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Mar 2015 14:45:13 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2NEjBcf023313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Mar 2015 14:45:12 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t2NEjBtX005109; Mon, 23 Mar 2015 14:45:11 GMT Received: from dhcp-b274.meeting.ietf.org (/31.133.178.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 23 Mar 2015 07:45:11 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: <550DD5E4.7020602@mnt.se> Date: Mon, 23 Mar 2015 09:45:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> <550DC95B.1040202@mnt.se> <629A4499-3D48-4A9C-9428-C76FF71C4804@oracle.com> <550DD5E4.7020602@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.2070.6) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:45:15 -0000 Leif, I think the document is ok. One thing I wonder about is the emphasis on = triggers. In reality, the SCIM specs simply specify protocol for CRUD = operations without looking at the motivation (as the use case documents = do) for why an operation would be invoked. The document does make this = clear that the core specs: > Triggers may not be relevant at the protocol or the schema, > they really serve to help identify the type or activity that = resulted > in a SCIM protocol exchange. That said, I note the new =E2=80=9CNotify=E2=80=9D drafts specify a way = for formalize =E2=80=9Ctriggers=E2=80=9D that cause SCIM protocol = commands to be issued. In that sense, the document fits well including the new potential items = the WG is considering. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 21, 2015, at 3:34 PM, Leif Johansson wrote: >=20 > On 03/21/2015 09:14 PM, Phil Hunt wrote: >> I don't have good network access at the moment (or I would check) but = it might be good to double check for any editorial conflicts/sync issues = between documents.=20 >>=20 >> In the last couple of api and core-schema revs we made some subtle = clarifications that I have not double checked against the use cases.=20 >>=20 >=20 > Can you review when you get bits? >=20 From nobody Mon Mar 23 08:25:38 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854D01A8AE0 for ; Mon, 23 Mar 2015 08:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 G1lQiYZO395R for ; Mon, 23 Mar 2015 08:25:34 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2281A89FF for ; Mon, 23 Mar 2015 08:25:27 -0700 (PDT) Received: by wetk59 with SMTP id k59so140801412wet.3 for ; Mon, 23 Mar 2015 08:25:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RXbk9ItehUgVYDCpgfXZhbFMKPYOXsDNm98503Ljp3I=; b=Ma1IEcZsEJw7ZqGmSHH2xEv8UrzsAO48P5iJCAe7EJfhm0xjCRwmqomT1HzmCToK8b MthQc4qS4xCVs5qVMg2V77ggJ3P+Tjz23cZo81rsIPV4hgMTSaZwoIhI8RR2aG79zjF7 mrM2CnL36Z06vqBaiyKdMNUpc62mV4PTchQaw4V+eKPDorCKMijGMGiu3Phm4QvMIskS fHreXEuJEwWES5GKZq3O5w9er1yZJJDTjMve5ftJF4+2DKDL5gxJytQ/JjFx1ATAwwd+ EvB7PuPucV8eCdgPXa5A/5zCqLGyA6VRYHVmNJIwGaPkFoFQkpHp5R7k2jTq8Imk4H7M N+UQ== X-Gm-Message-State: ALoCoQmFJctvOCLYzkl0viLF1M+zF5rHvHDugYnJ1Uipl5KQg3UFPey9AJAIgM/ZDdmpGBdxw8po X-Received: by 10.194.192.167 with SMTP id hh7mr188372499wjc.151.1427124325851; Mon, 23 Mar 2015 08:25:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:152:b4ce:36bc:aec7:7670? ([2001:67c:370:152:b4ce:36bc:aec7:7670]) by mx.google.com with ESMTPSA id ew13sm11624298wid.1.2015.03.23.08.25.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2015 08:25:25 -0700 (PDT) Message-ID: <55103063.4090101@mnt.se> Date: Mon, 23 Mar 2015 16:25:23 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Phil Hunt References: <8c45c27b-3da5-4fe6-bf8a-3385eb6cda93@alibaba-inc.com> <550DC95B.1040202@mnt.se> <629A4499-3D48-4A9C-9428-C76FF71C4804@oracle.com> <550DD5E4.7020602@mnt.se> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] AD review of draft-ietf-scim-use-cases-04 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:25:36 -0000 On 03/23/2015 03:45 PM, Phil Hunt wrote: > Leif, > > I think the document is ok. One thing I wonder about is the emphasis on triggers. In reality, the SCIM specs simply specify protocol for CRUD operations without looking at the motivation (as the use case documents do) for why an operation would be invoked. The document does make this clear that the core specs: >> Triggers may not be relevant at the protocol or the schema, >> they really serve to help identify the type or activity that resulted >> in a SCIM protocol exchange. > > > That said, I note the new “Notify†drafts specify a way for formalize “triggers†that cause SCIM protocol commands to be issued. > > In that sense, the document fits well including the new potential items the WG is considering. > Good! Note that the point of the uc document is not for the WG to be governed by the use-cases set down (we have the charter for that) but rather that the WG (and future efforts in this area) be informed about what use-cases were initial motivation for scim. So discrepancies between the uc doc and future extensions of scim may not necessarily be a problem per se - it may just be the natural way the scim community evolves. > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Mar 21, 2015, at 3:34 PM, Leif Johansson wrote: >> >> On 03/21/2015 09:14 PM, Phil Hunt wrote: >>> I don't have good network access at the moment (or I would check) but it might be good to double check for any editorial conflicts/sync issues between documents. >>> >>> In the last couple of api and core-schema revs we made some subtle clarifications that I have not double checked against the use cases. >>> >> >> Can you review when you get bits? >> > From nobody Tue Mar 24 08:37:56 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615441A8932; Tue, 24 Mar 2015 08:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 HhG9p2icMx6w; Tue, 24 Mar 2015 08:37:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AE11A8954; Tue, 24 Mar 2015 08:37:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324153745.26929.78778.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:37:45 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-use-cases-05.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:37:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the System for Cross-domain Identity Management Working Group of the IETF. Title : System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows Authors : Phil Hunt Bhumip Khasnabish Anthony Nadalin Kepeng LI Zachary Zeltsan Filename : draft-ietf-scim-use-cases-05.txt Pages : 18 Date : 2015-03-24 Abstract: This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's models and flows, and includes user scenarios, use cases, and requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-scim-use-cases-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 24 08:37:58 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0ED1A895C; Tue, 24 Mar 2015 08:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mGScWsleloTF; Tue, 24 Mar 2015 08:37:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B1A1A8963; Tue, 24 Mar 2015 08:37:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324153745.26929.30213.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:37:45 -0700 Archived-At: Subject: [scim] New Version Notification - draft-ietf-scim-use-cases-05.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:37:54 -0000 A new version (-05) has been submitted for draft-ietf-scim-use-cases: http://www.ietf.org/internet-drafts/draft-ietf-scim-use-cases-05.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-scim-use-cases-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Mar 24 08:40:50 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22E51A8972 for ; Tue, 24 Mar 2015 08:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 fB2zHt17s1wx for ; Tue, 24 Mar 2015 08:40:45 -0700 (PDT) Received: from out4133-114.mail.aliyun.com (out4133-114.mail.aliyun.com [42.120.133.114]) by ietfa.amsl.com (Postfix) with ESMTP id 1679C1A89AA for ; Tue, 24 Mar 2015 08:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1427211631; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=oGeJbaELql7TxLq09npHDB3FIJO9dlqhAwCuwSfKAtE=; b=Oofh50wyhORmnu6/myOvyyWXaheq0g69Qe81rQn5/seA2XezviasKW9stCa1W5Rik5AmMb+RJhLfD5npasBh8T8WikBs0ojr4DH/i3uVXI+XGrRoC0ZXCdijRnZl5F26C4oNdaR4ZhqqbFMPPt37DEsjL2YDDQKNMS54BEsQZHw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05024; MF=kepeng.lkp@alibaba-inc.com; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (kepeng.lkp@alibaba-inc.com[31.133.161.253]) by r41g03020.xy2.aliyun.com at Tue, 24 Mar 2015 23:40:30 +0800 Date: Tue, 24 Mar 2015 23:40:30 +0800 From: "Kepeng Li" To: "scim" Message-ID: <16f89d07-142a-4962-b942-62fdc6c62d1b@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2687495 MIME-Version: 1.0 References: 20150324153745.26929.30213.idtracker@ietfa.amsl.com In-Reply-To: 20150324153745.26929.30213.idtracker@ietfa.amsl.com Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_13396_4fcc8940_5511856e_102b" Archived-At: Cc: Barry Leiba Subject: [scim] =?utf-8?q?Fw=EF=BC=9ANew_Version_Notification_-_draft-ietf?= =?utf-8?q?-scim-use-cases-05=2Etxt?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Kepeng Li List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:40:47 -0000 ------=ALIBOUNDARY_13396_4fcc8940_5511856e_102b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Barry, and all,Please find the updated version according to Barry's feed= back and recent discussions.Thanks,Kind RegardsKepeng-------------------------= -----------------------------------------=0A=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A= internet-drafts =0A=E5=8F=91=E9=80=81=E6=97=B6=E9=97= =B4=EF=BC=9A2015=E5=B9=B43=E6=9C=8824=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 23= :37=0A=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9Adraft-ietf-scim-use-cases ; draft-ietf-scim-use-cases.shepherd ; draft-ietf-scim-use-cases.ad ; scim-chairs ; scim ; barryleiba =0A=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9A= New Version Notification - draft-ietf-scim-use-cases-05.txt=0A=0A=0AA new vers= ion (-05) has been submitted for draft-ietf-scim-use-cases:=0Ahttp://www.ietf.= org/internet-drafts/draft-ietf-scim-use-cases-05.txt=0A=0ASub state has been c= hanged to AD Followup from Revised ID Needed=0A=0A=0AThe IETF datatracker page= for this Internet-Draft is:=0Ahttps://datatracker.ietf.org/doc/draft-ietf-sci= m-use-cases/=0A=0ADiff from previous version:=0Ahttp://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-scim-use-cases-05=0A=0APlease note that it may take a couple o= f minutes from the time of submission=0Auntil the htmlized version and diff ar= e available at tools.ietf.org.=0A=0AIETF Secretariat. ------=ALIBOUNDARY_13396_4fcc8940_5511856e_102b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Barry, and all,

Please find the updated version acco= rding to Barry's feedback and recent discussions.

Thanks,

Kind Regards
Kepeng
=
------------------------------------------------------------------=
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9Ainternet-drafts <internet-drafts@ie= tf.org>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2015=E5=B9=B43=E6=9C= =8824=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 23:37
=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9Adraft-ietf-scim-use-cases <draft-ietf-scim-use-cases@ietf.org>;= draft-ietf-scim-use-cases.shepherd <draft-ietf-scim-use-cases.shepherd@iet= f.org>; draft-ietf-scim-use-cases.ad <draft-ietf-scim-use-cases.ad@ietf.= org>; scim-chairs <scim-chairs@ietf.org>; scim <scim@ietf.org>;= barryleiba <barryleiba@computer.org>
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC= =9ANew Version Notification - draft-ietf-scim-use-cases-05.txt

A new version (-05) has been submitted for draft-ietf-scim-use-cases:
htt= p://www.ietf.org/internet-drafts/draft-ietf-scim-use-cases-05.txt

Sub s= tate has been changed to AD Followup from Revised ID Needed


The IET= F datatracker page for this Internet-Draft is:
https://datatracker.ietf.org= /doc/draft-ietf-scim-use-cases/

Diff from previous version:
http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-scim-use-cases-05

Please note tha= t it may take a couple of minutes from the time of submission
until the htm= lized version and diff are available at tools.ietf.org.

IETF Secretaria= t.
------=ALIBOUNDARY_13396_4fcc8940_5511856e_102b-- From nobody Tue Mar 24 08:42:26 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC71A8A64 for ; Tue, 24 Mar 2015 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 QXfEDxwx-gu8 for ; Tue, 24 Mar 2015 08:42:20 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF651A8A6B for ; Tue, 24 Mar 2015 08:42:11 -0700 (PDT) Received: by ignm3 with SMTP id m3so54208603ign.0 for ; Tue, 24 Mar 2015 08:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iJ8TzC9V9M9ME5ZVhm95hKTXafMHl/L81/8hu/O91q0=; b=Ps5qRyznXq0bA74A4p5FxZOnILmkE8fsq6X6L1EyCQzWFoUHCmKNpP/ehlFkB92R6d 8G5eqaFXQEtGY44qs6bjA8kWuRk2Y3t81lG/LpoeICgoqrZbAP5mSnqIBOjRKz9IRw6G EXSSD5blOyf8nyME7S7KzxGMPBPLI2B2mU3AUY/t9epKhebJ8XPPi7MoReY5NKQbJvfv 6Z+9fvvGnLXJ5vKA+lDRrTw/rohoooybCbWqEBmgbxUJa+SuAL2WX8lc/vqWEEvcIfad afwIxrAt5Db8ziOm9VaUifnJ37KcFZvLPVwZGaDVjb+72M9DOFtTIzJ/jh1CJe2XoHIr x/KQ== MIME-Version: 1.0 X-Received: by 10.107.12.70 with SMTP id w67mr7599000ioi.10.1427211730817; Tue, 24 Mar 2015 08:42:10 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.173.134 with HTTP; Tue, 24 Mar 2015 08:42:10 -0700 (PDT) In-Reply-To: <16f89d07-142a-4962-b942-62fdc6c62d1b@alibaba-inc.com> References: <16f89d07-142a-4962-b942-62fdc6c62d1b@alibaba-inc.com> Date: Tue, 24 Mar 2015 11:42:10 -0400 X-Google-Sender-Auth: wG9f4BgDtPbdVGwsWt8j--6BB_g Message-ID: From: Barry Leiba To: Kepeng Li Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: scim Subject: Re: [scim] =?utf-8?q?Fw=EF=BC=9ANew_Version_Notification_-_draft-ietf?= =?utf-8?q?-scim-use-cases-05=2Etxt?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:42:22 -0000 > Please find the updated version according to Barry's feedback and recent > discussions. And I'm ready to put the "request last call" button on that as soon as the shepherd confirms. Barry From nobody Tue Mar 24 10:07:43 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2CE1A8A01 for ; Tue, 24 Mar 2015 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 bwhspBfGYh3m for ; Tue, 24 Mar 2015 10:07:41 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FBF1A8A57 for ; Tue, 24 Mar 2015 10:07:40 -0700 (PDT) Received: by oier21 with SMTP id r21so173507894oie.1 for ; Tue, 24 Mar 2015 10:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=SwJS6p9wEZQxN5q1WdeX7Gmuunaudnf9dK9UByiM3Kk=; b=WKxz+J1PMvqQWk6ISzqtUCdfFGSurWMG5Bhta2HZwjv6hM6yQp26ZkxzzzBNrWp+LE htW5A1Z55STYhl1ATt64nklEWWjPlQ3KGmTq4pl8k8TJByZlNfQrWPk57wjZb62DJd4d As2GcOgbnHFUyC/YR45CWmXIFhrkzQJvDV06WkKqE+bg/XBa/vBIkFf3VFbOVKpJGP5g TPiKgqsbhSZKwjZu4iwvyRobOxAVnw+p5CIGvsNxbHkUSMygxdwqDrBLaZke0yl7/jRc xiOsq68MPt5wl/ctdowiIhXebBmmrgV+G7QGCZtA0+9xI7nEBUj+dlDJ6qvwuewHQZHy tm8Q== X-Gm-Message-State: ALoCoQmfxJn8gkPRezZ7Bhf4aX6ylz45N+HY8j1by0HlyJzGKOhswaHs1I8igvGrcDZOGGqOjD+8 X-Received: by 10.202.196.135 with SMTP id u129mr3752771oif.69.1427216860386; Tue, 24 Mar 2015 10:07:40 -0700 (PDT) Received: from [172.16.86.24] ([199.227.110.154]) by mx.google.com with ESMTPSA id z125sm2498622oia.11.2015.03.24.10.07.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 10:07:39 -0700 (PDT) Message-ID: <551199D9.6060106@mnt.se> Date: Tue, 24 Mar 2015 18:07:37 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [scim] slides... X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:07:42 -0000 folks who are on the agenda for Dallas should feel free to send in slides (or tell me and Morteza that no slides are needed) sometime before the session starts on Thursday afternoon ;-) Cheers Leif From nobody Tue Mar 24 10:19:05 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAF51AC3B1 for ; Tue, 24 Mar 2015 10:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 3O2t5jTA0Maf for ; Tue, 24 Mar 2015 10:18:57 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E201ABB19 for ; Tue, 24 Mar 2015 10:18:44 -0700 (PDT) Received: by oiag65 with SMTP id g65so173649756oia.2 for ; Tue, 24 Mar 2015 10:18:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZCN9FaD+D7Grp+a4BIASmsYopvoS3r5qZcLQto8H/Ec=; b=LSikPFzC9cwhakr49uw2S2BqvhLMF9s7ePtfOHrJAlK7BNnEqH72WTtZSVMYcBkgIb 1Lc7coSMVCjMarcVoO77P9IuFX0sCvsNEK43AhciZi+I8DmiSw/YVpk7bCabMu56xDl+ sdSPlNuYu2gIY8j2hOqDQ+eqQf6xJWYmyR0s6enHxj5qoiSESX9hPh1OP/fRmydF2hTe Xry+yKHtFYV9Rjn35AnxRqcmBZGBVwCYxTiZo2xYLbac0pWwb/K3NDS95KLe1DxD+1U+ +/3cRMl/WtT8Wm5gEenN00y/85bW9FgxuTNq8tAQbx6tAAPaYqTS+gurrLlqJslEqp2q kJnw== X-Gm-Message-State: ALoCoQlUFER5S/CDr6NEkT3f9HU6EzRopoKV5IFGMTpSXVTGMgES1N9uqansGVE6SsIqwMtaTXvE X-Received: by 10.202.209.130 with SMTP id i124mr3862871oig.108.1427217523785; Tue, 24 Mar 2015 10:18:43 -0700 (PDT) Received: from [172.16.86.24] ([199.227.110.154]) by mx.google.com with ESMTPSA id v4sm2481669oec.7.2015.03.24.10.18.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 10:18:42 -0700 (PDT) Message-ID: <55119C71.6070305@mnt.se> Date: Tue, 24 Mar 2015 18:18:41 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: scim@ietf.org References: <16f89d07-142a-4962-b942-62fdc6c62d1b@alibaba-inc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [scim] =?utf-8?q?Fw=EF=BC=9ANew_Version_Notification_-_draft-ietf?= =?utf-8?q?-scim-use-cases-05=2Etxt?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 17:18:59 -0000 On 03/24/2015 04:42 PM, Barry Leiba wrote: >> Please find the updated version according to Barry's feedback and recent >> discussions. > > And I'm ready to put the "request last call" button on that as soon as > the shepherd confirms. > go From nobody Tue Mar 24 12:00:52 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FAD1A8A74 for ; Tue, 24 Mar 2015 12:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.311 X-Spam-Level: X-Spam-Status: No, score=-11.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 f_dQ8bCeAEOM for ; Tue, 24 Mar 2015 12:00:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4A41A8A97 for ; Tue, 24 Mar 2015 12:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=491; q=dns/txt; s=iport; t=1427223641; x=1428433241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BNF7Wa3toLghB4xL8hRqwb3IkL86spi5n7dIYvTelDo=; b=j5p03pWdh63uU4FlK4jBpkmMAkaSbKudSqGB3EZcnOiAwNqEQFT2s57T fX1nKHotvqI+LBEkIdys95A5DUFD7JjRLKqrVpGU7+22L24lZ1v5lKBzN bUNntoyN6iKCPRIwINJHjQRRkBUxsiK6dOTLPrWd8G0oVDS+rs4OF7MR1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+BwCzsxFV/4cNJK1cgwZSWgSDDsB9gjEKhXUCgUJMAQEBAQEBfYQVAQEDAQEBAR4BTAkCEAIBCBkDCxoDAicLGgQHAgQBDQWIJwgNkhiccQGaGgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgR6KA4R2B4JlgUgBBJBQiW+BG4Mwj2Eig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,459,1422921600"; d="scan'208";a="406280575" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP; 24 Mar 2015 19:00:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2OJ0eHX002085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 19:00:40 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 14:00:40 -0500 From: "Morteza Ansari (moransar)" To: Barry Leiba , Kepeng Li Thread-Topic: =?iso-2022-jp?B?W3NjaW1dIEZ3GyRCIScbKEJOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?iso-2022-jp?B?LSBkcmFmdC1pZXRmLXNjaW0tdXNlLWNhc2VzLTA1LnR4dA==?= Thread-Index: AQHQZkki7oRnKisVlk69HPwpmvtQzJ0r/RCA Date: Tue, 24 Mar 2015 19:00:39 +0000 Message-ID: References: <16f89d07-142a-4962-b942-62fdc6c62d1b@alibaba-inc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.6.64] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <637C245D4C40044DB909E531BA4BFC69@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: scim Subject: Re: [scim] =?iso-2022-jp?b?RncbJEIhJxsoQk5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?iso-2022-jp?b?dGlvbiAtIGRyYWZ0LWlldGYtc2NpbS11c2UtY2FzZXMtMDUudHh0?= X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 19:00:50 -0000 Sorry, was on a plane this morning. Looks good to me. Cheers, Morteza On 3/24/15, 10:42 AM, "Barry Leiba" wrote: >> Please find the updated version according to Barry's feedback and recent >> discussions. > >And I'm ready to put the "request last call" button on that as soon as >the shepherd confirms. > >Barry > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Tue Mar 24 12:33:51 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB61A8AE9; Tue, 24 Mar 2015 12:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 fxorMynhJBSR; Tue, 24 Mar 2015 12:33:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 026E11A8AD1; Tue, 24 Mar 2015 12:33:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150324193347.4705.56954.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 12:33:47 -0700 Archived-At: Cc: scim@ietf.org Subject: [scim] Last Call: (System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows) to Informational RFC X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 19:33:49 -0000 The IESG has received a request from the System for Cross-domain Identity Management WG (scim) to consider the following document: - 'System for Cross-domain Identity Management (SCIM) Definitions, Overview, and Flows' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's models and flows, and includes user scenarios, use cases, and requirements. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-scim-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From haavar.valeur@citrix.com Tue Mar 24 15:06:51 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2741A1B2B for ; Tue, 24 Mar 2015 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Up2v1jA1NqEk for ; Tue, 24 Mar 2015 15:06:48 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A559F1ACC8D for ; Tue, 24 Mar 2015 15:06:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,460,1422921600"; d="scan'208,217";a="246372704" From: Haavar Valeur To: Anthony Nadalin Thread-Topic: [scim] SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgAChu4CAAAkogIAV+lEA Date: Tue, 24 Mar 2015 22:05:57 +0000 Message-ID: <5B258021-4D90-47CB-9FF3-B7A0D80224EE@citrix.com> References: <8567D035-16D0-4668-B1A7-5D7D1A36835D@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5B2580214D9047CB9FF3B7A0D80224EEcitrixcom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" , Phil Hunt Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:54:20 -0000 --_000_5B2580214D9047CB9FF3B7A0D80224EEcitrixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgY291cGxlIG9mIGNvbW1lbnRzLg0KDQpJbiBzZWN0aW9uIDIuMyAoU0NJTSBjcmVh dGUpIGl0IHNheXMgdGhhdCDigJxTQ0lNIENyZWF0ZSBTSE9VTEQgTk9UIGlnbm9yZSBuYW1lc3Bh Y2UgY29uZmxpY3Rz4oCm4oCdLCBidXQgaW4gdGhlIGV4YW1wbGUgaXMgc2F5cyB0aGF0IGEgY3Jl YXRlIHdpdGggYSBzb2Z0eSBkZWxldGVkIGNvbmZsaWN0aW5nIHVzZXIgc2hvdWxkIG5vdCBmYWls LiBUaG9zZSB0d28gc3RhdGVtZW50cyBzZWVtcyBjb25mbGljdGluZyB0byBtZS4NCg0KSW4gc2Vj dGlvbiAyLjkgKFNDSU0gaGFyZCBkZWxldGUpLCBpdCBzYXlzIHRoZSB3YXkgdG8gZG8gYSBoYXJk IGRlbGV0ZSBpcyB0byBpbmNsdWRlIGEgcXVlcnkgcGFyYW1ldGVyIGlzU29mdERlbGV0ZWQ9dHJ1 ZS4gVGhhdOKAmXMgbm90IHZlcnkgaW50dWl0aXZlIHRvIG1lLiBJIHVuZGVyc3RhbmQgdGhhdOKA mXMgdGhlIHBhcmFtZXRlciBuYW1lIHVzZWQgaW4gYWxsIHRoZSBmaWx0ZXJzLCBidXQgcGVyaGFw cyBub3QgYSBuYW1lIHN1aXRlZCBmb3IgaW5kaWNhdGluZyBhIGhhcmQgZGVsZXRlLg0KDQoNCk9u IE1hciAxMCwgMjAxNSwgYXQgNToyOCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jv c29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpZZXMsIHNl ZW1zIHNvDQoNCkZyb206IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0K U2VudDogVHVlc2RheSwgTWFyY2ggMTAsIDIwMTUgMjo1NiBQTQ0KVG86IE1vcnRlemEgQW5zYXJp IChtb3JhbnNhcikNCkNjOiBBbnRob255IE5hZGFsaW47IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNj aW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NjaW1dIFNDSU0gU29mdCBEZWxldGUgRHJhZnQN Cg0KV2Fzbid0IHRoZSBvcmlnaW5hbCBwZXJzcGVjdGl2ZSBhbiBpc3N1ZSBvZiB0b21ic3Rvbmlu Zz8NCg0KSSBkbyB0aGluayB0aGlzIHdvdWxkIGJlIGEgZ3JlYXQgb3Bwb3J0dW5pdHkgdG8gZGlz Y3VzcyB0aGUgcmVsYXRpb25zaGlwIHRvIGFjdGl2YXRpb24gYW5kIGRlYWN0aXZhdGlvbi4NCg0K UGhpbA0KDQpPbiBNYXIgMTAsIDIwMTUsIGF0IDE0OjE3LCBNb3J0ZXphIEFuc2FyaSAobW9yYW5z YXIpIDxtb3JhbnNhckBjaXNjby5jb208bWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbT4+IHdyb3Rl Og0KQmVjYXVzZSBJIGhhZG7igJl0IHRob3VnaHQgb2YgaXQgYW5kIGRpZG7igJl0IGhhdmUgYSB1 c2UgY2FzZSBmb3IgaXQgOikNCg0KQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8gIE1pZ2h0IGJlIGlu dGVyZXN0aW5nLg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDEw LCAyMDE1IGF0IDI6MTUgUE0NClRvOiBNb3J0ZXphIEFuc2FyaSA8bW9yYW5zYXJAY2lzY28uY29t PG1haWx0bzptb3JhbnNhckBjaXNjby5jb20+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1A aWV0Zi5vcmc+IiA8c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSRTogU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdA0KDQpXaHkgbm8g4oCcc29mdCBjcmVhdGXigJ0g Pw0KDQpGcm9tOiBNb3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIFttYWlsdG86bW9yYW5zYXJAY2lz Y28uY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTAsIDIwMTUgMTI6MjcgUE0NClRvOiBBbnRo b255IE5hZGFsaW47IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdA0KDQpZZXMuIFRoZXJlIGlzIGEgdmVyeSBzaG9y dCBibHVyYiBhYm91dCB0aGUgZmFjdCB5b3UgY291bGQgcHJvdmlkZSBhZGRpdGlvbmFsIGF0dHJp YnV0ZXMgdG8gcmVzb2x2ZSBhbnkgcG90ZW50aWFsIG5hbWVzcGFjZSBjb25mbGljdHMuIEZvciBl eGFtcGxlIGlmIHlvdSBhcmUgdW5kZWxldGluZyBhIHVzZXIgeW91IGNvdWxkIHNlbmQgYSBuZXcg dXNlck5hbWUgYXMgcGFydCBvZiB0aGUgbW9kaWZ5IHJlcXVlc3Qgc28geW91IHVuZGVsZXRlIHRo ZSB1c2VyIG9iamVjdCBhbmQgcmVzb2x2ZSB0aGUgY29uZmxpY3QuDQoNClRoZSBtb3JlIGludGVy ZXN0aW5nIGNhc2UgaXMgdGhlIHJlZmVyZW5jZXMgYW5kIHdoYXQgdG8gZG8gaW4gdGhvc2UgY2Fz ZXMuIFJlZmVyZW5jZXMgc2hvdWxkIG5vdCBiZSB2aXNpYmxlIGluIGNhc2VzIG9mIHNvZnQgZGVs ZXRlZCBvYmplY3RzLCB0aGUgcXVlc3Rpb24gaXMgaG93IGV4cGVuc2l2ZSBpcyB0byBtYWludGFp biB0aGF0IGluZm9ybWF0aW9uIGFuZCBhZGQgdGhlIGxpbmtzIGFmdGVyIHRoZSBvYmplY3QgaXMg dW5kZWxldGVkLg0KDQpJbiBhIHByb3RvdHlwZSBJIGhhdmUgZG9uZSBvZiB0aGlzLCBJIHRvb2sg dGhlIGVhc3kgcm91dGUgYW5kIGp1c3QgZGVsZXRlZCByZWZlcmVuY2VzIGFuZCB0aGV5IG5lZWQg dG8gYmUgcmUtY3JlYXRlZC4gT2J2aW91c2x5IGl0IHdvcmtzLCBidXQgaXQgaXMgbm90IHRoZSBt b3N0IHVzZWZ1bCBzb2x1dGlvbi4gVGhlbiBhZ2FpbiBpZiB0aGlzIGlzIGEgcHJvdmlzaW9uaW5n IGNhc2UgYW5kIGVzc2VudGlhbGx5IGEgc2xhdmUgb2YgYW5vdGhlciBJRE0gc29sdXRpb24sIGl0 IGNhbiBlYXNpbHkgYmUgcmVjcmVhdGVkLiBUaGUgcmVhbCBwcm9ibGVtIGlzIHByZXNlcnZpbmcg dGhlIElEIG9mIHRoZSB1c2VyIGFuZCByZWluc3RhdGluZyBpdCByYXRoZXIgdGhhbiBnZXR0aW5n IGEgbmV3IElELg0KDQoNCkZyb206IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQu Y29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2gg MTAsIDIwMTUgYXQgMTI6MTQgUE0NClRvOiBNb3J0ZXphIEFuc2FyaSA8bW9yYW5zYXJAY2lzY28u Y29tPG1haWx0bzptb3JhbnNhckBjaXNjby5jb20+PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNj aW1AaWV0Zi5vcmc+IiA8c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSRTogU0NJTSBTb2Z0IERlbGV0ZSBEcmFmdA0KDQpTbyBpZiBJIGRlbGV0ZSAoc29mdCkg YW4gb2JqZWN0IGFuZCB0aGVuIGFkZCBhIG5ldyBvYmplY3Qgd2l0aCB0aGUgc2FtZSBuYW1lLCBh bmQgdGhlbiBJIHVuZGVsZXRlIHRoZSBvYmplY3QgSSBkZWxldGVkIHdvdWxkIHRoZSB1bmRlbGV0 ZSBmYWlsID8NCg0KRnJvbTogc2NpbSBbbWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1vcnRlemEgQW5zYXJpIChtb3JhbnNhcikNClNlbnQ6IE1vbmRheSwgTWFyY2gg OSwgMjAxNSA1OjUwIFBNDQpUbzogc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4N ClN1YmplY3Q6IFtzY2ltXSBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0DQoNClBoaWwgSHVudCBhbmQg SSBwdXQgdG9nZXRoZXIgYSB2ZXJ5IHZlcnkgdmVyeSByb3VnaCBkcmFmdCBmb3IgU0NJTSBzb2Z0 IGRlbGV0ZSBzZW1hbnRpY3MuIFRoZSBkcmFmdCBpcyBtaXNzaW5nIGEgbG90IG9mIGRldGFpbHMg YW5kIHJlcXVpcmUgYSBsb3QgbW9yZSB0aGlua2luZyBidXQgd2Ugd2FudGVkIHRvIHB1dCB0aGUg YmFzaWMgY29uY2VwdCBvdXQgdGhlcmUgZm9yIGRpc2N1c3Npb24gYXQgRGFsbGFzLiBUaGUgaWRl YSBvZiBzb2Z0IGRlbGV0ZS91bmRlbGV0ZSBoYXMgY29tZSB1cCBtYW55IHRpbWVzIGluIHZhcmlv dXMgZm9ydW1zIGFuZCBJIHBlcnNvbmFsbHkgdGhpbmsgaXQgaXMgYSB2ZXJ5IGltcG9ydGFudCBh c3BlY3Qgb2YgcmVhbCBsaWZlIG9wZXJhdGlvbmFsaXppbmcgU0NJTS4NCg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYW5zYXJpLXNjaW0tc29mdC1kZWxldGUvDQoNCkkg d291bGQgbGlrZSBhIHNsb3Qgb24gdGhlIGFnZW5kYSB0byBkaXNjdXNzIHRoaXMgZHJhZnQgYW5k IGdldCBmZWVkYmFjayBmcm9tIHRoZSBXRy4NCg0KDQpDaGVlcnMsDQpNb3J0ZXphDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxp c3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpodHRwczovL3NlY3VyZS13 ZWIuY2lzY28uY29tLzFqYV9XUDhfcmZ2SWZzUzRXMmtBc250MmR3Y3l5V05SLUpsbjJRREZ5SVo3 MjVraEJyUXBtSTJCUVJvemRwSHRwNkxOM3RXMTN4Mkd6SUQwUURKWlRmWjJFLVVLNk9QY09Qczht eTdWT1I2akdLb1JUMnIyWDNEU2NQQUd3dEZ1WF9nY1ZlS0paOWRxMGdkSXpSZ0xiXzBJRWR0dE5k akRRanhONWZuS1BmTEkvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZzY2ltDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5v cmc+DQpodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFqYV9XUDhfcmZ2SWZzUzRXMmtBc250 MmR3Y3l5V05SLUpsbjJRREZ5SVo3MjVraEJyUXBtSTJCUVJvemRwSHRwNkxOM3RXMTN4Mkd6SUQw UURKWlRmWjJFLVVLNk9QY09QczhteTdWT1I2akdLb1JUMnIyWDNEU2NQQUd3dEZ1WF9nY1ZlS0pa OWRxMGdkSXpSZ0xiXzBJRWR0dE5kakRRanhONWZuS1BmTEkvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0 Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltDQoNCg== --_000_5B2580214D9047CB9FF3B7A0D80224EEcitrixcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUg YSBjb3VwbGUgb2YgY29tbWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBzZWN0aW9uIDIuMyAoU0NJTSBjcmVhdGUpIGl0IHNh eXMgdGhhdCDigJw8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxZW07IiBjbGFzcz0iIj5TQ0lNIENy ZWF0ZSBTSE9VTEQgTk9UIGlnbm9yZSBuYW1lc3BhY2UgY29uZmxpY3RzPC9zcGFuPuKApuKAnSwg YnV0IGluIHRoZSBleGFtcGxlIGlzIHNheXMgdGhhdCBhIGNyZWF0ZSB3aXRoIGEgc29mdHkgZGVs ZXRlZCBjb25mbGljdGluZyB1c2VyIHNob3VsZCBub3QgZmFpbC4gVGhvc2UNCiB0d28gc3RhdGVt ZW50cyBzZWVtcyBjb25mbGljdGluZyB0byBtZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkluIHNlY3Rpb24gMi45IChTQ0lNIGhhcmQg ZGVsZXRlKSwgaXQgc2F5cyB0aGUgd2F5IHRvIGRvIGEgaGFyZCBkZWxldGUgaXMgdG8gaW5jbHVk ZSBhIHF1ZXJ5IHBhcmFtZXRlciZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiIGNs YXNzPSIiPmlzU29mdERlbGV0ZWQ9dHJ1ZS4gVGhhdDwvc3Bhbj7igJk8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxZW07IiBjbGFzcz0iIj5zIG5vdCB2ZXJ5Jm5ic3A7PC9zcGFuPmludHVpdGl2ZTxz cGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiIGNsYXNzPSIiPiZuYnNwO3RvDQogbWUuIEkmbmJz cDs8L3NwYW4+dW5kZXJzdGFuZDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsiIGNsYXNzPSIi PiZuYnNwOzwvc3Bhbj50aGF04oCZcyB0aGUgcGFyYW1ldGVyIG5hbWUgdXNlZCBpbiBhbGwgdGhl IGZpbHRlcnMsIGJ1dCBwZXJoYXBzIG5vdCBhIG5hbWUgc3VpdGVkIGZvciBpbmRpY2F0aW5nIGEg aGFyZCBkZWxldGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMTAsIDIwMTUsIGF0IDU6MjggUE0sIEFudGhvbnkg TmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgY2xhc3M9 IiI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlllcywgc2VlbXMg c288bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxl OiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsg Ym9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWwgSHVudCBb PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgTWFyY2ggMTAsIDIw MTUgMjo1NiBQTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9ydGV6YSBBbnNhcmkgKG1vcmFu c2FyKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QW50aG9ueSBOYWRhbGluOzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+c2NpbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UmU6IFtzY2ltXSBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0PG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCldhc24ndCB0aGUgb3JpZ2luYWwgcGVyc3BlY3RpdmUgYW4gaXNzdWUgb2YgdG9t YnN0b25pbmc/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkkgZG8gdGhpbmsg dGhpcyB3b3VsZCBiZSBhIGdyZWF0IG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MgdGhlIHJlbGF0aW9u c2hpcCB0byBhY3RpdmF0aW9uIGFuZCBkZWFjdGl2YXRpb24uJm5ic3A7PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KUGhpbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiPg0KPGJyIGNsYXNzPSIiPg0KT24gTWFyIDEwLCAyMDE1LCBhdCAxNDoxNywgTW9ydGV6 YSBBbnNhcmkgKG1vcmFuc2FyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNv bSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+bW9yYW5zYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdp bi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQmVjYXVz ZSBJIGhhZG7igJl0IHRob3VnaHQgb2YgaXQgYW5kIGRpZG7igJl0IGhhdmUgYSB1c2UgY2FzZSBm b3IgaXQgOik8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQ2FuIHlvdSBwbGVh c2UgZXhwbGFpbj8gJm5ic3A7TWlnaHQgYmUgaW50ZXJlc3RpbmcuPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9y ZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7 IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5G cm9tOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWls dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5UdWVzZGF5LCBNYXJjaCAxMCwgMjAxNSBhdCAy OjE1IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Nb3J0ZXphIEFuc2FyaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bW9yYW5zYXJAY2lzY28uY29tPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zY2ltQGlldGYub3Jn PC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2NpbUBp ZXRmLm9yZzwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJFOiBTQ0lNIFNv ZnQgRGVsZXRlIERyYWZ0PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+V2h5IG5vIOKAnHNvZnQgY3JlYXRl4oCdID88L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1 LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9y dGV6YSBBbnNhcmkgKG1vcmFuc2FyKSBbPGEgaHJlZj0ibWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNv bSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+bWFpbHRvOm1vcmFuc2FyQGNpc2NvLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNl bnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5U dWVzZGF5LCBNYXJjaCAxMCwgMjAxNSAxMjoyNyBQTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi PlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ QW50aG9ueSBOYWRhbGluOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2NpbUBpZXRmLm9yZzwv YT48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFNDSU0gU29mdCBEZWxldGUgRHJh ZnQ8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlllcy4gVGhl cmUgaXMgYSB2ZXJ5IHNob3J0IGJsdXJiIGFib3V0IHRoZSBmYWN0IHlvdSBjb3VsZCBwcm92aWRl IGFkZGl0aW9uYWwgYXR0cmlidXRlcyB0byByZXNvbHZlIGFueSBwb3RlbnRpYWwgbmFtZXNwYWNl IGNvbmZsaWN0cy4gRm9yIGV4YW1wbGUgaWYgeW91IGFyZSB1bmRlbGV0aW5nIGEgdXNlciB5b3Ug Y291bGQNCiBzZW5kIGEgbmV3IHVzZXJOYW1lIGFzIHBhcnQgb2YgdGhlIG1vZGlmeSByZXF1ZXN0 IHNvIHlvdSB1bmRlbGV0ZSB0aGUgdXNlciBvYmplY3QgYW5kIHJlc29sdmUgdGhlIGNvbmZsaWN0 Ljwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+VGhlIG1vcmUgaW50ZXJlc3RpbmcgY2Fz ZSBpcyB0aGUgcmVmZXJlbmNlcyBhbmQgd2hhdCB0byBkbyBpbiB0aG9zZSBjYXNlcy4gUmVmZXJl bmNlcyBzaG91bGQgbm90IGJlIHZpc2libGUgaW4gY2FzZXMgb2Ygc29mdCBkZWxldGVkIG9iamVj dHMsIHRoZSBxdWVzdGlvbiBpcyBob3cgZXhwZW5zaXZlIGlzIHRvIG1haW50YWluDQogdGhhdCBp bmZvcm1hdGlvbiBhbmQgYWRkIHRoZSBsaW5rcyBhZnRlciB0aGUgb2JqZWN0IGlzIHVuZGVsZXRl ZC48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkluIGEgcHJvdG90eXBlIEkgaGF2ZSBk b25lIG9mIHRoaXMsIEkgdG9vayB0aGUgZWFzeSByb3V0ZSBhbmQganVzdCBkZWxldGVkIHJlZmVy ZW5jZXMgYW5kIHRoZXkgbmVlZCB0byBiZSByZS1jcmVhdGVkLiBPYnZpb3VzbHkgaXQgd29ya3Ms IGJ1dCBpdCBpcyBub3QgdGhlIG1vc3QgdXNlZnVsIHNvbHV0aW9uLiBUaGVuDQogYWdhaW4gaWYg dGhpcyBpcyBhIHByb3Zpc2lvbmluZyBjYXNlIGFuZCBlc3NlbnRpYWxseSBhIHNsYXZlIG9mIGFu b3RoZXIgSURNIHNvbHV0aW9uLCBpdCBjYW4gZWFzaWx5IGJlIHJlY3JlYXRlZC4gVGhlIHJlYWwg cHJvYmxlbSBpcyBwcmVzZXJ2aW5nIHRoZSBJRCBvZiB0aGUgdXNlciBhbmQgcmVpbnN0YXRpbmcg aXQgcmF0aGVyIHRoYW4gZ2V0dGluZyBhIG5ldyBJRC48L3NwYW4+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xv cjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNw dCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Gcm9tOjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBt aWNyb3NvZnQuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OzxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPkRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5UdWVzZGF5LCBNYXJjaCAxMCwgMjAxNSBhdCAxMjoxNCBQTTxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9ydGV6YSBBbnNhcmkgJmx0OzxhIGhyZWY9Im1haWx0bzpt b3JhbnNhckBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPm1vcmFuc2FyQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8 YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2NpbUBpZXRmLm9yZzwvYT4mcXVvdDsN CiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNjaW1AaWV0Zi5vcmc8L2E+ Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SRTogU0NJTSBTb2Z0IERlbGV0ZSBE cmFmdDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+U28gaWYgSSBkZWxldGUgKHNvZnQpIGFuIG9iamVjdCBhbmQgdGhl biBhZGQgYSBuZXcgb2JqZWN0IHdpdGggdGhlIHNhbWUgbmFtZSwgYW5kIHRoZW4gSSB1bmRlbGV0 ZSB0aGUgb2JqZWN0IEkgZGVsZXRlZCB3b3VsZCB0aGUgdW5kZWxldGUgZmFpbCA/PC9zcGFuPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3At Y29sb3I6IHJnYigyMjUsIDIyNSwgMjI1KTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5n OiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPnNjaW0gWzxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5v cmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPm1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5Pbg0KIEJlaGFsZiBP ZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TW9y dGV6YSBBbnNhcmkgKG1vcmFuc2FyKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXks IE1hcmNoIDksIDIwMTUgNTo1MCBQTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnNjaW1AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPltzY2ltXSBTQ0lNIFNvZnQgRGVsZXRlIERyYWZ0PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPiZu YnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+UGhpbCBIdW50IGFuZCBJIHB1dCB0b2dldGhlciBhIHZlcnkgdmVyeSB2ZXJ5IHJv dWdoIGRyYWZ0IGZvciBTQ0lNIHNvZnQgZGVsZXRlIHNlbWFudGljcy4gVGhlIGRyYWZ0IGlzIG1p c3NpbmcgYSBsb3Qgb2YgZGV0YWlscyBhbmQgcmVxdWlyZSBhIGxvdCBtb3JlIHRoaW5raW5nIGJ1 dCB3ZSB3YW50ZWQgdG8gcHV0DQogdGhlIGJhc2ljIGNvbmNlcHQgb3V0IHRoZXJlIGZvciBkaXNj dXNzaW9uIGF0IERhbGxhcy4gVGhlIGlkZWEgb2Ygc29mdCBkZWxldGUvdW5kZWxldGUgaGFzIGNv bWUgdXAgbWFueSB0aW1lcyBpbiB2YXJpb3VzIGZvcnVtcyBhbmQgSSBwZXJzb25hbGx5IHRoaW5r IGl0IGlzIGEgdmVyeSBpbXBvcnRhbnQgYXNwZWN0IG9mIHJlYWwgbGlmZSBvcGVyYXRpb25hbGl6 aW5nIFNDSU0uPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbnNhcmktc2NpbS1zb2Z0LWRlbGV0ZS8i IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFuc2FyaS1zY2ltLXNv ZnQtZGVsZXRlLzwvYT48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkkgd291bGQgbGlr ZSBhIHNsb3Qgb24gdGhlIGFnZW5kYSB0byBkaXNjdXNzIHRoaXMgZHJhZnQgYW5kIGdldCBmZWVk YmFjayBmcm9tIHRoZSBXRy48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5DaGVlcnMsPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPk1vcnRlemE8L3NwYW4+PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7 IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCnNjaW0gbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNj aW1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9zZWN1cmUtd2Vi LmNpc2NvLmNvbS8xamFfV1A4X3Jmdklmc1M0VzJrQXNudDJkd2N5eVdOUi1KbG4yUURGeUlaNzI1 a2hCclFwbUkyQlFSb3pkcEh0cDZMTjN0VzEzeDJHeklEMFFESlpUZloyRS1VSzZPUGNPUHM4bXk3 Vk9SNmpHS29SVDJyMlgzRFNjUEFHd3RGdVhfZ2NWZUtKWjlkcTBnZEl6UmdMYl8wSUVkdHROZGpE UWp4TjVmbktQZkxJL2h0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGc2NpbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xamFfV1A4X3Jmdklm c1M0VzJrQXNudDJkd2N5eVdOUi1KbG4yUURGeUlaNzI1a2hCclFwbUkyQlFSb3pkcEh0cDZMTjN0 VzEzeDJHeklEMFFESlpUZloyRS1VSzZPUGNPUHM4bXk3Vk9SNmpHS29SVDJyMlgzRFNjUEFHd3RG dVhfZ2NWZUtKWjlkcTBnZEl6UmdMYl8wSUVkdHROZGpEUWp4TjVmbktQZkxJL2h0dHBzJTNBJTJG JTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2NpbTwvYT48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5zY2ltDQogbWFpbGluZyBs aXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi PnNjaW1AaWV0Zi5vcmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFqYV9XUDhfcmZ2 SWZzUzRXMmtBc250MmR3Y3l5V05SLUpsbjJRREZ5SVo3MjVraEJyUXBtSTJCUVJvemRwSHRwNkxO M3RXMTN4Mkd6SUQwUURKWlRmWjJFLVVLNk9QY09QczhteTdWT1I2akdLb1JUMnIyWDNEU2NQQUd3 dEZ1WF9nY1ZlS0paOWRxMGdkSXpSZ0xiXzBJRWR0dE5kakRRanhONWZuS1BmTEkvaHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFqYV9XUDhfcmZ2 SWZzUzRXMmtBc250MmR3Y3l5V05SLUpsbjJRREZ5SVo3MjVraEJyUXBtSTJCUVJvemRwSHRwNkxO M3RXMTN4Mkd6SUQwUURKWlRmWjJFLVVLNk9QY09QczhteTdWT1I2akdLb1JUMnIyWDNEU2NQQUd3 dEZ1WF9nY1ZlS0paOWRxMGdkSXpSZ0xiXzBJRWR0dE5kakRRanhONWZuS1BmTEkvaHR0cHMlM0El MkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2ltPC9hPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5B2580214D9047CB9FF3B7A0D80224EEcitrixcom_-- From nobody Tue Mar 24 16:54:49 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0ED1A1A81 for ; Tue, 24 Mar 2015 16:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pZwKpzpQXbcU for ; Tue, 24 Mar 2015 16:54:46 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D841A1A65 for ; Tue, 24 Mar 2015 16:54:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,461,1422921600"; d="scan'208";a="246397974" From: Haavar Valeur To: "scim@ietf.org" Thread-Topic: Organizational unit SCIM extension Thread-Index: AQHQZo3gAZJQG/Uhyk2Fltx5Ryl7+Q== Date: Tue, 24 Mar 2015 23:54:33 +0000 Message-ID: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 23:54:48 -0000 Has there been any discussion around a standard SCIM extension that handles= organizational units (OU)? A quick google search came up with a couple of = emails from 3 years ago, but no real subsidence. =20 If there has not been any discussion around this, is there a reason for it? Best Haavar= From nobody Tue Mar 24 17:16:00 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610AC1A1BBC for ; Tue, 24 Mar 2015 17:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LZkXJIJsPq5Y for ; Tue, 24 Mar 2015 17:15:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF2B1A1BC2 for ; Tue, 24 Mar 2015 17:15:57 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2P0FsKn003576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2015 00:15:55 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t2P0Fsbn009211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2015 00:15:54 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2P0FsDj020315; Wed, 25 Mar 2015 00:15:54 GMT Received: from [172.16.89.33] (/199.227.110.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Mar 2015 17:15:54 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12B466) In-Reply-To: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> Date: Tue, 24 Mar 2015 19:15:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <51F3F00D-1280-4F70-BFCA-EF1ED2CC9E29@oracle.com> References: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> To: Haavar Valeur X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 00:15:59 -0000 It depends... If you want hierarchy like ldap, there is no way to do this as scim is flat e= xcept for resource type.=20 If you just want to define organizations as their own resource type it would= be fairly easy to write this up as an extension. I believe many are doing t= his informally now.=20 Hope this helps.=20 Phil > On Mar 24, 2015, at 18:54, Haavar Valeur wrote:= >=20 > Has there been any discussion around a standard SCIM extension that handle= s organizational units (OU)? A quick google search came up with a couple of e= mails from 3 years ago, but no real subsidence. =20 >=20 > If there has not been any discussion around this, is there a reason for it= ? >=20 > Best > Haavar > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From nobody Tue Mar 24 18:02:54 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD61A1A6E for ; Tue, 24 Mar 2015 18:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZwzcolxaknwE for ; Tue, 24 Mar 2015 18:02:51 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145C61A0419 for ; Tue, 24 Mar 2015 18:02:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,461,1422921600"; d="scan'208";a="246408921" From: Haavar Valeur To: Phil Hunt Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZo3gAZJQG/Uhyk2Fltx5Ryl7+Z0syfYAgAANFgA= Date: Wed, 25 Mar 2015 01:02:47 +0000 Message-ID: <8F483EED-C19E-422E-9DC8-E960D99A5E3F@citrix.com> References: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> <51F3F00D-1280-4F70-BFCA-EF1ED2CC9E29@oracle.com> In-Reply-To: <51F3F00D-1280-4F70-BFCA-EF1ED2CC9E29@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 01:02:53 -0000 SSB3YXMgdGhpbmtpbmcgYWJvdXQgaXQgYXMgaXTigJlzIG93biByZXNvdXJjZSB0eXBlLiBJdCBj b3VsZCBiZSBhIHNpbXBsZSBhcyBzb21ldGhpbmcgc2ltaWxhciB0byBob3cgZ3JvdXBzIHdvcmss IG9yIGl0IGNvdWxkIGJlIG1vcmUgZXh0ZW5zaXZlIGFuZCBpbmNsdWRlIHJ1bGVzL3JvbGVzIGZv ciBkZWxlZ2F0ZWQgYWRtaW5pc3RyYXRpb24uDQoNCkRvZXNu4oCZdCBpdCBtYWtlIHNlbnNlIHRv IG1ha2UgYSBmb3JtYWwgc2NoZW1hIGZvciBPVXM/DQoNCj4gT24gTWFyIDI0LCAyMDE1LCBhdCA3 OjE1IFBNLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPiB3cm90ZToNCj4gDQo+IEl0 IGRlcGVuZHMuLi4NCj4gDQo+IElmIHlvdSB3YW50IGhpZXJhcmNoeSBsaWtlIGxkYXAsIHRoZXJl IGlzIG5vIHdheSB0byBkbyB0aGlzIGFzIHNjaW0gaXMgZmxhdCBleGNlcHQgZm9yIHJlc291cmNl IHR5cGUuIA0KPiANCj4gSWYgeW91IGp1c3Qgd2FudCB0byBkZWZpbmUgb3JnYW5pemF0aW9ucyBh cyB0aGVpciBvd24gcmVzb3VyY2UgdHlwZSBpdCB3b3VsZCBiZSBmYWlybHkgZWFzeSB0byB3cml0 ZSB0aGlzIHVwIGFzIGFuIGV4dGVuc2lvbi4gSSBiZWxpZXZlIG1hbnkgYXJlIGRvaW5nIHRoaXMg aW5mb3JtYWxseSBub3cuIA0KPiANCj4gSG9wZSB0aGlzIGhlbHBzLiANCj4gDQo+IFBoaWwNCj4g DQo+PiBPbiBNYXIgMjQsIDIwMTUsIGF0IDE4OjU0LCBIYWF2YXIgVmFsZXVyIDxoYWF2YXIudmFs ZXVyQGNpdHJpeC5jb20+IHdyb3RlOg0KPj4gDQo+PiBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vz c2lvbiBhcm91bmQgYSBzdGFuZGFyZCBTQ0lNIGV4dGVuc2lvbiB0aGF0IGhhbmRsZXMgb3JnYW5p emF0aW9uYWwgdW5pdHMgKE9VKT8gQSBxdWljayBnb29nbGUgc2VhcmNoIGNhbWUgdXAgd2l0aCBh IGNvdXBsZSBvZiBlbWFpbHMgZnJvbSAzIHllYXJzIGFnbywgYnV0IG5vIHJlYWwgc3Vic2lkZW5j ZS4gIA0KPj4gDQo+PiBJZiB0aGVyZSBoYXMgbm90IGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5k IHRoaXMsIGlzIHRoZXJlIGEgcmVhc29uIGZvciBpdD8NCj4+IA0KPj4gQmVzdA0KPj4gSGFhdmFy DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g c2NpbSBtYWlsaW5nIGxpc3QNCj4+IHNjaW1AaWV0Zi5vcmcNCj4+IGh0dHBzOi8vc2VjdXJlLXdl Yi5jaXNjby5jb20vMV9CSzBGbzZsR0xWU1BiclMyLUFsQkVEbTRXZGdfRXRpb2JmS092cGlmVlRs NThmY2pfWGR2MnFWVGJQMVJBemZKcnhRU2h6TWxpdXh5MkR3QjhpX3pVY2VUZ2l6ejhwTV9mVUI3 ZFV0R0JyajVEc1lHb0w3VVlCNkpjQXB3dUlyVW5zYjI3ZzlyTWxoNWYwdkpUUGpoSENEWDhBS2w2 REdWNnItaDVNUGdzTS9odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnNjaW0NCj4gDQoNCg== From nobody Tue Mar 24 18:19:41 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4842B1A1DBC for ; Tue, 24 Mar 2015 18:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 ImXfsM-CY69W for ; Tue, 24 Mar 2015 18:19:37 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 209B01A1C06 for ; Tue, 24 Mar 2015 18:19:37 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2P1JYta004777 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2015 01:19:35 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2P1JY5l019004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2015 01:19:34 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2P1JY9c027235; Wed, 25 Mar 2015 01:19:34 GMT Received: from dhcp-8d14.meeting.ietf.org (/31.133.141.20) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Mar 2015 18:19:34 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Phil Hunt In-Reply-To: <8F483EED-C19E-422E-9DC8-E960D99A5E3F@citrix.com> Date: Tue, 24 Mar 2015 20:19:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> <51F3F00D-1280-4F70-BFCA-EF1ED2CC9E29@oracle.com> <8F483EED-C19E-422E-9DC8-E960D99A5E3F@citrix.com> To: Haavar Valeur X-Mailer: Apple Mail (2.2070.6) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 01:19:39 -0000 I would avoid a group like object because of scalability issues. = Organization memberships tend to be very very large (compared even to = groups). I believe this is why there is an =E2=80=9Corganization=E2=80=9D = attribute in the Enterprise extension for User resources. You can query for all the User=E2=80=99s who have a organization eq = =E2=80=9Csome value=E2=80=9D, or you can check a User resource to find = out what organization they are a member of. IOW - treat the = organization attribute as a kind of role for delegated admin. Phil @independentid www.independentid.com phil.hunt@oracle.com > On Mar 24, 2015, at 8:02 PM, Haavar Valeur = wrote: >=20 > I was thinking about it as it=E2=80=99s own resource type. It could be = a simple as something similar to how groups work, or it could be more = extensive and include rules/roles for delegated administration. >=20 > Doesn=E2=80=99t it make sense to make a formal schema for OUs? >=20 >> On Mar 24, 2015, at 7:15 PM, Phil Hunt wrote: >>=20 >> It depends... >>=20 >> If you want hierarchy like ldap, there is no way to do this as scim = is flat except for resource type.=20 >>=20 >> If you just want to define organizations as their own resource type = it would be fairly easy to write this up as an extension. I believe many = are doing this informally now.=20 >>=20 >> Hope this helps.=20 >>=20 >> Phil >>=20 >>> On Mar 24, 2015, at 18:54, Haavar Valeur = wrote: >>>=20 >>> Has there been any discussion around a standard SCIM extension that = handles organizational units (OU)? A quick google search came up with a = couple of emails from 3 years ago, but no real subsidence. =20 >>>=20 >>> If there has not been any discussion around this, is there a reason = for it? >>>=20 >>> Best >>> Haavar >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> = https://secure-web.cisco.com/1_BK0Fo6lGLVSPbrS2-AlBEDm4Wdg_EtiobfKOvpifVTl= 58fcj_Xdv2qVTbP1RAzfJrxQShzMliuxy2DwB8i_zUceTgizz8pM_fUB7dUtGBrj5DsYGoL7UY= B6JcApwuIrUnsb27g9rMlh5f0vJTPjhHCDX8AKl6DGV6r-h5MPgsM/https%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fscim >>=20 >=20 From nobody Tue Mar 24 19:16:13 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C11A90B4 for ; Tue, 24 Mar 2015 19:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 V0yWwvjp0LlD for ; Tue, 24 Mar 2015 19:16:09 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C511A90AD for ; Tue, 24 Mar 2015 19:16:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,462,1422921600"; d="scan'208";a="248091549" From: Haavar Valeur To: Phil Hunt Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZo3gAZJQG/Uhyk2Fltx5Ryl7+Z0syfYAgAANFgCAAASwgIAAD8yA Date: Wed, 25 Mar 2015 02:16:06 +0000 Message-ID: <51FAA2E7-667A-4056-9D51-57598E6B7092@citrix.com> References: <3430560F-0FC5-4663-9177-881B0A1FD443@citrix.com> <51F3F00D-1280-4F70-BFCA-EF1ED2CC9E29@oracle.com> <8F483EED-C19E-422E-9DC8-E960D99A5E3F@citrix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <9BC5A76B99EBA543BBFAB1B39BBE90BF@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 02:16:11 -0000 SXQgcHJvYmFibHkgbWFrZXMgc2Vuc2UgZm9yIHRoZSBPVSBhc3NvY2lhdGlvbiB0byBiZSBvbiB0 aGUgdXNlciBvYmplY3QsIHNpbmNlIGl04oCZcyBhIG1hbnktdG8tb25lIHJlbGF0aW9uc2hpcC4g SG93ZXZlciwgSSB0aGluayBpdCBzdGlsbCBtYWtlcyBzZW5zZSB0byBoYXZlIGEgc2NoZW1hIGZv ciBPVXMuIFlvdSBuZWVkIGEgd2F5IHRvIGNyZWF0ZSBhbmQgZGVsZXRlIHRoZW0sIGFuZCBtYWtl IG5lc3RlZCBPVXMuIFBlcmhhcHMgZXZlbiBhZGQgYWRtaW5zIHRvIHRoZSBPVS4NCg0KPiBPbiBN YXIgMjQsIDIwMTUsIGF0IDg6MTkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+ IHdyb3RlOg0KPiANCj4gSSB3b3VsZCBhdm9pZCBhIGdyb3VwIGxpa2Ugb2JqZWN0IGJlY2F1c2Ug b2Ygc2NhbGFiaWxpdHkgaXNzdWVzLiAgT3JnYW5pemF0aW9uIG1lbWJlcnNoaXBzIHRlbmQgdG8g YmUgdmVyeSB2ZXJ5IGxhcmdlIChjb21wYXJlZCBldmVuIHRvIGdyb3VwcykuDQo+IA0KPiBJIGJl bGlldmUgdGhpcyBpcyB3aHkgdGhlcmUgaXMgYW4g4oCcb3JnYW5pemF0aW9u4oCdIGF0dHJpYnV0 ZSBpbiB0aGUgRW50ZXJwcmlzZSBleHRlbnNpb24gZm9yIFVzZXIgcmVzb3VyY2VzLg0KPiANCj4g WW91IGNhbiBxdWVyeSBmb3IgYWxsIHRoZSBVc2Vy4oCZcyB3aG8gaGF2ZSBhIG9yZ2FuaXphdGlv biBlcSDigJxzb21lIHZhbHVl4oCdLCBvciB5b3UgY2FuIGNoZWNrIGEgVXNlciByZXNvdXJjZSB0 byBmaW5kIG91dCB3aGF0IG9yZ2FuaXphdGlvbiB0aGV5IGFyZSBhIG1lbWJlciBvZi4gICBJT1cg LSB0cmVhdCB0aGUgb3JnYW5pemF0aW9uIGF0dHJpYnV0ZSBhcyBhIGtpbmQgb2Ygcm9sZSBmb3Ig ZGVsZWdhdGVkIGFkbWluLg0KPiANCj4gUGhpbA0KPiANCj4gQGluZGVwZW5kZW50aWQNCj4gd3d3 LmluZGVwZW5kZW50aWQuY29tDQo+IHBoaWwuaHVudEBvcmFjbGUuY29tDQo+IA0KPj4gT24gTWFy IDI0LCAyMDE1LCBhdCA4OjAyIFBNLCBIYWF2YXIgVmFsZXVyIDxoYWF2YXIudmFsZXVyQGNpdHJp eC5jb20+IHdyb3RlOg0KPj4gDQo+PiBJIHdhcyB0aGlua2luZyBhYm91dCBpdCBhcyBpdOKAmXMg b3duIHJlc291cmNlIHR5cGUuIEl0IGNvdWxkIGJlIGEgc2ltcGxlIGFzIHNvbWV0aGluZyBzaW1p bGFyIHRvIGhvdyBncm91cHMgd29yaywgb3IgaXQgY291bGQgYmUgbW9yZSBleHRlbnNpdmUgYW5k IGluY2x1ZGUgcnVsZXMvcm9sZXMgZm9yIGRlbGVnYXRlZCBhZG1pbmlzdHJhdGlvbi4NCj4+IA0K Pj4gRG9lc27igJl0IGl0IG1ha2Ugc2Vuc2UgdG8gbWFrZSBhIGZvcm1hbCBzY2hlbWEgZm9yIE9V cz8NCj4+IA0KPj4+IE9uIE1hciAyNCwgMjAxNSwgYXQgNzoxNSBQTSwgUGhpbCBIdW50IDxwaGls Lmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSXQgZGVwZW5kcy4uLg0KPj4+IA0K Pj4+IElmIHlvdSB3YW50IGhpZXJhcmNoeSBsaWtlIGxkYXAsIHRoZXJlIGlzIG5vIHdheSB0byBk byB0aGlzIGFzIHNjaW0gaXMgZmxhdCBleGNlcHQgZm9yIHJlc291cmNlIHR5cGUuIA0KPj4+IA0K Pj4+IElmIHlvdSBqdXN0IHdhbnQgdG8gZGVmaW5lIG9yZ2FuaXphdGlvbnMgYXMgdGhlaXIgb3du IHJlc291cmNlIHR5cGUgaXQgd291bGQgYmUgZmFpcmx5IGVhc3kgdG8gd3JpdGUgdGhpcyB1cCBh cyBhbiBleHRlbnNpb24uIEkgYmVsaWV2ZSBtYW55IGFyZSBkb2luZyB0aGlzIGluZm9ybWFsbHkg bm93LiANCj4+PiANCj4+PiBIb3BlIHRoaXMgaGVscHMuIA0KPj4+IA0KPj4+IFBoaWwNCj4+PiAN Cj4+Pj4gT24gTWFyIDI0LCAyMDE1LCBhdCAxODo1NCwgSGFhdmFyIFZhbGV1ciA8aGFhdmFyLnZh bGV1ckBjaXRyaXguY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhhcyB0aGVyZSBiZWVuIGFueSBk aXNjdXNzaW9uIGFyb3VuZCBhIHN0YW5kYXJkIFNDSU0gZXh0ZW5zaW9uIHRoYXQgaGFuZGxlcyBv cmdhbml6YXRpb25hbCB1bml0cyAoT1UpPyBBIHF1aWNrIGdvb2dsZSBzZWFyY2ggY2FtZSB1cCB3 aXRoIGEgY291cGxlIG9mIGVtYWlscyBmcm9tIDMgeWVhcnMgYWdvLCBidXQgbm8gcmVhbCBzdWJz aWRlbmNlLiAgDQo+Pj4+IA0KPj4+PiBJZiB0aGVyZSBoYXMgbm90IGJlZW4gYW55IGRpc2N1c3Np b24gYXJvdW5kIHRoaXMsIGlzIHRoZXJlIGEgcmVhc29uIGZvciBpdD8NCj4+Pj4gDQo+Pj4+IEJl c3QNCj4+Pj4gSGFhdmFyDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+IHNjaW0gbWFpbGluZyBsaXN0DQo+Pj4+IHNjaW1AaWV0Zi5vcmcN Cj4+Pj4gaHR0cHM6Ly9zZWN1cmUtd2ViLmNpc2NvLmNvbS8xX0JLMEZvNmxHTFZTUGJyUzItQWxC RURtNFdkZ19FdGlvYmZLT3ZwaWZWVGw1OGZjal9YZHYycVZUYlAxUkF6ZkpyeFFTaHpNbGl1eHky RHdCOGlfelVjZVRnaXp6OHBNX2ZVQjdkVXRHQnJqNURzWUdvTDdVWUI2SmNBcHd1SXJVbnNiMjdn OXJNbGg1ZjB2SlRQamhIQ0RYOEFLbDZER1Y2ci1oNU1QZ3NNL2h0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2NpbQ0KPj4+IA0KPj4gDQo+IA0KDQo= From nobody Wed Mar 25 09:47:48 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05E1A8A67 for ; Wed, 25 Mar 2015 09:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vUH_hxwxUSOy for ; Wed, 25 Mar 2015 09:47:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB801A877B for ; Wed, 25 Mar 2015 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=932; q=dns/txt; s=iport; t=1427302065; x=1428511665; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fNB2svJszq/RwdRsJrseOz5i/1LKO+2Sc2idrhKAFwQ=; b=JLBdLOiEix9X1uZKmzY9JcC10Spv4zKc9jiMwl2LBt3S8ovCV83NsWxI 3j2Iewv3N57sPcq5Nd4+Iht1NZnA0zuEQgZr2TEYKhR1v0XrPcBnQhhPt rQ74SiGe+bdxg1aP+zdtYJOj7601NxXp/EraSzFbXmNCNXlo9kANZizvE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBgCL5RJV/5FdJa1cgwZSWgTCUoIxCodPTAEBAQEBAX2EFQEBBAEBATc0HQEINjcLJwQBEogvDclJAQEBAQYBAQEBAQEYBIshiSoFkFCJb5QsIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,465,1422921600"; d="scan'208";a="135327138" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 25 Mar 2015 16:47:44 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2PGliSU019206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 16:47:44 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 11:47:44 -0500 From: "Morteza Ansari (moransar)" To: Haavar Valeur , "scim@ietf.org" Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Q== Date: Wed, 25 Mar 2015 16:47:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.222.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CD08CC8D83C48448DFCCAEE804A6196@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:47:47 -0000 If you are talking about hierarchical organization of resource instances, we had that discussion in the very early days of SCIM 1.0 work. I actually think I brought that up as a request but after talking to other vendors it seemed every SaaS service was doing a flat name space for users & groups and nobody had a request from customers for a hierarchical model so the feature was dropped. Cheers, Morteza On 3/24/15, 6:54 PM, "Haavar Valeur" wrote: >Has there been any discussion around a standard SCIM extension that >handles organizational units (OU)? A quick google search came up with a >couple of emails from 3 years ago, but no real subsidence. > >If there has not been any discussion around this, is there a reason for >it? > >Best >Haavar >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From nobody Wed Mar 25 09:54:32 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98611A88EA for ; Wed, 25 Mar 2015 09:54:31 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uqPMWc2BNwsg for ; Wed, 25 Mar 2015 09:54:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5001A8838 for ; Wed, 25 Mar 2015 09:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33125; q=dns/txt; s=iport; t=1427302469; x=1428512069; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4v981XEK9OZ3zQBb7lTGooTwMr/RO7KHShI8nQtNhgk=; b=mdeJhsTSX4kLOjsdAFlAggJOmSmtASyvOJUZMAndLacoPDPrj51Nf+TJ 4xgjNhpruLLBecr9aZ+NgQvOTEQBhY4fX/odovZgCERIGlw2X+y6EylUt XTAUmIXkpn14uBidYjC6HZj1y/qxDZhurhdXniUzKUORvUDloWCSvpgfN M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBgDf5xJV/5JdJa1cgkNDUloEwlKCGBkBBoV4AoFYTAEBAQEBAX2EFAEBAQQBAQFrBAcQAgEIEQMBAQEhAQYHJwsUCQgCBAENBRkCiBQNyUQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIshhGUNBAYBhC0FhQuBQod1gg6Db4YAgRuDMI9hIoNubwEBgUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,465,1422921600"; d="scan'208,217";a="403479059" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 25 Mar 2015 16:54:28 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t2PGsRXP026637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 16:54:27 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 11:54:27 -0500 From: "Morteza Ansari (moransar)" To: Haavar Valeur , Anthony Nadalin Thread-Topic: [scim] SCIM Soft Delete Draft Thread-Index: AQHQWswqiNsvHhxZ3Emxagx6FL5fJZ0WFtMA///iXoCAAD/KAP//3v8AgACANICAAAkngIAV+kyAgADnd4A= Date: Wed, 25 Mar 2015 16:54:26 +0000 Message-ID: References: <8567D035-16D0-4668-B1A7-5D7D1A36835D@oracle.com> <5B258021-4D90-47CB-9FF3-B7A0D80224EE@citrix.com> In-Reply-To: <5B258021-4D90-47CB-9FF3-B7A0D80224EE@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.222.195] Content-Type: multipart/alternative; boundary="_000_D13850E51211C1moransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] SCIM Soft Delete Draft X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:54:31 -0000 --_000_D13850E51211C1moransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the feedback. The wording obviously need a lot of improving. The idea is that soft delete= d objects don=92t cause a conflict in namespace. So if =93user1=94 is signe= d up for a service, and then user1 is soft deleted, another user1 can be cr= eated and if the admin attempts to undelete the soft deleted user1, then th= ere is a conflict and user1 need to be renamed to an unused one. And yes, I agree the naming for the filter is not the most intuitive one bu= t the question is which is worse, not being consistent with the rest of the= filters or make this one more readable? We can definitely go either route. Cheers, Morteza From: Haavar Valeur > Date: Tuesday, March 24, 2015 at 5:05 PM To: Anthony Nadalin > Cc: Phil Hunt >, Morteza = Ansari >, "scim@ietf.org" > Subject: Re: [scim] SCIM Soft Delete Draft I have a couple of comments. In section 2.3 (SCIM create) it says that =93SCIM Create SHOULD NOT ignore = namespace conflicts=85=94, but in the example is says that a create with a = softy deleted conflicting user should not fail. Those two statements seems = conflicting to me. In section 2.9 (SCIM hard delete), it says the way to do a hard delete is t= o include a query parameter isSoftDeleted=3Dtrue. That=92s not very intuiti= ve to me. I understand that=92s the parameter name used in all the filters,= but perhaps not a name suited for indicating a hard delete. On Mar 10, 2015, at 5:28 PM, Anthony Nadalin > wrote: Yes, seems so From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, March 10, 2015 2:56 PM To: Morteza Ansari (moransar) Cc: Anthony Nadalin; scim@ietf.org Subject: Re: [scim] SCIM Soft Delete Draft Wasn't the original perspective an issue of tombstoning? I do think this would be a great opportunity to discuss the relationship to= activation and deactivation. Phil On Mar 10, 2015, at 14:17, Morteza Ansari (moransar) > wrote: Because I hadn=92t thought of it and didn=92t have a use case for it :) Can you please explain? Might be interesting. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 2:15 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft Why no =93soft create=94 ? From: Morteza Ansari (moransar) [mailto:moransar@cisco.com] Sent: Tuesday, March 10, 2015 12:27 PM To: Anthony Nadalin; scim@ietf.org Subject: Re: SCIM Soft Delete Draft Yes. There is a very short blurb about the fact you could provide additiona= l attributes to resolve any potential namespace conflicts. For example if y= ou are undeleting a user you could send a new userName as part of the modif= y request so you undelete the user object and resolve the conflict. The more interesting case is the references and what to do in those cases. = References should not be visible in cases of soft deleted objects, the ques= tion is how expensive is to maintain that information and add the links aft= er the object is undeleted. In a prototype I have done of this, I took the easy route and just deleted = references and they need to be re-created. Obviously it works, but it is no= t the most useful solution. Then again if this is a provisioning case and e= ssentially a slave of another IDM solution, it can easily be recreated. The= real problem is preserving the ID of the user and reinstating it rather th= an getting a new ID. From: Anthony Nadalin > Date: Tuesday, March 10, 2015 at 12:14 PM To: Morteza Ansari >, "scim@i= etf.org" > Subject: RE: SCIM Soft Delete Draft So if I delete (soft) an object and then add a new object with the same nam= e, and then I undelete the object I deleted would the undelete fail ? From: scim [mailto:scim-bounces@ietf.org] On Behalf Of Morteza Ansari (mora= nsar) Sent: Monday, March 9, 2015 5:50 PM To: scim@ietf.org Subject: [scim] SCIM Soft Delete Draft Phil Hunt and I put together a very very very rough draft for SCIM soft del= ete semantics. The draft is missing a lot of details and require a lot more= thinking but we wanted to put the basic concept out there for discussion a= t Dallas. The idea of soft delete/undelete has come up many times in variou= s forums and I personally think it is a very important aspect of real life = operationalizing SCIM. https://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/ I would like a slot on the agenda to discuss this draft and get feedback fr= om the WG. Cheers, Morteza _______________________________________________ scim mailing list scim@ietf.org https://secure-web.cisco.com/1ja_WP8_rfvIfsS4W2kAsnt2dwcyyWNR-Jln2QDFyIZ725= khBrQpmI2BQRozdpHtp6LN3tW13x2GzID0QDJZTfZ2E-UK6OPcOPs8my7VOR6jGKoRT2r2X3DSc= PAGwtFuX_gcVeKJZ9dq0gdIzRgLb_0IEdttNdjDQjxN5fnKPfLI/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim _______________________________________________ scim mailing list scim@ietf.org https://secure-web.cisco.com/1ja_WP8_rfvIfsS4W2kAsnt2dwcyyWNR-Jln2QDFyIZ725= khBrQpmI2BQRozdpHtp6LN3tW13x2GzID0QDJZTfZ2E-UK6OPcOPs8my7VOR6jGKoRT2r2X3DSc= PAGwtFuX_gcVeKJZ9dq0gdIzRgLb_0IEdttNdjDQjxN5fnKPfLI/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim --_000_D13850E51211C1moransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for the feedback.

The wording obviously need a lot of improving. The idea is that soft d= eleted objects don=92t cause a conflict in namespace. So if =93user1=94 is = signed up for a service, and then user1 is soft deleted, another user1 can = be created and if the admin attempts to undelete the soft deleted user1, then there is a conflict and user1 need t= o be renamed to an unused one.

And yes, I agree the naming for the filter is not the most intuitive o= ne but the question is which is worse, not being consistent with the rest o= f the filters or make this one more readable? We can definitely go either r= oute.


Cheers,
Morteza

From: Haavar Valeur <haavar.valeur@citrix.com>
Date: Tuesday, March 24, 2015 at 5:= 05 PM
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: Phil Hunt <phil.hunt@oracle.com>, Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] SCIM Soft Delet= e Draft

I have a couple of comments.

In section 2.3 (SCIM create) it says that =93SCIM Create SHOULD NOT ignore namespace confli= cts=85=94, but in the example is says that a create with a softy del= eted conflicting user should not fail. Those two statements seems conflicting to me.

In section 2.9 (SCIM hard delete), it says the way to do a = hard delete is to include a query parameter isSoftDeleted=3Dtrue. That=92s not very intuitive to me. I understand&nb= sp;that=92s the parameter name used in all the filters, but perhaps = not a name suited for indicating a hard delete. 


On Mar 10, 2015, at 5:28 PM, Anthony Nadalin <tonynad@microsoft.com> wro= te:

Yes, seems so
 
From:&= nbsp;Phil Hunt [mailto:phil.hunt@oracle= .com] 
Sent: T= uesday, March 10, 2015 2:56 PM
To: Mor= teza Ansari (moransar)
Cc: Ant= hony Nadalin; scim@ietf.org
Subject: Re: [scim] SCIM Soft Delete Draft
 
Wasn't the original perspective an issue of tombstoning?
 
I do think this would be a great opportunity to discuss the relationship to= activation and deactivation. 

Phil


On Mar 10, 2015, at 14:17, Morteza Ansari (moransar) <moransar@cisco.com> wrote:

Because I hadn=92t thought of it and didn=92t have a use case for it :)
 
Can you please explain?  Might be interesting.
 
From: Anthony Nadalin <tonynad@micro= soft.com>
Date: T= uesday, March 10, 2015 at 2:15 PM
To: Mor= teza Ansari <moransar@cisco.com>, &quo= t;scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft
 
Why no =93soft create=94 ?
 
From:&= nbsp;Morteza Ansari (moransar) [mailto:mo= ransar@cisco.com]  Sent: T= uesday, March 10, 2015 12:27 PM
To: Ant= hony Nadalin; scim@ietf.org
Subject: Re: SCIM Soft Delete Draft
 
Yes. There is a very short blurb about the fact you could provide add= itional attributes to resolve any potential namespace conflicts. For exampl= e if you are undeleting a user you could send a new userName as part of the modify request so you undelete the user= object and resolve the conflict.
 
The more interesting case is the references and what to do in those c= ases. References should not be visible in cases of soft deleted objects, th= e question is how expensive is to maintain that information and add the links after the object is undeleted.
 
In a prototype I have done of this, I took the easy route and just de= leted references and they need to be re-created. Obviously it works, but it= is not the most useful solution. Then again if this is a provisioning case and essentially a slave of another ID= M solution, it can easily be recreated. The real problem is preserving the = ID of the user and reinstating it rather than getting a new ID.
 
 
From: Anthony Nadalin <tonynad@micro= soft.com>
Date: T= uesday, March 10, 2015 at 12:14 PM
To: Mor= teza Ansari <moransar@cisco.com>, &quo= t;scim@ietf.org" <scim@ietf.org>
Subject: RE: SCIM Soft Delete Draft
 
So if I delete (soft) an object and then add a = new object with the same name, and then I undelete the object I deleted wou= ld the undelete fail ?
 
From:&= nbsp;scim [mailto:scim-bounces@ietf.or= g] On Behalf Of Morteza An= sari (moransar)
Sent: M= onday, March 9, 2015 5:50 PM
To: scim@ietf.org
Subject: [scim] SCIM Soft Delete Draft
 
Phil Hunt and I put together a very very very rough draft for SCIM so= ft delete semantics. The draft is missing a lot of details and require a lo= t more thinking but we wanted to put the basic concept out there for discussion at Dallas. The idea of soft del= ete/undelete has come up many times in various forums and I personally thin= k it is a very important aspect of real life operationalizing SCIM.<= o:p class=3D"">
 
http= s://datatracker.ietf.org/doc/draft-ansari-scim-soft-delete/
 
I would like a slot on the agenda to discuss this draft and get feedb= ack from the WG.
 
 
Cheers,
Morteza
_______________________________________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1ja_WP8_rfvIf= sS4W2kAsnt2dwcyyWNR-Jln2QDFyIZ725khBrQpmI2BQRozdpHtp6LN3tW13x2GzID0QDJZTfZ2= E-UK6OPcOPs8my7VOR6jGKoRT2r2X3DScPAGwtFuX_gcVeKJZ9dq0gdIzRgLb_0IEdttNdjDQjx= N5fnKPfLI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim
_______________________________________________
scim mailing list
scim@ietf.org
https://secure-web.cisco.com/1ja_= WP8_rfvIfsS4W2kAsnt2dwcyyWNR-Jln2QDFyIZ725khBrQpmI2BQRozdpHtp6LN3tW13x2GzID= 0QDJZTfZ2E-UK6OPcOPs8my7VOR6jGKoRT2r2X3DScPAGwtFuX_gcVeKJZ9dq0gdIzRgLb_0IEd= ttNdjDQjxN5fnKPfLI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim

 --_000_D13850E51211C1moransarciscocom_-- From nobody Wed Mar 25 12:36:18 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AECE1B2B0C for ; Wed, 25 Mar 2015 12:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pet2uhVbJMvq for ; Wed, 25 Mar 2015 12:36:12 -0700 (PDT) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA6A1B2B03 for ; Wed, 25 Mar 2015 12:36:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="248370991" From: Haavar Valeur To: "Morteza Ansari (moransar)" Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA Date: Wed, 25 Mar 2015 19:33:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <4CDBBFDE3410FB4385C3CE52EF54854C@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:36:17 -0000 SSB0aGluayBoYXZpbmcgdGhlIE9VcyBiZSBoaWVyYXJjaGljYWwgc2hvdWxkIGJlIGFuIG9wdGlv biBpZiBhbiBleHRlbnNpb24gd2FzIGFkZGVkLCBidXQgZXZlbiB3aXRob3V0IHRoYXQgSSB3b3Vs ZCB0aGluayB0aGF0IGl04oCZcyBiZW5lZmljaWFsIHRvIGhhdmUgT1VzIGluIHRoZSBBUEkuIFdp dGhvdXQgT1UgcmVwcmVzZW50ZWQgaW4gdGhlIHNjaGVtYSB5b3Ugd291bGQgaGF2ZSBsb29zZSBy ZWZlcmVuY2VzIHRvIG9iamVjdHMgdGhhdCBhcmUgY3JlYXRlZCB3aXRoIHByb3ByaWV0YXJ5IEFQ SXMgb3Igc2NoZW1hcy4NCg0KSeKAmW0gYSBsaXR0bGUgc3VycHJpc2VkIHRoYXQgdGhlIGNvbnNl bnN1cyB3YXMgdGhhdCBTYWFTIHByb3ZpZGVycyBoYXZlIGEgZmxhdCBPVSBzdHJ1Y3R1cmUuIEZy b20gd2hhdCBJ4oCZdmUgc2VlbiwgYSBsb3Qgb2YgcHJvdmlkZXJzIHN1cHBvcnQgYSBoaWVyYXJj aHkgKHdpdGggYSBzb21lIG5vdGFibGUgZXhjZXB0aW9ucykuIEkgd291bGQgdGhpbmsgaXQgd291 bGQgYmUgYSBjb21tb24gdXNlIGNhc2UgZm9yIGxhcmdlciBjdXN0b21lcnMgb2YgYSBTYWFTIHBy b3ZpZGVyIHRvIHN5bmMgdGhlaXIgZW1wbG95ZWUgZGlyZWN0b3J5IHRvIHRoZSBwcm92aWRlciwg aW5jbHVkaW5nIE9Vcy4gVGhlIE9VcyB3b3VsZCBiZSB1c2VkIHRvIHNldCBwYXNzd29yZCBwb2xp Y2VzLCBmZWRlcmF0ZWQgbG9naW4gc2V0dGluZ3MgYW5kIGFkbWluaXN0cmF0aW9uIG9yIHByb2R1 Y3QgcHJpdmlsZWdlcyBvbiB0aGUgU2FhUyBwcm92aWRlciBzaWRlLiANCg0KSGF2ZSB0aGUgU2Fh UyBwcm92aWRlcnMgY2hhbmdlZCB0aGlzIG92ZXIgdGhlIHllYXJzLCBvciBkbyBJIGhhdmUgdGhl IHdyb25nIGltcHJlc3Npb24/DQoNCg0KPiBPbiBNYXIgMjUsIDIwMTUsIGF0IDExOjQ3IEFNLCBN b3J0ZXphIEFuc2FyaSAobW9yYW5zYXIpIDxtb3JhbnNhckBjaXNjby5jb20+IHdyb3RlOg0KPiAN Cj4gSWYgeW91IGFyZSB0YWxraW5nIGFib3V0IGhpZXJhcmNoaWNhbCBvcmdhbml6YXRpb24gb2Yg cmVzb3VyY2UgaW5zdGFuY2VzLA0KPiB3ZSBoYWQgdGhhdCBkaXNjdXNzaW9uIGluIHRoZSB2ZXJ5 IGVhcmx5IGRheXMgb2YgU0NJTSAxLjAgd29yay4gSSBhY3R1YWxseQ0KPiB0aGluayBJIGJyb3Vn aHQgdGhhdCB1cCBhcyBhIHJlcXVlc3QgYnV0IGFmdGVyIHRhbGtpbmcgdG8gb3RoZXIgdmVuZG9y cyBpdA0KPiBzZWVtZWQgZXZlcnkgU2FhUyBzZXJ2aWNlIHdhcyBkb2luZyBhIGZsYXQgbmFtZSBz cGFjZSBmb3IgdXNlcnMgJiBncm91cHMNCj4gYW5kIG5vYm9keSBoYWQgYSByZXF1ZXN0IGZyb20g Y3VzdG9tZXJzIGZvciBhIGhpZXJhcmNoaWNhbCBtb2RlbCBzbyB0aGUNCj4gZmVhdHVyZSB3YXMg ZHJvcHBlZC4NCj4gDQo+IA0KPiBDaGVlcnMsDQo+IE1vcnRlemENCj4gDQo+IE9uIDMvMjQvMTUs IDY6NTQgUE0sICJIYWF2YXIgVmFsZXVyIiA8aGFhdmFyLnZhbGV1ckBjaXRyaXguY29tPiB3cm90 ZToNCj4gDQo+PiBIYXMgdGhlcmUgYmVlbiBhbnkgZGlzY3Vzc2lvbiBhcm91bmQgYSBzdGFuZGFy ZCBTQ0lNIGV4dGVuc2lvbiB0aGF0DQo+PiBoYW5kbGVzIG9yZ2FuaXphdGlvbmFsIHVuaXRzIChP VSk/IEEgcXVpY2sgZ29vZ2xlIHNlYXJjaCBjYW1lIHVwIHdpdGggYQ0KPj4gY291cGxlIG9mIGVt YWlscyBmcm9tIDMgeWVhcnMgYWdvLCBidXQgbm8gcmVhbCBzdWJzaWRlbmNlLg0KPj4gDQo+PiBJ ZiB0aGVyZSBoYXMgbm90IGJlZW4gYW55IGRpc2N1c3Npb24gYXJvdW5kIHRoaXMsIGlzIHRoZXJl IGEgcmVhc29uIGZvcg0KPj4gaXQ/DQo+PiANCj4+IEJlc3QNCj4+IEhhYXZhcg0KPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNjaW0gbWFpbGlu ZyBsaXN0DQo+PiBzY2ltQGlldGYub3JnDQo+PiBodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29t LzFOVDV6V3FfVi14dTlRQ1ItNkItVHQ3WG4wRmVUUlppXzhuNjhENHo5U2lFSGRjV1hpTjJjeGJ5 ZThmNDl3c1h4elBoV0psR19lakIzNDdNcy0xUzU4cnVoVmN3SWRyNEZCcUNlZHJUZURic1hXblpQ SEwwTExvNWE2dEVNTFRQMzVaQlFDWUF2SWJNZE52UDdKMkdnRVc1ZWRMa0Nwc1RMVkNKemlhRWtY dGsvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzY2lt DQo+IA0KPiANCg0K From nobody Wed Mar 25 13:11:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FC51AD359 for ; Wed, 25 Mar 2015 13:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 GZPm86BWxASL for ; Wed, 25 Mar 2015 13:11:49 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B521A8A27 for ; Wed, 25 Mar 2015 13:11:49 -0700 (PDT) Received: by iedm5 with SMTP id m5so31200281ied.3 for ; Wed, 25 Mar 2015 13:11:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=U2AzzXGc/rwxcX2bgHjzmimyrxaA/74VHSPR69e16uo=; b=aQD+U19c3B2y9LXCF1LFBAiIOxRMaTRlgg9UwAMWbRHstX54zEr6av6x8vIt3+oSym EjTgjHbikxJtiJwsp4Zwn3og3SwoQD5WFcXfe6582NDxE/zYfnqk5SACVlXkR4fbnHdE m2T+kzCW5+Dv56/ZcOcMqoparud+FVQdpRCMcw6wCCBBEtKZzmBL94qYrPQuaoVmPhQe 0V/0xLJmHbcg/ZJHaSjicOm6XUtuZWPf2be2DpJkEVKKaJC1o4Lgb5KnXM7mO0UIjgyj Stww+iBCu7/Z9+sy9bygKeIA9zSSayAcmaKTtm9ZE2entXtwSQmOQutPlCI6EWSBSeEl UytQ== X-Gm-Message-State: ALoCoQmOxLd8C+0TRpjCg6ni4v57O99nAX0FRHN8k59+cFRmsjh+c8lb/7RaZUYItOYAgvWJuV/P X-Received: by 10.42.89.72 with SMTP id f8mr34163761icm.24.1427314309028; Wed, 25 Mar 2015 13:11:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.127.76 with HTTP; Wed, 25 Mar 2015 13:11:28 -0700 (PDT) In-Reply-To: References: From: Ian Glazer Date: Wed, 25 Mar 2015 16:11:28 -0400 Message-ID: To: Haavar Valeur Content-Type: multipart/alternative; boundary=90e6ba6147e25f994405122282d0 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:11:52 -0000 --90e6ba6147e25f994405122282d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In our case we have a flat-ish model. We can represent OUs and a hierarchy but it is represented on the user object and not as a standalone organizational structure On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur wrote: > I think having the OUs be hierarchical should be an option if an extensio= n > was added, but even without that I would think that it=E2=80=99s benefici= al to have > OUs in the API. Without OU represented in the schema you would have loose > references to objects that are created with proprietary APIs or schemas. > > I=E2=80=99m a little surprised that the consensus was that SaaS providers= have a > flat OU structure. From what I=E2=80=99ve seen, a lot of providers suppor= t a > hierarchy (with a some notable exceptions). I would think it would be a > common use case for larger customers of a SaaS provider to sync their > employee directory to the provider, including OUs. The OUs would be used = to > set password polices, federated login settings and administration or > product privileges on the SaaS provider side. > > Have the SaaS providers changed this over the years, or do I have the > wrong impression? > > > > On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) < > moransar@cisco.com> wrote: > > > > If you are talking about hierarchical organization of resource instance= s, > > we had that discussion in the very early days of SCIM 1.0 work. I > actually > > think I brought that up as a request but after talking to other vendors > it > > seemed every SaaS service was doing a flat name space for users & group= s > > and nobody had a request from customers for a hierarchical model so the > > feature was dropped. > > > > > > Cheers, > > Morteza > > > > On 3/24/15, 6:54 PM, "Haavar Valeur" wrote: > > > >> Has there been any discussion around a standard SCIM extension that > >> handles organizational units (OU)? A quick google search came up with = a > >> couple of emails from 3 years ago, but no real subsidence. > >> > >> If there has not been any discussion around this, is there a reason fo= r > >> it? > >> > >> Best > >> Haavar > >> _______________________________________________ > >> scim mailing list > >> scim@ietf.org > >> > https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9SiE= HdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL0LLo= 5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fscim > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --=20 Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --90e6ba6147e25f994405122282d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In our case we have a flat-ish model. We can represent OUs= and a hierarchy but it is represented on the user object and not as a stan= dalone organizational structure

On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur <haavar.valeur@citrix.com> wrote:
I think having the OUs be hierarchical should be an option if an ext= ension was added, but even without that I would think that it=E2=80=99s ben= eficial to have OUs in the API. Without OU represented in the schema you wo= uld have loose references to objects that are created with proprietary APIs= or schemas.

I=E2=80=99m a little surprised that the consensus was that SaaS providers h= ave a flat OU structure. From what I=E2=80=99ve seen, a lot of providers su= pport a hierarchy (with a some notable exceptions). I would think it would = be a common use case for larger customers of a SaaS provider to sync their = employee directory to the provider, including OUs. The OUs would be used to= set password polices, federated login settings and administration or produ= ct privileges on the SaaS provider side.

Have the SaaS providers changed this over the years, or do I have the wrong= impression?


> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
>
> If you are talking about hierarchical organization of resource instanc= es,
> we had that discussion in the very early days of SCIM 1.0 work. I actu= ally
> think I brought that up as a request but after talking to other vendor= s it
> seemed every SaaS service was doing a flat name space for users & = groups
> and nobody had a request from customers for a hierarchical model so th= e
> feature was dropped.
>
>
> Cheers,
> Morteza
>
> On 3/24/15, 6:54 PM, "Haavar Valeur" <haavar.valeur@citrix.com> wrote:
>
>> Has there been any discussion around a standard SCIM extension tha= t
>> handles organizational units (OU)? A quick google search came up w= ith a
>> couple of emails from 3 years ago, but no real subsidence.
>>
>> If there has not been any discussion around this, is there a reaso= n for
>> it?
>>
>> Best
>> Haavar
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si= EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL0LL= o5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fscim
>
>

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



--
=
Ian Glazer
Senior Director, Identity
+1 202 255 3166
--90e6ba6147e25f994405122282d0-- From nobody Wed Mar 25 13:11:54 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE88A1A8A27 for ; Wed, 25 Mar 2015 13:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6Zpldpi3s2Ly for ; Wed, 25 Mar 2015 13:11:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263591A8AA4 for ; Wed, 25 Mar 2015 13:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2980; q=dns/txt; s=iport; t=1427314311; x=1428523911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i4ZRwQNnxzRD005bog0Lbd9Ys+ybsbcj9Gqb9454Vag=; b=HNkVjX34TxNkk3P3gotRbdcTaDkBsDSdmGicLXtuDZM0bbLy80U6kDvp cHHq0tPnT4Vag8W1EKvQFbrLA9UfTZrJpsJ8ziNfKZHs8XOPGTBVbbuJ/ 06wWwP9xBm4eiWc8Rea8YuFBvsWFF6Ybq81FpaXHeJW3C+v9u1/vPwg0q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBgBkFhNV/4kNJK1TCYMGUloEwlaCMQyFcwKBWkwBAQEBAQF9hBUBAQQBAQFrCxACAQgYFgEBFicLJQIEDgUJEogUDcoNAQEBAQEBAQEBAQEBAQEBAQEBGoshgjmBWwcKAR0zBxIBBYQVBYpjhW2Db4N0ggyBG4MwjBqDRyKDbm+BBAcXIn8BAQE X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="135396227" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 25 Mar 2015 20:11:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2PKBf0A028004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 20:11:41 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 15:11:41 -0500 From: "Morteza Ansari (moransar)" To: Haavar Valeur Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA//+VPgA= Date: Wed, 25 Mar 2015 20:11:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.230.42] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:11:52 -0000 To be clear my previous response to your email and this email are with me wearing implementer hat and not speaking as chair. I can=B9t see how we could add the OU hierarchy as an extension of the SCIM= . That would be a pretty intrusive change and require changes to almost everything in SCIM. However, if you have ideas how this could be done, I would love to hear them. Also if you know of SaaS solutions where the identity space is hierarchical, please share that. I started thinking the same way but didn=B9t find any vendor that supported it or customers that asked for it. Cheers, Morteza On 3/25/15, 2:33 PM, "Haavar Valeur" wrote: >I think having the OUs be hierarchical should be an option if an >extension was added, but even without that I would think that it=B9s >beneficial to have OUs in the API. Without OU represented in the schema >you would have loose references to objects that are created with >proprietary APIs or schemas. > >I=B9m a little surprised that the consensus was that SaaS providers have a >flat OU structure. From what I=B9ve seen, a lot of providers support a >hierarchy (with a some notable exceptions). I would think it would be a >common use case for larger customers of a SaaS provider to sync their >employee directory to the provider, including OUs. The OUs would be used >to set password polices, federated login settings and administration or >product privileges on the SaaS provider side. > >Have the SaaS providers changed this over the years, or do I have the >wrong impression? > > >> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) >> wrote: >>=20 >> If you are talking about hierarchical organization of resource >>instances, >> we had that discussion in the very early days of SCIM 1.0 work. I >>actually >> think I brought that up as a request but after talking to other vendors >>it >> seemed every SaaS service was doing a flat name space for users & groups >> and nobody had a request from customers for a hierarchical model so the >> feature was dropped. >>=20 >>=20 >> Cheers, >> Morteza >>=20 >> On 3/24/15, 6:54 PM, "Haavar Valeur" wrote: >>=20 >>> Has there been any discussion around a standard SCIM extension that >>> handles organizational units (OU)? A quick google search came up with a >>> couple of emails from 3 years ago, but no real subsidence. >>>=20 >>> If there has not been any discussion around this, is there a reason for >>> it? >>>=20 >>> Best >>> Haavar >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>>=20 >>>https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si >>>EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL >>>0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2F >>>www.ietf.org%2Fmailman%2Flistinfo%2Fscim >>=20 >>=20 > From nobody Wed Mar 25 13:19:53 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653851B2B6F for ; Wed, 25 Mar 2015 13:19:51 -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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 iDoPR95WD1-o for ; Wed, 25 Mar 2015 13:19:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B52D1A8738 for ; Wed, 25 Mar 2015 13:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9839; q=dns/txt; s=iport; t=1427314789; x=1428524389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tAsY3ZjFQ0aYacJXlbVrntH0LB+2fAo1fb/W2C9ocQY=; b=HSroVS/SataaD/kZTFGwEjXqiSjiZKoKGzwwYaOV5571chALKrKSEyGD T9rjSZHoMI2nvU5Kp8dLqjVJacm25GyXZFN1R8nJv5cqyhqaZgjUz8B7m DmJTIibH1cIx7sHU8SUmmoGZetu+ru07DifGTl1EdzYIcPrxoZmlVkOIt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNBgDEFxNV/5pdJa1TBgOCQ0NSWgTCVoIxAQaFeAKBWkwBAQEBAQF9hBQBAQEDAQEBAWsEBwULAgEIDgMDAQIBFgEBDwcnCxQJCAIEAQ0FiCcIDcoRAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYQbSgEMBAcRAQEFhBUFkFCDb4N0ggyULCKDbm8BAYECBxcifwEBAQ X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208,217";a="406658314" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 25 Mar 2015 20:19:48 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2PKJmNh027844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 20:19:48 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.193]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 15:19:48 -0500 From: "Morteza Ansari (moransar)" To: Ian Glazer , Haavar Valeur Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA///pAQD//65UgA== Date: Wed, 25 Mar 2015 20:19:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.63.72] Content-Type: multipart/alternative; boundary="_000_D138821B1211FDmoransarciscocom_" MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:19:51 -0000 --_000_D138821B1211FDmoransarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for bringing that up. Yes, that type of relationship is easily repre= sented. A true hierarchical model where potentially even uniqueness is hier= archical (like LDAP) is what I was talking about. Cheers, Morteza From: Ian Glazer > Date: Wednesday, March 25, 2015 at 3:11 PM To: Haavar Valeur > Cc: Morteza Ansari >, "scim@i= etf.org" > Subject: Re: [scim] Organizational unit SCIM extension In our case we have a flat-ish model. We can represent OUs and a hierarchy = but it is represented on the user object and not as a standalone organizati= onal structure On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur > wrote: I think having the OUs be hierarchical should be an option if an extension = was added, but even without that I would think that it=92s beneficial to ha= ve OUs in the API. Without OU represented in the schema you would have loos= e references to objects that are created with proprietary APIs or schemas. I=92m a little surprised that the consensus was that SaaS providers have a = flat OU structure. From what I=92ve seen, a lot of providers support a hier= archy (with a some notable exceptions). I would think it would be a common = use case for larger customers of a SaaS provider to sync their employee dir= ectory to the provider, including OUs. The OUs would be used to set passwor= d polices, federated login settings and administration or product privilege= s on the SaaS provider side. Have the SaaS providers changed this over the years, or do I have the wrong= impression? > On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) > wrote: > > If you are talking about hierarchical organization of resource instances, > we had that discussion in the very early days of SCIM 1.0 work. I actuall= y > think I brought that up as a request but after talking to other vendors i= t > seemed every SaaS service was doing a flat name space for users & groups > and nobody had a request from customers for a hierarchical model so the > feature was dropped. > > > Cheers, > Morteza > > On 3/24/15, 6:54 PM, "Haavar Valeur" > wrote: > >> Has there been any discussion around a standard SCIM extension that >> handles organizational units (OU)? A quick google search came up with a >> couple of emails from 3 years ago, but no real subsidence. >> >> If there has not been any discussion around this, is there a reason for >> it? >> >> Best >> Haavar >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si= EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL0LL= o5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fscim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim -- Ian Glazer Senior Director, Identity +1 202 255 3166 @iglazer --_000_D138821B1211FDmoransarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for bringing that up. Yes, that type of relationship is easily = represented. A true hierarchical model where potentially even uniqueness is= hierarchical (like LDAP) is what I was talking about.


Cheers,
Morteza

From: Ian Glazer <iglazer@salesforce.com>
Date: Wednesday, March 25, 2015 at = 3:11 PM
To: Haavar Valeur <haavar.valeur@citrix.com>
Cc: Morteza Ansari <moransar@cisco.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] Organizational = unit SCIM extension

In our case we have a flat-ish model. We can represent OUs= and a hierarchy but it is represented on the user object and not as a stan= dalone organizational structure

On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur <= span dir=3D"ltr"> <haavar.va= leur@citrix.com> wrote:
I think having the OUs be hierarchical should be an option if an extension = was added, but even without that I would think that it=92s beneficial to ha= ve OUs in the API. Without OU represented in the schema you would have loos= e references to objects that are created with proprietary APIs or schemas.

I=92m a little surprised that the consensus was that SaaS providers have a = flat OU structure. From what I=92ve seen, a lot of providers support a hier= archy (with a some notable exceptions). I would think it would be a common = use case for larger customers of a SaaS provider to sync their employee directory to the provider, including OUs. = The OUs would be used to set password polices, federated login settings and= administration or product privileges on the SaaS provider side.

Have the SaaS providers changed this over the years, or do I have the wrong= impression?


> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
>
> If you are talking about hierarchical organization of resource instanc= es,
> we had that discussion in the very early days of SCIM 1.0 work. I actu= ally
> think I brought that up as a request but after talking to other vendor= s it
> seemed every SaaS service was doing a flat name space for users & = groups
> and nobody had a request from customers for a hierarchical model so th= e
> feature was dropped.
>
>
> Cheers,
> Morteza
>
> On 3/24/15, 6:54 PM, "Haavar Valeur" <haavar.valeur@citrix.com> wrote:
>
>> Has there been any discussion around a standard SCIM extension tha= t
>> handles organizational units (OU)? A quick google search came up w= ith a
>> couple of emails from 3 years ago, but no real subsidence.
>>
>> If there has not been any discussion around this, is there a reaso= n for
>> it?
>>
>> Best
>> Haavar
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9SiEHd= cWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL0LLo5a= 6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2Fwww.ietf.= org%2Fmailman%2Flistinfo%2Fscim
>
>

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



--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
 --_000_D138821B1211FDmoransarciscocom_-- From nobody Wed Mar 25 13:46:31 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592881A8A97 for ; Wed, 25 Mar 2015 13:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lzy_2lKpHYHw for ; Wed, 25 Mar 2015 13:46:28 -0700 (PDT) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05621A00D8 for ; Wed, 25 Mar 2015 13:46:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="246715795" From: Haavar Valeur To: "Morteza Ansari (moransar)" Thread-Topic: [scim] Organizational unit SCIM extension Thread-Index: AQHQZxtqAZJQG/Uhyk2Fltx5Ryl7+Z0uDFoA//+VPgCAAH8NAA== Date: Wed, 25 Mar 2015 20:46:24 +0000 Message-ID: <25626256-27A4-4FC3-8A2F-C56181677759@citrix.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-ID: <8A2C6ED7AE467E46B78695BDA7CF87B3@citrix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "scim@ietf.org" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:46:30 -0000 I might be wrong, I=92ve not gone too deep into the user administration of = different providers, but my first impression is that salesforce (apparently= actually flat-ish), google, amazon and SAP have some sort of hierarchy. I= =92m sure members of this WG have more detailed knowledge of the different = providers. I have not put much thought into how this can be represented as an extensio= n. I wanted to see if there has been any work in this area already, or if i= t=92s even needed. Seems like if it=92s expected to manage OUs external to = SCIM, and then have a soft reference on the user user object, it would be p= ossible to have an extension data model for OUs that are not intrusive to t= he core schema. > On Mar 25, 2015, at 3:11 PM, Morteza Ansari (moransar) wrote: >=20 > To be clear my previous response to your email and this email are with me > wearing implementer hat and not speaking as chair. >=20 > I can=B9t see how we could add the OU hierarchy as an extension of the SC= IM. > That would be a pretty intrusive change and require changes to almost > everything in SCIM. However, if you have ideas how this could be done, I > would love to hear them. >=20 > Also if you know of SaaS solutions where the identity space is > hierarchical, please share that. I started thinking the same way but > didn=B9t find any vendor that supported it or customers that asked for it= . >=20 >=20 > Cheers, > Morteza >=20 > On 3/25/15, 2:33 PM, "Haavar Valeur" wrote: >=20 >> I think having the OUs be hierarchical should be an option if an >> extension was added, but even without that I would think that it=B9s >> beneficial to have OUs in the API. Without OU represented in the schema >> you would have loose references to objects that are created with >> proprietary APIs or schemas. >>=20 >> I=B9m a little surprised that the consensus was that SaaS providers have= a >> flat OU structure. From what I=B9ve seen, a lot of providers support a >> hierarchy (with a some notable exceptions). I would think it would be a >> common use case for larger customers of a SaaS provider to sync their >> employee directory to the provider, including OUs. The OUs would be used >> to set password polices, federated login settings and administration or >> product privileges on the SaaS provider side. >>=20 >> Have the SaaS providers changed this over the years, or do I have the >> wrong impression? >>=20 >>=20 >>> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) >>> wrote: >>>=20 >>> If you are talking about hierarchical organization of resource >>> instances, >>> we had that discussion in the very early days of SCIM 1.0 work. I >>> actually >>> think I brought that up as a request but after talking to other vendors >>> it >>> seemed every SaaS service was doing a flat name space for users & group= s >>> and nobody had a request from customers for a hierarchical model so the >>> feature was dropped. >>>=20 >>>=20 >>> Cheers, >>> Morteza >>>=20 >>> On 3/24/15, 6:54 PM, "Haavar Valeur" wrote: >>>=20 >>>> Has there been any discussion around a standard SCIM extension that >>>> handles organizational units (OU)? A quick google search came up with = a >>>> couple of emails from 3 years ago, but no real subsidence. >>>>=20 >>>> If there has not been any discussion around this, is there a reason fo= r >>>> it? >>>>=20 >>>> Best >>>> Haavar >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>>=20 >>>> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9= Si >>>> EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZP= HL >>>> 0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%= 2F >>>> http://secure-web.cisco.com/1Eu6_QGp7T23OybgyO6R0YBcrk2gA5H6_Vq-ArbeGT= 7COGOcICwQByVBUplMr8O8ClHILi9O6lNofRWiFWH6ywXgPwf0J5vZL8TuJAYXRVacWmuhqE7wU= gKl34hfs0f-Mrpyk0cZUEf7k1gFotYWbMd0_2BWMR_NtGNAI3pYv_6KrtDx3dJ00seMmPigsLNU= u/http%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim >>>=20 >>>=20 >>=20 >=20 >=20 From nobody Sun Mar 29 03:25:11 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3953E1A1B73 for ; Sun, 29 Mar 2015 03:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 zqg3RMMMGQbQ for ; Sun, 29 Mar 2015 03:25:07 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D091A1B3C for ; Sun, 29 Mar 2015 03:25:06 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so89491231lbb.3 for ; Sun, 29 Mar 2015 03:25:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ybHlgxKFZzjUBeVrEC1SUD0TNtLosz9S76jaEFKMoKo=; b=WHLZ/yzqsBqKB3pz2i28ctOIUF4DJMQGBZdmQgnYhy/dLPHCYSmoPRgJv1QTYku/ma qy+c0pJeWQvFCuwsmJmT1IjMGjqCoM4vrIBLJxDEtQFIksKUuORzjAM8fPCjxE0KJvz9 HUaSm9wYluprkRPsxKFvr+q3orDgAGAahGKZTcII2jNO3qdLPQq2jX4LmZG7Ta/rvWCR 5TL9qYAdMdInDLStBQzn1kTUni7xLqQpyGcbbPy11p0L8APxJJ4C/fDMzZg4Ekxj48ZS W4HFAMeBlmIgu6dOdCXnDMMmIFgWvI+6og9YO9LPBUL4qC3VGj3LOhlzEBTjAa625MCZ dO8g== X-Gm-Message-State: ALoCoQmqUT91fL6zidixpdcsrmtOAKtK3YeFLrcZC/g9ckn9TZG/wN1/Ai6MgxAZn5sv8sEbfM88 MIME-Version: 1.0 X-Received: by 10.152.20.71 with SMTP id l7mr1044900lae.69.1427624704936; Sun, 29 Mar 2015 03:25:04 -0700 (PDT) Received: by 10.152.110.166 with HTTP; Sun, 29 Mar 2015 03:25:04 -0700 (PDT) In-Reply-To: <25626256-27A4-4FC3-8A2F-C56181677759@citrix.com> References: <25626256-27A4-4FC3-8A2F-C56181677759@citrix.com> Date: Sun, 29 Mar 2015 12:25:04 +0200 Message-ID: From: Samuel Erdtman To: Haavar Valeur Content-Type: multipart/alternative; boundary=089e01493e1c69200c05126ac717 Archived-At: Cc: "scim@ietf.org" , "Morteza Ansari \(moransar\)" Subject: Re: [scim] Organizational unit SCIM extension X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 10:25:10 -0000 --089e01493e1c69200c05126ac717 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Does not seem like there is a consensus that OU hierarchy is needed, however a suggestion for a solution came to mid so I just thought I send it out and se what people think. What about using the path to create the hierarchical OU structure /Users /Groups //Users //Groups When searching under / results would include Users/Groups under // but not the other way around. I dont know if this creates enough flexibility e.g with the following structure //Users //Users It would be hard to search for users in both ou2 and ou4 with one request. Best regards //Samuel On Wed, Mar 25, 2015 at 9:46 PM, Haavar Valeur wrote: > I might be wrong, I=E2=80=99ve not gone too deep into the user administra= tion of > different providers, but my first impression is that salesforce (apparent= ly > actually flat-ish), google, amazon and SAP have some sort of hierarchy. I= =E2=80=99m > sure members of this WG have more detailed knowledge of the different > providers. > > I have not put much thought into how this can be represented as an > extension. I wanted to see if there has been any work in this area alread= y, > or if it=E2=80=99s even needed. Seems like if it=E2=80=99s expected to ma= nage OUs external > to SCIM, and then have a soft reference on the user user object, it would > be possible to have an extension data model for OUs that are not intrusiv= e > to the core schema. > > > On Mar 25, 2015, at 3:11 PM, Morteza Ansari (moransar) < > moransar@cisco.com> wrote: > > > > To be clear my previous response to your email and this email are with = me > > wearing implementer hat and not speaking as chair. > > > > I can=C2=B9t see how we could add the OU hierarchy as an extension of t= he > SCIM. > > That would be a pretty intrusive change and require changes to almost > > everything in SCIM. However, if you have ideas how this could be done, = I > > would love to hear them. > > > > Also if you know of SaaS solutions where the identity space is > > hierarchical, please share that. I started thinking the same way but > > didn=C2=B9t find any vendor that supported it or customers that asked f= or it. > > > > > > Cheers, > > Morteza > > > > On 3/25/15, 2:33 PM, "Haavar Valeur" wrote: > > > >> I think having the OUs be hierarchical should be an option if an > >> extension was added, but even without that I would think that it=C2=B9= s > >> beneficial to have OUs in the API. Without OU represented in the schem= a > >> you would have loose references to objects that are created with > >> proprietary APIs or schemas. > >> > >> I=C2=B9m a little surprised that the consensus was that SaaS providers= have a > >> flat OU structure. From what I=C2=B9ve seen, a lot of providers suppor= t a > >> hierarchy (with a some notable exceptions). I would think it would be = a > >> common use case for larger customers of a SaaS provider to sync their > >> employee directory to the provider, including OUs. The OUs would be us= ed > >> to set password polices, federated login settings and administration o= r > >> product privileges on the SaaS provider side. > >> > >> Have the SaaS providers changed this over the years, or do I have the > >> wrong impression? > >> > >> > >>> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) > >>> wrote: > >>> > >>> If you are talking about hierarchical organization of resource > >>> instances, > >>> we had that discussion in the very early days of SCIM 1.0 work. I > >>> actually > >>> think I brought that up as a request but after talking to other vendo= rs > >>> it > >>> seemed every SaaS service was doing a flat name space for users & > groups > >>> and nobody had a request from customers for a hierarchical model so t= he > >>> feature was dropped. > >>> > >>> > >>> Cheers, > >>> Morteza > >>> > >>> On 3/24/15, 6:54 PM, "Haavar Valeur" wrote= : > >>> > >>>> Has there been any discussion around a standard SCIM extension that > >>>> handles organizational units (OU)? A quick google search came up wit= h > a > >>>> couple of emails from 3 years ago, but no real subsidence. > >>>> > >>>> If there has not been any discussion around this, is there a reason > for > >>>> it? > >>>> > >>>> Best > >>>> Haavar > >>>> _______________________________________________ > >>>> scim mailing list > >>>> scim@ietf.org > >>>> > >>>> > https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si > >>>> > EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL > >>>> > 0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2F > >>>> > http://secure-web.cisco.com/1Eu6_QGp7T23OybgyO6R0YBcrk2gA5H6_Vq-ArbeGT7CO= GOcICwQByVBUplMr8O8ClHILi9O6lNofRWiFWH6ywXgPwf0J5vZL8TuJAYXRVacWmuhqE7wUgKl= 34hfs0f-Mrpyk0cZUEf7k1gFotYWbMd0_2BWMR_NtGNAI3pYv_6KrtDx3dJ00seMmPigsLNUu/h= ttp%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim > >>> > >>> > >> > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --089e01493e1c69200c05126ac717 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Does not seem like there is a conse= nsus that OU hierarchy is needed, however a suggestion for a solution came = to mid so I just thought I send it out and se what people think.
=
What about using the path to create the hierarchical OU stru= cture

<base-path>/<ou1>Users
<base-path>/<ou1>Groups
<base-path>/<ou= 1>/<ou2>Users
<base-path>/<ou1>/<ou2&= gt;Groups

When searching under <base-path&g= t;/<ou1> results would include Users/Groups under <base-path>/&= lt;ou1>/<ou2> but not the other way around. I dont know if this cr= eates enough flexibility e.g
with the following structure
<base-path>/<ou1>/<ou2>Users
<base-path>/<ou3>/<ou4>Users
It would be h= ard to search for users in both ou2 and ou4 with one request.

Best regards
//Samuel

=





On Wed, Mar 25, = 2015 at 9:46 PM, Haavar Valeur <haavar.valeur@citrix.com> wrote:
I might be wrong, I=E2=80=99v= e not gone too deep into the user administration of different providers, bu= t my first impression is that salesforce (apparently actually flat-ish), go= ogle, amazon and SAP have some sort of hierarchy. I=E2=80=99m sure members = of this WG have more detailed knowledge of the different providers.

I have not put much thought into how this can be represented as an extensio= n. I wanted to see if there has been any work in this area already, or if i= t=E2=80=99s even needed. Seems like if it=E2=80=99s expected to manage OUs = external to SCIM, and then have a soft reference on the user user object, i= t would be possible to have an extension data model for OUs that are not in= trusive to the core schema.

> On Mar 25, 2015, at 3:11 PM, Morteza Ansari (moransar) <moransar@cisco.com> wrote:
>
> To be clear my previous response to your email and this email are with= me
> wearing implementer hat and not speaking as chair.
>
> I can=C2=B9t see how we could add the OU hierarchy as an extension of = the SCIM.
> That would be a pretty intrusive change and require changes to almost<= br> > everything in SCIM. However, if you have ideas how this could be done,= I
> would love to hear them.
>
> Also if you know of SaaS solutions where the identity space is
> hierarchical, please share that. I started thinking the same way but > didn=C2=B9t find any vendor that supported it or customers that asked = for it.
>
>
> Cheers,
> Morteza
>
> On 3/25/15, 2:33 PM, "Haavar Valeur" <haavar.valeur@citrix.com> wrote:
>
>> I think having the OUs be hierarchical should be an option if an >> extension was added, but even without that I would think that it= =C2=B9s
>> beneficial to have OUs in the API. Without OU represented in the s= chema
>> you would have loose references to objects that are created with >> proprietary APIs or schemas.
>>
>> I=C2=B9m a little surprised that the consensus was that SaaS provi= ders have a
>> flat OU structure. From what I=C2=B9ve seen, a lot of providers su= pport a
>> hierarchy (with a some notable exceptions). I would think it would= be a
>> common use case for larger customers of a SaaS provider to sync th= eir
>> employee directory to the provider, including OUs. The OUs would b= e used
>> to set password polices, federated login settings and administrati= on or
>> product privileges on the SaaS provider side.
>>
>> Have the SaaS providers changed this over the years, or do I have = the
>> wrong impression?
>>
>>
>>> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar)
>>> <moransar@cisco.com> wrote:
>>>
>>> If you are talking about hierarchical organization of resource=
>>> instances,
>>> we had that discussion in the very early days of SCIM 1.0 work= . I
>>> actually
>>> think I brought that up as a request but after talking to othe= r vendors
>>> it
>>> seemed every SaaS service was doing a flat name space for user= s & groups
>>> and nobody had a request from customers for a hierarchical mod= el so the
>>> feature was dropped.
>>>
>>>
>>> Cheers,
>>> Morteza
>>>
>>> On 3/24/15, 6:54 PM, "Haavar Valeur" <haavar.valeur@citrix.com> wrote: >>>
>>>> Has there been any discussion around a standard SCIM exten= sion that
>>>> handles organizational units (OU)? A quick google search c= ame up with a
>>>> couple of emails from 3 years ago, but no real subsidence.=
>>>>
>>>> If there has not been any discussion around this, is there= a reason for
>>>> it?
>>>>
>>>> Best
>>>> Haavar
>>>> _______________________________________________
>>>> scim mailing list
>>>> scim@ietf.org
>>>>
>>>> https://secure-web.cisco.com/1= NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si
>>>> EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCe= drTeDbsXWnZPHL
>>>> 0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/= https%3A%2F%2F
>>>> http://secure-web.cisco.com/1Eu6_QGp7T23= OybgyO6R0YBcrk2gA5H6_Vq-ArbeGT7COGOcICwQByVBUplMr8O8ClHILi9O6lNofRWiFWH6ywX= gPwf0J5vZL8TuJAYXRVacWmuhqE7wUgKl34hfs0f-Mrpyk0cZUEf7k1gFotYWbMd0_2BWMR_NtG= NAI3pYv_6KrtDx3dJ00seMmPigsLNUu/http%3A%2F%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fscim
>>>
>>>
>>
>
>

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

--089e01493e1c69200c05126ac717-- From nobody Sun Mar 29 20:18:34 2015 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9D71A1A99 for ; Sun, 29 Mar 2015 20:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EKTNP0hKUWye for ; Sun, 29 Mar 2015 20:18:31 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 E1F191A1A15 for ; Sun, 29 Mar 2015 20:18:30 -0700 (PDT) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t2U3ITVL011325 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Mar 2015 03:18:30 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t2U3ITXg006564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Mar 2015 03:18:29 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t2U3ITvU010482 for ; Mon, 30 Mar 2015 03:18:29 GMT Received: from [10.0.1.20] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 29 Mar 2015 20:18:29 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_7DED97E5-EC49-4D01-8CEB-005E16BE9418" Message-Id: <26DBF321-4A9E-4742-BB37-23F146815D28@oracle.com> Date: Sun, 29 Mar 2015 22:18:27 -0500 To: SCIM WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [scim] New Draft: draft-hunt-scim-password-mgmt-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 03:18:33 -0000 --Apple-Mail=_7DED97E5-EC49-4D01-8CEB-005E16BE9418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As per the discussion at the IETF92 SCIM WG meeting, I have submitted an = individual contribution for the password management proposal that Bjorn = presented last Thursday. I believe Bjorn will present a different model = in the near future. Link: draft-hunt-scim-password-mgmt = -00 This draft extends the SCIM core schema and includes all the schema and = resource type definitions to handle password policy, account state = (login failures etc) and account recovery functions. We have = successfully implemented a version very close to this draft (this draft = is more generic). During the Dallas meeting it was discussed that password management = should be done as part of a general credential management solution. = Though I haven=E2=80=99t yet updated the draft above, I do agree and = support a wider charter on credential management. Phil @independentid www.independentid.com phil.hunt@oracle.com --Apple-Mail=_7DED97E5-EC49-4D01-8CEB-005E16BE9418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As per the discussion at the IETF92 SCIM WG meeting, I have = submitted an individual contribution for the password management = proposal that Bjorn presented last Thursday. I believe Bjorn will = present a different model in the near future.

Link: draft-hunt-scim-password-mgmt-00

This draft extends the = SCIM core schema and includes all the schema and resource type = definitions to handle password policy, account state (login failures = etc) and account recovery functions. We have successfully implemented a = version very close to this draft (this draft is more generic).

During the Dallas = meeting it was discussed that password management should be done as part = of a general credential management solution. Though I haven=E2=80=99t = yet updated the draft above, I do agree and support a wider charter on = credential management.


= --Apple-Mail=_7DED97E5-EC49-4D01-8CEB-005E16BE9418--