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

[hahnt@us.ibm.com]

Rob,

Thanks for the responses.

I have a couple more comments on these below - look for TJH>

Thanks again,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


Rob Weltman <robw@worldspot.com> on 10/01/2000 08:26:37 PM

To:   Timothy Hahn/Endicott/IBM@IBMUS
cc:   ietf-ldapext@netscape.com
Subject:  Re: comments on draft-ietf-ldapext-ldap-java-api-11.txt



  I think a few things overlap with the discussion earlier in September
on this list, but I've provided responses to all on an item-by-item
basis.

  Thanks for your detailed review!

Rob

hahnt@us.ibm.com wrote:
>
> Section 4.26.1:
> ---------------
> Clarification: the full response is received prior to throwing the
> referral exception, correct?

  I'm not sure why you're referring to 4.26.1 with the question; is the
question answered in 4.35.4?

TJH> Seeing that LDAPReferralException is returned (not thrown), this now
makes sense.



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

  Safety.


> 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

  and also:

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_028_sasl.html

  LDAPBind and SASL or startTLS is the way to go.


> Is hop_limit set to zero by default?  Does zero imply no limit?

  The default value and the semantics of zero should be defined in the
draft. Zero should imply no limit, but the default should be a
reasonable value (to allow reasonable nesting levels of reference while
preventing infinite loops); I propose 5.

TJH> 5 sounds fine to me.


> Section 4.32.3:
> ---------------
> Would it be useful to have a "isReponseReceived( int msgid )" method
> as well?

  That might be useful.


> How about an "isComplete( int msgid )"?

  I'm not sure that makes sense: if all results have been retrieved for
a particular message ID, there is no longer a queue maintained for it.
getMessageIDs() will not return the ID. It would be difficult for the
application to distinguish between the request being complete (all
results retrieved for that ID) on the one hand, and an invalid ID on the
other.

TJH> I agree that if there is no longer anything maintained for the message
ID
TJH> that it would be hard to distinguish.  But if an application wanted to
TJH> hold of on processing the response until the complete message was
TJH> received it could test such an "isComplete()" result.



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

TJH> agreed.

>
> Thanks,
> Tim Hahn
>
> Internet: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681