Hi Noriko,<br><br>i've read the design document <a href="http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format" target="_blank">http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format</a><br><br>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?<br>
<br>Here is the commit comment for that parameter :<br><br>commit 0410819d48795fca4faf986cf8658c34c4d929e3<br>Author: Nathan Kinder <<a href="mailto:nkinder@redhat.com">nkinder@redhat.com</a>><br>Date: Wed May 13 11:12:11 2009 -0700<br>
<br> Add strict DN syntax enforcement option.<br> <br> The DN syntax has become more restrictive over time, and the<br> current rules are quite strict. Strict adherence to the rules<br> defined in RFC 4514, section 3, would likely cause some pain to<br>
client applications. Things such as spaces between the RDN<br> components are not allowed, yet many people use them still since<br> they were allowed in the previous specification outlined in RFC<br> 1779.<br>
<br> To deal with the special circumstances around validation of the DN<br> syntax, a configuration attribute is provided named<br> nsslapd-dn-validate-strict. This configuration attribute will<br> ensure that the value strictly adheres to the rules defined in RFC<br>
4514, section 3 if it is set to on. If it is set to off, the server<br> will normalize the value before checking it for syntax violations.<br> Our current normalization function was designed to handle DN values<br>
adhering to RFC 1779 or RFC 2253<br><br>Concerning the logic of escaping/unescaping/normalisation we could test how openldap behaves in each case (as you've made it in "DN HEX HEX" bug).<br><br>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? The sensitive part here is the whole o-NetscapeRoot tree: console using and writing this type of values, replication agreement/management etc<br>
<br>As for the "related bugs" section i think another bug should be added (<a href="https://bugzilla.redhat.com/show_bug.cgi?id=199923" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=199923</a>), it concernes the same RFC4514 compliance.<br>