Subject: Open issues with the Java LDAP API draft

From: Rob Weltman <[email-masked]>
Date: Sun, 21 Jan 2001 17:13:31 -0800

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.

  Nothing major, I don't think, and I'd like to conclude discussion on them in a week or so and update the Internet Draft.

Rob

1.-------------------------------------------------------------------

4.23 public class LDAPNameFormSchema 
                 extends LDAPSchemaElement 
     
    The LDAPNameFormSchema class represents the definition of a Name 
    Form. It is used to discover or modify the allowed naming attributes 
    for a particular object class. See [2] for a description of SAME form 
    representation in LDAP.
  
 second to last line should be (error in caps)
  
    for a particular object class. See [2] for a description of NAME form 

Rob: typo

2.-------------------------------------------------------------------

In sections 4.6.7, 4.26.1, 4.38.1, and 4.40.1, "host" is defined as
a hostname or dotted string which may include trailing colon and port
number.  This does not allow IPv6 addresses to be specified, and
should be changed to comply with RFC 2732:

      host          = hostname | IPv4address | IPv6reference
      ipv6reference = "[" IPv6address "]"

For example:

      "[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80"
      ldap://[3ffe:2a00:100:7031::1]:1050/o=abc

Rob: OK

3.-------------------------------------------------------------------

 One change that I suggested was way off base now
 that I look at it again.  That change is the
 change of values of the LDAP operation constants
  
 BIND_REQUEST 0 -> 0x60
  
 etc.
  
 That is certainly one thing I didn't read carefully
 enough.  Somehow I got it into my head
 that it was a numeric sequence, but on a more careful
 examination, the numbers come straight from
 RFC 2251.  I think that next draft should
 put the numbers back the way they were
 before.  We shouldn't be encoding the
 operation values with the ASN1 constructed, primitive
 bits, etc., just the operation value itself.
  
 Sorry for the miscue
  
 -Steve

Rob: suggest reverting to the values listed in the prior draft.

4.a-----------------------------------------------------------------

It might be better to eliminate the current unsolicited notification methods and instead have methods to add and remove listeners for usolicited notifications. The implementation can then discard unsolicited notifications if there are no listeners: 

In LDAPConnection:

public void addUnsolicitedNotificationListener(
    LDAPUnsolicitedNotificationListener listener )

public void removeUnsolicitedNotificationListener(
    LDAPUnsolicitedNotificationListener listener )

New interface:

public interface LDAPUnsolicitedNotificationListener {
   public void messageReceived( LDAPMessage msg );
}

Rob: that's my proposal; it allows instant notification of unsolicited messages without polling, and I think that is what applications need.

4.b-----------------------------------------------------------------

From Kurt:
I believe there should be an explicit requirement:
  Implementations MUST generate requests with a non-zero message ID.

Rob: agree

5.-------------------------------------------------------------------

The draft is incorrect: LDAPEntry.getAttribute returns a single attribute, as does
LDAPAttributeSet.getAttribute. 

Rob: typo

6.-------------------------------------------------------------------

In the sample code for asynchronous search on in section 9.2 of IETF draft 12. The getReferrals() method should be used instead of getUrls().

Rob: agree

7.-------------------------------------------------------------------

So shouldn't both the input stream and the output stream be set
in one atomic operation so it is thread safe?

Rob: I don't think there is a need for that. It is easy to add a synchronized wrapper for the two methods if a particular implementation needs to guard against (for example) different threads asynchronously changing the input stream but not the output stream. Actually, if an application has threads doing that, it's asking for trouble anyway. You really don't want one thread changing the input and output streams (even if they are done simultaneously) behind the back of another thread.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 22 Jan 2001 22:47:32 -0800

>  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 m…

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

---

From: Rob Weltman <[email-masked]>
Date: Sun, 28 Jan 2001 22:14:48 -0800

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

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

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

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

> comment as what is to be done with characters outside of UCS-2

  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.

> specification(s) [core + required extensions (SASL/TLS)].

  To what, more specifically?

> The relationship with JNDI should also be discussed.

  Not relevant to this document.

> a security perspective.  The default should be not to chase

  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.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 29 Jan 2001 08:34:50 -0800

At 10:14 PM 1/28/01 -0800, Rob Weltman wrote:
>  Which characters are you thinking of?

RFC 2252, 6.2:
   Servers and clients MUST be prepared to
   receive encodings of arbitrary Unicode characters, including
   characters not presently assigned to any character set.

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

Yes.  My point here is that the API is NOT prepared to receive
encodings of arbitary Unicode characters.  

>Whatever solution is adopted for the Java language should also be adopted by any Java class libraries, including this one.

Then state this in the I-D.

>  To what, more specifically?

"The Java Language Specification", J. Gosling, et. al.,
Addison Wesley, Jun 2000.

>  Not relevant to this document.

I disagree.  I believe IETF Standard Track documents should provide
some background and intended use discussion when there are overlapping
specifications.  JNDI is a Java Standard Extension and this I-D
overlaps greatly with it.

>> Missing normative references:

I should have said "Java Language Specification".  See above.

>  What's the RFC number?

RFC number not required.  I suggest referring to the JCP
approved specification.  "Java SASL Specification",
JCP JSR#28, as I believe this is what the I-D depends on.

>  What's the RFC number?

I suggest "Java Secure Socket Extension",  ...,
available at http://java.sun.com/

>  What's the RFC number?

I don't have a suggestion here other than to remove support
for ldaps (LDAP over SSL) [the isSecure() method] as this
requires a normative reference to a specification with
appropriate standard track maturity.

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

I would reference 2829 where you introduce LDAP SASL Bind and/or
where you discuss authentication and authorization security
considerations specific to the API.