========================================================================
How is T.61<->iso8859-1 conversion of ldap requests and results intended
to be done -- if any thought been given to it? Many programs do not
convert at all. I tried to figure out where it would be best to put it,
and ended with rather conflicting interests. For example, I wonder if
it's a choice between doing it easily at just a few places, or doing it
correctly but at nearly every printf...
* Can I safely run all returned values through a T61->iso filter, or is
some rudimentary parsing enough to recognize that (a part of) an
attribute should be unT61ified?
Or do we need to check against known attributes first (meaning that
the client needs a copy of the oidtables), and parse attributes such
as postalAddress, or - aargh - a T.61 component of a postalAddress or
DN inside an iattr inside an iattr:-(
And is there anything special about DNs with T61 in this respect?
* I presume unT61ifying must be done *before* ldap_friendly()
conversion, or would the right thing actually be to put T.61 strings
in ETCDIR/ldapfriendly instead of iso8859-1 chars? (Otherwise
iso8859-1 chars from ldapfriendly would be "converted from T.61".)
* "Real" unT61ifying (unlike the more-or-less correct ISODE variant)
can create "meaningful" chars, for example \a4 -> '$' and \a6 -> '#'.
I guess we can forget about doing such translations in any convenient
way -- on attributes like postalAddress or iattr, for example?
* Then there is the cursed trouble that a string converted from T.61
cannot be converted back T.61, so programs must often keep the T.61
version of a string around while showing the user a converted string.
A lookup/search of an iso8859 DN should convert to T.61, after all.
If it can guess which conversion the user wanted:-(
Well, actually it seems better to "down-convert" searches to iso646
(i.e remove acccents and so on), because downconverted values are
often stored in the Directory - often even as DNs - while search for
T.61 is buggy in quipu. Wildcards + T61 do not live well together,
for example.
Of course this is not really an ldap issue, just common enough that it
would be useful with *some* library with a standard way of handling
it. Maybe a datastructure {T61val, convertedVal} or a cache.
BTW, one other question: How does ldap like that I modify a result
string from LDAP (if it is not made longer of course)?
Regards,
Hallvard B Furuseth
UNINETT Directory Service, Norway email: katalog-hjelp@uninett.no