Re: [ldapext] DBIS commentary

"Bannister, Mark" <Mark.Bannister@morganstanley.com> Wed, 02 December 2015 08:59 UTC

Return-Path: <Mark.Bannister@morganstanley.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 E6BD11B34C7 for <ldapext@ietfa.amsl.com>; 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 <ldapext@ietfa.amsl.com>; 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 <ldapext@ietf.org>; 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 <ldapext@ietf.org>; 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" <Mark.Bannister@morganstanley.com>
To: "'Jordan Brown'" <Jordan.Brown@oracle.com>
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: <http://mailarchive.ietf.org/arch/msg/ldapext/z2QYe3xkfBeGxs5RSrc4XZlQ7Jc>
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 08:59:36 -0000

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.

Charlie wrote:
> 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.

I’m also a firm believer in providing options for working in different ways, rather than
trying to force everyone to fit a single paradigm.  To that end, perhaps we drop the
notion of DBIS “replacing” RFC2307/RFC2307bis and it just becomes another way to
do things.

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).

Jordan Brown wrote:
> 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.

It wouldn’t have bothered me until I came across a very large organisation for
which this broke.  More suggestions in the other thread.

> 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.

Yes but that is basic electrical safety which is communicated far and wide, we even teach this
to our children.  Plus there are office inspections that pick this up if you’re doing it wrong, so
it’s corrected.  I don’t think it’s a relevant rebuff.  NIS being case sensitive is more akin to
Californians being allowed to turn right on red (as long as they promise not to knock over a
pedestrian).  If you changed the rules of the road tomorrow, people will forget.  But the
rules of our road affect computer software, and software never forgets.  Worse, software
outlives hardware by a long way, it doesn’t fall off like dead wood (old servers being
decommissioned).  Someone has to rewrite it.

Mark.



________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions 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 Reform 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. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor 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 foregoing.