Open issues with the Java LDAP API draft

[Rob Weltman <robw@worldspot.com>]

  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.