Re: More about draft-ietf-ldapext-ldap-c-api-01

[Mark Smith <mcs@netscape.com>]

Hallvard B Furuseth wrote:
> 
> ===
> 
> Can the RFC say both
>    Obsoletes: RFC 1823
> and
>    Interested readers are referred to RFC 1823.
> ?

Clearly it can.  Perhaps it should not.  What do you think?


> ===
> 
> You might add an "Incompatibilities with RFC 1823" section.
> Here is a quick draft with the changes I've noticed.
> ...

This seems like a good idea (as an appendix).  And thanks for the text!


> ===
> 
> What LDAP options do internally opened referral connections get?
> The current options of the operation/session which caused the referral,
> or something simpler?

The options of the session that caused the referral.  I will clarify
this in the next revision of the draft.

> 
> I assume the API binds anonymously, since it should not save credentials
> according to the Security Consideration section?

The intent is to bind anonymously by default but provide a callback to
allow the application to supply the correct credentials.  Definition of
the callback is an open issue but one I have some thoughts on.  I'll try
to put out a proposal soon.


> Some calls to configure how the API handles the stuff above with
> automatic referrals might be useful.  And for clients that chase
> referrals "by hand", something like
>     ldap_set_option( ld, LDAP_OPT_COPYOPT, source_ld )
> call which copies various options (size/time-limit, server/client
> controls & so on) of source_ld to ld.

Interesting idea.  I think this might make sense for a future revision.
More thought into what functions would help applications who want to
handle referrals themselves is needed.


> 
> Another way to set up how automatic referrals are done could be to allow
> ldap_<set/get>_option(NULL, ...), where (LDAP*)NULL means the default
> options for connections opened with future ldap_<init/open>() calls.

This is already supported, but I'd rather "inherit" the settings for
automatic referral chasing from the "parent" connection.  That makes
more sense to me....

> 
> Oh, and a call to unpack a referral (LDAPURL) into its (hostport, base,
> ...) elements would be useful for people who handle referrals "by hand".

We have this in the Netscape (and U-M) SDKs, although it needs updating
for LDAPv3 URLs which now support extensions.  The function is called
ldap_url_parse().


> 
> ======
> 
> 15.2:
> 
> > If the caller takes responsibility for ordering values
> > of sets and sequences correctly,
>           ^^^^^^^^^^^^^
> No, the order in sequences is significant.  (At least not the kind of
> sequences I know about.)

I think "and sequences" should be removed.  Is that what you are
suggesting?


> 
> Add "and removing DEFAULT values".

Okay.  The updated text on the LBER_USE_DER option now reads:

When this option is present, lengths will always be encoded in the
minimum number of octets.  Note that this option does not cause values 
of sets to be rearranged in tag and byte order or default values to be
removed, so these functions are not sufficient for generating DER
output as defined in X.509 and X.680.  If the caller takes
responsibility for ordering values of sets correctly and removing
default values, DER output as defined in X.509 and X.680 can be
produced.


> 
> > DER output as defined in X.509 and X.680 can be produced.
> 
> If there is any interest in DER, these functions could be defined to
> help with that:
> 
>   int ber_bvcmp ( struct berval *bv1, struct berval *bv2 )
> 
>     Compares bv1 and bv2 according to the DER rules.  The function
>     returns an integer greater than, equal to, or less than 0, if *bv1
>     is greater than, equal to, or less than *bv2 respectively.
> 
>   void ber_bvecsort ( struct berval **bvec )
> 
>     If bvec is not NULL, sort it according to the DER rules.
>     bvec is NULL or a NULL-terminated array of `struct berval*'s.

I don't think DER is a requirement for LDAP applications, but we should
consider addig these kind of functions if demand is high.

Thanks for all of the great comments!

-- 
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"