Re: Open issues with the Java LDAP API draft

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 10:14 PM 1/28/01 -0800, Rob Weltman wrote:
>> 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?

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.

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

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

>> The relationship with JNDI should also be discussed.
>
>  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:
>>         Java API Spec

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



>>         Java SASL API Spec
>
>  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.

>>         Java TLS API Spec
>  What's the RFC number?

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

>>         ldaps (LDAP over SSL)
>
>  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.


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

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