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

[hahnt@us.ibm.com]

Steve,

Ok by me - as long as the default value is defined.  10 sounds fine.

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


"Steve Sonntag" <VTAG@novell.com> on 10/03/2000 06:30:36 PM

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






>>> hahnt@us.ibm.com>  02-Oct-00 4:09:59 AM >>

The current draft defines hop_limit as  10, see 4.7.7 &
4.39.39.  I say leave it as it currently is in the draft

-Steve

> 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