[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Java LDAP API draft reconciliation
- To: ietf-ldapext@netscape.com
- Subject: Java LDAP API draft reconciliation
- From: rweltman@netscape.com (Rob Weltman)
- Date: Tue, 23 Mar 1999 15:22:17 -0800
- Organization: Netscape Communications Corp.
- References: <369568B7.F67D19EC@netscape.com> <36E4331A.23E62ECC@innosoft.com> <36E550A9.7BBFC82F@netscape.com> <36E6B24B.2E411D83@innosoft.com> <36E6BD57.97B5FC16@netscape.com> <36E83510.6D469D35@innosoft.com> <36E86EB4.55BCE884@netscape.com> <36E9834F.C39DF49B@innosoft.com> <36E99A7C.1AC3B431@netscape.com> <36E99C08.204FE7C9@netscape.com> <36EAE122.A4A16F9@netscape.com> <36ED4C32.D78A580E@innosoft.com>
- Resent-date: Tue, 23 Mar 1999 15:22:44 -0800 (PST)
- Resent-from: ietf-ldapext@netscape.com
- Resent-message-id: <"51cfr.0.Yn6.u82-s"@glacier>
- Resent-sender: ietf-ldapext-request@netscape.com
Tim Howes and Rob Weltman fron Netscape met with Chris Tomlinson and Mark Wahl of Innosoft and Jim Sermersheim of Novell at the IETF in Minneapolis 3/16/99 to work on unifying the two current Internet Drafts on a Java LDAP API:
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-ldap-java-api-03.txt
http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ldapext-alt-ldap-java-api-00.txt
The focus of the meeting was on identifying what changes would need to be made to the former proposal. This is a summary of what was agreed on:
1. Exposing the mechanism that associates an LDAP request with the response to the request.
The justification for this is a desire to multiplex the result/response streams from multiple searches (potentially to multiple servers on different hosts). Support for this will be added in the form of a separate class, parallell to LDAPConnection, in order to not disrupt existing functionality or introduce complexity in the more common cases.
2. Server response controls returned on searching should be provided through the search results, not through the connection (as is the case for other operations).
This will be added.
3. Support for both server timeout and interface timeout in the API.
Only server timeout is required of the API. It will be clarified in the API document that this is the case.
4. Unique class for each possible server or interface error code.
No agreement here. Rob will poll the newsgroups to get a feeling for if users want this.
5. Reauthentication on referrals must support multi-level SASL and/or TLS negotiation.
Rob will investigate if this is possible with the current definitions; if not, support will be added.
6. Names of classes and methods should be those used in protocol drafts and RFCs.
The "authenticate" methods will be changed to "bind".
7. API/protocol elements which are integers or strings should be unique classes instead: search scope, sort attribute names, alias dereferencing flag, modify operation type.
No changes will be made to the API draft.
8. One or two APIs
If the changes above are made, Innosoft will withdraw the alternate API proposal, and the single API draft can be moved forward to final call.
Rob