RE: immutable, permanent DNs @ Stanford

Alexis Bor <> Fri, 09 January 1998 17:16 UTC

Delivery-Date: Fri, 09 Jan 1998 12:16:30 -0500
Received: from (cnri []) by (8.8.7/8.8.7a) with ESMTP id MAA15041 for <>; Fri, 9 Jan 1998 12:16:29 -0500 (EST)
Received: from ( []) by (8.8.5/8.8.7a) with ESMTP id MAA17318 for <>; Fri, 9 Jan 1998 12:19:15 -0500 (EST)
Received: from ( []) by (8.8.7/8.8.7a) with ESMTP id MAA15038 for <>; Fri, 9 Jan 1998 12:16:18 -0500 (EST)
Received: by with Internet Mail Service (5.5.1960.3) id <Y7002HX7>; Fri, 9 Jan 1998 09:16:00 -0800
Message-ID: <>
From: Alexis Bor <>
Subject: RE: immutable, permanent DNs @ Stanford
Date: Fri, 9 Jan 1998 09:15:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1D22.3B009272"

After many efforts at various different DN naming approaches between
1990 and 1995, I ended up with the same conclusion - that the DN is just
a unique pointer to an entry and nothing else.  This really makes life
much simpler.  Back in 1995, it was almost impossible to get anyone to
agree or even consider this.  

I am now seeing many large companies finding that this is the only way
to do it.  The only challenge is what to use for the unique permanent
value.  Your choice is just as good as any.  Many companies are using
employee badge numbers or generating unique numbers within the directory
service.  Some are also trying to coordinate the values with their HR
systems (often PeopleSoft or SAP).

Thanks for your input - I am hoping that more and more people consider
such an approach.

-- Alexis

Alexis Bor
Directory Works, Inc.
16312 194th Avenue NE
Woodinville, WA  98072
425-844-2375 (FAX) 

> -----Original Message-----
> From: Jeff.Hodges@Stanford.EDU [mailto:Jeff.Hodges@Stanford.EDU]
> Sent: Friday, January 09, 1998 1:43 AM
> To:
> Cc:
> Subject: immutable, permanent DNs @ Stanford
> I have a test directory up that folks are welcome to poke at...
>   ldap://
> 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://, with 
> a search root of "dc=stanford,dc=edu").
> You should then be able to get at the test entries by setting the
> Directory" tool to..
>   search for items in 'director' where the 'name' 'contains' 'entry'
> An "ldapsearch" command that returns similar results is..
>   ldapsearch -h -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
> (which will expose the entry's DN as a side-effect). Also, you can get
> Stanford University entry by setting the "Search Directory" tool to..
>   search for items in 'director' where the 'organization' 'contains'
> An "ldapsearch" command that returns the same results is..
>   ldapsearch -h -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,
> "regid" is short for "Registry ID". The ID presently used is a
> 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
> entries themselves. Should we decide that its useful for our directory
> provide a browseable organizational representation, we'll likely
> 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
> (and our own in-house staff) become more educated about
> directory technology, they'll create tools that shelter users from DN 
> intricities, and instead focus on using well-known "naming attributes"
> 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
> directly with DNs, but rather with focused attributes (such as cn), 
> that serve 
> as user-perceivable names for the entries for search purposes. Once
> entries are read, then the app can cache the DN and use it as a "key"
> base-object *lookups*.
> Additionally, Communicator is highly configurable -- see...

 (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
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
  * object classes used "under the hood" in search filters

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



[1] The Registries Project pages...

 <<Alexis Bor (E-mail).vcf>>