summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1609.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1609.txt')
-rw-r--r--doc/rfc/rfc1609.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc1609.txt b/doc/rfc/rfc1609.txt
new file mode 100644
index 0000000..df3718e
--- /dev/null
+++ b/doc/rfc/rfc1609.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group G. Mansfield
+Request for Comments: 1609 AIC Systems Laboratory
+Category: Experimental T. Johannsen
+ Dresden University
+ M. Knopper
+ Merit Networks, Inc.
+ March 1994
+
+
+ Charting Networks in the X.500 Directory
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ There is a need for a framework wherein the infrastructural and
+ service related information about communication networks can be made
+ accessible from all places and at all times in a reasonably efficient
+ manner and with reasonable accuracy. This document presents a model
+ in which a communication network with all its related details and
+ descriptions can be represented in the X.500 Directory. Schemas of
+ objects and their attributes which may be used for this purpose are
+ presented. The model envisages physical objects and several logical
+ abstractions of the physical objects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 1]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+Table of Contents
+
+ 1. Introduction 2
+ 2. Infrastructural information requirements 2
+ 3. The Nature of the Network Map - The X.500 Solution 4
+ 4. The hierarchical model of a network 5
+ 4.1 Network maps 5
+ 4.2 Representation in the X.500 Directory 6
+ 5. Position in The Directory Information Tree(DIT) 7
+ 6. Proposed Schemes 8
+ 6.1 Communication Object Classes 9
+ 6.2 Physical elements 10
+ 6.2.1 Network 10
+ 6.2.2 Node 11
+ 6.2.3 NetworkInterface 12
+ 6.3 Logical Elements 12
+ 6.3.1 Network 13
+ 6.3.2 Node 13
+ 6.3.3 NetworkInterface 13
+ 7. Security Considerations 14
+ 8. Authors' Addresses 14
+ 9. References 15
+
+1. Introduction
+
+ The rapid and widespread use of computer networking has highlighted
+ the importance of holding and servicing information about the
+ networking infrastructure itself. The growing and active interest in
+ network management, which has concentrated mainly in the areas of
+ fault and performance management on a local scale, is severely
+ constrained by the lack of any organized pool of information about
+ the network infrastructure itself. Some attempts have been made, on a
+ piecemeal basis, to provide a larger view of some particular aspect
+ of the network (WHOIS, DNS, .. in the case of the Internet; [1],
+ [2]). But to date, little or no effort has been made in setting up
+ the infrastructural framework, for such an information pool. In this
+ work we explore the possibility of setting up a framework to hold and
+ serve the infrastructural information of a network.
+
+2. Infrastructural information requirements
+
+ Network operation and management requires information about the
+ structure of the network, the nodes, links and their properties.
+ Further, with current networks extending literally beyond bounds, the
+ scope of the information covers networks beyond the span of local
+ domain of authority or administration. When the Network was
+ relatively small and simple the map was already known to the
+ knowledgable network administrator. Based on this knowledge the
+
+
+
+Mansfield, Johannsen & Knopper [Page 2]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ course of the packets to different destinations would be charted. But
+ presently the size of the Network is already beyond such usages. The
+ current growth of the Network is near explosive. This is giving rise
+ to the urgent necessity of having infrastructural and service related
+ information made accessible from all places and at all times in a
+ reasonably efficient manner and with reasonable accuracy. In the rest
+ of this work a network is the media for transmitting information.
+ Network elements are equipment with one or more network interfaces
+ whereby it is possible to exchange information with the network.
+ Network elements with multiple interfaces e.g.,
+ gateways/routers/bridges/repeaters... may be used to connect
+ networks. Network related information, referred to as 'network map'
+ in the rest of this paper, should
+
+ 1. Show the interconnection between the various network
+ elements. This will basically represent the Network as a graph
+ where vertices represent objects like gateways/workstations/
+ subnetworks and edges indicate the connections.
+
+ 2. Show properties and functions of the various network elements
+ and the interconnections. Attributes of vertices will represent
+ various properties of the objects e.g., speed, charge, protocol, OS,
+ etc. Functions include services offered by a network element.
+
+ 3. Contain various name and address information of the networks
+ and network elements
+
+ 4. Contain information about various administrative and management
+ details related to the networks and network elements.
+
+ 5. Contain the policy related information, part of which may be
+ private while the other part may be made public.
+
+ Using this map the following services may be provided
+
+ 1. Configuration management:
+
+ - Display the physical configuration of a network,
+ i.e., nodes and their physical interconnections
+ - Display the logical configuration of a network,
+ i.e., nodes and their logical interconnections.
+
+ 2. Route management:
+
+ - Find alternate routes by referring to the physical
+ and logical configurations.
+ - Generate routing tables considering local policy and
+ policy of transit domains
+
+
+
+Mansfield, Johannsen & Knopper [Page 3]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ - Check routing tables for routing loops,
+ non-optimality, incorrect paths, etc.
+
+ 3. Fault management: In case of network failures
+ alternatives may be found and used to bypass the
+ problem node or link.
+
+ 4. Service management: Locate various services and
+ servers in the Network.
+
+ 5. Optimization: The information available can be used
+ to carry out various optimizations, for example cost,
+ traffic, response-time, etc.
+
+ 6. Provide mappings between the various names and
+ addresses of elements
+
+ 7. Depict administrative/autonomous domains.
+
+ 8. Network Administration and Management: References to
+ people responsible for administering and technically
+ maintaining a network will be useful.
+
+ Examples of such usages are described in [3], [4].
+
+3. The Nature of the Network Map - The X.500 solution
+
+ Implementing and maintaining a detailed map of the network poses a
+ serious problem. The scope of the map is global and the network
+ itself is expanding. Some of the problems that are peculiar to the
+ network map are listed below.
+
+ o The Network configuration is quasi-static. Nodes,
+ links and networks are being added,updated and deleted
+ someplace or the other.
+
+ o The Network is huge and geographically distributed.
+
+ o The network spans several political and administrative
+ areas. The related information is also controlled and
+ maintained in a distributed fashion.
+
+ In short, global network configuration information is unwieldy and
+ growing continuously. It is impossible to service such information
+ in a centralized fashion. There is need for a distributed framework
+ which allows users and applications to access information about
+ users, services, networks, ... easily and globally. The OSI X.500
+ Directory services [5] provides a rich framework to support a
+
+
+
+Mansfield, Johannsen & Knopper [Page 4]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ globally distributed information service system. The X.500 Directory
+ is intended to be a very large and highly distributed database. It is
+ structured hierarchically with entries arranged in the form of a tree
+ in which each object corresponds to a node or an entry. Information
+ is stored about an object as a set of attributes.
+
+4. The hierarchical model of a network
+
+ For representing networks in the Directory we use the following
+ hierarchical model.
+
+ A network is the media for transmitting information with zero or more
+ network elements each having at least one network interface on the
+ media. The media may be any kind of a line (physical circuit/virtual
+ circuit), or a collection of interconnected networks.
+
+ < The postscript version of this document >
+ < has a figure here. However, the figure >
+ <is too complex to be drawn in simple ASCII.>
+
+ Figure 1: Simple and composite networks and their mapping to the DIT.
+
+ The model allows hierarchy of subnetworks. Network elements with
+ multiple interfaces may act as external gateways to the attached
+ network and to networks higher up in the hierarchy. Thus, a gateway
+ may be the external gateway of several networks which are either
+ interconnected or have a hierarchical relationship.
+
+ A network may be simple consisting of zero or more network elements
+ or composite consisting of several sub-networks. Examples of simple
+ networks are ethernets, optical fiber/copper cables, free space, .. .
+
+4.1 Network Maps
+
+ Using the above model it is straight forward to draw the topological
+ graph of the network where the vertices represent the components of
+ the network and edges indicate the connections. For visual
+ representation the graph may be translated to a more "physical"
+ illustration (figure 1).
+
+ Just as there are several maps of the same geographical domain
+ (political, natural...) one can envisage several views of the same
+ network and its components. A view (called "image" in the remainder)
+ could pertain to a particular protocol suite (IP/OSI/...), an
+ administrative domain or purpose. Using images, several abstractions
+ of the same object are possible.
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 5]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+4.2 Representation in the X.500 Directory
+
+ To represent the various images of networks and its components along
+ with the real-image relationship among the various objects we
+ introduce the following classes of objects:
+
+ o Communication Object Class (CO): All objects defined
+ furtheron in this document belong to this class.
+ Common attributes for all communication objects are
+ defined in section 6.
+
+ o Physical Communication Object Class (PCO): A subclass
+ of CO-class, this class defines common properties for
+ all objects representing physical communication objects.
+
+ o Image Communication Object Class (ICO): A subclass of
+ CO-class, this class defines common properties for all
+ objects representing images of communication objects.
+
+ The above classes sort communication objects into physical or image
+ object. As is implied in the nomenclature a physical object will
+ have several attributes describing it physical properties - location,
+ weight, size, .... etc. An image object will have an Image-of
+ attribute. The Image-of attribute will point to a physical object or
+ to another image object.
+
+ Using this schema it is possible to represent the case of several
+ logical network systems (running different protocol stacks - IP, XNS,
+ SNA, OSI, ...) which coexist on the same physical network.
+ Information related to different types of networks, no matter what
+ the underlying communication protocol is, will reside in the
+ Directory in harmony. Also, their interrelation will be represented
+ and accessed in a fashion independent of the source/destination
+ network, namely, using the OSI X.500 protocol.
+
+ Schemes for physical networks and logical images of physical networks
+ are defined in section 6.
+
+ All objects are defined in section 6.
+
+
+
+
+
+
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 6]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ ...............
+ : :
+ : IP OSI :
+ : +-+ +-+ :
+ : |A| |B| :
+ NetWork -----> : +-+ +-+ :
+ / \ : | | :
+ / \ : ============ :
+ / \ : | :
+ / \ : +-+ :
+ / \ : |C| :
+ / \ : +-+ :
+ OSI-image IP-image : IP + OSI :
+ | | +..............+
+ V V
+ ........ ........
+ : : : :
+ IP : OSI : : IP : OSI
+ +-+ : +-+ : : +-+ : +-+
+ |A| : |B| : : |A| : |B|
+ +-+ : +-+ : : +-+ : +-+
+ ....|...: | : : | :..|...
+ : ============ : : ============ :
+ : | : : | :
+ : +-+ : : +-+ :
+ : |C| : : |C| :
+ : +-+ : : +-+ :
+ : IP + OSI : : IP + OSI :
+ +..............+ +..............+
+
+
+ Figure 2: Several logical views of the same physical network
+
+5. Position in the Directory Information Tree (DIT)
+
+ Information about networks usually will be contained in the DIT as
+ subordinate of the organization maintaining the network. The network
+ model gets mapped into a tree structure for network elements. There
+ is one network object giving general descriptions of the network.
+ Subordinates of this network object are node objects for each node
+ element present in the network. Node objects hold networkInterface
+ objects as subordinates. A network can be physically or logically
+ subdivided into several (sub)networks. In this case, a network entry
+ will have network objects as subordinates which again build the same
+ structure. These entries may be kept as subordinates of
+ organizationalUnit entries as well, with pointers from the "root"
+ network.
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 7]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ This structure holds for physical and logical elements. Physical
+ elements are named network, node and networkInterface, and logical
+ elements are named networkImage, nodeImage and networkInterfaceImage.
+
+ _root_
+ / \
+ / \
+ / \
+ country \
+ / \
+ / organization
+ / / | \
+ / / | \
+ / / | \
+ / / | \
+ / organizationalUnit* | \
+ / / \ \ | \
+ / / \ \__|_________ \
+ / / \ | \ \
+ Person Network*<====>NetworkImage*
+ | |
+ | |
+ Node NodeImage
+ | |
+ | |
+ NetworkInterface NetworkInterfaceImage
+
+ Legends: * the object may recursively contain objects of
+ same class as children
+
+ Figure 3: Part of the Directory Information Tree,
+ showing relations of White Pages and network objects
+
+6. Proposed Schemes
+
+ A physical network comprises of wires and machines. The physical map
+ of the network will show the interconnections of these nodes by these
+ circuits.
+
+ For each physical network element, one or more images may exist.
+ Similarly, an image may be attached to one or more physical objects.
+ The types of images can grow along with the requirements.
+ Relationship between elements (physical or logical) are expressed by
+ attributes or the position in the Directory tree.
+
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 8]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ Problems that are addressed in the schema:
+
+ 1. Avoiding data duplication
+ 2. Preserving administrative boundaries/controls.
+ 3. Simple representation (minimal number of pointers)
+ 4. Security: Though no special emphasis has been placed
+ in this work we believe the X.500 access control policies
+ policies will provide a reasonable secure framework for security
+ and privacy.
+
+ Problems that are not addressed:
+
+ 1. Caching policies, etc.: to be decided locally
+
+6.1 Communication Object Classes
+
+ The object classes introduced in section 4 are defined as follows:
+
+ CommunicationObject OBJECT CLASS
+ SUBCLASS of top
+ MAY CONTAIN {
+ description :: CaseIgnoreStringSyntax,
+ /* can contain any information about the object,
+ however, wherever an appropriate attribute
+ exists, this should be used first to hold
+ information */
+ adminContact :: distinguishedNameSyntax,
+ /* points to the person which is responsible for
+ the administration of the instance this object
+ describes;
+ This refers to the instance only in the context
+ of the concrete object class */
+ technContact :: distinguishedNameSyntax,
+ /* points to the person which is responsible for
+ the technical maintenance of the instance this
+ object describes;
+ This refers to the instance only in the context
+ of the concrete object class;
+ Availability (e.g. hours of service) is not
+ covered by this attribute. */
+ }
+
+ PhysicalCommunicationObject OBJECT CLASS
+ SUBCLASS of CommunicationObject
+ MAY CONTAIN{
+ owner :: distinguishedNameSyntax,
+ /* refers to organization or person owning the
+ physical element;
+
+
+
+Mansfield, Johannsen & Knopper [Page 9]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ Note that more detailed information (like lease,
+ rental, etc.) can be covered in a specific image
+ (ownerImage) of this element */
+ localityName :: CaseIgnoreStringSyntax
+ /* where the object is located;
+ can be used freely to "spot" a network element,
+ e.g. state/city/street/building/floor/room/
+ desk/... */
+ ICO :: distinguishedNameSyntax
+ /* points to image object the physical object
+ is related to;
+ might have several values if physical object is
+ used for several applications at the same time */
+ }
+
+ ImageCommunicationObject OBJECT CLASS
+ SUBCLASS of CommunicationObject
+ MAY CONTAIN{
+ type :: caseIgnoreStringSyntax,
+ /* expresses the view this object refers to, e.g.
+ view of provider/user/IP/OSI/...;
+ Note that this information can be covered by
+ the object class in some cases
+ (e.g. ipNetworkImage gives the IP view) */
+ imageOf :: distinguishedNameSyntax,
+ /* points to physical/image object the image
+ is related to;
+ might have several values if view applies to
+ several physical objects at the same time */
+ }
+
+6.2 Physical elements
+
+ The following objects describe network elements without saying
+ anything about their usage. All objects inherit properties of the
+ PhysicalCommunicationObject class.
+
+6.2.1 Network
+
+ The network object supplies general descriptions which are common for
+ a set of nodes and circuits comprising one network. This includes
+ information about the type of circuits (medium, broadcast or point-
+ to- point, etc.) and properties (speed etc.).
+
+ network OBJECT CLASS
+ SUBCLASS of PhysicalCommunicationObject
+ MUST CONTAIN {
+ networkName :: caseIgnoreStringSyntax }
+
+
+
+Mansfield, Johannsen & Knopper [Page 10]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ MAY CONTAIN {
+ externalGateway :: distinguishedNameSyntax,
+ /* points to one or more nodes that connect
+ this network to neighbor networks;
+ whether a node actually is used as gateway
+ for one or the other protocol, is defined
+ in a related networkImageObject */
+ nwType :: caseIgnoreStringSyntax,
+ /* type of this network;
+ either "composite" (if consisting of subnetworks)
+ or type of a line:
+ bus, ring, star, mesh, point-to-point */
+ media :: caseIgnoreStringSyntax,
+ /* if network is not composite,
+ describes physical media:
+ copper, fiber optic, etc. */
+ speed :: numericStringSyntax,
+ /* nominal bandwidth, e.g. 64 kbps */
+ traffic :: numericStringSyntax
+ /* (average) use in percent of nominal bandwidth
+ [ this needs more specification later ] */
+ configurationDate :: uTCTimeSyntax,
+ /* date when network was configured in current
+ shape */
+ configurationHistory :: caseIgnoreStringSyntax
+ /* list of configuration changes, like:
+ added/removed nodes, lines */
+ }
+
+6.2.2 Node
+
+ The node object describes any kind of device that is part of the
+ network, such as simple nodes, printer, bridges.
+
+ node OBJECT CLASS
+ SUBCLASS of PhysicalCommunicationObject
+ MUST CONTAIN{
+ nodeName :: caseIgnoreStringSyntax }
+ MAY CONTAIN {
+ machineType :: caseIgnoreStringSyntax,
+ /* e.g. main frame, work station, PC, printer;
+ might include manufacturer */
+ OS :: caseIgnoreStringSyntax,
+ /* e.g. VM, UNIX, DOS; might include release */
+ }
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 11]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+6.2.3 NetworkInterface
+
+ Each node object will have one or more networkInterface objects as
+ subordinates. NetworkInterface objects provide information about
+ interfaces of the node and connectivity.
+
+ networkInterface OBJECT CLASS
+ SUBCLASS of PhysicalCommunicationObject
+ MUST CONTAIN {
+ networkInterfaceName :: caseIgnoreStringSyntax
+ /* It is suggested that the networkInterface
+ name is derived from the name of the logical
+ device this networkInterface represents for
+ the operating system, e.g. le0, COM1 */
+ }
+ MAY CONTAIN {
+ networkInterfaceAddress :: caseIgnoreStringSyntax,
+ /* this should contain a protocol-independent
+ interface address, e.g. Ethernet board number */
+ connectedNetwork :: distinguishedNameSyntax,
+ /* pointer to object of network which this networkInterface is
+ connected to */
+ }
+
+6.3 Logical Elements
+
+ An abstract view of a physical element is called image in this
+ document. The word image gets appended to the object type, leading
+ to the new objects networkImage, nodeImage and networkInterfaceImage.
+ Images will either build Directory trees of themselves or be stored
+ as part of the physical network tree (see section 5).
+
+ Image objects inherit properties of the ImageCommunicationObject
+ class.
+
+ Each image object has specific attributes which vary depending on the
+ point of view (IP, OSI, ...). Also, the user and provider of an image
+ will view an object differently; further a user of an object may also
+ be providing the services of the same object to another user.
+
+ Therefore, in the following a complete and general list of attributes
+ cannot be given. We recommend to define subclasses of Image classes
+ for each logical view. These subclasses inherit all attributes
+ defined with the object classes below and add more specific
+ attributes. Examples for an IP-view are given in [1].
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 12]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+6.3.1 Network
+
+ There may be several network images for one and the same physical
+ network: one for each protocol, application, etc.
+
+ networkImage OBJECT CLASS
+ SUBCLASS of ImageCommunicationObject
+ MAY CONTAIN {
+ externalGateway :: distinguishedNameSyntax,
+ /* points to one or more nodes that act
+ as gateway for the protocol application
+ this images refers to */
+ speed :: numericStringSyntax,
+ /* nominal bandwidth for the channel dedicated
+ to this protocol or application ,
+ e.g. 64 kbps */
+ traffic :: numericStringSyntax,
+ /* (average) use in percent of nominal bandwidth
+ [this needs more specification later ] */
+ charge :: numericStringSyntax
+ /* amount of money that has to be paid to
+ service provider for usage;
+ [it is felt that this needs further definition:
+ e.g. monetary unit / time unit, monetary unit /
+ data unit ] */
+ }
+
+6.3.2 Node
+
+ Name and functionality within the network might vary for a node from
+ protocol to protocol considered. In particular, a node might act as
+ gateway for one protocol but not for the other. Routing policy is
+ stored in the case of policy gateways.
+
+ nodeImage OBJECT CLASS
+ SUBCLASS of ImageCommunicationObject
+ /* no attributes common for all nodeImages have been
+ defined yet */
+
+6.3.3 NetworkInterface
+
+ As with physical nodes, nodeImages have networkInterfaces
+ (networkInterfaceImages) which describe connectivity to other network
+ elements. NetworkInterfaceImages are only given if the protocol is
+ establishing connections via this networkInterface.
+
+ networkInterfaceImage OBJECT CLASS
+ SUBCLASS of ImageCommunicationObject
+
+
+
+Mansfield, Johannsen & Knopper [Page 13]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+ MAY CONTAIN {
+ networkInterfaceAddress :: caseIgnoreStringSyntax,
+ /* the networkInterface address in the image
+ context, e.g. IP number, NSAP */
+ connectedNetwork :: distinguishedNameSyntax
+ /* pointer to networkImageObject that describes
+ the network this networkInterface is attached
+ to in terms of the protocol or application the
+ image indicates */
+ }
+
+7. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+8. Authors' Addresses
+
+ Glenn Mansfield
+ AIC Systems Laboratory
+ 6-6-3 Minami Yoshinari
+ Aoba-ku, Sendai 989-32
+ Japan
+
+ Phone: +81 22 279-3310
+ EMail: glenn@aic.co.jp
+
+
+ Thomas Johannsen
+ Dresden University of Technology
+ Institute of
+ Communication Technology
+ D-01062 Dresden
+ Germany
+
+ Phone: +49 351 463-4621
+ EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
+
+
+ Mark Knopper
+ Merit Network, Inc.
+ 1071 Beal Avenue
+ Ann Arbor, MI 48109
+
+ EMail: mak@merit.edu
+
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 14]
+
+RFC 1609 Charting Networks in the X.500 Directory March 1994
+
+
+9. References
+
+ [1] Harrenstein, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC
+ 954, SRI, October 1985.
+
+ [2] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+ [3] Johannsen, T., Mansfield, G., Kosters, M., and S. Sataluri,
+ "Representing IP information in the X.500 Directory", RFC 1609,
+ Dresden University, AIC Systems Laboratory, Network
+ Solutions,Inc., AT&T Bell Laboratories, March 1994.
+
+ [4] Johannsen, T., and G. Mansfield, "The Soft Pages Project", OSI-DS
+ WG document, OSI-DS-39, Dresden University, AIC Systems
+ Laboratory, February 1993.
+
+ [5] CCITT Blue Book, "Data Communication Networks: Directory",
+ Recommendations X.500-X.521, December 1988.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mansfield, Johannsen & Knopper [Page 15]
+