Re: ldap_str2dn etc.

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

At 05:15 AM 2001-10-02, Pierangelo Masarati wrote:
>I started working on the string 2 dn.  I'm trying to make clear what
>is to be done.  I'll enumerate some points I'd like to be fixed.
>Some of them may look trivial, but a) I'm not sure I always understand
>English correctly, and b) sometimes RFCs and other documentation
>seem a bit obscure, regardless of the efforts for clarity of the
>writers.
>
>1) ldap_str2dn is intended to give a a) tokenized, b) normalized 
>__STRING REPRESENTATION__ of a DN, right?

ldap_str2dn() takes as input a string representation of a
DN and produces a structural representation of the DN.

>I mean, the DistinguishedName
>will be broken in RelativeDistinguishedName, which will be broken 
>AttributeTypeAndValue items, each of which, on turn, will be broken 
>in AttributeType and AttributeValue.

Yes.

>In the meanwhile, the
>AttributeType will be __UPPERCASED__

No.  It places the AttributeType parsed from the string into
the AttributeType into the LDAPDN structure.  No modification.

>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.

>3) ldap_dn2str is NOT the opposite of ldap_str2dn, in the sense that
>the conversion should be a __MANY__ to __ONE__, right?

consider:
        dnout = str2dn(dn2str(dnin))
        strout = dn2str(str2dn(strin))

dnout should equal dnin.  While strout is equivalent to strin,
they may not be equal.

Note that strout here is not the same as what dn_normalize()
nor dn_normalize_case() produces.  That requires additional
work.

        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.

But, for slapd purposes, two functions are needed.  A DN
"normalizer" and a DN "pretter".  The "pretter" is basically
the ldap_dn_normalize(), but the "normalizer" actually involves
"normalizing" each value of each AVA per its syntax.

>If the LDAPv3 string representation of the DN is required, then
>ldap_dn2str will basically concat all its pieces; so this conversion
>is expected to be very efficient, as opposed to the ldap_str2dn, right?

Both are efficient in the sense they just convert between
forms of representation.

>4) it is relatively clear what LDAPv3 DN string representation is;

Be sure to follow the LDAPbis DN draft for LDAPv3.  It is even
clearer than 2253.

>I've figured out the LDAPv2 differences (I hope I didn't miss anything:
>to this purpose I plan to prepare a white paper on the implementation
>to ease specifications adherence and bug track/changes).  I have a
>vague idea of what UFN is (and its support, I guess, is not a priority).

See RFC 1777 for LDAPv2 and UFNs.

>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.

>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.

>6) finally, I admit I'm a bit ignorant on Unicode stuff; I see from
>RFC 2253 that the string representation of the values in unicode
>must be given by escaping with '\' the exadecimal representation of 
>the bytes of each Unicode symbol.  I guess I need to treat all the
>strings that may be Unicode encoded by means of the ldap_utf8* funcs.

For str2dn, one just needs to decode each escaped octet.
For dn2str, each octet which is not a valid octet of a UTF-8
character MUST be escaped.  Other octets MAY be escaped.
This is were flags come in.  When escaping an octet which
is part of a multi-octet UTF-8 character, each octet of the
UTF-8 character must also be escaped.  The LDAPbis draft
may be clearer here.