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