home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1617 < prev    next >
Text File  |  1995-09-15  |  57KB  |  1,572 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  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
  12.                                                                   SWITCH
  13.                                                                 May 1994
  14.  
  15.  
  16.       Naming and Structuring Guidelines for X.500 Directory Pilots
  17.  
  18. Status of this Memo
  19.  
  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.
  23.  
  24. Abstract
  25.  
  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.
  31.  
  32. Table of Contents
  33.  
  34.     1. Introduction                                                2
  35.     2. DIT Structure                                               3
  36.     2.1. Structure Rules                                           3
  37.     2.2. The Top Level of the DIT                                  3
  38.     2.3. Countries                                                 4
  39.     2.4. Organisations                                             5
  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
  48.            Above Approaches                                        9
  49.     3. Naming Style                                               10
  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
  55.  
  56.  
  57.  
  58. RARE Working Group on Network Applications Support (WG-NAP)     [Page 1]
  59.  
  60. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  61.  
  62.  
  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
  82.     5. Miscellany                                                 22
  83.     5.1. Schema consistency of aliases                            22
  84.     5.2. Organisational Units                                     23
  85.     6. References                                                 23
  86.     7. Security Considerations                                    23
  87.     8. Authors' Addresses                                         24
  88.     9. Appendix - Example Entries                                 25
  89.  
  90. 1. Introduction
  91.  
  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
  98.    shall be supported.
  99.  
  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.
  104.  
  105.    As a pre-requisite to this document, it is assumed that the COSINE
  106.    and Internet X.500 Schema is followed [1].
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. RARE Working Group on Network Applications Support (WG-NAP)     [Page 2]
  115.  
  116. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  117.  
  118.  
  119. 2. DIT Structure
  120.  
  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.
  124.  
  125.    This section briefly notes five other key issues.
  126.  
  127. 2.1 Structure Rules
  128.  
  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.
  136.  
  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.
  143.  
  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.
  149.  
  150. 2.2 The Top Level of the DIT
  151.  
  152.    The following information will be present at the top level of the
  153.    DIT:
  154.  
  155.    Participating Countries
  156.  
  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.
  161.  
  162.    International Organisations
  163.  
  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
  167.  
  168.  
  169.  
  170. RARE Working Group on Network Applications Support (WG-NAP)     [Page 3]
  171.  
  172. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  173.  
  174.  
  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.
  182.  
  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.
  187.  
  188.    Localities
  189.  
  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.
  198.  
  199.    DSA Information
  200.  
  201.       Some information on DSAs may be needed at the top level.  This
  202.       should be kept to a minimum.
  203.  
  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.
  210.  
  211. 2.3 Countries
  212.  
  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
  223.  
  224.  
  225.  
  226. RARE Working Group on Network Applications Support (WG-NAP)     [Page 4]
  227.  
  228. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  229.  
  230.  
  231.    the North American Directory Forum [3]. Another example is the
  232.    organisation of the X.500 namespace as standardized in Australia [4].
  233.  
  234. 2.4 Organisations
  235.  
  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.
  240.  
  241.    The organisation entry itself shall contain the information necessary
  242.    to contact the organisation: for example, postal address, telephone
  243.    and fax numbers.
  244.  
  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
  254.    DN changes.
  255.  
  256. 2.4.1 Directory Manager, Postmaster & Secretary
  257.  
  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.
  265.  
  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
  269.  
  270.       CN=Directory Manager
  271.  
  272.       CN=Postmaster
  273.  
  274.       CN=Secretary
  275.  
  276.    should be added as additional values whenever another language than
  277.    English is used for the name of the entries.
  278.  
  279.  
  280.  
  281.  
  282. RARE Working Group on Network Applications Support (WG-NAP)     [Page 5]
  283.  
  284. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  285.  
  286.  
  287. 2.4.2 Depth of tree
  288.  
  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.
  296.  
  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.
  305.  
  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.
  309.  
  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.
  315.  
  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.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. RARE Working Group on Network Applications Support (WG-NAP)     [Page 6]
  339.  
  340. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  341.  
  342.  
  343. 2.4.3 Real World Organisational Structure
  344.  
  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.
  350.  
  351. 2.5 Multi-National Organisations
  352.  
  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.
  360.  
  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.
  365.  
  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
  373.    approaches.
  374.  
  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.
  379.  
  380. 2.5.1 The Multi-National as a Single Entity
  381.  
  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.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. RARE Working Group on Network Applications Support (WG-NAP)     [Page 7]
  395.  
  396. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  397.  
  398.  
  399.                             ROOT
  400.  
  401.                            / | \
  402.                           /  |  \
  403.  
  404.                       C=GB  C=FR  C=US
  405.  
  406.                      /       |       \
  407.                     /        |        \
  408.  
  409.           O=MultiNat---->O=MultiNat<----O=MultiNat
  410.  
  411.                          /    |    \
  412.                         /     |     \
  413.                        /      |      \
  414.  
  415.                  l=abc      ou=def     l=fgi
  416.  
  417.                      ---> means "alias to"
  418.  
  419.       Figure 1: The multi-national as a single entity
  420.  
  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.
  427.  
  428. 2.5.2 The Multi-National as a Loose Confederation
  429.  
  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.
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. RARE Working Group on Network Applications Support (WG-NAP)     [Page 8]
  451.  
  452. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  453.  
  454.  
  455.                               ROOT
  456.  
  457.                              / | \
  458.                             /  |  \
  459.                         C=GB C=FR C=US
  460.  
  461.                         /      |     \
  462.                        /       |      \
  463.               O=MultiNat   O=MultiNat   O=MultiNat
  464.  
  465.              /    |        /    |   \        |    \
  466.             /     |       /     |    \       |     \
  467.  
  468.         L=FR    L=GB<---L=GB     |   L=US--->L=US   L=FR
  469.           \                      |                 /
  470.            ------------------->L=FR<----------------
  471.  
  472.                       ---> means "alias to"
  473.  
  474.       Figure 2: The multi-national as a loose confederation
  475.  
  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.
  481.  
  482. 2.5.3 Loosely Linked DIT Sub-Trees
  483.  
  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.
  487.  
  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.)
  494.  
  495. 2.5.4 Summary of Advantages and Disadvantages of the Above Approaches
  496.  
  497.    Providing an internal directory
  498.  
  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
  503.  
  504.  
  505.  
  506. RARE Working Group on Network Applications Support (WG-NAP)     [Page 9]
  507.  
  508. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  509.  
  510.  
  511.       operations. In the last case, interfaces would have to "know" to
  512.       follow the soft links indicated by the seeAlso attribute.
  513.  
  514.    Impact on naming
  515.  
  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.
  525.  
  526.    Views of the organisation
  527.  
  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.
  536.  
  537.    Lookup performance
  538.  
  539.       All methods should perform reasonably well, providing information
  540.       is either held within a single DSA or it is replicated to the
  541.       other DSAs.
  542.  
  543. 3. Naming Style
  544.  
  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
  559.  
  560.  
  561.  
  562. RARE Working Group on Network Applications Support (WG-NAP)    [Page 10]
  563.  
  564. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  565.  
  566.  
  567.    deal with be user-friendly." [2]
  568.  
  569.    Naming is dependent on a number of factors and these are now
  570.    considered in turn.
  571.  
  572. 3.1 Multi-Component Relative Distinguished Names
  573.  
  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.
  582.  
  583. 3.2 National Guidelines for Naming
  584.  
  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).
  590.  
  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.
  594.  
  595. 3.3 Naming Organisation and Organisational Unit Names
  596.  
  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.
  609.  
  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
  613.    this approach:
  614.  
  615.  
  616.  
  617.  
  618. RARE Working Group on Network Applications Support (WG-NAP)    [Page 11]
  619.  
  620. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  621.  
  622.  
  623.       1.   The names should be meaningful.
  624.  
  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.
  629.  
  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
  638.    Services.
  639.  
  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
  650.    alternative values.
  651.  
  652. 3.4 Naming Human Users
  653.  
  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.
  665.  
  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
  671.  
  672.  
  673.  
  674. RARE Working Group on Network Applications Support (WG-NAP)    [Page 12]
  675.  
  676. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  677.  
  678.  
  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.
  685.  
  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!
  692.  
  693.    More details on the use of commonName in section 4.4.1.
  694.  
  695. 3.5 Application Entities
  696.  
  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).
  705.  
  706. 4. Attribute Values
  707.  
  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.
  711.  
  712.    The following sections give recommendations how to use them in X.500
  713.    pilot projects.
  714.  
  715. 4.1 Basic Attribute Syntaxes
  716.  
  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
  719.    syntaxes only.
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. RARE Working Group on Network Applications Support (WG-NAP)    [Page 13]
  731.  
  732. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  733.  
  734.  
  735. 4.1.1 Printable String
  736.  
  737.    This most simple syntax uses a subset of characters from ISO 646 IRV.
  738.  
  739.     A-Z   a-z   0-9   '     (     )     +
  740.  
  741.     ,     -     .     /     :     ?     space
  742.  
  743.     Tab 1: Characters in PrintableString
  744.  
  745. 4.1.2 IA5 String - T.50
  746.  
  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.
  751.  
  752. 4.1.3 Teletex String - T.61
  753.  
  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).
  759.  
  760. 4.1.4 Case Ignore String
  761.  
  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.
  766.  
  767. 4.1.5 Distinguished Name
  768.  
  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
  775.    search operations.
  776.  
  777. 4.2 Languages & Transliteration
  778.  
  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.
  783.  
  784.  
  785.  
  786. RARE Working Group on Network Applications Support (WG-NAP)    [Page 14]
  787.  
  788. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  789.  
  790.  
  791. 4.2.1 Languages other than English
  792.  
  793.    Many countries have more than one national language and a world-wide
  794.    Directory must be able to support non-English-speaking users.
  795.  
  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.
  799.  
  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.
  806.  
  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.
  810.  
  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.
  815.  
  816. 4.2.2 Transliteration
  817.  
  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.
  831.  
  832. 4.3 Access control
  833.  
  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
  839.  
  840.  
  841.  
  842. RARE Working Group on Network Applications Support (WG-NAP)    [Page 15]
  843.  
  844. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  845.  
  846.  
  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.
  851.  
  852. 4.4 Selected Attributes
  853.  
  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.
  857.  
  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]
  861.  
  862. 4.4.1 Personal Attributes
  863.  
  864.    commonName [X.520]
  865.  
  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.
  873.  
  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 "."
  882.       characters.
  883.  
  884.  
  885.          Format:    Firstname [Initials] Lastname
  886.  
  887.          Example:   Steve Kille
  888.  
  889.                     Stephen E. Kille
  890.  
  891.                     S.E. Kille
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. RARE Working Group on Network Applications Support (WG-NAP)    [Page 16]
  899.  
  900. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  901.  
  902.  
  903.       The use of 'Lastname Firstname' is deprecated as explained in
  904.       section 3.4.
  905.  
  906.    favouriteDrink [RFC 1274]
  907.  
  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.
  913.  
  914.       Example: Pure Crystal Water
  915.  
  916.    organizationalStatus [RFC 1274]
  917.  
  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.
  922.  
  923.       A Directory administrator should consider carefully the
  924.       distinctions between this and the title and description
  925.       attributes.
  926.  
  927.       Example: undergraduate student
  928.  
  929.    personalTitle [RFC 1274]
  930.  
  931.       The usually used titles, especially academic ones. Excessive use
  932.       should be avoided.
  933.  
  934.       Example: Prof. Dr.
  935.  
  936.    roomNumber [RFC 1274]
  937.  
  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.
  940.  
  941.       Example: HLW B12
  942.  
  943.    secretary [RFC 1274]
  944.  
  945.       The secretary of the person. This is the Distinguished Name (DN)
  946.       of the secretary.
  947.  
  948.       Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
  949.  
  950.  
  951.  
  952.  
  953.  
  954. RARE Working Group on Network Applications Support (WG-NAP)    [Page 17]
  955.  
  956. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  957.  
  958.  
  959.    surname [X.520]
  960.  
  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.
  963.  
  964.       Example: Kille
  965.  
  966.    title [X.520]
  967.  
  968.       Title describing the position, job title or function of an
  969.       organisational person.
  970.  
  971.       Example: Manager - International Sales
  972.  
  973.    userId [RFC 1274]
  974.  
  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.
  978.  
  979.       Example: skille
  980.  
  981.    userPassword [X.520]
  982.  
  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.
  988.  
  989.       Example: 8kiu8z7e
  990.  
  991. 4.4.2 Organisational Attributes
  992.  
  993.    associatedDomain [RFC 1274]
  994.  
  995.       The Internet domain name for an organisation or one of its units.
  996.  
  997.       Example: isode.com
  998.  
  999.    businessCategory [X.520]
  1000.  
  1001.       Type of business an organisation, an organisational unit or
  1002.       organisational person is involved in. The values could be chosen
  1003.       from a thesaurus.
  1004.  
  1005.       Example: Software Development
  1006.  
  1007.  
  1008.  
  1009.  
  1010. RARE Working Group on Network Applications Support (WG-NAP)    [Page 18]
  1011.  
  1012. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1013.  
  1014.  
  1015.    organizationName [X.520]
  1016.  
  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.
  1020.  
  1021.       Example:    Uni Lausanne
  1022.                   Universite de Lausanne
  1023.                   Universit\c2e Lausanne (with a T.61 encoded umlaut)
  1024.                   University of Lausanne
  1025.                  unil
  1026.  
  1027.    organizationalUnitName [X.520]
  1028.  
  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.
  1032.  
  1033.       Example:    Institut fuer Angewandte Mathematik
  1034.                   Mathematik
  1035.                   iam
  1036.  
  1037.    roleOccupant [X.520]
  1038.  
  1039.       The person(s) in that role. This is the Distinguished Name of the
  1040.       entry of the person(s).
  1041.  
  1042.       Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
  1043.  
  1044.    searchGuide [X.520]
  1045.  
  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
  1049.       configure it.
  1050.  
  1051. 4.4.3 Local Attributes
  1052.  
  1053.    localityName [X.520]
  1054.  
  1055.       Name of the place, village or town with values in local and other
  1056.       languages as useful.
  1057.  
  1058.       Example:    Bale
  1059.                   B\c3ale (with a T.61 encoded accented character) Basel
  1060.                   Basilea
  1061.                   Basle
  1062.  
  1063.  
  1064.  
  1065.  
  1066. RARE Working Group on Network Applications Support (WG-NAP)    [Page 19]
  1067.  
  1068. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1069.  
  1070.  
  1071.    stateOrProvinceName [X.520]
  1072.  
  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
  1077.  
  1078.       Example:    Ticino
  1079.                   Tessin
  1080.                   TI
  1081.  
  1082. 4.4.4 Miscellaneous Attributes
  1083.  
  1084.    audio [RFC 1274]
  1085.  
  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.
  1090.  
  1091.    description [X.520]
  1092.  
  1093.       A short informal explanation of special interests of a person or
  1094.       organisation. Overlap with businessCategory, organizationalStatus
  1095.       and title should be avoided.
  1096.  
  1097.       Example: Networking, distributed systems, OSI, implementation.
  1098.  
  1099.    friendlyCountryName [RFC 1274]
  1100.  
  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.
  1105.  
  1106.    jpegPhoto [RFC 1488] [8]
  1107.  
  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.
  1112.  
  1113.    photo [RFC 1274]
  1114.  
  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
  1118.       jpegPhoto.
  1119.  
  1120.  
  1121.  
  1122. RARE Working Group on Network Applications Support (WG-NAP)    [Page 20]
  1123.  
  1124. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1125.  
  1126.  
  1127.    seeAlso [X.520]
  1128.  
  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
  1131.       of the entry.
  1132.  
  1133.       Example: CN=Beverly Pyke, O=ISODE Consortium, C=GB
  1134.  
  1135. 4.4.5 MHS Attributes
  1136.  
  1137.    mhsORAddresses [X.411]
  1138.  
  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.
  1143.  
  1144.    rfc822mailbox [RFC 1274]
  1145.  
  1146.       E-Mail address in RFC 822 notation
  1147.  
  1148.       Example: s.kille@isode.com
  1149.  
  1150.    textEncodedORAddress [RFC 1274]
  1151.  
  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.
  1159.  
  1160.       Example:    G=thomas; S=lenggenhager; OU1=gate; O=switch; \
  1161.                   P=switch; A=arcom; C=ch;
  1162.  
  1163. 4.4.6 Postal Attributes
  1164.  
  1165.    postalAddress [X.520]
  1166.  
  1167.       The full postal address (but not including the name) in
  1168.       international notation, with up to 6 lines with 30 characters
  1169.       each.
  1170.  
  1171.       Example:    SWITCH
  1172.                   Limmatquai 13
  1173.                   CH-8001 Zurich
  1174.  
  1175.  
  1176.  
  1177.  
  1178. RARE Working Group on Network Applications Support (WG-NAP)    [Page 21]
  1179.  
  1180. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1181.  
  1182.  
  1183.    postalCode [X.520]
  1184.  
  1185.       The postalCode will be the same as used in the postalAddress (in
  1186.       international notation).
  1187.  
  1188.       Example: CH-8001
  1189.  
  1190.    streetAddress [X.520]
  1191.  
  1192.       It shall be the street where the person has its office. Mostly, it
  1193.       will be the street part of the postalAddress.
  1194.  
  1195.       Example: Limmatquai 138
  1196.  
  1197. 4.4.7 Telecom Attributes
  1198.  
  1199.    telephoneNumber, facsimileTelephoneNumber & iSDNAddress [X.520]
  1200.  
  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.
  1204.  
  1205.       Format: "+" <country code> <national number> ["x" <extension>]
  1206.       Example: +41 1 268 1540
  1207.  
  1208.    telexNumber [X.520]
  1209.  
  1210.       The telex number in the international notation
  1211.  
  1212.       Example: 817379, ch, ehhg
  1213.  
  1214. 5. Miscellany
  1215.  
  1216.    This section draws attention to two areas which frequently provoke
  1217.    questions, and where it is felt that a consistent approach will be
  1218.    useful.
  1219.  
  1220. 5.1 Schema consistency of aliases
  1221.  
  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'.
  1224.  
  1225.    The following two checks should be made:
  1226.  
  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.
  1230.  
  1231.  
  1232.  
  1233.  
  1234. RARE Working Group on Network Applications Support (WG-NAP)    [Page 22]
  1235.  
  1236. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1237.  
  1238.  
  1239.       2.   If the entry (aliased object) were placed where the alias
  1240.            is, there should be no schema violation.
  1241.  
  1242. 5.2 Organisational Units
  1243.  
  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.
  1251.  
  1252. 6. References
  1253.  
  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.
  1257.  
  1258.    [2] "The Directory --- Overview of concepts, models and services",
  1259.        CCITT X.500 Series Recommendations, December 1988.
  1260.  
  1261.    [3] The North American Directory Forum. "A Naming Scheme for C=US",
  1262.        RFC 1255, NADF-175, NADF, September 1991.
  1263.  
  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.
  1267.  
  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.
  1271.  
  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.
  1275.  
  1276.    [7] Jeunink, E., and E. Huizer, "Directory Services and Privacy
  1277.        Issues", RARE WG-DATMAN, TF-LEGAL, Work in Progress, May 1993.
  1278.  
  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.
  1283.  
  1284. 7. Security Considerations
  1285.  
  1286.    Security issues are not substantially discussed in this memo.
  1287.  
  1288.  
  1289.  
  1290. RARE Working Group on Network Applications Support (WG-NAP)    [Page 23]
  1291.  
  1292. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1293.  
  1294.  
  1295. 8. Authors' Addresses
  1296.  
  1297.    Paul Barker
  1298.    Department of Computer Science
  1299.    University College London
  1300.    Gower Street
  1301.    London WC1E 6BT
  1302.    England
  1303.  
  1304.    Phone: +44 71 380 7366
  1305.    EMail: p.barker@cs.ucl.ac.uk
  1306.  
  1307.    DN:  CN=Paul Barker, OU=Computer Science, O=University College
  1308.         London, C=GB
  1309.  
  1310.    UFN: Paul Barker, Computer Science, UCL, GB
  1311.  
  1312.  
  1313.    Steve Kille
  1314.    ISODE Consortium
  1315.    The Dome
  1316.    The Square
  1317.    Richmond TW9 1DT
  1318.    England
  1319.  
  1320.    Phone: +44 81 332 9091
  1321.    EMail: s.kille@isode.com
  1322.  
  1323.    DN:  CN=Steve Kille, O=ISODE Consortium, C=GB
  1324.  
  1325.    UFN: S. Kille, ISODE   Consortium, GB
  1326.  
  1327.  
  1328.    Thomas Lenggenhager
  1329.    SWITCH
  1330.    Limmatquai 138
  1331.    CH-8001 Zurich
  1332.    Switzerland
  1333.  
  1334.    Phone: +41 1 268 1540
  1335.    EMail: lenggenhager@switch.ch
  1336.  
  1337.    DN:  CN=Thomas Lenggenhager, O=SWITCH, C=CH
  1338.  
  1339.    UFN: Thomas Lenggenhager, SWITCH, CH
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346. RARE Working Group on Network Applications Support (WG-NAP)    [Page 24]
  1347.  
  1348. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1349.  
  1350.  
  1351. 9. Appendix - Example Entries
  1352.  
  1353. 9.1 Country
  1354.  
  1355.     DN: C=CH
  1356.  
  1357.     objectClass=top & country & domainRelatedObject & friendlyCountry
  1358.     country=CH
  1359.     associatedDomain=ch
  1360.     friendlyCountryName=CH
  1361.     friendlyCountryName=Confoederatio Helvetica
  1362.     friendlyCountryName=Schweiz
  1363.     friendlyCountryName=Suisse
  1364.     friendlyCountryName=Svizzera
  1365.     friendlyCountryName=Switzerland
  1366.  
  1367. 9.2 Organisation
  1368.  
  1369.     DN: O=SWITCH, C=CH
  1370.  
  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
  1378.     localityName=Zurich
  1379.     localityName={T.61}Z\c8urich
  1380.     stateOrProvinceName=ZH
  1381.     stateOrProvinceName=Zuerich
  1382.     stateOrProvinceName=Zurich
  1383.     stateOrProvinceName={T.61}Z\c8urich
  1384.     postalAddress=SWITCH
  1385.                   Limmatquai 138
  1386.                   CH-8001 Zurich
  1387.     postalCode=CH-8001
  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
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. RARE Working Group on Network Applications Support (WG-NAP)    [Page 25]
  1403.  
  1404. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1405.  
  1406.  
  1407. 9.3 Organisation Unit
  1408.  
  1409.     DN: OU=SWITCHdirectory, O=SWITCH, C=CH
  1410.  
  1411.     objectClass=top & organizationalUnit
  1412.     description=The SWITCH X.500 pilot project
  1413.     organizationalUnitName=SWITCHdirectory
  1414.     localityName=Zurich
  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
  1422.                   SWITCH
  1423.                   Limmatquai 138
  1424.                   CH-8001 Zurich
  1425.     postalCode=CH-8001
  1426.     streetAddress=Limmatquai 138
  1427.     telephoneNumber=+41 1 268 1540
  1428.     facsimileTelephoneNumber=+41 1 268 1568
  1429.  
  1430. 9.4 Organizational Role
  1431.  
  1432.     DN: CN=Directory Manager, O=SWITCH, C=CH
  1433.  
  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
  1440.     localityName=Zurich
  1441.     localityName={T.61}Z\c8urich
  1442.     stateOrProvinceName=Zurich
  1443.     stateOrProvinceName=Zuerich
  1444.     stateOrProvinceName=ZH
  1445.     stateOrProvinceName={T.61}Z\c8urich
  1446.     postalAddress=SWITCHdirectory
  1447.                   SWITCH
  1448.                   Limmatquai 138
  1449.                   CH-8001 Zurich
  1450.     postalCode=CH-8001
  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;
  1455.  
  1456.  
  1457.  
  1458. RARE Working Group on Network Applications Support (WG-NAP)    [Page 26]
  1459.  
  1460. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1461.  
  1462.  
  1463.     DN: CN=Postmaster, O=SWITCH, C=CH
  1464.  
  1465.     objectClass=top & organizationalRole & mhsUser
  1466.     commonName=Postmaster
  1467.     commonName=Helpdesk
  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;
  1475.  
  1476.     DN: CN=Secretary, O=SWITCH, C=CH
  1477.  
  1478.     objectClass=top & organizationalRole & quipuObject
  1479.     commonName=Secretary
  1480.     roleOccupant=CN=Franziska Remund, O=SWITCH, C=CH
  1481.  
  1482.  
  1483.  
  1484.  
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. RARE Working Group on Network Applications Support (WG-NAP)    [Page 27]
  1515.  
  1516. RFC 1617      Naming and Structuring Guidelines for X.500       May 1994
  1517.  
  1518.  
  1519. 9.5 Person
  1520.  
  1521.     DN: CN=Thomas Lenggenhager, O=SWITCH, C=CH
  1522.  
  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
  1530.     localityName=Zurich
  1531.     localityName={T.61}Z\c8urich
  1532.     stateOrProvinceName=ZH
  1533.     stateOrProvinceName=Zuerich
  1534.     stateOrProvinceName=Zurich
  1535.     stateOrProvinceName={T.61}Z\c8urich
  1536.     postalAddress=SWITCH
  1537.                   Limmatquai 138
  1538.                   CH-8001 Zurich
  1539.     postalCode=CH-8001
  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;
  1544.     userPassword=secret
  1545.     textEncodedORaddress={T.61}S=lenggenhager; O=switch; P=switch; \
  1546.                                   A=arcom; C=ch;
  1547.     rfc822mailbox=lenggenhager@switch.ch
  1548.     secretary=CN=Franziska Remund, O=SWITCH, C=CH
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570. RARE Working Group on Network Applications Support (WG-NAP)    [Page 28]
  1571.  
  1572.