RE: immutable, permanent DNs @ Stanford

Alexis Bor <alexis.bor@DirectoryWorks.com> Fri, 09 January 1998 23:09 UTC

Delivery-Date: Fri, 09 Jan 1998 18:10:00 -0500
Return-Path: alexis.bor@DirectoryWorks.com
Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18831 for <ietf-archive@ietf.org>; Fri, 9 Jan 1998 18:09:59 -0500 (EST)
Received: from ns.ietf.org (ietf.org [132.151.1.19]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA18768 for <ietf-archive@cnri.reston.va.us>; Fri, 9 Jan 1998 18:12:46 -0500 (EST)
Received: from disneyland.directoryworks.com (smtp.directoryworks.com [38.212.14.2]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA18828 for <iesg@ietf.org>; Fri, 9 Jan 1998 18:09:57 -0500 (EST)
Received: by smtp.directoryworks.com with Internet Mail Service (5.5.1960.3) id <Y7002HZF>; Fri, 9 Jan 1998 15:09:40 -0800
Message-ID: <41F77E366C97D011B13400609778F568034D56@smtp.directoryworks.com>
From: Alexis Bor <alexis.bor@DirectoryWorks.com>
To: ietf-ids@umich.edu
Cc: iesg@ns.ietf.org
Subject: RE: immutable, permanent DNs @ Stanford
Date: Fri, 9 Jan 1998 15:09:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD1D53.9F100342"

In the example you reference the documentatoin on modifying the Netscape
Communicator for LDAP.  

Has anyone come across similar instructions for Microsoft products, such
as Outlook 98 or Outlook Express, as well as Internet Explorer?

-- Alexis

Alexis Bor
Directory Works, Inc.
16312 194th Avenue NE
Woodinville, WA  98072
425-788-7647
425-844-2375 (FAX)
alexis.bor@directoryworks.com
http://www.directoryworks.com 

> -----Original Message-----
> From: Jeff.Hodges@Stanford.EDU [mailto:Jeff.Hodges@Stanford.EDU]
> Sent: Friday, January 09, 1998 1:43 AM
> To: ietf-ids@umich.edu
> Cc: iesg@ietf.org
> 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>>