Re: [ldapext] DBIS commentary
Simo Sorce <simo@redhat.com> Wed, 02 December 2015 01:06 UTC
Return-Path: <simo@redhat.com>
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 <ldapext@ietfa.amsl.com>; 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 <ldapext@ietfa.amsl.com>; 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 <ldapext@ietf.org>; 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 <simo@redhat.com>
To: "Bannister, Mark" <Mark.Bannister@morganstanley.com>
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: <http://mailarchive.ietf.org/arch/msg/ldapext/MsSu6lQx01DAywIxvOyqFs_uVq0>
Cc: "'ldapext@ietf.org'" <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 <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=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: > <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. Bugs happen, even in specifications. > Imagine if the electronics industry in America > > started selling devices with only English three-pin > plugs<https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, 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. > </rant> -- Simo Sorce * Red Hat, Inc * New York
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Steven Legg
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Ludovic Poitou
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- [ldapext] Case sensitivity of user/group names (w… Jordan Brown
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Simo Sorce
- [ldapext] Using groupOfNames (or similar) for UNI… Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Bannister, Mark
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] Using groupOfNames (or similar) for… Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Oza, Dhairesh
- [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- [ldapext] draft-masarati-ldap-deref as ldapext wo… Michael Ströder
- Re: [ldapext] Case sensitivity summary Simo Sorce
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Howard Chu
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Simo Sorce
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- Re: [ldapext] Using groupOfNames (or similar) for… Andrew Findlay
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity summary Bannister, Mark
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Bannister, Mark