As per Relevance of the word structure, we have this rfc below:
Network Working Group P.
Requests for Comments 1384 University College
S.E. Hardcastle-
ISODE
January 1993
Naming Guidelines for Directory
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Deployment of a Directory will benefit from following
guidelines. This document defines a number of naming guidelines
Alignment to these guidelines is recommended for directory pilots
1
As a pre-requisite to this document, it is assumed that the
and Internet X.500 Schema is followed [1].
2 DIT
The majority of this document is concerned with DIT structure
naming for organisations, organisational units and personal entries
This section briefly notes three other key issues
2.1 The top level of the
The following information will be present at the top level of
DIT
Participating
The entries should contain suitable values of the "
Country" attribute
International
An international organisation is an organisation, such as
United Nations, which inherently has a brief and scope
many nations. Such organisations might be considered to
supra-national and this, indeed, is the raison-d'etre of
organisations. Such organisations will almost all be
or quasi-governmental. A multi-national organisation is
Barker & Hardcastle-Kille [Page 1]
RFC 1384 Naming Guidelines January 1993
organisation which operates in more than one country, but is
supra-national. This classification includes the large
organisations whose production and sales are spread throughout
large number of countries
International organisations, may be registered at the top level
This will not be done for multi-national organisations. The
international organisation registered so far is: Internet.
is not a formal registration, but is adopted for the
Directory Service
A few localities will be registered under the root. The
purpose of these locality entries is to provide a "natural"
node for organisations which are supra-national, and yet which
not have global authority in their particular field.
organisations will usually be governmental or quasi-governmental
Example localities might include: Europe, Africa, West Indies
Example organisations within Europe might include: European
of Justice, European Space Agency, European Commission
DSA
Some information on DSAs may be needed at the top level.
should be kept to a minimum
The only directory information for which there is a recognised
level registration authority is countries. Registration of
information at the top level may potentially cause problems. At
stage, it is argued that the benefits of additional top
registration outweighs these problems. However, this
problem should be noted by anyone making use of such a registration
2.2 The DNS within the
The rules for the DNS parts of the DIT are defined in [3].
modification to this is that the DNS tree will be rooted
"O=Internet", rather than at the root of the DIT
2.3 Access
An entry's object class attribute, and any attribute(s) used
naming an entry are of special significance and may be considered
be "structural". Any inability to access these attributes will
militate against successful querying of the Directory. For example
user interfaces typically limit the scope of their searches
searching for entries of a particular type, where the type of
is indicated by its object class. Thus, unless the intention is
bar public access to an entry or set of entries, the object class
Barker & Hardcastle-Kille [Page 2]
RFC 1384 Naming Guidelines January 1993
naming attributes should be publicly readable
3 Naming
The first goal of naming is to provide unique identifiers
entries. Once this is achieve, the next major goal in naming
should be to facilitate querying of the Directory. In particular
support for a naming structure which facilitates use of user
naming is desirable. Other considerations, such as
reflecting the organisational structure of an organisation, should
disregarded if this has an adverse effect on normal querying.
experience in the pilot has shown that a consistent approach
structure and naming is an aid to querying using a wide range of
interfaces, as interfaces are often optimised for DIT
which appear prevalent
Naming is dependent on a number of factors and these are
considered in turn
3.1 National
Where naming is being done in a country which has
guidelines for naming, these guidelines should in general
followed. These guidelines might be based on an
registration authority, or may make use use of an
registration mechanism (e.g., company name registration).
Where an organisation has a name which is nationally registered in
existing registry, this name is likely to be appropriate for use
the Directory, even in cases where there are no national guidelines
3.2 Structure
A DIT structure is suggested in Annex B of X.521, and it
recommended that Directory Pilots should follow a slightly
form of these guidelines. The rules should be extended for
DNS [3]. Some simple restrictions should be applied, as
below
For most countries pilots, the following simple structure
suffice. The country entry will appear immediately beneath the
of the tree. Organisations which have national significance
have entries immediately beneath their respective country entries
Smaller organisations which are only known in a particular
should be placed underneath locality entries representing states
similar geographical divisions. Large organisations will
need to be sub-divided by organisational units to help in
disambiguation of entries for people with common names. Entries
Barker & Hardcastle-Kille [Page 3]
RFC 1384 Naming Guidelines January 1993
people and roles will be stored beneath organisations
organisational units. An example plan evolving for the US is
work of the North American Directory Forum [2].
As noted above, there will be a few exceptions to this
structure. International organisations will be stored
under the root of the tree. Multi-national organisations will
stored within the framework outlined, but with some use of
and attributes such as seeAlso to help bind together the
parts of these organisations. This is discussed in more
later
3.3 Depth of
The broad recommendation is that the DIT should be as flat
possible. A flat tree means that Directory names will be
short, and probably somewhat similar in length and
structure to paper mail addresses. A deep DIT would imply
Directory names, with somewhat arbitrary component parts, with
result which it is argued seems less natural. Any artificiality
the choice of names militates against successful querying
A presumption behind this style of naming is that most querying
be supported by the user specifying convenient strings of
which will be mapped onto powerful search operations.
alternative approach of the user browsing their way down the tree
selecting names from large numbers of possibilities may be
appropriate in some cases, and a deeper tree facilitates this
However, these guidelines recommend a shallow tree, and implicitly
search oriented approach
It may be considered that there are two determinants of DIT depth
first, how far down the DIT an organisation is placed; second,
structure of the DIT within organisations
The structure of the upper levels of the tree will be determined
due course by various registration authorities, and the pilot
have to work within the given structure. However, it is
that the various pilots are cognisant of what the structures
likely to be, and move early to adopt these structures
The other principal determinant of DIT depth is whether
organisation splits its entries over a number of
units, and if so, the number of levels. The recommendation here
that this sub-division of organisations is kept to a minimum.
maximum of two levels of organisational unit should suffice even
large organisations. Organisations with only a few tens or
of employees should strongly consider not using organisational
Barker & Hardcastle-Kille [Page 4]
RFC 1384 Naming Guidelines January 1993
at all. It is noted that there may be some problems with choice
unique RDNs when using a flat DIT structure. Multiple value RDNs
alleviate this problem. The standard recommends that
organizationalUnitName attribute can also be used as a
attribute to disambiguate entries. Further disambiguation may
achieved by the use of a personalTitle attribute in the RDN
3.4 Organisation and Organisational Unit
The naming of organisations in the Directory will ultimately
under the jurisdiction of official naming authorities. In
interim, it is recommended that pilots and organisations follow
guidelines. An organisation's RDN should usually be the full name
the organisation, rather than just a set of initials. This
that University College London should be preferred over UCL.
example of the problems which a short name might cause is given
the proposed registration of AA for the Automobile Association.
seems reasonable at first glance, as the Automobile Association
well known by this acronym. However, it seems less reasonable in
broader perspective when you consider organisations such
Alcoholics Anonymous and American Airlines which use the
acronym. Just as initials should usually be avoided
organisational RDNs, so should formal names which, for example,
only on official charters and are not generally well known.
are two reasons for this approach
1. The names should be meaningful
2. The names should uniquely identify the organisation, and be
name which is unlikely to be challenged in an open
process. For example, UCL might well be challenged by
Carriers Ltd
The same arguments on naming style can be applied with even
force to the choice of RDNs for organisational units.
abbreviated names will be in common parlance within an organisation
they will almost always be meaningless outside of that organisation
While many people in academic computing habitually refer to CS
thinking of Computer Science, CS may be given several
interpretations. It could equally be interpreted as
Services, Cognitive Science, Clinical Science or even
Services
For both organisations and organisational units, extra
information should be stored in the directory as alternative
of the naming attribute. Thus, for University College London,
should be stored as an alternative organizationName attribute value
Similarly CS could be stored as an alternative
Barker & Hardcastle-Kille [Page 5]
RFC 1384 Naming Guidelines January 1993
value for Computer Science and any of the other departments
earlier. In general, entries will be located by searching, and so
is not essential to have names which are either memorable
guessable. Minimising of typing may be achieved by use of
selected alternate values
3.5 Naming human
A reasonably consistent approach to naming people is
critical as a large percentage of directory usage will be looking
information about people. User interfaces will be better able
assist users if entries have names conforming to a common format,
small group of formats. It is suggested that the RDN should
such a format. Alternative values of the common name
should be used to store extra naming information. It seems
to try to ensure that the RDN commonName value is genuinely the
common name for a person as it is likely that user interfaces
choose to place greater weight on matches on the RDN than on
on one of the alternative names. It is proposed that pilots
ignore the standard's recommendations on storing personal titles,
letters indicating academic and professional qualifications
the commonName attribute, as this overloads the commonName attribute
A personalTitle attribute has already been specified in the
and Internet Schema, and another attribute could be specified
information about qualifications
Furthermore, the common name attribute should not be used to
other attribute information such as telephone numbers, room numbers
or local codes. Such information should be stored within
appropriate attributes as defined in the COSINE and Internet X.500
Schema. If such attributes have to be used to disambiguate entries
multi-valued RDNs should be used, such that other attribute(s)
used for naming in addition to a common name
The choice of RDN for humans will be influenced by
considerations. In many countries the best choice will be of
form familiar-first-name surname. Thus, Steve Hardcastle-Kille
preferred as the RDN choice for one of this document's co-authors
while Stephen E. Hardcastle-Kille is stored as an
commonName value. Sets of initials should not be concatenated into
single "word", but be separated by spaces and/or "." characters
Pragmatic choices will have to be made for other cultures
3.6 Application
The guidelines of X.521 should be followed, in that the
entity should always be named relative to an Organisation
Organisational Unit. The application process will often
Barker & Hardcastle-Kille [Page 6]
RFC 1384 Naming Guidelines January 1993
to a system or host. In this case, the application entities
be named by Common Names which identify the service (e.g., "
Service"). In cases where there is no useful distinction
application process and application entity, the application
may be omitted (This is often done for DSAs in the current pilot).
4 Multinational
The standard says that only international organisations may be
under the root of the DIT. This implies that multi-
organisations must be represented as a number of separate
underneath country or locality entries. This structure makes it
awkward to use X.500 within a multi-national to provide an
organisational directory, as the data is now spread widely
the DIT, rather than all being grouped within a single sub-tree
Many people have expressed the view that this restriction is a
limitation of X.500, and argue that the intentions of the
should be ignored in this respect. This note argues, though,
the standard should be followed
No attempt to precisely define multinational organisation is
here. Instead, the observation is made that the term is applied to
variety of organisational structures, where an organisation
in more than one country. This suggests that a variety of
structures may be appropriate to accommodate these
organisational structures. This document suggests three approaches
and notes some of the characteristics associated with each of
approaches
Before considering the approaches, it is worth bearing in mind
that a major aim in the choice of a DIT structure is to
querying, and that approaches which militate against this should
avoided wherever possible
Barker & Hardcastle-Kille [Page 7]
RFC 1384 Naming Guidelines January 1993
4.1 The multi-national as a single
/ | \
/ | \
C=GB C=FR C=
/ | \
/ | \
O=MultiNat---->O=MultiNat<----O=
/ | \
/ | \
/ | \
l=abc ou=def l=
---> means "alias to
Figure 1: The multi-national as a single
In many cases, a multi-national organisation will operate with
highly centralised structure. While the organisation may have
operations in a number of countries, the organisation is
controlled from the centre and the disparate parts of
organisation exist only as limbs of the main organisation. In such
situation, the model shown in figure 1 may be the best choice.
organisation's entries all exist under a single sub-tree.
organisational structure beneath the organisation entry
reflect the perceived structure of the organisation, and so
recommendations on this matter can be made here. To assist
person querying the directory, alias entries should be created
all countries where the organisation operates
4.2 The multi-national as a loose
Another common model of organisational structure is that where
multi-national consists of a number of national entities, which
in large part independent of both sibling national entities, and
any central entity. In such cases, the model shown in Figure 2
be
Barker & Hardcastle-Kille [Page 8]
RFC 1384 Naming Guidelines January 1993
/ | \
/ | \
C=GB C=FR C=
/ | \
/ | \
O=MultiNat O=MultiNat O=
/ | / | \ | \
/ | / | \ | \
L=GB L=FR / | \ L=FR L=
L=GB L=FR L=
---> means "alias to
Figure 2: The multi-national as a loose
better choice. Organisational entries exist within each country,
only that country's localities and organisational units
directly beneath the appropriate organisational entry. Some
together of the various parts of the organisation can be achieved
the use of aliases for localities and organisational units, and
can be done in a highly flexible fashion. In some cases,
national view might not contain all branches of the company,
illustrated in Figure 2.
4.3 Loosely linked DIT sub-
A third approach is to avoid aliasing altogether, and to use
looser binding provided by an attribute such as seeAlso.
approach treats all parts of an organisation as essentially separate
A unified view of the organisation can only be achieved by
interfaces choosing to follow the seeAlso links. This is a
difference with aliasing, where decisions to follow links may
specified within the protocol. (Note that it may be better
specify another attribute for this purpose, as seeAlso is likely
be used for a wide variety of purposes.)
4.4 Summary of advantages and disadvantages of the above
Providing an internal
All the above methods can be used to provide an
directory. In the first two cases, the linkage to other parts
the organisation can be followed by the protocol and
Barker & Hardcastle-Kille [Page 9]
RFC 1384 Naming Guidelines January 1993
organisation-wide searches can be achieved by single X.500
operations. In the last case, interfaces would have to "know"
follow the soft links indicated by the seeAlso attribute
Impact on
In the single-entity model, all DNs within the organisation
be under one country. It could be argued that this will
result in rather "unnatural" naming. In the loose-
model, DNs are more natural, although the need to
between organisational units and localities on an international
rather than just a national, basis may have some impact on
choice of names. For example, it may be necessary to add in
extra level of organisational unit or locality information.
the loosely-linked model, there is no impact on naming at all
Views of the
The first method provides a unique view of the organisation.
loose confederacy allows for a variety of views of
organisation. The view from the centre of the organisation
well be that all constituent organisations should be seen as
of the main organisation, whereas other parts of the
may only be interested in the organisation's centre and a few
its sibling organisations. The third model gives an
flexible view of organisational structures
Lookup
All methods should perform reasonably well, providing
is held, or at least replicated, within a single DSA
5
This section draws attention to two areas which frequently
questions, and where it is felt that a consistent approach will
useful
5.1 Schema consistency of
According to the letter of the standard, an alias may point at
entry. It is beneficial for aliases to be ``schema consistent''.
The following two checks should be made
1. The Relative Distinguished Name of the alias should be a
Relative Distinguished Name of the entry
2. If the entry (aliased object) were placed where the alias is
there should be no schema violation
Barker & Hardcastle-Kille [Page 10]
RFC 1384 Naming Guidelines January 1993
5.2 Organisational
There is a problem that many organisations can be
organisations or organisational units, dependent on the location
the DIT (with aliases giving the alternate names). For example,
organisation may be an independent national organisation and also
organisational unit of a parent organisation. To achieve this, it
important to allow an entry to be of both object class
and of object class organisational unit
[1] P. Barker and S.E. Hardcastle-Kille. The COSINE and
X.500 schema. Request for Comments RFC 1274, Department
Computer Science, University College London, November 1991.
[2] The North American Directory Forum. A Naming Scheme for C=US
September 1991. Also NADF-175.
[3] S.E. Hardcastle-Kille. X.500 and domains. Request for
RFC 1279, Department of Computer Science, University
London, November 1991.
6 Security
Security issues are not discussed in this memo
Barker & Hardcastle-Kille [Page 11]
RFC 1384 Naming Guidelines January 1993
7 Authors'
Paul
Department of Computer
University College
Gower
WC1E 6
Phone:+44-71-380-7366
EMail: P.Barker@CS.UCL.AC.
Steve Hardcastle-
ISODE
P.O. Box 505
SW11 1
Phone:+44-71-223-4062
EMail: S.Kille@ISODE.
Barker & Hardcastle-Kille [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
