doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc1384.txt b/doc/rfc/rfc1384.txt
new file mode 100644
index 0000000..4ca13c5
--- /dev/null
+++ b/doc/rfc/rfc1384.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          P. Barker
+Requests for Comments 1384                     University College London
+                                                   S.E. Hardcastle-Kille
+                                                        ISODE Consortium
+                                                            January 1993
+
+
+                 Naming Guidelines for Directory Pilots
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   Deployment of a Directory will benefit from following certain
+   guidelines.  This document defines a number of naming guidelines.
+   Alignment to these guidelines is recommended for directory pilots.
+
+1  Introduction
+
+   As a pre-requisite to this document, it is assumed that the COSINE
+   and Internet X.500 Schema is followed [1].
+
+2  DIT structure
+
+   The majority of this document is concerned with DIT structure and
+   naming for organisations, organisational units and personal entries.
+   This section briefly notes three other key issues.
+
+2.1  The top level of the DIT
+
+   The following information will be present at the top level of the
+   DIT:
+
+   Participating Countries
+      The entries should contain suitable values of the "Friendly
+      Country" attribute.
+
+   International Organisations
+      An international organisation is an organisation, such as the
+      United Nations, which inherently has a brief and scope covering
+      many nations.  Such organisations might be considered to be
+      supra-national and this, indeed, is the raison-d'etre of such
+      organisations.  Such organisations will almost all be governmental
+      or quasi-governmental.  A multi-national organisation is an
+
+
+
+Barker & Hardcastle-Kille                                       [Page 1]
+
+RFC 1384                   Naming Guidelines                January 1993
+
+
+      organisation which operates in more than one country, but is not
+      supra-national.  This classification includes the large commercial
+      organisations whose production and sales are spread throughout a
+      large number of countries.
+
+      International organisations, may be registered at the top level.
+      This will not be done for multi-national organisations.  The only
+      international organisation registered so far is:  Internet.  This
+      is not a formal registration, but is adopted for the Internet
+      Directory Service.
+
+   Localities
+      A few localities will be registered under the root.  The chief
+      purpose of these locality entries is to provide a "natural" parent
+      node for organisations which are supra-national, and yet which do
+      not have global authority in their particular field.  Such
+      organisations will usually be governmental or quasi-governmental.
+      Example localities might include: Europe, Africa, West Indies.
+      Example organisations within Europe might include: European Court
+      of Justice, European Space Agency, European Commission.
+
+   DSA Information
+      Some information on DSAs may be needed at the top level.  This
+      should be kept to a minimum.
+
+   The only directory information for which there is a recognised top
+   level registration authority is countries.  Registration of other
+   information at the top level may potentially cause problems.  At this
+   stage, it is argued that the benefits of additional top level
+   registration outweighs these problems.  However, this potential
+   problem should be noted by anyone making use of such a registration.
+
+2.2  The DNS within the DIT
+
+   The rules for the DNS parts of the DIT are defined in [3].  One
+   modification to this is that the DNS tree will be rooted under
+   "O=Internet", rather than at the root of the DIT.
+
+2.3  Access control
+
+   An entry's object class attribute, and any attribute(s) used for
+   naming an entry are of special significance and may be considered to
+   be "structural".  Any inability to access these attributes will often
+   militate against successful querying of the Directory.  For example,
+   user interfaces typically limit the scope of their searches by
+   searching for entries of a particular type, where the type of entry
+   is indicated by its object class.  Thus, unless the intention is to
+   bar public access to an entry or set of entries, the object class and
+
+
+
+Barker & Hardcastle-Kille                                       [Page 2]
+
+RFC 1384                   Naming Guidelines                January 1993
+
+
+   naming attributes should be publicly readable.
+
+3  Naming Style
+
+   The first goal of naming is to provide unique identifiers for
+   entries.  Once this is achieve, the next major goal in naming entries
+   should be to facilitate querying of the Directory.  In particular,
+   support for a naming structure which facilitates use of user friendly
+   naming is desirable.  Other considerations, such as accurately
+   reflecting the organisational structure of an organisation, should be
+   disregarded if this has an adverse effect on normal querying.  Early
+   experience in the pilot has shown that a consistent approach to
+   structure and naming is an aid to querying using a wide range of user
+   interfaces, as interfaces are often optimised for DIT structures
+   which appear prevalent.
+
+   Naming is dependent on a number of factors and these are now
+   considered in turn.
+
+3.1  National Guidelines
+
+   Where naming is being done in a country which has established
+   guidelines for naming, these guidelines should in general be
+   followed.  These guidelines might be based on an established
+   registration authority, or may make use use of an existing
+   registration mechanism (e.g., company name registration).
+
+   Where an organisation has a name which is nationally registered in an
+   existing registry, this name is likely to be appropriate for use in
+   the Directory, even in cases where there are no national guidelines.
+
+3.2  Structure Rules
+
+   A DIT structure is suggested in Annex B of X.521, and it is
+   recommended that Directory Pilots should follow a slightly modified
+   form of these guidelines.  The rules should be extended for handling
+   DNS [3].  Some simple restrictions should be applied, as described
+   below.
+
+   For most countries pilots, the following simple structure should
+   suffice.  The country entry will appear immediately beneath the root
+   of the tree.  Organisations which have national significance should
+   have entries immediately beneath their respective country entries.
+   Smaller organisations which are only known in a particular locality
+   should be placed underneath locality entries representing states or
+   similar geographical divisions.  Large organisations will probably
+   need to be sub-divided by organisational units to help in the
+   disambiguation of entries for people with common names.  Entries for
+
+
+
+Barker & Hardcastle-Kille                                       [Page 3]
+
+RFC 1384                   Naming Guidelines                January 1993
+
+
+   people and roles will be stored beneath organisations or
+   organisational units.  An example plan evolving for the US is the
+   work of the North American Directory Forum [2].
+
+   As noted above, there will be a few exceptions to this basic
+   structure.  International organisations will be stored immediately
+   under the root of the tree.  Multi-national organisations will be
+   stored within the framework outlined, but with some use of aliases
+   and attributes such as seeAlso to help bind together the constituent
+   parts of these organisations.  This is discussed in more detail
+   later.
+
+3.3  Depth of tree
+
+   The broad recommendation is that the DIT should be as flat as
+   possible.  A flat tree means that Directory names will be relatively
+   short, and probably somewhat similar in length and component
+   structure to paper mail addresses.  A deep DIT would imply long
+   Directory names, with somewhat arbitrary component parts, with a
+   result which it is argued seems less natural.  Any artificiality in
+   the choice of names militates against successful querying.
+
+   A presumption behind this style of naming is that most querying will
+   be supported by the user specifying convenient strings of characters
+   which will be mapped onto powerful search operations.  The
+   alternative approach of the user browsing their way down the tree and
+   selecting names from large numbers of possibilities may be more
+   appropriate in some cases, and a deeper tree facilitates this.
+   However, these guidelines recommend a shallow tree, and implicitly a
+   search oriented approach.
+
+   It may be considered that there are two determinants of DIT depth:
+   first, how far down the DIT an organisation is placed; second, the
+   structure of the DIT within organisations.
+
+   The structure of the upper levels of the tree will be determined in
+   due course by various registration authorities, and the pilot will
+   have to work within the given structure.  However, it is important
+   that the various pilots are cognisant of what the structures are
+   likely to be, and move early to adopt these structures.
+
+   The other principal determinant of DIT depth is whether an
+   organisation splits its entries over a number of organisational
+   units, and if so, the number of levels.  The recommendation here is
+   that this sub-division of organisations is kept to a minimum.  A
+   maximum of two levels of organisational unit should suffice even for
+   large organisations.  Organisations with only a few tens or hundreds
+   of employees should strongly consider not using organisational units
+
+
+
+Barker & Hardcastle-Kille                                       [Page 4]
+
+RFC 1384                   Naming Guidelines                January 1993
+
+
+   at all.  It is noted that there may be some problems with choice of
+   unique RDNs when using a flat DIT structure.  Multiple value RDNs can
+   alleviate this problem.  The standard recommends that an
+   organizationalUnitName attribute can also be used as a naming
+   attribute to disambiguate entries.  Further disambiguation may be
+   achieved by the use of a personalTitle attribute in the RDN.
+
+3.4  Organisation and Organisational Unit Names
+
+   The naming of organisations in the Directory will ultimately come
+   under the jurisdiction of official naming authorities.  In the
+   interim, it is recommended that pilots and organisations follow these
+   guidelines.  An organisation's RDN should usually be the full name of
+   the organisation, rather than just a set of initials.  This means
+   that University College London should be preferred over UCL. An
+   example of the problems which a short name might cause is given by
+   the proposed registration of AA for the Automobile Association.  This
+   seems reasonable at first glance, as the Automobile Association is
+   well known by this acronym.  However, it seems less reasonable in a
+   broader perspective when you consider organisations such as
+   Alcoholics Anonymous and American Airlines which use the same
+   acronym.  Just as initials should usually be avoided for
+   organisational RDNs, so should formal names which, for example, exist
+   only on official charters and are not generally well known.  There
+   are two reasons for this approach:
+
+   1.  The names should be meaningful.
+
+   2.  The names should uniquely identify the organisation, and be a
+       name which is unlikely to be challenged in an open registration
+       process.  For example, UCL might well be challenged by United
+       Carriers Ltd.
+
+   The same arguments on naming style can be applied with even greater
+   force to the choice of RDNs for organisational units.  While
+   abbreviated names will be in common parlance within an organisation,
+   they will almost always be meaningless outside of that organisation.
+   While many people in academic computing habitually refer to CS when
+   thinking of Computer Science, CS may be given several different
+   interpretations.  It could equally be interpreted as Computing
+   Services, Cognitive Science, Clinical Science or even Counselling
+   Services.
+
+   For both organisations and organisational units, extra naming
+   information should be stored in the directory as alternative values
+   of the naming attribute.  Thus, for University College London, UCL
+   should be stored as an alternative organizationName attribute value.
+   Similarly CS could be stored as an alternative organizationalUnitName
+
+
+
+Barker & Hardcastle-Kille                                       [Page 5]
+
+RFC 1384                   Naming Guidelines                January 1993
+
+
+   value for Computer Science and any of the other departments cited
+   earlier.  In general, entries will be located by searching, and so it
+   is not essential to have names which are either memorable or
+   guessable.  Minimising of typing may be achieved by use of carefully
+   selected alternate values.
+
+3.5  Naming human users
+
+   A reasonably consistent approach to naming people is particularly
+   critical as a large percentage of directory usage will be looking up
+   information about people.  User interfaces will be better able to
+   assist users if entries have names conforming to a common format, or
+   small group of formats.  It is suggested that the RDN should follow
+   such a format.  Alternative values of the common name attribute
+   should be used to store extra naming information.  It seems sensible
+   to try to ensure that the RDN commonName value is genuinely the most
+   common name for a person as it is likely that user interfaces may
+   choose to place greater weight on matches on the RDN than on matches
+   on one of the alternative names.  It is proposed that pilots should
+   ignore the standard's recommendations on storing personal titles, and
+   letters indicating academic and professional qualifications within
+   the commonName attribute, as this overloads the commonName attribute.
+   A personalTitle attribute has already been specified in the COSINE
+   and Internet Schema, and another attribute could be specified for
+   information about qualifications.
+
+   Furthermore, the common name attribute should not be used to hold
+   other attribute information such as telephone numbers, room numbers,
+   or local codes.  Such information should be stored within the
+   appropriate attributes as defined in the COSINE and Internet X.500
+   Schema.  If such attributes have to be used to disambiguate entries,
+   multi-valued RDNs should be used, such that other attribute(s) be
+   used for naming in addition to a common name.
+
+   The choice of RDN for humans will be influenced by cultural
+   considerations.  In many countries the best choice will be of the
+   form familiar-first-name surname.  Thus, Steve Hardcastle-Kille is
+   preferred as the RDN choice for one of this document's co-authors,
+   while Stephen E. Hardcastle-Kille is stored as an alternative
+   commonName value.  Sets of initials should not be concatenated into a
+   single "word", but be separated by spaces and/or "." characters.
+   Pragmatic choices will have to be made for other cultures.
+
+3.6  Application Entities
+
+   The guidelines of X.521 should be followed, in that the application
+   entity should always be named relative to an Organisation or
+   Organisational Unit.  The application process will often correspond
+
+
+
+Barker & Hardcastle-Kille                                       [Page 6]
+
+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:+44-71-380-7366
+
+
+       EMail:  P.Barker@CS.UCL.AC.UK
+
+       Steve Hardcastle-Kille
+       ISODE Consortium
+       P.O. Box 505
+       London
+       SW11 1DX
+       England
+
+
+       Phone:+44-71-223-4062
+
+
+       EMail:  S.Kille@ISODE.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barker & Hardcastle-Kille                                      [Page 12]
+
\ No newline at end of file