RE: immutable, permanent DNs @ Stanford

[Alexis Bor <[e-mail]>]

Jeff,
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-788-7647
425-844-2375 (FAX)
[e-mail]
http://www.directoryworks.com 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, January 09, 1998 1:43 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: immutable, permanent DNs @ Stanford
> 
> 
> 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








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