Re: Case sensitivity summary

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:[email protected]] 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 =

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

> 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 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
[email protected]
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.