Re: LDAPEXT status and last calls

[mcs@netscape.com (Mark C Smith)]

"Kurt D. Zeilenga" wrote:

> Though most of draft-ietf-ldapext-ldap-c-api-01.txt is okay,
> I believe there are still a number of outstanding issues that
> must be discussed and resolved before last call should be made.
> I believe the draft will require significant revision before it
> can be progressed as a proposed standard.  I do not believe a WG
> last call should be made on this draft at this time.

I more or less agree.  I had planned one more revision before last call.  If
the comments and open issues can be addressed to everyone's satisfaction
during and after last call without another last call being needed, then I
have no problem with the current draft being in last call.  I defer to the WG
chairs to decide what is the best procedure to use.


> ...
> In particular, I believe the following issues must be
> addressed before it should be progressed:
>
> * UTF-8 requirement for DNs/string values
>         Needs to be clarified what is required of the implementation
>         when using LDAPv2 and detailing specific translation requirements.

My personal view is that (1) LDAPv2 is not very interesting as it is on its
way out and (2) implementations have done a lot of different things with
respect to charsets used in LDAPv2.  We can argue the merits of different
approaches, but since we are specifying an API for LDAPv3 I do not believe we
should spend a lot of effort on this area.  A statement such as "If the LDAP
API is used to communicate with LDAPv2 servers, the character set used for
attribute values and DNs when they are passed and and out of LDAP API
functions should match that defined by LDAPv2 (typically ASCII or T.61)."
What do you think?


> * Header requirements should be detailed.

I plan to incorporate some of your earlier comments into the draft.
Specifically, I agree that the ldap.h header file should have all of these
characteristics: idempotent, mutually independent, equivalent to file level
declarations, well documented.



> Also, all the "Outstanding Issues" should be resolved:

In my opinion, most of these can be safely deferred to separate extension
documents.


> 23.1 multithreaded apps
>         Could be described as an extension...
>         (I am willing to work on such).

I'd like to work with you on this.


> 23.3 client control for chasing referrals
>         Could be described as an extension...

True.  I think Microsoft (at least) has an implementation of this already.


> 23.4 hostname:port and IPv6
>         How is this resolved in URLs?  (ie: proto://host:port/ must also
>         conflict with IPv6)  Recommend we resolve the LDAP IPv6 issue
>         similiar to however it is being resolved with URL's.

Sounds like a good strategy.  I'll investigate.


> 23.5 SASL API
>         Could be described as an extension...

Agreed.


> 23.6 charsets other than UTF-8
>         Should be handled as an extension (I am working on such).

Agreed.


> 23.7 Session Options
>         ldap_get/set_option interface should be nailed down.

I am pretty happy with it as currently defined, but will respond to your
earlier comments on the subject.  There is definitely a tradeoff between
creating the perfect API and maintaining compatibility with existing
implementations (this draft has been around for a long time now).


> 23.9 LDAP C API extension mechanism
>         should be nailed down.

I think it is close as well, but will respond to your comments on this
subject too.

Thanks for all of your helpful comments so far!

-Mark