RE: LDAPEXT status and last calls

["Michael Armijo (Exchange)" <micharm@Exchange.Microsoft.com>]

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.
> 

We should make every attempt to put the changes in place to be ready for
last call at the upcoming IETF meeting.

> 
> > ...
> > 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?

I agree that we should not spend too much time on LDAPv2.  I don't think
most people are very interested in pursuing this if it will delay the draft.

> 
> 
> > * 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.
> 

Once again, I do not think that minor header requirements should delay the
release of this draft.  

> 
> 
> > Also, all the "Outstanding Issues" should be resolved:
> 
> In my opinion, most of these can be safely deferred to 
> separate extension
> documents.
> 

I agree that most of the outstanding issues can wait.  They were placed in
Appendix C just because they are not very important.

> 
> > 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

We really need to make the final push to release this document.  We should
get a final version of the document created with any minor changes that are
necessary and have it ready for last call at the meeting.

Michael