[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAPEXT status and last calls
Mark C Smith wrote:
>
> "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