[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt
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