LDAPv2 with draft-ietf-ldapext-ldap-c-api-01

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

The draft defines everything in terms of LDAPv3 - sometimes explicitly,
other times implicitly.  For example,

"5.  Overview of LDAP API Use" says:

> As in the LDAPv3 protocol itself, all DNs and string values that are
> passed into or produced by the C LDAP API are represented as UTF-8[10]
> characters.

"9.6. Searching" says:

> filter       A character string as described in [3] (...)

where [3] is rfc2253.

This seems to mean that if we connect to an LDAPv2 server, the API must
translate LDAPv3 input to LDAPv2 format and LDAPv2 output to LDAPv3
format.  (Different charset, different quoting mechanism for non-ASCII
data, different quoting of filters, and probably lots of other stuff.)

The draft does say

> For compatibility with existing applications, implementations of this
> API will by default use version 2 of the LDAP protocol.  Applications
> that intend to take advantage of LDAP version 3 features will need to
> use the ldap_set_option() call with a LDAP_OPT_PROTOCOL_VERSION to
> switch to version 3.

but I'm not quite sure what this means here, when you explicitly say we
use the LDAPv3 formats.

Anyway, general and safe translation between T.61 (in LDAPv2) and UTF-8
is impossible because the client may not know the attribute types of all
the attributes, and binary attributes should not be translated.

OTOH, I think you could auto-translate betweenI the LDAPv2 quoting
mechanism in filters and the LDAPv3 quoting mechanism.

Auto-translation would be nice, though.  Otherwise an LDAPv2-aware
LDAPv3 client must deal with this itself.  I can't think of a non-kludge
to fix that, though: Add some LDAPv2-translation calls for various data
types?  An ldap_set_option() to auto-translate known attribute types and
filters, and give an error if the API can't auto-translate something?
Or do we just assume clients and servers handle this properly (like all
these "UTF-8 LDAPv2" servers we get nowadays)?

-- 
Hallvard