[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
ldap_str2dn etc.
Kurt,
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? 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__ if it belongs to the list of types
reported in RFC 2253 (2.3). This list is reported "As an example ...",
so will other types be allowed? RFC 2252 is cited as a reference, so
are ALL the types listed in it eligible for string representation in
the structure? This implies a lot of lookup to check if a type can
be string-represented. Otherwise the OID will be used.
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?
3) ldap_dn2str is NOT the opposite of ldap_str2dn, in the sense that
the conversion should be a __MANY__ to __ONE__, right?
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?
4) it is relatively clear what LDAPv3 DN string representation is;
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).
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)?
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?
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.
Thanks for the clarifications.
Pierangelo.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy |
http://www.aero.polimi.it/~masarati