Re: Distinguished name format & RFC 1779

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:59 AM 8/25/99 +0200, Frédéric Poels wrote:
>At 11:31 24/08/99 -0700, you wrote:
>>At 06:28 PM 8/24/99 +0200, Frédéric Poels wrote:
>>>When adding (1) with openLDAP 2.0-alpha2, everything workd fine, I get
>>>'o=HOME'
>>>                -> ldapsearch -b "o=HOME" -s base "objectclass=*" succeeds
>>>When adding (2), I get 'o="HOME"' with double quotes which is not
>>>equivalent to (1)
>>>                -> ldapsearch -b "o=HOME" -s base "objectclass=*" fails
>>
>>Yes, this is one of the features not yet implemented.
>
>What will happen when this will be implemented?

Well, we'll have to wait and see...  but likely the exact form of
the DN provided with the ADD operation will be stored in the directory
and that this would be returned by the search (with minimal rewriting
to conform to RFC2253, Section 4).   Matching would be done in
normalized space such that alternative quoting/escaping would still
match.

That is,
	cn=foo\+\+\+
or
	2.5.4.3="foo+++"
or
	commonName=#666f6f2b2b2b
or
	cn=foo\2b\2b\2b

or ...

are all the same DN.  

I am planning on updating the clients (but not the client SDK)
to fail if an invalid DN is provided.  You'll be able to disable
this feature.

Hence, ldapsearch -b 'cn=foo+++' '(objectclass=*)'

will return INVALID DN without contacting the server.  If the
DN is valid (or the check is disabled), the clients will
send the DN "as is" to the server.  If the server determines
that the DN is invalid (which the above DN is), it should
return INVALID DN.


>In my opinion (1) is much more natural (it's "shell" like: 'export o=HOME'
>and 'export o="HOME"' set value 'HOME' and not '"HOME'" to the environment
>variable 'o') but posts about "distinguished name++" seem to indicate that
>(2) will be the answer. I'm wondering why distinguished names are not
>stored in a "canonical" format that would allow easy comparison?
>
>The reason I'm so interrested about that is that I'm using 3 directory
>servers that should exchange information. I was thinking about OpenLDAP as
>the 3rd one but that will only work if it's able to manage distinguished
>names containing '+' signs the same way the 2 already populated servers do.

We plan on implementing RFC2253 DN requirements.

>Many clients are already in production, they issue ldapsearch('foo=bar++')
>and not ldapsearch('foo=bar\+\+').

If the client sends a DN 'foo=bar++' OVER THE WIRE it should expect an
invalid DN (or similiar) error.   A client, of course, is free to
accept foo=bar++ from the user and rewrite it into an acceptable
form before submitting the LDAP operation.

Kurt