doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1684.txt b/doc/rfc/rfc1684.txt
new file mode 100644
index 0000000..139c8da
--- /dev/null
+++ b/doc/rfc/rfc1684.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                            P. Jurg
+Request for Comments: 1684                                    SURFnet bv
+Category: Informational                                      August 1994
+
+
+          Introduction to White Pages Services based on X.500
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document aims at organisations who are using local and global
+   electronic communication on a day to day basis and for whom using an
+   electronic White Pages Service is therefore indispensable.
+
+   The document provides an introduction to the international ITU-T
+   (formerly CCITT) X.500 and ISO 9594 standard, which is particularly
+   suited for providing an integrated local and global electronic White
+   Pages Service.
+
+   In addition a short overview of the experience gained from the
+   Paradise X.500 pilot is given. References to more detailed
+   information are included.
+
+   The document should be useful for managers of the above mentioned
+   organisations who need to get the necessary executive commitment for
+   making the address information of their organisation available by
+   means of X.500.
+
+Table Of Contents
+
+   1. Introduction ................................................  2
+   2. Concept of X.500 ............................................  3
+     2.1  Directory Model .........................................  3
+     2.2  Information Model .......................................  4
+   3.  Benefits of X.500 ..........................................  5
+   4.  Organisational aspects of X.500(experience from Paradise) ..  6
+   5.  Applications of X.500 ......................................  8
+   6.  References .................................................  9
+   7.  Security Considerations .................................... 10
+   8.  Author's Address ........................................... 10
+
+
+
+
+
+
+RARE Working Group on Network Applications Support              [Page 1]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+1. Introduction
+
+   Due to the tremendous growth and development of international
+   computer networks we have nowadays the possibility to overcome -
+   without having to travel - geographical distances when working
+   together with other people. Besides the possibility of using the
+   telephone we may use electronic data exchange to discuss working
+   documents, new ideas, plans or whatsoever. One of the most popular
+   means for this is electronic mail, which can be used to exchange
+   all kinds of electronic data: from informal pure text messages to
+   formatted and multi-media documents.
+
+   As the number of people connected to computer networks grows (and
+   it does continuously, it is at least doubling each year!), it
+   becomes more difficult to track down people's electronic (mail)
+   addresses. Hence, in order to make global communication over
+   computer networks work, a global White Pages service is
+   indispensable. Such a service should of course provide people's
+   electronic mail addresses, but could also easily contain telephone
+   and fax numbers and postal addresses.
+
+   Currently, one technical solution for a globally distributed
+   White Pages service is X.500 and there exists an international
+   infrastructure based on X.500 technology called 'Paradise'
+   (Piloting An inteRnationAl DIrectory SErvice), which contains about
+   1.5 million entries belonging to persons and 3,000 belonging to
+   organisations. Worldwide 35 countries are involved. Paradise is
+   also a project of the EC. The project continues until September
+   1994. Afterwards its operational tasks will be taken over by a
+   European service provider for the R&D community (DANTE).
+
+   The goal of Paradise and related national initiatives is to
+   stimulate and extend the use of the X.500 White Pages service.
+   Within the pilot attention is paid to technical and organisational
+   aspects. The Paradise infrastructure is mainly based on the
+   Internet Protocol. The specific issues that are related to the use
+   of the Internet Protocol for X.500 can be found in [5].
+
+   In the decision process of joining the international X.500
+   infrastructure and opening (part) of the local (address)
+   information to the outside world, it is important that an
+   organisation fully understands the technical and organisational
+   issues that are involved.
+
+   This document tries to be of help in this matter first by
+   explaining the main concepts of X.500 (section 2) and subsequently
+   by pointing out its benefits (section 3), the organisational
+   aspects that are involved (section 4), and for which other
+
+
+
+RARE Working Group on Network Applications Support              [Page 2]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   applications the X.500 infrastructure may be used in the near
+   future (section 5).
+
+2. Concept of X.500
+
+   The X.500 standard describes a so-called 'Directory Service', which
+   can be used for all types of electronic directories. This document
+   focusses on the use of X.500 for a global White Pages Directory.
+   The concept of X.500 may roughly be divided in the 'Directory
+   model' and the 'Information model'.
+
+   2.1  Directory model
+
+   X.500 uses a distributed approach to achieve the goal of a global
+   Directory Service. The idea is that local (communication oriented)
+   information of an organisation is maintained locally in one or more
+   so called Directory System Agents (DSA's). 'Locally' is a flexible
+   expression here: it is possible that one DSA keeps information of
+   more than one organisation. A DSA essentially is a database:
+
+      - in which the information is stored according to the X.500
+        standard (see section 2.2),
+
+      - that has the ability, where necessary, to exchange data
+        with other DSA's.
+
+   Through the communication among each other the DSA's form the
+   Directory Information Tree (DIT). The DIT is a virtual hierarchical
+   datastructure consisting of a 'root', below which 'countries' are
+   defined. Below the countries (usually) 'organisations' are defined,
+   and below an organisation 'persons', or first additional
+   'organisational units', are defined (see the simplified illustration
+   below where only three countries and no organisational units are
+   presented). The DIT is a representation of the global Directory.
+
+             root                      o
+                                      /|\
+                                     / | \
+                                    /  |  \
+             countries            uk   de  fr
+                                 / |   /\   |\
+                                /  |  /  \  | \
+             organisations     a   b c    d e  f
+                               |   | |    | |  |
+             persons          ..  .. ...  .... ...
+
+
+
+
+
+
+RARE Working Group on Network Applications Support              [Page 3]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   Each DSA holds a part of the global Directory and is able to find
+   out, through the hierarchical DIT structure, which DSA holds which
+   parts of the Directory.
+
+   The standard does not describe how to distribute different part of
+   the Directory among DSA's. However, the information corresponding to
+   a single node of the DIT (i.e., a country, organisation, person)
+   cannot be distributed over several DSA's. In practice a large
+   organisation will maintain one or more DSA's that hold its part of
+   the Directory. Smaller organisations may share a DSA with other
+   organisations.The distribution among the DSA's is totally transparent
+   to the users of the Directory.
+
+   A user of the Directory can be a person or a computer. A user
+   accesses the Directory through a so-called Directory User Agent
+   (DUA). The DUA automatically contacts a nearby DSA by means of which
+   the user may search or browse through the DIT and retrieve
+   corresponding information. A DUA can be implemented in all sorts of
+   user interfaces. Therefore users may access the Directory through
+   dedicated DUA interfaces or for example e-mail applications.
+   Currently most DUA nterfaces to be used by persons are dedicated, but
+   it is expected that in the near future a lot of DUA interfaces will
+   be integrated with other applications.
+
+2.2 Information Model
+
+   Besides the Directory model, the X.500 standard also defines the
+   information model used in the Directory Service.
+
+   All information in the Directory is stored in 'entries', each of
+   which belongs to at least one so-called 'object class'. In the White
+   Pages application of X.500, on which we focus here, object classes
+   are defined such as 'country', 'organisation', 'organisational unit'
+   and 'person'.
+
+   The actual information in an entry is determined by so-called
+   'attributes' which are contained in that entry. The object classes to
+   which an entry belongs define what types of attributes an entry may
+   use and hence what information is specific for entries belonging to
+   that object class. The object class 'person' for example allows
+   attribute types like 'common name', 'telephone number', and 'e-mail
+   address' to be used and the object class 'organisation' allows for
+   attribute types like 'organisation name' and 'business category'.
+   Dependent on its type an attribute can take one or more values.
+
+   To specify the name of an entry in the DIT, at least one attribute
+   value of the entry is used. The entry of a person is usually named
+   after the value of the attribute type 'common name'. The name of an
+
+
+
+RARE Working Group on Network Applications Support              [Page 4]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   entry must be unique on the same level in the subtree of the DIT to
+   which the entry belongs.
+
+   An example of an entry belonging to the object class 'person' is:
+
+       Attribute type              Attribute value
+       --------------              --------------
+
+       Object Class:               top
+                                   person
+       Common Name:                Thomas Lenggenhager
+                                   T. Lenggenhager
+       Surname:                    Lenggenhager
+       Postal Address:             SWITCH
+                                   Limmatquai 138
+                                   CH-8001 Zuerich
+       Telephone Number:           +41 1 268 1540
+       Facsimile Telephone Number: +41 1 268 1568
+       Mail:                       lenggenhager@switch.ch
+
+   This entry corresponds to the node in the DIT that occurs below the
+   node of the organisation 'SWITCH' and is named after the first value
+   of the attribute type 'common name': 'Thomas Lenggenhager'.
+
+3.  Benefits of X.500
+
+   Why should one use X.500 for a local White Pages service? Here are
+   some good arguments:
+
+      - The distributed character of the service. A large
+        organisation may distribute the responsibility for the
+        management of the information it presents through X.500 by
+        distributing this information over several DSA's (without
+        losing the overall structure)
+
+      - The flexibility of the service. Besides for public purposes,
+        X.500 may also be used for specific private Directory Service
+        applications. Whereas the definitions of the DIT, object
+        classes and attribute types of the public White Pages
+        information within an organisation have to conform to those
+        of the rest of world, the internal applications may use their
+        own DIT structure and their own definitions of object classes
+        and attributes (the values being only visible within (a part)
+        of the organisation). Nevertheless one local infrastructure
+        can be used for both the public and private computers.
+
+
+
+
+
+
+RARE Working Group on Network Applications Support              [Page 5]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+      - Good alternative for paper Directories. The provision of
+        White Pages services based on X.500 may be a good alternative
+        for paper directories, because the latter directories are
+        rarely up-to-date (due to the printing costs) and because
+        X.500 not only can be used by humans but also by
+        applications.
+
+   Some important arguments in favour of X.500 for global use are:
+
+      - By its distributed nature X.500 is particularly suited for a
+        large global White Pages directory. Maintenance can take
+        place in a distributed way.
+
+      - Good searching capabilities. X.500 offers the possibility to
+        do searches in any level or in any subtree of the DIT. In
+        order to do a search an attribute type together with a value
+        have to be specified. Then the Directory searches for all
+        entries that contain an attribute of that type with the given
+        value. For example one can search for all persons in an
+        organisation having a particular common name, or all
+        organisations within a country that have telecommunications
+        as their business category. It is up to the organisations
+        that maintain the DSA's to decide who may perform which
+        searches and also how many levels deep a search may be.
+
+        Searches can be done on the basis of an exact or approximate
+        match. It is worthwile to note that distributed searches
+        (that need connections to a lot of DSA's) may be expensive
+        and are generally not encouraged.
+
+      - There are DUA interfaces for the White Pages service
+        availablefor all types of workstations (DOS, Macintosh OS,
+        Unix). For an overview of X.500 available software see
+        RFC 1292 [2] or updates of this document.
+
+      - X.500 is an international standard. Using a standard
+        obviously means less problems with interoperability and
+        interworking.Also the standard is updated according to
+        practical experience.
+
+4.  Organisational aspects of X.500 (experience from Paradise)
+
+   The organisational aspects involved in operating a local X.500 (or
+   any other electronic) Directory can roughly be divided in   three
+   sub-aspects:datamanagement, legal issues and cost aspects. With
+   respect to cost aspects there is no publicly known model or
+   experience at the moment.
+
+
+
+
+RARE Working Group on Network Applications Support              [Page 6]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   Therefore the focus in this document is on datamanagement and legal
+   issues.
+
+   Data management refers to issues that are related to inserting
+   appropriate information into the Directory and keeping it up to date.
+
+   From the experience of participants in Paradise we obtain that the
+   following items are of first importance:
+
+      - Executive commitment. Without this it is almost impossible to
+        create an organisation wide up-to-date electronic Directory.
+
+      - Structure of the local DIT. In joining the international
+        infrastructure an organisation has to conform to some rules
+        for the local DIT structure as presented to the global X.500
+        infrastructure. A recommendation on how to structure a local
+        DIT and how to use the available attributes can be found in
+        [7]. The most important recommendation in the latter document
+        is to keep the local part of the DIT as simple (flat) as
+        possible. The reason is that users from outside the
+        organisation may otherwise have difficulties in finding
+        entries of persons within the organisation (searches in the
+        DIT are often only allowed one level deep).
+
+      - Attributes to be used. For the existing infrastructure the
+        objects and associated attributes that are globally used, are
+        documented in [1].
+
+      - Sources of the data. An organisation has to find out where to
+        get what kind of data and develop procedures for uploading
+        its DSA('s).
+
+      - Delegating responsibilities for updates. Procedures have to
+        bedeveloped for updates of the local Directory. These
+        procedures have to include delegation of responsibilities.
+
+      - Security procedures. Rules have to be set for access and
+        security. Who may contact the DSA? Who will have access to
+        which subtrees and what attributes?
+
+   A study of the legal consequences of presenting (address) information
+   via X.500 lead to the main conclusion that in Europe an organisation
+   has to formally register its data collections.  Registration implies
+   defining a goal for the application. This has to be done for the
+   White Pages service as well as for any deviating local application of
+   X.500. However, the different national laws may differ with respect
+   to legal restrictions. For more information on this subject we refer
+   to "Building a Directory Service, Final Report test phase SURFnet
+
+
+
+RARE Working Group on Network Applications Support              [Page 7]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   X.500 pilot project", E.  Huizer, SURFnet B.V., Utrecht NL, 1994.
+   (copies available from SURFnet B.V.)
+
+   Among the Paradise members there are several pilots running at the
+   moment with the goal to evaluate the organisational aspects. Case
+   studies coming from these pilots will be documented.
+
+   Small or medium size organisations that have not too many entries to
+   insert in the Directory may use one of the different national
+   initiatives concerning a 'central DSA'. These central DSA's are
+   operated by national service providers and contain the White Pages
+   information of a lot of small and medium size organisations. For
+   organisations in countries without such a national service there is
+   also a European central DSA (Paradise) and an American central DSA
+   (InterNIC). It is worth noting that the central DSA services are only
+   technical services, i.e., a participating organisation still has to
+   cover the organisational issues. However, part of a central DSA
+   service may be consultancy with respect to datamanagement and legal
+   issues.
+
+5.  Applications of X.500
+
+   Besides for White Pages, X.500 can be useful for all kinds of
+   distributed information storage from which humans or machines can
+   benefit. Examples that are likely to use X.500 in the near future
+   are: distribution list mechanism, public key distribution for Privacy
+   Enhanced Mail (PEM), routing of X.400 messages, distribution of EDI
+   identifiers, etc. For more information we refer to [7]. Below the
+   first three applications are briefly discussed.
+
+   The distribution list mechanism uses X.500 for finding the e-mail
+   addresses of the persons that have subscribed to a list. The
+   distributed approach of X.500 makes it possible that people change
+   their e-mail address without having to change their subscription to
+   distribution lists.
+
+   PEM (see a.o. [8] or [4]) uses a public key mechanism for exchanging
+   secure e-mail messages. For example: one will be able to end a secure
+   message by encrypting a message with the publicly known (public) key
+   of the recipient. Only the recipient of the message can decipher the
+   message using his/her private key. In order to make such a mechanism
+   work one must have access to the public keys of all possible
+   recipients. X.500 can be used for this purpose.
+
+   At this moment a world-wide pilot is running in which X.400 routing
+   is done by means of X.500. X.400 MTA's use special DUA's to find via
+   the Directory the MTA's to which the recipients of a message want
+   their mail to be delivered. The distributed approach of X.500 will
+
+
+
+RARE Working Group on Network Applications Support              [Page 8]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+   mean much less routing management (currently tables are used that
+   have to be updated/exchanged periodically).
+
+6.  References
+
+   [1] Barker, P., and S. Kille,"The COSINE and Internet X.500 Schema",
+       RFC 1274, University College London, November 1991.
+
+   [2] Getchell, A., and S. Sataluri, Editors, "A Revised Catalog of
+       Available X.500 Implementations", FYI 11, RFC 1632, Lawrence
+       Livermore National Laboratory, AT&T Bell Laboratories, May 1994.
+
+   [3] Weider, C., and J. Reynolds, "Executive Introduction to Directory
+       Services using the X.500 Protocol", FYI 13, RFC 1308, ANS,
+       USC/Information Sciences Institute, March 1992.
+
+   [4] Linn, J., "Privacy Enhancement for Internet Electronic Mail:Part
+       I: Message Encryption and Authentication Procedures", RFC 1421,
+       IAB IRTF PSRG, IETF PEM WGs, Feblruary 1993.
+
+   [5] Hardcastle-Kille, S., Huizer, E., Cerf, V., Hobby, R., and S.
+       Kent, "A Strategic Plan for Deploying an Internet X.500 Directory
+       Service", RFC 1430, ISODE Consortium, SURFnet bv, Corporation for
+       National Research Initiatives, University of California, Davis,
+       Bolt, Beranek and Newman, February 1993.
+
+   [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+       Protocol", RFC 1487, Performance Systems International,
+       University of Michigan, ISODE Consortium, July 1993.
+
+   [7] Weider, C., and R. Wright, R., "A Survey of Advanced Usages of
+       X.500", FYI 21, RFC 1491, Merit Network, Inc, Lawrence Berkeley
+       Laboratory, July 1993.
+
+   [8] "Privacy Enhanced Mail in more detail", Zegwaart, E., Computer
+       Networks for Research in Europe Vol. 2, pp.  63-71.
+
+   [9] Barker, P., Kille, S., and T. Lenggenhager, T., "Naming and
+       Structuring Guidelines for X.500 Directory Pilots", RTR 11/RFC
+       1617, University College London, ISODE Consortium, SWITCH, May
+       1994.   For a good technical introduction to X.500 we also
+       recommend:
+
+  [10] Rose, M., "The Little Black Book", PSI Inc., Prentice Hall Inc.,
+       New Jersey, 1992.
+
+  [11] Steedman, D., "The Directory standard and its application",
+       Technology Appraisals, Twickenham (U.K.), 1993.
+
+
+
+RARE Working Group on Network Applications Support              [Page 9]
+
+RFC 1684       Introduction to X.500 White Pages Services    August 1994
+
+
+7.  Security Considerations
+
+   Security issues are not explicitly discussed in this memo.
+
+8.  Author's Address
+
+   Peter Jurg
+   SURFnet bv
+   Postbus 19035
+   NL-3501 DA Utrecht
+   The Netherlands
+
+   Phone: +31 30 310290
+   Fax: +31 20 340903
+   RFC822: Peter.Jurg@surfnet.nl
+   X.400: C=nl; ADMD=400net; PRMD=surf; O=surfnet; S=jurg
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+RARE Working Group on Network Applications Support             [Page 10]
+