[Date Prev][Date Next]
Re: Characters in DN
I was reviewing the handling of '#' and noticed that it includes
a lot of BER parsing which should be left to -llber. That is,
when the '#' format is used, we should construct a BerElement
and then use ber_*() routines to extract what we need. We may
need to extend -llber a bit, but I rather we extend -llber than
construct custom BER code for DNs (and for ;binary).
At 11:26 AM 7/12/2001, David A. Cooper wrote:
>OK. I have modified the code to be more conformant with draft-ietf-ldapbis-dn-05.txt. Now, the '=' character is not escaped in the normalized string, and '#' is only escaped if it is the first character in an attribute value. I also added a note at the beginning of servers/slapd/dn.c listing the functions in that module that I wrote and specifying that that code is in the public domain (i.e., it is not subject to copyright).
>A new patch file is now available for download from http://csrc.nist.gov/pki/testing/openLDAP_contrib.html.
>If you have any other suggestions for changes to the code, please let me know.
>At 08:28 AM 7/12/01 +0200, Pierangelo Masarati wrote:
>>"David A. Cooper" wrote:
>> > > I have only one question. You treat '=' and '#' as
>> > > characters that need to be escaped. While rfc 2253
>> > > says implementations may escape other characters,
>> > > it doesn't require them to be treated as special except
>> > > in type/value separation (=) and beginning of string (#).
>> > > I think you should handle them differently.
>> > In my code, I compromised. The dn_validate/dn_normalize functions will
>> > take as input DNs that contain unescaped (=)'s and (#)'s, but in the
>> > normalized form they are escaped. So for example, the input "cn= ===###" is
>> > accepted, but the output is "CN=\=\=\=\#\#\#".
>> > I see that the BNF in draft-ietf-ldapbis-dn-05.txt is different. It defines
>> > stringchar as:
>> > stringchar = <any UTF-8 character (can be multiple octets)
>> > except one of escaped or ESC>
>> > escaped = "," / "+" / """ / "<" / ">" / ";"
>> > So, while the BNF of draft-ietf-ldapbis-dn-05.txt is clear that '=' and '#'
>> > do not need to be escaped, the BNF in RFC 2253 suggests otherwise (in
>> > contradiction to the text of RFC 2253).
>>As Kurt said, we'd better stick with draft-ietf-ldapbis-dn-05.txt,
>>so your code is OK although it may be improved to obtain a strict
>>adherence to draft-ietf-ldapbis-dn-05.txt, which is preferable.
>> > To some degree, the issue is somewhat academic though. The code will accept
>> > DNs with unescaped '=' and '#' and the normalized versions of the DNs, with
>> > the '=' and '#' are definitely compliant with RFC 2253. The only question is
>> > whether a few bytes are being wasted by including escape characters where
>> > they may not be absolutely necessary.
>>We're not talking about wasting chars :)
>> > However, if people feel that this is important, I'll look into changing the
>> > code to avoid escaping '=' and '#' (unless the '#' is the first character in
>> > the string).
>> > > Someone who's directly involved in unicode stuff
>> > > should check the UTF part before anything is added.
>> > > I'm totally stuck with it at present (see why we need
>> > > ITS?)
>> > That would be helpful. Originally, Stig Venås incorporated unicode
>> > normalization into the dnNormalize function by making a call to
>> > UTF8normalize. I used the UTF8normalize function as a guide in order to
>> > directly incorporate calls to uccanondecomp and uccanoncomp into my code. I
>> > tried it out with a few simple examples, and the code seems to be handling
>> > unicode normalization properly, but it would certainly be helpful to have
>> > others test it out as well.
>>If there's no objections, I'll incorporate your code under
>>#ifdef to ease testing by other users.Thanks for contributing.
>>Another note: I guess OpenLDAP needs a copyright statement
>>in your code, as it is a big chunk of work. You may check out
>>As I see there's a nice statement from the US Government that
>>puts this code in the public domain, you may simply use the basic
>>suggestions you find in the above mentioned page, augmented by
>>that statement. You may modify your patch, or simply send a
>>followup to your ITS (reply to the message you got from the its).
>>You have to do this because copyright statements in principle
>>cannot be changed by others (I guess).
>>Dr. Pierangelo Masarati | voice: +39 02 2399 8309
>>Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
>>Politecnico di Milano | mailto:email@example.com
>>via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati