Re: ldap_str2dn etc.

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 09:42 AM 2001-10-02, Pierangelo Masarati wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> >2) what's the best way to check attribute description from a library
>> >function, i.e. not from inside slapd?  Which functions do address the
>> >problem? Or, in other words, do I need to (hard)code RFC 2252 attribute
>> >types somewhere in the library?
>> 
>> Even in pedantic mode, I suggest not restricting the attributeType
>> by name to a table.  Maybe we can have a table flag that uses
>> hardcoded or application provided tables.  But let's skip that for
>> now.
>
>Does this mean I'd leave AttributeTypes as they are (string or OID)
>without reformatting them, regardless they're "common" or not?

Yes.  Any normalization of the AttributeType NAMEs should be done
outside of the str2dn and dn2str, e.g. in a normalize() function:
        strout = dn2str(normalize(str2dn(strin)))

>> can do some simple normalizations of LDAPDN, such as sorting
>> AVAs within a multi-valued RDN.  This is what ldap_dn_normalize
>> is intended to wrap.
>
>Well, I've seen something about sorting AVAs within RDNs (RFC 2253):
>        When converting from an ASN.1 RelativeDistinguishedName to a string,
>        the output consists of the string encodings of each
>        AttributeTypeAndValue (according to 2.3), in any order.

In BER, one has an unordered SEQUENCE of RDNs.  So, when generating
a string, any order can be used.  But dn2str() should, however,
generate the string encoding using the order of the AVAs in the
LDAPDN representation.   Sorting of AVAs in the LDAPDN representation
should be done outside of str2dn and dn2str, e.g. in a normalize()
function.

>> >But I'm a bit in trouble with DCE. What's the best source of information
>> >on it (I mean the best within dn string representation issues)?
>> 
>> See Luke's comment.
>
>Maybe I'll introduce an extra flag LDAP_DN_AD_CANONICAL.

Hmmm... guess I'll have to re-read Luke's comment.  Note how
I intend to separate conversion of format from normalization.

>> >5) I guess the "LDAP_DN_PEDANTIC" flag means "strictly adhere to the
>> >standards"; as a consequence the parsing should be as liberal as
>> >possible
>> >if the flag is not set, right?
>> 
>> Yes.  There might be degrees of pedantic that make sense.
>
>I'll figure out a list of possible liberals, and code them in flags.
>We may also group liberals in appropriate masks that make sense
>altogether.

Yes, the default (0) being fairly liberal.  Bits of may have to
changed to provide additional liberals or to remove default
liberals.

Kurt