Re: Summary of issues with the Java LDAP API and resolutions

[Rob Weltman <robw@coscend.com>]

"Kurt D. Zeilenga" wrote:
> 
> >> I note that LDAP use of TLS (RFC2830, 4.1) allows for LDAP data to
> >> be sent over the TCP stream after a TLS closure.  Application
> >> notification of changes in security services provided is critical.
> >
> >  Hmmm, that's interesting. Are you aware of any TLS implementations that allow this?
> 
> I believe OpenSSL does.
> 
> >I had discussions with the inventors of SSL (the precursor to TLS) back at Netscape about just that and they didn't think it was realistic for a connection to be continued to use for non-TLS exchanges on terminating the TLS session. I know that RFC 2246 section 7.2.1 leaves the question open.
> >  If it is realistic, we'll address it. If not, RFC 2830 should change.
> 
> I believe it should be addressed in the API.

  I have to think about that a little more.
 

> >> >> Also, I note it would be useful if methods of LDAPUrl
> >> >> (4.41.1) distinguished between an explicit and default
> >> >> parameters of an LDAP URL.  For example getScope() could return
> >> >> SCOPE_DEFAULT if an explicit scope wasn't provided.  As
> >> >> this behavior is likely only useful to applications
> >> >> doing their own referral/reference chasing, likely
> >> >> best to have some means to enable/disable this behavior.
> >> >
> >> >  Unnecessary complication.
> >>
> >> Unnecessary unless an application needs to implement their
> >> own chasing...
> >
> >  Unnecessary in that case, too.
> 
> Unnecessary in that the application can implement it's own
> LDAP URL parsing because this class doesn't address the needs
> of such applications.

  An application is always free to do its own LDAP URL parsing, and there will undoubtedly always be applications that choose to do so. But all applications that implement their own chasing of referrals do not need to distinguish between explicit URL parameters and implied URL parameters. As a matter of fact, in the years I've worked with the Java LDAP API and applications that did their own referral processing, I haven't seen a single such case. The effective URL is what matters other than on error, and on error the literal URL is available to present to the user or a log file.

 
> >> >13. > I would assume "thread-safe" is a term defined in the Java
> >> >> technical specification.  As this requirement is a MUST, I
> >> >> would suggest a normative reference to the specific definition
> >> >> of the term would be appropriate.
> >> >
> >> >  The Java Technical Specification at http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#30206 does not mention thread-safety, but thread-safe is not a Java term but rather a general programming concept applicable to any language supporting threads. We are not aware of a normative reference, but we could provide one from a dictionary if necessary.
> >>
> >> Because of the MUST, I think you need to be more specific
> >> in what is required by the implementor.
> >
> >  Thread-safe is a well-known and well-understood programming concept, but it is not defined in the Java Technical Specification (that applies to many other programming concepts as well).
> 
> Well I agree that "thread safe" is generally understood concept,
> I note it has numerous definitions.  My dictionary has two which
> have subtle but significant differences.  Given the MUST, I assume
> there are specific requirements which must be met and these
> subtleties matter.

  There are no specific requirements other than that it be safe for more than one thread to invoke the method simultaneously, which it is what thread-safe means.

 
> >> >> Also, how do implementations indicate which additional
> >> >> classes and methods are thread-safe?
> >> >
> >> >  By stating that they are thread-safe in the documentation for the implementation.
> >>
> >> A documentation provided for an implementation should not
> >> be viewed as part of implementation.  I do not believe
> >> it appropriate for the TS to contain any particular
> >> documentation requirements.
> >>
> >> I would assume this API provides source-level interoperability.
> >> If a developer has to read each APIs document, than there
> >> is not source-level interoperability.
> >
> >  APIs are interoperable even if one is thread-safe and one is not,
> >as long as the user of the APIs is aware of the situation. The users of APIs become aware of the APIs and their characteristics by reading the documentation.
> 
> In my opinion, it is inappropriate for a user to have to read
> any particular's documentation to use their implementation of
> the specification.  The whole point of standardization is to
> free the user from having to code to specific implementations.
> An API TS which fails in this regard, is not appropriate for
> the standard track.

  The proposed API guarantees that a developer can code to one definition and it will work on any implementation of the API. However, if the developer wants to take advantage of additional features beyond what is specified in the standards document for the API in a particular implementation, the developer will have to read the documention for that implementation. There is no way around it. In the case under discussion, an application which assumes a method is not thread-safe will work also if the method is thread-safe.

 
> I believe the TS should include a statement as to level
> of interoperability which it intends to provide. I presume
> the TS aims to provide source-level compatibility.

  The API provides binary compatibility which is stronger than source-level compatibility (which may require you to recompile an application when using a different implementation of the API). But of course, here as anywhere else, if a particular implementation provides additional features and a developer choose to take advantage of them, the developer can't assume the same features are available in every other implementation.

Rob