RFC 1617
Naming and Structuring Guidelines for X.500 Directory Pilots
Naming and Structuring Guidelines for X.500 Directory Pilots 🎀
okay bestie, so this is RFC 1617 🦋 and it's marked Informational, which means it's guidance and not a standard, no cap. It came out in May 1994 and was written by P. Barker from University College London, S. Kille from the ISODE Consortium, and T. Lenggenhager from SWITCH. It's also RARE Technical Report: 11 💅 and it obsoletes RFC 1384, so this is the glow-up that replaces the older version ✨. The title block doesn't list anything else it updates.
Status of this Memo 📝
This memo provides information for the Internet community. It does not specify an Internet standard of any kind, and 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
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 251. Introduction 💖
okay so the people this is mainly for are data managers who work with X.500 Directory Services 🧚. With these guidelines it should be easier for them to figure out the structure of the part of the Directory Information Tree they want to model, like how their organisation shows up in the Directory. Decisions about which data elements to store for each kind of entry shall be supported too 🍓.
These guidelines are mostly about the White Pages use of the Directory, which is the X.500 application with the most operational experience right now. Still, lots of the recommendations also work for other Directory applications 🌈.
As a prerequisite, it is assumed that the COSINE and Internet X.500 Schema is followed [1] 📚.
2. DIT Structure 🌸
Most of this document is about DIT structure, naming, and how to use attributes for organisations, organisational units, and personal entries 🦋.
This section quickly covers 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 💅. A few simple restrictions should also be applied, as described below. For other uses of the Directory, like e-mail routing with the Directory or storing network information in it, you'll need to follow the guidelines in the respective documents 📬.
One of the few exceptions to the basic DIT structure is that international organisations are 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 goes like this: when a subtree is mainly accessed via searching, it should be as flat as possible to improve performance. When 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. The entries should also 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. These might be considered supra-national, and that, honestly, is the raison-d'etre of such organisations 👑. Almost all of them will 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 includes the big commercial organisations whose production and sales are spread across 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: Inmarsat, Internet and North Atlantic Treaty Organization 🛰️.
Localities
A few localities will be registered under the root. The main purpose of these locality entries is to give a "natural" parent node to organisations that are supra-national but don't 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 with a recognised top level registration authority is countries. Registering 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, anyone making use of such a registration should note this potential problem 🙈.
2.3 Countries
The national standardisation bodies will define national guidelines for the structure of the national part of the DIT. In the meantime, the following simple structure should suffice 🌷. The country entry will appear immediately beneath the root of the tree. Organisations with national significance should have entries immediately beneath their respective country entries. Smaller organisations that are only known in a particular locality should be placed underneath locality entries representing states or similar geographical divisions. Entries for private persons will be listed under the locality entries 🏡. An example plan evolving for the US is the work of 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 disambiguate 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 a lot over time, the aim should be to minimise the number of changes to the DIT 😭. Note that renaming a superior department entry changes the DN of all subordinate entries. This has an undesirable impact on the service for several reasons. Alias entries, and certain attributes of 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
Just like 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 🔥. Secretary entries for an organisation and its units should also 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=Secretaryshould be added as additional values whenever a language other than English is used for the name of the entries 🌈.
2.4.2 Depth of tree 🌸
okay bestie, the big vibe for White Pages is that the DIT should be as flat as possible 🫶 a flat tree means Directory names stay relatively short and kinda similar in length and component structure to paper mail addresses 💌 a deep DIT means long names with somewhat arbitrary bits, which seems less natural (and honestly, yeah 💀). Any artificiality in the choice of names militates against successful querying, so no fake-feeling names pls 🙈
The presumption behind this style of naming is that most querying gets done when the user types convenient strings of characters that get mapped onto powerful search operations ✨ The alternative is users browsing their way down the tree and picking names from big piles of possibilities. That may be more appropriate in some cases, and a deeper tree makes it easier 🧚 BUT these guidelines recommend a shallow tree, and implicitly a search-oriented approach, so we're team search 🔍
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 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. Still, it's important that the various pilots are cognisant of what those structures are likely to be, and move early to adopt them 💅
The other main determinant is whether an organisation splits its entries over a number of organisational units, and if so, how many levels. The recommendation here is that this sub-division 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's 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 using a personalTitle or userId attribute in the RDN 🎀
2.4.3 Real World Organisational Structure 🦋
Another aspect of 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 the 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. That makes it more awkward to use X.500 within a multi-national to provide an internal organisational directory, since the data is spread widely throughout the DIT instead of 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 is made here to precisely define "multinational organisation." 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. That suggests a variety of DIT structures may be appropriate to accommodate these different structures. This document suggests three approaches, and notes some of the characteristics associated with each 🧩
Before considering the approaches, it's worth bearing in mind again that a major aim in choosing 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, it's strongly controlled from the centre, and the disparate parts exist only as limbs of the main organisation. In a situation like that, the model shown in figure 1 may be the best choice 💜
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
All of the organisation's entries exist under a single sub-tree. The organisational structure beneath the organisation entry should reflect the perceived structure of the organisation, so no recommendations on that matter can be made here. To help 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 is one 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 🌸
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 using 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 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 from 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, so 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 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 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 centre and a few of their 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 replicated to the other DSAs 🚀
3. Naming Style 💖
The first goal of naming is to provide unique identifiers for entries. Once that's achieved, the next major goal should be to facilitate querying of the Directory. In particular, support for a naming structure that 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 they have 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, since 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 deal with be user-friendly." [2]
Naming depends 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 🙈 Using multi-component relative distinguished names means you can avoid artificial naming values like "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 🌍
Okay so, if you're naming stuff in a country that already has naming guidelines, these guidelines should in general be followed 💅 Those guidelines might be based on an established registration authority, or they might use an existing registration mechanism (e.g., company name registration). Super practical, no cap.
Also, if an organisation's name is already nationally registered in an existing registry, that name is likely to be a good fit for the Directory 🎀 This still applies even when there aren't any national guidelines. Main character energy for registered names ✨
3.3 Naming Organisation and Organisational Unit Names 🏢
The naming of organisations in the Directory will eventually be run by official naming authorities 👑 Until then, it is recommended that pilots and organisations follow these guidelines. An organisation's RDN should usually be the full name of the organisation, not just a set of initials. So University College London should be preferred over UCL 🎓
Here's why short names can get messy 🙈 Someone proposed registering AA for the Automobile Association. At first glance that seems fine, because the Automobile Association is well known by that acronym. But zoom out a bit and it's less reasonable, since Alcoholics Anonymous and American Airlines use the same acronym too. Iconic plot twist, honestly.
Just like initials should usually be avoided for organisational RDNs, so should formal names that only exist on official charters and aren't generally well known. There are two reasons for this:
- The names should be meaningful.
- 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 naming style logic applies even harder to organisational unit RDNs 🫶 Abbreviations are everyday language inside an organisation, but they almost always mean nothing outside of it. Lots of people in academic computing habitually think of CS as Computer Science, but CS could be read several different ways. It could just as easily mean Computing Services, Cognitive Science, Clinical Science or even Counselling Services. Yikes 💀
For both organisations and organisational units, extra naming info should be stored in the directory as alternative values of the naming attribute. So 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 for any of the other departments mentioned earlier. Entries will generally be found by searching, so it's not essential for RDNs to be the most memorable or guessable, although names should still be recognisable 🦋 Users don't have to type long names when you pick good alternative values.
3.4 Naming Human Users 🧑💻
Being pretty consistent about how we name people is super important, because a huge percentage of directory usage is looking up info about people 👀 User interfaces can help people way more when entries have names that follow a common format, or a 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 info. It makes sense to make sure the RDN commonName value is genuinely the most common name for a person, because user interfaces may give more weight to matches on the RDN than on matches on one of the alternative names 💜
The choice of RDN for humans will be shaped by culture 🌏 In many countries the best choice will look like familiar-first-name surname. So 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. Other cultures need pragmatic choices. The common name attribute should not be used to hold other attribute information such as telephone numbers, room numbers, or local codes. That info belongs in the appropriate attributes defined in the COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs shows how clashing names can be made unique 🔥
Don't pick a naming strategy just because of what the current user interface implementations can do 😤 For example, it is inappropriate to use common names of the form 'surname firstname' just because a user interface shows results in a nicer order that way. 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, which means the application entity should always be named relative to an Organisation or Organisational Unit. The application process will often match up with a system or host. In that case, the application entities should be named by Common Names that identify the service (e.g., "FTAM Service") ✨ Where there's no useful difference between application process and application entity, the application process may be left out. (This is often done for DSAs in the current pilot.)
4. Attribute Values 🎀
Generally, attribute values should be used the way the standards document them 📖 Sometimes the standard isn't very precise about which attribute to use or how to represent a value, which is a lot honestly 🙃
The following sections give recommendations on 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 use. Most attribute types only use the basic attribute syntaxes 💖
4.1.1 Printable String
This simplest syntax uses a subset of characters from ISO 646 IRV ✨ Here's the list:
A-Z a-z 0-9 ' ( ) +
, - . / : ? space
Tab 1: Characters in PrintableString4.1.2 IA5 String - T.50
The International Alphabet No. 5 (IA5) comes 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 kind of unusual for computing 😭 It uses mixed one and two octet character codes, which are harder to handle than single octet codes. Most of its characters can be mapped to the more widely supported 8-bit character set standard ISO 8859-1 (ISO Latin-1).
4.1.4 Case Ignore String
Lots of attributes use this case insensitive syntax 🌈 It lets attribute values use a mix of upper and lower case letters, as appropriate. When attribute values are matched, though, case is given no significance.
4.1.5 Distinguished Name
A Distinguished Name should currently never contain a value in T.61 string syntax, because most users wouldn't be able to view or type it correctly thanks to a lack of appropriate hardware or software configuration 💀 So only the characters defined in printable string syntax should be used as part of an RDN. The correct representation of the name should be added as an additional attribute value to match for search operations 🔍
4.2 Languages & Transliteration 🌐
The standard as available has zero support for using different languages in the Directory 😤 For example, you can't add a language qualifier to a description attribute, and you can't use characters beyond the Teletex character set either.
4.2.1 Languages other than English
Many countries have more than one national language, and a world-wide Directory has to support non-English-speaking users 🌍
Until the standard solves this, you can use multi-valued attributes to give 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 their original value, to increase the chance that searches succeed for users who speak a foreign language. Other attributes like description, organizationName and organizationalUnitName should provide multi-lingual values where appropriate.
The drawback is that user interfaces end up showing a lot of redundant info, because they can't know the language of each value and pick one automatically 🙈
Note: The sequence of multi-valued attribute values in an entry cannot be defined. It is always up to the DSA to decide the order to store and return them as results, and up to the DUA to decide the order to display them.
4.2.2 Transliteration 🔤
So what can we do to make sure everyone can read an attribute when a value uses one of the special characters from the T.61 character set? An interim fix is transliteration, which was used back in the typewriter days, where e.g., the German 'a' with umlaut is written as 'ae'. Transliteration isn't necessarily unique, since it depends on the language. English speakers transliterate the 'a' with umlaut just to an 'a'. Still, it's better than only using the T.61 value, since it may not be possible to display that value at all 🦋 Whenever an attribute needs a character that isn't in PrintableString and the attribute syntax allows the T.61 character set, it is recommended that the attribute be supplied as a 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 super significant and may be considered to be "structural". If you can't access these attributes, querying the Directory will often fail 😭 For example, user interfaces usually narrow their searches by looking for entries of a particular type, and the type of entry is shown by its object class. So unless the goal 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 📝
This section lists attributes along with a short description of what they should be used for, plus some examples. [6] The source of each attribute is given in brackets.
Note that due to national legal restrictions on privacy issues, it might be forbidden to use certain attributes, or the search on them might be restricted. [7]
4.4.1 Personal Attributes ✨
commonName [X.520] 🦋
okay so the pilots are basically saying: please ignore the standard's suggestions about putting personal titles and academic or professional letters inside commonName, because that overloads the attribute. There's already a personalTitle attribute in the COSINE and Internet Schema, and another attribute could be made for qualifications. very organised, very iconic 💅
The choice of a name depends on the culture (see section 3.4). When a commonName is selected as (part of) an RDN, the most often used form of the name should be selected. A firstname should never be supplied only as an initial, unless the source data doesn't include forenames, obvs 🙈. Having the full value is super important so you can tell two similar entries apart. Sets of initials shouldn't get mashed into one "word"; they should be separated by spaces and/or "." characters. ✨
Format: Firstname [Initials] Lastname
Example: Steve Kille
Stephen E. Kille
S.E. KilleThe use of 'Lastname Firstname' is deprecated, as explained in section 3.4. 💀
favouriteDrink [RFC 1274] 🍓
The vibe here is that it's a benign attribute any user can create or modify (given a suitable user interface) without messing up the directory service the way changing an e-mail address or telephone number would. Main character energy for low-stakes data 🧚
Example: Pure Crystal Water
organizationalStatus [RFC 1274] 🎀
This one is the category a person is often referred to by in an organisation. In academia, that might be things like undergraduate student, researcher, lecturer, etc. 🎓
A Directory administrator should consider carefully the distinctions between this and the title and description attributes. Be careful, bestie 👀
Example: undergraduate student
personalTitle [RFC 1274] 👑
The usually used titles, especially academic ones. Excessive use should be avoided, so don't go overboard 💅
Example: Prof. Dr.
roomNumber [RFC 1274] 🌸
The room where the person works. How to write the room number will mostly be defined locally, 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
surname [X.520] 🦋
Same as with commonName, it's a matter of culture what to use for surname in the case of a noble name, e.g., de Stefani, von Gunten. The culture really decides here 🌍
Example: Kille
title [X.520] 💼
The title describes 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 them in the entry. It might also be used to form a unique RDN for the person. Lowkey useful 🙌
Example: skille
userPassword [X.520] 🔐
The password of the entry, which allows 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. Bestie, this is a serious one, don't reuse your system password! 😭
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] 🏪
This is the type of business an organisation, an organisational unit or an organisational person is involved in. The values could be chosen from a thesaurus. 📚
Example: Software Development
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
unilorganizationalUnitName [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
iamroleOccupant [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 of this attribute. It seems that it isn't powerful enough for real usage. Experience is needed before anyone can give recommendations on how to configure it. Not the moment, ngl 💀
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
BaslestateOrProvinceName [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
TI4.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. Pronunciation check, bestie 🗣️
description [X.520] 📝
A short, informal explanation of the 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. Be inclusive, babe 🫶
jpegPhoto [RFC 1488] [8] 📸
A colour or grayscale picture encoded according to the 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. Pics or it didn't happen 📷
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. RIP photo, we love jpegPhoto now 🥲
seeAlso [X.520] 🔗
A 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] 💌
This attribute uses an ASN.1 structure internally. The string notation used for display purposes is implementation dependent. It's especially useful for an integrated X.400 user agent, since it gets the address in a directly usable format. Very efficient, very slay ⚡
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, whereas textencodedORAddress is just a string which will mostly have a different syntax than the mailer expects. Okay, so it's on its way out, but it's been a whole era 🥀
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 of 30 characters each.
Example: SWITCH
Limmatquai 13
CH-8001 ZurichpostalCode [X.520] 🗳️
The postalCode will be the same as used in the postalAddress (in international notation).
Example: CH-8001
streetAddress [X.520] 🛣️
This shall be the street where the person has their 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 international notation according to CCITT E.123. The separator '-' instead of a space may be used according to local habit, but it should be used consistently within a country. 📱
Format: "+" <country code> <national number> ["x" <extension>]
Example: +41 1 268 1540telexNumber [X.520] 📠
The telex number in international notation.
Example: 817379, ch, ehhg
5. Miscellany 🎀
This section draws attention to two areas that frequently provoke questions, where a consistent approach is felt to 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:
- 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.
- If the entry (aliased object) were placed where the alias is, there should be no schema violation.
5.2 Organisational Units 🏢
There's a problem where many organisations can be either organisations or organisational units, depending 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. Double life unlocked 👑🦋
6. References 📚✨
Okay bestie, here's the reading list 🤓 Every single source the spec leans on, with all the details, so you can go find them yourself if you're curious 🔍
[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 🔐
Okay, this one is short but IMPORTANT, so read it twice 😭 Security issues are not substantially discussed in this memo. So no, this document isn't your security guide 🙈 Plan accordingly, babe 💅
8. Authors' Addresses 💌
Here's who wrote it, with their contact details and their DN and UFN, all kept exactly as printed 🎀
Paul Barker 🌸
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, GBSteve Kille 🦋
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, GBThomas Lenggenhager 🧚
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, CH9. Appendix - Example Entries 🍓
Okay this is the fun part, the real-life examples 🤩 Every entry is copied exactly, weird backslashes and all, so you can see how these things actually look in a directory 👑
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=Switzerland9.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.ch9.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 15689.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;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=CH9.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=CHThat's the whole thing, bestie! 🌈✨ You made it through the entire RFC 1617 glow-up 💅👑
📦 where this page comes from
- ietf: rfc1617 1994-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms