Re: [ldapext] DBIS commentary

["Bannister, Mark" <[e-mail]>]

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.