Composition of an RDN

[Brian Williams <[e-mail]>]

I believe I have a naming / DIT structure problem. I don't know how to 
solve it. I'm looking for guidance.

I have been working on the naming convention / DIT structure for a 
distributed Directory application. In the near term, the leaf entries 
will be organizational persons and devices only. The devices are network 
devices for a very large TCP/IP network of personal computers, 
mainframes, and other computing systems, tied together using LANs, Hubs, 
Routers, X.25 and Frame Relay circuits, frame relay switches, and more. 
This network extends from coast-to-coast (Canada) serving an 
organization (actually an organizational unit) of some 40,000 people. It 
is foreseen that the Directory will be distributed across the country.

The organization unit is one that is subject to a lot of change and 
adjustment. Subordinate organizational units change shape, size, names, 
and even existence, with some regularity. Also, there is not necessarily 
any *logic* to the names given to such units.

I have spent quite a bit of time identifying what makes for a good 
Distinguished Name. ( There is lots of written material on this aspect 
of the Directory.) Basically, the qualities of a good name can be 
summarized as follow:

   - be user-friendly; i.e. easy to remember, and easy to guess, 
     given basic knowledge of the object,
   - have natural ambiguities solved through natural distinctions,
   - may be composed of common abbreviations,
   - be based upon static attributes to minimize changes, and
   - be constructed within specific character set restrictions.

Because of the dynamic nature of unit names in this organization, which 
often mean nothing to many people searching the Directory, I have 
decided against building a deep DIT with imbedded OUs. I also wish to 
fit into the recommended DIT as closely as possible, using existing 
object classes and attributes - only creating new one's where absolutely 
necessary.

Location is a key characteristic of the objects that this directory will 
contain. Location will also characterize the distribution of DSAs, thus 
locality should be part of the DN. Unfortunately, Devices and 
organizational people don't fall under locality (in the 
Recommendations), they come under organization or Org unit. I thus plan 
(subject to revision due to new understanding) to use a DIT as follows:

root
    \
    c=ca
       \
       o=national institution
          \
  ou=division a, locality = ***    (a 2 attribute RDN at this level)
     /          \
(device)        (organizational person)
common name=         common name=

Division A represents my particular OU. (Someone else manages o=national 
organization, and above.) We are spread across the country. (Many of the 
divisions of this national organization are similarly spread across the 
country, but there is no organizational links between those parts of the 
various divisions at a particular locality. We're like separate 
companies.) 

Some of the RDNs of the entries subordinate to o=national institution 
will be:

ou=division a, l=vancouver
ou=division a, l=edmonton
ou=division a, l=winnipeg
ou=division a, l=toronto
ou=division a, l=saint john

Each of these represent the root of a naming context. Immediately 
subordinate to these will be the device and organizational person 
entries.

We are coming to the area of my perceived problem. In many localities, 
this structure will suffice, however in the larger centres, I may 
require a finer locality definition, such as street address. I also 
expect that there will be a number of equivalent common names for a 
number of people. Adding another organizational unit level to the DIT 
may not be useful. Given the naming criteria presented above, who could 
distinguish between Bill Smith in Customer Service from Bill Smith in 
Customer Support. It may be better to use the Unique Identifier 
attribute.

Here is one of my questions.

If in an object class definition, it is defined that one value of two or 
more attribute types are to be used as the RDN of an entry, is it 
mandatory that both absolutely have to be used in every instance? Let me 
expand on this question.

Using the Bill Smith example above, can I use the unique identifier 
attribute only for those whose names where abiguity exists, and not use 
the attribute when there is no ambiguity; e.g. Roland Thorncliff (I just 
made that up - I don't think its too common a name. My apologies to you 
if you are a Roland Thorncliff.)

Similary, for my locality situation. Can I define street address as part 
of an RDN only for those locations where I need to supplement the 
municipality name? Or do I just include the street name as part of the 
locality attribute value.

Which is better? Which comforms to the spirit of the standards?

Example A - add an attribute to the RDN where needed

ou=division a, l=edmonton
ou=division a, l=winnipeg
ou=division a, l=toronto, street address=212 front street
ou=division a, l=toronto, street address=123 john street
ou=division a, l=saint john

Example B - add information to existing RDN value where needed

ou=division a, l=edmonton
ou=division a, l=winnipeg
ou=division a, l=toronto, 212 front street
ou=division a, l=toronto, 123 john street
ou=division a, l=saint john


I feel my latter problem would not exist if, within the recommended DIT, 
device and org person could appear below locality. A great number of 
other issues would go away if I could create a DIT as follows:

    root
        \
        c=ca
           \
           o=national institution
              \
        ou=division a
           /
        locality = **
         /      \
    (device)    (organizational person)
  common name=     common name=

My interpretation of the Recommended DIT suggests this does not conform, 
but I am not sure what problems it would introduce into my operations 
(I'm hoping for standard generic DSAs and DUAs without a need for custom 
development. My DSAs will be part of the global Directory and I want my 
division's directory to be accessible (i.e. some information readable) 
by Directory users not directly associated with our organization, hence 
my desire to stay as close to the standards as possible for those 
entries which may contain some "public" information. (I intend to create 
a number of new object classes attribute types, but these will be 
strictly for internal use only.)

These are my pressing questions of today. I have at hand both Rose's 
Little Black Book and Steedman's X.500, The Directory standard and its 
application. I also have the full set of the standards (in what appears 
to be final draft(1993)) plus Andrew Waugh's X.500 and the 1993 
Standard. I have most applicable RFCs, and numerous other documents 
found around the Internet and in libraries. I haven't found definitive 
answers to the questions posed above.

Any and all input will be appreciated. 

Regards,

Brian

[e-mail]