rfc1384.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 675 行 · 第 1/2 页


RFC 1384                   Naming Guidelines                January 1993


   to a system or host.  In this case, the application entities should
   be named by Common Names which identify the service (e.g., "FTAM
   Service").  In cases where there is no useful distinction between
   application process and application entity, the application process
   may be omitted (This is often done for DSAs in the current pilot).

4  Multinational Organisations

   The standard says that only international organisations may be placed
   under the root of the DIT. This implies that multi-national
   organisations must be represented as a number of separate entries
   underneath country or locality entries.  This structure makes it more
   awkward to use X.500 within a multi-national to provide an internal
   organisational directory, as the data is now spread widely throughout
   the DIT, rather than all being grouped within a single sub-tree.
   Many people have expressed the view that this restriction is a severe
   limitation of X.500, and argue that the intentions of the standard
   should be ignored in this respect.  This note argues, though, that
   the standard should be followed.

   No attempt to precisely define multinational organisation is essayed
   here.  Instead, the observation is made that the term is applied to a
   variety of organisational structures, where an organisation operates
   in more than one country.  This suggests that a variety of DIT
   structures may be appropriate to accommodate these different
   organisational structures.  This document suggests three approaches,
   and notes some of the characteristics associated with each of these
   approaches.

   Before considering the approaches, it is worth bearing in mind again
   that a major aim in the choice of a DIT structure is to facilitate
   querying, and that approaches which militate against this should be
   avoided wherever possible.


















Barker & Hardcastle-Kille                                       [Page 7]

RFC 1384                   Naming Guidelines                January 1993


4.1  The multi-national as a single entity


                             ROOT
                           /  |  \
                          /   |   \
                       C=GB  C=FR  C=US
                      /       |        \
                     /        |         \
           O=MultiNat---->O=MultiNat<----O=MultiNat
                          /    |   \
                         /     |    \
                        /      |     \
                   l=abc    ou=def    l=fgi


---> means "alias to"

           Figure 1:  The multi-national as a single entity


   In many cases, a multi-national organisation will operate with a
   highly centralised structure.  While the organisation may have large
   operations in a number of countries, the organisation is strongly
   controlled from the centre and the disparate parts of the
   organisation exist only as limbs of the main organisation.  In such a
   situation, the model shown in figure 1 may be the best choice.  The
   organisation's entries all exist under a single sub-tree.  The
   organisational structure beneath the organisation entry should
   reflect the perceived structure of the organisation, and so no
   recommendations on this matter can be made here.  To assist the
   person querying the directory, alias entries should be created for
   all countries where the organisation operates.

4.2  The multi-national as a loose confederation

   Another common model of organisational structure is that where a
   multi-national consists of a number of national entities, which are
   in large part independent of both sibling national entities, and of
   any central entity.  In such cases, the model shown in Figure 2 may
   be a










Barker & Hardcastle-Kille                                       [Page 8]

RFC 1384                   Naming Guidelines                January 1993


                             ROOT
                           /  |  \
                          /   |   \
                       C=GB  C=FR  C=US
                      /       |        \
                     /        |         \
           O=MultiNat     O=MultiNat     O=MultiNat
          /    |          /    |   \          |    \
         /     |         /     |    \         |     \
       L=GB   L=FR      /      |     \       L=FR   L=US
                      L=GB    L=FR  L=US


---> means "alias to"


        Figure 2:  The multi-national as a loose confederation


   better choice.  Organisational entries exist within each country, and
   only that country's localities and organisational units appear
   directly beneath the appropriate organisational entry.  Some binding
   together of the various parts of the organisation can be achieved by
   the use of aliases for localities and organisational units, and this
   can be done in a highly flexible fashion.  In some cases, the
   national view might not contain all branches of the company, as
   illustrated in Figure 2.

4.3  Loosely linked DIT sub-trees


   A third approach is to avoid aliasing altogether, and to use the
   looser binding provided by an attribute such as seeAlso.  This
   approach treats all parts of an organisation as essentially separate.

   A unified view of the organisation can only be achieved by user
   interfaces choosing to follow the seeAlso links.  This is a key
   difference with aliasing, where decisions to follow links may be
   specified within the protocol.  (Note that it may be better to
   specify another attribute for this purpose, as seeAlso is likely to
   be used for a wide variety of purposes.)

4.4  Summary of advantages and disadvantages of the above approaches

   Providing an internal directory
      All the above methods can be used to provide an internal
      directory.  In the first two cases, the linkage to other parts of
      the organisation can be followed by the protocol and thus



Barker & Hardcastle-Kille                                       [Page 9]

RFC 1384                   Naming Guidelines                January 1993


      organisation-wide searches can be achieved by single X.500
      operations.  In the last case, interfaces would have to "know" to
      follow the soft links indicated by the seeAlso attribute.

   Impact on naming
      In the single-entity model, all DNs within the organisation will
      be under one country.  It could be argued that this will often
      result in rather "unnatural" naming.  In the loose-confederation
      model, DNs are more natural, although the need to disambiguate
      between organisational units and localities on an international,
      rather than just a national, basis may have some impact on the
      choice of names.  For example, it may be necessary to add in an
      extra level of organisational unit or locality information.  In
      the loosely-linked model, there is no impact on naming at all.

   Views of the organisation
      The first method provides a unique view of the organisation.  The
      loose confederacy allows for a variety of views of the
      organisation.  The view from the centre of the organisation may
      well be that all constituent organisations should be seen as part
      of the main organisation, whereas other parts of the organisation
      may only be interested in the organisation's centre and a few of
      its sibling organisations.  The third model gives an equally
      flexible view of organisational structures.

   Lookup performance
      All methods should perform reasonably well, providing information
      is held, or at least replicated, within a single DSA.

5  Miscellany

   This section draws attention to two areas which frequently provoke
   questions, and where it is felt that a consistent approach will be
   useful.

5.1  Schema consistency of aliases

   According to the letter of the standard, an alias may point at any
   entry.  It is beneficial for aliases to be ``schema consistent''.
   The following two checks should be made:

   1.  The Relative Distinguished Name of the alias should be a valid
       Relative Distinguished Name of the entry.

   2.  If the entry (aliased object) were placed where the alias is,
       there should be no schema violation.





Barker & Hardcastle-Kille                                      [Page 10]

RFC 1384                   Naming Guidelines                January 1993


5.2  Organisational Units

   There is a problem that many organisations can be either
   organisations or organisational units, dependent on the location in
   the DIT (with aliases giving the alternate names).  For example, an
   organisation may be an independent national organisation and also an
   organisational unit of a parent organisation.  To achieve this, it is
   important to allow an entry to be of both object class organisation
   and of object class organisational unit.

References

   [1] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet
       X.500 schema. Request for Comments RFC 1274, Department of
       Computer Science, University College London, November 1991.

   [2] The North American Directory Forum.  A Naming Scheme for C=US,
       September 1991. Also NADF-175.

   [3] S.E. Hardcastle-Kille. X.500 and domains.  Request for Comments
       RFC 1279, Department of Computer Science, University College
       London, November 1991.

6  Security Considerations

   Security issues are not discussed in this memo.

























Barker & Hardcastle-Kille                                      [Page 11]

RFC 1384                   Naming Guidelines                January 1993


7  Authors' Addresses

       Paul Barker
       Department of Computer Science
       University College London
       Gower Street
       WC1E 6BT
       England

       Phone:[phone]


       EMail:  [e-mail]

       Steve Hardcastle-Kille
       ISODE Consortium
       P.O. Box 505
       London
       SW11 1DX
       England


       Phone:[phone]


       EMail:  [e-mail]

























Barker & Hardcastle-Kille                                      [Page 12]