From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1617.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc1617.txt (limited to 'doc/rfc/rfc1617.txt') diff --git a/doc/rfc/rfc1617.txt b/doc/rfc/rfc1617.txt new file mode 100644 index 0000000..ce57779 --- /dev/null +++ b/doc/rfc/rfc1617.txt @@ -0,0 +1,1571 @@ + + + + + + +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. + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 7] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 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 + + 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 under all + countries where the organisation operates. + +2.5.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. + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 8] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + ROOT + + / | \ + / | \ + C=GB C=FR C=US + + / | \ + / | \ + O=MultiNat O=MultiNat O=MultiNat + + / | / | \ | \ + / | / | \ | \ + + L=FR L=GB<---L=GB | L=US--->L=US L=FR + \ | / + ------------------->L=FR<---------------- + + ---> means "alias to" + + Figure 2: The multi-national as a loose confederation + + 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. + +2.5.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 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.) + +2.5.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 + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 9] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 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 either held within a single DSA or it is replicated to the + other DSAs. + +3. Naming Style + + The first goal of naming is to provide unique identifiers for + entries. Once this is achieved, 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 [5] 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. In addition, the X.501 standard notes that + "RDNs are intended to be long-lived so that the users of the + Directory can store the distinguished names of objects..." and "It is + preferable that distinguished names of objects which humans have to + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 10] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + deal with be user-friendly." [2] + + Naming is dependent on a number of factors and these are now + considered in turn. + +3.1 Multi-Component Relative Distinguished Names + + According to the standard, relative distinguished names may have more + than one component selected from the set of the attributes of the + entry to be named. This is useful when there are, for example, two + "John Smiths" in one department. The use of multi-component relative + distinguished names allows one to avoid artificial naming values such + as "John Smith 1" or "John Smith-2". Attributes which could be used + as the additional naming attribute include: personalTitle, + roomNumber, telephoneNumber, and userId. + +3.2 National Guidelines for Naming + + 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 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. + +3.3 Naming 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 that organisations such as + Alcoholics Anonymous and American Airlines 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: + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 11] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 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 RDNs which are either the most memorable or + guessable, although names should be recognisable. The need for users + not to type long names may be achieved by use of carefully selected + alternative values. + +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. + + 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 + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 12] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + will have to be made for other cultures. 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. Section 3.1 on multi-component RDNs + shows how clashing names can be made unique. + + The choice of a naming strategy should not be made on the basis of + the possibilities of the currently available user interface + implementations. For example, it is inappropriate to use common names + of the form 'surname firstname' merely because a user interface + presents results in a more satisfactory order by so doing. Use the + best structure for human names, and fix the user interface! + + More details on the use of commonName in section 4.4.1. + +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. Attribute Values + + In general the attribute values should be used as documented in the + standards. Sometimes the standard is not very precise about which + attribute to use and how to represent a value. + + The following sections give recommendations how to use them in X.500 + pilot projects. + +4.1 Basic Attribute Syntaxes + + Every attribute type has a definition of the attribute syntaxes its + values may be use. Most attribute types make use the basic attribute + syntaxes only. + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 13] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +4.1.1 Printable String + + This most simple syntax uses a subset of characters from ISO 646 IRV. + + A-Z a-z 0-9 ' ( ) + + + , - . / : ? space + + Tab 1: Characters in PrintableString + +4.1.2 IA5 String - T.50 + + The International Alphabet No. 5 (IA5) is known from the X.400 + message handling service. It covers a wider range of characters than + the printable string. The international reference version of IA5 + offers the same set of characters as ISO 646 IRV. + +4.1.3 Teletex String - T.61 + + The Teletex character set is a very unusual one in the computing + environment because it uses mixed one and two octet character codes + which are more difficult to handle than single octet codes. Most of + the characters can be mapped to the more often supported 8-bit + character set standard ISO 8859-1 (ISO Latin-1). + +4.1.4 Case Ignore String + + Many attributes use this case insensitive syntax. It allows attribute + values to be represented using a mixture of upper and lower case + letters, as appropriate. Matching of attribute values, however, is + performed such that no significance is given to case. + +4.1.5 Distinguished Name + + A Distinguished Name should currently never contain a value in T.61 + string syntax because most users would not be able to view or type it + correctly by lack of appropriate hardware/software configuration. + Therefore, only the characters defined in printable string syntax + should be used as part of a RDN. The correct representation of the + name should be added as additional attribute value to match for + search operations. + +4.2 Languages & Transliteration + + The standard as available has no support at all for the use of + different languages in the Directory. It is e.g., not possible to add + a language qualifier to a description attribute nor is it possible to + use characters beyond the Teletex character set. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 14] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +4.2.1 Languages other than English + + Many countries have more than one national language and a world-wide + Directory must be able to support non-English-speaking users. + + Until the standard provides a solution for this problem it is + possible to make use of multi-valued attributes to specify a value + not only in the local languages but also in English. + + In particular the friendlyCountryName, stateOrProvinceName and + localityName attributes should use the most often used translations + of its original value to increase the chance for successful searches + also for users with a foreign language. Other attributes like + description, organizationName and organizationalUnitName attributes + should provide multi-lingual values where appropriate. + + The drawback of this solution is, that the user interfaces present + much redundant information because they are not able to know the + language of the values and make an automatic selection. + + Note: The sequence of multi-valued attribute values in an entry + cannot be defined. It is always up to the DSA to decide on + which order to store them and return them as results, and + to the DUA to decide on which order to display them. + +4.2.2 Transliteration + + What measures can be taken to make sure all users are able to read an + attribute, when a value uses one of the special characters from the + T.61 character set? An interim solution is transliteration as used in + earlier days with the typewriters, where e.g., the German 'a' with + umlaut is written as 'ae'. Transliteration is not necessarily unique + since it is dependent on the language, English speakers transliterate + the 'a' with umlaut just to an 'a'. However, it is an improvement + over just using the T.61 value since it may not be possible to + display such a value at all. Whenever an attribute needs a character + not in PrintableString and the attribute syntax allows the use of the + T.61 character set, it is recommended that the attribute should be + supplied as multi-valued attribute both in T.61 string and in a + transliterated PrintableString notation. + +4.3 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 + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 15] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 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. + +4.4 Selected Attributes + + The section lists attributes together with a short description what + they should be used for and some examples. [6] The source of the + attributes is given in brackets. + + Note that due to national legal restrictions on privacy issues it + might be forbidden to use certain attributes or that the search on + them is restricted. [7] + +4.4.1 Personal Attributes + + commonName [X.520] + + 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. + + The choice of a name depends on the culture as discussed in + section 3.4. When a commonName is selected as (part of) a RDN the + most often used form of the name should be selected. A firstname + should never be supplied only as an initial (unless, of course, + the source data does not include forenames). It is very important + to have its full value in order to be able to distinguish between + two similar entries. Sets of initials should not be concatenated + into a single "word", but be separated by spaces and/or "." + characters. + + + Format: Firstname [Initials] Lastname + + Example: Steve Kille + + Stephen E. Kille + + S.E. Kille + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 16] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + The use of 'Lastname Firstname' is deprecated as explained in + section 3.4. + + favouriteDrink [RFC 1274] + + The intention of this attribute is that it provides at least one + benign attribute which any user can create or modify, given a + suitable user interface, without having the unfortunate impact on + the directory service that follows from modifying an attribute + such as an e-mail address or telephone number. + + Example: Pure Crystal Water + + organizationalStatus [RFC 1274] + + The Organisational Status attribute type specifies a category by + which a person is often referred to in an organisation. Examples + of usage in academia might include undergraduate student, + researcher, lecturer, etc. + + A Directory administrator should consider carefully the + distinctions between this and the title and description + attributes. + + Example: undergraduate student + + personalTitle [RFC 1274] + + The usually used titles, especially academic ones. Excessive use + should be avoided. + + Example: Prof. Dr. + + roomNumber [RFC 1274] + + The room where the person works, it will mostly be locally defined + how to write the room number, e.g., Building Floor Room. + + Example: HLW B12 + + secretary [RFC 1274] + + The secretary of the person. This is the Distinguished Name (DN) + of the secretary. + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 17] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + surname [X.520] + + Like with commonName it is a matter of culture what to use for + surname in case of a noble name, e.g., de Stefani, von Gunten. + + Example: Kille + + title [X.520] + + Title describing the position, job title or function of an + organisational person. + + Example: Manager - International Sales + + userId [RFC 1274] + + When an organisation has centrally managed user ids, it might make + sense to include it into the entry. It might also be used to form + a unique RDN for the person. + + Example: skille + + userPassword [X.520] + + The password of the entry which allows the modification of the + entry, provided that the access control permits it. The password + should not be the same as any system password, unless it is sure + that nobody can read it. With the current implementations this is + mostly not guaranteed. + + Example: 8kiu8z7e + +4.4.2 Organisational Attributes + + associatedDomain [RFC 1274] + + The Internet domain name for an organisation or one of its units. + + Example: isode.com + + businessCategory [X.520] + + Type of business an organisation, an organisational unit or + organisational person is involved in. The values could be chosen + from a thesaurus. + + Example: Software Development + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 18] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + organizationName [X.520] + + The name of the organisation. The value for the RDN should be + chosen according to section 3.3. Additional names like + abbreviations should be used for better search results. + + Example: Uni Lausanne + Universite de Lausanne + Universit\c2e Lausanne (with a T.61 encoded umlaut) + University of Lausanne + unil + + organizationalUnitName [X.520] + + The name of a part of the organisation. The value for the RDN + should be chosen according to section 3.3. Additional names like + abbreviations should be provided for better search results. + + Example: Institut fuer Angewandte Mathematik + Mathematik + iam + + roleOccupant [X.520] + + The person(s) in that role. This is the Distinguished Name of the + entry of the person(s). + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + + searchGuide [X.520] + + The currently available DUAs make no use this attribute. It seems + that it is not powerful enough for real usage. Experience is + needed before being able to give recommendations on how to + configure it. + +4.4.3 Local Attributes + + localityName [X.520] + + Name of the place, village or town with values in local and other + languages as useful. + + Example: Bale + B\c3ale (with a T.61 encoded accented character) Basel + Basilea + Basle + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 19] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + stateOrProvinceName [X.520] + + Name of the canton, county, department, province or state with + values in local and other languages as useful. If official and + commonly used abbreviations exist for the states, they should be + supplied as additional values + + Example: Ticino + Tessin + TI + +4.4.4 Miscellaneous Attributes + + audio [RFC 1274] + + The audio attribute uses a u-law encoded sound file as used by the + "play" utility on a Sun 4. According to RFC 1274 it is an interim + format. It may be useful to listen to the pronunciation of a name + which is otherwise unknown. + + description [X.520] + + A short informal explanation of special interests of a person or + organisation. Overlap with businessCategory, organizationalStatus + and title should be avoided. + + Example: Networking, distributed systems, OSI, implementation. + + friendlyCountryName [RFC 1274] + + The friendlyCountryName attribute type specifies names of + countries in human readable format. Especially the country name as + used in the major languages should be included as additional + values to help foreign users. + + jpegPhoto [RFC 1488] [8] + + A colour or grayscale picture encoded according to JPEG File + Interchange Format (JFIF). Thanks to compression the size of the + pictures is moderate. For persons it may show a portrait, for + organisations the company logo or a map on how to get there. + + photo [RFC 1274] + + The photo attribute is a b/w G3 fax encoded picture of an object. + The size of the photo should be in a sensible relation to the + informational value of it. This attribute will be replaced by + jpegPhoto. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 20] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + seeAlso [X.520] + + Reference to another closely related entry in the DIT, e.g., from + a room to the person using that room. It is the Distinguished Name + of the entry. + + Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB + +4.4.5 MHS Attributes + + mhsORAddresses [X.411] + + The attribute uses internally an ASN.1 structure. The string + notation used for display purposes is implementation dependent. + This attribute is especially useful for an integrated X.400 user + agent since it gets the address in a directly usable format. + + rfc822mailbox [RFC 1274] + + E-Mail address in RFC 822 notation + + Example: s.kille@isode.com + + textEncodedORAddress [RFC 1274] + + X.400 e-mail address in string notation. The F.401 notation should + be used. This attribute shall disappear once the majority of the + DUAs support the mhsORAddresses attribute. The advantage of the + latter attribute is, that a configurable DUA could adjust the + syntax to the one needed by the local mailer, where + textencodedORAddress is just a string which will mostly have a + different syntax than the mailer expects. + + Example: G=thomas; S=lenggenhager; OU1=gate; O=switch; \ + P=switch; A=arcom; C=ch; + +4.4.6 Postal Attributes + + postalAddress [X.520] + + The full postal address (but not including the name) in + international notation, with up to 6 lines with 30 characters + each. + + Example: SWITCH + Limmatquai 13 + CH-8001 Zurich + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 21] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + postalCode [X.520] + + The postalCode will be the same as used in the postalAddress (in + international notation). + + Example: CH-8001 + + streetAddress [X.520] + + It shall be the street where the person has its office. Mostly, it + will be the street part of the postalAddress. + + Example: Limmatquai 138 + +4.4.7 Telecom Attributes + + telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520] + + The phone number in the international notation according to CCITT + E.123. The separator '-' instead of space may be used according to + the local habit, it should be used consistently within a country. + + Format: "+" ["x" ] + Example: +41 1 268 1540 + + telexNumber [X.520] + + The telex number in the international notation + + Example: 817379, ch, ehhg + +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. + +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 use an + attribute type normally used for naming entries of the + object class of the main entry. + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 22] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + 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. + +6. References + + [1] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet + X.500 schema", RFC 1274, Department of Computer Science, + University College London, November 1991. + + [2] "The Directory --- Overview of concepts, models and services", + CCITT X.500 Series Recommendations, December 1988. + + [3] The North American Directory Forum. "A Naming Scheme for C=US", + RFC 1255, NADF-175, NADF, September 1991. + + [4] Michaelson, G., and M. Prior, "Naming Guidelines for the AARNet + X.500 Directory Service", RFC 1562, AEN-001, The University of + Queensland, The University of Adelaide, December 1993. + + [5] Hardcastle-Kille, S., "Using the OSI Directory to achieve user + friendly naming", RFC 1484, Department of Computer Science, + University College London, July 1993. + + [6] Barker, P., "Preparing data for inclusion in an X.500 Directory", + Research Note RN/92/41, Department of Computer Science, + University College London, May 1992. + + [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy + Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993. + + [8] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The X.500 + String Representation of Standard Attribute Syntaxes", RFC 1488, + University of Michigan, ISODE Consortium, Performance Systems + International, NeXor Ltd., July 1993. + +7. Security Considerations + + Security issues are not substantially discussed in this memo. + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 23] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +8. Authors' Addresses + + Paul Barker + Department of Computer Science + University College London + Gower Street + London WC1E 6BT + England + + Phone: +44 71 380 7366 + EMail: p.barker@cs.ucl.ac.uk + + DN: CN=Paul Barker, OU=Computer Science, O=University College + London, C=GB + + UFN: Paul Barker, Computer Science, UCL, GB + + + Steve Kille + ISODE Consortium + The Dome + The Square + Richmond TW9 1DT + England + + Phone: +44 81 332 9091 + EMail: s.kille@isode.com + + DN: CN=Steve Kille, O=ISODE Consortium, C=GB + + UFN: S. Kille, ISODE Consortium, GB + + + Thomas Lenggenhager + SWITCH + Limmatquai 138 + CH-8001 Zurich + Switzerland + + Phone: +41 1 268 1540 + EMail: lenggenhager@switch.ch + + DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH + + UFN: Thomas Lenggenhager, SWITCH, CH + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 24] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9. Appendix - Example Entries + +9.1 Country + + DN: C=CH + + objectClass=top & country & domainRelatedObject & friendlyCountry + country=CH + associatedDomain=ch + friendlyCountryName=CH + friendlyCountryName=Confoederatio Helvetica + friendlyCountryName=Schweiz + friendlyCountryName=Suisse + friendlyCountryName=Svizzera + friendlyCountryName=Switzerland + +9.2 Organisation + + DN: O=SWITCH, C=CH + + objectClass=top & organization & mhsUser & domainRelatedObject + description=Swiss Academic and Research Network + organizationName=SWIss TeleCommunication system for Higher + education\and research + organizationName=Swiss Academic and Research Network + organizationName=SWITCH + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=ZH + stateOrProvinceName=Zuerich + stateOrProvinceName=Zurich + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1515 + facsimileTelephoneNumber=+41 1 268 1568 + seeAlso=CN=Postmaster, O=SWITCH, C=CH + mhsORAddresses=S=postmaster, O=switch; P=switch; A=arcom; C=ch; + associatedDomain=switch.ch + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 25] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9.3 Organisation Unit + + DN: OU=SWITCHdirectory, O=SWITCH, C=CH + + objectClass=top & organizationalUnit + description=The SWITCH X.500 pilot project + organizationalUnitName=SWITCHdirectory + localityName=Zurich + localityName=Zuerich + localityName={T.61}Z\c8urich + stateOrProvinceName=Zurich + stateOrProvinceName=Zuerich + stateOrProvinceName=ZH + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCHdirectory + SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + +9.4 Organizational Role + + DN: CN=Directory Manager, O=SWITCH, C=CH + + objectClass=top & organizationalRole & mhsUser + commonName=Directory Manager + description=SWITCH Directory Managers + roleOccupant=CN=Martin Berli, O=SWITCH, C=CH + roleOccupant=CN=Thomas Lenggenhager, O=SWITCH, C=CH + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=Zurich + stateOrProvinceName=Zuerich + stateOrProvinceName=ZH + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCHdirectory + SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=switchinfo; O=switch; P=switch; A=arcom; C=ch; + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 26] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + + DN: CN=Postmaster, O=SWITCH, C=CH + + objectClass=top & organizationalRole & mhsUser + commonName=Postmaster + commonName=Helpdesk + roleOccupant=CN=Christoph Graf, O=SWITCH, C=CH + roleOccupant=CN=Felix Kugler, O=SWITCH, C=CH + roleOccupant=CN=Marcel Parodi, O=SWITCH, C=CH + roleOccupant=CN=Marcel Schneider, O=SWITCH, C=CH + telephoneNumber=+41 1 268 1520 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=postmaster; O=switch; P=switch; A=arcom; C=ch; + + DN: CN=Secretary, O=SWITCH, C=CH + + objectClass=top & organizationalRole & quipuObject + commonName=Secretary + roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 27] + +RFC 1617 Naming and Structuring Guidelines for X.500 May 1994 + + +9.5 Person + + DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH + + objectClass=top & person & organizationalPerson & mhsUser & + pilotObject & newPilotPerson + commonName=Thomas Lenggenhager + commonName=T. Lenggenhager + surname=Lenggenhager + description=SWITCHinfo, Project Leader + localityName=Zuerich + localityName=Zurich + localityName={T.61}Z\c8urich + stateOrProvinceName=ZH + stateOrProvinceName=Zuerich + stateOrProvinceName=Zurich + stateOrProvinceName={T.61}Z\c8urich + postalAddress=SWITCH + Limmatquai 138 + CH-8001 Zurich + postalCode=CH-8001 + streetAddress=Limmatquai 138 + telephoneNumber=+41 1 268 1540 + facsimileTelephoneNumber=+41 1 268 1568 + mhsORAddresses=S=lenggenhager; O=switch; P=switch; A=arcom; C=ch; + userPassword=secret + textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \ + A=arcom; C=ch; + rfc822mailbox=lenggenhager@switch.ch + secretary=CN=Franziska Remund, O=SWITCH, C=CH + + + + + + + + + + + + + + + + + + + + + +RARE Working Group on Network Applications Support (WG-NAP) [Page 28] + -- cgit v1.2.3