[389-devel] DN normalisation design document

[Noriko Hosoi]

On 03/17/2010 01:13 PM, Andrey Ivanov wrote:
>
>>     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.
>
> Ok. What i wanted to say is that we should avoid any new config 
> parameters in cn=config. The way you propose to handle the problem is 
> the best one - it is completely transparent to the user, the server 
> back-end "sees" only the normalised DNs so it does not complain and no 
> additional configuration
> parameters are necessary.
>
>     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?
>
> No, absolutely not, i agree completely with your reasoning. The code 
> should be strict but not completely rigid :) Taking care of the 
> "legacy" presentation in a transparent manner is the ideal solution.
>
>
Thanks so much for the confirmation, Andrey.  I'm working on the issue 
based on the design...
--noriko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100317/966deacb/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6646 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/389-devel/attachments/20100317/966deacb/attachment.bin