Re: Open issues with the Java LDAP API draft

[Rob Weltman <robw@worldspot.com>]

"Kurt D. Zeilenga" wrote:
> 
> 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.

  It only supports LDAPv3. It explicitly supports only UTF-8, and it mentions LDAPv2 in pointing out that controls are not supported in LDAPv2. I'll remove that clarification.

 
> 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.

  Yes, it is not necessary to reference either of those.

 
> 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.

  They are very important to developers in environments where directory data is multi-lingual, and they have been heavily used to date. I think they should stay.

 
> 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.

  Which characters are you thinking of? As far as I know none have yet been defined outside the lower 64k. If Unicode characters should be defined in the future beyond the 16-bit range, that will be a problem for all Java programs and for the Java language itself, not for LDAP in particular. Whatever solution is adopted for the Java language should also be adopted by any Java class libraries, including this one.

 
> There should be a normative reference to Java language
> specification(s) [core + required extensions (SASL/TLS)].

  To what, more specifically?


> The relationship with JNDI should also be discussed.

  Not relevant to this document.

 
> 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).

  Steve pointed out:

At 10:04 AM 1/23/01 -0700, Steve Sonntag wrote:
>The default behavior for following referrals is specified in
>the LDAPConstraints object.  The boolean doReferrals parameter
>controls whether referrals are followed or not.  The default
>for this parameter is "FALSE", i.e. referrals are not
>automatically followed [period].  See also 4.7.8.

 
> 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.

  I'll remove the reference to LDAP_PARTIAL_RESULTS, since an implementation of the API is no longer expected to work an LDAPv2 server.

 
> Missing normative references:
>         Java API Spec

  ?


>         Java SASL API Spec

  What's the RFC number?


>         Java TLS API Spec

  What's the RFC number?


>         ldaps (LDAP over SSL)

  What's the RFC number?


>         RFC 2222, RFC 2829, RFC 2830

  I'll add a reference to 2222 for SASL and to 2830 for TLS, but where would the reference to 2829 go?

Rob

> 
> Kurt