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

C API questions on section 9



I assume that when this document is sent to the RFC editors, we will remove
the paragraph:

 Until such time as this document is published as an RFC, implementations
 SHOULD use the value 2000 plus the revision number of this draft for
 LDAP_API_VERSION.  For example, the correct value for LDAP_API_VERSION
 for revision 04 of this draft is 2004.

Correct?  (The reason I had originally suggested an RFC number was to stop
implementors from shipping products claiming conformance to a standards-track
specification before the RFC was even published!)

In section 9.2 for LDAP_OPT_API_INFO: "If the value received is not recognized 
by the API implementation, the ldap_get_option() function ... returns an error 
without filling in any of the other fields in the LDAPAPIInfo structure.".  
So ldap_get_option() returns -1.  The question is, what does a subsequent call
to LDAP_OPT_ERROR_NUMBER return to signal this?  Since LDAP_OPT_API_INFO 
allocates memory, it can't be LDAP_NO_MEMORY, and none of the others look
suitable.  I propose that this section state that a subsequent call to get
the error number will indicate LDAP_NOT_SUPPORTED.

In section 9.2 the C API omits to mention that the caller must 
ldap_memfree(ldapai_vendor_name).

In section 9.2 I'm having trouble figuring how to use the feature info to 
obtain interoperability between a client from A, a feature from X and a 
library from Y.

 1. How do I find out _what_ the feature is?  (A client control? a new call?)
 2. How do I find out whose feature it is?  (An internal version number by
 itself is not useful - suppose vendor X adds a feature to vendor Y's base
 library - there is no guarantee that X and Y's numbering plans are 
 synchronized)
 3. How do new features register themselves so that ldap_get_option() will know
 about them?
 4. If the number could be an RFC or could be an internal number which might
 look like an RFC number, how does a client do a sensible comparison on it?

I propose we consider removing the feature info request of ldap_get_option()
from this document and consider moving it to its own document.  I suspect we 
will have enough trouble at present just getting source code interoperability
between different client libraries, that binary compatibility is still too far
away.  If you disagree, then I suggest then that we REQUIRE the version number
to be an RFC number.  

Mark Wahl, Directory Product Architect
Innosoft International, Inc.