📄 rfc1617.txt
字号:
Network Working Group P. Barker
Request for Comments: 1617 University College London
RARE Technical Report: 11 S. Kille
Obsoletes: 1384 ISODE Consortium
Category: Informational T. Lenggenhager
SWITCH
May 1994
Naming and Structuring Guidelines for X.500 Directory Pilots
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
Deployment of a Directory will benefit from following certain
guidelines. This document defines a number of naming and structuring
guidelines focused on White Pages usage. Alignment to these
guidelines is recommended for directory pilots. The final version of
this document will replace RFC 1384.
Table of Contents
1. Introduction 2
2. DIT Structure 3
2.1. Structure Rules 3
2.2. The Top Level of the DIT 3
2.3. Countries 4
2.4. Organisations 5
2.4.1. Directory Manager, Postmaster & Secretary 5
2.4.2. Depth of tree 6
2.4.3. Real World Organisational Structure 7
2.5. Multi-National Organisations 7
2.5.1. The Multi-National as a Single Entity 7
2.5.2. The Multi-National as a Loose Confederation 8
2.5.3. Loosely Linked DIT Sub-Trees 9
2.5.4. Summary of Advantages and Disadvantages of the
Above Approaches 9
3. Naming Style 10
3.1. Multi-Component Relative Distinguished Names 11
3.2. National Guidelines for Naming 11
3.3. Naming Organisation and Organisational Unit Names 11
3.4. Naming Human Users 12
3.5. Application Entities 13
RARE Working Group on Network Applications Support (WG-NAP) [Page 1]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
4. Attribute Values 13
4.1. Basic Attribute Syntaxes 13
4.1.1. Printable String 14
4.1.2. IA5 String - T.50 14
4.1.3. Teletex String - T.61 14
4.1.4. Case Ignore String 14
4.1.5. Distinguished Name 14
4.2. Languages & Transliteration 14
4.2.1. Languages other than English 15
4.2.2. Transliteration 15
4.3. Access control 15
4.4. Selected Attributes 16
4.4.1. Personal Attributes 16
4.4.2. Organisational Attributes 18
4.4.3. Local Attributes 19
4.4.4. Miscellaneous Attributes 20
4.4.5. MHS Attributes 21
4.4.6. Postal Attributes 21
4.4.7. Telecom Attributes 22
5. Miscellany 22
5.1. Schema consistency of aliases 22
5.2. Organisational Units 23
6. References 23
7. Security Considerations 23
8. Authors' Addresses 24
9. Appendix - Example Entries 25
1. Introduction
The intended audience for this document are mainly data managers
using X.500 Directory Services. With the help of these guidelines it
should be easier for them to define the structure for the part of the
Directory Information Tree they want to model, e.g., the
representation of their organisation in the Directory. In addition,
decisions like which data elements to store for each kind of entry
shall be supported.
These guidelines concentrate mainly on the White Pages use of the
Directory, the X.500 application with most operational experience
today, nonetheless many recommendations are also valid for other
applications of the Directory.
As a pre-requisite to this document, it is assumed that the COSINE
and Internet X.500 Schema is followed [1].
RARE Working Group on Network Applications Support (WG-NAP) [Page 2]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
2. DIT Structure
The majority of this document is concerned with DIT structure, naming
and the usage of attributes for organisations, organisational units
and personal entries.
This section briefly notes five other key issues.
2.1 Structure Rules
A DIT structure is suggested in Annex B of X.521 [2], and it is
recommended that Directory Pilots for White Pages services should
follow these guidelines. Some simple restrictions should be applied,
as described below. For further usage of the Directory like e-mail
routing with the Directory or storage of network information in the
Directory it will be necessary to follow the guidelines specified in
the respective documents.
One of the few exceptions to the basic DIT structure is, that
international organisations will be stored immediately under the root
of the tree. Multi-national organisations will be stored within the
framework outlined, but with some use of aliases and attributes such
as seeAlso to help bind together the constituent parts of these
organisations. This is discussed in more detail in section 2.5.
A general rule for the depth of a subtree is as follows: When a
subtree is mainly accessed via searching, it should be as flat as
possible to improve the performance, when the access will be mainly
through read operations, the depth of the subtree is not a
significant parameter for performance.
2.2 The Top Level of the DIT
The following information will be present at the top level of the
DIT:
Participating Countries
According to the standard the RDN is the ISO 3166 country code. In
addition, the entries should contain suitable values of the
friendlyCountryName attribute specified in RFC 1274. Use of this
attribute is described in more detail in section 4.4.4.
International Organisations
An international organisation is an organisation, such as the
United Nations, which inherently has a brief and scope covering
many nations. Such organisations might be considered to be
RARE Working Group on Network Applications Support (WG-NAP) [Page 3]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
supra-national and this, indeed, is the raison-d'etre of such
organisations. Such organisations will almost all be governmental
or quasi-governmental. A multi-national organisation is an
organisation which operates in more than one country, but is not
supra-national. This classification includes the large commercial
organisations whose production and sales are spread throughout a
large number of countries.
International organisations may be registered at the top level.
This will not be done for multi-national organisations. Currently
three organisations are registered so far: Inmarsat, Internet and
North Atlantic Treaty Organization.
Localities
A few localities will be registered under the root. The chief
purpose of these locality entries is to provide a "natural" parent
node for organisations which are supra-national, and yet which do
not have global authority in their particular field. Such
organisations will usually be governmental or quasi-governmental.
Example localities might include: Europe, Africa, West Indies.
Example organisations within Europe might include: European Court
of Justice, European Space Agency, European Commission.
DSA Information
Some information on DSAs may be needed at the top level. This
should be kept to a minimum.
The only directory information for which there is a recognised top
level registration authority is countries. Registration of other
information at the top level may potentially cause problems. At this
stage, it is argued that the benefit of limiting additional top level
registrations outweighs these problems. However, this potential
problem should be noted by anyone making use of such a registration.
2.3 Countries
The national standardisation bodies will define national guidelines
for the structure of the national part of the DIT. In the interim,
the following simple structure should suffice. The country entry will
appear immediately beneath the root of the tree. Organisations which
have national significance should have entries immediately beneath
their respective country entries. Smaller organisations which are
only known in a particular locality should be placed underneath
locality entries representing states or similar geographical
divisions. Entry for private persons will be listed under the
locality entries. An example plan evolving for the US is the work of
RARE Working Group on Network Applications Support (WG-NAP) [Page 4]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
the North American Directory Forum [3]. Another example is the
organisation of the X.500 namespace as standardized in Australia [4].
2.4 Organisations
Large organisations will probably need to be sub-divided by
organisational units to help in the disambiguation of entries for
people with common names. Entries for people and roles will be stored
beneath organisations or organisational units.
The organisation entry itself shall contain the information necessary
to contact the organisation: for example, postal address, telephone
and fax numbers.
Although the structure of organisations often changes considerably
over time, the aim should be to minimise the number of changes to the
DIT. Note that renaming a superior, department entry has the effect
of changing the DN of all subordinate entries. This has an
undesirable impact on the service for several reasons. Alias entries
and certain attributes or ordinary entries such as seeAlso, secretary
and roleOccupant use DNs to maintain links with other entries. These
references are one-way only and the Directory standard offers no
support to automatically update all references to an entry once its
DN changes.
2.4.1 Directory Manager, Postmaster & Secretary
Similar to messaging, where every domain has its postmaster address
it is highly recommended that each organisation in the X.500
Directory has two entries: Postmaster and Directory Manager. In
addition, Secretary entries for an organisation and its units should
be listed. If this guidance is followed, users will benefit because
it will be straightforward to find the right contacts for questions
or problems with the service.
These entries should use the object class organizationalRole with the
roleOccupant attributes containing the distinguished names of the
persons in charge of this role. The values
CN=Directory Manager
CN=Postmaster
CN=Secretary
should be added as additional values whenever another language than
English is used for the name of the entries.
RARE Working Group on Network Applications Support (WG-NAP) [Page 5]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
2.4.2 Depth of tree
The broad recommendation for White Pages is that the DIT should be as
flat as possible. A flat tree means that Directory names will be
relatively short, and probably somewhat similar in length and
component structure to paper mail addresses. A deep DIT would imply
long Directory names, with somewhat arbitrary component parts, with a
result which it is argued seems less natural. Any artificiality in
the choice of names militates against successful querying.
A presumption behind this style of naming is that most querying will
be supported by the user specifying convenient strings of characters
which will be mapped onto powerful search operations. The
alternative approach of the user browsing their way down the tree and
selecting names from large numbers of possibilities may be more
appropriate in some cases, and a deeper tree facilitates this.
However, these guidelines recommend a shallow tree, and implicitly a
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, the
structure of the DIT within organisations.
The structure of the upper levels of the tree will be determined in
due course by various registration authorities, and the pilot will
have to work within the given structure. However, it is important
that the various pilots are cognisant of what the structures are
likely to be, and move early to adopt these structures.
The other principal determinant of DIT depth is whether an
organisation splits its entries over a number of organisational
units, and if so, the number of levels. The recommendation here is
that this sub-division of organisations is kept to a minimum. A
maximum of two levels of organisational unit should suffice even for
large organisations. Organisations with only a few tens or hundreds
of employees should strongly consider not using organisational units
at all. It is noted that there may be some problems with choice of
unique RDNs when using a flat DIT structure. Multi-component RDNs can
alleviate this problem: see section 3.1. The standard X.521
recommends that an organizationalUnitName attribute can also be used
as a naming attribute to disambiguate entries [2]. Further
disambiguation may be achieved by the use of a personalTitle or
userId attribute in the RDN.
RARE Working Group on Network Applications Support (WG-NAP) [Page 6]
RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
2.4.3 Real World Organisational Structure
Another aspect on designing the DIT structure for an organisation is
the administrative structure within a company. Using the same
structure in the DIT might help in distributing maintenance authority
to the different units. Please note comments on the stability of the
DIT structure in section 2.4.
2.5 Multi-National Organisations
The standard says that only international organisations may be placed
under the root of the DIT. This implies that multi-national
organisations must be represented as a number of separate entries
underneath country or locality entries. This structure makes it more
awkward to use X.500 within a multi-national to provide an internal
organisational directory, as the data is now spread widely throughout
the DIT, rather than all being grouped within a single sub-tree.
Many people have expressed the view that this restriction is a severe
limitation of X.500, and argue that the intentions of the standard
should be ignored in this respect. This note argues, though, that the
standard should be followed.
No attempt to precisely define multinational organisation is essayed
here. Instead, the observation is made that the term is applied to a
variety of organisational structures, where an organisation operates
in more than one country. This suggests that a variety of DIT
structures may be appropriate to accommodate these different
organisational structures. This document suggests three approaches,
and notes some of the characteristics associated with each of these
approaches.
Before considering the approaches, it is worth bearing in mind again
that a major aim in the choice of a DIT structure is to facilitate
querying, and that approaches which militate against this should be
avoided wherever possible.
2.5.1 The Multi-National as a Single Entity
In many cases, a multi-national organisation will operate with a
highly centralised structure. While the organisation may have large
operations in a number of countries, the organisation is strongly
controlled from the centre and the disparate parts of the
organisation exist only as limbs of the main organisation. In such a
situation, the model shown in figure 1 may be the best choice.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -