It was just my luck that after writing an entire article about directory services on the Mac (see TidBITS-352), Apple announced it would be supporting LDAP, the Lightweight Directory Access Protocol. LDAP has the support of numerous other large companies, and it mainly remains to be seen what form Apple's LDAP support will take beyond the existing maX.500 client program.
Interestingly, the bulk of Apple's press release focuses on Apple's plans to support IMAP, Interactive Mail Access Protocol, a protocol for sending and receiving email on the Internet along the lines of the current standards, SMTP and POP. It will be interesting to see if this results in the next version of Apple Internet Mail Server supporting IMAP as well as SMTP and POP.
Many TidBITS readers wrote in with comments and additions to the article, and I wanted to share some of their thoughts with you.
Andrew Starr <email@example.com> adds:
You mentioned that one can have Netscape Navigator use Eudora as the mailto program. Your solution works, but I've found that the "Eudora Mailto: helper" makes things go a little bit better. It adds the capability of handling mailto links of the form: "mailto:firstname.lastname@example.org?subject=hello" and fills in the Subject line properly.
Also, you mentioned using FileMaker Pro or Now Contact with Eudora via scripts, but you objected to "brittle" scripts. Although I am sometimes leery of scripts that try to do too much, Claris Organizer 2.0 works with Eudora perfectly. It comes with a tiny script that invokes Claris Emailer when one clicks the button next to the email field, so I modified the script to send the information to Eudora instead.
Claris OfficeMail, when used with Emailer, has automatic address book updating. This feature keeps all users' local address books updated with the most current list of mail server users. In addition, once OfficeMail has automatically updated your Emailer address book, you can select "Export Addresses...", and produce a nice tab-delimited text file.
Ken Weiss <email@example.com> comments:
There are a few existing directory services tools that you missed. The most basic is NICNAME/Whois, which has been around for many years. It's text based, runs under TCP/IP, and just listens at a port and responds to simple commands. Another is Whois++, which is also a port listener. Whois++ incorporates the concept of query routing, which may allow it to scale up to large distributed organizations more effectively than LDAP/X.500. Most of the other solutions you discussed don't perform query routing or even X.500 style upward consolidation of indices, and won't scale to large databases effectively.
You accurately identified the backend database as being one of the key issues in directory services. Many people lose sight of the fact that a white pages directory is, at the core, an attribute/value based database.
George Yolland <firstname.lastname@example.org> writes:
Here are some points that were implied in your article on directory services but I don't feel were fully explored.
Directory Services are hierarchical. Directory services have several levels. For example, my personal contacts, my organization's employee list, my external business contacts, and so on, out to the world at large. I want to focus on what my directory services provides me. In my organization I work mostly with internal employees so I want their address information quickly accessible. Although I occasionally want to find the address of someone associated with an external organization, I generally would not want their directory information cluttering up my daily work. A standards-based system, such as LDAP, would allow organizations to share portions of their corporate directories if they chose to do so, possibly with some centralized service.
Useful directory systems are centrally maintained. This doesn't mean one workgroup for an entire enterprise must maintain the directory, but that some level of central administration - whether for the enterprise, operating divisions, or workgroups - is best if you want the information to be up-to-date. If an organization has multiple directories, these directories either must replicate themselves across the enterprise or be easily accessed across the enterprise for them to be useful. Here's where the standards-based systems like LDAP have the most potential. If they can communicate internally, they should also be able to communicate externally. I don't mind maintaining my personal and key business contacts but I should be able to find anyone within my organization easily without maintaining the list myself. This is also true of business contacts used broadly across the enterprise or group.
- Directory Services can be much more than a list of addresses. In our dream world, we would have one ID/password that would identify, authenticate, and authorize our access to resources on our networks. This service would be provided through directory services. Although you mentioned PowerTalk's keychain, it's not the same idea. It merely stored passwords for various services, rather than having a central database of users to which all other network resources refer. Users must still maintain passwords associated with their IDs on these various systems. A directory service has the potential to eliminate this. Ask any corporate support staff what its number one support issue is and I'll lay odds that it's supporting users in maintaining passwords.
John O'Shaughnessy comments:
I can tell you from experience that larger businesses rely on directory services for email - at least those I've worked for. I've seen companies keep 10,000 employees registered in a LAN email package, and I've seen companies try to tie email packages to existing directory services.
At my company we use an Oracle database that contains information about employees, and we've created tools to display basic information to the user. Although we've created GUI front ends for this database, the main thing we use these days (at least from Macs and PC's) is an interface we've created from Eudora's Ph feature. From the Eudora client, we just specify a Ph server, and on the Unix system, we define the appropriate "/etc/services" entry to reply to a Ph request. We then point the Ph request at the database described above, and the user can query the whole database from Eudora!
The bigger problems are those that you started to mention in the article - i.e., who's going to maintain the data! We've had Human Resources people maintain part of the data, and Information Systems people maintain other parts, but we're trying to rethink the whole process. It's definitely a big issue around here.