[Date Prev][Date Next]
Re: ldap_str2dn etc.
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
>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.
>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
>3) ldap_dn2str is NOT the opposite of ldap_str2dn, in the sense that
>the conversion should be a __MANY__ to __ONE__, right?
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
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
>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.