Thanks for your comments, Andrey!
On 03/17/2010 08:02 AM, Andrey Ivanov wrote:
i've read the design document
In order to support "Old DN format including DN in the double quotes"
another cn=config switch may be necessary. It seems there was recently
a new switch introduced to make the dn syntax validation a little more
"relaxed" - nsslapd-dn-validate-strict. Maybe this one could be used
to allow for DNs with double-quoted values?
Actually, the way how we are going to
handle the old style 'dn:
<type>="<nested dn>",<the rest>' is converting the old
style to a new
style in the normalization when the server receives DNs from clients and
the converted new style DN is used in the rest of the process. The
nsslapd-dn-validate-strict value is examined in the DN syntax validation
code for now. Unless we change it, the DN syntax validation code always
receives the new DN style.
That being said, are you suggesting if nsslapd-dn-validate-strict is on,
we should not convert an old style DN to a new style? That'd be really
strict. I'm leaning toward to the other side accepting the both old and
new style with no restriction. Do you see any disadvantages in allowing
the old style?
Here is the commit comment for that parameter :
Author: Nathan Kinder <nkinder(a)redhat.com <mailto:firstname.lastname@example.org>>
Date: Wed May 13 11:12:11 2009 -0700
Add strict DN syntax enforcement option.
The DN syntax has become more restrictive over time, and the
current rules are quite strict. Strict adherence to the rules
defined in RFC 4514, section 3, would likely cause some pain to
client applications. Things such as spaces between the RDN
components are not allowed, yet many people use them still since
they were allowed in the previous specification outlined in RFC
To deal with the special circumstances around validation of the DN
syntax, a configuration attribute is provided named
nsslapd-dn-validate-strict. This configuration attribute will
ensure that the value strictly adheres to the rules defined in RFC
4514, section 3 if it is set to on. If it is set to off, the server
will normalize the value before checking it for syntax violations.
Our current normalization function was designed to handle DN values
adhering to RFC 1779 or RFC 2253
Concerning the logic of escaping/unescaping/normalisation we could
test how openldap behaves in each case (as you've made it in "DN HEX
Yes, I did. :) I found they are correctly handling the cases
escaped characters and non-ASCII UTF-8 characters in the seamless manner.
For upgrades/migrations and double quotes in DNs: the two values may
be left during the upgrade (just in case someone uses them as-is) and
then an optional validation/cleaning script could be provided separately?
right. That should work. I'm adding the validation/cleaning script
to the design memo.
The sensitive part here is the whole o-NetscapeRoot tree: console
using and writing this type of values, replication
As for the "related bugs" section i think another bug should be added
), it concernes the
same RFC4514 compliance.
Oops. That's right. I'm adding it, too.
Thanks so much for your comments.