[389-devel] DN normalisation design document

[Andrey Ivanov]

Hi Noriko,

i've read the design document
http://directory.fedoraproject.org/wiki/Upgrade_to_New_DN_Format

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?

Here is the commit comment for that parameter :

commit 0410819d48795fca4faf986cf8658c34c4d929e3
Author: Nathan Kinder <nkinder at redhat.com>
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
    1779.

    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 HEX" bug).

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

As for the "related bugs" section i think another bug should be added  (
https://bugzilla.redhat.com/show_bug.cgi?id=199923), it concernes the same
RFC4514 compliance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100317/8fa044f9/attachment.html