[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

"Kurt D. Zeilenga" wrote:
> 
> 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.

  The operations defined in the API (for language-sensitive extraction of attributes) are operations on an object in memory at the client side, not LDAP protocol operations. There is no need and no benefit to having the operations on LDAPAttributeSet mimic the semantics of the search protocol operation. The intent of the language-sensitive operations in the API is to provide significant value to the user of the API, beyond what can be accomplished with search options. As I described in a message to this list on September 21, the semantics of the language-sensitive operations on LDAPAttributeSet were derived from a study of desired behavior in environments where localized and multi-language data is to be retrieved from a directory.


> 
> >> 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...)

  I'll look them over.

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

  I'm not sure what the appropriate action is in this case, since I am pushing to get the API adopted as a standard Java extension though the JCP.

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

  That runs against the Java convention of all caps for constants :-)

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


Rob