Difference between revisions of "RFC1384"
imported>Admin (Created page with " Network Working Group P. Barker Requests for Comments 1384 University College London ...") |
|||
Line 1: | Line 1: | ||
− | |||
Line 10: | Line 9: | ||
ISODE Consortium | ISODE Consortium | ||
January 1993 | January 1993 | ||
− | |||
Naming Guidelines for Directory Pilots | Naming Guidelines for Directory Pilots | ||
− | |||
Status of this Memo | Status of this Memo | ||
− | |||
This memo provides information for the Internet community. It does | This memo provides information for the Internet community. It does | ||
not specify an Internet standard. Distribution of this memo is | not specify an Internet standard. Distribution of this memo is | ||
unlimited. | unlimited. | ||
− | |||
Abstract | Abstract | ||
− | |||
Deployment of a Directory will benefit from following certain | Deployment of a Directory will benefit from following certain | ||
guidelines. This document defines a number of naming guidelines. | guidelines. This document defines a number of naming guidelines. | ||
Alignment to these guidelines is recommended for directory pilots. | Alignment to these guidelines is recommended for directory pilots. | ||
− | |||
1 Introduction | 1 Introduction | ||
− | |||
As a pre-requisite to this document, it is assumed that the COSINE | As a pre-requisite to this document, it is assumed that the COSINE | ||
and Internet X.500 Schema is followed [1]. | and Internet X.500 Schema is followed [1]. | ||
− | |||
2 DIT structure | 2 DIT structure | ||
− | |||
The majority of this document is concerned with DIT structure and | The majority of this document is concerned with DIT structure and | ||
naming for organisations, organisational units and personal entries. | naming for organisations, organisational units and personal entries. | ||
This section briefly notes three other key issues. | This section briefly notes three other key issues. | ||
− | + | === The top level of the DIT === | |
− | |||
− | |||
The following information will be present at the top level of the | The following information will be present at the top level of the | ||
DIT: | DIT: | ||
− | |||
Participating Countries | Participating Countries | ||
The entries should contain suitable values of the "Friendly | The entries should contain suitable values of the "Friendly | ||
Country" attribute. | Country" attribute. | ||
− | |||
International Organisations | International Organisations | ||
An international organisation is an organisation, such as the | An international organisation is an organisation, such as the | ||
Line 53: | Line 39: | ||
organisations. Such organisations will almost all be governmental | organisations. Such organisations will almost all be governmental | ||
or quasi-governmental. A multi-national organisation is an | or quasi-governmental. A multi-national organisation is an | ||
+ | |||
+ | |||
Line 62: | Line 50: | ||
organisations whose production and sales are spread throughout a | organisations whose production and sales are spread throughout a | ||
large number of countries. | large number of countries. | ||
− | |||
International organisations, may be registered at the top level. | International organisations, may be registered at the top level. | ||
This will not be done for multi-national organisations. The only | This will not be done for multi-national organisations. The only | ||
Line 68: | Line 55: | ||
is not a formal registration, but is adopted for the Internet | is not a formal registration, but is adopted for the Internet | ||
Directory Service. | Directory Service. | ||
− | |||
Localities | Localities | ||
A few localities will be registered under the root. The chief | A few localities will be registered under the root. The chief | ||
Line 78: | Line 64: | ||
Example organisations within Europe might include: European Court | Example organisations within Europe might include: European Court | ||
of Justice, European Space Agency, European Commission. | of Justice, European Space Agency, European Commission. | ||
− | |||
DSA Information | DSA Information | ||
Some information on DSAs may be needed at the top level. This | Some information on DSAs may be needed at the top level. This | ||
should be kept to a minimum. | should be kept to a minimum. | ||
− | |||
The only directory information for which there is a recognised top | The only directory information for which there is a recognised top | ||
level registration authority is countries. Registration of other | level registration authority is countries. Registration of other | ||
Line 89: | Line 73: | ||
registration outweighs these problems. However, this potential | registration outweighs these problems. However, this potential | ||
problem should be noted by anyone making use of such a registration. | problem should be noted by anyone making use of such a registration. | ||
− | + | === The DNS within the DIT === | |
− | |||
− | |||
The rules for the DNS parts of the DIT are defined in [3]. One | The rules for the DNS parts of the DIT are defined in [3]. One | ||
modification to this is that the DNS tree will be rooted under | modification to this is that the DNS tree will be rooted under | ||
"O=Internet", rather than at the root of the DIT. | "O=Internet", rather than at the root of the DIT. | ||
− | + | === Access control === | |
− | |||
− | |||
An entry's object class attribute, and any attribute(s) used for | An entry's object class attribute, and any attribute(s) used for | ||
naming an entry are of special significance and may be considered to | naming an entry are of special significance and may be considered to | ||
Line 106: | Line 86: | ||
is indicated by its object class. Thus, unless the intention is to | is indicated by its object class. Thus, unless the intention is to | ||
bar public access to an entry or set of entries, the object class and | bar public access to an entry or set of entries, the object class and | ||
+ | |||
+ | |||
Line 112: | Line 94: | ||
naming attributes should be publicly readable. | naming attributes should be publicly readable. | ||
− | |||
3 Naming Style | 3 Naming Style | ||
− | |||
The first goal of naming is to provide unique identifiers for | The first goal of naming is to provide unique identifiers for | ||
entries. Once this is achieve, the next major goal in naming entries | entries. Once this is achieve, the next major goal in naming entries | ||
Line 126: | Line 106: | ||
interfaces, as interfaces are often optimised for DIT structures | interfaces, as interfaces are often optimised for DIT structures | ||
which appear prevalent. | which appear prevalent. | ||
− | |||
Naming is dependent on a number of factors and these are now | Naming is dependent on a number of factors and these are now | ||
considered in turn. | considered in turn. | ||
− | + | === National Guidelines === | |
− | |||
− | |||
Where naming is being done in a country which has established | Where naming is being done in a country which has established | ||
guidelines for naming, these guidelines should in general be | guidelines for naming, these guidelines should in general be | ||
Line 137: | Line 114: | ||
registration authority, or may make use use of an existing | registration authority, or may make use use of an existing | ||
registration mechanism (e.g., company name registration). | registration mechanism (e.g., company name registration). | ||
− | |||
Where an organisation has a name which is nationally registered in an | Where an organisation has a name which is nationally registered in an | ||
existing registry, this name is likely to be appropriate for use in | existing registry, this name is likely to be appropriate for use in | ||
the Directory, even in cases where there are no national guidelines. | the Directory, even in cases where there are no national guidelines. | ||
− | + | === Structure Rules === | |
− | |||
− | |||
A DIT structure is suggested in Annex B of X.521, and it is | A DIT structure is suggested in Annex B of X.521, and it is | ||
recommended that Directory Pilots should follow a slightly modified | recommended that Directory Pilots should follow a slightly modified | ||
Line 149: | Line 123: | ||
DNS [3]. Some simple restrictions should be applied, as described | DNS [3]. Some simple restrictions should be applied, as described | ||
below. | below. | ||
− | |||
For most countries pilots, the following simple structure should | For most countries pilots, the following simple structure should | ||
suffice. The country entry will appear immediately beneath the root | suffice. The country entry will appear immediately beneath the root | ||
Line 159: | Line 132: | ||
need to be sub-divided by organisational units to help in the | need to be sub-divided by organisational units to help in the | ||
disambiguation of entries for people with common names. Entries for | disambiguation of entries for people with common names. Entries for | ||
+ | |||
+ | |||
Line 167: | Line 142: | ||
organisational units. An example plan evolving for the US is the | organisational units. An example plan evolving for the US is the | ||
work of the North American Directory Forum [2]. | work of the North American Directory Forum [2]. | ||
− | |||
As noted above, there will be a few exceptions to this basic | As noted above, there will be a few exceptions to this basic | ||
structure. International organisations will be stored immediately | structure. International organisations will be stored immediately | ||
Line 175: | Line 149: | ||
parts of these organisations. This is discussed in more detail | parts of these organisations. This is discussed in more detail | ||
later. | later. | ||
− | + | === Depth of tree === | |
− | |||
− | |||
The broad recommendation is that the DIT should be as flat as | The broad recommendation is that the DIT should be as flat as | ||
possible. A flat tree means that Directory names will be relatively | possible. A flat tree means that Directory names will be relatively | ||
Line 185: | Line 157: | ||
result which it is argued seems less natural. Any artificiality in | result which it is argued seems less natural. Any artificiality in | ||
the choice of names militates against successful querying. | the choice of names militates against successful querying. | ||
− | |||
A presumption behind this style of naming is that most querying will | A presumption behind this style of naming is that most querying will | ||
be supported by the user specifying convenient strings of characters | be supported by the user specifying convenient strings of characters | ||
Line 194: | Line 165: | ||
However, these guidelines recommend a shallow tree, and implicitly a | However, these guidelines recommend a shallow tree, and implicitly a | ||
search oriented approach. | search oriented approach. | ||
− | |||
It may be considered that there are two determinants of DIT depth: | It may be considered that there are two determinants of DIT depth: | ||
first, how far down the DIT an organisation is placed; second, the | first, how far down the DIT an organisation is placed; second, the | ||
structure of the DIT within organisations. | structure of the DIT within organisations. | ||
− | |||
The structure of the upper levels of the tree will be determined in | The structure of the upper levels of the tree will be determined in | ||
due course by various registration authorities, and the pilot will | due course by various registration authorities, and the pilot will | ||
Line 204: | Line 173: | ||
that the various pilots are cognisant of what the structures are | that the various pilots are cognisant of what the structures are | ||
likely to be, and move early to adopt these structures. | likely to be, and move early to adopt these structures. | ||
− | |||
The other principal determinant of DIT depth is whether an | The other principal determinant of DIT depth is whether an | ||
organisation splits its entries over a number of organisational | organisation splits its entries over a number of organisational | ||
Line 212: | Line 180: | ||
large organisations. Organisations with only a few tens or hundreds | large organisations. Organisations with only a few tens or hundreds | ||
of employees should strongly consider not using organisational units | of employees should strongly consider not using organisational units | ||
+ | |||
+ | |||
Line 223: | Line 193: | ||
attribute to disambiguate entries. Further disambiguation may be | attribute to disambiguate entries. Further disambiguation may be | ||
achieved by the use of a personalTitle attribute in the RDN. | achieved by the use of a personalTitle attribute in the RDN. | ||
− | + | === Organisation and Organisational Unit Names === | |
− | |||
− | |||
The naming of organisations in the Directory will ultimately come | The naming of organisations in the Directory will ultimately come | ||
under the jurisdiction of official naming authorities. In the | under the jurisdiction of official naming authorities. In the | ||
Line 242: | Line 210: | ||
only on official charters and are not generally well known. There | only on official charters and are not generally well known. There | ||
are two reasons for this approach: | are two reasons for this approach: | ||
− | |||
1. The names should be meaningful. | 1. The names should be meaningful. | ||
− | |||
2. The names should uniquely identify the organisation, and be a | 2. The names should uniquely identify the organisation, and be a | ||
name which is unlikely to be challenged in an open registration | name which is unlikely to be challenged in an open registration | ||
process. For example, UCL might well be challenged by United | process. For example, UCL might well be challenged by United | ||
Carriers Ltd. | Carriers Ltd. | ||
− | |||
The same arguments on naming style can be applied with even greater | The same arguments on naming style can be applied with even greater | ||
force to the choice of RDNs for organisational units. While | force to the choice of RDNs for organisational units. While | ||
Line 259: | Line 224: | ||
Services, Cognitive Science, Clinical Science or even Counselling | Services, Cognitive Science, Clinical Science or even Counselling | ||
Services. | Services. | ||
− | |||
For both organisations and organisational units, extra naming | For both organisations and organisational units, extra naming | ||
information should be stored in the directory as alternative values | information should be stored in the directory as alternative values | ||
Line 265: | Line 229: | ||
should be stored as an alternative organizationName attribute value. | should be stored as an alternative organizationName attribute value. | ||
Similarly CS could be stored as an alternative organizationalUnitName | Similarly CS could be stored as an alternative organizationalUnitName | ||
+ | |||
+ | |||
Line 275: | Line 241: | ||
guessable. Minimising of typing may be achieved by use of carefully | guessable. Minimising of typing may be achieved by use of carefully | ||
selected alternate values. | selected alternate values. | ||
− | + | === Naming human users === | |
− | |||
− | |||
A reasonably consistent approach to naming people is particularly | A reasonably consistent approach to naming people is particularly | ||
critical as a large percentage of directory usage will be looking up | critical as a large percentage of directory usage will be looking up | ||
Line 295: | Line 259: | ||
and Internet Schema, and another attribute could be specified for | and Internet Schema, and another attribute could be specified for | ||
information about qualifications. | information about qualifications. | ||
− | |||
Furthermore, the common name attribute should not be used to hold | Furthermore, the common name attribute should not be used to hold | ||
other attribute information such as telephone numbers, room numbers, | other attribute information such as telephone numbers, room numbers, | ||
Line 303: | Line 266: | ||
multi-valued RDNs should be used, such that other attribute(s) be | multi-valued RDNs should be used, such that other attribute(s) be | ||
used for naming in addition to a common name. | used for naming in addition to a common name. | ||
− | |||
The choice of RDN for humans will be influenced by cultural | The choice of RDN for humans will be influenced by cultural | ||
considerations. In many countries the best choice will be of the | considerations. In many countries the best choice will be of the | ||
Line 312: | Line 274: | ||
single "word", but be separated by spaces and/or "." characters. | single "word", but be separated by spaces and/or "." characters. | ||
Pragmatic choices will have to be made for other cultures. | Pragmatic choices will have to be made for other cultures. | ||
− | + | === Application Entities === | |
− | |||
− | |||
The guidelines of X.521 should be followed, in that the application | The guidelines of X.521 should be followed, in that the application | ||
entity should always be named relative to an Organisation or | entity should always be named relative to an Organisation or | ||
Organisational Unit. The application process will often correspond | Organisational Unit. The application process will often correspond | ||
+ | |||
+ | |||
Line 328: | Line 290: | ||
application process and application entity, the application process | application process and application entity, the application process | ||
may be omitted (This is often done for DSAs in the current pilot). | may be omitted (This is often done for DSAs in the current pilot). | ||
− | |||
4 Multinational Organisations | 4 Multinational Organisations | ||
− | |||
The standard says that only international organisations may be placed | The standard says that only international organisations may be placed | ||
under the root of the DIT. This implies that multi-national | under the root of the DIT. This implies that multi-national | ||
Line 342: | Line 302: | ||
should be ignored in this respect. This note argues, though, that | should be ignored in this respect. This note argues, though, that | ||
the standard should be followed. | the standard should be followed. | ||
− | |||
No attempt to precisely define multinational organisation is essayed | No attempt to precisely define multinational organisation is essayed | ||
here. Instead, the observation is made that the term is applied to a | here. Instead, the observation is made that the term is applied to a | ||
Line 351: | Line 310: | ||
and notes some of the characteristics associated with each of these | and notes some of the characteristics associated with each of these | ||
approaches. | approaches. | ||
− | |||
Before considering the approaches, it is worth bearing in mind again | 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 | that a major aim in the choice of a DIT structure is to facilitate | ||
Line 376: | Line 334: | ||
− | |||
+ | |||
+ | === The multi-national as a single entity === | ||
ROOT | ROOT | ||
Line 390: | Line 349: | ||
/ | \ | / | \ | ||
l=abc ou=def l=fgi | l=abc ou=def l=fgi | ||
− | |||
---> means "alias to" | ---> means "alias to" | ||
− | |||
Figure 1: The multi-national as a single entity | Figure 1: The multi-national as a single entity | ||
− | |||
In many cases, a multi-national organisation will operate with a | In many cases, a multi-national organisation will operate with a | ||
Line 409: | Line 365: | ||
person querying the directory, alias entries should be created for | person querying the directory, alias entries should be created for | ||
all countries where the organisation operates. | all countries where the organisation operates. | ||
− | + | === The multi-national as a loose confederation === | |
− | |||
− | |||
Another common model of organisational structure is that where a | Another common model of organisational structure is that where a | ||
multi-national consists of a number of national entities, which are | multi-national consists of a number of national entities, which are | ||
Line 417: | Line 371: | ||
any central entity. In such cases, the model shown in Figure 2 may | any central entity. In such cases, the model shown in Figure 2 may | ||
be a | be a | ||
+ | |||
+ | |||
Line 440: | Line 396: | ||
L=GB L=FR / | \ L=FR L=US | L=GB L=FR / | \ L=FR L=US | ||
L=GB L=FR L=US | L=GB L=FR L=US | ||
− | |||
---> means "alias to" | ---> means "alias to" | ||
− | |||
Figure 2: The multi-national as a loose confederation | Figure 2: The multi-national as a loose confederation | ||
− | |||
better choice. Organisational entries exist within each country, and | better choice. Organisational entries exist within each country, and | ||
Line 456: | Line 409: | ||
national view might not contain all branches of the company, as | national view might not contain all branches of the company, as | ||
illustrated in Figure 2. | illustrated in Figure 2. | ||
− | + | === Loosely linked DIT sub-trees === | |
− | |||
− | |||
A third approach is to avoid aliasing altogether, and to use the | A third approach is to avoid aliasing altogether, and to use the | ||
looser binding provided by an attribute such as seeAlso. This | looser binding provided by an attribute such as seeAlso. This | ||
approach treats all parts of an organisation as essentially separate. | approach treats all parts of an organisation as essentially separate. | ||
− | |||
A unified view of the organisation can only be achieved by user | A unified view of the organisation can only be achieved by user | ||
interfaces choosing to follow the seeAlso links. This is a key | interfaces choosing to follow the seeAlso links. This is a key | ||
Line 470: | Line 420: | ||
specify another attribute for this purpose, as seeAlso is likely to | specify another attribute for this purpose, as seeAlso is likely to | ||
be used for a wide variety of purposes.) | be used for a wide variety of purposes.) | ||
− | + | === Summary of advantages and disadvantages of the above approaches === | |
− | |||
− | |||
Providing an internal directory | Providing an internal directory | ||
All the above methods can be used to provide an internal | All the above methods can be used to provide an internal | ||
directory. In the first two cases, the linkage to other parts of | directory. In the first two cases, the linkage to other parts of | ||
the organisation can be followed by the protocol and thus | the organisation can be followed by the protocol and thus | ||
+ | |||
+ | |||
Line 485: | Line 435: | ||
operations. In the last case, interfaces would have to "know" to | operations. In the last case, interfaces would have to "know" to | ||
follow the soft links indicated by the seeAlso attribute. | follow the soft links indicated by the seeAlso attribute. | ||
− | |||
Impact on naming | Impact on naming | ||
In the single-entity model, all DNs within the organisation will | In the single-entity model, all DNs within the organisation will | ||
Line 496: | Line 445: | ||
extra level of organisational unit or locality information. In | extra level of organisational unit or locality information. In | ||
the loosely-linked model, there is no impact on naming at all. | the loosely-linked model, there is no impact on naming at all. | ||
− | |||
Views of the organisation | Views of the organisation | ||
The first method provides a unique view of the organisation. The | The first method provides a unique view of the organisation. The | ||
Line 506: | Line 454: | ||
its sibling organisations. The third model gives an equally | its sibling organisations. The third model gives an equally | ||
flexible view of organisational structures. | flexible view of organisational structures. | ||
− | |||
Lookup performance | Lookup performance | ||
All methods should perform reasonably well, providing information | All methods should perform reasonably well, providing information | ||
is held, or at least replicated, within a single DSA. | is held, or at least replicated, within a single DSA. | ||
− | |||
5 Miscellany | 5 Miscellany | ||
− | |||
This section draws attention to two areas which frequently provoke | This section draws attention to two areas which frequently provoke | ||
questions, and where it is felt that a consistent approach will be | questions, and where it is felt that a consistent approach will be | ||
useful. | useful. | ||
− | + | === Schema consistency of aliases === | |
− | |||
− | |||
According to the letter of the standard, an alias may point at any | According to the letter of the standard, an alias may point at any | ||
entry. It is beneficial for aliases to be ``schema consistent''. | entry. It is beneficial for aliases to be ``schema consistent''. | ||
The following two checks should be made: | The following two checks should be made: | ||
− | |||
1. The Relative Distinguished Name of the alias should be a valid | 1. The Relative Distinguished Name of the alias should be a valid | ||
Relative Distinguished Name of the entry. | Relative Distinguished Name of the entry. | ||
− | |||
2. If the entry (aliased object) were placed where the alias is, | 2. If the entry (aliased object) were placed where the alias is, | ||
there should be no schema violation. | there should be no schema violation. | ||
Line 535: | Line 476: | ||
− | |||
+ | |||
+ | === Organisational Units === | ||
There is a problem that many organisations can be either | There is a problem that many organisations can be either | ||
organisations or organisational units, dependent on the location in | organisations or organisational units, dependent on the location in | ||
Line 544: | Line 486: | ||
important to allow an entry to be of both object class organisation | important to allow an entry to be of both object class organisation | ||
and of object class organisational unit. | and of object class organisational unit. | ||
− | |||
References | References | ||
− | |||
[1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet | [1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet | ||
− | X.500 schema. Request for Comments | + | X.500 schema. Request for Comments RFC 1274, Department of |
Computer Science, University College London, November 1991. | Computer Science, University College London, November 1991. | ||
− | |||
[2] The North American Directory Forum. A Naming Scheme for C=US, | [2] The North American Directory Forum. A Naming Scheme for C=US, | ||
September 1991. Also NADF-175. | September 1991. Also NADF-175. | ||
− | |||
[3] S.E. Hardcastle-Kille. X.500 and domains. Request for Comments | [3] S.E. Hardcastle-Kille. X.500 and domains. Request for Comments | ||
− | + | RFC 1279, Department of Computer Science, University College | |
London, November 1991. | London, November 1991. | ||
+ | 6 Security Considerations | ||
+ | Security issues are not discussed in this memo. | ||
− | |||
− | |||
Line 589: | Line 527: | ||
7 Authors' Addresses | 7 Authors' Addresses | ||
− | |||
Paul Barker | Paul Barker | ||
Department of Computer Science | Department of Computer Science | ||
Line 596: | Line 533: | ||
WC1E 6BT | WC1E 6BT | ||
England | England | ||
− | |||
Phone:+44-71-380-7366 | Phone:+44-71-380-7366 | ||
− | |||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Steve Hardcastle-Kille | Steve Hardcastle-Kille | ||
ISODE Consortium | ISODE Consortium | ||
Line 608: | Line 542: | ||
SW11 1DX | SW11 1DX | ||
England | England | ||
− | |||
Phone:+44-71-223-4062 | Phone:+44-71-223-4062 | ||
− | |||
EMail: [email protected] | EMail: [email protected] |
Revision as of 07:09, 23 September 2020
Network Working Group P. Barker Requests for Comments 1384 University College London
S.E. Hardcastle-Kille ISODE Consortium January 1993
Naming Guidelines for Directory Pilots
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. 1 Introduction As a pre-requisite to this document, it is assumed that the COSINE and Internet X.500 Schema is followed [1]. 2 DIT structure The majority of this document is concerned with DIT structure and naming for organisations, organisational units and personal entries. This section briefly notes three other key issues.
Contents
- 1 The top level of the DIT
- 2 The DNS within the DIT
- 3 Access control
- 4 National Guidelines
- 5 Structure Rules
- 6 Depth of tree
- 7 Organisation and Organisational Unit Names
- 8 Naming human users
- 9 Application Entities
- 10 The multi-national as a single entity
- 11 The multi-national as a loose confederation
- 12 Loosely linked DIT sub-trees
- 13 Summary of advantages and disadvantages of the above approaches
- 14 Schema consistency of aliases
- 15 Organisational Units
The top level of the DIT
The following information will be present at the top level of the DIT: Participating Countries
The entries should contain suitable values of the "Friendly Country" attribute.
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 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. The only international organisation registered so far is: Internet. This is not a formal registration, but is adopted for the Internet Directory Service.
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 benefits of additional top level registration outweighs these problems. However, this potential problem should be noted by anyone making use of such a registration.
The DNS within the DIT
The rules for the DNS parts of the DIT are defined in [3]. One modification to this is that the DNS tree will be rooted under "O=Internet", rather than at the root of the DIT.
Access control
An entry's object class attribute, and any attribute(s) used for naming an entry are of special significance and may be considered to be "structural". Any inability to access these attributes will often militate against successful querying of the Directory. For example, user interfaces typically limit the scope of their searches by searching for entries of a particular type, where the type of entry is indicated by its object class. Thus, unless the intention is to bar public access to an entry or set of entries, the object class and
naming attributes should be publicly readable. 3 Naming Style The first goal of naming is to provide unique identifiers for entries. Once this is achieve, the next major goal in naming entries should be to facilitate querying of the Directory. In particular, support for a naming structure which facilitates use of user friendly naming is desirable. Other considerations, such as accurately reflecting the organisational structure of an organisation, should be disregarded if this has an adverse effect on normal querying. Early experience in the pilot has shown that a consistent approach to structure and naming is an aid to querying using a wide range of user interfaces, as interfaces are often optimised for DIT structures which appear prevalent. Naming is dependent on a number of factors and these are now considered in turn.
National Guidelines
Where naming is being done in a country which has established guidelines for naming, these guidelines should in general be followed. These guidelines might be based on an established registration authority, or may make use use of an existing registration mechanism (e.g., company name registration). Where an organisation has a name which is nationally registered in an existing registry, this name is likely to be appropriate for use in the Directory, even in cases where there are no national guidelines.
Structure Rules
A DIT structure is suggested in Annex B of X.521, and it is recommended that Directory Pilots should follow a slightly modified form of these guidelines. The rules should be extended for handling DNS [3]. Some simple restrictions should be applied, as described below. For most countries pilots, 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. 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. An example plan evolving for the US is the work of the North American Directory Forum [2]. As noted above, there will be a few exceptions to this basic structure. 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 later.
Depth of tree
The broad recommendation 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. Multiple value RDNs can alleviate this problem. The standard recommends that an organizationalUnitName attribute can also be used as a naming attribute to disambiguate entries. Further disambiguation may be achieved by the use of a personalTitle attribute in the RDN.
Organisation and Organisational Unit Names
The naming of organisations in the Directory will ultimately come under the jurisdiction of official naming authorities. In the interim, it is recommended that pilots and organisations follow these guidelines. An organisation's RDN should usually be the full name of the organisation, rather than just a set of initials. This means that University College London should be preferred over UCL. An example of the problems which a short name might cause is given by the proposed registration of AA for the Automobile Association. This seems reasonable at first glance, as the Automobile Association is well known by this acronym. However, it seems less reasonable in a broader perspective when you consider organisations such as Alcoholics Anonymous and American Airlines which use the same acronym. Just as initials should usually be avoided for organisational RDNs, so should formal names which, for example, exist only on official charters and are not generally well known. There are two reasons for this approach: 1. The names should be meaningful. 2. The names should uniquely identify the organisation, and be a
name which is unlikely to be challenged in an open registration process. For example, UCL might well be challenged by United Carriers Ltd.
The same arguments on naming style can be applied with even greater force to the choice of RDNs for organisational units. While 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 when thinking of Computer Science, CS may be given several different interpretations. It could equally be interpreted as Computing Services, Cognitive Science, Clinical Science or even Counselling Services. For both organisations and organisational units, extra naming information should be stored in the directory as alternative values of the naming attribute. Thus, for University College London, UCL should be stored as an alternative organizationName attribute value. Similarly CS could be stored as an alternative organizationalUnitName
value for Computer Science and any of the other departments cited earlier. In general, entries will be located by searching, and so it is not essential to have names which are either memorable or guessable. Minimising of typing may be achieved by use of carefully selected alternate values.
Naming human users
A reasonably consistent approach to naming people is particularly critical as a large percentage of directory usage will be looking up information about people. User interfaces will be better able to assist users if entries have names conforming to a common format, or small group of formats. It is suggested that the RDN should follow such a format. Alternative values of the common name attribute should be used to store extra naming information. It seems sensible to try to ensure that the RDN commonName value is genuinely the most common name for a person as it is likely that user interfaces may choose to place greater weight on matches on the RDN than on matches on one of the alternative names. It is proposed that pilots should ignore the standard's recommendations on storing personal titles, and letters indicating academic and professional qualifications within the commonName attribute, as this overloads the commonName attribute. A personalTitle attribute has already been specified in the COSINE and Internet Schema, and another attribute could be specified for information about qualifications. Furthermore, the common name attribute should not be used to hold other attribute information such as telephone numbers, room numbers, or local codes. Such information should be stored within the 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) be used for naming in addition to a common name. The choice of RDN for humans will be influenced by cultural considerations. In many countries the best choice will be of the form familiar-first-name surname. Thus, Steve Hardcastle-Kille is preferred as the RDN choice for one of this document's co-authors, while Stephen E. Hardcastle-Kille is stored as an alternative commonName value. Sets of initials should not be concatenated into a single "word", but be separated by spaces and/or "." characters. Pragmatic choices will have to be made for other cultures.
Application Entities
The guidelines of X.521 should be followed, in that the application entity should always be named relative to an Organisation or Organisational Unit. The application process will often correspond
to a system or host. In this case, the application entities should be named by Common Names which identify the service (e.g., "FTAM Service"). In cases where there is no useful distinction between application process and application entity, the application process may be omitted (This is often done for DSAs in the current pilot). 4 Multinational 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.
The multi-national as a single entity
ROOT / | \ / | \ C=GB C=FR C=US / | \ / | \ O=MultiNat---->O=MultiNat<----O=MultiNat / | \ / | \ / | \ l=abc ou=def l=fgi
---> means "alias to"
Figure 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. The organisation's entries all exist under a single sub-tree. The organisational structure beneath the organisation entry should reflect the perceived structure of the organisation, and so no recommendations on this matter can be made here. To assist the person querying the directory, alias entries should be created for all countries where the organisation operates.
The multi-national as a loose confederation
Another common model of organisational structure is that where a multi-national consists of a number of national entities, which are in large part independent of both sibling national entities, and of any central entity. In such cases, the model shown in Figure 2 may be a
ROOT / | \ / | \ C=GB C=FR C=US / | \ / | \ O=MultiNat O=MultiNat O=MultiNat / | / | \ | \ / | / | \ | \ L=GB L=FR / | \ L=FR L=US L=GB L=FR L=US
---> means "alias to"
Figure 2: The multi-national as a loose confederation
better choice. Organisational entries exist within each country, and only that country's localities and organisational units appear directly beneath the appropriate organisational entry. Some binding together of the various parts of the organisation can be achieved by the use of aliases for localities and organisational units, and this can be done in a highly flexible fashion. In some cases, the national view might not contain all branches of the company, as illustrated in Figure 2.
Loosely linked DIT sub-trees
A third approach is to avoid aliasing altogether, and to use the looser binding provided by an attribute such as seeAlso. This approach treats all parts of an organisation as essentially separate. A unified view of the organisation can only be achieved by user interfaces choosing to follow the seeAlso links. This is a key difference with aliasing, where decisions to follow links may be specified within the protocol. (Note that it may be better to specify another attribute for this purpose, as seeAlso is likely to be used for a wide variety of purposes.)
Summary of advantages and disadvantages of the above approaches
Providing an internal directory
All the above methods can be used to provide an internal directory. In the first two cases, the linkage to other parts of the organisation can be followed by the protocol and thus
organisation-wide searches can be achieved by single X.500 operations. In the last case, interfaces would have to "know" to follow the soft links indicated by the seeAlso attribute.
Impact on naming
In the single-entity model, all DNs within the organisation will be under one country. It could be argued that this will often result in rather "unnatural" naming. In the loose-confederation model, DNs are more natural, although the need to disambiguate between organisational units and localities on an international, rather than just a national, basis may have some impact on the choice of names. For example, it may be necessary to add in an extra level of organisational unit or locality information. In the loosely-linked model, there is no impact on naming at all.
Views of the organisation
The first method provides a unique view of the organisation. The loose confederacy allows for a variety of views of the organisation. The view from the centre of the organisation may well be that all constituent organisations should be seen as part of the main organisation, whereas other parts of the organisation may only be interested in the organisation's centre and a few of its sibling organisations. The third model gives an equally flexible view of organisational structures.
Lookup performance
All methods should perform reasonably well, providing information is held, or at least replicated, within a single DSA.
5 Miscellany This section draws attention to two areas which frequently provoke questions, and where it is felt that a consistent approach will be useful.
Schema consistency of aliases
According to the letter of the standard, an alias may point at any 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 valid
Relative Distinguished Name of the entry.
2. If the entry (aliased object) were placed where the alias is,
there should be no schema violation.
Organisational Units
There is a problem that many organisations can be either organisations or organisational units, dependent on the location in the DIT (with aliases giving the alternate names). For example, an organisation may be an independent national organisation and also an organisational unit of a parent organisation. To achieve this, it is important to allow an entry to be of both object class organisation and of object class organisational unit. References [1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
X.500 schema. Request for Comments RFC 1274, Department of 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 Comments
RFC 1279, Department of Computer Science, University College London, November 1991.
6 Security Considerations Security issues are not discussed in this memo.
7 Authors' Addresses
Paul Barker Department of Computer Science University College London Gower Street WC1E 6BT England Phone:+44-71-380-7366
EMail: [email protected] Steve Hardcastle-Kille ISODE Consortium P.O. Box 505 London SW11 1DX England
Phone:+44-71-223-4062
EMail: [email protected]