RE: C API: is reference following underspecified?

["Anoop Anantha (Exchange)" <anoopa@Exchange.Microsoft.com>]

1] LDAP_OPT_REFERRALS controls both referral and reference chasing behavior.

2] A client control is supposed to be an input, not an output "parameter"
for the library. The behavior you require can be easily achieved by means of
an LDAP option. In our implementation, we have an option to reference the
connection for each message so that we can safely get back the connection
pointer (and thus the host which generated the referral) later by calling
ldap_conn_from_msg

//
//  Do we reference the connection for each message so that we can safely
get
//  the connection pointer back by calling ldap_conn_from_msg?
//

#define LDAP_OPT_REF_DEREF_CONN_PER_MSG 0x94

//
//  Given an LDAP message, return the connection pointer where the message
//  came from.  It can return NULL if the connection has already been freed.
//

WINLDAPAPI LDAP * LDAPAPI ldap_conn_from_msg (
    LDAP *PrimaryConn,
    LDAPMessage *res
    );

3] Reuse of msgids is implementation specific and probably needs no mention
in the draft. Our implementation does not reuse msgids.

4] If none of the referred servers can be successfully queried, the API will
return LDAP_REFERRAL. If at least one referral in a set of referrals can be
successfully chased, the result(s) are returned.

-Anoop Anantha
Microsoft Corp.

-----Original Message-----
From: Mark Wahl [mailto:M.Wahl@INNOSOFT.COM]
Sent: Monday, November 15, 1999 1:13 PM
To: mcs@netscape.com
Cc: M.Wahl@INNOSOFT.COM; howes@yahoo.com; Andy Herron (Exchange); Anoop
Anantha (Exchange); kurt@OpenLDAP.Org; ietf-ldapext@netscape.com
Subject: C API: is reference following underspecified?



I am getting questions which indicate to me that the referral following 
behavior when LDAP_CHASE_SUBORDINATE_REFERRALS is on is underspecified in
the C API draft -04, even for issues besides authentication.

1. The LDAP_OPT_REFERRALS text talks about referrals but not references.
Does
it apply to references as well, or just referral?

2. I was asked, why are the client controls only on the requests and not
on the responses?  If there was a LDAPControl ***clientctlsp on the 
ldap_get_entry_controls() or ldap_parse_reference() for example, then the 
library could put in a client control, such as the URL of the server 
which returned that entry or reference.  

2. When the library is following referrals and references, does it re-use
the 
same message id as the original request, or create a new one?  (In our
implmentation what is returned in *msgidp is an internal request
ID which is not necessarily the same as the message id. Our message
ID is a counter per conection).  This is important if there is a 
situation where server A holds naming contexts dc=com and 
dc=foo,dc=bar,dc=com but not dc=bar,dc=com.   Server B holds dc=bar,dc=com.

So the client contacts A and subtree searches dc=com.  Server A returns 
a referral to server B for dc=bar,dc=com, but is still returning matching
entries in the dc=com naming context.  The client library contacts 
server B and issues a search of dc=bar,dc=com.  Server B returns a referral 
to server A for dc=foo,dc=bar,dc=com.  The client then contacts server A
and issues a search below dc=foo,dc=bar,dc=com.  Since the original search
may not have yet returned Search Result Done, there must be two distinct
message IDs for these searches on server A.  Therefore either the message id

must change, or the client library block following references.  Does an 
ldap_result() still work if the message id changes?  

3. What does the library do if it cannot contact any of the URLs in a 
single search result reference? Or if it can but the server returns errors? 
Or success with controls?

Mark Wahl, Directory Product Architect
Innosoft International, Inc.