Network Working Group P. Barker and S.E. Kille INTERNET--DRAFT University College London February 1991 Naming Guidelines for Directory Pilots Status of this Memo Deployment of a Directory will benefit from following certain guidelines. This document defines a number of guidelines which are recommended. Conformance to these guidelines will be recommended for national pilots. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to the authors or to the discussion group . INTERNET--DRAFT Naming Guidelines February 1991 1 Introduction As a pre-requisite to this document, it is assumed that pilots are following the technical guidelines of the documents laid out in [Kil90a]. In particular the COSINE and Internet X.500 Schema should be followed [BK91]. 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 two other key issues. 2.1 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. Top level domain components The DNS top levels as defined in [Kil89]. International Organisations International organisations, such as the United Nations which does not belong to any specific country, will be registered at the top level. This will not be done for multi-national organisations, which are organisations which have a presence in more than one country. The international organisations registered so far are: Internet, COSINE. DSA Information Some information on DSAs may be needed at the top level. This should be kept to a minimum (See also the draft on DSA Naming). 2.2 The DNS within the DIT The rules for the DNS parts of the DIT are defined in [Kil89]. Barker and Kille Page 1 INTERNET--DRAFT Naming Guidelines February 1991 3 Naming Style It is the standpoint of this INTERNET--DRAFT that the primary motivation when 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 [Kil90b]. 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. 3.1 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 [Kil89]. 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. 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. Barker and Kille Page 2 INTERNET--DRAFT Naming Guidelines February 1991 3.2 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 [Kil90b]. 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 oreinted approach. There are two principal 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 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. Barker and Kille Page 3 INTERNET--DRAFT Naming Guidelines February 1991 3.3 Organisation and Organisational Unit Names An organisation's RDN should usually be the name by which the organisation is most commonly named. This will usually be the name in full, rather than just a set of initials. This means that University College London should be preferred over UCL, or that International Business Machines should be preferred over IBM. 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. In the end, the choice will be that of the naming authority. However, these guideline should be followed wherever possible. The same arguments 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. 3.4 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, generational qualifiers and letters Barker and Kille Page 4 INTERNET--DRAFT Naming Guidelines February 1991 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 naming Architecture, and another attribute could be specified for information about qualifications. 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 Kille is preferred as the RDN choice for one of this document's co-authors, while Stephen E. Kille is stored as an alternative commonName value. Pragmatic choices will have to be made for other cultures. 3.5 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 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 Barker and Kille Page 5 INTERNET--DRAFT Naming Guidelines February 1991 each of these approaches. Before considering the approaches, it is worth bearing 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. 4.1 The multi-national as a single entity # ROOT i ii ii i i"! X XX X XX XX XXz _________ii)_ ___________|? ___________ | C=GB | | C=FR | ||_________||C=US |___________| |______B___| | ||? _____BBN__ __|?________ ____________________|_____|___-| ___o_____e||O=MultiNa|t O=MultiNat O=MultiNat |___________| |_____|_@@_| |___________| AE | @ @ Locality and________-________||_|?___||_@R___||/orou=defl=abc Organisation Unit ent|_______||______||______|l=fgiries _ _______ ____-= 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. 4.2 The multi-national as a loose confederation Barker and Kille Page 6 INTERNET--DRAFT Naming Guidelines February 1991 # ii ROOT XX X ii i ii i "! XX XX X XX Xz ______ii)___ ___________|? ___________ | C=GB | | C=FR | | C=US | |___________| |_____|____ | |___@@_____| __|?______ _____@R_____ ____________|| | | |O=MultiNat | O=MultiNat O=MultiNat |____B______| |___B_____| |_______AA__| BB BB AA ____ff__ ____BBN_ BB __fl______AU____ |L=GB ||L=FR | B |L=FR ||L=US | |___HY__ ||__XX__ | BB |__ii___|_______|| H HH XX XX X B ii ii * HH HH ___Xff_XX__XXzffii)liiBBN__ HH HH||______||||____||_||___||L=GBL=FRL=US _ _______ ____-= alias to Figure 2: 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 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. 4.3 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 Barker and Kille Page 7 INTERNET--DRAFT Naming Guidelines February 1991 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.) 4.4 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, all 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. Barker and Kille Page 8 INTERNET--DRAFT Naming Guidelines February 1991 5.1 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. 5.2 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 [BK91] P. Barker and S.E. Kille. The COSINE and Internet X.500 schema, March 1991. Internet Draft: draft-ietf-osids-cosinex500-02.txt. [Kil89] S.E. Kille. X.500 and domains. Research Note RN/89/47, Department of Computer Science, University College London, May 1989. Also Internet Draft: draft-ucl-kille-x500domains-02.ps. [Kil90a] S.E. Kille. Building and internet directory using X.500, November 1990. Internet Draft: draft-ietf-osix500-directories-01.txt. [Kil90b] S.E. Kille. Using the OSI directory to achieve user friendly naming. Research Note RN/90/29, Department of Computer Science, University College London, February 1990. 6 Security Considerations Security considerations are not discussed in this INTERNET--DRAFT . Barker and Kille Page 9 INTERNET--DRAFT Naming Guidelines February 1991 7 Author's Addresses Paul Barker and Steve Kille Department of Computer Science University College London Gower Street WC1E 6BT England Phone:+44-71-380-7366 (Barker) Phone:+44-71-380-7294 (Kille) EMail: P.Barker@CS.UCL.AC.UK EMail: S.Kille@CS.UCL.AC.UK Barker and Kille Page 10