summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1684.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1684.txt')
-rw-r--r--doc/rfc/rfc1684.txt563
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]
+