Re: DBIS commentary

Jordan Brown <[email protected]> Tue, 1 Dec 2015 14:49:22 -0800
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============4826031613822591627==
Content-Type: multipart/alternative;
 boundary="------------040103040900080104070007"

This is a multi-part message in MIME format.
--------------040103040900080104070007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[ Splitting off a specific subthread as Michael requested ]
[ Resend with correct distribution ]

On 12/1/2015 2:06 PM, Charlie wrote:
> A directory backend that is intended to serve multiple existing
> operating systems probably shouldn't be telling any of those operating
> systems whether or not they should be case-sensitive.  It's out of
> scope for the project and causes arguments.

Well, but... if the various OSes are sharing the same naming attribute, it seems 
like there's an unbreakable chain of connections between them.  Either the 
attribute is case-sensitive, in which case the natively-case-insensitive OS will 
be confused, or the attribute is case-insensitive, in which case the 
natively-case-sensitive OS will be confused.

The way that I look at it is not that the directory is serving the OSes, but that 
the directory is defining a world that the OSes are choosing to play in... and 
when they choose to play in the directory's world, they have to live by its rules.

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

It's tempting to suggest that a single entry could have one name attribute that's 
case-sensitive and another that's case-insensitive (presumably from different 
auxiliary classes), and technically that'd be possible, but seems like an 
administrative nightmare... a very high cost to pay for the 0.1% of names where 
case-sensitivity is important.


--------------040103040900080104070007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-text-flowed" style=3D"font-family: -moz-fixed;
      font-size: 12px;" lang=3D"x-western">[ Splitting off a specific
      subthread as Michael requested ]
      <br>
      [ Resend with correct distribution ]<br>
      <br>
      On 12/1/2015 2:06 PM, Charlie wrote:
      <br>
      <blockquote type=3D"cite" style=3D"color: #666666;">A directory
        backend that is intended to serve multiple existing
        <br>
        operating systems probably shouldn't be telling any of those
        operating
        <br>
        systems whether or not they should be case-sensitive.=A0 It's out
        of
        <br>
        scope for the project and causes arguments.
        <br>
      </blockquote>
      <br>
      Well, but... if the various OSes are sharing the same naming
      attribute, it seems like there's an unbreakable chain of
      connections between them.=A0 Either the attribute is case-sensitive=
,
      in which case the natively-case-insensitive OS will be confused,
      or the attribute is case-insensitive, in which case the
      natively-case-sensitive OS will be confused.
      <br>
      <br>
      The way that I look at it is not that the directory is serving the
      OSes, but that the directory is defining a world that the OSes are
      choosing to play in... and when they choose to play in the
      directory's world, they have to live by its rules.
      <br>
      <br>
      <blockquote type=3D"cite" style=3D"color: #666666;">That being said=
,
        options are great to have.=A0 If you can support
        <br>
        existing systems while also giving people the ability to do
        whatever
        <br>
        you happen to think is better, you'll automatically win any such
        <br>
        arguments.
        <br>
      </blockquote>
      <br>
      It's tempting to suggest that a single entry could have one name
      attribute that's case-sensitive and another that's
      case-insensitive (presumably from different auxiliary classes),
      and technically that'd be possible, but seems like an
      administrative nightmare... a very high cost to pay for the 0.1%
      of names where case-sensitivity is important.<br>
      <br>
    </div>
  </body>
</html>

--------------040103040900080104070007--


--===============4826031613822591627==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext

--===============4826031613822591627==--