I assume this directory will contain all individuals associated with the University. It will encompass at least the current staff and student on-line directories, and very conceivably incorporate other data as well. For one thing, the HEPPS and student data bases may have more data, that we currently don't put online just because it didn't fit with staffdir or with the transfer format.
Some of the fringe categories might be put off in a separate data base, with an LDAP referral from the main site - e.g., Harborview, or supposing we maintained directory references for alumni if they acquired them as students.
Problems with referrals: they're supposed to work with current implementations, but in somewhat limited ways. I haven't been able to get it to work even as well as it's supposed to - I can get a referral to happen, but not in a useful way. (slapd will take a referral to its peer, if an attribute of the referral DN matches the client's search, but the referral doesn't seem to return anything.) Anyway, for example a client may be able to deal with referrals in its basic search, since the server does the work, but specific reference to a particular DN that was returned from the referral will fail, because that's a "base" search instead of "subtree".
There will be other IDs besides individuals, too. It's less obvious how it will look, but departments will probably have entries, and maybe there will be entries for documents and various intangible things.
We need an eternally stable reference for each individual. This will go into the Distinguished Name -- if you look at the LDAP staffdir web results, that's the little banner over each entry. The latest theory is that they could be generated on entry into Informix.
For now, the duplicates (e.g., Carol J. Johnson, Donald W. Johnson) seem to be OK - I mean, at least they do both show up. But I think we do need a unique ID here, and also one not subject to the vagaries of personal names.
This information goes out to the world - clients in general expose it, for example the X.500 finger I put up. So whatever we use has to be non-confidential. Some people are proposing to use user IDs (like our user@u), which has its attractive aspects but doesn't cover everyone and is potentially subject to change. Stanford may be inventing an ID number.
In general, LDAP doesn't care what goes into it. I came up with some initial attributes from the slapd administration guide: ``cn'' is Common Name, ``sn'' is SurName. I have scrounged up some other things from various published papers, and from looking at the University of Michigan's own LDAP data.
The client - say, an addressbook accessory - needs to be in some agreement with the server's nomenclature, or the query won't turn up anything it understands. Unfortunately, the notion of a common set of attributes doesn't seem to have been there from the start, and at best we hope for convergence.
Then there are a bunch of ``objectclass'' attributes that I'm pretty sure I don't understand. Everyone is ``objectclass=person'', and then they're also umichPerson as well; the guy at Stanford indicates this is essential (of course he makes them stanfordPerson or something.) They must have some special function, but I don't know what. What about studentPerson and staffPerson etc. - would we want studentUwPerson, i.e. is hierarchy explicit in the names?
http://www.microsoft.com/msdn/techinfo/schema/schema.htm (Large tables, your browser may not survive this.)
http://home.netscape.com/eng/server/directory/1.0/ag/contents.html
The big sites allow some write access to the data, either from the individual or some representative; access is controlled. Right now the data propagation is easily controlled, since there's one source (HEPPS). The simplest thing might be to feed HEPPS into a set of invented attributes, like heppscommonname, relate those to the ``standard'' attributes like cn, and maintain our own subsequent mods to the latter (most recent change wins.)
The one I'm running now is slapd 3.3 from the University of Michigan. The competition is mostly rewrites of this code, by its authors who have gone off variously to Netscape, Critical Angle, etc. I'm using the Berkeley B-Tree data base from db-1.85; GNU gdbm is about the same, but the UNIX standard ndbm won't work. I've experimented with a db-2 release, but the data base got up to several Gb and evidently wouldn't work anyway, so I've tabled that. I was using 1.85 compatibility. Data base generation takes hours, with just staff.
There doesn't seem to be anyone left at U. Mich. who wants their slapd to go on living, from the way it looks now. Critical Angle has a sample implementation that supports many of the proposed LDAP v3 features, available in binary form for Linux, Solaris, NT. Their site seems to have been on vacation since spring.