Re: Open issues with the Java LDAP API draft

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:13 PM 1/21/01 -0800, Rob Weltman wrote:
>  These are the issues that have been raised (that I am aware of) with the latest Java LDAP Internet Draft (http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-12.txt), along with my own proposals for disposition.

I have a few other issues.  Many of these have been
discussed previously.

The API appears to support both LDAPv2 and LDAPv3 but appears
to assumes use of UTF-8 regardless of the protocol.  LDAPv2
directoryStrings are restricted to T.61.  In addition, certain
LDAPv2 protocol strings (e.g. all LDAPStrings) are restricted
to IA5.  If LDAPv2 is to be support, it should be fully
supported and a normative reference to LDAPv2 should be stated.
If LDAPv2 is not to be supported, all mention of LDAPv2 should
be stricken.  I believe this API should not attempt to support
both LDAPv2 and LDAPv3.  As LDAPv2 will be moved to historical
status upon publication of an LDAPv3 Draft Standard, I recommend
this API support only LDAPv3.

API contains a reference to RFC 1823, an Informational RFC.
If this is non-normative, it should be noted.  If normative,
there is a standard track maturity issue in that RFC 1823 is
informational.  It appears to be normative to me.  

The abstract refers to the expired async API I-D unnecesarily.

It appears that the API specification requires implementation
of LDAP Language Tags, an extension to the "core" protocol
specification.  The core API should only require implementation
of the "core" protocol specification.  APIs for non-core
extensions should be detailed in API extensions.

Java, IIRC, uses UCS-2.  LDAP allows the full (31-bit) set of
ISO-10646-1 characters encoded in UTF-8.  There should be some
comment as what is to be done with characters outside of UCS-2
but with ISO-10646-1.

There should be a normative reference to Java language
specification(s) [core + required extensions (SASL/TLS)].
The relationship with JNDI should also be discussed.

Appears the default behavior is to chase referrals.  As I've
noted previously on this list, this is not a wise default from
a security perspective.  The default should be not to chase
referrals (period).

LDAP_PARTIAL_RESULTS?  There should be no mention of this.  However,
I note that the API should be capable of treating unrecognized
result codes returned by servers (including those reserved by API
specifications) as unknown errors.

Missing normative references:
        Java API Spec
        Java SASL API Spec
        Java TLS API Spec
        ldaps (LDAP over SSL)
        RFC 2222, RFC 2829, RFC 2830

Kurt