7 Network Working Group P. Barker
8 Request for Comments: 1617 University College London
9 RARE Technical Report: 11 S. Kille
10 Obsoletes: 1384 ISODE Consortium
11 Category: Informational T. Lenggenhager
16 Naming and Structuring Guidelines for X.500 Directory Pilots
20 This memo provides information for the Internet community. This memo
21 does not specify an Internet standard of any kind. Distribution of
22 this memo is unlimited.
26 Deployment of a Directory will benefit from following certain
27 guidelines. This document defines a number of naming and structuring
28 guidelines focused on White Pages usage. Alignment to these
29 guidelines is recommended for directory pilots. The final version of
30 this document will replace RFC 1384.
36 2.1. Structure Rules 3
37 2.2. The Top Level of the DIT 3
40 2.4.1. Directory Manager, Postmaster & Secretary 5
41 2.4.2. Depth of tree 6
42 2.4.3. Real World Organisational Structure 7
43 2.5. Multi-National Organisations 7
44 2.5.1. The Multi-National as a Single Entity 7
45 2.5.2. The Multi-National as a Loose Confederation 8
46 2.5.3. Loosely Linked DIT Sub-Trees 9
47 2.5.4. Summary of Advantages and Disadvantages of the
50 3.1. Multi-Component Relative Distinguished Names 11
51 3.2. National Guidelines for Naming 11
52 3.3. Naming Organisation and Organisational Unit Names 11
53 3.4. Naming Human Users 12
54 3.5. Application Entities 13
58 RARE Working Group on Network Applications Support (WG-NAP) [Page 1]
60 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
63 4. Attribute Values 13
64 4.1. Basic Attribute Syntaxes 13
65 4.1.1. Printable String 14
66 4.1.2. IA5 String - T.50 14
67 4.1.3. Teletex String - T.61 14
68 4.1.4. Case Ignore String 14
69 4.1.5. Distinguished Name 14
70 4.2. Languages & Transliteration 14
71 4.2.1. Languages other than English 15
72 4.2.2. Transliteration 15
73 4.3. Access control 15
74 4.4. Selected Attributes 16
75 4.4.1. Personal Attributes 16
76 4.4.2. Organisational Attributes 18
77 4.4.3. Local Attributes 19
78 4.4.4. Miscellaneous Attributes 20
79 4.4.5. MHS Attributes 21
80 4.4.6. Postal Attributes 21
81 4.4.7. Telecom Attributes 22
83 5.1. Schema consistency of aliases 22
84 5.2. Organisational Units 23
86 7. Security Considerations 23
87 8. Authors' Addresses 24
88 9. Appendix - Example Entries 25
92 The intended audience for this document are mainly data managers
93 using X.500 Directory Services. With the help of these guidelines it
94 should be easier for them to define the structure for the part of the
95 Directory Information Tree they want to model, e.g., the
96 representation of their organisation in the Directory. In addition,
97 decisions like which data elements to store for each kind of entry
100 These guidelines concentrate mainly on the White Pages use of the
101 Directory, the X.500 application with most operational experience
102 today, nonetheless many recommendations are also valid for other
103 applications of the Directory.
105 As a pre-requisite to this document, it is assumed that the COSINE
106 and Internet X.500 Schema is followed [1].
114 RARE Working Group on Network Applications Support (WG-NAP) [Page 2]
116 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
121 The majority of this document is concerned with DIT structure, naming
122 and the usage of attributes for organisations, organisational units
123 and personal entries.
125 This section briefly notes five other key issues.
129 A DIT structure is suggested in Annex B of X.521 [2], and it is
130 recommended that Directory Pilots for White Pages services should
131 follow these guidelines. Some simple restrictions should be applied,
132 as described below. For further usage of the Directory like e-mail
133 routing with the Directory or storage of network information in the
134 Directory it will be necessary to follow the guidelines specified in
135 the respective documents.
137 One of the few exceptions to the basic DIT structure is, that
138 international organisations will be stored immediately under the root
139 of the tree. Multi-national organisations will be stored within the
140 framework outlined, but with some use of aliases and attributes such
141 as seeAlso to help bind together the constituent parts of these
142 organisations. This is discussed in more detail in section 2.5.
144 A general rule for the depth of a subtree is as follows: When a
145 subtree is mainly accessed via searching, it should be as flat as
146 possible to improve the performance, when the access will be mainly
147 through read operations, the depth of the subtree is not a
148 significant parameter for performance.
150 2.2 The Top Level of the DIT
152 The following information will be present at the top level of the
155 Participating Countries
157 According to the standard the RDN is the ISO 3166 country code. In
158 addition, the entries should contain suitable values of the
159 friendlyCountryName attribute specified in RFC 1274. Use of this
160 attribute is described in more detail in section 4.4.4.
162 International Organisations
164 An international organisation is an organisation, such as the
165 United Nations, which inherently has a brief and scope covering
166 many nations. Such organisations might be considered to be
170 RARE Working Group on Network Applications Support (WG-NAP) [Page 3]
172 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
175 supra-national and this, indeed, is the raison-d'etre of such
176 organisations. Such organisations will almost all be governmental
177 or quasi-governmental. A multi-national organisation is an
178 organisation which operates in more than one country, but is not
179 supra-national. This classification includes the large commercial
180 organisations whose production and sales are spread throughout a
181 large number of countries.
183 International organisations may be registered at the top level.
184 This will not be done for multi-national organisations. Currently
185 three organisations are registered so far: Inmarsat, Internet and
186 North Atlantic Treaty Organization.
190 A few localities will be registered under the root. The chief
191 purpose of these locality entries is to provide a "natural" parent
192 node for organisations which are supra-national, and yet which do
193 not have global authority in their particular field. Such
194 organisations will usually be governmental or quasi-governmental.
195 Example localities might include: Europe, Africa, West Indies.
196 Example organisations within Europe might include: European Court
197 of Justice, European Space Agency, European Commission.
201 Some information on DSAs may be needed at the top level. This
202 should be kept to a minimum.
204 The only directory information for which there is a recognised top
205 level registration authority is countries. Registration of other
206 information at the top level may potentially cause problems. At this
207 stage, it is argued that the benefit of limiting additional top level
208 registrations outweighs these problems. However, this potential
209 problem should be noted by anyone making use of such a registration.
213 The national standardisation bodies will define national guidelines
214 for the structure of the national part of the DIT. In the interim,
215 the following simple structure should suffice. The country entry will
216 appear immediately beneath the root of the tree. Organisations which
217 have national significance should have entries immediately beneath
218 their respective country entries. Smaller organisations which are
219 only known in a particular locality should be placed underneath
220 locality entries representing states or similar geographical
221 divisions. Entry for private persons will be listed under the
222 locality entries. An example plan evolving for the US is the work of
226 RARE Working Group on Network Applications Support (WG-NAP) [Page 4]
228 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
231 the North American Directory Forum [3]. Another example is the
232 organisation of the X.500 namespace as standardized in Australia [4].
236 Large organisations will probably need to be sub-divided by
237 organisational units to help in the disambiguation of entries for
238 people with common names. Entries for people and roles will be stored
239 beneath organisations or organisational units.
241 The organisation entry itself shall contain the information necessary
242 to contact the organisation: for example, postal address, telephone
245 Although the structure of organisations often changes considerably
246 over time, the aim should be to minimise the number of changes to the
247 DIT. Note that renaming a superior, department entry has the effect
248 of changing the DN of all subordinate entries. This has an
249 undesirable impact on the service for several reasons. Alias entries
250 and certain attributes or ordinary entries such as seeAlso, secretary
251 and roleOccupant use DNs to maintain links with other entries. These
252 references are one-way only and the Directory standard offers no
253 support to automatically update all references to an entry once its
256 2.4.1 Directory Manager, Postmaster & Secretary
258 Similar to messaging, where every domain has its postmaster address
259 it is highly recommended that each organisation in the X.500
260 Directory has two entries: Postmaster and Directory Manager. In
261 addition, Secretary entries for an organisation and its units should
262 be listed. If this guidance is followed, users will benefit because
263 it will be straightforward to find the right contacts for questions
264 or problems with the service.
266 These entries should use the object class organizationalRole with the
267 roleOccupant attributes containing the distinguished names of the
268 persons in charge of this role. The values
276 should be added as additional values whenever another language than
277 English is used for the name of the entries.
282 RARE Working Group on Network Applications Support (WG-NAP) [Page 5]
284 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
289 The broad recommendation for White Pages is that the DIT should be as
290 flat as possible. A flat tree means that Directory names will be
291 relatively short, and probably somewhat similar in length and
292 component structure to paper mail addresses. A deep DIT would imply
293 long Directory names, with somewhat arbitrary component parts, with a
294 result which it is argued seems less natural. Any artificiality in
295 the choice of names militates against successful querying.
297 A presumption behind this style of naming is that most querying will
298 be supported by the user specifying convenient strings of characters
299 which will be mapped onto powerful search operations. The
300 alternative approach of the user browsing their way down the tree and
301 selecting names from large numbers of possibilities may be more
302 appropriate in some cases, and a deeper tree facilitates this.
303 However, these guidelines recommend a shallow tree, and implicitly a
304 search oriented approach.
306 It may be considered that there are two determinants of DIT depth:
307 first, how far down the DIT an organisation is placed; second, the
308 structure of the DIT within organisations.
310 The structure of the upper levels of the tree will be determined in
311 due course by various registration authorities, and the pilot will
312 have to work within the given structure. However, it is important
313 that the various pilots are cognisant of what the structures are
314 likely to be, and move early to adopt these structures.
316 The other principal determinant of DIT depth is whether an
317 organisation splits its entries over a number of organisational
318 units, and if so, the number of levels. The recommendation here is
319 that this sub-division of organisations is kept to a minimum. A
320 maximum of two levels of organisational unit should suffice even for
321 large organisations. Organisations with only a few tens or hundreds
322 of employees should strongly consider not using organisational units
323 at all. It is noted that there may be some problems with choice of
324 unique RDNs when using a flat DIT structure. Multi-component RDNs can
325 alleviate this problem: see section 3.1. The standard X.521
326 recommends that an organizationalUnitName attribute can also be used
327 as a naming attribute to disambiguate entries [2]. Further
328 disambiguation may be achieved by the use of a personalTitle or
329 userId attribute in the RDN.
338 RARE Working Group on Network Applications Support (WG-NAP) [Page 6]
340 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
343 2.4.3 Real World Organisational Structure
345 Another aspect on designing the DIT structure for an organisation is
346 the administrative structure within a company. Using the same
347 structure in the DIT might help in distributing maintenance authority
348 to the different units. Please note comments on the stability of the
349 DIT structure in section 2.4.
351 2.5 Multi-National Organisations
353 The standard says that only international organisations may be placed
354 under the root of the DIT. This implies that multi-national
355 organisations must be represented as a number of separate entries
356 underneath country or locality entries. This structure makes it more
357 awkward to use X.500 within a multi-national to provide an internal
358 organisational directory, as the data is now spread widely throughout
359 the DIT, rather than all being grouped within a single sub-tree.
361 Many people have expressed the view that this restriction is a severe
362 limitation of X.500, and argue that the intentions of the standard
363 should be ignored in this respect. This note argues, though, that the
364 standard should be followed.
366 No attempt to precisely define multinational organisation is essayed
367 here. Instead, the observation is made that the term is applied to a
368 variety of organisational structures, where an organisation operates
369 in more than one country. This suggests that a variety of DIT
370 structures may be appropriate to accommodate these different
371 organisational structures. This document suggests three approaches,
372 and notes some of the characteristics associated with each of these
375 Before considering the approaches, it is worth bearing in mind again
376 that a major aim in the choice of a DIT structure is to facilitate
377 querying, and that approaches which militate against this should be
378 avoided wherever possible.
380 2.5.1 The Multi-National as a Single Entity
382 In many cases, a multi-national organisation will operate with a
383 highly centralised structure. While the organisation may have large
384 operations in a number of countries, the organisation is strongly
385 controlled from the centre and the disparate parts of the
386 organisation exist only as limbs of the main organisation. In such a
387 situation, the model shown in figure 1 may be the best choice.
394 RARE Working Group on Network Applications Support (WG-NAP) [Page 7]
396 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
409 O=MultiNat---->O=MultiNat<----O=MultiNat
417 ---> means "alias to"
419 Figure 1: The multi-national as a single entity
421 The organisation's entries all exist under a single sub-tree. The
422 organisational structure beneath the organisation entry should
423 reflect the perceived structure of the organisation, and so no
424 recommendations on this matter can be made here. To assist the person
425 querying the directory, alias entries should be created under all
426 countries where the organisation operates.
428 2.5.2 The Multi-National as a Loose Confederation
430 Another common model of organisational structure is that where a
431 multi-national consists of a number of national entities, which are
432 in large part independent of both sibling national entities, and of
433 any central entity. In such cases, the model shown in Figure 2 may be
434 a better choice. Organisational entries exist within each country,
435 and only that country's localities and organisational units appear
436 directly beneath the appropriate organisational entry.
450 RARE Working Group on Network Applications Support (WG-NAP) [Page 8]
452 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
463 O=MultiNat O=MultiNat O=MultiNat
468 L=FR L=GB<---L=GB | L=US--->L=US L=FR
470 ------------------->L=FR<----------------
472 ---> means "alias to"
474 Figure 2: The multi-national as a loose confederation
476 Some binding together of the various parts of the organisation can be
477 achieved by the use of aliases for localities and organisational
478 units, and this can be done in a highly flexible fashion. In some
479 cases, the national view might not contain all branches of the
480 company, as illustrated in Figure 2.
482 2.5.3 Loosely Linked DIT Sub-Trees
484 A third approach is to avoid aliasing altogether, and to use the
485 looser binding provided by an attribute such as seeAlso. This
486 approach treats all parts of an organisation as essentially separate.
488 A unified view of the organisation can only be achieved by user
489 interfaces choosing to follow the seeAlso links. This is a key
490 difference with aliasing, where decisions to follow links may be
491 specified within the protocol. (Note that it may be better to specify
492 another attribute for this purpose, as seeAlso is likely to be used
493 for a wide variety of purposes.)
495 2.5.4 Summary of Advantages and Disadvantages of the Above Approaches
497 Providing an internal directory
499 All the above methods can be used to provide an internal
500 directory. In the first two cases, the linkage to other parts of
501 the organisation can be followed by the protocol and thus
502 organisation-wide searches can be achieved by single X.500
506 RARE Working Group on Network Applications Support (WG-NAP) [Page 9]
508 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
511 operations. In the last case, interfaces would have to "know" to
512 follow the soft links indicated by the seeAlso attribute.
516 In the single-entity model, all DNs within the organisation will
517 be under one country. It could be argued that this will often
518 result in rather "unnatural" naming. In the loose- confederation
519 model, DNs are more natural, although the need to disambiguate
520 between organisational units and localities on an international,
521 rather than just a national, basis may have some impact on the
522 choice of names. For example, it may be necessary to add in an
523 extra level of organisational unit or locality information. In the
524 loosely-linked model, there is no impact on naming at all.
526 Views of the organisation
528 The first method provides a unique view of the organisation. The
529 loose confederacy allows for a variety of views of the
530 organisation. The view from the centre of the organisation may
531 well be that all constituent organisations should be seen as part
532 of the main organisation, whereas other parts of the organisation
533 may only be interested in the organisation's centre and a few of
534 its sibling organisations. The third model gives an equally
535 flexible view of organisational structures.
539 All methods should perform reasonably well, providing information
540 is either held within a single DSA or it is replicated to the
545 The first goal of naming is to provide unique identifiers for
546 entries. Once this is achieved, the next major goal in naming entries
547 should be to facilitate querying of the Directory. In particular,
548 support for a naming structure which facilitates use of user friendly
549 naming [5] is desirable. Other considerations, such as accurately
550 reflecting the organisational structure of an organisation, should be
551 disregarded if this has an adverse effect on normal querying. Early
552 experience in the pilot has shown that a consistent approach to
553 structure and naming is an aid to querying using a wide range of user
554 interfaces, as interfaces are often optimised for DIT structures
555 which appear prevalent. In addition, the X.501 standard notes that
556 "RDNs are intended to be long-lived so that the users of the
557 Directory can store the distinguished names of objects..." and "It is
558 preferable that distinguished names of objects which humans have to
562 RARE Working Group on Network Applications Support (WG-NAP) [Page 10]
564 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
567 deal with be user-friendly." [2]
569 Naming is dependent on a number of factors and these are now
572 3.1 Multi-Component Relative Distinguished Names
574 According to the standard, relative distinguished names may have more
575 than one component selected from the set of the attributes of the
576 entry to be named. This is useful when there are, for example, two
577 "John Smiths" in one department. The use of multi-component relative
578 distinguished names allows one to avoid artificial naming values such
579 as "John Smith 1" or "John Smith-2". Attributes which could be used
580 as the additional naming attribute include: personalTitle,
581 roomNumber, telephoneNumber, and userId.
583 3.2 National Guidelines for Naming
585 Where naming is being done in a country which has established
586 guidelines for naming, these guidelines should in general be
587 followed. These guidelines might be based on an established
588 registration authority, or may make use of an existing registration
589 mechanism (e.g., company name registration).
591 Where an organisation has a name which is nationally registered in an
592 existing registry, this name is likely to be appropriate for use in
593 the Directory, even in cases where there are no national guidelines.
595 3.3 Naming Organisation and Organisational Unit Names
597 The naming of organisations in the Directory will ultimately come
598 under the jurisdiction of official naming authorities. In the
599 interim, it is recommended that pilots and organisations follow these
600 guidelines. An organisation's RDN should usually be the full name of
601 the organisation, rather than just a set of initials. This means that
602 University College London should be preferred over UCL. An example
603 of the problems which a short name might cause is given by the
604 proposed registration of AA for the Automobile Association. This
605 seems reasonable at first glance, as the Automobile Association is
606 well known by this acronym. However, it seems less reasonable in a
607 broader perspective when you consider that organisations such as
608 Alcoholics Anonymous and American Airlines use the same acronym.
610 Just as initials should usually be avoided for organisational RDNs,
611 so should formal names which, for example, exist only on official
612 charters and are not generally well known. There are two reasons for
618 RARE Working Group on Network Applications Support (WG-NAP) [Page 11]
620 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
623 1. The names should be meaningful.
625 2. The names should uniquely identify the organisation, and be
626 a name which is unlikely to be challenged in an open
627 registration process. For example, UCL might well be
628 challenged by United Carriers Ltd.
630 The same arguments on naming style can be applied with even greater
631 force to the choice of RDNs for organisational units. While
632 abbreviated names will be in common parlance within an organisation,
633 they will almost always be meaningless outside of that organisation.
634 While many people in academic computing habitually refer to CS when
635 thinking of Computer Science, CS may be given several different
636 interpretations. It could equally be interpreted as Computing
637 Services, Cognitive Science, Clinical Science or even Counselling
640 For both organisations and organisational units, extra naming
641 information should be stored in the directory as alternative values
642 of the naming attribute. Thus, for University College London, UCL
643 should be stored as an alternative organizationName attribute value.
644 Similarly CS could be stored as an alternative organizationalUnitName
645 value for Computer Science and any of the other departments cited
646 earlier. In general, entries will be located by searching, and so it
647 is not essential to have RDNs which are either the most memorable or
648 guessable, although names should be recognisable. The need for users
649 not to type long names may be achieved by use of carefully selected
652 3.4 Naming Human Users
654 A reasonably consistent approach to naming people is particularly
655 critical as a large percentage of directory usage will be looking up
656 information about people. User interfaces will be better able to
657 assist users if entries have names conforming to a common format, or
658 small group of formats. It is suggested that the RDN should follow
659 such a format. Alternative values of the common name attribute should
660 be used to store extra naming information. It seems sensible to try
661 to ensure that the RDN commonName value is genuinely the most common
662 name for a person as it is likely that user interfaces may choose to
663 place greater weight on matches on the RDN than on matches on one of
664 the alternative names.
666 The choice of RDN for humans will be influenced by cultural
667 considerations. In many countries the best choice will be of the form
668 familiar-first-name surname. Thus, Steve Kille is preferred as the
669 RDN choice for one of this document's co-authors, while Stephen E.
670 Kille is stored as an alternative commonName value. Pragmatic choices
674 RARE Working Group on Network Applications Support (WG-NAP) [Page 12]
676 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
679 will have to be made for other cultures. The common name attribute
680 should not be used to hold other attribute information such as
681 telephone numbers, room numbers, or local codes. Such information
682 should be stored within the appropriate attributes as defined in the
683 COSINE and Internet X.500 Schema. Section 3.1 on multi-component RDNs
684 shows how clashing names can be made unique.
686 The choice of a naming strategy should not be made on the basis of
687 the possibilities of the currently available user interface
688 implementations. For example, it is inappropriate to use common names
689 of the form 'surname firstname' merely because a user interface
690 presents results in a more satisfactory order by so doing. Use the
691 best structure for human names, and fix the user interface!
693 More details on the use of commonName in section 4.4.1.
695 3.5 Application Entities
697 The guidelines of X.521 should be followed, in that the application
698 entity should always be named relative to an Organisation or
699 Organisational Unit. The application process will often correspond to
700 a system or host. In this case, the application entities should be
701 named by Common Names which identify the service (e.g., "FTAM
702 Service"). In cases where there is no useful distinction between
703 application process and application entity, the application process
704 may be omitted (This is often done for DSAs in the current pilot).
708 In general the attribute values should be used as documented in the
709 standards. Sometimes the standard is not very precise about which
710 attribute to use and how to represent a value.
712 The following sections give recommendations how to use them in X.500
715 4.1 Basic Attribute Syntaxes
717 Every attribute type has a definition of the attribute syntaxes its
718 values may be use. Most attribute types make use the basic attribute
730 RARE Working Group on Network Applications Support (WG-NAP) [Page 13]
732 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
735 4.1.1 Printable String
737 This most simple syntax uses a subset of characters from ISO 646 IRV.
743 Tab 1: Characters in PrintableString
745 4.1.2 IA5 String - T.50
747 The International Alphabet No. 5 (IA5) is known from the X.400
748 message handling service. It covers a wider range of characters than
749 the printable string. The international reference version of IA5
750 offers the same set of characters as ISO 646 IRV.
752 4.1.3 Teletex String - T.61
754 The Teletex character set is a very unusual one in the computing
755 environment because it uses mixed one and two octet character codes
756 which are more difficult to handle than single octet codes. Most of
757 the characters can be mapped to the more often supported 8-bit
758 character set standard ISO 8859-1 (ISO Latin-1).
760 4.1.4 Case Ignore String
762 Many attributes use this case insensitive syntax. It allows attribute
763 values to be represented using a mixture of upper and lower case
764 letters, as appropriate. Matching of attribute values, however, is
765 performed such that no significance is given to case.
767 4.1.5 Distinguished Name
769 A Distinguished Name should currently never contain a value in T.61
770 string syntax because most users would not be able to view or type it
771 correctly by lack of appropriate hardware/software configuration.
772 Therefore, only the characters defined in printable string syntax
773 should be used as part of a RDN. The correct representation of the
774 name should be added as additional attribute value to match for
777 4.2 Languages & Transliteration
779 The standard as available has no support at all for the use of
780 different languages in the Directory. It is e.g., not possible to add
781 a language qualifier to a description attribute nor is it possible to
782 use characters beyond the Teletex character set.
786 RARE Working Group on Network Applications Support (WG-NAP) [Page 14]
788 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
791 4.2.1 Languages other than English
793 Many countries have more than one national language and a world-wide
794 Directory must be able to support non-English-speaking users.
796 Until the standard provides a solution for this problem it is
797 possible to make use of multi-valued attributes to specify a value
798 not only in the local languages but also in English.
800 In particular the friendlyCountryName, stateOrProvinceName and
801 localityName attributes should use the most often used translations
802 of its original value to increase the chance for successful searches
803 also for users with a foreign language. Other attributes like
804 description, organizationName and organizationalUnitName attributes
805 should provide multi-lingual values where appropriate.
807 The drawback of this solution is, that the user interfaces present
808 much redundant information because they are not able to know the
809 language of the values and make an automatic selection.
811 Note: The sequence of multi-valued attribute values in an entry
812 cannot be defined. It is always up to the DSA to decide on
813 which order to store them and return them as results, and
814 to the DUA to decide on which order to display them.
816 4.2.2 Transliteration
818 What measures can be taken to make sure all users are able to read an
819 attribute, when a value uses one of the special characters from the
820 T.61 character set? An interim solution is transliteration as used in
821 earlier days with the typewriters, where e.g., the German 'a' with
822 umlaut is written as 'ae'. Transliteration is not necessarily unique
823 since it is dependent on the language, English speakers transliterate
824 the 'a' with umlaut just to an 'a'. However, it is an improvement
825 over just using the T.61 value since it may not be possible to
826 display such a value at all. Whenever an attribute needs a character
827 not in PrintableString and the attribute syntax allows the use of the
828 T.61 character set, it is recommended that the attribute should be
829 supplied as multi-valued attribute both in T.61 string and in a
830 transliterated PrintableString notation.
834 An entry's object class attribute, and any attribute(s) used for
835 naming an entry are of special significance and may be considered to
836 be "structural". Any inability to access these attributes will often
837 militate against successful querying of the Directory. For example,
838 user interfaces typically limit the scope of their searches by
842 RARE Working Group on Network Applications Support (WG-NAP) [Page 15]
844 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
847 searching for entries of a particular type, where the type of entry
848 is indicated by its object class. Thus, unless the intention is to
849 bar public access to an entry or set of entries, the object class and
850 naming attributes should be publicly readable.
852 4.4 Selected Attributes
854 The section lists attributes together with a short description what
855 they should be used for and some examples. [6] The source of the
856 attributes is given in brackets.
858 Note that due to national legal restrictions on privacy issues it
859 might be forbidden to use certain attributes or that the search on
860 them is restricted. [7]
862 4.4.1 Personal Attributes
866 It is proposed that pilots should ignore the standard's
867 recommendations on storing personal titles, and letters indicating
868 academic and professional qualifications within the commonName
869 attribute, as this overloads the commonName attribute. A
870 personalTitle attribute has already been specified in the COSINE
871 and Internet Schema, and another attribute could be specified for
872 information about qualifications.
874 The choice of a name depends on the culture as discussed in
875 section 3.4. When a commonName is selected as (part of) a RDN the
876 most often used form of the name should be selected. A firstname
877 should never be supplied only as an initial (unless, of course,
878 the source data does not include forenames). It is very important
879 to have its full value in order to be able to distinguish between
880 two similar entries. Sets of initials should not be concatenated
881 into a single "word", but be separated by spaces and/or "."
885 Format: Firstname [Initials] Lastname
898 RARE Working Group on Network Applications Support (WG-NAP) [Page 16]
900 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
903 The use of 'Lastname Firstname' is deprecated as explained in
906 favouriteDrink [RFC 1274]
908 The intention of this attribute is that it provides at least one
909 benign attribute which any user can create or modify, given a
910 suitable user interface, without having the unfortunate impact on
911 the directory service that follows from modifying an attribute
912 such as an e-mail address or telephone number.
914 Example: Pure Crystal Water
916 organizationalStatus [RFC 1274]
918 The Organisational Status attribute type specifies a category by
919 which a person is often referred to in an organisation. Examples
920 of usage in academia might include undergraduate student,
921 researcher, lecturer, etc.
923 A Directory administrator should consider carefully the
924 distinctions between this and the title and description
927 Example: undergraduate student
929 personalTitle [RFC 1274]
931 The usually used titles, especially academic ones. Excessive use
936 roomNumber [RFC 1274]
938 The room where the person works, it will mostly be locally defined
939 how to write the room number, e.g., Building Floor Room.
945 The secretary of the person. This is the Distinguished Name (DN)
948 Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
954 RARE Working Group on Network Applications Support (WG-NAP) [Page 17]
956 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
961 Like with commonName it is a matter of culture what to use for
962 surname in case of a noble name, e.g., de Stefani, von Gunten.
968 Title describing the position, job title or function of an
969 organisational person.
971 Example: Manager - International Sales
975 When an organisation has centrally managed user ids, it might make
976 sense to include it into the entry. It might also be used to form
977 a unique RDN for the person.
983 The password of the entry which allows the modification of the
984 entry, provided that the access control permits it. The password
985 should not be the same as any system password, unless it is sure
986 that nobody can read it. With the current implementations this is
987 mostly not guaranteed.
991 4.4.2 Organisational Attributes
993 associatedDomain [RFC 1274]
995 The Internet domain name for an organisation or one of its units.
999 businessCategory [X.520]
1001 Type of business an organisation, an organisational unit or
1002 organisational person is involved in. The values could be chosen
1005 Example: Software Development
1010 RARE Working Group on Network Applications Support (WG-NAP) [Page 18]
1012 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1015 organizationName [X.520]
1017 The name of the organisation. The value for the RDN should be
1018 chosen according to section 3.3. Additional names like
1019 abbreviations should be used for better search results.
1021 Example: Uni Lausanne
1022 Universite de Lausanne
1023 Universit\c2e Lausanne (with a T.61 encoded umlaut)
1024 University of Lausanne
1027 organizationalUnitName [X.520]
1029 The name of a part of the organisation. The value for the RDN
1030 should be chosen according to section 3.3. Additional names like
1031 abbreviations should be provided for better search results.
1033 Example: Institut fuer Angewandte Mathematik
1037 roleOccupant [X.520]
1039 The person(s) in that role. This is the Distinguished Name of the
1040 entry of the person(s).
1042 Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
1046 The currently available DUAs make no use this attribute. It seems
1047 that it is not powerful enough for real usage. Experience is
1048 needed before being able to give recommendations on how to
1051 4.4.3 Local Attributes
1053 localityName [X.520]
1055 Name of the place, village or town with values in local and other
1056 languages as useful.
1059 B\c3ale (with a T.61 encoded accented character) Basel
1066 RARE Working Group on Network Applications Support (WG-NAP) [Page 19]
1068 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1071 stateOrProvinceName [X.520]
1073 Name of the canton, county, department, province or state with
1074 values in local and other languages as useful. If official and
1075 commonly used abbreviations exist for the states, they should be
1076 supplied as additional values
1082 4.4.4 Miscellaneous Attributes
1086 The audio attribute uses a u-law encoded sound file as used by the
1087 "play" utility on a Sun 4. According to RFC 1274 it is an interim
1088 format. It may be useful to listen to the pronunciation of a name
1089 which is otherwise unknown.
1093 A short informal explanation of special interests of a person or
1094 organisation. Overlap with businessCategory, organizationalStatus
1095 and title should be avoided.
1097 Example: Networking, distributed systems, OSI, implementation.
1099 friendlyCountryName [RFC 1274]
1101 The friendlyCountryName attribute type specifies names of
1102 countries in human readable format. Especially the country name as
1103 used in the major languages should be included as additional
1104 values to help foreign users.
1106 jpegPhoto [RFC 1488] [8]
1108 A colour or grayscale picture encoded according to JPEG File
1109 Interchange Format (JFIF). Thanks to compression the size of the
1110 pictures is moderate. For persons it may show a portrait, for
1111 organisations the company logo or a map on how to get there.
1115 The photo attribute is a b/w G3 fax encoded picture of an object.
1116 The size of the photo should be in a sensible relation to the
1117 informational value of it. This attribute will be replaced by
1122 RARE Working Group on Network Applications Support (WG-NAP) [Page 20]
1124 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1129 Reference to another closely related entry in the DIT, e.g., from
1130 a room to the person using that room. It is the Distinguished Name
1133 Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
1135 4.4.5 MHS Attributes
1137 mhsORAddresses [X.411]
1139 The attribute uses internally an ASN.1 structure. The string
1140 notation used for display purposes is implementation dependent.
1141 This attribute is especially useful for an integrated X.400 user
1142 agent since it gets the address in a directly usable format.
1144 rfc822mailbox [RFC 1274]
1146 E-Mail address in RFC 822 notation
1148 Example: s.kille@isode.com
1150 textEncodedORAddress [RFC 1274]
1152 X.400 e-mail address in string notation. The F.401 notation should
1153 be used. This attribute shall disappear once the majority of the
1154 DUAs support the mhsORAddresses attribute. The advantage of the
1155 latter attribute is, that a configurable DUA could adjust the
1156 syntax to the one needed by the local mailer, where
1157 textencodedORAddress is just a string which will mostly have a
1158 different syntax than the mailer expects.
1160 Example: G=thomas; S=lenggenhager; OU1=gate; O=switch; \
1161 P=switch; A=arcom; C=ch;
1163 4.4.6 Postal Attributes
1165 postalAddress [X.520]
1167 The full postal address (but not including the name) in
1168 international notation, with up to 6 lines with 30 characters
1178 RARE Working Group on Network Applications Support (WG-NAP) [Page 21]
1180 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1185 The postalCode will be the same as used in the postalAddress (in
1186 international notation).
1190 streetAddress [X.520]
1192 It shall be the street where the person has its office. Mostly, it
1193 will be the street part of the postalAddress.
1195 Example: Limmatquai 138
1197 4.4.7 Telecom Attributes
1199 telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520]
1201 The phone number in the international notation according to CCITT
1202 E.123. The separator '-' instead of space may be used according to
1203 the local habit, it should be used consistently within a country.
1205 Format: "+" <country code> <national number> ["x" <extension>]
1206 Example: +41 1 268 1540
1210 The telex number in the international notation
1212 Example: 817379, ch, ehhg
1216 This section draws attention to two areas which frequently provoke
1217 questions, and where it is felt that a consistent approach will be
1220 5.1 Schema consistency of aliases
1222 According to the letter of the standard, an alias may point at any
1223 entry. It is beneficial for aliases to be 'schema consistent'.
1225 The following two checks should be made:
1227 1. The Relative Distinguished Name of the alias should use an
1228 attribute type normally used for naming entries of the
1229 object class of the main entry.
1234 RARE Working Group on Network Applications Support (WG-NAP) [Page 22]
1236 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1239 2. If the entry (aliased object) were placed where the alias
1240 is, there should be no schema violation.
1242 5.2 Organisational Units
1244 There is a problem that many organisations can be either
1245 organisations or organisational units, dependent on the location in
1246 the DIT (with aliases giving the alternate names). For example, an
1247 organisation may be an independent national organisation and also an
1248 organisational unit of a parent organisation. To achieve this, it is
1249 important to allow an entry to be of both object class organisation
1250 and of object class organisational unit.
1254 [1] Barker, P., and S. Hardcastle-Kille, "The COSINE and Internet
1255 X.500 schema", RFC 1274, Department of Computer Science,
1256 University College London, November 1991.
1258 [2] "The Directory --- Overview of concepts, models and services",
1259 CCITT X.500 Series Recommendations, December 1988.
1261 [3] The North American Directory Forum. "A Naming Scheme for C=US",
1262 RFC 1255, NADF-175, NADF, September 1991.
1264 [4] Michaelson, G., and M. Prior, "Naming Guidelines for the AARNet
1265 X.500 Directory Service", RFC 1562, AEN-001, The University of
1266 Queensland, The University of Adelaide, December 1993.
1268 [5] Hardcastle-Kille, S., "Using the OSI Directory to achieve user
1269 friendly naming", RFC 1484, Department of Computer Science,
1270 University College London, July 1993.
1272 [6] Barker, P., "Preparing data for inclusion in an X.500 Directory",
1273 Research Note RN/92/41, Department of Computer Science,
1274 University College London, May 1992.
1276 [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy
1277 Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993.
1279 [8] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The X.500
1280 String Representation of Standard Attribute Syntaxes", RFC 1488,
1281 University of Michigan, ISODE Consortium, Performance Systems
1282 International, NeXor Ltd., July 1993.
1284 7. Security Considerations
1286 Security issues are not substantially discussed in this memo.
1290 RARE Working Group on Network Applications Support (WG-NAP) [Page 23]
1292 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1295 8. Authors' Addresses
1298 Department of Computer Science
1299 University College London
1304 Phone: +44 71 380 7366
1305 EMail: p.barker@cs.ucl.ac.uk
1307 DN: CN=Paul Barker, OU=Computer Science, O=University College
1310 UFN: Paul Barker, Computer Science, UCL, GB
1320 Phone: +44 81 332 9091
1321 EMail: s.kille@isode.com
1323 DN: CN=Steve Kille, O=ISODE Consortium, C=GB
1325 UFN: S. Kille, ISODE Consortium, GB
1334 Phone: +41 1 268 1540
1335 EMail: lenggenhager@switch.ch
1337 DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
1339 UFN: Thomas Lenggenhager, SWITCH, CH
1346 RARE Working Group on Network Applications Support (WG-NAP) [Page 24]
1348 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1351 9. Appendix - Example Entries
1357 objectClass=top & country & domainRelatedObject & friendlyCountry
1360 friendlyCountryName=CH
1361 friendlyCountryName=Confoederatio Helvetica
1362 friendlyCountryName=Schweiz
1363 friendlyCountryName=Suisse
1364 friendlyCountryName=Svizzera
1365 friendlyCountryName=Switzerland
1371 objectClass=top & organization & mhsUser & domainRelatedObject
1372 description=Swiss Academic and Research Network
1373 organizationName=SWIss TeleCommunication system for Higher
1374 education\and research
1375 organizationName=Swiss Academic and Research Network
1376 organizationName=SWITCH
1377 localityName=Zuerich
1379 localityName={T.61}Z\c8urich
1380 stateOrProvinceName=ZH
1381 stateOrProvinceName=Zuerich
1382 stateOrProvinceName=Zurich
1383 stateOrProvinceName={T.61}Z\c8urich
1384 postalAddress=SWITCH
1388 streetAddress=Limmatquai 138
1389 telephoneNumber=+41 1 268 1515
1390 facsimileTelephoneNumber=+41 1 268 1568
1391 seeAlso=CN=Postmaster, O=SWITCH, C=CH
1392 mhsORAddresses=S=postmaster, O=switch; P=switch; A=arcom; C=ch;
1393 associatedDomain=switch.ch
1402 RARE Working Group on Network Applications Support (WG-NAP) [Page 25]
1404 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1407 9.3 Organisation Unit
1409 DN: OU=SWITCHdirectory, O=SWITCH, C=CH
1411 objectClass=top & organizationalUnit
1412 description=The SWITCH X.500 pilot project
1413 organizationalUnitName=SWITCHdirectory
1415 localityName=Zuerich
1416 localityName={T.61}Z\c8urich
1417 stateOrProvinceName=Zurich
1418 stateOrProvinceName=Zuerich
1419 stateOrProvinceName=ZH
1420 stateOrProvinceName={T.61}Z\c8urich
1421 postalAddress=SWITCHdirectory
1426 streetAddress=Limmatquai 138
1427 telephoneNumber=+41 1 268 1540
1428 facsimileTelephoneNumber=+41 1 268 1568
1430 9.4 Organizational Role
1432 DN: CN=Directory Manager, O=SWITCH, C=CH
1434 objectClass=top & organizationalRole & mhsUser
1435 commonName=Directory Manager
1436 description=SWITCH Directory Managers
1437 roleOccupant=CN=Martin Berli, O=SWITCH, C=CH
1438 roleOccupant=CN=Thomas Lenggenhager, O=SWITCH, C=CH
1439 localityName=Zuerich
1441 localityName={T.61}Z\c8urich
1442 stateOrProvinceName=Zurich
1443 stateOrProvinceName=Zuerich
1444 stateOrProvinceName=ZH
1445 stateOrProvinceName={T.61}Z\c8urich
1446 postalAddress=SWITCHdirectory
1451 streetAddress=Limmatquai 138
1452 telephoneNumber=+41 1 268 1540
1453 facsimileTelephoneNumber=+41 1 268 1568
1454 mhsORAddresses=S=switchinfo; O=switch; P=switch; A=arcom; C=ch;
1458 RARE Working Group on Network Applications Support (WG-NAP) [Page 26]
1460 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1463 DN: CN=Postmaster, O=SWITCH, C=CH
1465 objectClass=top & organizationalRole & mhsUser
1466 commonName=Postmaster
1468 roleOccupant=CN=Christoph Graf, O=SWITCH, C=CH
1469 roleOccupant=CN=Felix Kugler, O=SWITCH, C=CH
1470 roleOccupant=CN=Marcel Parodi, O=SWITCH, C=CH
1471 roleOccupant=CN=Marcel Schneider, O=SWITCH, C=CH
1472 telephoneNumber=+41 1 268 1520
1473 facsimileTelephoneNumber=+41 1 268 1568
1474 mhsORAddresses=S=postmaster; O=switch; P=switch; A=arcom; C=ch;
1476 DN: CN=Secretary, O=SWITCH, C=CH
1478 objectClass=top & organizationalRole & quipuObject
1479 commonName=Secretary
1480 roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH
1514 RARE Working Group on Network Applications Support (WG-NAP) [Page 27]
1516 RFC 1617 Naming and Structuring Guidelines for X.500 May 1994
1521 DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
1523 objectClass=top & person & organizationalPerson & mhsUser &
1524 pilotObject & newPilotPerson
1525 commonName=Thomas Lenggenhager
1526 commonName=T. Lenggenhager
1527 surname=Lenggenhager
1528 description=SWITCHinfo, Project Leader
1529 localityName=Zuerich
1531 localityName={T.61}Z\c8urich
1532 stateOrProvinceName=ZH
1533 stateOrProvinceName=Zuerich
1534 stateOrProvinceName=Zurich
1535 stateOrProvinceName={T.61}Z\c8urich
1536 postalAddress=SWITCH
1540 streetAddress=Limmatquai 138
1541 telephoneNumber=+41 1 268 1540
1542 facsimileTelephoneNumber=+41 1 268 1568
1543 mhsORAddresses=S=lenggenhager; O=switch; P=switch; A=arcom; C=ch;
1545 textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \
1547 rfc822mailbox=lenggenhager@switch.ch
1548 secretary=CN=Franziska Remund, O=SWITCH, C=CH
1570 RARE Working Group on Network Applications Support (WG-NAP) [Page 28]