re: draft-ietf-ldapext-ldap-c-api-00.txt

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

Comments on Section 14. ASN.1 Encoding:

1. In section 14.2, the explanation of LBER_USE_DER says "these
functions are not suitable for generating DER".  I believe it would be
better to say "sufficient" instead of "suitable".  If the application
takes responsibility for ordering sets and sequences, it should be
possible to produce DER.

2. ber_printf should have an option (possibly 'T') to encode an explicit
tag.  While explicit tags never appear in the Ldap protocol, they could
appear in extensions, and do appear in attribute values (e.g.,
Certificates).  

The text describing ber_skip_tag should be changed to describe its usage
in handling explicit tags.  (It should already work.)

3. Why doesn't ber_flatten return an error if '{' and '}' are not
matched?  At least say that the results of ber_flatten are undefined if
braces are mismatched.  In other words, allow the API to check; the
current text seems to permit its use to intentionally generate invalid
BER.

Other comments:
4. Is there a reason 'const' is not used in the function prototypes?

5. Sections 12 & 13.  These sections should clarify what happens when
the LDAPmessage contains the results from multiple search requests as
could be returned by ldap_result with LDAP_RES_ANY specified.  Do
ldap_*_entry, ldap_*_reference, ldap_count_entries and
ldap_count_references only consider results of a single search or of all
the searches in the message chain?  

Also, are there any side-effects caused by doing ldap_result specifying
LDAP_MSG_RECEIVED?  Is anything different about processing the rest of
the search results on a subsequent ldap_result?  In protocol terms, does
the absence of the [APPLICATION 5] message have effect on the api?

6. Section 13.4.  How do multi-valued RDNs show up in the explode
function results?

7. Secion 21.1.  Can you summarize the multithreading issues?