Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt

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

At 05:26 PM 10/1/00 -0700, Rob Weltman wrote:
>> Section 4.3.5:
>> --------------
>> "cn;lang-ja-JP-kanji" may be a subtype of "cn;lang-ja" - based on
>> recent discussions on this list, I don't think that this is true.  It
>> seems to me that "cn;lang-ja-JP-kanji" is really treated as a subtype
>> of "cn".
>> 
>> similarly, I think the example in this section need fixing as well:
>> 
>> getAttribute( "cn", "lang-en-us" ); does NOT return "cn;lang-en"
>> 
>> getAttribute( "sn", "lang-en" ); does NOT return "sn"
>> 
>> formating for description of "attrName" should be fixed.
>
>  I discussed the motivation for the behavior defined in the draft
>earlier in September.

Please note language tags have no structure and should not be
parsed. "cn;lang-ja-JP-kanji" is not a subtype of "cn;lang-ja"

Note that since LDAP language tags are an extension to LDAP "core"
protocol, I suggest that LDAP Java API language tag likewise be
an extension and detailed in a separate TS.

>> Section 4.3.8:
>> --------------
>> Are attribute descriptions and attribute subtypes accounted for in
>> this?  For example, will a:
>> 
>> attrSet.remove("name");
>> 
>> call result in all "cn", "sn", "cn;lang-us" attributes being removed
>> from the LDAPAttributeSet?
>
>  Yes

This behavior is inconsistent with LDAP/X.500 subtyping.  attrSet
is modifying the attrSet and hence should be consistent with
the protocol modify... which would only delete "name" and not
its subtypes.

>> Section 4.7.1:
>> --------------
>> Maybe this was covered in previous discussions on this list.  It is
>> not clear from the draft, however, what the subtle differences are
>> between a LDAPBind and LDAPRebind class and where these differences
>> are used.
>
>  In practice, LDAPRebind is a simple interface for simple binds. For
>anything more complex, including SASL, LDAPBind should be used.

s/more complex/secure/

>> Section 4.11.1:
>> ---------------
>> "after appropriate normalization".  Doesn't this imply that the CLIENT
>> have full knowledge of the "active" schema?  More clarification as to
>> the extent of normalization that will be done is needed here.  Full DN
>> handling is actually quite complex.  If that is what is intended here,
>> then it needs to be made clear.  Further, this could require some form
>> of communication with an LDAP server to get a set of "schema" with
>> which to work with.
>
>  The normalization that is done is:
>
>escape processing
>white space between the RDN separator (",") and the following RDN
>case-insensitivity for RDNs with case-insensitive syntax
>
>  Yes, determining which RDNs have case-insensitive syntax does require
>access to a subset of the schema of a particular server.

Actually, the parent of the entry named by the entry could be
controlled by a different subschema, held by a different server...

>> Section 4.16.5:
>> ---------------
>> Are the constants referred to here for result codes defined as static
>> constants anywhere?  I did not see them defined as such anywhere in
>> this draft.  This could possibly be done in LDAPException as:
>> 
>> class LDAPException {
>> ...
>> public static final int NO_SUCH_OBJECT = 1;
>> ...
>> }
>
>  The values are not defined in the draft, so as to avoid redundancy.
>They are defined in RFC 2252.

I assume you mean RFC 2251 and the ASN.1 defined resultCode
names and their corresponding values.  However, the API uses
different names than the ASN.1... hence there is a need for a
explicit API name <-> ASN.1 name mapping table.  (I'd prefer
the API just use the ASN.1 names...)

>> Section 4.31.1:
>> ---------------
>> Why is doReferrals set to "false" by default?
>
>  Safety.

Clarification: security considerations

>> non-SIMPLE re-bind authentication seems to need more thought, in
>> general.  Is anybody working on this?
>
>  Yes:
>
>http://www.ietf.org/internet-drafts/draft-weltman-java-sasl-03.txt

Is this going to progressed on the Standard Track as well?

>> Section 4.31.3:
>> ---------------
>> LDAP_DEREF_NEVER  should be LDAPConnection.DEREF_NEVER
>> LDAP_DEREF_FINDING should be LDAPConnection.DEREF_FINDING
>> LDAP_DEREF_SEARCHING should be LDAPConnection.DEREF_SEARCHING
>> LDAP_DEREF_ALWAYS should be LDAPConnection.DEREF_ALWAYS
>
>  OK

I'd prefer using the ASN.1 names where ever possible, e.g:
   LDAPConnection.neverDerefAliases
   LDAPConnection.derefInSearching
   LDAPConnection.derefFindingBaseObj
   LDAPConnection.derefAlways


>> Section 4.40.1:
>> ---------------
>> Will the client send off abandon requests for all outstanding (but
>> incomplete) operations if a bind() is invoked?
>
>  No. That doesn't seem justified, IMHO.

I concur.  Given that a bind request causes all outstanding requests
to be abandoned automatically, sending off abandon requests for all
outstanding operations would be pointless.

Kurt