The DirConnect 1 event for testing LDAP clients and servers helped show the high level of interoperability in the market today. Further, the technical staff of participating LDAP vendors were able to meet to discuss the future of various LDAP features and extensions, and were able to help set the course for LDAP development in the coming years.

Participants

DirConnect 1 was held in San Jose, California on June 19 and 20, 1997. The following companies participated in the event:

• Control Data Systems *
• Critical Angle
• IBM/ccMail *
• IBM/SoftSwitch *
• Innosoft *
• Isode
• Lucent Technologies *
• Microsoft *
• Netscape *
• Novell
• Oracle
• Qualcomm *
• Worldtalk Corporation
• XCert

It was generally agreed that the majority of shipping LDAP clients and servers were represented at the event.

In addition, the following people helped prepare and lead the event:

• Paul E. Hoffman, Internet Mail Consortium
• Patrik Faltstrom, Tele2
• Christopher Walon Apple, ATT Labs
• Jeff Hodges, Stanford University

Two groups also helped the event by allowing us to use their LDAP test suites as the basis for the unofficial test suite of the event. Both EuroSInet and Network Applications Consortium's suites were used as the basis for the combined test suite.

Event Summary

The LDAPv3 protocol is implemented up until the latest draft. No major problems with the protocol were found, but the DirConnect participants explored many things outside of the core specification so that there would be more common ground -- and therefore more interoperability -- for products which implement more than the core capabilities.

On the interoperability front, a few vendors reported problems with other implementations, but there was a general agreement that the problems were limited and fixable. Much of the work of the event was testing beyond simple LDAP queries and responses.

During the event, some vendors had questions of interpretation about the LDAPv3 spec. Mark Wahl, one of the authors of the LDAPv3 core specification, was on hand to help resolve these questions. In some cases, the questions caused Mark to add clarification to the final draft of the LDAPv3 spec, which subsequently went into Working Group last call.

Internationalization Extensions

It was clear that internationalization extensions to the LDAPv3 protocol need more testing. In particular, sorting, language tags, and (because of sorting issues) the paged result set need work. Paged result set seemed to be a good thing, but it requires the server to do sorting of the result set, which is not a simple task. The outcome of a lengthy discussion at the event was that it should be possible for the client to request some sorting, but the server can always say "no, but I did it this way". Because paged result set and sorting were implemented only in a small number of servers, it was not discussed further.

UNICODE/UTF-8 implementations were in some cases based on the built-in functionality in the operating system, and in some cases based on functions in the server/client themselves. It was unclear how the decomposition specified in UNICODE (but not in ISO-10646) should, if ever, be used in the comparison algorithms.

Open Questions

Schema publishing was supported by a few products. It was a bit unclear how or if it was working, and most vendors used some standard schemas, with easy configuration tools for supported schemas. Most vendors supported the SLAPd server built-in schemas, and of course X.520/521.

There was a question about the way an LDAPv3 server should respond to an LDAPv2 client when the server wants to generate an LDAPv3 referral/search continuation.

The question is whether to have SSL/TLS over a separate port or via the startTLS command within the LDAP protocol. Most companies wanted to use the startTLS command, but some people in the security community had expressed some reservations about starting TLS during an insecure session, although no specific problems have been shown. The vendors at DirConnect said that most of them would implement and test startTLS in the near future; IMC will create a list of such clients and servers to aid the testing.

Software Tested at DirConnect 1

A more detailed partition of the different products were:

• 9 standalone LDAP servers
• 2 LDAP clients
• 2 HTTP cgi-bin clients
• 2 Proxies to DAP/X.500 (LDAP server)
• 1 Firewall proxy (LDAP server and client)
• 1 CCMail proxy (LDAP server)
• 1 Mail routing client (LDAP client)
• 1 NDS proxy (LDAP server)
• 1 Sync module (LDAP client)

The breakdown of operating systems usage was:

• 12 run on UNIX and NT.
• 7 run on NT (not UNIX) (some of these also Win-95).
• 1 ran on Netware

• 6 read/write, 3 read only
• 3 handle T.61, 4 do not handle T.61
• 3 handle UTF-8 encoded UNICODE
• 5 handle UMICH referrals extension to LDAPv2, 4 do not
• 2 handle LDAPv3 referrals
• 2 handle LDAPv3 continuation references
• 2 uses paged results
• 1 asks for server-side sorting
• 2 handle SASL bind options
• 1 handles the dynamic object class (the client library, no actual client)
• 2 handle the extensible object class
• 1 has support for language codes
• 2 handle all sorts of DN quoting (1 handles 80% of it :-)
• 1 handles extensiblematch

Of the 14 programs which act as LDAP servers the following functions were supported:

• 9 were mastering the data
• 4 were able to have interfaces to existing databases (to ccmail, to Oracle via Oracle references, to LDAPv2, and to a private API)
• 1 had support for CLDAP
• 1 had support for MAPI
• 10 were used in larger packages as tools, mostly for holding message routing information
• 3 were acting as gateways to or from LDAP
• 10 handle T.61
• 8 handle UTF-8 encoded UNICODE
• 13 handle binary values
• 9 gives back UMICH referrals to LDAPv2 clients, when possible (some problems exist when an LDAPv3 server downgrades from LDAPv3 referrals to LDAPv2)
• 4 give back LDAPv3 referrals
• 4 give back LDAPv3 continuation references
• 2 handle paged result sets (and 2 more were working on it)
• 1 handled server-side sorting (and 2 more were working on it)
• 4 handled SASL bind options (1 only did the protocol, 3 were extensible, out of which 1 handled the GSS API and 2 supported KerberosV out of the box)
• 0 handled the dynamicObject class
• 3 handled the extensibleObject class, 1 more "very soon now"
• 1 handled storage of language code, but not preferred language
• 3 handled all forms of DN quoting, 1 more RFC 17xx, not the current one
• 3 handled extensibleMatch
• 4 handled extended protocol operations
• 3 handled all protocol operations (1 additional handled all except modifyDN)
• 5 handled LDAP URLs (1959), 1 additional just as text
• 6 handled LDAP schema publication
• 8 supported user certificate, but mostly only as binary data
• 9 supported replication, 2 with LDAP and changelog, others proprietary
• 5 handled at least one subschema entry in the root DSE
• 4 handled changelog
• 6 handled creatorsName
• 8 handled createTimestamp
• 6 handled modifiersName
• 9 handled modifyTimestamp
• 6 handled subschemaSubentry
• 6 handled namingContexts
• 4 handled supportedExtension
• 4 handled supportedControl
• 3 handled supportedSASLmechanisms
• 6 handled supportedLDAPversion
• 4 had support for LDAP server controls
• 5 had support for SSL over a separate port
• 1 had support for the startTLS command

The Next Steps

It was also agreed that having a publicly-available test suite would help vendors between events. To that end, Chris Apple from AT&T Labs agreed to lead an effort on a separate mailing list to create a good, open LDAPv3 test suite effort that IMC will make publicly available.

• New versions of IMC reports are given new report numbers but the name of the report remains the same.
• You can get the newest version of this report from the IMC Web site at <http://www.imc.org/dc1-final.html>.
• A list of available IMC reports can be found at <http://www.imc.org/reports.html>.

• To provide feedback or to get more information on IMC reports, send mail to <reports@imc.org>.
• For information on the Internet Mail Consortium, please visit our Web site at <http://www.imc.org/>, send us email at <info@imc.org>, or call us at +1 (831) 426-9827.