From nobody Tue Dec 1 02:13:38 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A061B3A67 for ; Tue, 1 Dec 2015 02:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 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, RCVD_IN_DNSWL_HI=-5, 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 swUyuF9kmyGt for ; Tue, 1 Dec 2015 02:13:33 -0800 (PST) Received: from pimtaint01.ms.com (pimtaint01.ms.com [199.89.103.68]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BC71B3A66 for ; Tue, 1 Dec 2015 02:13:32 -0800 (PST) Received: from pimtaint01 (localhost.ms.com [127.0.0.1]) by pimtaint01.ms.com (output Postfix) with ESMTP id B2A7A3041C1 for ; Tue, 1 Dec 2015 05:13:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1448964811; x=1450174411; bh=IHLKJXlpz6PreD/Oa2WeTR7YnrwYc5EF3B7sv0sUFAY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=a1htbdoS9DNNPW2OTtZTuKbpchoMkCBbYkT7MGeM20gaSxPuQNTEUqsZv957LAfY1 woUuJ1ywgh49fKWNDgmiGSz0Qf6jk+73pC4F0atehAAbYrn59+zATJT1x5/XdlZPxw Q59mXCvgNXOlq4J32lY2fYHpqk+DzLMpZ1heCgRg= Received: from rrsmmta04.ms.com (rrsmmta04.ms.com [10.204.131.4]) by pimtaint01.ms.com (internal Postfix) with ESMTP id 9A7C13041B8; Tue, 1 Dec 2015 05:13:31 -0500 (EST) Received: from HZWEX2004N4.msad.ms.com (hzwex2004n4.ms.com [10.195.143.202]) by rrsmmta04.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB1ADVHb016752; Tue, 1 Dec 2015 10:13:31 GMT Received: from HZWEX2006N3.msad.ms.com (10.195.143.205) by HZWEX2004N4.msad.ms.com (10.195.143.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 05:13:30 -0500 Received: from OYWEX0203N4.msad.ms.com (10.208.118.84) by HZWEX2006N3.msad.ms.com (10.195.137.203) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 05:13:30 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0203N4.msad.ms.com ([169.254.4.193]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 10:13:29 +0000 From: "Bannister, Mark" To: "'Jordan Brown'" Thread-Topic: DBIS commentary Thread-Index: AQHRJ6BIKlY+hp6UAEOXycsas61P9Z6uB0MAgAb+lgCAAOCEYA== Date: Tue, 1 Dec 2015 10:13:28 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> In-Reply-To: <565CAC30.6010701@oracle.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFDOZWEX0209N2msad_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/01 04:08:00 #6830883; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 10:13:37 -0000 --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFDOZWEX0209N2msad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9yZGFuLA0KDQoNCg0KPiBPbiB0aGUgY2FzZS1zZW5zaXRpdml0eSBmcm9udDogIHdlIGhh dmUgYSBwcmV0dHkgZnVuZGFtZW50YWwgZGlzYWdyZWVtZW50LiAgSSBiZWxpZXZlIHRoYXQgVU5J WCBuYW1lcw0KDQo+IG11c3QgZXZlbnR1YWxseSBiZWNvbWUgY2FzZS1pbnNlbnNpdGl2ZSwgdGhh dCBpdCBpcyBvbmx5IGEgbWF0dGVyIG9mIHRpbWUgdW50aWwgdGhleSBkby4NCg0KDQoNClllcywg eW91J3JlIHJpZ2h0LCB0aGlzIGlzIGEgcHJldHR5IGZ1bmRhbWVudGFsIGRpc2FncmVlbWVudC4g IEFzIEkgZG9uJ3Qgc2VlIGFueW9uZSBlbHNlIGVudGVyaW5nIHRoZQ0KDQpkZWJhdGUgc3VwcG9y dGluZyBjYXNlIHNlbnNpdGl2aXR5LCBJIGZlYXIgdGhpcyB3aWxsIGZhaWwgb24gYSBzdGFuZGFy ZHMgdHJhY2suICBJIG1heSBqdXN0IGtlZXAgdGhlDQoNCnNvZnR3YXJlIGF2YWlsYWJsZSBhcyBh biBhbHRlcm5hdGl2ZSwgYW5kIHRob3NlIHdobyB3YW50IGl0IGNhbiB1c2UgaXQsIGJ1dCBJIHRo aW5rIGFueSBob3BlcyBJIGhhZA0KDQp0aGF0IERCSVMgbWlnaHQgb25lIGRheSBiZSBhIHN0YW5k YXJkIGhhdmUganVzdCBiZWVuIGRhc2hlZC4gIEkgd2lsbCBjb250aW51ZSB0byBhbnN3ZXIgc29t ZQ0KDQpvZiB5b3VyIHBvaW50cyBhbnl3YXksIGp1c3QgZm9yIGNvbXBsZXRpb24uICBUaG9zZSB3 aG8gYWdyZWUgd2l0aCBtZSBhcmUgZWl0aGVyIGEpIG5vdCBzcGVha2luZw0KDQp1cCBvciBiKSBu b3QgcmVhZGluZyB0aGlzIG1haWxpbmcgbGlzdC4NCg0KDQoNCkhvd2V2ZXIsIEkgd291bGQgcG9p bnQgb3V0IHRoYXQgeW91IHdpbGwgbWVldCByZXNpc3RhbmNlIChhbmQvb3IgZGlzZ3J1bnRsZWQg Y3VzdG9tZXJzIGFmdGVyIHRoZQ0KDQpmYWN0KSBpZiB5b3UgYXR0ZW1wdCB0byBjaGFuZ2UgVU5J WCB0byBiZSBjYXNlLWluc2Vuc2l0aXZlLiAgQnR3LCB3aGF0IHdhcyB5b3VyIHBsYW4gZm9yIGNh c2UNCg0Kc2Vuc2l0aXZpdHkgaW4gZmlsZXN5c3RlbXM/DQoNCg0KDQo+IFVOSVggaXMgbm90IHRo ZSB3aG9sZSB3b3JsZCwgYW5kIHRoZSBlbnRpcmUgcmVzdCBvZiB0aGUgd29ybGQgaXMgY2xlYXIg dGhhdCBNQVJLLCBNYXJrLCBhbmQgbWFyaw0KDQo+IGFyZSB0aGUgc2FtZSBwZXJzb24uDQoNCg0K DQpXaXRoIHBlb3BsZSwgcGVyaGFwcy4gIFdpdGggcGVvcGxlIHZzLiBzZXJ2aWNlIGFjY291bnRz IHBlcmhhcHMgbm90LiAgUGVyaGFwcyBJIGhhdmUgYSB1c2VyIHdpdGgNCg0KYSBsb2dpbiBuYW1l IG9mICdzaGVpbGEnIGJ1dCBJIGFsc28gaGF2ZSBhIHNlcnZpY2UgYWNjb3VudCBjYWxsZWQgJ1NI RUlMQScuICBJIHN1cHBvc2UgbmV4dCB5b3Ugd2lsbA0KDQpiZSBwcm9wb3NpbmcgdG8gcmVkZWZp bmUgdGhlIEVuZ2xpc2ggbGFuZ3VhZ2UgYnkgc2F5aW5nIHRoYXQgY2FzZSBpcyB1bmltcG9ydGFu dCB3aGVuIHN0YXJ0aW5nDQoNCnNlbnRlbmNlcywgb3Igd2hlbiB3cml0aW5nIHByb3BlciBub3Vu cyB2cyBub3Vucz8gIEJlIGNhcmVmdWwgd2hlbiB5b3Ugc2F5ICJ0aGUgZW50aXJlIHJlc3QNCg0K b2YgdGhlIHdvcmxkIiwgYmUgc3VyZSB5b3UgcmVhbGx5IGtub3cgdGhlIGVudGlyZSByZXN0IG9m IHRoZSB3b3JsZC4gIEkgZG9uJ3QgY2xhaW0gdG8sIGJ1dCBJIGRvIGhhdmUNCg0KcmVhbCBleGFt cGxlcyBvZiBwcm9ibGVtcyB0aGF0IERCSVMgaXMgc29sdmluZyB0b2RheS4NCg0KDQoNCj4gPiBJ ZiB5b3UgaGF2ZSBhbiBpc3N1ZSB3aXRoIGF1dGhQYXNzd29yZCBiZWluZyBpbiBSRkMyMzA3Ymlz LCBub3cgaXMgdGhlDQoNCj4gPiB0aW1lIHRvIHJhaXNlIGl0LCBhcyBpdCBpcyBvbiB0aGUgbmV3 IExEQVBFWFQgY2hhcnRlciBhbmQgdGhlIFdHIGFyZQ0KDQo+ID4gcGxhbm5pbmcgdG8gZmluYWxp c2UgUkZDMjMwN2JpcyBpbiB0aGUgbmV4dCAxMiBtb250aHMgYW5kIGdpdmUgaXQgaXRzIG93biBS RkMgbnVtYmVyLg0KDQo+DQoNCj4gSSByZWNvbW1lbmQgbG9va2luZyBwcmV0dHkgaGFyZCBhdCB3 aGV0aGVyIGEgbmV3IGF0dHJpYnV0ZSBpcyBuZWVkZWQsIGdpdmVuIHRoYXQgdGhlcmUNCg0KPiBz ZWVtIHRvIGJlIHRocmVlIG90aGVyIGV4aXN0aW5nIGF0dHJpYnV0ZXMuDQoNCj4NCg0KPiBJbiBn ZW5lcmFsLCBpdCBzZWVtcyBiZXN0IHRvIGRpc2NvdXJhZ2UgbWFraW5nIHBhc3N3b3JkIGhhc2hl cyB2aXNpYmxlIC0gcGVyaGFwcyBldmVuIHRvDQoNCj4gdGhlIHBvaW50IG9mIG5vdCBzdGFuZGFy ZGl6aW5nIHRoZW0uDQoNCg0KDQpZb3UgbWlnaHQgd2FudCB0byBwb2ludCB0aGF0IG91dCBpbiBh IHNlcGFyYXRlIHRocmVhZCwgYXMgSSBzYXksIFJGQzIzMDdiaXMgaXMgb24gdGhlIG5ldw0KDQpM REFQRVhUIGNoYXJ0ZXIgYnV0IHRob3NlIHJ1bm5pbmcgd2l0aCB0aGUgbmV3IGNoYXJ0ZXIgbWF5 IG5vdCBiZSByZWFkaW5nIHRoZXNlIGVtYWlsDQoNCmNoYWlucyBpbiBhbnkgZGVwdGguDQoNCg0K DQo+IE15IGtleSBwb2ludCBoZXJlIGlzIHRoYXQgREJJUyBzaG91bGQgc3BlY2lmeSB3aGF0IGF0 dHJpYnV0ZSBzaG91bGQgcmVwbGFjZSBpdCwgd2hhdCBhdHRyaWJ1dGUNCg0KPiBjbGllbnRzIGFy ZSBleHBlY3RlZCB0byB1c2UgdG8gcG9wdWxhdGUgdGhlIHB3X2dlY29zIGZpZWxkIGluIHN0cnVj dCBwYXNzd2QuDQoNCg0KDQpkcmFmdC1iYW5uaXN0ZXItZGJpcy1wYXNzd2QgcHJvdmlkZXMgYSBz dWdnZXN0aW9uIGFscmVhZHkgaW4gMi4xLjMuMToNCg0KDQoNCiAgIFRoZSBwb3NpeFVzZXJBY2Nv dW50IG9iamVjdCBjbGFzcyBpcyBhdXhpbGlhcnkgYW5kIG11c3QgYWx3YXlzIGJlDQoNCiAgIGFz c29jaWF0ZWQgd2l0aCBhbm90aGVyIHN0cnVjdHVyYWwgY2xhc3MuICBPbmUgc3VjaCBjbGFzcyBp cw0KDQogICBpbmV0T3JnUGVyc29uIFtSRkMyNzk4XS4gIElmIHVzZXIgYWNjb3VudHMgd2VyZSBn aXZlbiB0aGUNCg0KICAgaW5ldE9yZ1BlcnNvbiBjbGFzcywgdGhlbiBkaXNwbGF5TmFtZSBtaWdo dCBiZSBhbiBhcHByb3ByaWF0ZSB2YWx1ZQ0KDQogICBmb3IgdGhlIGRiaXNNYXBHZWNvcyBhdHRy aWJ1dGUuDQoNCg0KDQpHaXZlbiB0aGF0IHRoZSBnZWNvcyBmaWVsZCBjYW4gZW5jb2RlIGFueXRo aW5nIGluIGFueSBmb3JtYXQsIEkgZGlkbid0IHRoaW5rIEkgY291bGQgcmVhbGlzdGljYWxseQ0K DQpkbyBhbnkgYmV0dGVyIHRoYW4gcHJvdmlkZSBhIHN1Z2dlc3Rpb24uDQoNCg0KDQo+ID4+IHBv c2l4R3JvdXAgLyBwb3NpeEdyb3VwQWNjb3VudA0KDQo+ID4+DQoNCj4gPj4gWC41MjEgZ3JvdXBP Zk5hbWVzIHNlZW1zIGxpa2UgYSBtb3JlIGFwcHJvcHJpYXRlIGJhc2lzIGZvciB0aGUgZGVmaW5p dGlvbiBvZiBhIGdyb3VwLg0KDQo+ID4gQnV0IHRoYXQgZG9lc24ndCBhbGxvdyBmb3IgR0lEIG51 bWJlci4NCg0KPg0KDQo+IEEgc3ViY2xhc3MgZG9lcy4NCg0KDQoNCkkgaGF2ZSBwZW9wbGUgdGVs bGluZyBtZSBncm91cE9mTmFtZXMgZG9lc24ndCB3b3JrIHdlbGwgZm9yIHRoZW0gYmVjYXVzZSBp dCBjYW4gYmUgYSBncm91cA0KDQpvZiBhbnl0aGluZy4gIEV4dHJhIExEQVAgc2VhcmNoZXMgYXJl IHJlcXVpcmVkIHRvIGZpZ3VyZSBvdXQgd2hhdCB0eXBlIG9mIG9iamVjdCB0aGUgbWVtYmVycw0K DQphcmUuICBUaGF0IGxlYWRzIHRvIGEgcmF0aGVyIGluZWZmaWNpZW50IHN5c3RlbS4NCg0KDQoN Cj4gPj4gbmlzTmV0Z3JvdXAgLyBuZXRncm91cE9iamVjdA0KDQo+ID4+DQoNCj4gPj4gQWx0aG91 Z2ggbm90IGEgcGVyZmVjdCBtYXRjaCwgZ3JvdXBPZk5hbWVzIHNlZW1zIGxpa2UgaXQgbWlnaHQg YmUgYQ0KDQo+ID4+IGJldHRlciBiYXNpcyBmb3IgZ3JvdXBpbmcgY29tcHV0ZXJzLg0KDQo+ID4g bmV0Z3JvdXBzIGFyZSBhIHNwZWNpZmljIGNvbnN0cnVjdCwgdHJ5aW5nIHRvIHNxdWVlemUgdGhl bSBpbnRvDQoNCj4gPiBzb21ldGhpbmcgZWxzZSB0aGF0IGlzIG5vdCBhIHBlcmZlY3QgbWF0Y2gg d291bGQgYmUgYSBzdWJvcHRpbWFsDQoNCj4gPiBkZWNpc2lvbi4gIExEQVAgY2FuIHJlcHJlc2Vu dCBuZXRncm91cCBkYXRhIGJldHRlciwgc28gbGV0J3MgcmVwcmVzZW50IGl0IGJldHRlci4NCg0K Pg0KDQo+IFllcywgaXQgY2FuLi4uIGFuZCBmb3IgbW9zdCBwdXJwb3NlcyBpdCBoYXMsIGluIHRo ZSBmb3JtIG9mIGdyb3VwT2ZOYW1lcy4gIElmIHlvdSBoYXZlIHVzZXJzDQoNCj4gcmVwcmVzZW50 ZWQgaW4gdGhlIGRpcmVjdG9yeSwgdGhlIG5hdHVyYWwgd2F5IHRvIGdyb3VwIHRoZW0gaXMgd2l0 aCBncm91cE9mTmFtZXMuICBJZiB5b3UNCg0KPiBoYXZlIGhvc3RzIHJlcHJlc2VudGVkIGluIHRo ZSBkaXJlY3RvcnksIHRoZSBuYXR1cmFsIHdheSB0byBncm91cCB0aGVtIGlzIHdpdGggZ3JvdXBP Zk5hbWVzLg0KDQo+IFRoZSBvbmx5IHRoaW5nIHRoYXQgdGhlcmUgaXNuJ3QgYW4gb2J2aW91cyB3 YXkgdG8gZ3JvdXAgaXMgInVzZXIgWCBvbiBob3N0IFkiLiAgTm90IHRoYXQgSSd2ZSBzZWVuDQoN Cj4gYSBsb3Qgb2YgY29uY3JldGUgaW5zdGFuY2VzIG9mIG5ldGdyb3VwcywgYnV0IEkgZG9uJ3Qg dGhpbmsgSSd2ZSBzZWVuIG9uZSBvZiB0aG9zZSB5ZXQuDQoNCg0KDQpTZWUgcHJldmlvdXMgcmVz ZXJ2YXRpb25zIHJlZ2FyZGluZyBncm91cE9mTmFtZXMuICBJbWFnaW5lIHRyeWluZyB0byBjb25z dHJ1Y3QgYSBzZWFyY2gNCg0Kb3BlcmF0aW9uIHRvIGZpbmQganVzdCBob3N0IG1lbWJlcnMsIG9y IGp1c3QgdXNlciBtZW1iZXJzLg0KDQoNCg0KSG93ZXZlciwgSSBzZWVtIHRvIGJlIGEgbG9uZSB2 b2ljZSBhZ2FpbiBpbiBmYXZvdXIgb2YgbmV0Z3JvdXBzLiAgSSd2ZSBzZWVuIHRoZW0gdXNlZCBh biBhd2Z1bA0KDQpsb3QgYW5kIHdpdGggYSBiaXQgb2YgaW1wcm92ZW1lbnQsIHRoZXknbGwgYmUg YSBsb3QgbW9yZSBtYW5hZ2VhYmxlLiAgSSBrbm93IGhvdyBwYWluZnVsIGl0IHdpbGwNCg0KYmUg Zm9yIGZvbGsgdG8gdHJ5IHRvIG1vdmUgYXdheSBmcm9tIHRoZW0sIHNvIGluIHRoZSBzcGlyaXQg b2YgbWFraW5nIHRoaW5ncyBlYXN5IGZvciBwZW9wbGUNCg0KSSBoYXZlIGJlZW4gcHJvcG9zaW5n IGluY3JlbWVudGFsIGltcHJvdmVtZW50cyByYXRoZXIgdGhhbiBqdXN0IGR1bXBpbmcgdGhlbSBh bmQNCg0KZG9pbmcgc29tZXRoaW5nIGNvbXBsZXRlbHkgZGlmZmVyZW50LiAgRXZlcnlvbmUgZWxz ZSBjb21tZW50aW5nIG9uIHRoaXMgbGlzdCBzZWVtcyB0byBoYXRlDQoNCnRoZW0uICBBbm90aGVy IGZ1bmRhbWVudGFsIGRpZmZlcmVuY2Ugd2UgaGF2ZSAuLi4NCg0KDQoNCj4gSGF2aW5nIHR3byBu YW1lcyB0aGF0IGRpZmZlciBvbmx5IGluIGNhc2UgbGVhZCB0byBkaWZmZXJlbnQgcG9ydCBudW1i ZXJzIHNlZW1zIGxpa2UgYQ0KDQo+IHNwZWN0YWN1bGFybHkgYmFkIGlkZWEuICBJZiB0aGVyZSdz IGFuIG9yZ2FuaXphdGlvbiB0aGF0IGhhcyBzb21laG93IGZvdW5kIHRoZW1zZWx2ZXMNCg0KPiBp biBzdWNoIGEgbWVzcyB0aGVuIEknbSB2ZXJ5IHNvcnJ5IGZvciB0aGVtDQoNCg0KDQo8cmFudD4N Cg0KV2FpdC4gIE5JUyBwZXJtaXR0ZWQgdGhpcy4gIElmIGZvbGsgaGF2ZSBkb25lIHdoYXQgTklT IGFsbG93ZWQgdGhlbSB0byBkbywgYW5kIGl0DQoNCmZpdHRlZCB0aGVpciB3b3JraW5nIHByYWN0 aWNlLCB0aGVuIHlvdSBjYW4ndCBibGFtZSB0aGVtIGZvciB0aGF0LiAgSWYgeW91IGRvbid0IGxp a2UgaXQNCg0KYW5kIHdhbnQgdG8gbGFiZWwgaXQgImEgbWVzcyIsIHRoYXQncyBmaW5lIHlvdSBj YW4gZG8gdGhhdCwgYnV0IEkgZG8gbm90IHdhbnQgdG8gbGVhdmUNCg0KcGVvcGxlIGJlaGluZC4g IElmIHlvdSB3aXNoIHRvIGNhbGwgaXQgYSBtZXNzLCB0aGVuIFN1biBNaWNyb3N5c3RlbXMgY3Jl YXRlZCB0aGUgbWVzcywNCg0KYnV0IGl0J3MgaW5mcmFzdHJ1Y3R1cmUgYW5kIHdlJ3JlIHN0dWNr IHdpdGggaXQuICBJbWFnaW5lIGlmIHRoZSBlbGVjdHJvbmljcyBpbmR1c3RyeSBpbiBBbWVyaWNh DQoNCnN0YXJ0ZWQgc2VsbGluZyBkZXZpY2VzIHdpdGggb25seSBFbmdsaXNoIHRocmVlLXBpbiBw bHVnczxodHRwczovL3d3dy5nb29nbGUuY28udWsvdXJsP3NhPXQmcmN0PWomcT0mZXNyYz1zJnNv dXJjZT13ZWImY2Q9MiZjYWQ9cmphJnVhY3Q9OCZ2ZWQ9MGFoVUtFd2lRemZqUnM3ckpBaFVDS2lZ S0hZNmVDWm9RRmdnaU1BRSZ1cmw9aHR0cCUzQSUyRiUyRnd3dy5mYXN0Y29kZXNpZ24uY29tJTJG MzAzMjgwNyUyRndoeS1lbmdsYW5kLWhhcy10aGUtYmVzdC13YWxsLXNvY2tldHMtb24tZWFydGgm dXNnPUFGUWpDTkVQNHNyZW1rdkk1NkJvVGI3RDdySmhGYVJiZ2c+LCBjaXRpbmcgdGhhdCB0aGUg b3JpZ2luYWwgd2FzIGENCg0K4oCcYmFkIGRlc2lnbuKAnSBhbmQgYW55b25lIHdobyBoYXMgZm91 bmQgdGhlbXNlbHZlcyBpbiBzdWNoIGEgbWVzcyBhcyB0byBoYXZlDQoNCmluY29tcGF0aWJsZSB3 YWxsIHNvY2tldHMsIHdlbGwgdmVyeSBzb3JyeSBmb3IgdGhlbSBidXQgdGhhdOKAmXMganVzdCB0 b3VnaCBsdWNrLg0KDQpSaWdodC4gIFlvdeKAmWQgY2F1c2UgYW4gb3V0Y3J5LiAgU2FtZSB0aGlu ZyBhcHBsaWVzIGhlcmUuICBXaXRoIE5JUyBhIHBhcnRpY3VsYXINCg0Kd29ya2luZyBwcmFjdGlj ZSB3YXMgYWJzb2x1dGVseSBmaW5lLiAgTm93IGl0IGlzbuKAmXQuICBBbmQgcGVvcGxlIGFyZSBs ZWZ0IHRvIGZpeCBpdA0KDQp0aGVtc2VsdmVzLiAgSSB0aGluayB0aGF04oCZcyB2ZXJ5IGJhZC4g IChBbmQgZm9yIHRob3NlIHdobyBzYXkg4oCcTklTIGlzIGRlYWTigJ0sIHRoYXTigJlzDQoNCmFi c29sdXRlbHkgbm90IHRydWUsIHRoZXJlIGFyZSBsYXJnZSBvcmdhbmlzYXRpb25zIHN0aWxsIHVz aW5nIE5JUyBhbmQgd2hvIGhhdmVu4oCZdA0KDQp5ZXQgbWlncmF0ZWQgdG8gTERBUCwgcGVyaGFw cyBiZWNhdXNlIHRoZSBtaWdyYXRpb24gdG8gTERBUCBpcyB0b28gaGFyZCBmb3INCg0KdGhlbSBp biB0aGUgcHJlc2VudCBjbGltYXRlKS4NCg0KPC9yYW50Pg0KDQoNCg0KQmVzdCByZWdhcmRzLA0K DQpNYXJrLg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpOT1RJ Q0U6IE1vcmdhbiBTdGFubGV5IGlzIG5vdCBhY3RpbmcgYXMgYSBtdW5pY2lwYWwgYWR2aXNvciBh bmQgdGhlIG9waW5pb25zIG9yIHZpZXdzIGNvbnRhaW5lZCBoZXJlaW4gYXJlIG5vdCBpbnRlbmRl ZCB0byBiZSwgYW5kIGRvIG5vdCBjb25zdGl0dXRlLCBhZHZpY2Ugd2l0aGluIHRoZSBtZWFuaW5n IG9mIFNlY3Rpb24gOTc1IG9mIHRoZSBEb2RkLUZyYW5rIFdhbGwgU3RyZWV0IFJlZm9ybSBhbmQg Q29uc3VtZXIgUHJvdGVjdGlvbiBBY3QuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVu aWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGRlc3Ryb3kgYWxsIGVsZWN0cm9uaWMgYW5kIHBhcGVy IGNvcGllczsgZG8gbm90IGRpc2Nsb3NlLCB1c2Ugb3IgYWN0IHVwb24gdGhlIGluZm9ybWF0aW9u OyBhbmQgbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuIE1pc3RyYW5zbWlzc2lvbiBpcyBu b3QgaW50ZW5kZWQgdG8gd2FpdmUgY29uZmlkZW50aWFsaXR5IG9yIHByaXZpbGVnZS4gTW9yZ2Fu IFN0YW5sZXkgcmVzZXJ2ZXMgdGhlIHJpZ2h0LCB0byB0aGUgZXh0ZW50IHBlcm1pdHRlZCB1bmRl ciBhcHBsaWNhYmxlIGxhdywgdG8gbW9uaXRvciBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zLiBU aGlzIG1lc3NhZ2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2lu ZyBsaW5rOiBodHRwOi8vd3d3Lm1vcmdhbnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzIElmIHlvdSBj YW5ub3QgYWNjZXNzIHRoZXNlIGxpbmtzLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IG1lc3Nh Z2UgYW5kIHdlIHdpbGwgc2VuZCB0aGUgY29udGVudHMgdG8geW91LiBCeSBtZXNzYWdpbmcgd2l0 aCBNb3JnYW4gU3RhbmxleSB5b3UgY29uc2VudCB0byB0aGUgZm9yZWdvaW5nLg0K --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFDOZWEX0209N2msad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8SEVBRD48IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNsYWlt ZXIgVGVtcGxhdGUgRWRpdG9yIG9uIDA1OjEzOjMxIFR1ZXNkYXksIDEgRGVjZW1iZXIgMjAxNSAt LT4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPlAuY2FmYTg1OGMtYTY0YS00MDE4LWIzNTctZWI4MDg0 YjZiMjY3IHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpMSS5jYWZhODU4Yy1hNjRhLTQwMTgt YjM1Ny1lYjgwODRiNmIyNjcgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5jYWZhODU4 Yy1hNjRhLTQwMTgtYjM1Ny1lYjgwODRiNmIyNjcgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0N ClRBQkxFLmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWViODA4NGI2YjI2N1RhYmxlIHsNCglNQVJH SU46IDBjbSAwY20gMHB0DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8 L1NUWUxFPg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCIgLz4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiIC8+DQo8c3R5bGU+PCEtLQ0KLyog Rm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBk aXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29Ob1NwYWNpbmcsIGxpLk1zb05vU3BhY2luZywgZGl2 Lk1zb05vU3BhY2luZw0KCXttc28tc3R5bGUtcHJpb3JpdHk6MTsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5Db2RlDQoJe21zby1z dHlsZS1uYW1lOkNvZGU7DQoJbXNvLXN0eWxlLXByaW9yaXR5OjE7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L0hFQUQ+DQoNCjxCT0RZIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxQPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkhpIEpvcmRhbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiB0aGUgY2Fz ZS1zZW5zaXRpdml0eSBmcm9udDombmJzcDsgd2UgaGF2ZSBhIHByZXR0eSBmdW5kYW1lbnRhbCBk aXNhZ3JlZW1lbnQuJm5ic3A7IEkgYmVsaWV2ZSB0aGF0IFVOSVggbmFtZXM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbXVzdCBldmVudHVhbGx5IGJlY29tZSBj YXNlLWluc2Vuc2l0aXZlLCB0aGF0IGl0IGlzIG9ubHkgYSBtYXR0ZXIgb2YgdGltZSB1bnRpbCB0 aGV5IGRvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ZZXMsIHlvdSdyZSByaWdodCwg dGhpcyBpcyBhIHByZXR0eSBmdW5kYW1lbnRhbCBkaXNhZ3JlZW1lbnQuJm5ic3A7IEFzIEkgZG9u J3Qgc2VlIGFueW9uZSBlbHNlIGVudGVyaW5nIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+ZGViYXRlIHN1cHBvcnRpbmcgY2FzZSBzZW5zaXRpdml0eSwgSSBmZWFy IHRoaXMgd2lsbCBmYWlsIG9uIGEgc3RhbmRhcmRzIHRyYWNrLiZuYnNwOyBJIG1heSBqdXN0IGtl ZXAgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zb2Z0d2FyZSBh dmFpbGFibGUgYXMgYW4gYWx0ZXJuYXRpdmUsIGFuZCB0aG9zZSB3aG8gd2FudCBpdCBjYW4gdXNl IGl0LCBidXQgSSB0aGluayBhbnkgaG9wZXMgSSBoYWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPnRoYXQgREJJUyBtaWdodCBvbmUgZGF5IGJlIGEgc3RhbmRhcmQgaGF2 ZSBqdXN0IGJlZW4gZGFzaGVkLiZuYnNwOyBJIHdpbGwgY29udGludWUgdG8gYW5zd2VyIHNvbWU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm9mIHlvdXIgcG9pbnRzIGFu eXdheSwganVzdCBmb3IgY29tcGxldGlvbi4mbmJzcDsgVGhvc2Ugd2hvIGFncmVlIHdpdGggbWUg YXJlIGVpdGhlciBhKSBub3Qgc3BlYWtpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnVwIG9yIGIpIG5vdCByZWFkaW5nIHRoaXMgbWFpbGluZyBsaXN0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCBJIHdvdWxkIHBvaW50IG91dCB0aGF0IHlv dSB3aWxsIG1lZXQgcmVzaXN0YW5jZSAoYW5kL29yIGRpc2dydW50bGVkIGN1c3RvbWVycyBhZnRl ciB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmZhY3QpIGlmIHlv dSBhdHRlbXB0IHRvIGNoYW5nZSBVTklYIHRvIGJlIGNhc2UtaW5zZW5zaXRpdmUuJm5ic3A7IEJ0 dywgd2hhdCB3YXMgeW91ciBwbGFuIGZvciBjYXNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5zZW5zaXRpdml0eSBpbiBmaWxlc3lzdGVtcz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBVTklYIGlzIG5vdCB0aGUgd2hvbGUgd29ybGQsIGFuZCB0aGUg ZW50aXJlIHJlc3Qgb2YgdGhlIHdvcmxkIGlzIGNsZWFyIHRoYXQgTUFSSywgTWFyaywgYW5kIG1h cms8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYXJlIHRoZSBz YW1lIHBlcnNvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2l0aCBwZW9wbGUsIHBl cmhhcHMuJm5ic3A7IFdpdGggcGVvcGxlIHZzLiBzZXJ2aWNlIGFjY291bnRzIHBlcmhhcHMgbm90 LiZuYnNwOyBQZXJoYXBzIEkgaGF2ZSBhIHVzZXIgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+YSBsb2dpbiBuYW1lIG9mICdzaGVpbGEnIGJ1dCBJIGFsc28gaGF2 ZSBhIHNlcnZpY2UgYWNjb3VudCBjYWxsZWQgJ1NIRUlMQScuJm5ic3A7IEkgc3VwcG9zZSBuZXh0 IHlvdSB3aWxsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5iZSBwcm9w b3NpbmcgdG8gcmVkZWZpbmUgdGhlIEVuZ2xpc2ggbGFuZ3VhZ2UgYnkgc2F5aW5nIHRoYXQgY2Fz ZSBpcyB1bmltcG9ydGFudCB3aGVuIHN0YXJ0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5zZW50ZW5jZXMsIG9yIHdoZW4gd3JpdGluZyBwcm9wZXIgbm91bnMgdnMg bm91bnM/Jm5ic3A7IEJlIGNhcmVmdWwgd2hlbiB5b3Ugc2F5ICZxdW90O3RoZSBlbnRpcmUgcmVz dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+b2YgdGhlIHdvcmxkJnF1 b3Q7LCBiZSBzdXJlIHlvdSByZWFsbHkga25vdyB0aGUgZW50aXJlIHJlc3Qgb2YgdGhlIHdvcmxk LiZuYnNwOyBJIGRvbid0IGNsYWltIHRvLCBidXQgSSBkbyBoYXZlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5yZWFsIGV4YW1wbGVzIG9mIHByb2JsZW1zIHRoYXQgREJJ UyBpcyBzb2x2aW5nIHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgSWYgeW91IGhhdmUgYW4gaXNzdWUgd2l0aCBhdXRoUGFzc3dvcmQgYmVpbmcgaW4gUkZDMjMw N2Jpcywgbm93IGlzIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsgdGltZSB0byByYWlzZSBpdCwgYXMgaXQgaXMgb24gdGhlIG5ldyBMREFQRVhU IGNoYXJ0ZXIgYW5kIHRoZSBXRyBhcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7IHBsYW5uaW5nIHRvIGZpbmFsaXNlIFJGQzIzMDdiaXMgaW4gdGhl IG5leHQgMTIgbW9udGhzIGFuZCBnaXZlIGl0IGl0cyBvd24gUkZDIG51bWJlci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgcmVjb21tZW5kIGxvb2tpbmcgcHJldHR5IGhhcmQg YXQgd2hldGhlciBhIG5ldyBhdHRyaWJ1dGUgaXMgbmVlZGVkLCBnaXZlbiB0aGF0IHRoZXJlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNlZW0gdG8gYmUgdGhy ZWUgb3RoZXIgZXhpc3RpbmcgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IEluIGdlbmVyYWwsIGl0IHNlZW1zIGJlc3QgdG8gZGlzY291cmFnZSBtYWtpbmcgcGFz c3dvcmQgaGFzaGVzIHZpc2libGUgLSBwZXJoYXBzIGV2ZW4gdG88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIHBvaW50IG9mIG5vdCBzdGFuZGFyZGl6aW5n IHRoZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllvdSBtaWdodCB3YW50IHRvIHBv aW50IHRoYXQgb3V0IGluIGEgc2VwYXJhdGUgdGhyZWFkLCBhcyBJIHNheSwgUkZDMjMwN2JpcyBp cyBvbiB0aGUgbmV3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5MREFQ RVhUIGNoYXJ0ZXIgYnV0IHRob3NlIHJ1bm5pbmcgd2l0aCB0aGUgbmV3IGNoYXJ0ZXIgbWF5IG5v dCBiZSByZWFkaW5nIHRoZXNlIGVtYWlsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5jaGFpbnMgaW4gYW55IGRlcHRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IE15IGtleSBwb2ludCBoZXJlIGlzIHRoYXQgREJJUyBzaG91bGQgc3BlY2lmeSB3aGF0 IGF0dHJpYnV0ZSBzaG91bGQgcmVwbGFjZSBpdCwgd2hhdCBhdHRyaWJ1dGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY2xpZW50cyBhcmUgZXhwZWN0ZWQgdG8g dXNlIHRvIHBvcHVsYXRlIHRoZSBwd19nZWNvcyBmaWVsZCBpbiBzdHJ1Y3QgcGFzc3dkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5kcmFmdC1iYW5uaXN0ZXItZGJpcy1wYXNzd2QgcHJv dmlkZXMgYSBzdWdnZXN0aW9uIGFscmVhZHkgaW4gMi4xLjMuMTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBwb3NpeFVzZXJBY2NvdW50IG9iamVjdCBjbGFz cyBpcyBhdXhpbGlhcnkgYW5kIG11c3QgYWx3YXlzIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXNzb2NpYXRlZCB3aXRoIGFub3RoZXIgc3Ry dWN0dXJhbCBjbGFzcy4mbmJzcDsgT25lIHN1Y2ggY2xhc3MgaXM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbmV0T3JnUGVyc29uIFtSRkMyNzk4 XS4mbmJzcDsgSWYgdXNlciBhY2NvdW50cyB3ZXJlIGdpdmVuIHRoZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGluZXRPcmdQZXJzb24gY2xhc3Ms IHRoZW4gZGlzcGxheU5hbWUgbWlnaHQgYmUgYW4gYXBwcm9wcmlhdGUgdmFsdWU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBmb3IgdGhlIGRiaXNN YXBHZWNvcyBhdHRyaWJ1dGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkdpdmVuIHRo YXQgdGhlIGdlY29zIGZpZWxkIGNhbiBlbmNvZGUgYW55dGhpbmcgaW4gYW55IGZvcm1hdCwgSSBk aWRuJ3QgdGhpbmsgSSBjb3VsZCByZWFsaXN0aWNhbGx5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5kbyBhbnkgYmV0dGVyIHRoYW4gcHJvdmlkZSBhIHN1Z2dlc3Rpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgcG9zaXhHcm91cCAv IHBvc2l4R3JvdXBBY2NvdW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmZ3Q7IFguNTIxIGdyb3VwT2ZOYW1lcyBzZWVtcyBsaWtlIGEgbW9yZSBhcHByb3By aWF0ZSBiYXNpcyBmb3IgdGhlIGRlZmluaXRpb24gb2YgYSBncm91cC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBCdXQgdGhhdCBkb2Vzbid0IGFsbG93 IGZvciBHSUQgbnVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQSBzdWJj bGFzcyBkb2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhhdmUgcGVvcGxlIHRl bGxpbmcgbWUgZ3JvdXBPZk5hbWVzIGRvZXNuJ3Qgd29yayB3ZWxsIGZvciB0aGVtIGJlY2F1c2Ug aXQgY2FuIGJlIGEgZ3JvdXA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pm9mIGFueXRoaW5nLiZuYnNwOyBFeHRyYSBMREFQIHNlYXJjaGVzIGFyZSByZXF1aXJlZCB0byBm aWd1cmUgb3V0IHdoYXQgdHlwZSBvZiBvYmplY3QgdGhlIG1lbWJlcnM8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmFyZS4mbmJzcDsgVGhhdCBsZWFkcyB0byBhIHJhdGhl ciBpbmVmZmljaWVudCBzeXN0ZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZndDsgbmlzTmV0Z3JvdXAgLyBuZXRncm91cE9iamVjdDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jmd0OyBBbHRob3VnaCBub3QgYSBwZXJmZWN0IG1h dGNoLCBncm91cE9mTmFtZXMgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSBhDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZndDsgYmV0dGVyIGJhc2lzIGZv ciBncm91cGluZyBjb21wdXRlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgbmV0Z3JvdXBzIGFyZSBhIHNwZWNpZmljIGNvbnN0cnVjdCwgdHJ5aW5n IHRvIHNxdWVlemUgdGhlbSBpbnRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyBzb21ldGhpbmcgZWxzZSB0aGF0IGlzIG5vdCBhIHBlcmZlY3QgbWF0 Y2ggd291bGQgYmUgYSBzdWJvcHRpbWFsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyBkZWNpc2lvbi4mbmJzcDsgTERBUCBjYW4gcmVwcmVzZW50IG5l dGdyb3VwIGRhdGEgYmV0dGVyLCBzbyBsZXQncyByZXByZXNlbnQgaXQgYmV0dGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgWWVzLCBpdCBjYW4uLi4gYW5kIGZvciBtb3N0IHB1 cnBvc2VzIGl0IGhhcywgaW4gdGhlIGZvcm0gb2YgZ3JvdXBPZk5hbWVzLiZuYnNwOyBJZiB5b3Ug aGF2ZSB1c2VyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBy ZXByZXNlbnRlZCBpbiB0aGUgZGlyZWN0b3J5LCB0aGUgbmF0dXJhbCB3YXkgdG8gZ3JvdXAgdGhl bSBpcyB3aXRoIGdyb3VwT2ZOYW1lcy4mbmJzcDsgSWYgeW91PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGhhdmUgaG9zdHMgcmVwcmVzZW50ZWQgaW4gdGhlIGRp cmVjdG9yeSwgdGhlIG5hdHVyYWwgd2F5IHRvIGdyb3VwIHRoZW0gaXMgd2l0aCBncm91cE9mTmFt ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBvbmx5 IHRoaW5nIHRoYXQgdGhlcmUgaXNuJ3QgYW4gb2J2aW91cyB3YXkgdG8gZ3JvdXAgaXMgJnF1b3Q7 dXNlciBYIG9uIGhvc3QgWSZxdW90Oy4mbmJzcDsgTm90IHRoYXQgSSd2ZSBzZWVuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGEgbG90IG9mIGNvbmNyZXRlIGlu c3RhbmNlcyBvZiBuZXRncm91cHMsIGJ1dCBJIGRvbid0IHRoaW5rIEkndmUgc2VlbiBvbmUgb2Yg dGhvc2UgeWV0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWUgcHJldmlvdXMgcmVz ZXJ2YXRpb25zIHJlZ2FyZGluZyBncm91cE9mTmFtZXMuJm5ic3A7IEltYWdpbmUgdHJ5aW5nIHRv IGNvbnN0cnVjdCBhIHNlYXJjaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+b3BlcmF0aW9uIHRvIGZpbmQganVzdCBob3N0IG1lbWJlcnMsIG9yIGp1c3QgdXNlciBtZW1i ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3dldmVyLCBJIHNlZW0gdG8gYmUg YSBsb25lIHZvaWNlIGFnYWluIGluIGZhdm91ciBvZiBuZXRncm91cHMuJm5ic3A7IEkndmUgc2Vl biB0aGVtIHVzZWQgYW4gYXdmdWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPmxvdCBhbmQgd2l0aCBhIGJpdCBvZiBpbXByb3ZlbWVudCwgdGhleSdsbCBiZSBhIGxvdCBt b3JlIG1hbmFnZWFibGUuJm5ic3A7IEkga25vdyBob3cgcGFpbmZ1bCBpdCB3aWxsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5iZSBmb3IgZm9sayB0byB0cnkgdG8gbW92 ZSBhd2F5IGZyb20gdGhlbSwgc28gaW4gdGhlIHNwaXJpdCBvZiBtYWtpbmcgdGhpbmdzIGVhc3kg Zm9yIHBlb3BsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZl IGJlZW4gcHJvcG9zaW5nIGluY3JlbWVudGFsIGltcHJvdmVtZW50cyByYXRoZXIgdGhhbiBqdXN0 IGR1bXBpbmcgdGhlbSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PmRvaW5nIHNvbWV0aGluZyBjb21wbGV0ZWx5IGRpZmZlcmVudC4mbmJzcDsgRXZlcnlvbmUgZWxz ZSBjb21tZW50aW5nIG9uIHRoaXMgbGlzdCBzZWVtcyB0byBoYXRlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij50aGVtLiZuYnNwOyBBbm90aGVyIGZ1bmRhbWVudGFsIGRp ZmZlcmVuY2Ugd2UgaGF2ZSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBI YXZpbmcgdHdvIG5hbWVzIHRoYXQgZGlmZmVyIG9ubHkgaW4gY2FzZSBsZWFkIHRvIGRpZmZlcmVu dCBwb3J0IG51bWJlcnMgc2VlbXMgbGlrZSBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IHNwZWN0YWN1bGFybHkgYmFkIGlkZWEuJm5ic3A7IElmIHRoZXJlJ3Mg YW4gb3JnYW5pemF0aW9uIHRoYXQgaGFzIHNvbWVob3cgZm91bmQgdGhlbXNlbHZlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpbiBzdWNoIGEgbWVzcyB0aGVu IEknbSB2ZXJ5IHNvcnJ5IGZvciB0aGVtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZs dDtyYW50Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2FpdC4m bmJzcDsgTklTIHBlcm1pdHRlZCB0aGlzLiZuYnNwOyBJZiBmb2xrIGhhdmUgZG9uZSB3aGF0IE5J UyBhbGxvd2VkIHRoZW0gdG8gZG8sIGFuZCBpdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Zml0dGVkIHRoZWlyIHdvcmtpbmcgcHJhY3RpY2UsIHRoZW4geW91IGNhbid0 IGJsYW1lIHRoZW0gZm9yIHRoYXQuJm5ic3A7IElmIHlvdSBkb24ndCBsaWtlIGl0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hbmQgd2FudCB0byBsYWJlbCBpdCAmcXVv dDthIG1lc3MmcXVvdDssIHRoYXQncyBmaW5lIHlvdSBjYW4gZG8gdGhhdCwgYnV0IEkgZG8gbm90 IHdhbnQgdG8gbGVhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBl b3BsZSBiZWhpbmQuJm5ic3A7IElmIHlvdSB3aXNoIHRvIGNhbGwgaXQgYSBtZXNzLCB0aGVuIFN1 biBNaWNyb3N5c3RlbXMgY3JlYXRlZCB0aGUgbWVzcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPmJ1dCBpdCdzIGluZnJhc3RydWN0dXJlIGFuZCB3ZSdyZSBzdHVjayB3 aXRoIGl0LiZuYnNwOyBJbWFnaW5lIGlmIHRoZSBlbGVjdHJvbmljcyBpbmR1c3RyeSBpbiBBbWVy aWNhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zdGFydGVkIHNlbGxp bmcgZGV2aWNlcyB3aXRoIG9ubHkgPGEgaHJlZj0iaHR0cHM6Ly93d3cuZ29vZ2xlLmNvLnVrL3Vy bD9zYT10JmFtcDtyY3Q9aiZhbXA7cT0mYW1wO2VzcmM9cyZhbXA7c291cmNlPXdlYiZhbXA7Y2Q9 MiZhbXA7Y2FkPXJqYSZhbXA7dWFjdD04JmFtcDt2ZWQ9MGFoVUtFd2lRemZqUnM3ckpBaFVDS2lZ S0hZNmVDWm9RRmdnaU1BRSZhbXA7dXJsPWh0dHAlM0ElMkYlMkZ3d3cuZmFzdGNvZGVzaWduLmNv bSUyRjMwMzI4MDclMkZ3aHktZW5nbGFuZC1oYXMtdGhlLWJlc3Qtd2FsbC1zb2NrZXRzLW9uLWVh cnRoJmFtcDt1c2c9QUZRakNORVA0c3JlbWt2STU2Qm9UYjdEN3JKaEZhUmJnZyI+DQpFbmdsaXNo IHRocmVlLXBpbiBwbHVnczwvYT4sIGNpdGluZyB0aGF0IHRoZSBvcmlnaW5hbCB3YXMgYTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+4oCcYmFkIGRlc2lnbuKAnSBhbmQg YW55b25lIHdobyBoYXMgZm91bmQgdGhlbXNlbHZlcyBpbiBzdWNoIGEgbWVzcyBhcyB0byBoYXZl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5pbmNvbXBhdGlibGUgd2Fs bCBzb2NrZXRzLCB3ZWxsIHZlcnkgc29ycnkgZm9yIHRoZW0gYnV0IHRoYXTigJlzIGp1c3QgdG91 Z2ggbHVjay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJpZ2h0LiZu YnNwOyBZb3XigJlkIGNhdXNlIGFuIG91dGNyeS4mbmJzcDsgU2FtZSB0aGluZyBhcHBsaWVzIGhl cmUuJm5ic3A7IFdpdGggTklTIGEgcGFydGljdWxhcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+d29ya2luZyBwcmFjdGljZSB3YXMgYWJzb2x1dGVseSBmaW5lLiZuYnNw OyBOb3cgaXQgaXNu4oCZdC4mbmJzcDsgQW5kIHBlb3BsZSBhcmUgbGVmdCB0byBmaXggaXQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRoZW1zZWx2ZXMuJm5ic3A7IEkg dGhpbmsgdGhhdOKAmXMgdmVyeSBiYWQuJm5ic3A7IChBbmQgZm9yIHRob3NlIHdobyBzYXkg4oCc TklTIGlzIGRlYWTigJ0sIHRoYXTigJlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5hYnNvbHV0ZWx5IG5vdCB0cnVlLCB0aGVyZSBhcmUgbGFyZ2Ugb3JnYW5pc2F0aW9u cyBzdGlsbCB1c2luZyBOSVMgYW5kIHdobyBoYXZlbuKAmXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPnlldCBtaWdyYXRlZCB0byBMREFQLCBwZXJoYXBzIGJlY2F1c2Ug dGhlIG1pZ3JhdGlvbiB0byBMREFQIGlzIHRvbyBoYXJkIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhlbSBpbiB0aGUgcHJlc2VudCBjbGltYXRlKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvcmFudCZndDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+TWFyay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8QlIgLz48QlIgLz4NCjxIUiBp ZD1IUjEgLz4NCjxCUiAvPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IENPTE9SOiAj ODA4MDgwOyBGT05ULVNJWkU6IDcuNXB0Ij5OT1RJQ0U6IA0KTW9yZ2FuIFN0YW5sZXkgaXMgbm90 IGFjdGluZyBhcyBhIG11bmljaXBhbCBhZHZpc29yIGFuZCB0aGUgb3BpbmlvbnMgb3Igdmlld3Mg DQpjb250YWluZWQgaGVyZWluIGFyZSBub3QgaW50ZW5kZWQgdG8gYmUsIGFuZCBkbyBub3QgY29u c3RpdHV0ZSwgYWR2aWNlIHdpdGhpbiANCnRoZSBtZWFuaW5nIG9mIFNlY3Rpb24gOTc1IG9mIHRo ZSBEb2RkLUZyYW5rIFdhbGwgU3RyZWV0IFJlZm9ybSBhbmQgQ29uc3VtZXIgDQpQcm90ZWN0aW9u IEFjdC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2UgZGVzdHJveSANCmFsbCBlbGVjdHJvbmljIGFuZCBwYXBlciBjb3BpZXM7IGRvIG5vdCBk aXNjbG9zZSwgdXNlIG9yIGFjdCB1cG9uIHRoZSANCmluZm9ybWF0aW9uOyBhbmQgbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkuIE1pc3RyYW5zbWlzc2lvbiBpcyBub3QgaW50ZW5kZWQgDQp0 byB3YWl2ZSBjb25maWRlbnRpYWxpdHkgb3IgcHJpdmlsZWdlLiBNb3JnYW4gU3RhbmxleSByZXNl cnZlcyB0aGUgcmlnaHQsIHRvIHRoZSANCmV4dGVudCBwZXJtaXR0ZWQgdW5kZXIgYXBwbGljYWJs ZSBsYXcsIHRvIG1vbml0b3IgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9ucy4gDQpUaGlzIG1lc3Nh Z2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2luZyBsaW5rOiA8 QSBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBDT0xPUjogIzgwODA4MDsgRk9OVC1TSVpFOiA3 LjVwdCIgaHJlZj0iaHR0cDovL3d3dy5tb3JnYW5zdGFubGV5LmNvbS9kaXNjbGFpbWVycyI+aHR0 cDovL3d3dy5tb3JnYW5zdGFubGV5LmNvbS9kaXNjbGFpbWVyczwvQT4gDQpJZiB5b3UgY2Fubm90 IGFjY2VzcyB0aGVzZSBsaW5rcywgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBtZXNzYWdlIGFu ZCB3ZSB3aWxsIA0Kc2VuZCB0aGUgY29udGVudHMgdG8geW91LiBCeSBtZXNzYWdpbmcgd2l0aCBN b3JnYW4gU3RhbmxleSB5b3UgY29uc2VudCB0byB0aGUgDQpmb3JlZ29pbmcuPC9TUEFOPjxCUiAv Pg0KPFA+PC9QPg0KPFA+PC9QPg0KPFA+PC9QPjwvUD48L0JPRFk+DQo8L0hUTUw+DQoNCg== --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFDOZWEX0209N2msad_-- From nobody Tue Dec 1 03:51:13 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D20E1A90F7 for ; Tue, 1 Dec 2015 03:51:09 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 TW4Cuv8x-q65 for ; Tue, 1 Dec 2015 03:51:07 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 75FF51A90FA for ; Tue, 1 Dec 2015 03:51:07 -0800 (PST) Received: by pacej9 with SMTP id ej9so3392308pac.2 for ; Tue, 01 Dec 2015 03:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=N/pnfQmayNMg6oDY5A4tINVXGQG/cLx+yXE8JLWO0Zo=; b=f/g38x88PrmY9HVUI8tI3SvMJBYSY5ALWmvdwD2TPJKrnwxEWqkIMVHgktcYrw3jGS UXLQ+pz4a8XYhu8JOAJFKNuxqLgkLPlTxYdkclUUu7Jv+zEeKB3qRdchVpl3+bhVO/h+ zYuQDmxFEhnppz/tMhfeJxT9q/7ddBk393AsKbQAyNbNCmJ/C4m3oyTCT2E7Lk0LbalA oRxzbZ8mGImnu9jmbAjXl3WpuoV0uYW0vaTifoYY0KLsUf6AX9aR7CigQwbOn41TSZjZ i/bRFrypGcxWGuTof4gS5eyJJ4gCuShMgw9Cj8OOrORi47d2h1w4h655HV6LsDPapmv9 zxTg== X-Received: by 10.98.89.196 with SMTP id k65mr79349843pfj.12.1448970667042; Tue, 01 Dec 2015 03:51:07 -0800 (PST) Received: from lpm.att.net (99-7-168-171.lightspeed.sntcca.sbcglobal.net. [99.7.168.171]) by smtp.gmail.com with ESMTPSA id lg14sm58292282pab.45.2015.12.01.03.51.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 03:51:05 -0800 (PST) Date: Tue, 1 Dec 2015 03:51:03 -0800 From: Ludovic Poitou To: Jordan Brown , =?utf-8?Q?Bannister=2C_Mark?= Message-ID: In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> X-Mailer: Airmail Beta (338) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="565d89a7_149b8945_e9ad" Archived-At: Cc: "=?utf-8?Q?ldapext=40ietf.org?=" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 11:51:09 -0000 --565d89a7_149b8945_e9ad Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Just a quick note: there is no new LDAPEXT charter, but a Proposal to ref= orm LDAPEXT and a draft charter being discussed. Regards, Ludovic. =46rom:=C2=A0Bannister, Mark Reply:=C2=A0Bannister, Mark Date:=C2=A01 December 2015 at 02:13:39 To:=C2=A0Jordan Brown CC:=C2=A0ldapext=40ietf.org Subject:=C2=A0 Re: =5Bldapext=5D DBIS commentary =20 You might want to point that out in a separate thread, as I say, R=46C230= 7bis is on the new LDAPEXT charter but those running with the new charter may not be reading= these email chains in any depth. =C2=A0 --=C2=A0 Ludovic Poitou http://ludopoitou.com --565d89a7_149b8945_e9ad Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

> On the case-sensitivity front:  we have a pretty fundamental disagreement.  I believe that UNIX names

> must eventually become case-insensitive, that it is only a matter of time until they do.

 

Yes, you're right, this is a pretty fundamental disagreement.  As I don't see anyone else entering the

debate supporting case sensitivity, I fear this will fail on a standards track.  I may just keep the

software available as an alternative, and those who want it can use it, but I think any hopes I had

that DBIS might one day be a standard have just been dashed.  I will continue to answer some

of your points anyway, just for completion.  Those who agree with me are either a) not speaking

up or b) not reading this mailing list.


Do note again that RFC 4876 mapping would let you redirect the clients to use a custom case-sensitive attribute, or attributes from different auxiliary classes.

However, I would point out that you will meet resistance (and/or disgruntled customers after the

fact) if you attempt to change UNIX to be case-insensitive.


For the particular case of user names, I'll note that you're the first person I've talked to who isn't working directly on Solaris LDAP development who has even noticed that LDAP user names are case-insensitive, much less complained.

Btw, what was your plan for case sensitivity in filesystems?


Baby steps :-)

I do think that that's inevitable too, just not as soon as user names.  User names have more cross-platform impact, a more direct association to human names, and get typed by hand more often in many environments.

Any environment that interoperates with Windows will end up with case-insensitive file names, at least in data file systems.  Case-insensitivity is already an option on ZFS, and a "mixed" mode is the default on our storage appliances.

 > UNIX is not the whole world, and the entire rest of the world is clear that MARK, Mark, and mark

> are the same person.

 

With people, perhaps.  With people vs. service accounts perhaps not.  Perhaps I have a user with

a login name of 'sheila' but I also have a service account called 'SHEILA'.  I suppose next you will

be proposing to redefine the English language by saying that case is unimportant when starting

sentences, or when writing proper nouns vs nouns?  Be careful when you say "the entire rest

of the world", be sure you really know the entire rest of the world.  I don't claim to, but I do have

real examples of problems that DBIS is solving today.


I'd suggest that having a login name that duplicates a service account name, except for case, is asking for trouble.  Even in a relative bastion of UNIX like Oracle, we noticed that some of the corporate UIs present user names as all upper case.  Case sensitivity is really quite unnatural for humans.  There's no shortage of commercial systems that change the case of the left side of e-mail addresses, which will really mess you up if you're using the natural username@domain construction and your usernames are case-sensitive.  They're wrong, but they're common.  (And, importantly, almost nobody *notices* that they are wrong.)

I doubt we'd want to go too far off into the weeds on English semantics, but I'd argue that case *is* unimportant when starting sentences.  It helps to mark the beginning of the sentence, but does not otherwise affect the meaning of the word.  When I say "Cars drive on roads" or "The cars are on the road", "Cars" and "cars" mean the same thing.  For proper nouns you have a point - Oracle and an oracle are two different things.  (Though even there, note the proper noun does not take an article.)  However, user names are always proper nouns.  Come to think of it, there's something interesting there.  "Mark" and "Bannister" are both proper nouns, yet "mark" and "bannister" are common nouns.  The only reason that we tolerate using "mark" and "bannister" as user names is that we internally convert them into their capitalized forms; treating them as common nouns as standard English would have us do wouldn't make any sense.

> My key point here is that DBIS should specify what attribute should replace it, what attribute

> clients are expected to use to populate the pw_gecos field in struct passwd.

 

draft-bannister-dbis-passwd provides a suggestion already in 2.1.3.1:

 

   The posixUserAccount object class is auxiliary and must always be

   associated with another structural class.  One such class is

   inetOrgPerson [RFC2798].  If user accounts were given the

   inetOrgPerson class, then displayName might be an appropriate value

   for the dbisMapGecos attribute.

 

Given that the gecos field can encode anything in any format, I didn't think I could realistically

do any better than provide a suggestion.


I think you could safely specify displayName as a MAY attribute, and let people use RFC 4876 mapping if for some reason they want to use something else.

Having two attribute-mapping mechanisms - RFC 4876 mapping and dbisMapGecos - seems bothersome.

> >> posixGroup / posixGroupAccount

> >>

> >> X.521 groupOfNames seems like a more appropriate basis for the definition of a group.

> > But that doesn't allow for GID number.

>

> A subclass does.

 

I have people telling me groupOfNames doesn't work well for them because it can be a group

of anything.  Extra LDAP searches are required to figure out what type of object the members

are.  That leads to a rather inefficient system.


There are two problems there:

1)  A group could contain anything, even when you want it to only contain one type.  Administrator error could lead to incorrect configurations.  In programming-ese, it's not type-safe.  One might hope that you could set up metadata limiting the types of objects that could be added to a group, like you can set up limits on the types of objects that can be put in a container, but I don't know if you can.  One hopes that your administration UIs will help here - if you're defining a group of users, the administration UI presumably knows that and only lets you add users.  At the same time, this flexibility enables nested groups, which can be very useful.
2)  You have to do "extra" searches to get any real information on the member.  Yes, that's a very big problem.  The particular pain point is that getgrnam and getgrgid are defined to return a list of the members of the group, necessitating a search for *each* member.  That gets pretty painful when a group has thousands of members.  I think the truly right answer there is to add new APIs that don't retrieve the members, and even to redefine the existing APIs to not retrieve the members, because there are almost no cases where it actually makes sense to retrieve the list of members of a UNIX group.  The standards provide some help in that there are hints in the UNIX standard that the list of members returned may not be complete.  Also:  Caching is your friend. Note also that the PADL version of nss_ldap has a "nss_getgrent_skipmembers" option that disables returning the list of members.

As long as we're talking about flaws in groupOfNames:  there's also the problem that "member" is a MUST attribute, and that makes empty groups problematic.  Active Directory uses the same basic structure, but uses the "group" class instead of groupOfNames, and for "group" the "member" attribute is a MAY.  RFC2307bis-02 replaces groupOfNames with groupOfMembers, again with "member" as a MAY.

(One might have hoped that you could have an attribute with a empty list of values, but X.501 does not allow that.)

See previous reservations regarding groupOfNames.  Imagine trying to construct a search
operation to find just host members, or just user members.

Do note that the queries that you normally need are "is this host (or user) a member of this group" and "what groups is this user a member of".  It's hard to find cases where you really want to ask "what are the members of this group".  The "is this X a member" and "what groups is this X a member of" queries aren't bad at all with groupOfNames - you have to do a lookup on X to get its DN, but then you just do a natural (and efficient) search.

> Having two names that differ only in case lead to different port numbers seems like a
> spectacularly bad idea.  If there's an organization that has somehow found themselves
> in such a mess then I'm very sorry for them

 

<rant>

Wait.  NIS permitted this.  If folk have done what NIS allowed them to do, and it

fitted their working practice, then you can't blame them for that.  If you don't like it

and want to label it "a mess", that's fine you can do that, but I do not want to leave

people behind.  If you wish to call it a mess, then Sun Microsystems created the mess,

but it's infrastructure and we're stuck with it.  Imagine if the electronics industry in America

started selling devices with only English three-pin plugs, citing that the original was a

“bad design” and anyone who has found themselves in such a mess as to have

incompatible wall sockets, well very sorry for them but that’s just tough luck.

Right.  You’d cause an outcry.  Same thing applies here.  With NIS a particular

working practice was absolutely fine.  Now it isn’t.  And people are left to fix it

themselves.  I think that’s very bad.  (And for those who say “NIS is dead”, that’s

absolutely not true, there are large organisations still using NIS and who haven’t

yet migrated to LDAP, perhaps because the migration to LDAP is too hard for

them in the present climate).

</rant>


Well, kind of.  Yes, you were allowed to do it.  That doesn't necessarily mean that it was ever a good idea.

The structure of extension cords and power strips lets you daisy-chain them together to any length.  That doesn't mean that it's a good idea to do it, or that the fire marshal won't cite you on your next office inspection.

Also, remember that IANA, not NIS, is the authority on the definition of service names, and it defines them as case-insensitive.  There's a very good argument that NIS treating them in a case-sensitive way is a bug.

--------------080908010309080803020209-- From nobody Tue Dec 1 11:19:52 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1C1A1A4B for ; Tue, 1 Dec 2015 11:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 Hq8AT1Psd8IC for ; Tue, 1 Dec 2015 11:19:48 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C681A1A36 for ; Tue, 1 Dec 2015 11:19:45 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id B751C1CFB1 for ; Tue, 1 Dec 2015 19:19:38 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 583DA1D776 for ; Tue, 1 Dec 2015 19:19:36 +0000 (UTC) From: =?UTF-8?Q?Michael_Str=c3=b6der?= To: ldapext@ietf.org X-Enigmail-Draft-Status: N1110 Message-ID: <565DE716.6040701@stroeder.com> Date: Tue, 1 Dec 2015 19:29:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000108090009000208020408" Archived-At: Subject: [ldapext] NIS, RFC2307, RFC2307bis, DBIS, whatever... X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 19:19:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000108090009000208020408 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable HI! This is a purely organizational posting. *** Please do not follow-up on technical details in this thread!!! *** Reviewing the recent RFC2307bis/DBIS e-mail thread I think long texts dis= cussing various topics at once is a real obstacle to get people involved. I also strongly feel that trying to solve all problems at once with one b= ig solution will make it really hard to reach some sort of consensus on part= icular work items. Rather people should be able to pick certain aspects to solv= e part of the problem in their particular deployment. I'd vote for dividing the NIS/LDAP topic into several sub-topics already = raised and start separate mail threads: 1. Case-sensitive vs. case-insensitive names further divided into: - Scope: POSIX vs. rest-of-world - User/login names - Group names - Service names 2. posixAccount vs. posixUserAccount (DBIS) vs. whatever - current common posixAccount usage (structural object class etc.) - gecos field: displayName vs. configurable mapping etc. - IANA considerations 3. Groups - current groupOfNames/posixGroup practice - empty groups (groupOfEntries) - attribute memberUID vs. member vs. whatever - IANA considerations 4. Host/service groups - NIS netgroups vs. groupOfNames vs. other host groups schema - which approaches are really used? 5. Client configuration profiles: - RFC 4876 usage - DBIS Feel free to extend this. Next steps: 1. I'd be very thankful if people could step up picking *one* sub-topic a= nd start a separate discussion thread ideally first summarizing which approa= ches for this particular sub-topic were considered in the past or lying on the= table as I-D. Please stay neutral and do not start such a sub-thread endorsing= a particular solution. 2. The goal for each discussion thread should be to work out a set of rea= l hard requirements or to agree that there is no consensus on the requireme= nts. 3. After that hopefully we can agree which work items are put into the ch= arter. I'm quite aware that some of the topics above overlap. But please let's = try to be disciplined and get more structure into the discussion. Otherwise I d= on't see a chance to get work done. Ciao, Michael. --------------ms000108090009000208020408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwMTE4Mjk0MlowLwYJKoZIhvcNAQkEMSIEIE1Myxq5pyZQfORfacTotJAy1VlVxGBpXuAc EDXbKezJMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBHwvstGEaniBjQtjac 84kIhoiO80m65EzzwUurm4JezIL/H0v4dIb1qPOZ45g1jSdve9nZYcrbMXA0s1RT6gEd/nnm IYjOfaVGyGXRftu1iauIYSB+WDqdOG2VDHTGGBAbZ7guYXqd7TYf8WCxnyb8q5oWWTzrUCjR 5hforiVr4figvPvo6T1yJwxNOX1jX5ybQ1cUP1OEPprLahbJm8gEbUHS+78w61MSkN6mNC7u Scsg052t+wfxh6FIJy4sHq17PebNDi8NlPk4nNDgxxchBSxwl5i/EE/WuCh3QREwGxf9UbF0 f8L08hDdciaSkPe2idsVrYfvQezTdUy1Jj67AAAAAAAA --------------ms000108090009000208020408-- From nobody Tue Dec 1 14:06:46 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED801A9037 for ; Tue, 1 Dec 2015 14:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.509 X-Spam-Level: X-Spam-Status: No, score=0.509 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, MALFORMED_FREEMAIL=1.488, MISSING_HEADERS=1.021, 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 GBkBPFWvdzqi for ; Tue, 1 Dec 2015 14:06:43 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 835E21A8F37 for ; Tue, 1 Dec 2015 14:06:43 -0800 (PST) Received: by lfdl133 with SMTP id l133so27332621lfd.2 for ; Tue, 01 Dec 2015 14:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=oViZNFpXOVpAGxhspN4ErbPpvYjlll4E94FcZpcd2JA=; b=0OjKukKfIFMnfLe9tNdrbFuwF+UjLpwhjMU9bnhiW+BpAi4fcFgNwp5XHEwtP8Qsye NWRgVZeAViZUa0hPs7YI+P2jxn0bUtDYJkdRb6sKwcyeofloV2mtnjqzUkHbxUuN6vec OILgXk7zkR1a6+zo6fhl4A6ieaoonFyATM1p8IWa1rnvor1gaLn63BFAbLsc48XoVMkf GlddWtjYYL1K5vx05Bu6NtHMH9fEn106eqD+PKY+dhP7YLux+dHyaj2T1t2JH+VHvC4z icA5Pt13Zq3WdRlM3/qpxZ6yIDz4rHfevPwSwSRJMS1eG5l3pvC+8fFSArcs+RvFtJ9j HH3w== MIME-Version: 1.0 X-Received: by 10.25.29.205 with SMTP id d196mr27034196lfd.81.1449007601651; Tue, 01 Dec 2015 14:06:41 -0800 (PST) Received: by 10.114.80.193 with HTTP; Tue, 1 Dec 2015 14:06:41 -0800 (PST) In-Reply-To: <565DDE78.5030908@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> Date: Tue, 1 Dec 2015 17:06:41 -0500 Message-ID: From: Charlie Cc: "ldapext@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 22:06:44 -0000 A directory backend that is intended to serve multiple existing operating systems probably shouldn't be telling any of those operating systems whether or not they should be case-sensitive. It's out of scope for the project and causes arguments. That being said, options are great to have. If you can support existing systems while also giving people the ability to do whatever you happen to think is better, you'll automatically win any such arguments. --Charlie From nobody Tue Dec 1 14:49:34 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC9D1AD351 for ; Tue, 1 Dec 2015 14:49:32 -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 irBKv28e3Sxk for ; Tue, 1 Dec 2015 14:49:31 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 766541AD2D5 for ; Tue, 1 Dec 2015 14:49:31 -0800 (PST) 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 tB1MnUCO002252 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 22:49:30 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB1MnTSk023368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 22:49:30 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1MnTpO003619; Tue, 1 Dec 2015 22:49:29 GMT Received: from [10.159.135.55] (/10.159.135.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 14:49:29 -0800 To: Charlie References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> From: Jordan Brown Message-ID: <565E23F2.7080005@oracle.com> Date: Tue, 1 Dec 2015 14:49:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040103040900080104070007" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 22:49:33 -0000 This is a multi-part message in MIME format. --------------040103040900080104070007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [ Splitting off a specific subthread as Michael requested ] [ Resend with correct distribution ] On 12/1/2015 2:06 PM, Charlie wrote: > A directory backend that is intended to serve multiple existing > operating systems probably shouldn't be telling any of those operating > systems whether or not they should be case-sensitive. It's out of > scope for the project and causes arguments. Well, but... if the various OSes are sharing the same naming attribute, it seems like there's an unbreakable chain of connections between them. Either the attribute is case-sensitive, in which case the natively-case-insensitive OS will be confused, or the attribute is case-insensitive, in which case the natively-case-sensitive OS will be confused. The way that I look at it is not that the directory is serving the OSes, but that the directory is defining a world that the OSes are choosing to play in... and when they choose to play in the directory's world, they have to live by its rules. > That being said, options are great to have. If you can support > existing systems while also giving people the ability to do whatever > you happen to think is better, you'll automatically win any such > arguments. It's tempting to suggest that a single entry could have one name attribute that's case-sensitive and another that's case-insensitive (presumably from different auxiliary classes), and technically that'd be possible, but seems like an administrative nightmare... a very high cost to pay for the 0.1% of names where case-sensitivity is important. --------------040103040900080104070007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
[ Splitting off a specific subthread as Michael requested ]
[ Resend with correct distribution ]

On 12/1/2015 2:06 PM, Charlie wrote:
A directory backend that is intended to serve multiple existing
operating systems probably shouldn't be telling any of those operating
systems whether or not they should be case-sensitive. It's out of
scope for the project and causes arguments.

Well, but... if the various OSes are sharing the same naming attribute, it seems like there's an unbreakable chain of connections between them. Either the attribute is case-sensitive, in which case the natively-case-insensitive OS will be confused, or the attribute is case-insensitive, in which case the natively-case-sensitive OS will be confused.

The way that I look at it is not that the directory is serving the OSes, but that the directory is defining a world that the OSes are choosing to play in... and when they choose to play in the directory's world, they have to live by its rules.

That being said, options are great to have. If you can support
existing systems while also giving people the ability to do whatever
you happen to think is better, you'll automatically win any such
arguments.

It's tempting to suggest that a single entry could have one name attribute that's case-sensitive and another that's case-insensitive (presumably from different auxiliary classes), and technically that'd be possible, but seems like an administrative nightmare... a very high cost to pay for the 0.1% of names where case-sensitivity is important.

--------------040103040900080104070007-- From nobody Tue Dec 1 14:50:41 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBCA1AD34E for ; Tue, 1 Dec 2015 14:50:39 -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 rb-9OskI-rNE for ; Tue, 1 Dec 2015 14:50:37 -0800 (PST) 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 B3C081AD2D5 for ; Tue, 1 Dec 2015 14:50:37 -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 tB1MoWvL011975 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Dec 2015 22:50:33 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB1MoWof017203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 22:50:32 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB1MoWh3028107; Tue, 1 Dec 2015 22:50:32 GMT Received: from [10.159.135.55] (/10.159.135.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 14:50:32 -0800 From: Jordan Brown To: Charlie References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> Message-ID: <565E242A.7080703@oracle.com> Date: Tue, 1 Dec 2015 14:50:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010105000900070101040408" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "ldapext@ietf.org" Subject: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 22:50:39 -0000 This is a multi-part message in MIME format. --------------010105000900070101040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [ I just can't win for losing today. Let's try this *one more time* with the right subject. ] [ Splitting off a specific subthread as Michael requested ] [ Resend with correct distribution ] On 12/1/2015 2:06 PM, Charlie wrote: > A directory backend that is intended to serve multiple existing > operating systems probably shouldn't be telling any of those operating > systems whether or not they should be case-sensitive. It's out of > scope for the project and causes arguments. Well, but... if the various OSes are sharing the same naming attribute, it seems like there's an unbreakable chain of connections between them. Either the attribute is case-sensitive, in which case the natively-case-insensitive OS will be confused, or the attribute is case-insensitive, in which case the natively-case-sensitive OS will be confused. The way that I look at it is not that the directory is serving the OSes, but that the directory is defining a world that the OSes are choosing to play in... and when they choose to play in the directory's world, they have to live by its rules. > That being said, options are great to have. If you can support > existing systems while also giving people the ability to do whatever > you happen to think is better, you'll automatically win any such > arguments. It's tempting to suggest that a single entry could have one name attribute that's case-sensitive and another that's case-insensitive (presumably from different auxiliary classes), and technically that'd be possible, but seems like an administrative nightmare... a very high cost to pay for the 0.1% of names where case-sensitivity is important. --------------010105000900070101040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
[ I just can't win for losing today. Let's try this *one more time* with the right subject. ]
[ Splitting off a specific subthread as Michael requested ]
[ Resend with correct distribution ]

On 12/1/2015 2:06 PM, Charlie wrote:
A directory backend that is intended to serve multiple existing
operating systems probably shouldn't be telling any of those operating
systems whether or not they should be case-sensitive. It's out of
scope for the project and causes arguments.

Well, but... if the various OSes are sharing the same naming attribute, it seems like there's an unbreakable chain of connections between them. Either the attribute is case-sensitive, in which case the natively-case-insensitive OS will be confused, or the attribute is case-insensitive, in which case the natively-case-sensitive OS will be confused.

The way that I look at it is not that the directory is serving the OSes, but that the directory is defining a world that the OSes are choosing to play in... and when they choose to play in the directory's world, they have to live by its rules.

That being said, options are great to have. If you can support
existing systems while also giving people the ability to do whatever
you happen to think is better, you'll automatically win any such
arguments.

It's tempting to suggest that a single entry could have one name attribute that's case-sensitive and another that's case-insensitive (presumably from different auxiliary classes), and technically that'd be possible, but seems like an administrative nightmare... a very high cost to pay for the 0.1% of names where case-sensitivity is important.

--------------010105000900070101040408-- From nobody Tue Dec 1 17:06:14 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9851B2FE8 for ; Tue, 1 Dec 2015 17:06:13 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 LoFSdYLyyuWO for ; Tue, 1 Dec 2015 17:06:11 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F25A1B2FDF for ; Tue, 1 Dec 2015 17:06:11 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 06D8CC0CC623; Wed, 2 Dec 2015 01:06:11 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2169ZP032383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Dec 2015 20:06:10 -0500 Message-ID: <1449018369.9040.25.camel@redhat.com> From: Simo Sorce To: "Bannister, Mark" Date: Tue, 01 Dec 2015 20:06:09 -0500 In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 01:06:13 -0000 On Tue, 2015-12-01 at 10:13 +0000, Bannister, Mark wrote: > > > Wait. NIS permitted this. If folk have done what NIS allowed them to > do, and it fitted their working practice, then you can't blame them > for that. If you don't like it and want to label it "a mess", that's > fine you can do that, but I do not want to leave people behind. If > you wish to call it a mess, then Sun Microsystems created the mess, > but it's infrastructure and we're stuck with it. Bugs happen, even in specifications. > Imagine if the electronics industry in America > > started selling devices with only English three-pin > plugs, citing that the original was a “bad design” and anyone who has found themselves in such a mess as to have incompatible wall sockets, well very sorry for them but that’s just tough luck. Funny you bring up this example, because these kind of changes happened quite a few times in history, just on power plugs: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Obsolete_types I've used converters from one type to another for many years in Italy given there we are still supposedly at the end of a multi-decades long transition from this: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Italy_.28Type_L.29 to this: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F17_unearthed_plug or this: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F3_and_CEE_7.2F4_.28German_.22Schuko.22.3B_Type_F.29 by way of this: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F16_.22Europlug.22_.28Type_C.29 > Right. You’d cause an outcry. If enough people thought it was the end of the world, yeah, but it didn't happen, and in most cases it isn't happening in the Unix/Linux world. Most people are just happy to use case-preserving names (ie case-insensitive names were the name is preserved in the form entered in most cases). > Same thing applies here. With NIS a particular working practice was > absolutely fine. Now it isn’t. And people are left to fix it > themselves. I think that’s very bad. (And for those who say “NIS is > dead”, that’s absolutely not true, there are large organisations still > using NIS and who haven’t yet migrated to LDAP, perhaps because the > migration to LDAP is too hard for them in the present climate). There is always some holdout with every technology, that's not a reason to stop the evolution of standards in the direction everyone else is going. > -- Simo Sorce * Red Hat, Inc * New York From nobody Tue Dec 1 17:21:54 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13D1B3037 for ; Tue, 1 Dec 2015 17:21:53 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 6ZBaWrbJmVES for ; Tue, 1 Dec 2015 17:21:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0881B3034 for ; Tue, 1 Dec 2015 17:21:50 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A0A0A8E22B; Wed, 2 Dec 2015 01:21:50 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB21LmEX005831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Dec 2015 20:21:49 -0500 Message-ID: <1449019308.9040.38.camel@redhat.com> From: Simo Sorce To: Jordan Brown Date: Tue, 01 Dec 2015 20:21:48 -0500 In-Reply-To: <565DDE78.5030908@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 01:21:53 -0000 On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote: > > I have people telling me groupOfNames doesn't work well for them > > because it can be a group of anything. > > Extra LDAP searches are required to figure out what type of object > > the members are. That leads to a rather inefficient system. > > > > There are two problems there: > > 1) A group could contain anything, even when you want it to only > contain one type. Administrator error could lead to incorrect > configurations. In programming-ese, it's not type-safe. One might > hope that you could set up metadata limiting the types of objects that > could be added to a group, like you can set up limits on the types of > objects that can be put in a container, but I don't know if you can. > One hopes that your administration UIs will help here - if you're > defining a group of users, the administration UI presumably knows that > and only lets you add users. At the same time, this flexibility > enables nested groups, which can be very useful. This is very true and there are products that can cope, there are also mechanism to more efficiently (at least latency wise) if you use controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00 Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use it in various clients. > 2) You have to do "extra" searches to get any real information on the > member. The control above helps quite a bit in cases where you really need to search. > Yes, that's a very big problem. The particular pain point is that > getgrnam and getgrgid are defined to return a list of the members of > the group, necessitating a search for *each* member. That gets pretty > painful when a group has thousands of members. It is fully broken indeed, based on age old databases that were very small and always local to the system. > I think the truly right answer there is to add new APIs that don't > retrieve the members, and even to redefine the existing APIs to not > retrieve the members, because there are almost no cases where it > actually makes sense to retrieve the list of members of a UNIX group. It would be nice to have a new API, although Posix has some wiggle room which we fully exploit in clients like Windbind and SSSD. Both clients simply do not return all members in the enumeration cases (getgrent) but only in the explicit group retrieve case (getgrnam). This is because Posix allows to omit results in the enumeration case according to some interpretations. > The standards provide some help in that there are hints in the UNIX > standard that the list of members returned may not be complete. Indeed, some admins complain about this so switches are provided in the above mentioned clients to behave "the classic way". And surprisingly very few systems really have a big issue with this. Given that any application that depends on full group enumeration is already fully broken and a performance liability on any enterprise system that has accounts in the thousands. > Also: Caching is your friend. Note also that the PADL version of > nss_ldap has a "nss_getgrent_skipmembers" option that disables > returning the list of members. Any client that doesn't do caching today is really a bad idea. > As long as we're talking about flaws in groupOfNames: there's also > the problem that "member" is a MUST attribute, and that makes empty > groups problematic. This was, in fact, such a big problem that in the FreeIPA product we decided to break with the standard and changed member to be MAY, never looked back on this choice. > Active Directory uses the same basic structure, but uses the "group" > class instead of groupOfNames, and for "group" the "member" attribute > is a MAY. RFC2307bis-02 replaces groupOfNames with groupOfMembers, > again with "member" as a MAY. > > (One might have hoped that you could have an attribute with a empty > list of values, but X.501 does not allow that.) > > > See previous reservations regarding groupOfNames. Imagine trying to > construct a > > search > > operation to find just host members, or just user members. > > Do note that the queries that you normally need are "is this host (or > user) a member of this group" and "what groups is this user a member > of". It's hard to find cases where you really want to ask "what are > the members of this group". The "is this X a member" and "what groups > is this X a member of" queries aren't bad at all with groupOfNames - > you have to do a lookup on X to get its DN, but then you > just do a natural (and efficient) search. Yes this is generally the case for "system level" clients, but indeed many poor administrative clients tend to do the former kind of query, because they think it is a good idea to show all the members, they tend to have some problems when the members reach the multiple tens of thousands :-) Simo. P.S. I switched to use my "corporate" email address so there is no confusion on what hat I may be wearing. -- Simo Sorce * Red Hat, Inc * New York From nobody Tue Dec 1 18:22:08 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478DC1B3133 for ; Tue, 1 Dec 2015 18:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1, 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 sJvzxF6fKFvI for ; Tue, 1 Dec 2015 18:22:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 4DCE21B3132 for ; Tue, 1 Dec 2015 18:22:04 -0800 (PST) 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 tB22M2VF003891 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2015 02:22:03 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 tB22M26r024703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 02:22:02 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB22M197009729; Wed, 2 Dec 2015 02:22:02 GMT Received: from [10.159.135.55] (/10.159.135.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 18:22:01 -0800 To: Simo Sorce References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> From: Jordan Brown Message-ID: <565E55C3.9080404@oracle.com> Date: Tue, 1 Dec 2015 18:21:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449019308.9040.38.camel@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "'ldapext@ietf.org'" Subject: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 02:22:06 -0000 [ Splitting off a subtopic as Michael requested. ] On 12/1/2015 5:21 PM, Simo Sorce wrote: > On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote: >> There are two problems there: >> >> 1) A group could contain anything, even when you want it to only >> contain one type. [...] > This is very true and there are products that can cope, there are also > mechanism to more efficiently (at least latency wise) if you use > controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00 > > Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use > it in various clients. That control is indeed very interesting. I don't immediately see how it helps with the type-safety problem, though. Am I missing something? >> I think the truly right answer there is to add new APIs that don't >> retrieve the members, and even to redefine the existing APIs to not >> retrieve the members, because there are almost no cases where it >> actually makes sense to retrieve the list of members of a UNIX group. > It would be nice to have a new API, although Posix has some wiggle room > which we fully exploit in clients like Windbind and SSSD. > > Both clients simply do not return all members in the enumeration cases > (getgrent) but only in the explicit group retrieve case (getgrnam). > This is because Posix allows to omit results in the enumeration case > according to some interpretations. Yes, and I infer that there's corresponding omissions in other parts of the standard. In the getgrent description, the standard describes omitting this information on the basis of security restrictions. Omitting the data there would not help security at all if you could immediately turn around and request it through getgrname and getgrgid. Meeting the security need would require having the restrictions in both places. > Indeed, some admins complain about this so switches are provided in the above > mentioned clients to behave "the classic way". And surprisingly very few systems > really have a big issue with this. Given that any application that depends on > full group enumeration is already fully broken and a performance liability on > any enterprise system that has accounts in the thousands. Right. The old "walk through all of the groups and then through all of their members" strategy is doubly wrong: the number of groups can be very large, and the number of members of each group can be very large. Heck, even with RFC2307 memberUid groups, simply retrieving the group list can easily involve moving half a megabyte of data. That's a lot of wasted processing when all you really wanted was a gid<->name lookup. >> As long as we're talking about flaws in groupOfNames: there's also >> the problem that "member" is a MUST attribute, and that makes empty >> groups problematic. > This was, in fact, such a big problem that in the FreeIPA product we > decided to break with the standard and changed member to be MAY, never > looked back on this choice. We could address it through introducing a new object class (and here I include just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just creating a wholly new one), or by changing the definition. This is one of those cases where I'd say that breaking formal compatibility might well be appropriate. From nobody Wed Dec 2 00:59:37 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BD11B34C7 for ; Wed, 2 Dec 2015 00:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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] 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 Uzr03cJbD9pq for ; Wed, 2 Dec 2015 00:59:33 -0800 (PST) Received: from hqmtaint03.ms.com (hqmtaint03.ms.com [205.228.53.73]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77AA1B34C0 for ; Wed, 2 Dec 2015 00:59:32 -0800 (PST) Received: from hqmtaint03 (localhost.ms.com [127.0.0.1]) by hqmtaint03.ms.com (output Postfix) with ESMTP id 1064B171329 for ; Wed, 2 Dec 2015 03:59:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449046771; x=1450256371; bh=/pX4UHwTTBkTeLX8ClRoqBY+rn8YCaCnh160Fp55QOs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=iF8/vh5oXkOSBZHDy8SyAMaclDmDCwg5HQC+KVAlIvTyURBsQ0bd8A38cUNttpRdh 8MmFs0EtfZ5TRa+Q1w6wwc4y6xRpM5Q4FMfUN8MjCcoTdnGrJn2EKGS/ZncQW1DRTn +ynSkm/vZ9aMrIfcmyjBqqJGEYrmjUsh14UpeOXY= Received: from rrsmmta03.ms.com (rrsmmta03.ms.com [10.204.137.7]) by hqmtaint03.ms.com (internal Postfix) with ESMTP id E2CE31712EA; Wed, 2 Dec 2015 03:59:31 -0500 (EST) Received: from RRWEX2005N2.msad.ms.com (rrwex2005n2.ms.com [10.196.131.20]) by rrsmmta03.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB28xVqh017294; Wed, 2 Dec 2015 08:59:31 GMT Received: from HZWEX2012N4.msad.ms.com (10.195.143.204) by RRWEX2005N2.msad.ms.com (10.196.131.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 03:59:31 -0500 Received: from OYWEX0207N3.msad.ms.com (10.208.118.31) by HZWEX2012N4.msad.ms.com (10.195.143.204) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 03:59:30 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0207N3.msad.ms.com ([10.208.118.31]) with mapi id 14.03.0235.001; Wed, 2 Dec 2015 08:59:29 +0000 From: "Bannister, Mark" To: "'Jordan Brown'" Thread-Topic: DBIS commentary Thread-Index: AQHRJ6BIKlY+hp6UAEOXycsas61P9Z6uB0MAgAb+lgCAAOCEYIAAjJoAgAD26dA= Date: Wed, 2 Dec 2015 08:59:29 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> In-Reply-To: <565DDE78.5030908@oracle.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30EOZWEX0209N2msad_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/02 02:53:00 #6726429; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 08:59:36 -0000 --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30EOZWEX0209N2msad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9yZGFuIEJyb3duIHdyb3RlOg0KPiBEbyBub3RlIGFnYWluIHRoYXQgUkZDIDQ4NzYgbWFwcGlu ZyB3b3VsZCBsZXQgeW91IHJlZGlyZWN0IHRoZSBjbGllbnRzIHRvIHVzZSBhIGN1c3RvbQ0KPiBj YXNlLXNlbnNpdGl2ZSBhdHRyaWJ1dGUsIG9yIGF0dHJpYnV0ZXMgZnJvbSBkaWZmZXJlbnQgYXV4 aWxpYXJ5IGNsYXNzZXMuDQoNCkkgc2hvdWxkIHJlYWxseSBoYXZlIG1hZGUgaXQgY2xlYXIgdGhh dCBEQklTIHN1cGVyc2VkZXMgUkZDIDQ4NzYsIGFuZCBpbnRyb2R1Y2VzIG1vcmUNCnBvd2VyZnVs IG1hcHBpbmcgY29uc3RydWN0cy4gIFdpdGggREJJUywgeW91IGNhbiBzdXBwb3J0IGFuIFJGQzIz MDcgc2NoZW1hIChjYXNlDQppbnNlbnNpdGl2ZSkgYW5kIHRoZSBEQklTIHNjaGVtYSAoY2FzZSBz ZW5zaXRpdmUpIGZyb20gdGhlIHNhbWUgY2xpZW50IGlmIHlvdSBzbyBjaG9vc2UsDQphbmQgYXQg c2V2ZXJhbCBsZXZlbHMuICBZb3UgY291bGQgaGF2ZSBncm91cHMgb2YgaG9zdHMgd2l0aCBjYXNl IHNlbnNpdGl2ZSBtYXBzIHZzLiBncm91cHMNCm9mIGhvc3Qgd2l0aCBjYXNlIGluc2Vuc2l0aXZl IG1hcHMuICBZb3UgY291bGQgaGF2ZSBhIGhvc3Qgd2hlcmUgc29tZSBtYXBzIGFyZSBjYXNlDQpz ZW5zaXRpdmUgYW5kIHNvbWUgYXJlIG5vdC4gIFlvdSBjYW4gZXZlbiBoYXZlIHBhcnRzIG9mIGEg bWFwIHByb3ZpZGVkIHZpYSBvbmUgc2NoZW1hDQphbmQgcGFydHMgZnJvbSBhbm90aGVyLCBpLmUu IGNhc2Ugc2Vuc2l0aXZpdHkgZm9yIHNvbWUgZW50cmllcyBhbmQgaW5zZW5zaXRpdml0eSBmb3Ig b3RoZXJzDQppZiB0aGF04oCZcyByZWFsbHkgd2hhdCB5b3Ugd2lzaGVkIHRvIGRvLiAgSWYgeW91 IHVzZSBEQklTLCB5b3UgY2VydGFpbmx5IGhhdmUgbm8gbmVlZCB0bw0KdXNlIFJGQyA0ODc2Lg0K DQpDaGFybGllIHdyb3RlOg0KPiBUaGF0IGJlaW5nIHNhaWQsIG9wdGlvbnMgYXJlIGdyZWF0IHRv IGhhdmUuICBJZiB5b3UgY2FuIHN1cHBvcnQgZXhpc3Rpbmcgc3lzdGVtcyB3aGlsZQ0KPiBhbHNv IGdpdmluZyBwZW9wbGUgdGhlIGFiaWxpdHkgdG8gZG8gd2hhdGV2ZXIgeW91IGhhcHBlbiB0byB0 aGluayBpcyBiZXR0ZXIsIHlvdSdsbA0KPiBhdXRvbWF0aWNhbGx5IHdpbiBhbnkgc3VjaCBhcmd1 bWVudHMuDQoNCknigJltIGFsc28gYSBmaXJtIGJlbGlldmVyIGluIHByb3ZpZGluZyBvcHRpb25z IGZvciB3b3JraW5nIGluIGRpZmZlcmVudCB3YXlzLCByYXRoZXIgdGhhbg0KdHJ5aW5nIHRvIGZv cmNlIGV2ZXJ5b25lIHRvIGZpdCBhIHNpbmdsZSBwYXJhZGlnbS4gIFRvIHRoYXQgZW5kLCBwZXJo YXBzIHdlIGRyb3AgdGhlDQpub3Rpb24gb2YgREJJUyDigJxyZXBsYWNpbmfigJ0gUkZDMjMwNy9S RkMyMzA3YmlzIGFuZCBpdCBqdXN0IGJlY29tZXMgYW5vdGhlciB3YXkgdG8NCmRvIHRoaW5ncy4N Cg0KSm9yZGFuIEJyb3duIHdyb3RlOg0KPiBNYXJrIEJhbm5pc3RlciB3cm90ZToNCj4gPiBCdHcs IHdoYXQgd2FzIHlvdXIgcGxhbiBmb3IgY2FzZSBzZW5zaXRpdml0eSBpbiBmaWxlc3lzdGVtcz8N Cj4NCj4gQmFieSBzdGVwcyA6LSkNCj4NCj4gSSBkbyB0aGluayB0aGF0IHRoYXQncyBpbmV2aXRh YmxlIHRvbywganVzdCBub3QgYXMgc29vbiBhcyB1c2VyIG5hbWVzDQoNCldvdy4gIEdvb2QgbHVj ayB3aXRoIHRoYXQuICAoQm9pbGluZyBvY2VhbnMgY29tZXMgdG8gbWluZCkuDQoNCkpvcmRhbiBC cm93biB3cm90ZToNCj4gRm9yIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugb2YgdXNlciBuYW1lcywgSSds bCBub3RlIHRoYXQgeW91J3JlIHRoZSBmaXJzdCBwZXJzb24gSSd2ZSB0YWxrZWQNCj4gdG8gd2hv IGlzbid0IHdvcmtpbmcgZGlyZWN0bHkgb24gU29sYXJpcyBMREFQIGRldmVsb3BtZW50IHdobyBo YXMgZXZlbiBub3RpY2VkIHRoYXQNCj4gTERBUCB1c2VyIG5hbWVzIGFyZSBjYXNlLWluc2Vuc2l0 aXZlLCBtdWNoIGxlc3MgY29tcGxhaW5lZC4NCg0KSXQgd291bGRu4oCZdCBoYXZlIGJvdGhlcmVk IG1lIHVudGlsIEkgY2FtZSBhY3Jvc3MgYSB2ZXJ5IGxhcmdlIG9yZ2FuaXNhdGlvbiBmb3INCndo aWNoIHRoaXMgYnJva2UuICBNb3JlIHN1Z2dlc3Rpb25zIGluIHRoZSBvdGhlciB0aHJlYWQuDQoN Cj4gV2VsbCwga2luZCBvZi4gIFllcywgeW91IHdlcmUgYWxsb3dlZCB0byBkbyBpdC4gIFRoYXQg ZG9lc24ndCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgaXQgd2FzIGV2ZXIgYSBnb29kIGlkZWEuDQo+ DQo+IFRoZSBzdHJ1Y3R1cmUgb2YgZXh0ZW5zaW9uIGNvcmRzIGFuZCBwb3dlciBzdHJpcHMgbGV0 cyB5b3UgZGFpc3ktY2hhaW4gdGhlbSB0b2dldGhlciB0byBhbnkgbGVuZ3RoLiAgVGhhdA0KPiBk b2Vzbid0IG1lYW4gdGhhdCBpdCdzIGEgZ29vZCBpZGVhIHRvIGRvIGl0LCBvciB0aGF0IHRoZSBm aXJlIG1hcnNoYWwgd29uJ3QgY2l0ZSB5b3Ugb24geW91ciBuZXh0IG9mZmljZSBpbnNwZWN0aW9u Lg0KDQpZZXMgYnV0IHRoYXQgaXMgYmFzaWMgZWxlY3RyaWNhbCBzYWZldHkgd2hpY2ggaXMgY29t bXVuaWNhdGVkIGZhciBhbmQgd2lkZSwgd2UgZXZlbiB0ZWFjaCB0aGlzDQp0byBvdXIgY2hpbGRy ZW4uICBQbHVzIHRoZXJlIGFyZSBvZmZpY2UgaW5zcGVjdGlvbnMgdGhhdCBwaWNrIHRoaXMgdXAg aWYgeW914oCZcmUgZG9pbmcgaXQgd3JvbmcsIHNvDQppdOKAmXMgY29ycmVjdGVkLiAgSSBkb27i gJl0IHRoaW5rIGl04oCZcyBhIHJlbGV2YW50IHJlYnVmZi4gIE5JUyBiZWluZyBjYXNlIHNlbnNp dGl2ZSBpcyBtb3JlIGFraW4gdG8NCkNhbGlmb3JuaWFucyBiZWluZyBhbGxvd2VkIHRvIHR1cm4g cmlnaHQgb24gcmVkIChhcyBsb25nIGFzIHRoZXkgcHJvbWlzZSBub3QgdG8ga25vY2sgb3ZlciBh DQpwZWRlc3RyaWFuKS4gIElmIHlvdSBjaGFuZ2VkIHRoZSBydWxlcyBvZiB0aGUgcm9hZCB0b21v cnJvdywgcGVvcGxlIHdpbGwgZm9yZ2V0LiAgQnV0IHRoZQ0KcnVsZXMgb2Ygb3VyIHJvYWQgYWZm ZWN0IGNvbXB1dGVyIHNvZnR3YXJlLCBhbmQgc29mdHdhcmUgbmV2ZXIgZm9yZ2V0cy4gIFdvcnNl LCBzb2Z0d2FyZQ0Kb3V0bGl2ZXMgaGFyZHdhcmUgYnkgYSBsb25nIHdheSwgaXQgZG9lc27igJl0 IGZhbGwgb2ZmIGxpa2UgZGVhZCB3b29kIChvbGQgc2VydmVycyBiZWluZw0KZGVjb21taXNzaW9u ZWQpLiAgU29tZW9uZSBoYXMgdG8gcmV3cml0ZSBpdC4NCg0KTWFyay4NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCk5PVElDRTogTW9yZ2FuIFN0YW5sZXkgaXMgbm90 IGFjdGluZyBhcyBhIG11bmljaXBhbCBhZHZpc29yIGFuZCB0aGUgb3BpbmlvbnMgb3Igdmlld3Mg Y29udGFpbmVkIGhlcmVpbiBhcmUgbm90IGludGVuZGVkIHRvIGJlLCBhbmQgZG8gbm90IGNvbnN0 aXR1dGUsIGFkdmljZSB3aXRoaW4gdGhlIG1lYW5pbmcgb2YgU2VjdGlvbiA5NzUgb2YgdGhlIERv ZGQtRnJhbmsgV2FsbCBTdHJlZXQgUmVmb3JtIGFuZCBDb25zdW1lciBQcm90ZWN0aW9uIEFjdC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ug ZGVzdHJveSBhbGwgZWxlY3Ryb25pYyBhbmQgcGFwZXIgY29waWVzOyBkbyBub3QgZGlzY2xvc2Us IHVzZSBvciBhY3QgdXBvbiB0aGUgaW5mb3JtYXRpb247IGFuZCBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseS4gTWlzdHJhbnNtaXNzaW9uIGlzIG5vdCBpbnRlbmRlZCB0byB3YWl2ZSBjb25m aWRlbnRpYWxpdHkgb3IgcHJpdmlsZWdlLiBNb3JnYW4gU3RhbmxleSByZXNlcnZlcyB0aGUgcmln aHQsIHRvIHRoZSBleHRlbnQgcGVybWl0dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LCB0byBtb25p dG9yIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMuIFRoaXMgbWVzc2FnZSBpcyBzdWJqZWN0IHRv IHRlcm1zIGF2YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5nIGxpbms6IGh0dHA6Ly93d3cubW9yZ2Fu c3RhbmxleS5jb20vZGlzY2xhaW1lcnMgSWYgeW91IGNhbm5vdCBhY2Nlc3MgdGhlc2UgbGlua3Ms IHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgbWVzc2FnZSBhbmQgd2Ugd2lsbCBzZW5kIHRoZSBj b250ZW50cyB0byB5b3UuIEJ5IG1lc3NhZ2luZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlvdSBjb25z ZW50IHRvIHRoZSBmb3JlZ29pbmcuDQo= --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30EOZWEX0209N2msad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8SEVBRD48IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNsYWlt ZXIgVGVtcGxhdGUgRWRpdG9yIG9uIDAzOjU5OjMxIFdvZW5zZGFnLCAyIERlc2VtYmVyIDIwMTUg LS0+DQo8U1RZTEUgdHlwZT10ZXh0L2Nzcz5QLmFlOGI0OWQ5LWQ1ZDgtNGIwOS1hOTc1LTUxMjhm NzRiZGE1ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KTEkuYWU4YjQ5ZDktZDVkOC00YjA5 LWE5NzUtNTEyOGY3NGJkYTVkIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpESVYuYWU4YjQ5 ZDktZDVkOC00YjA5LWE5NzUtNTEyOGY3NGJkYTVkIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9 DQpUQUJMRS5hZThiNDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4Zjc0YmRhNWRUYWJsZSB7DQoJTUFS R0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0K PC9TVFlMRT4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIC8+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIiAvPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwg ZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1z b05vU3BhY2luZywgbGkuTXNvTm9TcGFjaW5nLCBkaXYuTXNvTm9TcGFjaW5nDQoJe21zby1zdHls ZS1wcmlvcml0eToxOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1s ZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uQ29kZQ0KCXttc28tc3R5bGUtbmFtZTpDb2RlOw0KCW1zby1zdHlsZS1wcmlvcml0eToxOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5jYWZhODU4Yy1hNjRhLTQwMTgtYjM1Ny1l YjgwODRiNmIyNjcsIGxpLmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWViODA4NGI2YjI2NywgZGl2 LmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWViODA4NGI2YjI2Nw0KCXttc28tc3R5bGUtbmFtZTpj YWZhODU4Yy1hNjRhLTQwMTgtYjM1Ny1lYjgwODRiNmIyNjc7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L0hFQUQ+DQoNCjxCT0RZIGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8UD4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1m b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+Sm9yZGFuIEJyb3duIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7IERvIG5vdGUgYWdhaW4gdGhhdCBSRkMgNDg3NiBt YXBwaW5nIHdvdWxkIGxldCB5b3UgcmVkaXJlY3QgdGhlIGNsaWVudHMgdG8gdXNlIGEgY3VzdG9t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPiZndDsgY2FzZS1zZW5zaXRpdmUgYXR0cmli dXRlLCBvciBhdHRyaWJ1dGVzIGZyb20gZGlmZmVyZW50IGF1eGlsaWFyeSBjbGFzc2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0Q+SSBzaG91bGQgcmVhbGx5IGhhdmUgbWFkZSBpdCBjbGVhciB0aGF0IERCSVMgc3VwZXJz ZWRlcyBSRkMgNDg3NiwgYW5kIGludHJvZHVjZXMgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RD5wb3dlcmZ1bCBtYXBwaW5nIGNvbnN0cnVjdHMuJm5ic3A7IFdpdGggREJJUywgeW91 IGNhbiBzdXBwb3J0IGFuIFJGQzIzMDcgc2NoZW1hIChjYXNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEPmluc2Vuc2l0aXZlKSBhbmQgdGhlIERCSVMgc2NoZW1hIChjYXNlIHNlbnNpdGl2 ZSkgZnJvbSB0aGUgc2FtZSBjbGllbnQgaWYgeW91IHNvIGNob29zZSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0Q+YW5kIGF0IHNldmVyYWwgbGV2ZWxzLiZuYnNwOyBZb3UgY291bGQgaGF2 ZSBncm91cHMgb2YgaG9zdHMgd2l0aCBjYXNlIHNlbnNpdGl2ZSBtYXBzIHZzLiBncm91cHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+b2YgaG9zdCB3aXRoIGNhc2UgaW5zZW5zaXRpdmUg bWFwcy4mbmJzcDsgWW91IGNvdWxkIGhhdmUgYSBob3N0IHdoZXJlIHNvbWUgbWFwcyBhcmUgY2Fz ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5zZW5zaXRpdmUgYW5kIHNvbWUgYXJlIG5v dC4mbmJzcDsgWW91IGNhbiBldmVuIGhhdmUgcGFydHMgb2YgYSBtYXAgcHJvdmlkZWQgdmlhIG9u ZSBzY2hlbWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+YW5kIHBhcnRzIGZyb20gYW5v dGhlciwgaS5lLiBjYXNlIHNlbnNpdGl2aXR5IGZvciBzb21lIGVudHJpZXMgYW5kIGluc2Vuc2l0 aXZpdHkgZm9yIG90aGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5pZiB0aGF04oCZ cyByZWFsbHkgd2hhdCB5b3Ugd2lzaGVkIHRvIGRvLiZuYnNwOyBJZiB5b3UgdXNlIERCSVMsIHlv dSBjZXJ0YWlubHkgaGF2ZSBubyBuZWVkIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE PnVzZSBSRkMgNDg3Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEPkNoYXJsaWUgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEPiZndDsgVGhhdCBiZWluZyBzYWlkLCBvcHRpb25zIGFyZSBncmVhdCB0byBo YXZlLiZuYnNwOyBJZiB5b3UgY2FuIHN1cHBvcnQgZXhpc3Rpbmcgc3lzdGVtcyB3aGlsZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7IGFsc28gZ2l2aW5nIHBlb3BsZSB0aGUgYWJp bGl0eSB0byBkbyB3aGF0ZXZlciB5b3UgaGFwcGVuIHRvIHRoaW5rIGlzIGJldHRlciwgeW91J2xs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPiZndDsgYXV0b21hdGljYWxseSB3aW4gYW55 IHN1Y2ggYXJndW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+SeKAmW0gYWxzbyBhIGZpcm0gYmVsaWV2ZXIgaW4g cHJvdmlkaW5nIG9wdGlvbnMgZm9yIHdvcmtpbmcgaW4gZGlmZmVyZW50IHdheXMsIHJhdGhlciB0 aGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPnRyeWluZyB0byBmb3JjZSBldmVyeW9u ZSB0byBmaXQgYSBzaW5nbGUgcGFyYWRpZ20uJm5ic3A7IFRvIHRoYXQgZW5kLCBwZXJoYXBzIHdl IGRyb3AgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPm5vdGlvbiBvZiBEQklTIOKA nHJlcGxhY2luZ+KAnSBSRkMyMzA3L1JGQzIzMDdiaXMgYW5kIGl0IGp1c3QgYmVjb21lcyBhbm90 aGVyIHdheSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5kbyB0aGluZ3MuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RD5Kb3JkYW4gQnJvd24gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPiZn dDsgTWFyayBCYW5uaXN0ZXIgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPiZn dDsgJmd0OyBCdHcsIHdoYXQgd2FzIHlvdXIgcGxhbiBmb3IgY2FzZSBzZW5zaXRpdml0eSBpbiBm aWxlc3lzdGVtcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+Jmd0OyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+Jmd0OyBCYWJ5IHN0ZXBzIDotKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RD4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7IEkg ZG8gdGhpbmsgdGhhdCB0aGF0J3MgaW5ldml0YWJsZSB0b28sIGp1c3Qgbm90IGFzIHNvb24gYXMg dXNlciBuYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+V293LiZuYnNwOyBHb29kIGx1Y2sgd2l0aCB0aGF0LiZuYnNw OyAoQm9pbGluZyBvY2VhbnMgY29tZXMgdG8gbWluZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5Kb3JkYW4gQnJvd24g d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPiZndDsgRm9yIHRoZSBwYXJ0aWN1 bGFyIGNhc2Ugb2YgdXNlciBuYW1lcywgSSdsbCBub3RlIHRoYXQgeW91J3JlIHRoZSBmaXJzdCBw ZXJzb24gSSd2ZSB0YWxrZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+Jmd0OyB0byB3 aG8gaXNuJ3Qgd29ya2luZyBkaXJlY3RseSBvbiBTb2xhcmlzIExEQVAgZGV2ZWxvcG1lbnQgd2hv IGhhcyBldmVuIG5vdGljZWQgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7 IExEQVAgdXNlciBuYW1lcyBhcmUgY2FzZS1pbnNlbnNpdGl2ZSwgbXVjaCBsZXNzIGNvbXBsYWlu ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RD5JdCB3b3VsZG7igJl0IGhhdmUgYm90aGVyZWQgbWUgdW50aWwgSSBjYW1l IGFjcm9zcyBhIHZlcnkgbGFyZ2Ugb3JnYW5pc2F0aW9uIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RD53aGljaCB0aGlzIGJyb2tlLiZuYnNwOyBNb3JlIHN1Z2dlc3Rpb25zIGluIHRo ZSBvdGhlciB0aHJlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7IFdlbGwsIGtpbmQgb2YuJm5ic3A7IFllcywg eW91IHdlcmUgYWxsb3dlZCB0byBkbyBpdC4mbmJzcDsgVGhhdCBkb2Vzbid0IG5lY2Vzc2FyaWx5 IG1lYW4gdGhhdCBpdCB3YXMgZXZlciBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0Q+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT1mb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+Jmd0OyBUaGUgc3Ry dWN0dXJlIG9mIGV4dGVuc2lvbiBjb3JkcyBhbmQgcG93ZXIgc3RyaXBzIGxldHMgeW91IGRhaXN5 LWNoYWluIHRoZW0gdG9nZXRoZXIgdG8gYW55IGxlbmd0aC4mbmJzcDsgVGhhdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RD4mZ3Q7IGRvZXNuJ3QgbWVhbiB0aGF0IGl0J3MgYSBnb29kIGlk ZWEgdG8gZG8gaXQsIG9yIHRoYXQgdGhlIGZpcmUgbWFyc2hhbCB3b24ndCBjaXRlIHlvdSBvbiB5 b3VyIG5leHQgb2ZmaWNlIGluc3BlY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5ZZXMgYnV0IHRoYXQgaXMgYmFz aWMgZWxlY3RyaWNhbCBzYWZldHkgd2hpY2ggaXMgY29tbXVuaWNhdGVkIGZhciBhbmQgd2lkZSwg d2UgZXZlbiB0ZWFjaCB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPnRvIG91ciBj aGlsZHJlbi4mbmJzcDsgUGx1cyB0aGVyZSBhcmUgb2ZmaWNlIGluc3BlY3Rpb25zIHRoYXQgcGlj ayB0aGlzIHVwIGlmIHlvdeKAmXJlIGRvaW5nIGl0IHdyb25nLCBzbzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RD5pdOKAmXMgY29ycmVjdGVkLiZuYnNwOyBJIGRvbuKAmXQgdGhpbmsgaXTi gJlzIGEgcmVsZXZhbnQgcmVidWZmLiZuYnNwOyBOSVMgYmVpbmcgY2FzZSBzZW5zaXRpdmUgaXMg bW9yZSBha2luIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPkNhbGlmb3JuaWFucyBi ZWluZyBhbGxvd2VkIHRvIHR1cm4gcmlnaHQgb24gcmVkIChhcyBsb25nIGFzIHRoZXkgcHJvbWlz ZSBub3QgdG8ga25vY2sgb3ZlciBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPnBlZGVz dHJpYW4pLiZuYnNwOyBJZiB5b3UgY2hhbmdlZCB0aGUgcnVsZXMgb2YgdGhlIHJvYWQgdG9tb3Jy b3csIHBlb3BsZSB3aWxsIGZvcmdldC4mbmJzcDsgQnV0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RD5ydWxlcyBvZiBvdXIgcm9hZCBhZmZlY3QgY29tcHV0ZXIgc29mdHdhcmUsIGFu ZCBzb2Z0d2FyZSBuZXZlciBmb3JnZXRzLiZuYnNwOyBXb3JzZSwgc29mdHdhcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT1mb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxRjQ5N0Q+b3V0bGl2ZXMgaGFyZHdhcmUgYnkgYSBsb25nIHdheSwgaXQg ZG9lc27igJl0IGZhbGwgb2ZmIGxpa2UgZGVhZCB3b29kIChvbGQgc2VydmVycyBiZWluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5kZWNvbW1pc3Npb25lZCkuJm5ic3A7IFNvbWVvbmUg aGFzIHRvIHJld3JpdGUgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RD5NYXJrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPWZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 IzFGNDk3RD48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxCUiAvPjxCUiAv Pg0KPEhSIGlkPUhSMSAvPg0KPEJSIC8+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsg Q09MT1I6ICM4MDgwODA7IEZPTlQtU0laRTogNy41cHQiPk5PVElDRTogDQpNb3JnYW4gU3Rhbmxl eSBpcyBub3QgYWN0aW5nIGFzIGEgbXVuaWNpcGFsIGFkdmlzb3IgYW5kIHRoZSBvcGluaW9ucyBv ciB2aWV3cyANCmNvbnRhaW5lZCBoZXJlaW4gYXJlIG5vdCBpbnRlbmRlZCB0byBiZSwgYW5kIGRv IG5vdCBjb25zdGl0dXRlLCBhZHZpY2Ugd2l0aGluIA0KdGhlIG1lYW5pbmcgb2YgU2VjdGlvbiA5 NzUgb2YgdGhlIERvZGQtRnJhbmsgV2FsbCBTdHJlZXQgUmVmb3JtIGFuZCBDb25zdW1lciANClBy b3RlY3Rpb24gQWN0LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsIHBsZWFzZSBkZXN0cm95IA0KYWxsIGVsZWN0cm9uaWMgYW5kIHBhcGVyIGNvcGllczsg ZG8gbm90IGRpc2Nsb3NlLCB1c2Ugb3IgYWN0IHVwb24gdGhlIA0KaW5mb3JtYXRpb247IGFuZCBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4gTWlzdHJhbnNtaXNzaW9uIGlzIG5vdCBpbnRl bmRlZCANCnRvIHdhaXZlIGNvbmZpZGVudGlhbGl0eSBvciBwcml2aWxlZ2UuIE1vcmdhbiBTdGFu bGV5IHJlc2VydmVzIHRoZSByaWdodCwgdG8gdGhlIA0KZXh0ZW50IHBlcm1pdHRlZCB1bmRlciBh cHBsaWNhYmxlIGxhdywgdG8gbW9uaXRvciBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zLiANClRo aXMgbWVzc2FnZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF2YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5n IGxpbms6IDxBIHN0eWxlPSJGT05ULUZBTUlMWTogQXJpYWw7IENPTE9SOiAjODA4MDgwOyBGT05U LVNJWkU6IDcuNXB0IiBocmVmPSJodHRwOi8vd3d3Lm1vcmdhbnN0YW5sZXkuY29tL2Rpc2NsYWlt ZXJzIj5odHRwOi8vd3d3Lm1vcmdhbnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzPC9BPiANCklmIHlv dSBjYW5ub3QgYWNjZXNzIHRoZXNlIGxpbmtzLCBwbGVhc2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IG1l c3NhZ2UgYW5kIHdlIHdpbGwgDQpzZW5kIHRoZSBjb250ZW50cyB0byB5b3UuIEJ5IG1lc3NhZ2lu ZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlvdSBjb25zZW50IHRvIHRoZSANCmZvcmVnb2luZy48L1NQ QU4+PEJSIC8+DQo8UD48L1A+DQo8UD48L1A+DQo8UD48L1A+PC9QPjwvQk9EWT4NCjwvSFRNTD4N Cg0K --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30EOZWEX0209N2msad_-- From nobody Wed Dec 2 01:19:32 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3151A1B95 for ; Wed, 2 Dec 2015 01:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 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_24=0.6, RCVD_IN_DNSWL_HI=-5, 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 gmLEulN8QdUv for ; Wed, 2 Dec 2015 01:19:26 -0800 (PST) Received: from pimtaint03.ms.com (pimtaint03.ms.com [199.89.103.73]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574621A1B49 for ; Wed, 2 Dec 2015 01:19:26 -0800 (PST) Received: from pimtaint03 (localhost.ms.com [127.0.0.1]) by pimtaint03.ms.com (output Postfix) with ESMTP id 68A482B34418 for ; Wed, 2 Dec 2015 04:19:25 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449047965; x=1450257565; bh=xTBjwBeLRcbeWYNW/QyS0QU6BbmhXNIGPxSwuym+f3g=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=RvCT9YWInU4NBYEMbbKPsa8XJaQRUaXo1SigkG7WYUirdCWZXAhSwTEJIEF4w2j0T j4j5FnH7SlXx5/k0ShDF/RVZMN+tid+dtfbeVLVPsgyxmYaNpi07D9tjh/Wkp9lCMf IBtmt4pbBH2NVjhWg4louMN85XkzPDYIcvo8kJHM= Received: from hzsmmta02.ms.com (hzsmmta02.ms.com [10.195.137.198]) by pimtaint03.ms.com (internal Postfix) with ESMTP id 4CE8C2B3437C; Wed, 2 Dec 2015 04:19:25 -0500 (EST) Received: from RRWEX2003N2.msad.ms.com (rrwex2003n2.ms.com [10.196.135.17]) by hzsmmta02.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB29JPBR021238; Wed, 2 Dec 2015 09:19:25 GMT Received: from RRWEX2004N1.msad.ms.com (10.196.141.202) by RRWEX2003N2.msad.ms.com (10.196.135.17) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 04:19:24 -0500 Received: from OYWEX0205N4.msad.ms.com (10.208.118.92) by RRWEX2004N1.msad.ms.com (10.196.141.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 04:19:24 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0205N4.msad.ms.com ([10.208.118.92]) with mapi id 14.03.0235.001; Wed, 2 Dec 2015 09:19:23 +0000 From: "Bannister, Mark" To: "'Jordan Brown'" Thread-Topic: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) Thread-Index: AQHRLIq1SRf4xarC5EmoIP9nuG9pz563ZnJw Date: Wed, 2 Dec 2015 09:19:22 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <565E242A.7080703@oracle.com> In-Reply-To: <565E242A.7080703@oracle.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/02 02:53:00 #6726429; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 09:19:31 -0000 --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jordan Brown wrote: > > On 12/1/2015 2:06 PM, Charlie wrote: > > > > A directory backend that is intended to serve multiple existing > > operating systems probably shouldn't be telling any of those operating > > systems whether or not they should be case-sensitive. It's out of > > scope for the project and causes arguments. > > Well, but... if the various OSes are sharing the same naming attribute, i= t seems like > there's an unbreakable chain of connections between them. Either the att= ribute is > case-sensitive, in which case the natively-case-insensitive OS will be co= nfused, or > the attribute is case-insensitive, in which case the natively-case-sensit= ive OS will be confused. > > The way that I look at it is not that the directory is serving the OSes, = but that the > directory is defining a world that the OSes are choosing to play in... an= d when they > choose to play in the directory's world, they have to live by its rules. Hang on. In the old days, directories were giant yellow books that sat nex= t to the telephone. There were no rules of engagement. You want a telephone number= , you open the book and find it. If the book was upside down, you didn't hav= e to stand on your head to read it, you could turn the book round. I think it would be a mistake to try to make the world revolve around direc= tories. A directory is a server, the clue is in the name, it *serves* clients. Dif= ferent clients have different needs. It would be wrong to mandate big changes on the client-si= de just to interoperate, but this is exactly what you are suggesting. Remember not= everyone cares about having their UNIX and Windows entries co-exist anyway and never= will. > > That being said, options are great to have. If you can support > > existing systems while also giving people the ability to do whatever > > you happen to think is better, you'll automatically win any such > > arguments. > > It's tempting to suggest that a single entry could have one name attribut= e that's > case-sensitive and another that's case-insensitive (presumably from diffe= rent auxiliary > classes), and technically that'd be possible, but seems like an administr= ative nightmare... > a very high cost to pay for the 0.1% of names where case-sensitivity is i= mportant. Ok here's an idea. What if we could define case sensitive entries in a dir= ectory that were only available to case sensitive clients. All the case insensitive en= tries were available to all. Then, in 99% of cases where we don't care and UNIX/Windows share a= ttributes they can interoperate. In the 1% of cases where we need UNIX-specific entr= ies that are case sensitive, we don't want the Windows hosts to see these entries be= cause they would get confused, we can define them too. Then the DUA on a UNIX host can advertise itself as case sensitive when it = binds to the DSA, when it searches for a list of user names (or whatever data, just using use= r names as an example here), it will see: mark jordan michael charlie CHARLIE (where CHARLIE is actually a service account that our customer wants specif= ically in uppercase for whatever reason, we don't care about the reason here remember, we're ju= st providing options). A Windows client does not advertise itself as case sensitive when it binds = to the DSA, and when it performs the same LDAP search it will see: mark jordan michael charlie ... and that's ok, because CHARLIE is a service account intended for runnin= g a UNIX app. You can actually do this today using DBIS, by setting up two configuration = map entries for the passwd database, one using the RFC2307 schema (e.g. ou=3Drfc2307,o= =3Dinfra) and one using the DBIS schema (e.g. ou=3Ddbis,o=3Dinfra). A UNIX client will obtai= n passwd entries from both locations, and the case sensitive users are configured under ou= =3Ddbis,o=3Dinfra. Windows clients only know about ou=3Drfc2307,o=3Dinfra and therefore only g= et to see the case insensitive entries. Mark. (p.s. sorry Charlie couldn't include you directly in this reply as our corp= orate security policy prevents me from mailing a gmail account, but hopefully you'll get i= t via the mailing list). ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers If you cannot= access these links, please notify us by reply message and we will send the= contents to you. By messaging with Morgan Stanley you consent to the foreg= oing. --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jordan Brown wrote:

> > On 12/1/2015 2:06 PM, Charlie wrote:

> >

> > A directory backend that is intended to= serve multiple existing

> > operating systems probably shouldn't be= telling any of those operating

> > systems whether or not they should be c= ase-sensitive.  It's out of

> > scope for the project and causes argume= nts.

>

> Well, but... if the various OSes are sharing= the same naming attribute, it seems like

> there's an unbreakable chain of connections = between them.  Either the attribute is

> case-sensitive, in which case the natively-c= ase-insensitive OS will be confused, or

> the attribute is case-insensitive, in which = case the natively-case-sensitive OS will be confused.

>

> The way that I look at it is not that the di= rectory is serving the OSes, but that the

> directory is defining a world that the OSes = are choosing to play in... and when they

> choose to play in the directory's world, the= y have to live by its rules.

 

Hang on.  In the old days, directories were = giant yellow books that sat next to the

telephone.  There were no rules of engagemen= t.  You want a telephone number,

you open the book and find it.  If the book = was upside down, you didn’t have to stand

on your head to read it, you could turn the book = round.

 

I think it would be a mistake to try to make the = world revolve around directories.

A directory is a server, the clue is in the name,= it *serves* clients.  Different clients have

different needs.  It would be wrong to manda= te big changes on the client-side just

to interoperate, but this is exactly what you are= suggesting.  Remember not everyone

cares about having their UNIX and Windows entries= co-exist anyway and never will.

 

> > That being said, options are great to h= ave.  If you can support

> > existing systems while also giving peop= le the ability to do whatever

> > you happen to think is better, you'll a= utomatically win any such

> > arguments.

>

> It's tempting to suggest that a single entry= could have one name attribute that's

> case-sensitive and another that's case-insen= sitive (presumably from different auxiliary

> classes), and technically that'd be possible= , but seems like an administrative nightmare...

> a very high cost to pay for the 0.1% of name= s where case-sensitivity is important.

 

Ok here’s an idea.  What if we could d= efine case sensitive entries in a directory that

were only available to case sensitive clients.&nb= sp; All the case insensitive entries were available

to all.  Then, in 99% of cases where we don&= #8217;t care and UNIX/Windows share attributes

they can interoperate.  In the 1% of cases w= here we need UNIX-specific entries that

are case sensitive, we don’t want the Windo= ws hosts to see these entries because they

would get confused, we can define them too.<= /o:p>

 

Then the DUA on a UNIX host can advertise itself = as case sensitive when it binds to the DSA,

when it searches for a list of user names (or wha= tever data, just using user names as an example

here), it will see:

 

mark

jordan

michael

charlie

CHARLIE

 

(where CHARLIE is actually a service account that= our customer wants specifically in uppercase

for whatever reason, we don’t care about th= e reason here remember, we’re just providing

options).

 

A Windows client does not advertise itself as cas= e sensitive when it binds to the DSA, and when

it performs the same LDAP search it will see:

 

mark

jordan

michael

charlie

 

... and that’s ok, because CHARLIE is a ser= vice account intended for running a UNIX app.

 

You can actually do this today using DBIS, by set= ting up two configuration map entries

for the passwd database, one using the RFC2307 sc= hema (e.g. ou=3Drfc2307,o=3Dinfra) and one

using the DBIS schema (e.g. ou=3Ddbis,o=3Dinfra).=   A UNIX client will obtain passwd entries

from both locations, and the case sensitive users= are configured under ou=3Ddbis,o=3Dinfra.

Windows clients only know about ou=3Drfc2307,o=3D= infra and therefore only get to see

the case insensitive entries.

 

Mark.

 

(p.s. sorry Charlie couldn’t include you di= rectly in this reply as our corporate security

policy prevents me from mailing a gmail account, = but hopefully you’ll get it via

the mailing list).

 




= NOTICE:=20 Morgan Stanley is not acting as a municipal advisor and the opinions or vie= ws=20 contained herein are not intended to be, and do not constitute, advice with= in=20 the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume= r=20 Protection Act. If you have received this communication in error, please de= stroy=20 all electronic and paper copies; do not disclose, use or act upon the=20 information; and notify the sender immediately. Mistransmission is not inte= nded=20 to waive confidentiality or privilege. Morgan Stanley reserves the right, t= o the=20 extent permitted under applicable law, to monitor electronic communications= .=20 This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers=20 If you cannot access these links, please notify us by reply message and we = will=20 send the contents to you. By messaging with Morgan Stanley you consent to t= he=20 foregoing.

--_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_-- From nobody Wed Dec 2 08:39:28 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EA81B2BDB for ; Wed, 2 Dec 2015 08:39:26 -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 Hle_sOT8-qjv for ; Wed, 2 Dec 2015 08:39:23 -0800 (PST) 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 354271B2BE5 for ; Wed, 2 Dec 2015 08:39:23 -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 tB2GdMoM028050 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2015 16:39:22 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB2GdLX2001676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 16:39:21 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB2GdLXL001318; Wed, 2 Dec 2015 16:39:21 GMT Received: from [10.159.135.55] (/10.159.135.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Dec 2015 08:39:21 -0800 To: "Bannister, Mark" References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> From: Jordan Brown Message-ID: <565F1EB2.9060405@oracle.com> Date: Wed, 2 Dec 2015 08:39:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> Content-Type: multipart/alternative; boundary="------------060600090203030008030702" X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 16:39:26 -0000 This is a multi-part message in MIME format. --------------060600090203030008030702 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/2015 12:59 AM, Bannister, Mark wrote: > > Jordan Brown wrote: > > > Do note again that RFC 4876 mapping would let you redirect the clients to use a custom > > > case-sensitive attribute, or attributes from different auxiliary classes. > > I should really have made it clear that DBIS supersedes RFC 4876, and introduces > more > > powerful mapping constructs. With DBIS, you can support an RFC2307 schema (case > > insensitive) and the DBIS schema (case sensitive) from the same client if you so > choose, > > and at several levels. You could have groups of hosts with case sensitive maps > vs. groups > > of host with case insensitive maps. You could have a host where some maps are case > > sensitive and some are not. You can even have parts of a map provided via one > schema > > and parts from another, i.e. case sensitivity for some entries and insensitivity > for others > > if that’s really what you wished to do. If you use DBIS, you certainly have no > need to > > use RFC 4876. > Ah, indeed. So if there were case-sensitive and case-insensitive attributes available (presumably in different auxiliary classes), you could use those mapping constructs to choose the non-default variation. It doesn't look like you've got 4876 completely covered, though. Attribute mapping is only one of the things it does - it also tells the clients which servers to connect to and what authentication schemes to use. If you're replacing 4876, there should be a plan for replacing that capability. > Jordan Brown wrote: > > > Mark Bannister wrote: > > > > Btw, what was your plan for case sensitivity in filesystems? > > > > > > Baby steps :-) > > > > > > I do think that that's inevitable too, just not as soon as user names > > Wow. Good luck with that. (Boiling oceans comes to mind). > I work in name services, not file systems, so it's not an active project. I just think it'll happen eventually, that interoperability with Windows will force it. --------------060600090203030008030702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/2/2015 12:59 AM, Bannister, Mark wrote:

Jordan Brown wrote:

> Do note again that RFC 4876 mapping would let you redirect the clients to use a custom

> case-sensitive attribute, or attributes from different auxiliary classes.

 

I should really have made it clear that DBIS supersedes RFC 4876, and introduces more

powerful mapping constructs.  With DBIS, you can support an RFC2307 schema (case

insensitive) and the DBIS schema (case sensitive) from the same client if you so choose,

and at several levels.  You could have groups of hosts with case sensitive maps vs. groups

of host with case insensitive maps.  You could have a host where some maps are case

sensitive and some are not.  You can even have parts of a map provided via one schema

and parts from another, i.e. case sensitivity for some entries and insensitivity for others

if that’s really what you wished to do.  If you use DBIS, you certainly have no need to

use RFC 4876.


Ah, indeed.  So if there were case-sensitive and case-insensitive attributes available (presumably in different auxiliary classes), you could use those mapping constructs to choose the non-default variation.

It doesn't look like you've got 4876 completely covered, though.  Attribute mapping is only one of the things it does - it also tells the clients which servers to connect to and what authentication schemes to use.  If you're replacing 4876, there should be a plan for replacing that capability.

Jordan Brown wrote:

> Mark Bannister wrote:

> > Btw, what was your plan for case sensitivity in filesystems?

>

> Baby steps :-)

>

> I do think that that's inevitable too, just not as soon as user names

 

Wow.  Good luck with that.  (Boiling oceans comes to mind).


I work in name services, not file systems, so it's not an active project.  I just think it'll happen eventually, that interoperability with Windows will force it.

--------------060600090203030008030702-- From nobody Wed Dec 2 09:21:10 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1501AC3BE for ; Wed, 2 Dec 2015 09:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 HtmaYgq407m9 for ; Wed, 2 Dec 2015 09:21:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D7F1A90ED for ; Wed, 2 Dec 2015 09:21:03 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 37E97C0CC62B; Wed, 2 Dec 2015 17:21:03 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2HL1NT002308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Dec 2015 12:21:02 -0500 Message-ID: <1449076861.9040.56.camel@redhat.com> From: Simo Sorce To: Jordan Brown Date: Wed, 02 Dec 2015 12:21:01 -0500 In-Reply-To: <565E55C3.9080404@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <565E55C3.9080404@oracle.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 17:21:08 -0000 On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote: > [ Splitting off a subtopic as Michael requested. ] > > On 12/1/2015 5:21 PM, Simo Sorce wrote: > > On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote: > >> There are two problems there: > >> > >> 1) A group could contain anything, even when you want it to only > >> contain one type. [...] > > This is very true and there are products that can cope, there are also > > mechanism to more efficiently (at least latency wise) if you use > > controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00 > > > > Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use > > it in various clients. > > That control is indeed very interesting. I don't immediately see how it helps > with the type-safety problem, though. Am I missing something? The idea is that you can get all data up at once including objectclass and then you can simply drop results that do not have the right objectclass value. It is a little more wasteful than being able to specify a secondary filter (that would probably be a great addition to the draft), for the search done on the attribute of the group entry, but it is still good enough to efficiently get results as well as easily weed off unwanted ones. > >> I think the truly right answer there is to add new APIs that don't > >> retrieve the members, and even to redefine the existing APIs to not > >> retrieve the members, because there are almost no cases where it > >> actually makes sense to retrieve the list of members of a UNIX group. > > It would be nice to have a new API, although Posix has some wiggle room > > which we fully exploit in clients like Windbind and SSSD. > > > > Both clients simply do not return all members in the enumeration cases > > (getgrent) but only in the explicit group retrieve case (getgrnam). > > This is because Posix allows to omit results in the enumeration case > > according to some interpretations. > > Yes, and I infer that there's corresponding omissions in other parts of the > standard. In the getgrent description, the standard describes omitting this > information on the basis of security restrictions. Omitting the data there would > not help security at all if you could immediately turn around and request it > through getgrname and getgrgid. Meeting the security need would require having > the restrictions in both places. True, but are not doing this for security reasons, we are just taking the fact that omissions are permissible as a blanket permission to omit results, and clients should be prepared to deal with that. After all the texts are vague and you could think that the security measure expressed here is about not revealing group names. The fact you can easily scan the whole group ID space is just the annoying consequence of the fact most systems do not have a randomized ID assignment policy and have a pretty limited ID space at just 32bit of size or less. But hey, that's not my fault! :-) > > Indeed, some admins complain about this so switches are provided in the above > > mentioned clients to behave "the classic way". And surprisingly very few systems > > really have a big issue with this. Given that any application that depends on > > full group enumeration is already fully broken and a performance liability on > > any enterprise system that has accounts in the thousands. > > Right. The old "walk through all of the groups and then through all of their > members" strategy is doubly wrong: the number of groups can be very large, and > the number of members of each group can be very large. > > Heck, even with RFC2307 memberUid groups, simply retrieving the group list can > easily involve moving half a megabyte of data. That's a lot of wasted processing > when all you really wanted was a gid<->name lookup. > > >> As long as we're talking about flaws in groupOfNames: there's also > >> the problem that "member" is a MUST attribute, and that makes empty > >> groups problematic. > > This was, in fact, such a big problem that in the FreeIPA product we > > decided to break with the standard and changed member to be MAY, never > > looked back on this choice. > > We could address it through introducing a new object class (and here I include > just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just > creating a wholly new one), or by changing the definition. This is one of those > cases where I'd say that breaking formal compatibility might well be appropriate. Yes, it would be nice to change the class, because it is forward safe to do so, if you created objects when the MUST was in place, nothing breaks if you relax the constraint to MAY, at least from the POV of data consistency in the directory. And I never found any software the specifically rely on the fact you can't delete the last member attribute from a group for something. Actually usually I saw software that had to use workarounds like adding the group dn to itself (and concealing the self-reference in the UI) when an admin wants to remove the last member but not remove the whole group. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Wed Dec 2 10:09:08 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3041ACDD1 for ; Wed, 2 Dec 2015 10:09:06 -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 0p5hB047BXvB for ; Wed, 2 Dec 2015 10:09:04 -0800 (PST) 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 6DE631ACDCE for ; Wed, 2 Dec 2015 10:09:04 -0800 (PST) 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 tB2I933w024124 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2015 18:09:03 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB2I93ob004796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 18:09:03 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB2I92Av005769; Wed, 2 Dec 2015 18:09:02 GMT Received: from [10.159.249.98] (/10.159.249.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Dec 2015 10:09:02 -0800 To: Simo Sorce References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <565E55C3.9080404@oracle.com> <1449076861.9040.56.camel@redhat.com> From: Jordan Brown Message-ID: <565F33B7.4000801@oracle.com> Date: Wed, 2 Dec 2015 10:08:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449076861.9040.56.camel@redhat.com> Content-Type: multipart/alternative; boundary="------------040505020607040501020002" X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 18:09:07 -0000 This is a multi-part message in MIME format. --------------040505020607040501020002 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/2/2015 9:21 AM, Simo Sorce wrote: > On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote: >> [draft-masarati-ldap-deref-00] is indeed very interesting. I don't >> immediately see how it helps with the type-safety problem, though. >> Am I missing something? > The idea is that you can get all data up at once including objectclass > and then you can simply drop results that do not have the right > objectclass value. > It is a little more wasteful than being able to specify a secondary > filter (that would probably be a great addition to the draft), for the > search done on the attribute of the group entry, but it is still good > enough to efficiently get results as well as easily weed off unwanted > ones. OK, sure. (Better still would be to have some way to tell the directory to limit the types allowed.) >> Yes, and I infer that there's corresponding omissions in other parts of the >> standard. In the getgrent description, the standard describes omitting this >> information on the basis of security restrictions. Omitting the data there >> would not help security at all if you could immediately turn around and request >> it through getgrname and getgrgid. Meeting the security need would require >> having the restrictions in both places. > True, but are not doing this for security reasons, we are just taking > the fact that omissions are permissible as a blanket permission to omit > results, and clients should be prepared to deal with that. Right, but the standard describes it in terms of security. > After all the texts are vague and you could think that the security > measure expressed here is about not revealing group names. It explicitly mentions editing the list of members (emphasis added): http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrent.html An implementation that provides extended security controls may impose further implementation-defined restrictions on accessing the group database. In particular, the system may deny the existence of some or all of the group database entries associated with groups other than those groups associated with the caller *and may omit users other than the caller from the list of members of groups in database entries that are returned*. > The fact you can easily scan the whole group ID space is just the > annoying consequence of the fact most systems do not have a randomized > ID assignment policy and have a pretty limited ID space at just 32bit of > size or less. But hey, that's not my fault! :-) That too, but I was thinking about the list-of-members part... if you have a security reason for keeping the list of members hidden, it wouldn't do you any good to hide it from getgrent when the caller could then immediately retrieve it using getgrgid. >> We could address it through introducing a new object class (and here I include >> just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just >> creating a wholly new one), or by changing the definition. This is one of those >> cases where I'd say that breaking formal compatibility might well be appropriate. > Yes, it would be nice to change the class, because it is forward safe to > do so, if you created objects when the MUST was in place, nothing breaks > if you relax the constraint to MAY, at least from the POV of data > consistency in the directory. > > And I never found any software the specifically rely on the fact you > can't delete the last member attribute from a group for something. > Actually usually I saw software that had to use workarounds like adding > the group dn to itself (and concealing the self-reference in the UI) > when an admin wants to remove the last member but not remove the whole > group. The potential problem is a consumer that knows that the "member" attribute MUST be present, and freaks out if it isn't. --------------040505020607040501020002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/2/2015 9:21 AM, Simo Sorce wrote:
On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote:
[draft-masarati-ldap-deref-00] is indeed very interesting. I don't
immediately see how it helps with the type-safety problem, though.
Am I missing something?

The idea is that you can get all data up at once including objectclass
and then you can simply drop results that do not have the right
objectclass value.
It is a little more wasteful than being able to specify a secondary
filter (that would probably be a great addition to the draft), for the
search done on the attribute of the group entry, but it is still good
enough to efficiently get results as well as easily weed off unwanted
ones.

OK, sure.  (Better still would be to have some way to tell the directory to limit the types allowed.)
Yes, and I infer that there's corresponding omissions in other parts of the standard. In the getgrent description, the standard describes omitting this information on the basis of security restrictions. Omitting the data there would not help security at all if you could immediately turn around and request it through getgrname and getgrgid. Meeting the security need would require having the restrictions in both places. 
True, but are not doing this for security reasons, we are just taking
the fact that omissions are permissible as a blanket permission to omit
results, and clients should be prepared to deal with that.

Right, but the standard describes it in terms of security.

After all the texts are vague and you could think that the security
measure expressed here is about not revealing group names.

It explicitly mentions editing the list of members (emphasis added):

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrent.html

An implementation that provides extended security controls may impose further implementation-defined restrictions on accessing the group database. In particular, the system may deny the existence of some or all of the group database entries associated with groups other than those groups associated with the caller and may omit users other than the caller from the list of members of groups in database entries that are returned.


The fact you can easily scan the whole group ID space is just the
annoying consequence of the fact most systems do not have a randomized
ID assignment policy and have a pretty limited ID space at just 32bit of
size or less. But hey, that's not my fault! :-)

That too, but I was thinking about the list-of-members part... if you have a security reason for keeping the list of members hidden, it wouldn't do you any good to hide it from getgrent when the caller could then immediately retrieve it using getgrgid.

We could address it through introducing a new object class (and here I include 
just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just 
creating a wholly new one), or by changing the definition.  This is one of those 
cases where I'd say that breaking formal compatibility might well be appropriate.

Yes, it would be nice to change the class, because it is forward safe to
do so, if you created objects when the MUST was in place, nothing breaks
if you relax the constraint to MAY, at least from the POV of data
consistency in the directory.

And I never found any software the specifically rely on the fact you
can't delete the last member attribute from a group for something.
Actually usually I saw software that had to use workarounds like adding
the group dn to itself (and concealing the self-reference in the UI)
when an admin wants to remove the last member but not remove the whole
group.

The potential problem is a consumer that knows that the "member" attribute MUST be present, and freaks out if it isn't.

--------------040505020607040501020002-- From nobody Wed Dec 2 10:37:22 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BD41ACE25 for ; Wed, 2 Dec 2015 10:37:21 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 kfZqh_-Gj9dm for ; Wed, 2 Dec 2015 10:37:20 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332671ACE23 for ; Wed, 2 Dec 2015 10:37:20 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 9EFC78EFD7; Wed, 2 Dec 2015 18:37:19 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2IbH1F029037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Dec 2015 13:37:18 -0500 Message-ID: <1449081437.9040.63.camel@redhat.com> From: Simo Sorce To: Jordan Brown Date: Wed, 02 Dec 2015 13:37:17 -0500 In-Reply-To: <565F33B7.4000801@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <565E55C3.9080404@oracle.com> <1449076861.9040.56.camel@redhat.com> <565F33B7.4000801@oracle.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 18:37:21 -0000 On Wed, 2015-12-02 at 10:08 -0800, Jordan Brown wrote: > > The potential problem is a consumer that knows that the "member" > attribute MUST be present, and freaks out if it isn't. I have no evidence of such client existing or being relevant. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Thu Dec 3 02:35:16 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C711B3348 for ; Thu, 3 Dec 2015 02:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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] 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 T_muvJNCUzk1 for ; Thu, 3 Dec 2015 02:35:12 -0800 (PST) Received: from pimtaint03.ms.com (pimtaint03.ms.com [199.89.103.73]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1BA1ACDC3 for ; Thu, 3 Dec 2015 02:35:11 -0800 (PST) Received: from pimtaint03 (localhost.ms.com [127.0.0.1]) by pimtaint03.ms.com (output Postfix) with ESMTP id C841A2B344E8 for ; Thu, 3 Dec 2015 05:35:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449138910; x=1450348510; bh=JBa43E50FcePGgivhMmnI5EY2NONsCXsMSBPeQ4urIE=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=PHDYfI1wquVny73uvFHmPPl0khqc+LmJpKgI6+H6+mO2oMnhtiepZ5YGDiR/BsVPG xZp69c6ZxXDWEtJhdM5gbW12itNHRVK20saz+dU4nQdEigcpn2QRQJkWcxtBEwCJIO jtHEhbopu+Q410rVoLDAEYcg0R+69fNaTkVAr1pw= Received: from hzsmmta05.ms.com (hzsmmta05.ms.com [10.203.134.67]) by pimtaint03.ms.com (internal Postfix) with ESMTP id AF88A2B344C5; Thu, 3 Dec 2015 05:35:10 -0500 (EST) Received: from RRWEX2001N2.msad.ms.com (rrwex2001n2.ms.com [10.196.131.19]) by hzsmmta05.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB3AZAGp002641; Thu, 3 Dec 2015 10:35:10 GMT Received: from RRWEX2017N1.msad.ms.com (10.103.12.140) by RRWEX2001N2.msad.ms.com (10.196.131.19) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 05:35:09 -0500 Received: from OYWEX0202N4.msad.ms.com (10.208.118.83) by RRWEX2017N1.msad.ms.com (10.103.12.140) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 05:35:09 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0202N4.msad.ms.com ([169.254.3.127]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 10:35:08 +0000 From: "Bannister, Mark" To: "'Jordan Brown'" Thread-Topic: DBIS commentary Thread-Index: AQHRJ6BIKlY+hp6UAEOXycsas61P9Z6uB0MAgAb+lgCAAOCEYIAAjJoAgAD26dCAAIbUAIABK48Q Date: Thu, 3 Dec 2015 10:35:07 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> In-Reply-To: <565F1EB2.9060405@oracle.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3AOZWEX0209N2msad_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/03 04:23:00 #6678499; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:35:14 -0000 --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3AOZWEX0209N2msad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9yZGFuIEJyb3duIHdyb3RlOg0KDQo+ID4gT24gMTIvMi8yMDE1IDEyOjU5IEFNLCBCYW5uaXN0 ZXIsIE1hcmsgd3JvdGU6DQoNCj4gPiBKb3JkYW4gQnJvd24gd3JvdGU6DQoNCj4gPiA+IERvIG5v dGUgYWdhaW4gdGhhdCBSRkMgNDg3NiBtYXBwaW5nIHdvdWxkIGxldCB5b3UgcmVkaXJlY3QgdGhl IGNsaWVudHMgdG8gdXNlIGEgY3VzdG9tDQoNCj4gPiA+IGNhc2Utc2Vuc2l0aXZlIGF0dHJpYnV0 ZSwgb3IgYXR0cmlidXRlcyBmcm9tIGRpZmZlcmVudCBhdXhpbGlhcnkgY2xhc3Nlcy4NCg0KPiA+ DQoNCj4gPiBJIHNob3VsZCByZWFsbHkgaGF2ZSBtYWRlIGl0IGNsZWFyIHRoYXQgREJJUyBzdXBl cnNlZGVzIFJGQyA0ODc2LCBhbmQgaW50cm9kdWNlcyBtb3JlDQoNCj4gPiBwb3dlcmZ1bCBtYXBw aW5nIGNvbnN0cnVjdHMuICBXaXRoIERCSVMsIHlvdSBjYW4gc3VwcG9ydCBhbiBSRkMyMzA3IHNj aGVtYSAoY2FzZQ0KDQo+ID4gaW5zZW5zaXRpdmUpIGFuZCB0aGUgREJJUyBzY2hlbWEgKGNhc2Ug c2Vuc2l0aXZlKSBmcm9tIHRoZSBzYW1lIGNsaWVudCBpZiB5b3Ugc28gY2hvb3NlLA0KDQo+ID4g YW5kIGF0IHNldmVyYWwgbGV2ZWxzLiAgWW91IGNvdWxkIGhhdmUgZ3JvdXBzIG9mIGhvc3RzIHdp dGggY2FzZSBzZW5zaXRpdmUgbWFwcyB2cy4gZ3JvdXBzDQoNCj4gPiBvZiBob3N0IHdpdGggY2Fz ZSBpbnNlbnNpdGl2ZSBtYXBzLiAgWW91IGNvdWxkIGhhdmUgYSBob3N0IHdoZXJlIHNvbWUgbWFw cyBhcmUgY2FzZQ0KDQo+ID4gc2Vuc2l0aXZlIGFuZCBzb21lIGFyZSBub3QuICBZb3UgY2FuIGV2 ZW4gaGF2ZSBwYXJ0cyBvZiBhIG1hcCBwcm92aWRlZCB2aWEgb25lIHNjaGVtYQ0KDQo+ID4gYW5k IHBhcnRzIGZyb20gYW5vdGhlciwgaS5lLiBjYXNlIHNlbnNpdGl2aXR5IGZvciBzb21lIGVudHJp ZXMgYW5kIGluc2Vuc2l0aXZpdHkgZm9yIG90aGVycw0KDQo+ID4gaWYgdGhhdOKAmXMgcmVhbGx5 IHdoYXQgeW91IHdpc2hlZCB0byBkby4gIElmIHlvdSB1c2UgREJJUywgeW91IGNlcnRhaW5seSBo YXZlIG5vIG5lZWQgdG8NCg0KPiA+IHVzZSBSRkMgNDg3Ni4NCg0KPiA+DQoNCj4gQWgsIGluZGVl ZC4gIFNvIGlmIHRoZXJlIHdlcmUgY2FzZS1zZW5zaXRpdmUgYW5kIGNhc2UtaW5zZW5zaXRpdmUg YXR0cmlidXRlcyBhdmFpbGFibGUgKHByZXN1bWFibHkgaW4gZGlmZmVyZW50IGF1eGlsaWFyeSBj bGFzc2VzKSwgeW91IGNvdWxkIHVzZSA+IHRob3NlIG1hcHBpbmcgY29uc3RydWN0cyB0byBjaG9v c2UgdGhlIG5vbi1kZWZhdWx0IHZhcmlhdGlvbi4NCg0KPg0KDQo+IEl0IGRvZXNuJ3QgbG9vayBs aWtlIHlvdSd2ZSBnb3QgNDg3NiBjb21wbGV0ZWx5IGNvdmVyZWQsIHRob3VnaC4gIEF0dHJpYnV0 ZSBtYXBwaW5nIGlzIG9ubHkgb25lIG9mIHRoZSB0aGluZ3MgaXQgZG9lcyAtIGl0IGFsc28gdGVs bHMgdGhlIGNsaWVudHMgd2hpY2ggPiBzZXJ2ZXJzIHRvIGNvbm5lY3QgdG8gYW5kIHdoYXQgYXV0 aGVudGljYXRpb24gc2NoZW1lcyB0byB1c2UuICBJZiB5b3UncmUgcmVwbGFjaW5nIDQ4NzYsIHRo ZXJlIHNob3VsZCBiZSBhIHBsYW4gZm9yIHJlcGxhY2luZyB0aGF0IGNhcGFiaWxpdHkuDQoNCg0K DQpZZXMgSeKAmXZlIG5vdCBxdWl0ZSB1bmRlcnN0b29kIHRoYXQuICBZb3UgbmVlZCB0byBjb25m aWd1cmUgdGhlIGNsaWVudCB0byB0YWxrIHRvIGFuIExEQVAgc2VydmVyLCBpbiBvcmRlcg0KDQp0 byBvYnRhaW4gYSBwcm9maWxlIHRoYXQgdGVsbHMgaXQgdG8gdGFsayB0byBhIGRpZmZlcmVudCBM REFQIHNlcnZlciBpbnN0ZWFkLiAgV2h5IHdvdWxkIHlvdSBub3QganVzdA0KDQpjb25maWd1cmUg dGhlIGNsaWVudCB0byB0YWxrIHRvIHRoZSBjb3JyZWN0IExEQVAgc2VydmVyIGluIHRoZSBmaXJz dCBwbGFjZT8gIFBsZWFzZSBleHBsYWluIHRoZSB1c2UtY2FzZS4NCg0KDQoNCj4gPiBKb3JkYW4g QnJvd24gd3JvdGU6DQoNCj4gPiA+IE1hcmsgQmFubmlzdGVyIHdyb3RlOg0KDQo+ID4gPiA+IEJ0 dywgd2hhdCB3YXMgeW91ciBwbGFuIGZvciBjYXNlIHNlbnNpdGl2aXR5IGluIGZpbGVzeXN0ZW1z Pw0KDQo+ID4gPg0KDQo+ID4gPiBCYWJ5IHN0ZXBzIDotKQ0KDQo+ID4gPg0KDQo+ID4gPiBJIGRv IHRoaW5rIHRoYXQgdGhhdCdzIGluZXZpdGFibGUgdG9vLCBqdXN0IG5vdCBhcyBzb29uIGFzIHVz ZXIgbmFtZXMNCg0KPiA+DQoNCj4gPiBXb3cuICBHb29kIGx1Y2sgd2l0aCB0aGF0LiAgKEJvaWxp bmcgb2NlYW5zIGNvbWVzIHRvIG1pbmQpLg0KDQo+DQoNCj4gSSB3b3JrIGluIG5hbWUgc2Vydmlj ZXMsIG5vdCBmaWxlIHN5c3RlbXMsIHNvIGl0J3Mgbm90IGFuIGFjdGl2ZSBwcm9qZWN0LiAgSSBq dXN0IHRoaW5rIGl0J2xsIGhhcHBlbiBldmVudHVhbGx5LCB0aGF0DQoNCj4gaW50ZXJvcGVyYWJp bGl0eSB3aXRoIFdpbmRvd3Mgd2lsbCBmb3JjZSBpdC4NCg0KDQoNCkkgZm91bmQgYW4gaW50ZXJl c3RpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHZlcnkgc3ViamVjdDoNCg0KaHR0cHM6Ly9uZXdzLnlj b21iaW5hdG9yLmNvbS9pdGVtP2lkPTg4NzY3MjINCg0KDQoNCk1hcmsuDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk5PVElDRTogTW9yZ2FuIFN0YW5sZXkgaXMg bm90IGFjdGluZyBhcyBhIG11bmljaXBhbCBhZHZpc29yIGFuZCB0aGUgb3BpbmlvbnMgb3Igdmll d3MgY29udGFpbmVkIGhlcmVpbiBhcmUgbm90IGludGVuZGVkIHRvIGJlLCBhbmQgZG8gbm90IGNv bnN0aXR1dGUsIGFkdmljZSB3aXRoaW4gdGhlIG1lYW5pbmcgb2YgU2VjdGlvbiA5NzUgb2YgdGhl IERvZGQtRnJhbmsgV2FsbCBTdHJlZXQgUmVmb3JtIGFuZCBDb25zdW1lciBQcm90ZWN0aW9uIEFj dC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2UgZGVzdHJveSBhbGwgZWxlY3Ryb25pYyBhbmQgcGFwZXIgY29waWVzOyBkbyBub3QgZGlzY2xv c2UsIHVzZSBvciBhY3QgdXBvbiB0aGUgaW5mb3JtYXRpb247IGFuZCBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseS4gTWlzdHJhbnNtaXNzaW9uIGlzIG5vdCBpbnRlbmRlZCB0byB3YWl2ZSBj b25maWRlbnRpYWxpdHkgb3IgcHJpdmlsZWdlLiBNb3JnYW4gU3RhbmxleSByZXNlcnZlcyB0aGUg cmlnaHQsIHRvIHRoZSBleHRlbnQgcGVybWl0dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LCB0byBt b25pdG9yIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMuIFRoaXMgbWVzc2FnZSBpcyBzdWJqZWN0 IHRvIHRlcm1zIGF2YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5nIGxpbms6IGh0dHA6Ly93d3cubW9y Z2Fuc3RhbmxleS5jb20vZGlzY2xhaW1lcnMgSWYgeW91IGNhbm5vdCBhY2Nlc3MgdGhlc2UgbGlu a3MsIHBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgbWVzc2FnZSBhbmQgd2Ugd2lsbCBzZW5kIHRo ZSBjb250ZW50cyB0byB5b3UuIEJ5IG1lc3NhZ2luZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlvdSBj b25zZW50IHRvIHRoZSBmb3JlZ29pbmcuDQo= --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3AOZWEX0209N2msad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8SEVBRD48IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNsYWlt ZXIgVGVtcGxhdGUgRWRpdG9yIG9uIDA1OjM1OjEwIERvbmRlcmRhZywgMyBEZXNlbWJlciAyMDE1 IC0tPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+UC4zYzM2NDkwMC0zMWUxLTRlM2UtYmI0NS0yOWY1 OGQ5YTFlN2Qgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLjNjMzY0OTAwLTMxZTEtNGUz ZS1iYjQ1LTI5ZjU4ZDlhMWU3ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLjNjMzY0 OTAwLTMxZTEtNGUzZS1iYjQ1LTI5ZjU4ZDlhMWU3ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0K fQ0KVEFCTEUuM2MzNjQ5MDAtMzFlMS00ZTNlLWJiNDUtMjlmNThkOWExZTdkVGFibGUgew0KCU1B UkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0N CjwvU1RZTEU+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04IiAvPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSIgLz4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5N c29Ob1NwYWNpbmcsIGxpLk1zb05vU3BhY2luZywgZGl2Lk1zb05vU3BhY2luZw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpz cGFuLkNvZGUNCgl7bXNvLXN0eWxlLW5hbWU6Q29kZTsNCgltc28tc3R5bGUtcHJpb3JpdHk6MTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuYWU4YjQ5ZDktZDVkOC00YjA5LWE5NzUt NTEyOGY3NGJkYTVkLCBsaS5hZThiNDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4Zjc0YmRhNWQsIGRp di5hZThiNDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4Zjc0YmRhNWQNCgl7bXNvLXN0eWxlLW5hbWU6 YWU4YjQ5ZDktZDVkOC00YjA5LWE5NzUtNTEyOGY3NGJkYTVkOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFj azt9DQpwLmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWViODA4NGI2YjI2NywgbGkuY2FmYTg1OGMt YTY0YS00MDE4LWIzNTctZWI4MDg0YjZiMjY3LCBkaXYuY2FmYTg1OGMtYTY0YS00MDE4LWIzNTct ZWI4MDg0YjZiMjY3DQoJe21zby1zdHlsZS1uYW1lOmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWVi ODA4NGI2YjI2NzsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI1 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvSEVBRD4NCg0KPEJP RFkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPFA+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Sm9yZGFuIEJyb3du IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 IE9uIDEyLzIvMjAxNSAxMjo1OSBBTSwgQmFubmlzdGVyLCBNYXJrIHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEpvcmRhbiBCcm93biB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7 IERvIG5vdGUgYWdhaW4gdGhhdCBSRkMgNDg3NiBtYXBwaW5nIHdvdWxkIGxldCB5b3UgcmVkaXJl Y3QgdGhlIGNsaWVudHMgdG8gdXNlIGEgY3VzdG9tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBjYXNlLXNlbnNpdGl2ZSBhdHRyaWJ1dGUsIG9y IGF0dHJpYnV0ZXMgZnJvbSBkaWZmZXJlbnQgYXV4aWxpYXJ5IGNsYXNzZXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSSBzaG91bGQgcmVhbGx5IGhh dmUgbWFkZSBpdCBjbGVhciB0aGF0IERCSVMgc3VwZXJzZWRlcyBSRkMgNDg3NiwgYW5kIGludHJv ZHVjZXMgbW9yZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7IHBvd2VyZnVsIG1hcHBpbmcgY29uc3RydWN0cy4mbmJzcDsgV2l0aCBEQklTLCB5b3UgY2Fu IHN1cHBvcnQgYW4gUkZDMjMwNyBzY2hlbWEgKGNhc2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBpbnNlbnNpdGl2ZSkgYW5kIHRoZSBEQklTIHNjaGVt YSAoY2FzZSBzZW5zaXRpdmUpIGZyb20gdGhlIHNhbWUgY2xpZW50IGlmIHlvdSBzbyBjaG9vc2Us PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYW5kIGF0 IHNldmVyYWwgbGV2ZWxzLiZuYnNwOyBZb3UgY291bGQgaGF2ZSBncm91cHMgb2YgaG9zdHMgd2l0 aCBjYXNlIHNlbnNpdGl2ZSBtYXBzIHZzLiBncm91cHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBvZiBob3N0IHdpdGggY2FzZSBpbnNlbnNpdGl2ZSBt YXBzLiZuYnNwOyBZb3UgY291bGQgaGF2ZSBhIGhvc3Qgd2hlcmUgc29tZSBtYXBzIGFyZSBjYXNl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgc2Vuc2l0 aXZlIGFuZCBzb21lIGFyZSBub3QuJm5ic3A7IFlvdSBjYW4gZXZlbiBoYXZlIHBhcnRzIG9mIGEg bWFwIHByb3ZpZGVkIHZpYSBvbmUgc2NoZW1hPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgYW5kIHBhcnRzIGZyb20gYW5vdGhlciwgaS5lLiBjYXNlIHNl bnNpdGl2aXR5IGZvciBzb21lIGVudHJpZXMgYW5kIGluc2Vuc2l0aXZpdHkgZm9yIG90aGVyczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGlmIHRoYXTi gJlzIHJlYWxseSB3aGF0IHlvdSB3aXNoZWQgdG8gZG8uJm5ic3A7IElmIHlvdSB1c2UgREJJUywg eW91IGNlcnRhaW5seSBoYXZlIG5vIG5lZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyB1c2UgUkZDIDQ4NzYuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IEFoLCBpbmRlZWQuJm5ic3A7IFNvIGlmIHRoZXJlIHdlcmUgY2Fz ZS1zZW5zaXRpdmUgYW5kIGNhc2UtaW5zZW5zaXRpdmUgYXR0cmlidXRlcyBhdmFpbGFibGUgKHBy ZXN1bWFibHkgaW4gZGlmZmVyZW50IGF1eGlsaWFyeSBjbGFzc2VzKSwgeW91IGNvdWxkIHVzZSAm Z3Q7IHRob3NlIG1hcHBpbmcgY29uc3RydWN0cyB0byBjaG9vc2UgdGhlIG5vbi1kZWZhdWx0IHZh cmlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEl0IGRvZXNuJ3QgbG9v ayBsaWtlIHlvdSd2ZSBnb3QgNDg3NiBjb21wbGV0ZWx5IGNvdmVyZWQsIHRob3VnaC4mbmJzcDsg QXR0cmlidXRlIG1hcHBpbmcgaXMgb25seSBvbmUgb2YgdGhlIHRoaW5ncyBpdCBkb2VzIC0gaXQg YWxzbyB0ZWxscyB0aGUgY2xpZW50cyB3aGljaCAmZ3Q7IHNlcnZlcnMgdG8gY29ubmVjdCB0byBh bmQgd2hhdCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHRvIHVzZS4mbmJzcDsgSWYgeW91J3JlIHJl cGxhY2luZw0KIDQ4NzYsIHRoZXJlIHNob3VsZCBiZSBhIHBsYW4gZm9yIHJlcGxhY2luZyB0aGF0 IGNhcGFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlllcyBJ4oCZdmUgbm90 IHF1aXRlIHVuZGVyc3Rvb2QgdGhhdC4mbmJzcDsgWW91IG5lZWQgdG8gY29uZmlndXJlIHRoZSBj bGllbnQgdG8gdGFsayB0byBhbiBMREFQIHNlcnZlciwgaW4gb3JkZXI8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRvIG9idGFpbiBhIHByb2ZpbGUgdGhhdCB0ZWxscyBp dCB0byB0YWxrIHRvIGEgZGlmZmVyZW50IExEQVAgc2VydmVyIGluc3RlYWQuJm5ic3A7IFdoeSB3 b3VsZCB5b3Ugbm90IGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PmNvbmZpZ3VyZSB0aGUgY2xpZW50IHRvIHRhbGsgdG8gdGhlIGNvcnJlY3QgTERBUCBzZXJ2ZXIg aW4gdGhlIGZpcnN0IHBsYWNlPyZuYnNwOyBQbGVhc2UgZXhwbGFpbiB0aGUgdXNlLWNhc2UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBKb3JkYW4gQnJvd24gd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyBN YXJrIEJhbm5pc3RlciB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyAmZ3Q7ICZndDsgQnR3LCB3aGF0IHdhcyB5b3VyIHBsYW4gZm9yIGNhc2Ug c2Vuc2l0aXZpdHkgaW4gZmlsZXN5c3RlbXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEJhYnkgc3RlcHMgOi0pPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEkgZG8gdGhpbmsgdGhhdCB0aGF0 J3MgaW5ldml0YWJsZSB0b28sIGp1c3Qgbm90IGFzIHNvb24gYXMgdXNlciBuYW1lczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFdvdy4mbmJzcDsgR29v ZCBsdWNrIHdpdGggdGhhdC4mbmJzcDsgKEJvaWxpbmcgb2NlYW5zIGNvbWVzIHRvIG1pbmQpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSSB3b3JrIGluIG5hbWUgc2VydmljZXMs IG5vdCBmaWxlIHN5c3RlbXMsIHNvIGl0J3Mgbm90IGFuIGFjdGl2ZSBwcm9qZWN0LiZuYnNwOyBJ IGp1c3QgdGhpbmsgaXQnbGwgaGFwcGVuIGV2ZW50dWFsbHksIHRoYXQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIFdpbmRv d3Mgd2lsbCBmb3JjZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBmb3VuZCBh biBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIG9uIHRoaXMgdmVyeSBzdWJqZWN0OjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGEgaHJlZj0iaHR0cHM6Ly9uZXdzLnljb21i aW5hdG9yLmNvbS9pdGVtP2lkPTg4NzY3MjIiPmh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20v aXRlbT9pZD04ODc2NzIyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYXJrLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxCUiAvPjxCUiAvPg0KPEhSIGlkPUhSMSAvPg0KPEJSIC8+PFNQQU4gc3R5 bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsgQ09MT1I6ICM4MDgwODA7IEZPTlQtU0laRTogNy41cHQi Pk5PVElDRTogDQpNb3JnYW4gU3RhbmxleSBpcyBub3QgYWN0aW5nIGFzIGEgbXVuaWNpcGFsIGFk dmlzb3IgYW5kIHRoZSBvcGluaW9ucyBvciB2aWV3cyANCmNvbnRhaW5lZCBoZXJlaW4gYXJlIG5v dCBpbnRlbmRlZCB0byBiZSwgYW5kIGRvIG5vdCBjb25zdGl0dXRlLCBhZHZpY2Ugd2l0aGluIA0K dGhlIG1lYW5pbmcgb2YgU2VjdGlvbiA5NzUgb2YgdGhlIERvZGQtRnJhbmsgV2FsbCBTdHJlZXQg UmVmb3JtIGFuZCBDb25zdW1lciANClByb3RlY3Rpb24gQWN0LiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBkZXN0cm95IA0KYWxsIGVsZWN0 cm9uaWMgYW5kIHBhcGVyIGNvcGllczsgZG8gbm90IGRpc2Nsb3NlLCB1c2Ugb3IgYWN0IHVwb24g dGhlIA0KaW5mb3JtYXRpb247IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4gTWlz dHJhbnNtaXNzaW9uIGlzIG5vdCBpbnRlbmRlZCANCnRvIHdhaXZlIGNvbmZpZGVudGlhbGl0eSBv ciBwcml2aWxlZ2UuIE1vcmdhbiBTdGFubGV5IHJlc2VydmVzIHRoZSByaWdodCwgdG8gdGhlIA0K ZXh0ZW50IHBlcm1pdHRlZCB1bmRlciBhcHBsaWNhYmxlIGxhdywgdG8gbW9uaXRvciBlbGVjdHJv bmljIGNvbW11bmljYXRpb25zLiANClRoaXMgbWVzc2FnZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF2 YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5nIGxpbms6IDxBIHN0eWxlPSJGT05ULUZBTUlMWTogQXJp YWw7IENPTE9SOiAjODA4MDgwOyBGT05ULVNJWkU6IDcuNXB0IiBocmVmPSJodHRwOi8vd3d3Lm1v cmdhbnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzIj5odHRwOi8vd3d3Lm1vcmdhbnN0YW5sZXkuY29t L2Rpc2NsYWltZXJzPC9BPiANCklmIHlvdSBjYW5ub3QgYWNjZXNzIHRoZXNlIGxpbmtzLCBwbGVh c2Ugbm90aWZ5IHVzIGJ5IHJlcGx5IG1lc3NhZ2UgYW5kIHdlIHdpbGwgDQpzZW5kIHRoZSBjb250 ZW50cyB0byB5b3UuIEJ5IG1lc3NhZ2luZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlvdSBjb25zZW50 IHRvIHRoZSANCmZvcmVnb2luZy48L1NQQU4+PEJSIC8+DQo8UD48L1A+DQo8UD48L1A+DQo8UD48 L1A+PC9QPjwvQk9EWT4NCjwvSFRNTD4NCg0K --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3AOZWEX0209N2msad_-- From nobody Thu Dec 3 02:43:01 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04F21B3362 for ; Thu, 3 Dec 2015 02:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 LF5NaHznXXRL for ; Thu, 3 Dec 2015 02:42:58 -0800 (PST) Received: from pimtaint01.ms.com (pimtaint01.ms.com [199.89.103.68]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B8A1B3368 for ; Thu, 3 Dec 2015 02:42:57 -0800 (PST) Received: from pimtaint01 (localhost.ms.com [127.0.0.1]) by pimtaint01.ms.com (output Postfix) with ESMTP id E0491304409 for ; Thu, 3 Dec 2015 05:42:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449139376; x=1450348976; bh=kWroKVoGj1t2lhEfbj7/Hs5fcJjXhlx7UMXGkbpqnWs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=e66cYFsHMCGb0beP0pcGj9X3T5mgpEEJIbUbEmZ1N1DUc6tzO2J7DY2L/VdfaraOT VCrMIiX1P/QoBE3Z0xJF+D5qGrgkDRRaF41tSRfwhTk957ejpvOseIunnEwOaAFiRN s1Uu+XHVpjFsxj1o1a9zlkpwGboikOIgBgmsv32k= Received: from rrsmmta03.ms.com (rrsmmta03.ms.com [10.204.137.7]) by pimtaint01.ms.com (internal Postfix) with ESMTP id CAB2E30445C; Thu, 3 Dec 2015 05:42:56 -0500 (EST) Received: from RRWEX2005N2.msad.ms.com (rrwex2005n2.ms.com [10.196.131.20]) by rrsmmta03.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB3AgupE014486; Thu, 3 Dec 2015 10:42:56 GMT Received: from RRWEX2005N1.msad.ms.com (10.196.129.20) by RRWEX2005N2.msad.ms.com (10.196.131.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 05:42:56 -0500 Received: from OZWEX0206N1.msad.ms.com (10.208.87.43) by RRWEX2005N1.msad.ms.com (10.196.129.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Dec 2015 05:42:55 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OZWEX0206N1.msad.ms.com ([10.208.87.43]) with mapi id 14.03.0235.001; Thu, 3 Dec 2015 10:42:54 +0000 From: "Bannister, Mark" To: "'Jordan Brown'" Thread-Topic: DBIS commentary Thread-Index: AQHRJ6BIKlY+hp6UAEOXycsas61P9Z6uB0MAgAb+lgCAAOCEYIAAjJoAgAD26dCAAIbUAIABK48QgAACdTA= Date: Thu, 3 Dec 2015 10:42:53 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] x-tm-as-product-ver: SMEX-11.0.0.4179-7.500.1018-21978.003 x-tm-as-result: No--45.649200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6FOZWEX0209N2msad_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/03 04:23:00 #6678499; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 10:43:00 -0000 --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6FOZWEX0209N2msad_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiA+ID4gSm9yZGFuIEJyb3duIHdyb3RlOg0KDQo+ID4gPiA+IE1hcmsgQmFubmlzdGVyIHdyb3Rl Og0KDQo+ID4gPiA+ID4gQnR3LCB3aGF0IHdhcyB5b3VyIHBsYW4gZm9yIGNhc2Ugc2Vuc2l0aXZp dHkgaW4gZmlsZXN5c3RlbXM/DQoNCj4gPiA+ID4NCg0KPiA+ID4gPiBCYWJ5IHN0ZXBzIDotKQ0K DQo+ID4gPiA+DQoNCj4gPiA+ID4gSSBkbyB0aGluayB0aGF0IHRoYXQncyBpbmV2aXRhYmxlIHRv bywganVzdCBub3QgYXMgc29vbiBhcyB1c2VyIG5hbWVzDQoNCj4gPiA+DQoNCj4gPiA+IFdvdy4g IEdvb2QgbHVjayB3aXRoIHRoYXQuICAoQm9pbGluZyBvY2VhbnMgY29tZXMgdG8gbWluZCkuDQoN Cj4gPg0KDQo+ID4gSSB3b3JrIGluIG5hbWUgc2VydmljZXMsIG5vdCBmaWxlIHN5c3RlbXMsIHNv IGl0J3Mgbm90IGFuIGFjdGl2ZSBwcm9qZWN0LiAgSSBqdXN0IHRoaW5rIGl0J2xsIGhhcHBlbiBl dmVudHVhbGx5LCB0aGF0DQoNCj4gPiBpbnRlcm9wZXJhYmlsaXR5IHdpdGggV2luZG93cyB3aWxs IGZvcmNlIGl0Lg0KDQo+DQoNCj4gSSBmb3VuZCBhbiBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIG9u IHRoaXMgdmVyeSBzdWJqZWN0Og0KDQo+IGh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRl bT9pZD04ODc2NzIyDQoNCj4NCg0KPiBNYXJrLg0KDQoNCg0KLi4uIGFuZCBsZXTigJlzIG5vdCBh bHNvIGZvcmdldDoNCg0KaHR0cDovL3B1YnMub3Blbmdyb3VwLm9yZy9vbmxpbmVwdWJzLzAwMDA5 NTM5OS94cmF0L3hiZF9jaGFwMDQuaHRtbCN0YWdfMDFfMDRfMDYNCg0KDQoNCkkgdGhpbmsgc29t ZSBvZiB0aGUgbG9jYWxlIGNvbnNpZGVyYXRpb25zIGdpdmVuIGluIHRoZXNlIHR3byBsaW5rcyBj YW4gYmUgYXBwbGllZCB0byB0aGUgZGlzY3Vzc2lvbg0KDQpvZiBjYXNlIGluc2Vuc2l0aXZpdHkg aW4gTERBUCBhdHRyaWJ1dGVzIHRvby4NCg0KDQoNCk1hcmsuDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCk5PVElDRTogTW9yZ2FuIFN0YW5sZXkgaXMgbm90IGFj dGluZyBhcyBhIG11bmljaXBhbCBhZHZpc29yIGFuZCB0aGUgb3BpbmlvbnMgb3Igdmlld3MgY29u dGFpbmVkIGhlcmVpbiBhcmUgbm90IGludGVuZGVkIHRvIGJlLCBhbmQgZG8gbm90IGNvbnN0aXR1 dGUsIGFkdmljZSB3aXRoaW4gdGhlIG1lYW5pbmcgb2YgU2VjdGlvbiA5NzUgb2YgdGhlIERvZGQt RnJhbmsgV2FsbCBTdHJlZXQgUmVmb3JtIGFuZCBDb25zdW1lciBQcm90ZWN0aW9uIEFjdC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2UgZGVz dHJveSBhbGwgZWxlY3Ryb25pYyBhbmQgcGFwZXIgY29waWVzOyBkbyBub3QgZGlzY2xvc2UsIHVz ZSBvciBhY3QgdXBvbiB0aGUgaW5mb3JtYXRpb247IGFuZCBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseS4gTWlzdHJhbnNtaXNzaW9uIGlzIG5vdCBpbnRlbmRlZCB0byB3YWl2ZSBjb25maWRl bnRpYWxpdHkgb3IgcHJpdmlsZWdlLiBNb3JnYW4gU3RhbmxleSByZXNlcnZlcyB0aGUgcmlnaHQs IHRvIHRoZSBleHRlbnQgcGVybWl0dGVkIHVuZGVyIGFwcGxpY2FibGUgbGF3LCB0byBtb25pdG9y IGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMuIFRoaXMgbWVzc2FnZSBpcyBzdWJqZWN0IHRvIHRl cm1zIGF2YWlsYWJsZSBhdCB0aGUgZm9sbG93aW5nIGxpbms6IGh0dHA6Ly93d3cubW9yZ2Fuc3Rh bmxleS5jb20vZGlzY2xhaW1lcnMgSWYgeW91IGNhbm5vdCBhY2Nlc3MgdGhlc2UgbGlua3MsIHBs ZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgbWVzc2FnZSBhbmQgd2Ugd2lsbCBzZW5kIHRoZSBjb250 ZW50cyB0byB5b3UuIEJ5IG1lc3NhZ2luZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlvdSBjb25zZW50 IHRvIHRoZSBmb3JlZ29pbmcuDQo= --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6FOZWEX0209N2msad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8SEVBRD48IS0tIFRlbXBsYXRlIGdlbmVyYXRlZCBieSBFeGNsYWlt ZXIgVGVtcGxhdGUgRWRpdG9yIG9uIDA1OjQyOjU2IERvbmRlcmRhZywgMyBEZXNlbWJlciAyMDE1 IC0tPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+UC5hZThiNDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4 Zjc0YmRhNWQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLmFlOGI0OWQ5LWQ1ZDgtNGIw OS1hOTc1LTUxMjhmNzRiZGE1ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0KfQ0KRElWLmFlOGI0 OWQ5LWQ1ZDgtNGIwOS1hOTc1LTUxMjhmNzRiZGE1ZCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdA0K fQ0KVEFCTEUuYWU4YjQ5ZDktZDVkOC00YjA5LWE5NzUtNTEyOGY3NGJkYTVkVGFibGUgew0KCU1B UkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0N CjwvU1RZTEU+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04IiAvPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSIgLz4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQs IGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5N c29Ob1NwYWNpbmcsIGxpLk1zb05vU3BhY2luZywgZGl2Lk1zb05vU3BhY2luZw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpz cGFuLkNvZGUNCgl7bXNvLXN0eWxlLW5hbWU6Q29kZTsNCgltc28tc3R5bGUtcHJpb3JpdHk6MTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KcC5hZThiNDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4 Zjc0YmRhNWQsIGxpLmFlOGI0OWQ5LWQ1ZDgtNGIwOS1hOTc1LTUxMjhmNzRiZGE1ZCwgZGl2LmFl OGI0OWQ5LWQ1ZDgtNGIwOS1hOTc1LTUxMjhmNzRiZGE1ZA0KCXttc28tc3R5bGUtbmFtZTphZThi NDlkOS1kNWQ4LTRiMDktYTk3NS01MTI4Zjc0YmRhNWQ7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj azt9DQpwLmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWViODA4NGI2YjI2NywgbGkuY2FmYTg1OGMt YTY0YS00MDE4LWIzNTctZWI4MDg0YjZiMjY3LCBkaXYuY2FmYTg1OGMtYTY0YS00MDE4LWIzNTct ZWI4MDg0YjZiMjY3DQoJe21zby1zdHlsZS1uYW1lOmNhZmE4NThjLWE2NGEtNDAxOC1iMzU3LWVi ODA4NGI2YjI2NzsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTI1 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L0hFQUQ+DQoNCjxCT0RZIGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxQPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IEpvcmRhbiBC cm93biB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmZ3Q7ICZndDsgTWFyayBCYW5uaXN0ZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQnR3LCB3aGF0IHdh cyB5b3VyIHBsYW4gZm9yIGNhc2Ugc2Vuc2l0aXZpdHkgaW4gZmlsZXN5c3RlbXM/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBC YWJ5IHN0ZXBzIDotKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBkbyB0aGluayB0aGF0IHRoYXQncyBpbmV2aXRhYmxlIHRv bywganVzdCBub3QgYXMgc29vbiBhcyB1c2VyIG5hbWVzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmd0OyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmZ3Q7IFdvdy4mbmJzcDsgR29vZCBsdWNr IHdpdGggdGhhdC4mbmJzcDsgKEJvaWxpbmcgb2NlYW5zIGNvbWVzIHRvIG1pbmQpLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEkgd29yayBpbiBuYW1lIHNlcnZp Y2VzLCBub3QgZmlsZSBzeXN0ZW1zLCBzbyBpdCdzIG5vdCBhbiBhY3RpdmUgcHJvamVjdC4mbmJz cDsgSSBqdXN0IHRoaW5rIGl0J2xsIGhhcHBlbiBldmVudHVhbGx5LCB0aGF0PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgaW50ZXJvcGVyYWJpbGl0eSB3 aXRoIFdpbmRvd3Mgd2lsbCBmb3JjZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IEkgZm91bmQgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHZlcnkgc3ViamVj dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaHR0cHM6Ly9u ZXdzLnljb21iaW5hdG9yLmNvbS9pdGVtP2lkPTg4NzY3MjI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IE1hcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi4uLiBhbmQg bGV04oCZcyBub3QgYWxzbyBmb3JnZXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48YSBocmVmPSJodHRwOi8vcHVicy5vcGVuZ3JvdXAub3JnL29ubGluZXB1YnMvMDAw MDk1Mzk5L3hyYXQveGJkX2NoYXAwNC5odG1sI3RhZ18wMV8wNF8wNiI+aHR0cDovL3B1YnMub3Bl bmdyb3VwLm9yZy9vbmxpbmVwdWJzLzAwMDA5NTM5OS94cmF0L3hiZF9jaGFwMDQuaHRtbCN0YWdf MDFfMDRfMDY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgdGhpbmsgc29tZSBv ZiB0aGUgbG9jYWxlIGNvbnNpZGVyYXRpb25zIGdpdmVuIGluIHRoZXNlIHR3byBsaW5rcyBjYW4g YmUgYXBwbGllZCB0byB0aGUgZGlzY3Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+b2YgY2FzZSBpbnNlbnNpdGl2aXR5IGluIExEQVAgYXR0cmlidXRlcyB0b28u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1hcmsuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPEJSIC8+ PEJSIC8+DQo8SFIgaWQ9SFIxIC8+DQo8QlIgLz48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEFy aWFsOyBDT0xPUjogIzgwODA4MDsgRk9OVC1TSVpFOiA3LjVwdCI+Tk9USUNFOiANCk1vcmdhbiBT dGFubGV5IGlzIG5vdCBhY3RpbmcgYXMgYSBtdW5pY2lwYWwgYWR2aXNvciBhbmQgdGhlIG9waW5p b25zIG9yIHZpZXdzIA0KY29udGFpbmVkIGhlcmVpbiBhcmUgbm90IGludGVuZGVkIHRvIGJlLCBh bmQgZG8gbm90IGNvbnN0aXR1dGUsIGFkdmljZSB3aXRoaW4gDQp0aGUgbWVhbmluZyBvZiBTZWN0 aW9uIDk3NSBvZiB0aGUgRG9kZC1GcmFuayBXYWxsIFN0cmVldCBSZWZvcm0gYW5kIENvbnN1bWVy IA0KUHJvdGVjdGlvbiBBY3QuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlv biBpbiBlcnJvciwgcGxlYXNlIGRlc3Ryb3kgDQphbGwgZWxlY3Ryb25pYyBhbmQgcGFwZXIgY29w aWVzOyBkbyBub3QgZGlzY2xvc2UsIHVzZSBvciBhY3QgdXBvbiB0aGUgDQppbmZvcm1hdGlvbjsg YW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LiBNaXN0cmFuc21pc3Npb24gaXMgbm90 IGludGVuZGVkIA0KdG8gd2FpdmUgY29uZmlkZW50aWFsaXR5IG9yIHByaXZpbGVnZS4gTW9yZ2Fu IFN0YW5sZXkgcmVzZXJ2ZXMgdGhlIHJpZ2h0LCB0byB0aGUgDQpleHRlbnQgcGVybWl0dGVkIHVu ZGVyIGFwcGxpY2FibGUgbGF3LCB0byBtb25pdG9yIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbnMu IA0KVGhpcyBtZXNzYWdlIGlzIHN1YmplY3QgdG8gdGVybXMgYXZhaWxhYmxlIGF0IHRoZSBmb2xs b3dpbmcgbGluazogPEEgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbDsgQ09MT1I6ICM4MDgwODA7 IEZPTlQtU0laRTogNy41cHQiIGhyZWY9Imh0dHA6Ly93d3cubW9yZ2Fuc3RhbmxleS5jb20vZGlz Y2xhaW1lcnMiPmh0dHA6Ly93d3cubW9yZ2Fuc3RhbmxleS5jb20vZGlzY2xhaW1lcnM8L0E+IA0K SWYgeW91IGNhbm5vdCBhY2Nlc3MgdGhlc2UgbGlua3MsIHBsZWFzZSBub3RpZnkgdXMgYnkgcmVw bHkgbWVzc2FnZSBhbmQgd2Ugd2lsbCANCnNlbmQgdGhlIGNvbnRlbnRzIHRvIHlvdS4gQnkgbWVz c2FnaW5nIHdpdGggTW9yZ2FuIFN0YW5sZXkgeW91IGNvbnNlbnQgdG8gdGhlIA0KZm9yZWdvaW5n LjwvU1BBTj48QlIgLz4NCjxQPjwvUD4NCjxQPjwvUD4NCjxQPjwvUD48L1A+PC9CT0RZPg0KPC9I VE1MPg0KDQo= --_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6FOZWEX0209N2msad_-- From nobody Thu Dec 3 09:00:37 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC71A8F34 for ; Thu, 3 Dec 2015 09:00:36 -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 FlTBhVPGDqnv for ; Thu, 3 Dec 2015 09:00:34 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 88A711A901D for ; Thu, 3 Dec 2015 09:00:34 -0800 (PST) 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 tB3H0XlU006149 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Dec 2015 17:00:33 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 tB3H0WBb011174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 17:00:33 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 tB3H0V4C014920; Thu, 3 Dec 2015 17:00:32 GMT Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 09:00:31 -0800 To: "Bannister, Mark" References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> From: Jordan Brown Message-ID: <56607528.9050905@oracle.com> Date: Thu, 3 Dec 2015 09:00:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> Content-Type: multipart/alternative; boundary="------------060409080206060504060102" X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] DBIS commentary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 17:00:36 -0000 This is a multi-part message in MIME format. --------------060409080206060504060102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/3/2015 2:35 AM, Bannister, Mark wrote: > >> It doesn't look like you've got 4876 completely covered, though. Attribute >> mapping is only one of the things it does - it also tells the clients which >> servers to connect to and what authentication schemes to use. If you're >> replacing 4876, there should be a plan for replacing that capability. > > Yes I’ve not quite understood that. You need to configure the client to talk to > an LDAP server, in order > > to obtain a profile that tells it to talk to a different LDAP server instead. > Why would you not just > > configure the client to talk to the correct LDAP server in the first place? > Please explain the use-case. > Centralized reconfiguration. Your initial configuration is a bootstrap; after that, changes in the profile can direct you to use new sets of servers as existing servers are replaced. Similarly, if you've got PKI or Kerberos infrastructure in place, the profile can tell you to start using it. --------------060409080206060504060102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/3/2015 2:35 AM, Bannister, Mark wrote:

It doesn't look like you've got 4876 completely covered, though.  Attribute mapping is only one of the things it does - it also tells the clients which servers to connect to and what authentication schemes to use.  If you're replacing 4876, there should be a plan for replacing that capability.

Yes I’ve not quite understood that.  You need to configure the client to talk to an LDAP server, in order

to obtain a profile that tells it to talk to a different LDAP server instead.  Why would you not just

configure the client to talk to the correct LDAP server in the first place?  Please explain the use-case.


Centralized reconfiguration.  Your initial configuration is a bootstrap; after that, changes in the profile can direct you to use new sets of servers as existing servers are replaced.  Similarly, if you've got PKI or Kerberos infrastructure in place, the profile can tell you to start using it.

--------------060409080206060504060102-- From nobody Thu Dec 3 09:17:37 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524CF1B2B29 for ; Thu, 3 Dec 2015 09:17:36 -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 ekGwPYZuvgkT for ; Thu, 3 Dec 2015 09:17:35 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 EE0DE1B2A29 for ; Thu, 3 Dec 2015 09:17:34 -0800 (PST) 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 tB3HHXIw028846 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Dec 2015 17:17:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB3HHXgl030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 17:17:33 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB3HHX2w000566; Thu, 3 Dec 2015 17:17:33 GMT Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 09:17:33 -0800 To: "Bannister, Mark" References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> From: Jordan Brown Message-ID: <56607926.1080306@oracle.com> Date: Thu, 3 Dec 2015 09:17:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> Content-Type: multipart/alternative; boundary="------------080309080407040105060800" X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 17:17:36 -0000 This is a multi-part message in MIME format. --------------080309080407040105060800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit [ Trying to keep case sensitivity discussions on their own thread ] On 12/3/2015 2:42 AM, Bannister, Mark wrote: > > ... and let’s not also forget: > > http://pubs.opengroup.org/onlinepubs/000095399/xrat/xbd_chap04.html#tag_01_04_06 > > I think some of the locale considerations given in these two links can be > applied to the discussion > > of case insensitivity in LDAP attributes too. > If we were starting from NIS and /etc/passwd, yes. If we were not concerned with directory interoperability between different platforms, yes. If we were not concerned with consistency with names as used in the rest of the industry and in normal human practice, yes. But none of those things are true. --------------080309080407040105060800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
[ Trying to keep case sensitivity discussions on their own thread ]

On 12/3/2015 2:42 AM, Bannister, Mark wrote:

... and let’s not also forget:

http://pubs.opengroup.org/onlinepubs/000095399/xrat/xbd_chap04.html#tag_01_04_06

 

I think some of the locale considerations given in these two links can be applied to the discussion

of case insensitivity in LDAP attributes too.


If we were starting from NIS and /etc/passwd, yes.
If we were not concerned with directory interoperability between different platforms, yes.
If we were not concerned with consistency with names as used in the rest of the industry and in normal human practice, yes.

But none of those things are true.

--------------080309080407040105060800-- From nobody Thu Dec 3 14:45:25 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5D31B2B26 for ; Thu, 3 Dec 2015 14:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ct_hX-yCccIv for ; Thu, 3 Dec 2015 14:45:22 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 1A5121B2B45 for ; Thu, 3 Dec 2015 14:45:22 -0800 (PST) Received: by lbcdv4 with SMTP id dv4so10519641lbc.2 for ; Thu, 03 Dec 2015 14:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eC+PWgKHO+y8cdmIqmn4OLh/WNCmY5/SvBJLB+q4l4s=; b=GG55V2vvV322633dPNx/u7LahwssV3PFBXmg3h6gLkwY2VC437YeHh0qzqI7pEJvJd yHsVondvovE231WX+f4xezaBpNTXcQHd4cNy7RR4GXrFnDvdRrX2uOvh4SebXIQXbLXf JK08UHPmCk5/vdUnxgu0XxdVgglsf6c+SUmdy25QvsqaG2SMAPK7tcZVsAAX8cTLkbZB 0A//K2hjF61B/hZ28Ly5LlEwkKFgBcGjorwYAR0EzKQCYbRYeXvu8d4wdkchx7bh5dZK pKkbZF3Y48hR46J3YGtnUR4NudW9fwUlqlajSPtJ4q1Nv8AhGscq3gC0WlHYtGEnvuOv HkgQ== MIME-Version: 1.0 X-Received: by 10.112.247.103 with SMTP id yd7mr6756335lbc.46.1449182720286; Thu, 03 Dec 2015 14:45:20 -0800 (PST) Received: by 10.114.80.193 with HTTP; Thu, 3 Dec 2015 14:45:20 -0800 (PST) In-Reply-To: <56607926.1080306@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> Date: Thu, 3 Dec 2015 17:45:20 -0500 Message-ID: From: Charlie To: Jordan Brown Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 22:45:23 -0000 Well, in a cleanly integrated environment, I'd expect to see most users' Microsoft SamAccountName and POSIX uid be identical lower-cased strings less than 20 characters long. I believe all currently shipping LDAP directory implementations support the necessary schema. Certainly AD and OpenLDAP both do. SamAccountName should be case-insensitive, uid should be case-sensitive. If you use each one appropriately in the environment for which it is intended, you can let POSIX sysadmins and Windows sysadmins retain whatever preferences, whims or bigotries they treasure. End users will be able to use all their systems as the documentation directs them, and programmers will be able to rely on their man pages &etc. I just don't see any significant advantages to using a single naming attribute shared with other systems. Why bother? It's all pain, no gain. Keeping case-sensitive and case-insensitive versions of user identifiers is easier and gives better results. All software on the local node will perform as expected, and no OS documentation needs to be rewritten. --Charlie From nobody Thu Dec 3 15:02:26 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FEB1B2BF7 for ; Thu, 3 Dec 2015 15:02:24 -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 EJHVZQs5sB4m for ; Thu, 3 Dec 2015 15:02:23 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1789F1B2C10 for ; Thu, 3 Dec 2015 15:02:13 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB3N28wW014450 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Dec 2015 23:02:08 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB3N27vm031353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 23:02:07 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB3N27vB019135; Thu, 3 Dec 2015 23:02:07 GMT Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 15:02:06 -0800 To: Charlie References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> From: Jordan Brown Message-ID: <5660C9ED.7040000@oracle.com> Date: Thu, 3 Dec 2015 15:02:05 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 23:02:25 -0000 On 12/3/2015 2:45 PM, Charlie wrote: > Well, in a cleanly integrated environment, I'd expect to see most > users' Microsoft SamAccountName and POSIX uid be identical lower-cased > strings less than 20 characters long. I believe all currently > shipping LDAP directory implementations support the necessary schema. > Certainly AD and OpenLDAP both do. > > SamAccountName should be case-insensitive, uid should be > case-sensitive. If sAMAccountName and uid are identical, and sAMAccountName is case-insensitive, doesn't that mean that you can't have two users whose 'uid' differs only in case? It would seem that the only visible effect of such a configuration is that an attempt to look up a wrong-case name on UNIX would fail, which is compatible in some sense but doesn't seem to really add any value over case-insensitivity. From nobody Thu Dec 3 15:13:05 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32831A03A9 for ; Thu, 3 Dec 2015 15:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 BgQ3JY2Ch5zB for ; Thu, 3 Dec 2015 15:13:02 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 986411A03A6 for ; Thu, 3 Dec 2015 15:12:56 -0800 (PST) Received: by lfdl133 with SMTP id l133so100492061lfd.2 for ; Thu, 03 Dec 2015 15:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=grCSmTQs/0UZsupIWBC8pOKWIy32JzwZVfYpVOUUPRM=; b=nDilZCvRPlJLKcTN2q1igbX0ohKuaDjj3yI/wcStJZADOhhSXbTRybNzcbjxf+ccAj s42DLaW/LO7kUyBkZgKWYxIZerlaG89lXMHRoNLcJw+BpGxYM2hd4z5WJIpv940q8nDL nPpYW2p7LKmDKpjObr7RPiNZ9wpXFMufXbwQjnN75/65sOQP/6Hrz4e4h5pKbuG2Iped 8GsALwpTqvqAOT22Jat7j0s2JAu2E/N3Afyl7o+58ZjWlqwk7mZBfo2lGa528og8WuJh y6kGYL/QlRl3ucEGUk4PPkKjN6zSfl8oafLc7cdexSH4mIr+77wgdp1o3CHSyiWCuKV8 bUYQ== MIME-Version: 1.0 X-Received: by 10.25.150.204 with SMTP id y195mr6799749lfd.66.1449184374737; Thu, 03 Dec 2015 15:12:54 -0800 (PST) Received: by 10.114.80.193 with HTTP; Thu, 3 Dec 2015 15:12:54 -0800 (PST) Date: Thu, 3 Dec 2015 18:12:54 -0500 Message-ID: From: Charlie To: ldapext Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 23:13:04 -0000 After reading David Foster Wallace on set theory, I wrote an RFC a couple years back to address the lack of a generic or globally useful grouping mechanism in LDAP-accessible directories. Comments are welcomed. http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt If you're not up for a long-read, I would recommend just reading "Appendix D: Other Efforts and their Shortcomings" which explains all the attempts to date and how they've failed to gain traction. Projects continue to try to solve their individual problems instead of working towards a truly generic grouping mechanism that will suit all needs, so nothing's progressing. Simo mentioned this in the context of FreeIPA, for example - they broke their implementation of RFC2307 and moved on, rather than helping Andrew Findlay create a standard that supported empty groups. It seems like each of us is focused on our own potato patch. --Charlie From nobody Thu Dec 3 15:24:35 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FC71A1A17 for ; Thu, 3 Dec 2015 15:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Ne-0QsWx05-b for ; Thu, 3 Dec 2015 15:24:33 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 C63F71A1A04 for ; Thu, 3 Dec 2015 15:24:32 -0800 (PST) Received: by lfaz4 with SMTP id z4so101292393lfa.0 for ; Thu, 03 Dec 2015 15:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ZwgWQG2NAdNOVBecbrm3OCjXbh2ggN3ZVW00fBx/Vw=; b=XFQSEYb8nrSvoLD5X0FDG7lgjlBF4CLa2bNs4TG5JZ7NNI7PJ3lFi48BQjPst11xBS t3Fwplke5Po6s/G4V1OKWAHGj/NN/XhKW092haA6rP2dN5K4Fo6sUIYC726lM2MejmNi pNF3/NOEnkhsJEoS8SvdeDhoESMv7oQkWZHwexn8HJ039V2fPa22MWqm/WP4HiiMgwiu ufebz9oBLWbOdROXBf7v1xRLpPNjcQP5K7mRZJYkuaN1v4m+9Oz6cTD1ihMp+5QXd3fU mrq0RpPVnzSJ34YlgskAvwIlQpkhPHGPUesIWzq6iB/wBn4Ehq0hLLisE9Mx7/RqBNrY ds2A== MIME-Version: 1.0 X-Received: by 10.25.29.205 with SMTP id d196mr6740310lfd.81.1449185071031; Thu, 03 Dec 2015 15:24:31 -0800 (PST) Received: by 10.114.80.193 with HTTP; Thu, 3 Dec 2015 15:24:30 -0800 (PST) In-Reply-To: <5660C9ED.7040000@oracle.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> <5660C9ED.7040000@oracle.com> Date: Thu, 3 Dec 2015 18:24:30 -0500 Message-ID: From: Charlie To: Jordan Brown Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 23:24:34 -0000 On Thu, Dec 3, 2015 at 6:02 PM, Jordan Brown wrote: > On 12/3/2015 2:45 PM, Charlie wrote: >> >> Well, in a cleanly integrated environment, I'd expect to see most >> users' Microsoft SamAccountName and POSIX uid be identical lower-cased >> strings less than 20 characters long. I believe all currently >> shipping LDAP directory implementations support the necessary schema. >> Certainly AD and OpenLDAP both do. >> >> SamAccountName should be case-insensitive, uid should be >> case-sensitive. > > If sAMAccountName and uid are identical, and sAMAccountName is > case-insensitive, doesn't that mean that you can't have two users whose > 'uid' differs only in case? I think you missed the word "most"? Normal user accounts being created today would be unlikely to differ from each other only in case. Just old stuff and unique hacks. > It would seem that the only visible effect of such a configuration is that > an attempt to look up a wrong-case name on UNIX would fail, which is > compatible in some sense but doesn't seem to really add any value over > case-insensitivity. I see compatibility with published standards and system documentation as being vastly more valuable than catering to typing mistakes, but obviously that's just my opinion. More importantly, *nix tools and system utilities are going to make case-sensitive comparisons of usernames internally, so if your name service daemons aren't case-sensitive as well, *nix-based systems are likely to be subtly broken. Comparisons aren't restricted to the LDAP service host, they happen on the local OS too - including in site-developed code that was built to documented standards. --Charlie From nobody Thu Dec 3 16:33:53 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34F1B2B59 for ; Thu, 3 Dec 2015 16:33:51 -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 YrSfLjbMBMId for ; Thu, 3 Dec 2015 16:33:50 -0800 (PST) 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 EF5251B2B54 for ; Thu, 3 Dec 2015 16:33:49 -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 tB40XiaH026140 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 00:33:45 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 tB40XiFh001426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 00:33:44 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 tB40Xits003664; Fri, 4 Dec 2015 00:33:44 GMT Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 16:33:44 -0800 To: Charlie , ldapext References: From: Jordan Brown Message-ID: <5660DF62.5000800@oracle.com> Date: Thu, 3 Dec 2015 16:33:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 00:33:52 -0000 On 12/3/2015 3:12 PM, Charlie wrote: > After reading David Foster Wallace on set theory, I wrote an RFC a > couple years back to address the lack of a generic or globally useful > grouping mechanism in LDAP-accessible directories. Comments are > welcomed. > > http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt 3.1. Properly, Boy Scout and Scout are capitalized. In the general case, I'd say that it's equally correct to say that the list of Scouts is an attribute of the troop and to say that membership in the troop is an attribute of the particular Scout. It's an N:M relationship; it can be approached from either direction. (I had not realized until I got to the discussion in D.2 that a mailing list was best served by member-of attributes. One would think that it would be best served by a member-list attribute, but you're absolutely correct that using a member-of attribute reduces the number of queries in the common case.) For an indexed database, it's probably OK to represent the relationship in either direction. For a database that understands the relationship, the relationship might be visible on both sides and the connection automatically maintained. For simpler databases, indeed maintaining "member-of" is probably better, both because it's convenient for the common queries and because it's probably a smaller list than the "members" list. (But note: it's not at all obvious which variation is better from an access control standpoint. Is it more likely that you will want to hide the membership of group X, or the list of groups that user Y is a member of? Presumably if you want to do either, then you need to ensure that that membership linkage, however it is presented in the directory, is subject to access control restrictions.) 3.4. Empty sets are also useful in trivial cases, e.g. when creating a set and before populating, and as a possible intermediate state while adding and removing members. 3.5 I'm not convinced that "proxy" objects (which you call "dummy" objects) aren't the right answer. Directly referring to external objects assumes that there's no need for auxiliary data about those objects. (Hmm. Is there a need to describe auxiliary information about a particular membership relationship? For instance, for a mailing list, might one want to maintain a count of messages from a particular list to a particular user that have bounced?) 4.4 I'm not convinced that an undefined "scope" attribute is helpful. 4.5 psetMembership seems like overkill, though its ability to represent dynamic sets is interesting. 5.3 If recursion is always expanded by the client, there's no need for timeouts on queries to prevent DoS. The clients can decide on their own when to stop recursing. C.1, C.2 I thought that memberOfPset contained DNs. D.5 posixGroup has memberUid as a MAY attribute and so *can* represent empty sets. > If you're not up for a long-read, I would recommend just reading > "Appendix D: Other Efforts and their Shortcomings" which explains all > the attempts to date and how they've failed to gain traction. > > Projects continue to try to solve their individual problems instead of > working towards a truly generic grouping mechanism that will suit all > needs, so nothing's progressing. Simo mentioned this in the context > of FreeIPA, for example - they broke their implementation of RFC2307 > and moved on, rather than helping Andrew Findlay create a standard > that supported empty groups. It seems like each of us is focused on > our own potato patch. > Actually, here in the Solaris Naming organization, mostly our assumption is that we have to live with whatever the directory gives us, that the directory was established by the enterprise before we arrived on the scene and so our ability to influence it is minimal. We might participate in an effort such as this one to try to nudge the future in a desirable direction, but the assumption is that no one scheme will ever achieve such dominance that we can ignore the others. Of course I would be happy to be proven wrong so that we could remove a bunch of flexibility that's associated with the need to interoperate with such a variety of schemata. From nobody Thu Dec 3 16:51:43 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81F01B2C40 for ; Thu, 3 Dec 2015 16:51:42 -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 5iuHqd1E7EIg for ; Thu, 3 Dec 2015 16:51:41 -0800 (PST) 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 9C99D1B2C3B for ; Thu, 3 Dec 2015 16:51:41 -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 tB40panC008014 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 00:51:37 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB40pa9r026228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 00:51:36 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB40paNd029573; Fri, 4 Dec 2015 00:51:36 GMT Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 16:51:36 -0800 To: Charlie References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> <5660C9ED.7040000@oracle.com> From: Jordan Brown Message-ID: <5660E396.5030700@oracle.com> Date: Thu, 3 Dec 2015 16:51:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 00:51:42 -0000 I'm sorry, I just realized that this is a religious rathole that I can't afford to dive into. From nobody Thu Dec 3 23:11:07 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6F1ACEB0 for ; Thu, 3 Dec 2015 23:11:03 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, 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 S8i5lEi1_y5A for ; Thu, 3 Dec 2015 23:11:00 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4568F1B2E64 for ; Thu, 3 Dec 2015 23:10:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,380,1444719600"; d="scan'208";a="80834854" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 03 Dec 2015 23:05:58 -0800 Received: from HIOEXCMBX04-PRD.hq.netapp.com (10.122.105.37) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 3 Dec 2015 23:05:58 -0800 Received: from HIOEXCMBX04-PRD.hq.netapp.com ([::1]) by hioexcmbx04-prd.hq.netapp.com ([fe80::107a:3106:443b:1db%21]) with mapi id 15.00.1130.005; Thu, 3 Dec 2015 23:05:58 -0800 From: "Oza, Dhairesh" To: Charlie , Jordan Brown Thread-Topic: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) Thread-Index: AQHRLe6O+FgodCN8CUyJPi8xgUdUmJ66YtIAgAAEroCAAAZDAP//5pwg Date: Fri, 4 Dec 2015 07:05:57 +0000 Message-ID: <8f2da2363f684ec6bc95f8046dd81bd3@hioexcmbx04-prd.hq.netapp.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> <5660C9ED.7040000@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 07:11:04 -0000 >=20 > > It would seem that the only visible effect of such a configuration is > > that an attempt to look up a wrong-case name on UNIX would fail, which > > is compatible in some sense but doesn't seem to really add any value > > over case-insensitivity. >=20 > I see compatibility with published standards and system documentation as > being vastly more valuable than catering to typing mistakes, but obviousl= y > that's just my opinion. >=20 > More importantly, *nix tools and system utilities are going to make case- > sensitive comparisons of usernames internally, so if your name service > daemons aren't case-sensitive as well, *nix-based systems are likely to b= e > subtly broken. Comparisons aren't restricted to the LDAP service host, t= hey > happen on the local OS too - including in site-developed code that was bu= ilt to > documented standards. =20 They shouldn't be comparing names but uids/gids. Most tools and file system= s do this. As long as the source for look-up is always LDAP for both the cl= ient and server and it handles the cases consistently, there should not be = any problem. When specifying usernames in configs (like owner on files), it= would be nice if case didn't matter. So I agree with earlier comments that changing usernames that differ only i= n cases is a onetime pain that can be borne during the transition to LDAP f= rom NIS. Rgds Dhairesh > --Charlie >=20 > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext From nobody Fri Dec 4 02:02:38 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586E1B2DE3 for ; Fri, 4 Dec 2015 02:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 LLTU0aij1aGa for ; Fri, 4 Dec 2015 02:02:35 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10F51B2F37 for ; Fri, 4 Dec 2015 02:02:34 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id CB5051CE55; Fri, 4 Dec 2015 10:02:31 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 86D161D29F; Fri, 4 Dec 2015 10:02:30 +0000 (UTC) To: Charlie , ldapext References: From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <566164B6.9080008@stroeder.com> Date: Fri, 4 Dec 2015 11:02:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020200070302080009000608" Archived-At: Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 10:02:37 -0000 This is a cryptographically signed message in MIME format. --------------ms020200070302080009000608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Charlie wrote: > After reading David Foster Wallace on set theory, I wrote an RFC a > couple years back to address the lack of a generic or globally useful > grouping mechanism in LDAP-accessible directories. Comments are > welcomed. >=20 > http://typinganimal.net/rants/textify.php?f=3Ddraft-brooks-ldap-sets-00= =2Etxt Although you will likely claim that your I-D also describes the problem i= n general you're already endorsing a particular solution. :-/ I suspect that your mixed use of values in attribute 'psetMembership' wil= l rather contribute to the "hodgepodge of LDAP schema" you criticize than s= olving problems. Personally I don't see a strong need for generic "ur-objects" because one= can easily define such a schema for a particular deployment with custom schem= a with particular semantics. > If you're not up for a long-read, I would recommend just reading > "Appendix D: Other Efforts and their Shortcomings" which explains all > the attempts to date and how they've failed to gain traction. I agree with some of your points therein. But you have a wild mix of true= issues on one side and bad common practice with dummy objects on the other hand.= I'd say we should: 1. fix true issues (e.g. empty-group-problem) with a new I-D. 2. Add text (implementation notes, security considerations etc.) to preve= nt bad practice. For 2. you will never find text which prevents all people to shoot themse= lves in the foot. Ciao, Michael. --------------ms020200070302080009000608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDEwMDIzMFowLwYJKoZIhvcNAQkEMSIEIK2CTLi1zzQ4qcSU7gRP2YsRV7EHX106A7Qf 4fv02HyjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBd+LTAUAy7/3rrzsGT p3KpT6DOazNtFyknBqPHSELPQmHByoMJnF80yaceotNTUqUkxKYAgJhspCIbrgcFZihYR4BC zSQceGrPzqv7qxJD77CzlJFv1OX4O1npTjPROFemoZlbuadxf7+GMKGtOo0lAtynnb6f947q /WwjbrZG7Oj1WYW45ml6H4m05jPnYHeLqP78T+d401Sur4QOjKOuUQaNwrPUx7Y2aW6qbL8Q mf1C66XT335sJALA5pXo/bNLgzOiZWyJFlfnEgzA4sdDB6Qxl/JAuu0PlOeFur5xxRCRr6Xf N0KVmrV0+pGhp15yIouiNzUG+t3EcaWHUdZVAAAAAAAA --------------ms020200070302080009000608-- From nobody Fri Dec 4 03:18:00 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8461B1B3029 for ; Fri, 4 Dec 2015 03:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 nGM-Y1zSLNmQ for ; Fri, 4 Dec 2015 03:17:56 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70421B3025 for ; Fri, 4 Dec 2015 03:17:55 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 56F9D1CF66 for ; Fri, 4 Dec 2015 11:17:52 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 79F9B1D29F for ; Fri, 4 Dec 2015 11:17:49 +0000 (UTC) To: ldapext From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661765D.6040603@stroeder.com> Date: Fri, 4 Dec 2015 12:17:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020409020300050803080500" Archived-At: Subject: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 11:17:58 -0000 This is a cryptographically signed message in MIME format. --------------ms020409020300050803080500 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable HI! I try to summarize the pros and cons of approaches dealing with the empty-groupOfNames-issue raised here and there very often. Let us please focus on this particular issue. -------------------------------------------------------------------------= 1. Modified standard schema descriptions for 'groupOfNames' and 'groupOfUniqueNames': This is the work-around already chosen by various vendors: The MUST member or MUST uniqueMember is turned into MAY. + it just works, no interop-problems seen so far. + no change required in LDAP clients + no change required in access control rules + no change required in other client or server-side code dealing with gro= ups - It violates standardization best practices, most notably IANA considera= tions. - It could serve as a bad example to change standard schema at will. - Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA considerations. -------------------------------------------------------------------------= 2. new object class 'groupOfEntries' Andrew kindly wrote an mini I-D defining a new structural object class 'groupOfEntries' simply with MAY member instead of MUST meant as direct replacement for 'groupOfNames'. http://tools.ietf.org/html/draft-findlay-ldap-groupofentries + Very simple + Fully compliant to standardization best practices - It's not clear whether it was widely adopted in deployments. - small change required in LDAP clients for searching group entries - small change required in access control rules - small changes required in other client or server-side code dealing with= groups -------------------------------------------------------------------------= 3. draft-brooks-ldap-sets More general approach for solving all kinds of grouping issues by providi= ng a generic schema for sets. http://typinganimal.net/rants/textify.php?f=3Ddraft-brooks-ldap-sets-00.t= xt + generic solution for everything - completely new approach not compatible at all to what clients expect to= day - access control rules have to be modified (which might also be a pro but= not sure) - I-D did not receive much review so far, review effort needed -------------------------------------------------------------------------= Add more variants if you know about them. I'd like to get some result soon on which of these solutions have a vague= chance to be adopted at all. Given the former discussions we likely achieve a q= uicker result if we simply rule out approaches first. Especially some vendors should raise their voice which approaches they ar= e willing to adopt or not. Ciao, Michael. --------------ms020409020300050803080500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDExMTc0OVowLwYJKoZIhvcNAQkEMSIEIKl2HJWIjVgxKxmBdRbelpRiMRFgzRiRgwTT vB69cuoQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQB1D7r57M1YTR0eQ1oN 1a420/+nf48xa6XHqTCQ/BXWkAOwBUh6SBfmQqpVqyVlhEhfmvBeoo6kU/IyV02851kQysAu 6skJZIUwlL9+LWTf3MfpPDZQWm8zJDYy46PeawCEs7/c6tj4upwD0JLHBsckCvVLSY8LKX1z V2/6tXz8+VP5G1biT52duct9QRZ/lmbb971FMLCL5US/+bYmBmLCs8nAiGOV8yaT+bTNNvan g87jI0cyrpzcQgZ7XlfuRyc8SFOg7w2iuBizaFJgId3f3Vg8yZ1+NAlyw64XlobZbin1t+4l We0DZpUXQT7rCg4/gkaJLMF3c7Gso4juo6MbAAAAAAAA --------------ms020409020300050803080500-- From nobody Fri Dec 4 04:43:18 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED41B30ED for ; Fri, 4 Dec 2015 04:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 PrYT6-mn6QNP for ; Fri, 4 Dec 2015 04:43:14 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448861B30E3 for ; Fri, 4 Dec 2015 04:43:14 -0800 (PST) Received: from 208.51.155.90.in-addr.arpa ([90.155.51.208] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4phf-0004de-64 for ldapext@ietf.org; Fri, 04 Dec 2015 12:43:11 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4pco-0002Nr-8Q; Fri, 04 Dec 2015 12:38:10 +0000 Date: Fri, 4 Dec 2015 12:38:10 +0000 From: Andrew Findlay To: LDAP Extensions list Cc: LDAPEXT Message-ID: <20151204123810.GA8983@slab.skills-1st.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2da2363f684ec6bc95f8046dd81bd3@hioexcmbx04-prd.hq.netapp.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Subject: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 12:43:17 -0000 The more I look at this problem the more complex it gets, so time for a summary. Mark Bannister points out that case is a hard problem. In fact if we consider all the locales and cultures that a standard must serve it is *impossible* to do case-folding 'right' for everyone at once. > https://news.ycombinator.com/item?id=8876722 > http://pubs.opengroup.org/onlinepubs/000095399/xrat/xbd_chap04.html#tag_01_04_06 On the other hand, most computer users in Western cultures have become used to a large degree of case-insensitivity and this has been rolled into a lot of standards. There are several reasons for this, for example: 1) History: until about 1985 there were a lot of I/O devices that could not handle lower case at all, so when lower-case became available it had to be used in a backwards-compatible way. Indeed, some banking systems still seem to be upper-case only. 2) In some cultures there are no hard-and-fast rules for how certain name forms should be capitalised, so searches have to allow for this common ambiguity. 3) Laziness. This might be considered a virtue. Like it or not, all of the computing systems we are working with started life with a very strong Western cultural bias. In fact most of them have a bias towards the English language as used in North America. This means that Western non-technical users expect case-insensitive behaviour wherever that is possible. They have to be reminded that passwords are (sometimes) case sensitive and that the Caps Lock key is a hazard. The case-sensitive/insensitive problem is not just Unix vs Windows. For most end-users the ever-growing range of web-based apps is far more important. Many of those use e-mail addresses as usernames, and assume that such things are always case-insensitive. The standards allow case-sensitive names to the left of the '@' but in practice no mail admin in their right mind would implement case sensitive addresses. At least in this case we have a limited character set where case rules are well defined! We are not going to define a standard that forces everyone to do everything 'right' while providing interworking of differing systems. It is simply not possible. What we might aspire to is a standard that is general enough to be useful, which is internally self-consistent, and which comes with some guidelines to help people change their systems to work with it without breaking too many things. Charlie said: > Well, in a cleanly integrated environment, I'd expect to see most > users' Microsoft SamAccountName and POSIX uid be identical lower-cased > strings less than 20 characters long. ... and later: > Normal user accounts being > created today would be unlikely to differ from each other only in > case. Just old stuff and unique hacks. That seems like a very sensible target for systems serving predominantly Western user-bases. To make it really safe you have to disallow all non-ASCII characters, but that can be relaxed if the name form is carefully controlled at account-creation time and the users are told to always enter it exactly as defined. > I just don't see any significant advantages to using a single naming > attribute shared with other systems. Why bother? It's all pain, no > gain. Keeping case-sensitive and case-insensitive versions of user > identifiers is easier and gives better results. All software on the > local node will perform as expected, and no OS documentation needs to > be rewritten. If we were just trying to serve Unix and Windows that might be true, but the problem is wider. A unified account namespace for all systems is a worthwhile target for any organisation, but every system added to the mix brings its own quirks and limitations. Catering for those is more in the realm of best-practice advice than standards definition. > More importantly, *nix tools and system utilities are going to make > case-sensitive comparisons of usernames internally, so if your name > service daemons aren't case-sensitive as well, *nix-based systems are > likely to be subtly broken. Comparisons aren't restricted to the LDAP > service host, they happen on the local OS too - including in > site-developed code that was built to documented standards. While true, the amount of trouble caused by this can be considerably reduced by following a strict username allocation policy such as the one proposed above. Dhairesh said: > So I agree with earlier comments that changing usernames that differ > only in cases is a onetime pain that can be borne during the transition > to LDAP from NIS. Overall I think we are heading for something like this: 1) Usernames and groupnames should have caseIgnoreMatch syntax 2) Usernames and groupnames should preferably be stored in lower-case in cultures where that has meaning. Remember that LDAP is case-preserving even for case-insensitive attributes. 3) Systems that are internally case-sensitive should take extra care when using data from LDAP. I know this conflicts with Mark's wish to be able to import existing NIS data unchanged to cope with weird existing situations, but I see that as a special case that may be better handled in another way. Note that the above discussion *only* applies to usernames and groupnames. Unix-specific mappings such as automount maps are a different issue. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 05:53:04 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0040D1B31B9 for ; Fri, 4 Dec 2015 05:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4YHCLzZWk_5s for ; Fri, 4 Dec 2015 05:53:01 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238D41B31B4 for ; Fri, 4 Dec 2015 05:53:01 -0800 (PST) Received: from 208.51.155.90.in-addr.arpa ([90.155.51.208] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4qnC-0005Kb-OP; Fri, 04 Dec 2015 13:52:58 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4qiL-0002TU-7u; Fri, 04 Dec 2015 13:47:57 +0000 Date: Fri, 4 Dec 2015 13:47:57 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20151204134757.GE3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5661765D.6040603@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: ldapext Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 13:53:03 -0000 On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Strder wrote: > 1. Modified standard schema descriptions for 'groupOfNames' and > 'groupOfUniqueNames': > > This is the work-around already chosen by various vendors: > The MUST member or MUST uniqueMember is turned into MAY. > > + it just works, no interop-problems seen so far. > + no change required in LDAP clients > + no change required in access control rules > + no change required in other client or server-side code dealing with groups > > - It violates standardization best practices, most notably IANA considerations. > - It could serve as a bad example to change standard schema at will. > > Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA > considerations. I don't think there is an IANA consideration here. The modified schema is (currently) incorrect according to RFC4519 or is alternatively an experiment leading to a proposed change to a standard. In the latter case it would have to be accepted by IETF and published in a new RFC that obsoletes 4519. At that time, IANA would update the reference in the Object Identifiers table to point to the new document but would have no other involvement. In practice I cannot see such a change ever being accepted into the standards track. If anything, the relatively wide distribution of non-conformant implementations makes a stronger case for deprecating these objectclasses for new deployments. The definition of groupOfNames goes right back to X.521(1988) and it was already broken at that point: a) member was a mandatory attribute b) Nested groups were mentioned in the text but the semantics were left undefined > ------------------------------------------------------------------------- > > 2. new object class 'groupOfEntries' > > Andrew kindly wrote an mini I-D defining a new structural object class > 'groupOfEntries' simply with MAY member instead of MUST meant as direct > replacement for 'groupOfNames'. > > http://tools.ietf.org/html/draft-findlay-ldap-groupofentries > > + Very simple > + Fully compliant to standardization best practices > > - It's not clear whether it was widely adopted in deployments. Maybe not in the exact form I described in that I-D, but functionally equivalent objectclasses have been in most of my customers' systems. It could be argued that the corrupted form of groupOfNames described above is actually proof of widespread deployment of an analogous class. > - small change required in LDAP clients for searching group entries > - small change required in access control rules > - small changes required in other client or server-side code dealing with groups Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 06:00:53 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14C41B31BA for ; Fri, 4 Dec 2015 06:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 l3c5PrgWnC4w for ; Fri, 4 Dec 2015 06:00:49 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9BC1A87C7 for ; Fri, 4 Dec 2015 06:00:49 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id D6BF71CF66; Fri, 4 Dec 2015 14:00:46 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 264781D29F; Fri, 4 Dec 2015 14:00:45 +0000 (UTC) To: Andrew Findlay , LDAP Extensions list References: <20151204123810.GA8983@slab.skills-1st.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <56619C8C.1010805@stroeder.com> Date: Fri, 4 Dec 2015 15:00:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20151204123810.GA8983@slab.skills-1st.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080209050307080609050305" Archived-At: Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:00:52 -0000 This is a cryptographically signed message in MIME format. --------------ms080209050307080609050305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > We are not going to define a standard that forces everyone to do everyt= hing > 'right' while providing interworking of differing systems. It is simply= > not possible. That perfectly summarizes this topic. Thanks Andrew, for this clear statement. Let's keep the scope right. > Overall I think we are heading for something like this: >=20 > 1) Usernames and groupnames should have caseIgnoreMatch syntax >=20 > 2) Usernames and groupnames should preferably be stored in lower-case i= n > cultures where that has meaning. Remember that LDAP is case-preserving= > even for case-insensitive attributes. >=20 > 3) Systems that are internally case-sensitive should take extra care > when using data from LDAP. >=20 > I know this conflicts with Mark's wish to be able to import existing > NIS data unchanged to cope with weird existing situations, but I see th= at=20 > as a special case that may be better handled in another way. +1 !!! (That's pretty much exactly what I planned to suggest.) > Note that the above discussion *only* applies to usernames and groupnam= es. > Unix-specific mappings such as automount maps are a different issue. automount maps are maybe a similar topic like generating 'homeDirectory' = values for $HOME on case-sensitive file-systems based on user names. For this RECOMMENDing that usernames are normalized to lower-case is really helpfu= l. Regarding service names: (Personally I never saw any customer LDAP deployment storing a services m= ap.) 1. Service names are used in DNS RRs (SRV, DANE, etc.) and those DNS labe= ls are definitely supposed to be treated case-insensitive. 2. Jordan pointed out RFC 6335. =3D> I concur with Jordan: Service names MUST be treated case-insensitive= =2E Probably recommending in an implementation note to normalize values to lower-case seems also to be a good idea. =3D> People actually using case-sensitive service names to address *diffe= rent* services MUST clean up their local mess. But they likely have to do that = anyway. Ciao, Michael. --------------ms080209050307080609050305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE0MDA0NFowLwYJKoZIhvcNAQkEMSIEIFt2+IzDMy+u+oyHDgItWv5c6ZxAgWGTWCIh 8Wu1RKYSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAJP1C/jqjjKuQmtQoW 472RU55YHVWJE0PcVpAKREnNtjp30B/M7NLtTIja9pGFqcNF+YoNyyzXrCEeDn/a8X5qskWF lrEAwsfijXQzPApQHkYcd+3Nzf7B+1NVxFza0NsqRZO1P5s/EEeArJXMJA2IpJuCil6IrPoP yPHsFIKfqB2zezyGCOS9oWSGrXiwjCr0aS9pf1R6Gffn5Imb7WQkJF3VioIuAlhx/GN3qHkM SthHbWFy5aI/yDgWk7Ovqd3kQ5QbhVP/ZLnYh9QXAWnK1OajL/PmjHuk5qQKJP34+Jz8ri0/ iJM9xG8wvk5KYrKYqgXM9ug1CrZEuzdO8TBwAAAAAAAA --------------ms080209050307080609050305-- From nobody Fri Dec 4 06:11:32 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC01A872F for ; Fri, 4 Dec 2015 06:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 U9PnEl_6Fl6H for ; Fri, 4 Dec 2015 06:11:29 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9DD1B31DB for ; Fri, 4 Dec 2015 06:11:27 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id E607B1CF66; Fri, 4 Dec 2015 14:11:25 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 0BC361D29F; Fri, 4 Dec 2015 14:11:22 +0000 (UTC) To: Andrew Findlay References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <56619F0A.8060608@stroeder.com> Date: Fri, 4 Dec 2015 15:11:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20151204134757.GE3643@slab.skills-1st.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040900000007040902080706" Archived-At: Cc: ldapext Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:11:31 -0000 This is a cryptographically signed message in MIME format. --------------ms040900000007040902080706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Str=F6der wrote: >=20 >> 1. Modified standard schema descriptions for 'groupOfNames' and >> 'groupOfUniqueNames': >> >> This is the work-around already chosen by various vendors: >> The MUST member or MUST uniqueMember is turned into MAY. >> >> + it just works, no interop-problems seen so far. >> + no change required in LDAP clients >> + no change required in access control rules >> + no change required in other client or server-side code dealing with = groups >> >> - It violates standardization best practices, most notably IANA consid= erations. >> - It could serve as a bad example to change standard schema at will. >> >> Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IA= NA >> considerations. >=20 > I don't think there is an IANA consideration here. The modified schema > is (currently) incorrect according to RFC4519 or is alternatively an > experiment leading to a proposed change to a standard. In the latter > case it would have to be accepted by IETF and published in a new RFC > that obsoletes 4519. At that time, IANA would update the reference in > the Object Identifiers table to point to the new document but would hav= e > no other involvement. Ok. Do you think that a complete replacement RFC _obsoleting_ RFC 4519 would = be needed? If the ldapext community would agree on changing the standard wo= uldn't a small RFC _updating_ RFC 4519 also be sufficient? > In practice I cannot see such a change ever being accepted into the > standards track. If anything, the relatively wide distribution of > non-conformant implementations makes a stronger case for deprecating > these objectclasses for new deployments. >=20 > The definition of groupOfNames goes right back to X.521(1988) and it wa= s > already broken at that point: >=20 > a) member was a mandatory attribute Hmm, I somewhat disagree here. But maybe I'm just too pragmatic. ;-) > b) Nested groups were mentioned in the text but the semantics > were left undefined Please let us keep the scope limited to the empty-groupOfNames-issue. I'= m not keen on opening the can-of-worms on semantics of nested groups. >> 2. new object class 'groupOfEntries' >> >> Andrew kindly wrote an mini I-D defining a new structural object class= >> 'groupOfEntries' simply with MAY member instead of MUST meant as direc= t >> replacement for 'groupOfNames'. >> >> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries >> >> + Very simple >> + Fully compliant to standardization best practices >> >> - It's not clear whether it was widely adopted in deployments. >=20 > Maybe not in the exact form I described in that I-D, but functionally > equivalent objectclasses have been in most of my customers' systems. > It could be argued that the corrupted form of groupOfNames described > above is actually proof of widespread deployment of an analogous class.= Hmm, the wording gets a bit blurry here. How would you explain the clear distinction between 1. and 2.? Ciao, Michael. --------------ms040900000007040902080706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE0MTEyMlowLwYJKoZIhvcNAQkEMSIEIFLKtcnZzUesU0gXhilDI0+Wp9IeIeY0HYxu 8AX8yDZzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQA8TYvs+9x5RUh8LCMg FjSwAl4UBTYgBYcyoJJrPwxjyDQszt7C4XVFW0yIfapyusbBmzRKojDhVyswSvg9FDkc6O6y hIoiGIn7acUZE3D0/gRVuqZH+63Wk6rr9rnCi32rEDYx3AcgDkGqhYuHIAy0/84WwvtN+pdZ Zo1OhVEzseVp/pMvZB6Z4rw4SU15Vj995qXucucnLJtNoeWmCP76Lmv+heJe5gojTtd2T1EB U0WkVBlM8nK4K36uKmr+E/6o54yTT7DWpt2KZk2iBtmhEvSOiy90ZF1p3LK3Csv1FqDQw9GX tVVnCMnZhlmvuhhBDMQ59u0ceTcZKFygFm/mAAAAAAAA --------------ms040900000007040902080706-- From nobody Fri Dec 4 06:51:56 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69A41A86F2 for ; Fri, 4 Dec 2015 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 kZZUKE9HchvJ for ; Fri, 4 Dec 2015 06:51:53 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF9E1A86F1 for ; Fri, 4 Dec 2015 06:51:52 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 38C151CF66 for ; Fri, 4 Dec 2015 14:51:49 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id D216E1D29F for ; Fri, 4 Dec 2015 14:51:47 +0000 (UTC) To: "'ldapext@ietf.org'" References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> From: =?UTF-8?Q?Michael_Str=c3=b6der?= Message-ID: <5661A883.1050806@stroeder.com> Date: Fri, 4 Dec 2015 15:51:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449019308.9040.38.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000806090908090805080908" Archived-At: Subject: [ldapext] draft-masarati-ldap-deref as ldapext work item? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 14:51:55 -0000 This is a cryptographically signed message in MIME format. --------------ms000806090908090805080908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Simo Sorce wrote: > This is very true and there are products that can cope, there are also > mechanism to more efficiently (at least latency wise) if you use > controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00= >=20 > Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use= > it in various clients. I also consider this control to be very useful and therefore I've added s= upport for it in python-ldap a couple of weeks ago. And since there are already= two independent server implementations it should be easy to bring this I-D to= a ldapext RFC. Not sure whether the original authors are still motivated to work on it. Ciao, Michael. --------------ms000806090908090805080908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE0NTE0N1owLwYJKoZIhvcNAQkEMSIEIJNjJjYGXFUe/p3zGTEP+5OjJXP1HsILAwro VFL0Hy5RMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQA2ZHZYdkJbDeMxMTbM NGAy60to/+UobbS+HwJoAAem+Q7KYSee6FPcXWyGvP+1XVVJvdSx1T7O8MsRE7Y2KsOvv7My Hm50pc5LnjWy61SfspELZFuhNHKFbgysz8g0F0gF3bfh45iNquiz+CLx8DxZ1HkMqFJ8YtKt MdOLgbR1MEqgdA0exZOvl02OcKM6VFQCoSuHBYFS7oHQ9hbAviKQYYKJqv28dP8z6iZNI6Zv Bfik1AVJz2VK3E25hjlz9+hFnDMdk4weHaa3O1yPOrhKOLI6Ad6wuldvK1k1qDemtHIKTtp9 27Acz7tgVrfKPhwOjnbflh+Rn3Bz64hOfJWBAAAAAAAA --------------ms000806090908090805080908-- From nobody Fri Dec 4 07:26:22 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE041A8879 for ; Fri, 4 Dec 2015 07:26:20 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 TZGC3Jpqy4pK for ; Fri, 4 Dec 2015 07:26:18 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A212F1A887B for ; Fri, 4 Dec 2015 07:23:41 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0F48E120498; Fri, 4 Dec 2015 15:23:41 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4FNdM8020576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 10:23:40 -0500 Message-ID: <1449242619.3445.50.camel@redhat.com> From: Simo Sorce To: Jordan Brown Date: Fri, 04 Dec 2015 10:23:39 -0500 In-Reply-To: <5660DF62.5000800@oracle.com> References: <5660DF62.5000800@oracle.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: ldapext Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:26:20 -0000 On Thu, 2015-12-03 at 16:33 -0800, Jordan Brown wrote: > On 12/3/2015 3:12 PM, Charlie wrote: > > After reading David Foster Wallace on set theory, I wrote an RFC a > > couple years back to address the lack of a generic or globally useful > > grouping mechanism in LDAP-accessible directories. Comments are > > welcomed. > > > > http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt > > 3.1. > > Properly, Boy Scout and Scout are capitalized. > > In the general case, I'd say that it's equally correct to say that the list of > Scouts is an attribute of the troop and to say that membership in the troop is an > attribute of the particular Scout. It's an N:M relationship; it can be approached > from either direction. > > (I had not realized until I got to the discussion in D.2 that a mailing list was > best served by member-of attributes. One would think that it would be best served > by a member-list attribute, but you're absolutely correct that using a member-of > attribute reduces the number of queries in the common case.) > > For an indexed database, it's probably OK to represent the relationship in either > direction. For a database that understands the relationship, the relationship > might be visible on both sides and the connection automatically maintained. > > For simpler databases, indeed maintaining "member-of" is probably better, both > because it's convenient for the common queries and because it's probably a smaller > list than the "members" list. > > (But note: it's not at all obvious which variation is better from an access > control standpoint. Is it more likely that you will want to hide the membership > of group X, or the list of groups that user Y is a member of? Presumably if you > want to do either, then you need to ensure that that membership linkage, however > it is presented in the directory, is subject to access control restrictions.) Your points are correct, in fact in our project we do populate memberof automatically based on the member attribute (including unrolling nested relationship for the pain of those that loves non-unrolled memebrofs in AD) but we also prevent access to the memberof attribute to some classes (like unauthenticated guest sessions, etc..). The main issue with dealing with memberof is access control around the "add" operation. ManagerX for GroupX should be able to add any user to its group but shouldn't be able to add users to other groups or random objects. So a naive ACL that allows ManagerX to add memberof attributes to any user won't work. You need an ACL to express the concept that ManagerX can add only memberof attribute where the value is a group on which he is directly (or indirectly via group membership in a manager group) a "manager". (I am looking at 5.5 here now I realized and do not agree with it's optimism :-) Some ACL systems allow this, some do not, I believe a standardized base ACL system (possibly extensible with additional custom allow rules) that is reasonably complete and featured and also *fast* becomes a necessity. 3.3. This is basically hinting at the need to use Role Based Access Control, this is something many systems implement by using a group to represent a Role, and then performing access control and associating permissions to that group. > 3.4. > > Empty sets are also useful in trivial cases, e.g. when creating a set and before > populating, and as a possible intermediate state while adding and removing members. > > 3.5 > > I'm not convinced that "proxy" objects (which you call "dummy" objects) aren't the > right answer. Directly referring to external objects assumes that there's no need > for auxiliary data about those objects. > > (Hmm. Is there a need to describe auxiliary information about a particular > membership relationship? For instance, for a mailing list, might one want to > maintain a count of messages from a particular list to a particular user that have > bounced?) We introduced external members in our schema because we needed to represent members of a foreign realm (which we trust) without being able to replicate information (one way trust incoming only). The only information being IDs transmitted at authentication time. We do not use dummy objects, but we created a proper mechanism to resolve and store these IDs. 4.1 pragmaticSet has a MUST on description, as much as I understand the intent I think it is a mistake, as it will force admins to put trash in there when they do no want to put anything. I think it is better to allow nothing than to pollute the field with trash. As for the pSet being auxiliary, that may be a good idea, but I would also provide an structural class for instances where a pre-existing object is not available, it doesn't have to be a new one, just a recommended to use one. 4.2 the MUST on memberOfPset will make things very hard. This is conceptually the same as forcing a member in groupOfNames. As it forces the removal of the objectclass and all attributes to remove the last memberOfPset, this is really bad. > 4.4 > > I'm not convinced that an undefined "scope" attribute is helpful. > > 4.5 > > psetMembership seems like overkill, though its ability to represent dynamic sets > is interesting. I am no sure caseExactMatch etc are a good match for this object though as attribute names are case insensitive. > 5.3 > > If recursion is always expanded by the client, there's no need for timeouts on > queries to prevent DoS. The clients can decide on their own when to stop recursing. > > C.1, C.2 > > I thought that memberOfPset contained DNs. It is defined with DN sytnax, so the value "drools" also surprised me. > D.5 > > posixGroup has memberUid as a MAY attribute and so *can* represent empty sets. > > > > If you're not up for a long-read, I would recommend just reading > > "Appendix D: Other Efforts and their Shortcomings" which explains all > > the attempts to date and how they've failed to gain traction. > > > > Projects continue to try to solve their individual problems instead of > > working towards a truly generic grouping mechanism that will suit all > > needs, so nothing's progressing. Simo mentioned this in the context > > of FreeIPA, for example - they broke their implementation of RFC2307 > > and moved on, rather than helping Andrew Findlay create a standard > > that supported empty groups. It seems like each of us is focused on > > our own potato patch. > > > > Actually, here in the Solaris Naming organization, mostly our assumption is that > we have to live with whatever the directory gives us, that the directory was > established by the enterprise before we arrived on the scene and so our ability to > influence it is minimal. We might participate in an effort such as this one to try > to nudge the future in a desirable direction, but the assumption is that no one > scheme will ever achieve such dominance that we can ignore the others. Of course > I would be happy to be proven wrong so that we could remove a bunch of flexibility > that's associated with the need to interoperate with such a variety of schemata. Same here, most of our choices in FreeIPA did not come out of a willingness to resolve our own problem only, but due to a number of constrains based on what clients can do today. The ability of pset to dynamically generate atttributes to accomodate legacy service is great but the cost of doing it at query time will simply be impossible to sustain in any moderately sized environment. That is why in FreeIPA we generate atrtributes at add time (we generate both the memberof and the memberUid attributes, plus we have a full "compatibility" tree that re-represents all users with rfc2307 semantics (we primarily user rfc2307bis-like in the main tree. This is done so that these objects are computed once, as LDAP is generally write-seldom, read-often. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 07:28:53 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7971A87CD for ; Fri, 4 Dec 2015 07:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 q7p3r0QAQRsq for ; Fri, 4 Dec 2015 07:28:51 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D6E1A87CE for ; Fri, 4 Dec 2015 07:25:14 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4sER-0006Be-5K; Fri, 04 Dec 2015 15:25:11 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4sEQ-0002YD-Jz; Fri, 04 Dec 2015 15:25:10 +0000 Date: Fri, 4 Dec 2015 15:25:10 +0000 From: Andrew Findlay To: Michael =?iso-8859-1?Q?Str=F6der?= Message-ID: <20151204152510.GG3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <56619F0A.8060608@stroeder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56619F0A.8060608@stroeder.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: ldapext Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:28:53 -0000 On Fri, Dec 04, 2015 at 03:11:22PM +0100, Michael Strder wrote: > Do you think that a complete replacement RFC _obsoleting_ RFC 4519 would be > needed? If the ldapext community would agree on changing the standard wouldn't > a small RFC _updating_ RFC 4519 also be sufficient? That may be possible, but I don't know enough about the conventions to be sure. > Please let us keep the scope limited to the empty-groupOfNames-issue. I'm not > keen on opening the can-of-worms on semantics of nested groups. Indeed. That needs tackling in due course, but it is a much bigger problem. > >> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries > >> > >> + Very simple > >> + Fully compliant to standardization best practices > >> > >> - It's not clear whether it was widely adopted in deployments. > > > > Maybe not in the exact form I described in that I-D, but functionally > > equivalent objectclasses have been in most of my customers' systems. > > It could be argued that the corrupted form of groupOfNames described > > above is actually proof of widespread deployment of an analogous class. > > Hmm, the wording gets a bit blurry here. > How would you explain the clear distinction between 1. and 2.? There are exacly 2 differences between groupOfNames and groupOfEntries: 1) the member attribute is mandatory in groupOfNames but optional in groupOfEntries 2) the name and OID are different In practical terms, groupOfEntries is better because it allows for empty groups. The benefits are: a) Empty groups are reasonable things to have: the need for a group does not disappear just because there are no current members. b) Forcing groups to always contain at least one entry causes management systems to do silly things like adding an entry for a non-existent member or even making the group recursively a member of itself. These workarounds for the broken definition can cause security problems as well as just being awkward. There is no defined convention for doing this, so identifying the dummy member can be difficult. If several management systems can modify the same entry it is possible that it will accumulate several dummy members. Changing the existing groupOfNames to make member an optional attribute does not solve the problem: p) Existing management systems will continue to add dummy members but new ones will not know what to do about such values. q) New management systems will have to check the schema definition to find out whether member is mandatory or not. In effect, groupOfNames has been corrupted and is no longer a portable objectclass. On the other hand, the corrupt version of groupOfNames does serve as a proof that groupOfEntries is desired by the community because it is functionally identical. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 07:36:32 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295781A87B2 for ; Fri, 4 Dec 2015 07:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 1-M-0Fr9v813 for ; Fri, 4 Dec 2015 07:36:29 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43171A87AB for ; Fri, 4 Dec 2015 07:36:28 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 255F91CF66; Fri, 4 Dec 2015 15:36:26 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 47F0B1D29F; Fri, 4 Dec 2015 15:36:26 +0000 (UTC) To: Simo Sorce References: <5660DF62.5000800@oracle.com> <1449242619.3445.50.camel@redhat.com> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661B2FA.2020204@stroeder.com> Date: Fri, 4 Dec 2015 16:36:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449242619.3445.50.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040606010505090102000501" Archived-At: Cc: ldapext Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:36:31 -0000 This is a cryptographically signed message in MIME format. --------------ms040606010505090102000501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Simo Sorce wrote: > in fact in our project we do populate memberof > automatically based on the member attribute (including unrolling nested= > relationship for the pain of those that loves non-unrolled memebrofs in= > AD) but we also prevent access to the memberof attribute to some classe= s > (like unauthenticated guest sessions, etc..). But it was a fault to take the very same OID and NAME for that attribute = like 'memberOf' in MS AD because the semantics are different there (no nested = groups referenced). > The main issue with dealing with memberof is access control around the > "add" operation. Yupp. Needs value-based access control. Does 389-DS provide ACIs like thi= s? Ciao, Michael. --------------ms040606010505090102000501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE1MzYyNlowLwYJKoZIhvcNAQkEMSIEIBTjZAoHciwDPT94D2XAN/sVTxl0dV1fGzgS 0n76b3SUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAYONytcb0yOqyuwhtk AHwzE2s/ioqNaj5Uf5BhXhtwZIP3YVH8Yfx0Pv9QHoqWIdTi/odwLcY2yfhjNhjunDT7e48t 5IfpZEME5jPTpMjFXs7+lday8W7MWw4Et+vxPvYi4wMXL4LvUiHyLBIKpDj2Lq1RCs8TPpD6 4lSSdGuga+CVKLiD2R0uilj3q8evAldIwH8fvPYlAcYy4maOG2ObaSvm8EyEBGq6fG6rzBwr MjQtZCIdpElXlloqIL4c1IMLhcJV7JFZkFYKYhotxA1unVrl1pedHBs1HOHGMd4F87VBDwph NrRXWckq0RMBrWfPjhetjp5eCd0G6sLEhK1sAAAAAAAA --------------ms040606010505090102000501-- From nobody Fri Dec 4 07:40:19 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27131A8855 for ; Fri, 4 Dec 2015 07:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 T6dSF--0wm0F for ; Fri, 4 Dec 2015 07:40:13 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12F01A87F1 for ; Fri, 4 Dec 2015 07:40:12 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4FE478F28A; Fri, 4 Dec 2015 15:40:12 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4FeAOs006204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 10:40:11 -0500 Message-ID: <1449243610.3445.58.camel@redhat.com> From: Simo Sorce To: Michael =?ISO-8859-1?Q?Str=F6der?= Date: Fri, 04 Dec 2015 10:40:10 -0500 In-Reply-To: <56619C8C.1010805@stroeder.com> References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: LDAP Extensions list , Andrew Findlay Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:40:18 -0000 On Fri, 2015-12-04 at 15:00 +0100, Michael Ströder wrote: > Andrew Findlay wrote: > > We are not going to define a standard that forces everyone to do everything > > 'right' while providing interworking of differing systems. It is simply > > not possible. > > That perfectly summarizes this topic. > Thanks Andrew, for this clear statement. > > Let's keep the scope right. > > > Overall I think we are heading for something like this: > > > > 1) Usernames and groupnames should have caseIgnoreMatch syntax > > > > 2) Usernames and groupnames should preferably be stored in lower-case in > > cultures where that has meaning. Remember that LDAP is case-preserving > > even for case-insensitive attributes. > > > > 3) Systems that are internally case-sensitive should take extra care > > when using data from LDAP. > > > > I know this conflicts with Mark's wish to be able to import existing > > NIS data unchanged to cope with weird existing situations, but I see that > > as a special case that may be better handled in another way. > > +1 !!! > > (That's pretty much exactly what I planned to suggest.) > > > Note that the above discussion *only* applies to usernames and groupnames. > > Unix-specific mappings such as automount maps are a different issue. > > automount maps are maybe a similar topic like generating 'homeDirectory' values > for $HOME on case-sensitive file-systems based on user names. For this > RECOMMENDing that usernames are normalized to lower-case is really helpful. This is exactly what we did in FreeIPA too, we automatically convert the user name entered in lower case. We have no issues with "uncertain rules" about casefolding because we restricted the valid charset to Unicode and within unicode casfolding *to* lower case is not ambiguous and part of the standard. I think we further limit the interface to "Western charset" (read printable ASCII chars), but that is a restriction we can and will relax at some point. > Regarding service names: > > (Personally I never saw any customer LDAP deployment storing a services map.) > > 1. Service names are used in DNS RRs (SRV, DANE, etc.) and those DNS labels are > definitely supposed to be treated case-insensitive. There are odd things in the wild, so you need to be at least case-preserving, both for user names and services. > 2. Jordan pointed out RFC 6335. > > => I concur with Jordan: Service names MUST be treated case-insensitive. > Probably recommending in an implementation note to normalize values to > lower-case seems also to be a good idea. > > => People actually using case-sensitive service names to address *different* > services MUST clean up their local mess. But they likely have to do that anyway. ACK, maintaining broken systems may seem the only way for some organizations due to the daunting task and inter-dependencies that makes a clean up really hard. I have personally witnessed herculean efforts to migrate several hundreds diverged NIS domains into a single directory, and it ain't pretty. Especially if you have terabytes of data and numerous files with permissions to deal with. But the problem has always mostly been on uidNumber and gidNumber consolidation, usually name-mismatches have been mush easier to deal with because it is easy to remap usernames locally. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 07:45:19 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7B41A887F for ; Fri, 4 Dec 2015 07:45:17 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 rc6_-AlguCNV for ; Fri, 4 Dec 2015 07:45:16 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25401A882A for ; Fri, 4 Dec 2015 07:44:49 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 7348BC07754F; Fri, 4 Dec 2015 15:44:49 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4Filx2022161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 10:44:48 -0500 Message-ID: <1449243887.3445.59.camel@redhat.com> From: Simo Sorce To: Andrew Findlay Date: Fri, 04 Dec 2015 10:44:47 -0500 In-Reply-To: <20151204134757.GE3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: ldapext , Michael =?ISO-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:45:17 -0000 On Fri, 2015-12-04 at 13:47 +0000, Andrew Findlay wrote: > On Fri, Dec 04, 2015 at 12:17:49PM +0100, Michael Ströder wrote: > > > 1. Modified standard schema descriptions for 'groupOfNames' and > > 'groupOfUniqueNames': > > > > This is the work-around already chosen by various vendors: > > The MUST member or MUST uniqueMember is turned into MAY. > > > > + it just works, no interop-problems seen so far. > > + no change required in LDAP clients > > + no change required in access control rules > > + no change required in other client or server-side code dealing with groups > > > > - It violates standardization best practices, most notably IANA considerations. > > - It could serve as a bad example to change standard schema at will. > > > > Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA > > considerations. > > I don't think there is an IANA consideration here. The modified schema > is (currently) incorrect according to RFC4519 or is alternatively an > experiment leading to a proposed change to a standard. In the latter > case it would have to be accepted by IETF and published in a new RFC > that obsoletes 4519. At that time, IANA would update the reference in > the Object Identifiers table to point to the new document but would have > no other involvement. > > In practice I cannot see such a change ever being accepted into the > standards track. If anything, the relatively wide distribution of > non-conformant implementations makes a stronger case for deprecating > these objectclasses for new deployments. > > The definition of groupOfNames goes right back to X.521(1988) and it was > already broken at that point: > > a) member was a mandatory attribute > > b) Nested groups were mentioned in the text but the semantics > were left undefined > > > ------------------------------------------------------------------------- > > > > 2. new object class 'groupOfEntries' > > > > Andrew kindly wrote an mini I-D defining a new structural object class > > 'groupOfEntries' simply with MAY member instead of MUST meant as direct > > replacement for 'groupOfNames'. > > > > http://tools.ietf.org/html/draft-findlay-ldap-groupofentries > > > > + Very simple > > + Fully compliant to standardization best practices > > > > - It's not clear whether it was widely adopted in deployments. > > Maybe not in the exact form I described in that I-D, but functionally > equivalent objectclasses have been in most of my customers' systems. > It could be argued that the corrupted form of groupOfNames described > above is actually proof of widespread deployment of an analogous class. My 2c: An auxiliary class may be a better choice for a standard. > > - small change required in LDAP clients for searching group entries > > - small change required in access control rules > > - small changes required in other client or server-side code dealing with groups > > Andrew -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 07:56:51 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38731A88CB for ; Fri, 4 Dec 2015 07:56:49 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 F9DTZdP-EA1v for ; Fri, 4 Dec 2015 07:56:48 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F157F1A88CF for ; Fri, 4 Dec 2015 07:56:46 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 8DEC447D5; Fri, 4 Dec 2015 15:56:46 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4Fui64031257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 10:56:45 -0500 Message-ID: <1449244604.3445.65.camel@redhat.com> From: Simo Sorce To: Andrew Findlay Date: Fri, 04 Dec 2015 10:56:44 -0500 In-Reply-To: <20151204152510.GG3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <56619F0A.8060608@stroeder.com> <20151204152510.GG3643@slab.skills-1st.co.uk> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: ldapext , Michael =?ISO-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:56:50 -0000 On Fri, 2015-12-04 at 15:25 +0000, Andrew Findlay wrote: > On Fri, Dec 04, 2015 at 03:11:22PM +0100, Michael Ströder wrote: > > > Do you think that a complete replacement RFC _obsoleting_ RFC 4519 would be > > needed? If the ldapext community would agree on changing the standard wouldn't > > a small RFC _updating_ RFC 4519 also be sufficient? > > That may be possible, but I don't know enough about the conventions to > be sure. > > > Please let us keep the scope limited to the empty-groupOfNames-issue. I'm not > > keen on opening the can-of-worms on semantics of nested groups. > > Indeed. That needs tackling in due course, but it is a much bigger problem. > > > >> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries > > >> > > >> + Very simple > > >> + Fully compliant to standardization best practices > > >> > > >> - It's not clear whether it was widely adopted in deployments. > > > > > > Maybe not in the exact form I described in that I-D, but functionally > > > equivalent objectclasses have been in most of my customers' systems. > > > It could be argued that the corrupted form of groupOfNames described > > > above is actually proof of widespread deployment of an analogous class. > > > > Hmm, the wording gets a bit blurry here. > > How would you explain the clear distinction between 1. and 2.? > > There are exacly 2 differences between groupOfNames and groupOfEntries: > > 1) the member attribute is mandatory in groupOfNames but > optional in groupOfEntries > > 2) the name and OID are different > > In practical terms, groupOfEntries is better because it allows for > empty groups. The benefits are: > > a) Empty groups are reasonable things to have: the need for a group > does not disappear just because there are no current members. > > b) Forcing groups to always contain at least one entry causes > management systems to do silly things like adding an entry for > a non-existent member or even making the group recursively a > member of itself. These workarounds for the broken definition > can cause security problems as well as just being awkward. > There is no defined convention for doing this, so identifying > the dummy member can be difficult. If several management systems > can modify the same entry it is possible that it will accumulate > several dummy members. > > Changing the existing groupOfNames to make member an optional attribute > does not solve the problem: > > p) Existing management systems will continue to add dummy members > but new ones will not know what to do about such values. > > q) New management systems will have to check the schema definition > to find out whether member is mandatory or not. > > In effect, groupOfNames has been corrupted and is no longer a portable > objectclass. I do not agree with this conclusion. Realxing the constraint from MUST to MAY is forward compatible, and older tools can keep doing what they always did. Given there is no provision in the old or new groupOfNames to have members that "make sense", software always need to be prepared to deal with bogus members, so p) is not a "problem to solve". You may have a point with q) if you want to deal with a generic management system, but then your proposal to create a new objectlcass adds exactly the same problem, as the management system need to know what to use, except it makes it worse in 2 ways: 1) you have no way to find out what to do just by inspecting the schema because both classes may be in the schema, which do you choose ? 2) you have to change all client applications that are hardcoded to use groupOfNames Looking at 1) and 2) then q) is a comparatively little price to pay. > On the other hand, the corrupt version of groupOfNames does serve as > a proof that groupOfEntries is desired by the community because it is > functionally identical. Yet it is not identical, see 2) above. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 07:58:03 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CC11A88DE for ; Fri, 4 Dec 2015 07:58:02 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 4bwKBN3DW6mU for ; Fri, 4 Dec 2015 07:58:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910581A88D2 for ; Fri, 4 Dec 2015 07:58:00 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 59CE0C0CC62C; Fri, 4 Dec 2015 15:58:00 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4FvwwX021240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 10:57:59 -0500 Message-ID: <1449244678.3445.66.camel@redhat.com> From: Simo Sorce To: Andrew Findlay Date: Fri, 04 Dec 2015 10:57:58 -0500 In-Reply-To: <1449244604.3445.65.camel@redhat.com> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <56619F0A.8060608@stroeder.com> <20151204152510.GG3643@slab.skills-1st.co.uk> <1449244604.3445.65.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: ldapext , Michael =?ISO-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 15:58:02 -0000 On Fri, 2015-12-04 at 10:56 -0500, Simo Sorce wrote: > On Fri, 2015-12-04 at 15:25 +0000, Andrew Findlay wrote: > > On Fri, Dec 04, 2015 at 03:11:22PM +0100, Michael Ströder wrote: > > > > > Do you think that a complete replacement RFC _obsoleting_ RFC 4519 would be > > > needed? If the ldapext community would agree on changing the standard wouldn't > > > a small RFC _updating_ RFC 4519 also be sufficient? > > > > That may be possible, but I don't know enough about the conventions to > > be sure. > > > > > Please let us keep the scope limited to the empty-groupOfNames-issue. I'm not > > > keen on opening the can-of-worms on semantics of nested groups. > > > > Indeed. That needs tackling in due course, but it is a much bigger problem. > > > > > >> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries > > > >> > > > >> + Very simple > > > >> + Fully compliant to standardization best practices > > > >> > > > >> - It's not clear whether it was widely adopted in deployments. > > > > > > > > Maybe not in the exact form I described in that I-D, but functionally > > > > equivalent objectclasses have been in most of my customers' systems. > > > > It could be argued that the corrupted form of groupOfNames described > > > > above is actually proof of widespread deployment of an analogous class. > > > > > > Hmm, the wording gets a bit blurry here. > > > How would you explain the clear distinction between 1. and 2.? > > > > There are exacly 2 differences between groupOfNames and groupOfEntries: > > > > 1) the member attribute is mandatory in groupOfNames but > > optional in groupOfEntries > > > > 2) the name and OID are different > > > > In practical terms, groupOfEntries is better because it allows for > > empty groups. The benefits are: > > > > a) Empty groups are reasonable things to have: the need for a group > > does not disappear just because there are no current members. > > > > b) Forcing groups to always contain at least one entry causes > > management systems to do silly things like adding an entry for > > a non-existent member or even making the group recursively a > > member of itself. These workarounds for the broken definition > > can cause security problems as well as just being awkward. > > There is no defined convention for doing this, so identifying > > the dummy member can be difficult. If several management systems > > can modify the same entry it is possible that it will accumulate > > several dummy members. > > > > Changing the existing groupOfNames to make member an optional attribute > > does not solve the problem: > > > > p) Existing management systems will continue to add dummy members > > but new ones will not know what to do about such values. > > > > q) New management systems will have to check the schema definition > > to find out whether member is mandatory or not. > > > > In effect, groupOfNames has been corrupted and is no longer a portable > > objectclass. > > I do not agree with this conclusion. > Realxing the constraint from MUST to MAY is forward compatible, and > older tools can keep doing what they always did. > > Given there is no provision in the old or new groupOfNames to have > members that "make sense", software always need to be prepared to deal > with bogus members, so p) is not a "problem to solve". > > You may have a point with q) if you want to deal with a generic > management system, but then your proposal to create a new objectlcass > adds exactly the same problem, as the management system need to know > what to use, except it makes it worse in 2 ways: > 1) you have no way to find out what to do just by inspecting the schema > because both classes may be in the schema, which do you choose ? > 2) you have to change all client applications that are hardcoded to use > groupOfNames > > Looking at 1) and 2) then q) is a comparatively little price to pay. > > > On the other hand, the corrupt version of groupOfNames does serve as > > a proof that groupOfEntries is desired by the community because it is > > functionally identical. > > Yet it is not identical, see 2) above. Just to be clear, I am not against groupOfEntries and necessarily in favor of changing groupOfNames (although I did in our implementation), I just wanted to express dissent on the conclusions you drew. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 08:04:27 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02861A8908 for ; Fri, 4 Dec 2015 08:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 K0A2sGS2K8i1 for ; Fri, 4 Dec 2015 08:04:25 -0800 (PST) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by ietfa.amsl.com (Postfix) with ESMTP id BD48E1A88F5 for ; Fri, 4 Dec 2015 08:04:25 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id E310F83EF9; Fri, 4 Dec 2015 11:04:24 -0500 (EST) To: =?UTF-8?Q?Michael_Str=c3=b6der?= , "'ldapext@ietf.org'" References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <5661A883.1050806@stroeder.com> From: Howard Chu Message-ID: <5661B981.2000808@highlandsun.com> Date: Fri, 4 Dec 2015 16:04:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: <5661A883.1050806@stroeder.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ldapext] draft-masarati-ldap-deref as ldapext work item? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:04:26 -0000 Michael Ströder wrote: > Simo Sorce wrote: >> This is very true and there are products that can cope, there are also >> mechanism to more efficiently (at least latency wise) if you use >> controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00 >> >> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use >> it in various clients. > > I also consider this control to be very useful and therefore I've added support > for it in python-ldap a couple of weeks ago. And since there are already two > independent server implementations it should be easy to bring this I-D to a > ldapext RFC. > > Not sure whether the original authors are still motivated to work on it. I proposed this control to satisfy a need in supporting SAMBA / AD-compatibility in OpenLDAP. Symas is still actively engaged in implementing ActiveDirectory functionality in OpenLDAP, so yes, we are still committed to this particular item. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From nobody Fri Dec 4 08:04:57 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65151A88A3 for ; Fri, 4 Dec 2015 08:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 Ml1tPmzN_oH2 for ; Fri, 4 Dec 2015 08:04:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98ADD1A8824 for ; Fri, 4 Dec 2015 08:04:54 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 374E291346; Fri, 4 Dec 2015 16:04:54 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4G4qEC027171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 11:04:53 -0500 Message-ID: <1449245092.3445.71.camel@redhat.com> From: Simo Sorce To: Michael =?ISO-8859-1?Q?Str=F6der?= Date: Fri, 04 Dec 2015 11:04:52 -0500 In-Reply-To: <5661B2FA.2020204@stroeder.com> References: <5660DF62.5000800@oracle.com> <1449242619.3445.50.camel@redhat.com> <5661B2FA.2020204@stroeder.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: ldapext Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:04:55 -0000 On Fri, 2015-12-04 at 16:36 +0100, Michael Ströder wrote: > Simo Sorce wrote: > > in fact in our project we do populate memberof > > automatically based on the member attribute (including unrolling nested > > relationship for the pain of those that loves non-unrolled memebrofs in > > AD) but we also prevent access to the memberof attribute to some classes > > (like unauthenticated guest sessions, etc..). > > But it was a fault to take the very same OID and NAME for that attribute like > 'memberOf' in MS AD because the semantics are different there (no nested groups > referenced). I think fault or not is a matter of perspective, we do use this attribute for members of a group, as the description says. But yeah it behaves in a slightly different way than AD does and in retrospect we may have used 2 separate attributes. > > The main issue with dealing with memberof is access control around the > > "add" operation. > > Yupp. Needs value-based access control. Does 389-DS provide ACIs like this? Yes, it actually does, but we do not allow to modify the memberof attributes directly, we consider it an operational attribute (although not marked as operational :-) which is always set through an operation on the member attribute of the target group. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 08:06:34 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C941A88EA for ; Fri, 4 Dec 2015 08:06:32 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 fiaWaLyGgt66 for ; Fri, 4 Dec 2015 08:06:31 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514CF1A8908 for ; Fri, 4 Dec 2015 08:06:31 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 17B3596EE; Fri, 4 Dec 2015 16:06:31 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4G6T5F005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 11:06:30 -0500 Message-ID: <1449245189.3445.72.camel@redhat.com> From: Simo Sorce To: Howard Chu Date: Fri, 04 Dec 2015 11:06:29 -0500 In-Reply-To: <5661B981.2000808@highlandsun.com> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <5661A883.1050806@stroeder.com> <5661B981.2000808@highlandsun.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "'ldapext@ietf.org'" , Michael =?ISO-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] draft-masarati-ldap-deref as ldapext work item? X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:06:32 -0000 On Fri, 2015-12-04 at 16:04 +0000, Howard Chu wrote: > Michael Ströder wrote: > > Simo Sorce wrote: > >> This is very true and there are products that can cope, there are also > >> mechanism to more efficiently (at least latency wise) if you use > >> controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00 > >> > >> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use > >> it in various clients. > > > > I also consider this control to be very useful and therefore I've added support > > for it in python-ldap a couple of weeks ago. And since there are already two > > independent server implementations it should be easy to bring this I-D to a > > ldapext RFC. > > > > Not sure whether the original authors are still motivated to work on it. > > I proposed this control to satisfy a need in supporting SAMBA / > AD-compatibility in OpenLDAP. Symas is still actively engaged in implementing > ActiveDirectory functionality in OpenLDAP, so yes, we are still committed to > this particular item. At this point we are dependent on this control in FreeIPA (as well as our Samba work) so I will gladly volunteer to work on it if needed. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 08:34:37 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AD1A902D for ; Fri, 4 Dec 2015 08:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oVI-OQxJgA0P for ; Fri, 4 Dec 2015 08:34:34 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A271A8AAE for ; Fri, 4 Dec 2015 08:34:33 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4tJW-0006rN-6N; Fri, 04 Dec 2015 16:34:30 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4tJV-0002bh-MH; Fri, 04 Dec 2015 16:34:29 +0000 Date: Fri, 4 Dec 2015 16:34:29 +0000 From: Andrew Findlay To: Simo Sorce Message-ID: <20151204163429.GI3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <1449243887.3445.59.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449243887.3445.59.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: ldapext , Michael =?iso-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:34:35 -0000 On Fri, Dec 04, 2015 at 10:44:47AM -0500, Simo Sorce wrote: > An auxiliary class may be a better choice for a standard. Yes: I also prefer to define aux classes where possible. groupOfEntries was defined STRUCTURAL to make it a drop-in replacement for groupOfNames. If we were starting from a clean slate we might just define: ( 1.2.826.0.1.3458854.2.1.1.666 NAME 'membershipObject' SUP top AUXILIARY MAY ( member ) ) and allow designers to apply it to any appropriate structural class. Following that to its logical conclusion would give almost 1:1 correspondence between objectclasses and attributetypes, which most would probably regard as over-normalisation! In fact I think groups are very reasonable STRUCTURAL objects, as the concept of groups has such broad application. Where I might argue with the current definition of groupOfNames/groupOfEntries is the list of other descriptive attributes (why should groups have a businessCategory but no displayName for example?) Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 08:47:13 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD14B1A8989 for ; Fri, 4 Dec 2015 08:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 m7abNq3V1LHt for ; Fri, 4 Dec 2015 08:47:10 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E511A8903 for ; Fri, 4 Dec 2015 08:47:09 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id E81711CF66; Fri, 4 Dec 2015 16:47:06 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id A66581D29F; Fri, 4 Dec 2015 16:47:05 +0000 (UTC) To: Simo Sorce , Andrew Findlay References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <56619F0A.8060608@stroeder.com> <20151204152510.GG3643@slab.skills-1st.co.uk> <1449244604.3445.65.camel@redhat.com> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661C388.3090403@stroeder.com> Date: Fri, 4 Dec 2015 17:47:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449244604.3445.65.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060805090709060007090103" Archived-At: Cc: ldapext Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:47:11 -0000 This is a cryptographically signed message in MIME format. --------------ms060805090709060007090103 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo Sorce wrote: > I do not agree with this conclusion. > Realxing the constraint from MUST to MAY is forward compatible, and > older tools can keep doing what they always did. >=20 > Given there is no provision in the old or new groupOfNames to have > members that "make sense", software always need to be prepared to deal > with bogus members, so p) is not a "problem to solve". >=20 > You may have a point with q) if you want to deal with a generic > management system, but then your proposal to create a new objectlcass > adds exactly the same problem, as the management system need to know > what to use, except it makes it worse in 2 ways: > 1) you have no way to find out what to do just by inspecting the schema= > because both classes may be in the schema, which do you choose ? > 2) you have to change all client applications that are hardcoded to use= > groupOfNames >=20 > Looking at 1) and 2) then q) is a comparatively little price to pay. >=20 >> On the other hand, the corrupt version of groupOfNames does serve as >> a proof that groupOfEntries is desired by the community because it is >> functionally identical. >=20 > Yet it is not identical, see 2) above. I concur with Simo: The issues are almost non-issues because applications= already have to deal with the non-standard variants today. Also in practice I see much less client applications capable to properly = add dummy 'member' values, and if they do you have to explicitly configure it= anyway. The only soft issue is that changing 'groupOfNames', after careful considerations of course, could be abused as an example to request more quick&dirty changes in standardized schema (probably without careful considerations). Ciao, Michael. --------------ms060805090709060007090103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE2NDcwNFowLwYJKoZIhvcNAQkEMSIEIIRNDSfoWVuiuwzcWlD/O0lKlMvmVE2TF7lt tXK9J/bfMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBmKCnCpPMvMsXtUexH PBln5Rjd2Ll3Tc/hKEcceODCfhl0+L6DH+LCx+uJ+nKOxVAlpdpuItD1YNetSuu0b+T+U950 0RpoRq6QZ+lfaKaKysu2utNbdkk1zL/YoUgVDslqHo1BIGjrNXiv+5/FiwpAnYOd4kXyNNq7 uSameZfnrZHaSto4CcheGg7Q/ooiuEdkYSKachJeT6OKYFEJKHN+iVrpsi9ljqWsgza042Ku irfI52AhDgaBCH0sxryZVLnLjXukqrfkEvO6mSfkP/9RB5KrfeG9jSbn+7Ynf+SpNN2Cc5s1 iKKWN7PfGLeJF6Fl9Qq7xVnTPocVcp3ieKTOAAAAAAAA --------------ms060805090709060007090103-- From nobody Fri Dec 4 08:55:41 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACB61A8A3F for ; Fri, 4 Dec 2015 08:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 ajYwoaAsmPMy for ; Fri, 4 Dec 2015 08:55:37 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE5C1A8A25 for ; Fri, 4 Dec 2015 08:55:33 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id A41A31CF66; Fri, 4 Dec 2015 16:55:31 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 8BC641D29F; Fri, 4 Dec 2015 16:55:30 +0000 (UTC) To: Andrew Findlay , Simo Sorce References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <1449243887.3445.59.camel@redhat.com> <20151204163429.GI3643@slab.skills-1st.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661C581.7020900@stroeder.com> Date: Fri, 4 Dec 2015 17:55:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20151204163429.GI3643@slab.skills-1st.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050902050008040400050909" Archived-At: Cc: ldapext Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:55:39 -0000 This is a cryptographically signed message in MIME format. --------------ms050902050008040400050909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > On Fri, Dec 04, 2015 at 10:44:47AM -0500, Simo Sorce wrote: >=20 >> An auxiliary class may be a better choice for a standard. >=20 > Yes: I also prefer to define aux classes where possible. Note that DIT content rules (DCRs), DIT structure rules and name forms ca= n only be defined for structural object classes. =3D> I prefer to have a structural object class for group entries. With those rules you can define a local profile for structural object cla= sses. E.g. I make heavy use of DCRs with NOT to prevent lazy people from abusin= g attributes for any blurb breaking semantics. Having said this: If we change the structural object class 'groupOfNames' to MAY member, backward-compability can be easily achieved by locally adding MUST member= to a accompanying DIT content rule (on LDAP servers supporting DCRs). :-) Ciao, Michael. --------------ms050902050008040400050909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE2NTUyOVowLwYJKoZIhvcNAQkEMSIEILT/+ajgq8A08as0w/OIMnspVW3yt6gHHIFi l3giijGYMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBj16XuerTZRNuklFEj bo8qF9Q2JoQZYr+n1d1pSRZExteJfqxBC0fJxMpGxOvY754Mnma9Ff+4nTtPj0fpi/dPtOGX 2bUHuJzutG+dM2W5ySqjoBtCXaC4ylFSKucX0qDIXfU2vOBXVeyq79pLaCDYX6Ty6MNDmM8/ kXfLyUbliz3birH0OcJDPmkpwySfhON9zaMOy+xrFkluF86xfgsOQQ5QXD4o129BLp3D2M2R u+AZC9R1o+noXcu+VQusznZH3zfDFFDrQfIO5FjZMsJmgTRxfjxZVwl7Ig2CEHpekkDF+2RM +YP9UW52yH5nxJKF6grY2nx7vK4Vt9DyFwWiAAAAAAAA --------------ms050902050008040400050909-- From nobody Fri Dec 4 08:56:35 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32321A8A3F for ; Fri, 4 Dec 2015 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MlbLAVsVyJQe for ; Fri, 4 Dec 2015 08:56:32 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304421A8A3A for ; Fri, 4 Dec 2015 08:56:32 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4teo-00076C-FH; Fri, 04 Dec 2015 16:56:30 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4ten-0002d9-W2; Fri, 04 Dec 2015 16:56:29 +0000 Date: Fri, 4 Dec 2015 16:56:29 +0000 From: Andrew Findlay To: Simo Sorce Message-ID: <20151204165629.GJ3643@slab.skills-1st.co.uk> References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449243610.3445.58.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: LDAP Extensions list , Michael =?iso-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:56:34 -0000 On Fri, Dec 04, 2015 at 10:40:10AM -0500, Simo Sorce wrote: > There are odd things in the wild, so you need to be at least > case-preserving, both for user names and services. One idea that I did not put in the summary as it is a bit of a side-issue: Client systems that care about case-sensitivity might be given a config option to use extensible matching: ldapsearch -x '(&objectclass=posixAccount)(uid:caseExactMatch:=BABS))' ldapsearch -x '(&objectclass=posixAccount)(uid:caseExactMatch:=babs))' It would then be possible to have two entries where the uid differs only in case provided uid is not used as the RDN attribute. This SHOULD prevent either user from logging in on systems that are not using the search shown above, as the result of a normal search on uid would be ambiguous. Data management would require great care. > ACK, maintaining broken systems may seem the only way for some > organizations due to the daunting task and inter-dependencies that makes > a clean up really hard. I have personally witnessed herculean efforts to > migrate several hundreds diverged NIS domains into a single directory, > and it ain't pretty. Especially if you have terabytes of data and > numerous files with permissions to deal with. But the problem has always > mostly been on uidNumber and gidNumber consolidation, usually > name-mismatches have been mush easier to deal with because it is easy to > remap usernames locally. People are often tempted to build complex technical solutions because that is within their control and ability. It is almost always better in the long run to fix the organisational issues and migrate to a clean(er) set of data using a simpler technical setup. Anyone can make an existing system more complex. It takes effort and clear vision to make it simpler. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 08:59:11 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808021A8A57 for ; Fri, 4 Dec 2015 08:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 a13EgJT5pS-g for ; Fri, 4 Dec 2015 08:59:08 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A3E1A8A4F for ; Fri, 4 Dec 2015 08:59:08 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 95C301CF66; Fri, 4 Dec 2015 16:59:06 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id B79AB1D29F; Fri, 4 Dec 2015 16:59:05 +0000 (UTC) To: Simo Sorce References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661C659.5050804@stroeder.com> Date: Fri, 4 Dec 2015 17:59:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <1449243610.3445.58.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030406040705020208020607" Archived-At: Cc: LDAP Extensions list Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 16:59:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030406040705020208020607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Simo Sorce wrote: > On Fri, 2015-12-04 at 15:00 +0100, Michael Str=C3=B6der wrote: >> Regarding service names: >> >> (Personally I never saw any customer LDAP deployment storing a service= s map.) >> >> 1. Service names are used in DNS RRs (SRV, DANE, etc.) and those DNS l= abels are >> definitely supposed to be treated case-insensitive. >=20 > There are odd things in the wild, so you need to be at least > case-preserving, both for user names and services. I concur with case-preserving. But EQUALITY matching rule (which also en= forces uniqueness) should be case-insensitive. >> 2. Jordan pointed out RFC 6335. >> >> =3D> I concur with Jordan: Service names MUST be treated case-insensit= ive. >> Probably recommending in an implementation note to normalize values to= >> lower-case seems also to be a good idea. >> >> =3D> People actually using case-sensitive service names to address *di= fferent* >> services MUST clean up their local mess. But they likely have to do th= at anyway. >=20 > ACK, maintaining broken systems may seem the only way for some > organizations due to the daunting task and inter-dependencies that make= s > a clean up really hard. I have personally witnessed herculean efforts t= o > migrate several hundreds diverged NIS domains into a single directory, > and it ain't pretty. Especially if you have terabytes of data and > numerous files with permissions to deal with. But the problem has alway= s > mostly been on uidNumber and gidNumber consolidation, usually > name-mismatches have been mush easier to deal with because it is easy t= o > remap usernames locally. In those cases I tend to recommend to simply keep different LDAP server d= eployments. Ciao, Michael. --------------ms030406040705020208020607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDE2NTkwNVowLwYJKoZIhvcNAQkEMSIEIKr955/YLIMGmkhkQKW+NdKe/htSJq0SmQeu WosLwGY+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAUyPSHnE9t64C/7Izr xsWRgxlPci7Gu/DsK2JvIntvd7NASPfks9LBSxmTSLNMn2APmji3fALbNoq2C8REY1QTI9a4 x9z53n7E4OuA0kTk9FbeQ9Z3FkpNGVQSudTaKmB+FrRNHS+1y6qJpqYG+V4cCRAD3tqzekaU lynokVy4HT/lj9lvXVk8/JBuOSRlW5ilMR23XWt21BGzeRrDlqhIzab45JqA0WD1ZoofrQVI 9AwFbCdcw4ZGRuknX7OFXEKlw0oZSw7J0pNQS0w+w9BCIs6con2ebiVWl0ZpGf74EjrYfMNB YcRA5eOcg1eGI1BZzH26GEKfXoXNrAlq+sBNAAAAAAAA --------------ms030406040705020208020607-- From nobody Fri Dec 4 09:23:00 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D37B1A8AEF for ; Fri, 4 Dec 2015 09:23:00 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 abFrnT-h8NDw for ; Fri, 4 Dec 2015 09:22:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8BE1A8AE7 for ; Fri, 4 Dec 2015 09:22:58 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 4D77E4C524; Fri, 4 Dec 2015 17:22:58 +0000 (UTC) Received: from willson.usersys.redhat.com ([10.3.113.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB4HMue9032518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2015 12:22:57 -0500 Message-ID: <1449249776.3445.78.camel@redhat.com> From: Simo Sorce To: Andrew Findlay Date: Fri, 04 Dec 2015 12:22:56 -0500 In-Reply-To: <20151204163429.GI3643@slab.skills-1st.co.uk> References: <5661765D.6040603@stroeder.com> <20151204134757.GE3643@slab.skills-1st.co.uk> <1449243887.3445.59.camel@redhat.com> <20151204163429.GI3643@slab.skills-1st.co.uk> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: ldapext , Michael =?ISO-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 17:23:00 -0000 On Fri, 2015-12-04 at 16:34 +0000, Andrew Findlay wrote: > On Fri, Dec 04, 2015 at 10:44:47AM -0500, Simo Sorce wrote: > > > An auxiliary class may be a better choice for a standard. > > Yes: I also prefer to define aux classes where possible. > groupOfEntries was defined STRUCTURAL to make it a drop-in > replacement for groupOfNames. > > If we were starting from a clean slate we might just define: > > ( 1.2.826.0.1.3458854.2.1.1.666 NAME 'membershipObject' > SUP top > AUXILIARY > MAY ( member ) > ) > > and allow designers to apply it to any appropriate structural class. > Following that to its logical conclusion would give almost 1:1 > correspondence between objectclasses and attributetypes, which most > would probably regard as over-normalisation! > > In fact I think groups are very reasonable STRUCTURAL objects, > as the concept of groups has such broad application. Where I might argue > with the current definition of groupOfNames/groupOfEntries is the list > of other descriptive attributes (why should groups have a > businessCategory but no displayName for example?) I tend to agree, but posixGroup is structural ... sigh :) Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Fri Dec 4 09:30:36 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9F61A8971 for ; Fri, 4 Dec 2015 09:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, 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 F0qOV08TdqgI for ; Fri, 4 Dec 2015 09:30:34 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 6F9751A8BBD for ; Fri, 4 Dec 2015 09:30:24 -0800 (PST) Received: by lfdl133 with SMTP id l133so116108595lfd.2 for ; Fri, 04 Dec 2015 09:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=J1d8VIsEXmw93U5wrmJau0IgdUyDwhp5MkR/jVmyeWc=; b=mZsPS/NTf3te/Qfm5seOgxW4DHqUDUsE3yA3u6LLvovQRcqLBUIqF6WmGX7SXIlmoT BKGgEUCIscQZTCckggtz5AKBr+OZ3LLtCPhS+Qn+cxF0iEFuyBExezp5VpWOniB785tL WMMtCIjwLvdzcji5Jad4+u+7c9evBywfrTpxm0C5XN8Y8XalmJXK7V2TBheTjMmF6y73 wFqK26lu5+gojxZ29fYjoKiH5vIb7SuSq4QEYPlPdUIbJNI5UayNTHV5dUvLRGLu7AxB FXWgfLOptNIK82c6jW5OXy0IOnfb4t+q/rlDTTE75xVx9bCAJJbDzDL66xlD02nMzRWE Uhew== MIME-Version: 1.0 X-Received: by 10.25.29.205 with SMTP id d196mr8580919lfd.81.1449250222388; Fri, 04 Dec 2015 09:30:22 -0800 (PST) Received: by 10.114.80.193 with HTTP; Fri, 4 Dec 2015 09:30:22 -0800 (PST) In-Reply-To: <566164B6.9080008@stroeder.com> References: <566164B6.9080008@stroeder.com> Date: Fri, 4 Dec 2015 12:30:22 -0500 Message-ID: From: Charlie To: =?UTF-8?Q?Michael_Str=C3=B6der?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ldapext Subject: Re: [ldapext] LDAP Groups topic split-out X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 17:30:35 -0000 On Fri, Dec 4, 2015 at 5:02 AM, Michael Str=C3=B6der = wrote: > > http://typinganimal.net/rants/textify.php?f=3Ddraft-brooks-ldap-sets-00.t= xt > > Although you will likely claim that your I-D also describes the problem i= n > general you're already endorsing a particular solution. :-/ I have indeed endorsed a particular solution, but I support any effort that will address any of the structural problems exposed by real-life daily directory administration. In section 3 of my I-D I enumerated the requirements for a generalized solution to all grouping problems in real-world directories. Any solution that satisfies those requirements will make the world a better place. It doesn't have to be MY solution. But pragmatically, everyone is going to end up using memberOf attributes eventually. This should be clear by now; it's certainly clear to our friends in Redmond and Raleigh. We can fight this and make it painful for everyone involved - or we can accept it as architecturally correct, and create useful LDAP standards for programmers working towards system interoperability. --Charlie From nobody Fri Dec 4 10:00:16 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15081A9063 for ; Fri, 4 Dec 2015 10:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vcPDcVebDfe1 for ; Fri, 4 Dec 2015 10:00:12 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C154D1A908E for ; Fri, 4 Dec 2015 10:00:07 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4ueL-0007hF-3k for ldapext@ietf.org; Fri, 04 Dec 2015 18:00:05 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4ueJ-0002gX-Rk for ldapext@ietf.org; Fri, 04 Dec 2015 18:00:03 +0000 Date: Fri, 4 Dec 2015 18:00:03 +0000 From: Andrew Findlay To: ldapext@ietf.org Message-ID: <20151204180003.GK3643@slab.skills-1st.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Subject: [ldapext] A more radical approach to 2307 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 18:00:14 -0000 RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model and represent the data in LDAP with varying degrees of fidelity. Is this actually a good idea? I rather think not. The big value of LDAP and related things in complex organisations is that it allows a single abstract representation of 'important stuff' that can be used by many systems. To work in this environment the systems have to be flexible, with minimal built-in assumptions about the data. We have already established that no abstract representation can provide the full generality and semantics of each system's native database so compromise and simplification is essential. With this in mind (and donning my best flameproof suit) I suggest a radical approach to the task in hand: Throw out most of the 2307 NIS-like definitions. Consider what an Enterprise-level LDAP service might really contain *before* any OS-specific or app-specific requirements are imposed on it. Create new schema if needed to support a clean representation of that Enterprise data. Create new AUXILIARY classes to support the attributes needed for POSIX systems. The resulting set of attributes and classes would be *much* smaller than the 2307 set. Some whole categories could just vanish, e.g.: All the shadow password stuff (draft-behera is difficult enough and we don't need to duplicate its function on the client side) memberUid (we really *dont* need a POSIX-specific way to represent groups, and the syntax of memberUid does not even match that of uid) Most of the less-used NIS-map attributes and classes could be hived off into separate documents, or even dumped in favour of a generic structural lookup table with explicit case ignore/case sensitive semantics. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 10:10:48 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F00C1A90A7 for ; Fri, 4 Dec 2015 10:10:47 -0800 (PST) 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, 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 nYqvXNxRUI94 for ; Fri, 4 Dec 2015 10:10:45 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 6B5ED1ABD8F for ; Fri, 4 Dec 2015 10:10:43 -0800 (PST) Received: by ykdv3 with SMTP id v3so133300647ykd.0 for ; Fri, 04 Dec 2015 10:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JsjQ+sdmvMZmd5UVlQ8JX9IbFt8Jiv6rvRY84QEsTbg=; b=qS5YO3GxiuWf2hkYcJX6lo4BpEB51IpGLU8xo8A+K6/e+zqDRQTk2r6oMqqs0iti7Q loVvyHfx2bJ5JJnALr/fkClWhmi/Nl6Xx15KhZxe57bQN6LFoeh2dxgMJbFdvRb4hgzv 9+t8krtORClPzRunHxWObtq0JHf7tdEJNxGbqNIw66M8cOSNms6cd6ZZI4+S0hXdSe7N 7pSdKYWGSIccNGOOgO2xM0K6iozyGFjYB/7z8DvHnHsn8ECv/e556ywqzA8d0+zgtGRT fxSUBIeVYiStMGs/DK0jqUXXfqJ6IjD50bSmWAVU2PraEn3b2pUc//JfD/1xN4mawN24 Ocqg== 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=JsjQ+sdmvMZmd5UVlQ8JX9IbFt8Jiv6rvRY84QEsTbg=; b=ZZOrF3fwA67GRSqEFOHjEzDlaBmED0ZGvAh2tahvbSzZB7SX28tq1KqW3tzL2WqBH8 Le4OF2GkWzai92v6+rX52QA51q+s3NnoJfmjpSR5f43hKSbWdSU12b6BsMz2qD5JkMsT I7bMYBUUs/StZuljfkPAWIqbuQAMD8Nq0+/a7nK0/3Yq6hzpfo3W7FektGMDfpsomeKi f/qHcPJVYW9FSTxRSsLtDEeXWhA69loAJAbU5R6IO2N6oykjFqK4ov9zNhh7mLxDzNNv VNFiPNEOt+V6gTpU//i9e9rO+K61DFN3K51/visX/3xRy1aUTggeBLrx0uG1JeUtyRMB Fpiw== X-Gm-Message-State: ALoCoQm4oIfAIO3npnNke3BmxWn1Is5T7+kjeToeWGqxminLyTucvp1tMpS0Kdt1ZXwp5p9xp5ep X-Received: by 10.129.132.136 with SMTP id u130mr12084582ywf.208.1449252642646; Fri, 04 Dec 2015 10:10:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.224.209 with HTTP; Fri, 4 Dec 2015 10:10:03 -0800 (PST) In-Reply-To: <20151204180003.GK3643@slab.skills-1st.co.uk> References: <20151204180003.GK3643@slab.skills-1st.co.uk> From: Jim Willeke Date: Fri, 4 Dec 2015 10:10:03 -0800 Message-ID: To: Andrew Findlay Content-Type: multipart/alternative; boundary=001a114eed62f4a0230526166c1f Archived-At: Cc: ldapext Subject: Re: [ldapext] A more radical approach to 2307 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 18:10:47 -0000 --001a114eed62f4a0230526166c1f Content-Type: text/plain; charset=UTF-8 I tend to agree with Andrew. -- -jim Jim Willeke On Fri, Dec 4, 2015 at 10:00 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> wrote: > RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model > and represent the data in LDAP with varying degrees of fidelity. > Is this actually a good idea? I rather think not. > > The big value of LDAP and related things in complex organisations is > that it allows a single abstract representation of 'important stuff' > that can be used by many systems. To work in this environment the > systems have to be flexible, with minimal built-in assumptions about the > data. We have already established that no abstract representation can > provide the full generality and semantics of each system's native > database so compromise and simplification is essential. > > With this in mind (and donning my best flameproof suit) I suggest a > radical approach to the task in hand: > > Throw out most of the 2307 NIS-like definitions. > > Consider what an Enterprise-level LDAP service might really > contain *before* any OS-specific or app-specific requirements > are imposed on it. > > Create new schema if needed to support a clean representation > of that Enterprise data. > > Create new AUXILIARY classes to support the attributes needed > for POSIX systems. > > The resulting set of attributes and classes would be *much* smaller than > the 2307 set. Some whole categories could just vanish, e.g.: > > All the shadow password stuff (draft-behera is difficult enough > and we don't need to duplicate its function on the client side) > > memberUid (we really *dont* need a POSIX-specific way to > represent groups, and the syntax of memberUid does not even > match that of uid) > > Most of the less-used NIS-map attributes and classes could be > hived off into separate documents, or even dumped in favour of a > generic structural lookup table with explicit case ignore/case > sensitive semantics. > > Andrew > -- > ----------------------------------------------------------------------- > | From Andrew Findlay, Skills 1st Ltd | > | Consultant in large-scale systems, networks, and directory services | > | http://www.skills-1st.co.uk/ +44 1628 782565 | > ----------------------------------------------------------------------- > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > --001a114eed62f4a0230526166c1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree with Andrew.

--
-jim
Jim Willeke

On Fri, Dec 4, 2015 at 10:00 AM, Andrew Find= lay <andrew.findlay@skills-1st.co.uk> wrote:
RFC2307, 2307bis and DBIS all start from t= he NIS/YP/files-in-etc model
and represent the data in LDAP with varying degrees of fidelity.
Is this actually a good idea? I rather think not.

The big value of LDAP and related things in complex organisations is
that it allows a single abstract representation of 'important stuff'= ;
that can be used by many systems. To work in this environment the
systems have to be flexible, with minimal built-in assumptions about the data. We have already established that no abstract representation can
provide the full generality and semantics of each system's native
database so compromise and simplification is essential.

With this in mind (and donning my best flameproof suit) I suggest a
radical approach to the task in hand:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Throw out most of the 2307 NIS-like definitions= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Consider what an Enterprise-level LDAP service = might really
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contain *before* any OS-specific or app-specifi= c requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are imposed on it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Create new schema if needed to support a clean = representation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of that Enterprise data.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Create new AUXILIARY classes to support the att= ributes needed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for POSIX systems.

The resulting set of attributes and classes would be *much* smaller than the 2307 set. Some whole categories could just vanish, e.g.:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 All the shadow password stuff (draft-behera is = difficult enough
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and we don't need to duplicate its function= on the client side)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 memberUid (we really *dont* need a POSIX-specif= ic way to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 represent groups, and the syntax of memberUid d= oes not even
=C2=A0 =C2=A0 =C2=A0 =C2=A0 match that of uid)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Most of the less-used NIS-map attributes and cl= asses could be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 hived off into separate documents, or even dump= ed in favour of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 generic structural lookup table with explicit c= ase ignore/case
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sensitive semantics.

Andrew
--
-----------------------------------------------------------------------
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From Andrew = Findlay, Skills 1st Ltd=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
| Consultant in large-scale systems, networks, and directory services |
|=C2=A0 =C2=A0 =C2=A0http://www.skills-1st.co.uk/=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +44 1628 782565=C2=A0 =C2=A0 =C2=A0|
-----------------------------------------------------------------------

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

--001a114eed62f4a0230526166c1f-- From nobody Fri Dec 4 10:40:01 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944921B2BCB for ; Fri, 4 Dec 2015 10:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r7dSjdi0n8SI for ; Fri, 4 Dec 2015 10:39:58 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7AF1ACD48 for ; Fri, 4 Dec 2015 10:39:58 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4vGr-0007zj-Dj; Fri, 04 Dec 2015 18:39:53 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4vGq-0002jB-UV; Fri, 04 Dec 2015 18:39:52 +0000 Date: Fri, 4 Dec 2015 18:39:52 +0000 From: Andrew Findlay To: Simo Sorce Message-ID: <20151204183952.GB8983@slab.skills-1st.co.uk> References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com> <565E55C3.9080404@oracle.com> <1449076861.9040.56.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449076861.9040.56.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: "'ldapext@ietf.org'" Subject: Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 18:40:00 -0000 On Wed, Dec 02, 2015 at 12:21:01PM -0500, Simo Sorce wrote: > > >> I think the truly right answer there is to add new APIs that don't > > >> retrieve the members, and even to redefine the existing APIs to not > > >> retrieve the members, because there are almost no cases where it > > >> actually makes sense to retrieve the list of members of a UNIX group. +1 (at least!) > > > It would be nice to have a new API, although Posix has some wiggle room > > > which we fully exploit in clients like Windbind and SSSD. > > > > > > Both clients simply do not return all members in the enumeration cases > > > (getgrent) but only in the explicit group retrieve case (getgrnam). > > > This is because Posix allows to omit results in the enumeration case > > > according to some interpretations. > > > > Yes, and I infer that there's corresponding omissions in other parts of the > > standard. In the getgrent description, the standard describes omitting this > > information on the basis of security restrictions. Omitting the data there would > > not help security at all if you could immediately turn around and request it > > through getgrname and getgrgid. Meeting the security need would require having > > the restrictions in both places. > > True, but are not doing this for security reasons, we are just taking > the fact that omissions are permissible as a blanket permission to omit > results, and clients should be prepared to deal with that. > > After all the texts are vague and you could think that the security > measure expressed here is about not revealing group names. I think this is a very valuable insight. Any program that expects to enumerate the whole password or group database is a liability and this has been the case since Unix escaped from Bell Labs. In the 1980s there was a machine called Pyramid: it had a hashed database for /etc/hosts but it searched /etc/group and /etc/passwd linearly. We had one at the university for undergrad use so both files were quite large by the standards of the day (5000 entries - seems trivial now!) The result was very slow logins for people near the end of the file. This took a while to notice as all the computing staff were at the front... Following the POSIX stuff a bit further, getgrnam() refers to grp.h: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/grp.h.html Donning a definition-lawyer's pedantic wig I find this: ------------------------------------------------------------------------ The header shall declare the group structure, which shall include the following members: char *gr_name The name of the group. gid_t gr_gid Numerical group ID. char **gr_mem Pointer to a null-terminated array of character pointers to member names. ------------------------------------------------------------------------ That last field is interesting. There are pointers to member names, but it does *not* say that *all* members will be listed. Taken with the 'extended security controls' applicable to getgrent() I take this as approval to return only the data that an application would reasonably need. Certainly a new API would be better, but I think a config option to 'do the efficient thing' would be very reasonable. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 11:03:56 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FA81B3263 for ; Fri, 4 Dec 2015 11:03:55 -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 1tnkqby43gtK for ; Fri, 4 Dec 2015 11:03:53 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 C045A1B325F for ; Fri, 4 Dec 2015 11:03:53 -0800 (PST) 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 tB4J3pCu025816 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 19:03:52 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 tB4J3p4k015695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 19:03:51 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB4J3pPo026269; Fri, 4 Dec 2015 19:03:51 GMT Received: from [10.159.189.82] (/10.159.189.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Dec 2015 11:03:51 -0800 To: "Oza, Dhairesh" , Charlie References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F30E@OZWEX0209N2.msad.ms.com> <565F1EB2.9060405@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F3A@OZWEX0209N2.msad.ms.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F90F6F@OZWEX0209N2.msad.ms.com> <56607926.1080306@oracle.com> <5660C9ED.7040000@oracle.com> <8f2da2363f684ec6bc95f8046dd81bd3@hioexcmbx04-prd.hq.netapp.com> From: Jordan Brown Message-ID: <5661E394.2070001@oracle.com> Date: Fri, 4 Dec 2015 11:03:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <8f2da2363f684ec6bc95f8046dd81bd3@hioexcmbx04-prd.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "ldapext@ietf.org" Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 19:03:55 -0000 On 12/3/2015 11:05 PM, Oza, Dhairesh wrote: > They shouldn't be comparing names but uids/gids. Unfortunately, it's not always that simple. An e-mail program may have a configuration file with alias entries... are they case sensitive? Any program might keep per-user files somewhere, named after the user... is the file system case sensitive? In general, any configuration file might have user names in it (because they're the appropriate human interface), and might compare names because that's the obvious way to do it. People who say that case-insensitive user names may cause subtle problems are absolutely correct. But that doesn't mean that we shouldn't head that way. From nobody Fri Dec 4 11:16:03 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C781B3280 for ; Fri, 4 Dec 2015 11:16:01 -0800 (PST) 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 gLG_Y_Qrfjub for ; Fri, 4 Dec 2015 11:16:00 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 5A5321B327E for ; Fri, 4 Dec 2015 11:16:00 -0800 (PST) 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 tB4JFvpH008196 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 19:15:58 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 tB4JFuZM027394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 19:15:56 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 tB4JFuiJ021316; Fri, 4 Dec 2015 19:15:56 GMT Received: from [10.159.189.82] (/10.159.189.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Dec 2015 11:15:56 -0800 To: =?UTF-8?Q?Michael_Str=c3=b6der?= , ldapext References: <5661765D.6040603@stroeder.com> From: Jordan Brown Message-ID: <5661E664.8000703@oracle.com> Date: Fri, 4 Dec 2015 11:15:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <5661765D.6040603@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [ldapext] empty-groupOfNames-issue X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 19:16:01 -0000 On 12/4/2015 3:17 AM, Michael Strder wrote: > Especially some vendors should raise their voice which approaches they are > willing to adopt or not. I believe that the existing Solaris code (in S11+) will work with minor customization with any groupOfNames variant. You'd just tell it what object class and attribute to use. Anything with a fundamentally different structure... it'd be tough. The incentive to implement a new standard that the customers haven't adopted, that doesn't provide much truly new functionality, is pretty low. (Yes, I know that's a Catch-22.) From nobody Fri Dec 4 12:09:58 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42B91A0032 for ; Fri, 4 Dec 2015 12:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 04vqBrRaa232 for ; Fri, 4 Dec 2015 12:09:54 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1199F1A0022 for ; Fri, 4 Dec 2015 12:09:53 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id C86431CF3A; Fri, 4 Dec 2015 20:09:50 +0000 (UTC) Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id C91F21D662; Fri, 4 Dec 2015 20:09:48 +0000 (UTC) To: Andrew Findlay , ldapext@ietf.org References: <20151204180003.GK3643@slab.skills-1st.co.uk> From: =?UTF-8?Q?Michael_Str=c3=b6der?= X-Enigmail-Draft-Status: N1110 Message-ID: <5661F30C.3030604@stroeder.com> Date: Fri, 4 Dec 2015 21:09:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20151204180003.GK3643@slab.skills-1st.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070208060604070703040500" Archived-At: Subject: Re: [ldapext] A more radical approach to 2307 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 20:09:56 -0000 This is a cryptographically signed message in MIME format. --------------ms070208060604070703040500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andrew Findlay wrote: > RFC2307, 2307bis and DBIS all start from the NIS/YP/files-in-etc model > and represent the data in LDAP with varying degrees of fidelity. > Is this actually a good idea? I rather think not. Yepp. RFC 2307bis should be splitted. > The resulting set of attributes and classes would be *much* smaller tha= n > the 2307 set. Some whole categories could just vanish, e.g.: >=20 > All the shadow password stuff (draft-behera is difficult enough > and we don't need to duplicate its function on the client side) Yes, 'shadowAccount' is already regarded deprecated. > memberUid (we really *dont* need a POSIX-specific way to > represent groups, and the syntax of memberUid does not even > match that of uid) That's the only thing we might want to consider to keep because of backwards-compability to existing client implementations. > Most of the less-used NIS-map attributes and classes could be > hived off into separate documents, or even dumped in favour of a > generic structural lookup table with explicit case ignore/case > sensitive semantics. It might be worth to preserve some of the stuff but really in a separate = generic document. Ciao, Michael. --------------ms070208060604070703040500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIwNDIwMDk0OFowLwYJKoZIhvcNAQkEMSIEIIGytz+zOfnUnMeJxMgZhQ4pihZpRXEu4qYc j+n2puB4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQBpl4mKbneSuZYyF3ul 3JA1o6QdNL5+BfE0sww6PV/HmlxE3F+H2FGW6l7i+X65BKNUhbhMLB9o9OMcJzROoFSyJIK1 +238eiVKXT+lpFN/P3mJVgmF7eUR8RY+v+OjvnDN9BCncrPTQ1M+Fb7p2inNLTq8y5HsJVsi 4v7iJzDiZbSpmvZ8pNqgMN4ahCdhjmMuEm84JvifNWA9b0gCSHdn7gF+WskJvmD0dxMdjmor HiM2cSdD6SryXgnLNhB0zdWmZW2mds3Jl1YBXEkUpt2xF3YSNrx6IJQes2hVxGNezrqEj/IJ RL/p6p0XnYds9IhCK6Mwk0O8gghokzksoy3iAAAAAAAA --------------ms070208060604070703040500-- From nobody Fri Dec 4 14:01:10 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5331A92E3 for ; Fri, 4 Dec 2015 14:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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] 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 c77bWLTsX60J for ; Fri, 4 Dec 2015 14:01:06 -0800 (PST) Received: from pimtaint01.ms.com (pimtaint01.ms.com [199.89.103.68]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D482E1A92E2 for ; Fri, 4 Dec 2015 14:01:05 -0800 (PST) Received: from pimtaint01 (localhost.ms.com [127.0.0.1]) by pimtaint01.ms.com (output Postfix) with ESMTP id A6A023042BB; Fri, 4 Dec 2015 17:01:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449266464; x=1450476064; bh=B0iRtrp4xcKrOR60RIMd/8gQ3mERoxdaepVxx85O5n8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cYmL+tqibSr+Hzvc6Lps+tPrzrUTw9HLCpdPNeiHVSyURihLvtau9/B6jOvsUvvFY V9uWmUElUs6dnxVWoHI+nAagMB4MQu5uiOqJcIz/1NWzIdLPyNMRbOLiA8nCAyq38w En2q+46QEz/fX6/ERznttH186yBT1+mxZNd2aM+o= Received: from rrsmmta05.ms.com (rrsmmta05.ms.com [10.204.131.3]) by pimtaint01.ms.com (internal Postfix) with ESMTP id 8866E3041BD; Fri, 4 Dec 2015 17:01:04 -0500 (EST) Received: from HZWEX2002N4.msad.ms.com (hzwex2002n4.ms.com [10.195.139.202]) by rrsmmta05.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB4M14hZ029374; Fri, 4 Dec 2015 22:01:04 GMT Received: from HZWEX2001N3.msad.ms.com (10.195.129.16) by HZWEX2002N4.msad.ms.com (10.195.139.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:01:03 -0500 Received: from OYWEX0206N3.msad.ms.com (10.208.118.33) by HZWEX2001N3.msad.ms.com (10.195.129.16) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:01:03 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0206N3.msad.ms.com ([10.208.118.33]) with mapi id 14.03.0235.001; Fri, 4 Dec 2015 22:00:28 +0000 From: "Bannister, Mark" To: "'Andrew Findlay'" , Simo Sorce Thread-Topic: [ldapext] Case sensitivity summary Thread-Index: AQHRLpFcuE2cjQOlg0y8pThx01wW4Z662zMAgAAbyACAABVSgIAAUJHA Date: Fri, 4 Dec 2015 22:00:27 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F9254C@OZWEX0209N2.msad.ms.com> References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com> <20151204165629.GJ3643@slab.skills-1st.co.uk> In-Reply-To: <20151204165629.GJ3643@slab.skills-1st.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/04 11:54:00 #6669674; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: LDAP Extensions list , =?iso-8859-1?Q?Michael_Str=F6der?= Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:01:08 -0000 Andrew Findlay wrote: > We are not going to define a standard that forces everyone to do everythi= ng 'right' while providing > interworking of differing systems. It is simply not possible. Yes it *is* possible. You take the POSIX approach and do not attempt to in= terpret case. You do byte-by-byte comparisons. I store data in LDAP, when I retrieve it I expec= t to find it only if I send an identical sequence of bytes, and when it is returned it is unchan= ged. Anything else is making the system more complex than it needs to be. > Anyone can make an existing system more complex. It takes effort and clea= r vision to make it simpler. Isn't that what I just said? I'm glad you agree with me ;-) So, 65 goes i= n, 65 is what I need to find it and 65 is what comes out the other end. If I send 97, I should quite ri= ghtly not find my data. That's my simple, clear vision. As for users who don't know how to use the= ir CAPS LOCK key, send them on a training course, one that teaches them how to interact succe= ssfully with computer systems. Remind them it is a computer, not a human. We are alrea= dy having to display pop-ups in password fields along the lines of "you have your CAPS L= OCK key turned on, are you sure you meant to do that?" ... we could do the same with login= name fields. It is easier to educate humans to interact with computers, than the other w= ay around. > Like it or not, all of the computing systems we are working with started = life with a very strong > Western cultural bias. In fact most of them have a bias towards the Engli= sh language as used > in North America. It shouldn't matter that computers grew out of Western culture, that should= have to change, as the world is bigger now, standards ought to move on to reflect that. Embra= ce diversity through simplicity. Trying to maintain rules for case insensitive matching that ma= ke sense in 2015, that work for every locale, seems like a foolish never-ending pastime with pract= ically zero benefit. Mark. -----Original Message----- From: Ldapext [mailto:ldapext-bounces@ietf.org] On Behalf Of Andrew Findlay Sent: 04 December 2015 16:56 To: Simo Sorce Cc: LDAP Extensions list; Michael Str=F6der Subject: Re: [ldapext] Case sensitivity summary On Fri, Dec 04, 2015 at 10:40:10AM -0500, Simo Sorce wrote: > There are odd things in the wild, so you need to be at least=20 > case-preserving, both for user names and services. One idea that I did not put in the summary as it is a bit of a side-issue: Client systems that care about case-sensitivity might be given a config opt= ion to use extensible matching: ldapsearch -x '(&objectclass=3DposixAccount)(uid:caseExactMatch:=3DBABS))' ldapsearch -x '(&objectclass=3DposixAccount)(uid:caseExactMatch:=3Dbabs))' It would then be possible to have two entries where the uid differs only in= case provided uid is not used as the RDN attribute. This SHOULD prevent ei= ther user from logging in on systems that are not using the search shown ab= ove, as the result of a normal search on uid would be ambiguous. Data manag= ement would require great care. > ACK, maintaining broken systems may seem the only way for some=20 > organizations due to the daunting task and inter-dependencies that=20 > makes a clean up really hard. I have personally witnessed herculean=20 > efforts to migrate several hundreds diverged NIS domains into a single=20 > directory, and it ain't pretty. Especially if you have terabytes of=20 > data and numerous files with permissions to deal with. But the problem=20 > has always mostly been on uidNumber and gidNumber consolidation,=20 > usually name-mismatches have been mush easier to deal with because it=20 > is easy to remap usernames locally. People are often tempted to build complex technical solutions because that = is within their control and ability. It is almost always better in the long= run to fix the organisational issues and migrate to a clean(er) set of dat= a using a simpler technical setup. Anyone can make an existing system more complex. It takes effort and clear = vision to make it simpler. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers. If you canno= t access these links, please notify us by reply message and we will send th= e contents to you. By messaging with Morgan Stanley you consent to the fore= going.= From nobody Fri Dec 4 14:39:12 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AE41ACCD9 for ; Fri, 4 Dec 2015 14:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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] 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 yez6TY6OQOI9 for ; Fri, 4 Dec 2015 14:39:09 -0800 (PST) Received: from pimtaint01.ms.com (pimtaint01.ms.com [199.89.103.68]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572301ACC8C for ; Fri, 4 Dec 2015 14:39:09 -0800 (PST) Received: from pimtaint01 (localhost.ms.com [127.0.0.1]) by pimtaint01.ms.com (output Postfix) with ESMTP id A08C03045DA; Fri, 4 Dec 2015 17:39:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449268748; x=1450478348; bh=oFheBciwyu/AyAHsNZZ6I7lG7wVPGDpWkcTdOhRXxtk=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=M6nnee3fG9F4RCMxGGz1HHc60vRRMtFMYqXjTbJYTJD/QAsL2Cu5eAlxt83T87qV8 pLe1gpg/9Lr/9Rgc0rK627vwlQv759WpSZqpQT05O4ziy1YofAhvGp6HGejhKEC/P3 tW9ATurWXxy+hDTwMAv+PCh8XcYq7uqzfbQTN7iE= Received: from rrsmmta02.ms.com (rrsmmta02.ms.com [10.196.137.198]) by pimtaint01.ms.com (internal Postfix) with ESMTP id 84E3130466A; Fri, 4 Dec 2015 17:39:08 -0500 (EST) Received: from RRWEX2005N2.msad.ms.com (rrwex2005n2.ms.com [10.196.131.20]) by rrsmmta02.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB4Md8D6020302; Fri, 4 Dec 2015 22:39:08 GMT Received: from HZWEX2013N4.msad.ms.com (10.195.131.46) by RRWEX2005N2.msad.ms.com (10.196.131.20) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:39:07 -0500 Received: from OYWEX0202N4.msad.ms.com (10.208.118.83) by HZWEX2013N4.msad.ms.com (10.195.131.46) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:39:07 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0202N4.msad.ms.com ([169.254.3.127]) with mapi id 14.03.0235.001; Fri, 4 Dec 2015 22:39:06 +0000 From: "Bannister, Mark" To: "'Andrew Findlay'" , "ldapext@ietf.org" Thread-Topic: [ldapext] A more radical approach to 2307 Thread-Index: AQHRLr2jvQsvZIpf+kGtZ7K2DuMKoZ67YfMw Date: Fri, 4 Dec 2015 22:39:06 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F925A1@OZWEX0209N2.msad.ms.com> References: <20151204180003.GK3643@slab.skills-1st.co.uk> In-Reply-To: <20151204180003.GK3643@slab.skills-1st.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/04 11:54:00 #6669674; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [ldapext] A more radical approach to 2307 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:39:11 -0000 Andrew Findlay wrote: > The big value of LDAP and related things in complex organisations is that= it allows a single > abstract representation of 'important stuff' that can be used by many sys= tems. I would question your use of 'single' and 'abstract'. That's not how I see= directories being used in complex organisations. > To work in this environment the systems have to be flexible, with minimal= built-in assumptions > about the data. It sounds like you're describing a utopian system, but that in itself is an= invalid assumption. > We have already established that no abstract representation can provide t= he full > generality and semantics of each system's native database so compromise a= nd simplification > is essential. Not necessarily, as not everything needs to interoperate. Even when it doe= s it's not hard to have two pieces of information maintained to support the semantics of tw= o different systems. Bear in mind that the data in a directory usually comes from and = is managed by an external application. I don't know any large enterprises where human= s edit data directly within the directory. Therefore as long as the application that i= s managing the entries can be taught that in some cases it needs to maintain a couple of d= ifferent flavours, then I see no issue to be solved here. In the human mind it is "cleaner" t= o have one attribute serve all, but if it is simpler all-round to have two attributes = instead, the computer doesn't care, only the human mind seeking a false sense of perfection. > With this in mind (and donning my best flameproof suit) I suggest a radic= al approach to the task in hand: >=20 > Throw out most of the 2307 NIS-like definitions. >=20 > Consider what an Enterprise-level LDAP service might really > contain *before* any OS-specific or app-specific requirements > are imposed on it. >=20 > Create new schema if needed to support a clean representation > of that Enterprise data. >=20 > Create new AUXILIARY classes to support the attributes needed > for POSIX systems. In complex systems, it's so much *easier* for us humans to think about thro= wing away and starting again from scratch, thinking that the next one will be better. I = see it all too often. But I rarely see a better product at the end of the process, because what p= eople term as "legacy" or label as "20 year old code" (by which they infer bit-rot) is ac= tually wisdom, many lessons learned, greater interoperability. What you would end up with if you took the "radical approach" is another IP= v6, by which I mean a new standard that was supposed to be better all-round but because = it was not backwards compatible and was too painful for people to easily migrate to st= ill today it is barely adopted. Worse, the standards community were then so focused on IPv= 6 that IPv4 (on which the largest majority of the internet-connected world still c= ared) was getting little or no attention. That was a mistake. The promise of something brand new is often more exciting to humans than th= e thought of improving something that has been developed and improved by iteration ov= er the years. I think, however, that if standards are supposed to reflect what pe= ople are doing now, to take the best of the common approaches and come up with somet= hing that people can actually immediately make use of with very little change to thei= r working practices, the "radical approach" is not in our calling. I think we would = better serve those who need these standards by staying focused on incremental improvemen= ts, benefits that can be quickly and easily realised, immediate compatibility w= ith today's common approaches. Compare this with the building infrastructure in the world's largest and ol= dest cities. We live with it. We extend it. Some infrastructure we will never be able = to fully replace, and in many places we don't even try to. It's too costly, it's to= o disruptive. You can try to build a brand new city somewhere else in the country with al= l new modern standards, but you won't get that many people moving their homes to live there. Mark. ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers. If you canno= t access these links, please notify us by reply message and we will send th= e contents to you. By messaging with Morgan Stanley you consent to the fore= going.= From nobody Fri Dec 4 14:49:56 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42BC1ACD5A for ; Fri, 4 Dec 2015 14:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f443w5BeVSBV for ; Fri, 4 Dec 2015 14:49:53 -0800 (PST) Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1541ACD59 for ; Fri, 4 Dec 2015 14:49:53 -0800 (PST) Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1a4zAj-0001Ff-UG; Fri, 04 Dec 2015 22:49:50 +0000 Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from ) id 1a4zAj-0002pw-FT; Fri, 04 Dec 2015 22:49:49 +0000 Date: Fri, 4 Dec 2015 22:49:49 +0000 From: Andrew Findlay To: "Bannister, Mark" Message-ID: <20151204224949.GL3643@slab.skills-1st.co.uk> References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com> <20151204165629.GJ3643@slab.skills-1st.co.uk> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F9254C@OZWEX0209N2.msad.ms.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F9254C@OZWEX0209N2.msad.ms.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Andrew Findlay Archived-At: Cc: LDAP Extensions list , Michael =?iso-8859-1?Q?Str=F6der?= Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:49:55 -0000 On Fri, Dec 04, 2015 at 10:00:27PM +0000, Bannister, Mark wrote: > > We are not going to define a standard that forces everyone to do everything 'right' while providing > > interworking of differing systems. It is simply not possible. > > Yes it *is* possible. You take the POSIX approach and do not attempt to interpret case. You do > byte-by-byte comparisons. Yes that works perfectly. IFF you are only considering Unix-like systems. Most LDAP deployments at least aspire to be useful for a wider range of client systems. [ IFF == If and only if ] Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | ----------------------------------------------------------------------- From nobody Fri Dec 4 14:58:45 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92601ACE0E for ; Fri, 4 Dec 2015 14:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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] 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 0flerpdA24Jv for ; Fri, 4 Dec 2015 14:58:43 -0800 (PST) Received: from hqmtaint03.ms.com (hqmtaint03.ms.com [205.228.53.73]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDAE1ACE06 for ; Fri, 4 Dec 2015 14:58:43 -0800 (PST) Received: from hqmtaint03 (localhost.ms.com [127.0.0.1]) by hqmtaint03.ms.com (output Postfix) with ESMTP id 33FBE1716CF; Fri, 4 Dec 2015 17:58:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449269922; x=1450479522; bh=idS/EdZnf47rzY8iQM/I05SULz1jR0MRBzVRpOt0p+k=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hdExWFIlLaa52lwEp1H9CDCrSR9jtBg4Qjord/ZHUGJdAPFu0GrvrtmHnlchz3YMV ETPa6NPoIhIEhV73PkTohPH29NfxEFVo6tuK7pbh/Qnk6j43hmjjowjV69w4onYgU3 8DYFuBJg8F+BpNQJ6sHOt2dgM5wQyRFaByp53emw= Received: from rrsmmta04.ms.com (rrsmmta04.ms.com [10.204.131.4]) by hqmtaint03.ms.com (internal Postfix) with ESMTP id 150981716C3; Fri, 4 Dec 2015 17:58:42 -0500 (EST) Received: from HZWEX2006N4.msad.ms.com (hzwex2006n4.ms.com [10.195.139.203]) by rrsmmta04.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB4Mwf8o006314; Fri, 4 Dec 2015 22:58:41 GMT Received: from RRWEX2011N1.msad.ms.com (10.196.133.51) by HZWEX2006N4.msad.ms.com (10.195.139.203) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:58:41 -0500 Received: from OYWEX0201N4.msad.ms.com (10.208.118.82) by RRWEX2011N1.msad.ms.com (10.196.133.51) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Dec 2015 17:58:41 -0500 Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0201N4.msad.ms.com ([10.208.118.82]) with mapi id 14.03.0235.001; Fri, 4 Dec 2015 22:58:18 +0000 From: "Bannister, Mark" To: "'Andrew Findlay'" Thread-Topic: [ldapext] Case sensitivity summary Thread-Index: AQHRLpFcuE2cjQOlg0y8pThx01wW4Z662zMAgAAbyACAABVSgIAAUJHAgAASKICAAAGLMA== Date: Fri, 4 Dec 2015 22:58:17 +0000 Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F925D3@OZWEX0209N2.msad.ms.com> References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com> <20151204165629.GJ3643@slab.skills-1st.co.uk> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F9254C@OZWEX0209N2.msad.ms.com> <20151204224949.GL3643@slab.skills-1st.co.uk> In-Reply-To: <20151204224949.GL3643@slab.skills-1st.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mspolicyagent: version=1.0 x-originating-ip: [10.173.249.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2 X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, disabled by settings X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/04 11:54:00 #6669674; khse: 2014-03-12 13:55:01 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: LDAP Extensions list , =?iso-8859-1?Q?Michael_Str=F6der?= Subject: Re: [ldapext] Case sensitivity summary X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 22:58:45 -0000 > > > We are not going to define a standard that forces everyone to do=20 > > > everything 'right' while providing interworking of differing systems.= It is simply not possible. > >=20 > > Yes it *is* possible. You take the POSIX approach and do not attempt=20 > > to interpret case. You do byte-by-byte comparisons. >=20 > Yes that works perfectly. IFF you are only considering Unix-like systems.= Most LDAP > deployments at least aspire to be useful for a wider range of client syst= ems. >=20 > [ IFF =3D=3D If and only if ] >=20 > Andrew Not true. If all you're trying to do is protect Windows users from acciden= tal use of the CAPS LOCK key, you can fix that in Windows before you even talk to t= he directory server. Mark. ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers. If you canno= t access these links, please notify us by reply message and we will send th= e contents to you. By messaging with Morgan Stanley you consent to the fore= going.= From nobody Fri Dec 4 16:06:32 2015 Return-Path: X-Original-To: ldapext@ietfa.amsl.com Delivered-To: ldapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F471B33EF for ; Fri, 4 Dec 2015 16:06:30 -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 FhAopByYMs_9 for ; Fri, 4 Dec 2015 16:06:27 -0800 (PST) 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 505EC1B33EE for ; Fri, 4 Dec 2015 16:06:27 -0800 (PST) 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 tB506P4M023497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Dec 2015 00:06:25 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 tB506OsW023895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 5 Dec 2015 00:06:25 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 tB506NmS013770; Sat, 5 Dec 2015 00:06:23 GMT Received: from [10.159.189.82] (/10.159.189.82) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 04 Dec 2015 16:06:23 -0800 To: "Bannister, Mark" , "'Andrew Findlay'" , "ldapext@ietf.org" References: <20151204180003.GK3643@slab.skills-1st.co.uk> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F925A1@OZWEX0209N2.msad.ms.com> From: Jordan Brown Message-ID: <56622A78.5040506@oracle.com> Date: Fri, 4 Dec 2015 16:06:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F925A1@OZWEX0209N2.msad.ms.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [ldapext] A more radical approach to 2307 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 00:06:30 -0000 On 12/4/2015 2:39 PM, Bannister, Mark wrote: > [ start from scratch, vs incrementally improve ] Both answers are right, and both answers are wrong. It's wrong to throw away an architecture when it largely works, just needs a little tweaking, and where a replacement would be essentially the same. It's also wrong to slavishly preserve a legacy architecture when it's clearly flawed and a replacement could be better and cleaner. Both errors happen all the time. I tend to think that what we have here is a mix of the two.