Subject: Re: Open issues with the Java LDAP API draft

From: "Steve Sonntag" <[email-masked]>
Date: Mon, 22 Jan 2001 10:47:12 -0700

Minor typo related to item 5.  The description of attrName

"See 4.3.5for the syntax and semantics"

needs a space after 4.3.5
.................................................................................
7. Bibliography

[7] should refer to draft version 05 of the ldap-c-api
..................................................................................

-Steve

------------------------
Steve Sonntag
Novell, Inc., the leading provider of Net services software

>>> Rob Weltman <[email-masked]> 21-Jan-01 6:13:31 PM >>>
  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

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

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

Rob: typo

---

From: "Steve Sonntag" <[email-masked]>
Date: Mon, 22 Jan 2001 14:44:28 -0700

Rob,

In looking at the LDAPConnection object, I think the text should
be clarified as to which methods affect / apply to the global connection
(the source object) v.s. an individual clone of the LDAPConnection 
object.  Here is my swag at it - omitting requests except bind, connect
& disconnect.

add/RemoveUnsolicitedNotificationListener - connection
bind - connection & and possibly clone - see note
          (Note: if disconnected when attempting bind, the 
          API attempts a reconnect which now makes it
          specific to the clone the bind is done on.  Is this
          the intended behavior? - see 4.6.4 & 4.6.5.  I vote
          that bind does not attempt reconnect, but throws an
          exception instead).
connect - clone
disconnect - clone
finalize - clone
getAuthenticationDN - connection
getAuthenticationMethod - connection
getAuthenticationPassword - connection
get/setConstraints - clone
getHost - connection
get/setInputStream - connection
get/setOutputStream - connection
getPort - connection
get/setProperty - clone
getProtocolVersion - connection
getResponseControls - clone
getSaslBindCallBackHandler - connection
getSaslBindProperties - connection
get/setSearchConstraints - clone
getSocketFactory - connection
setSocketFactory - static connection
isBound - connecton
isConnected - connection
is/startTLS - connection

-Steve

------------------------
Steve Sonntag

---

From: "Steve Sonntag" <[email-masked]>
Date: Tue, 23 Jan 2001 10:56:10 -0700

Rob,

I think the wording for the method getResponseControls in the
LDAPConnection class needs to be clarified slightly to clarify
that it applies only to non search operations, e.g.

"Returns the latest Server Controls for non search  operations
returned by a Directory Server with a response to an LDAP
request from the current thread, or null if the latest
response contained no Server Controls."

-Steve

------------------------
Steve Sonntag

Rob

---

From: "Steve Sonntag" <[email-masked]>
Date: Wed, 24 Jan 2001 09:50:28 -0700

LDAPReferralException 

4.27 public class LDAPReferralException 
                  extends LDAPException 
    
   This exception, derived from LDAPException, is thrown when a server 
   returns a referral and automatic referral following has not been 
   enabled. 

Add to the above

    or automatic referral following could not follow any referrals.

-Steve

---

From: Rob Weltman <[email-masked]>
Date: Wed, 24 Jan 2001 09:10:55 -0800

Steve Sonntag wrote:

>   LDAPReferralException 4.27 public class LDAPReferralException
>                   extends LDAPException
>
>    enabled.Add to the above     or automatic referral following could not follow any referrals. -Steve

  That sounds hard to handle for a client. Are you thinking of the case where the referral points to a server which is inaccessible or which doesn't accept the credentials of the requestor? How would the client know which of those problems was being flagged if there is only a referral exception? And consequently, how would the client know what to do about it?

Rob

---

From: "Steve Sonntag" <[email-masked]>
Date: Thu, 25 Jan 2001 09:48:37 -0700

Actually, I was only taking the information given in the constructor
and copying it to the introduction of the class.

  public LDAPReferralException(String message,
                                LDAPException rootException)

   Constructs a default exception with a specified string as additional
   information and an exception that indicates a failure to follow a
   referral.  This exception applies only to synchronous operations and
   is thrown only on receipt of a referral when the referral was not
   followed.

As I was looking at this, I wondered if LDAPException is
too restrictive.  For example what is reported for a malformed URL?
We cannot report MalformedURLException as it is of type Exception.
Should the rootException be simply of type Exception?

Should the ReferralException class use matchedDN to indicate
which referral caused the problem, or is that overloading that field too much.

-Steve

---

From: "Steve Sonntag" <[email-masked]>
Date: Thu, 25 Jan 2001 14:49:38 -0700

4.6.22 getResponseControls

.... The method always returns null for asynchronous requests.

I believe what is meant here is that controls are never stored
for asynchronous requests.  I don't believe it means that
if an application makes a synchronous request, then
follows it up by an asynchronous request, that the
asynchronous request destroys any control data
stored from the synchronous request, i.e. stores null
where the last control is saved for that thread.

---

From: "Steve Sonntag" <[email-masked]>
Date: Thu, 25 Jan 2001 14:59:50 -0700

There are several methods that an application will never use:

LDAPConnection.setInputStream
LDAPConnection.getInputStream
LDAPConnection.setOutputStream
LDAPConnection.getOutputStream
LDAPControl.newInstance

It is my feeling that these should not be defined in the Java API draft,
even though functions like these may be defined as public in
some implementations.  These implementions use these in the API itself, 
but the application does not use them.

These functions force an implementation style, but the draft should not
force any style of implementation.  The draft should define only the application
interfaces.

These methods should be removed from the draft.

-Steve

------------------------
Steve Sonntag

---

From: Rob Weltman <[email-masked]>
Date: Thu, 25 Jan 2001 14:16:44 -0800

That would kill interoperability. A SASL layer that worked with one implementation of the LDAP API would not work with another, and a control written for one implementation would not work with another implementation.

Rob

Steve Sonntag wrote:

>    There are several methods that an application will never use: LDAPConnection.setInputStreamLDAPConnection.getInputStreamLDAPConnection.setOutputStreamLDAPConnection.getOutputStreamLDAPControl.newInstance It is my feeling that these should not be defined in the Java API draft,even though functions like these may be defined as public insome implementations.  These implementions use these in the API itself,but the application does not use them. These functions force an implementation style, but the draft should notforce any style of implementation.  The draft should define only the applicationinterfaces. These methods should be removed from the draft. -Steve ------------------------
> Steve Sonntag