immutable, permanent DNs @ Stanford

[[e-mail]]

I have a test directory up that folks are welcome to poke at...

  ldap://director.stanford.edu:389/

For example, you can point Netscape Communicator 4.X's "Search Directory" tool 
(available from the Edit menu) at it (by editing Edit:Preferences:Mail & 
Groups:Directory and adding info about ldap://director.stanford.edu:389/, with 
a search root of "dc=stanford,dc=edu").

You should then be able to get at the test entries by setting the "Search 
Directory" tool to..

  search for items in 'director' where the 'name' 'contains' 'entry'


An "ldapsearch" command that returns similar results is..

  ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu objectclass=\* dn

  (this command assumes a standard cshell command-line interface)


You'll get four entries back, without having to know anything about their DNs, 
or specifically the attribute used to construct the entries' RDNs.

You can now double-click on each of these entries to get a detailed view 
(which will expose the entry's DN as a side-effect). Also, you can get the 
Stanford University entry by setting the "Search Directory" tool to..

  search for items in 'director' where the 'organization' 'contains' 'SU'


An "ldapsearch" command that returns the same results is..

  ldapsearch -h director.stanford.edu -b dc=stanford,dc=edu -s base 
objectclass=\*

  (this command also assumes a standard cshell command-line interface)


So, about the DNs, they (presently) look like this...

 regid=3000169d-b824-21d1-8300-ab400e0baa77, ou=People, dc=Stanford, dc=edu

"regid" is short for "Registry ID". The ID presently used is a dce-uuid-based 
id. It could, and we're planning that it will be, a guaranteed-unique, 
non-resuable number generated by our Person Registry [1].

Also, all person entries are contained in the ou=People flat space. 
Organizational information will be contained in attributes in the person 
entries themselves. Should we decide that its useful for our directory to 
provide a browseable organizational representation, we'll likely implement 
that in a subtree parallel to ou=People, and utilize aliases/references to 
point back to the person entries.

Some folks will claim "the DNs aren't easily human-consummable." And, they are 
nominally correct. We're confident though, that as more applications vendors 
(and our own in-house staff) become more educated about LDAP/X.500-based 
directory technology, they'll create tools that shelter users from DN 
intricities, and instead focus on using well-known "naming attributes" (I'm 
not using "naming" in the strict X.500 sense here).
  
A very good example of this trend is NS Communicator's directory 
functionality. Notice how, in the examples above, the user doesn't interact 
directly with DNs, but rather with focused attributes (such as cn), that serve 
as user-perceivable names for the entries for search purposes. Once the 
entries are read, then the app can cache the DN and use it as a "key" for 
base-object *lookups*.

Additionally, Communicator is highly configurable -- see...

 http://developer.netscape.com/library/documentation/communicator/custom.htm

 (note that there may be newer documentation available (pls lemme know if so))

..for the details on how. Note that they allow one to configure how attributes 
are used in these fashions..

  * the displayed name of attributes
  * the set of attributes available for use in search specifications
  * which attributes and how they are used "under the hood" in search filters 
  * object classes used "under the hood" in search filters

I believe that we need to encourage vendors in general to provide similar 
levels of configurability in their directory-based wares, rather than the IETF 
trying to produce standards-track docs such that they can figure out what 
attributes to hard code into their dialogs.

Thanks,

Jeff
----

[1] The Registries Project pages...

  http://www.stanford.edu/group/itss-ccs/project/registry