Title: #298: ipaldap: handle binary encoding option transparently
`ipaldap` is not the proper place to handle this - it implements a (almost)
generic LDAP client, not a 389 DS client, and as such should not contain any
389 DS specific hacks. The premise is that the server gets exactly what the
user of `ipaldap` requested, and the user gets exactly what the server returned.
The binary transfer option is currently handled in code of the affected
commands. The next layer below is `baseldap`, which is where the handling
should be moved to make it generic for all commands.
Also note that the real bug in 389 DS is that it defines the attribute types to
use octet string syntax, rather than the certificate syntax as defined in RFC
4523. It actually behaves correctly, not enforcing the binary transfer option
on attribute types with octet string syntax.
See the full comment at
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code