deployment strategy for network info in Directory
Thomas Johannsen <Thomas.Johannsen@ifn.et.tu-dresden.de> Thu, 08 July 1993 17:17 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10747;
8 Jul 93 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10742;
8 Jul 93 13:17 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa16697;
8 Jul 93 13:17 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.01751-0@haig.cs.ucl.ac.uk>; Thu, 8 Jul 1993 16:05:24 +0100
Received: from Ebzaw1.et.tu-dresden.de by bells.cs.ucl.ac.uk with Internet
SMTP
id <g.25180-0@bells.cs.ucl.ac.uk>; Thu, 8 Jul 1993 16:01:59 +0100
Received: local by ebzaw1.et.tu-dresden.de (AIX 3.2/UCB 5.64/2.21) id AA34264;
Thu, 8 Jul 1993 16:59:45 +0100
Date: Thu, 8 Jul 1993 16:59:45 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Thomas Johannsen <Thomas.Johannsen@ifn.et.tu-dresden.de>
Message-Id: <9307081559.AA34264@ebzaw1.et.tu-dresden.de>
To: osi-ds@cs.ucl.ac.uk
Subject: deployment strategy for network info in Directory
One item on the task list left over from the last IETF was work
on a deployment strategy for network information in the Directory.
Glenn has started some good work in this area recently.
The whole thing is related to osi-ds37/38 and their various predecessors. Thus,
you should first read osi-ds-38 before you dive into this doc.
Please find below a very first draft on this issue. There are still lots
of things unstable and perhaps missing.
I'm looking forward to discussing details with you next Monday at Amsterdam.
Sorry for sending this last minute - you folks from America have a lot of
time during the long flight :-)
Thomas
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OSI-DS Working Group Glenn Mansfield
INTERNET-DRAFT Thomas Johannsen
Jun Murai
July 1993
Network Information in the Directory: a Deployment Strategy
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Expires: January 8, 1994 [Page 1]
Internet Draft July 1993
Abstract
This document describes a strategy for deploying the X.500 Directory in
the Internet. The focus is mainly on the Internet related information.
Contents
========
1.Introduction 2
2.Deployment Issues 3
3.Network Information 4
4.General strategy 5
4.1 The interrelation of the information
in the existing sources 5
4.2 Local representation of information 7
4.3 Relation of the information with the Global
Directory. 8
4.4 Where Should The Organization-info go? 9
4.5 The DIT Structure 11
4.6 Directory service infrastructure 12
4.7 Administrative Requirements 12
4.8 Deployment Stages 12
5. Mapping NIC-INFO onto the Directory 13
5.1 InterNICs database 13
5.2 RIPEs database 15
6.References 17
1. Introduction.
===============
The phenomenal and continued growth of networking in general and the
Internet in particular has led to the growing need of a distributed
framework which allows users and applications to access information
about users, services, networks, ... easily and globally. The OSI X.500
Directory service provides a rich framework to support a globally
distributed information service system. A strategic plan for the
deployment of an Internet Directory Service has been proposed in [STR].
Towards realizing this plan a substantial effort has been carried out by
the IETF OSI-DS WG in setting up the coherent information framework for
the Directory.
Presently several different but cooperating pilots [PSI, FOX, Paradise]
are offering Directory services. These basically deal with person and
organization related information.
There has been a substantial effort within the IETF OSI-DS WG to chart
Expires: January 8, 1994 [Page 2]
Internet Draft July 1993
network information in the Directory. Schemas have been developed for
this purpose. [ND, IP, DNS]. Experimental mini-pilots have been
established [IP2]
In this work we address the technical issue of deploying the directory
and spreading its use and application by covering information about the
network infrastructure. This is essential in making the Directory
Information Services itself a success. The issues cover strategies for
populating the Directory with Network Information.
It should be noted that though some of the services that are or may be
offered by the Directory do overlap with existing services, there is no
immediate or near future plan of replacing any existing service. The
proposed services may be viewed as an experimental and/or auxiliary
service. Depending on the application it may be a preferred service, in
some cases. So there is not going to be any *migration* from some system
to the Directory system.
2. Deployment Issues
====================
- Technical
o fixing the schemas atleast on an experimental basis
o arranging for distribution of the schemas
o setting up the Directory infrastructure
o providing the user applications and interfaces
- Organizational/Administrative
o Set-up an organizational structure for IDMD
o Administrators/POCs
o Management/distribution of schemas
- General
o Education regarding the utility and necessity of the Directory
o Applications to make the Directory more attractive
o A viable bootstrapping strategy that takes care of the transitional
state
There has been considerable activity in the OSI-DS WG on the schemas
for networks and network objects. Work is progressing on the
distribution mechanism for the schemas. The Directory infrastructure
requires an OSI-stack. Available implementations have been examined and
catalogued by the IETF DISI WG in [IMP]. Important developments have
taken place in the user application area with the LDAP [LDAP] protocol
progressing in the standards track. The usage of this protocol removes
the burden of implementing an OSI stack from user applications of the
Expires: January 8, 1994 [Page 3]
Internet Draft July 1993
Directory. Several attractive applications are being worked upon in the
IETF OSI-DS WG. The SoftPages [SPP] project involves optimising document
retrieval by using the network information stored in the Directory.
The Organizational and Administrative framework for the directory in the
Internet requires a lot of work. There is an initiative within the IETF
OSI-DS WG to formulate this framework. In this work we briefly explore
this issue. More detailed discussion will be found in [ADMIN-DOC]
The educative aspects and the applications aspect are being taken up in
the IETF DISI WG.
In the following we examine in detail the issue of the bootstrapping
strategy for populating the Directory with Network information.
3. Network Information.
======================
The network information basically consist of:
* information about the interconnection between the various elements.
* properties and functions of the various network elements and the
interconnections. e.g. speed, charge, protocol, OS, etc. Functions
include services offered by a network element. [File Server, DNS
Server, mail gateway, ...]
* various name and address information of the networks and network
elements [ DNS info, ...]
* information about various administrative and management details
related to the networks and network elements. [ Managers POCs,
owners, ..]
* the policy related information [ Autonomous System Number]
Schemas have been drawn up to represent the IP network information in
the Directory. The defined objects are IPNetworkImage, IPNodeImage,
delegatedBlock, asNumber.
With the stage being set for servicing IP-Network information in the
Directory the deployment problem boils down to one of populating the
directory.
Expires: January 8, 1994 [Page 4]
Internet Draft July 1993
4. General strategy.
====================
It is clear that one will have to make use of existing data to populate
the Directory. A lot of information already exists in a disorganized,
unconnected form. The existing information pool consists of NIC
information, DNS information, routing policy information, Service
information, .... The list is neither exclusive nor exhaustive. The
Internic, National NICs and various NOCs also contain a substantial
amount of information related to networks, numbers, administrators and
organizations. The DNS system is a global distributed database that
contains a lot of network related information . At the lowest level,the
yellow pages and password files contain user/mailbox related
information. There is no doubt that an effective bootstrapping strategy
would have to make use of these massive pools of information.
4.1 The interrelation of the information in the existing sources.
=================================================================
Network information in the present sources covers not only information
about the sources (e.g. NICs :NIC-Profiles) but also covers in varying
degrees of depth the network information and services offered by that
source as well as administrative information related to the various
components. All the components of the information are interrelated. A
person is a member of an organization and at the same time maybe the
manager of a Network. A Network may belong to an Organization and have a
Manager, ...
Expires: January 8, 1994 [Page 5]
Internet Draft July 1993
+-------------+ +--------------+
| | Affiliation | |
| |<-----------------------| |
| Org.Info | | Person.info |
| | | |
+-------------+ +--------------+
X X
\ /
\ /
Owned by,\ /Manager,
Assigned to/by /point of contact
\ /
\ /
\ /
\ /
\ /
+-------------------+
| |
| Network.info |
| |
+-------------------+
Taking a closer look at the NIC information base we see that it contains
information related to the
Network : network number
name
Nameserver
Reverse-server
Domain name
Domain : name
Name Server
Reverse-server
network number
AutonomousSystem:
ASs from which routes are accepted
ASs to which routes are announced
The default Handling of routes
Person:
Name and contact
Organization
Name and address
Expires: January 8, 1994 [Page 6]
Internet Draft July 1993
The primary information held in the NIC is the Network, Domain and
routing policy [AutonomousSystem] related info.
The Person and Organization info is secondary basically as owner of
network, poc, admin-c etc.etc.
4.2 Local representation of information
=======================================
A simple method would be to map the data directly to create IpNw, DNS,
AsNum objects each of which would contain a copy of the organization
info, and person info. This is shown in the figure below.
+---------------------------------------------------------+
| +-----------+ |
| +-----------+ +-----------+ | admin-c | |
| | | | | +-----------+ |
| | Org | | DNS | |
| | | | | +-----------+ |
| +-----------+ +-----------+ | techn-c | |
| +-----------+ |
+-------------------> DNS OBJECT <------------------------+
+---------------------------------------------------------+
| +-----------+ |
| +-----------+ +-----------+ | admin-c | |
| | | | | +-----------+ |
| | Org | | IpNW | |
| | | | | +-----------+ |
| +-----------+ +-----------+ | techn-c | |
| +-----------+ |
+-------------------> IpNw OBJECT <-----------------------+
+---------------------------------------------------------+
| +-----------+ |
| +-----------+ +-----------+ | admin-c | |
| | | | | +-----------+ |
| | Org | | AsNum | |
| | | | | +-----------+ |
| +-----------+ +-----------+ | techn-c | |
| +-----------+ |
+-------------------> AsNum OBJECT <----------------------+
The disadvantage of the scheme is that generally the Organization info
will be the same for all the three objects and also in most cases the
administrative contacts(admin-c) and the technical contacts(techn-c) are
the same. This leads to a lot of "local duplication" of information.
There is no scope of avoiding it.
Another design is to separate the objects based on the nature of
Expires: January 8, 1994 [Page 7]
Internet Draft July 1993
information. The organization, admin-c and techn-c details are not held
in the network objects. Instead, pointers are maintained to organization
and person (admin-c and techn-c) objects. This scheme is shown in the
figure below:
+-----------+
| |
/| DNS |---+
/ | | |
/ +-----------+ |
/ | +-----------+
+-----------+ / +-----------+ | /| admin-c |
| |/ | | | / +-----------+
| Org |------| IpNW |-----
| |\ | | | \ +-----------+
+-----------+ \ +-----------+ | \| techn-c |
\ | +-----------+
\ +-----------+ |
\ | | |
\| AsNum |---+
| |
+-----------+
The advantages of this method are obvious. Though the figure has been
drawn for the best case, in the worst case, where the contacts and
organizations are different for the DNS, IpNW and AsNum, the performance
is similar to that in the earlier method.
4.3 Relation of the information with the Global Directory.
==========================================================
It is clear that the primary information should be mastered in the NIC -
the problem arises with the case of the secondary information. Though
this information is held locally it is generally mastered at some other
place.
A good strategy would avoid explicit duplication of information. By
explicit duplication of information we mean where the information is
duplicated outside the directory framework. For example person XXXX is
registered with his complete information [Name, Address, Sex, Age, ...]
in the employer, in the Locality of his residence, in the Club of which
he is a member, ... . This goes against the grain of a distributed
information system and makes the problem of maintaining the information
more difficult. For example if the Persons address changes the change
will have to be carried out at all the places, else there will be
outdated information in the system. The Directory allows the creation
of pointers so that the persons information remains in one place and all
Expires: January 8, 1994 [Page 8]
Internet Draft July 1993
other places refer to this place for the information by a pointer [But
that will remain transparent to the user]. As far the user is concerned
he needs to maintain the information in one place only.
The Directory offers several ways of handling this case
o strong coupling : maintain an alias which is a pointer to the
original object.
o loose coupling : maintain a seeAlso attribute which is a pointer
attribute. Its existence and semantics will be understood and
interpreted by user applications not by the directory protocol.
o no coupling : the less preferable alternative - the data is copied
on to several places by defining additional attributes.
There are relative merits and demerits of each cases. By a strong
coupling the integrity is ensured. But, control over the availablilty of
the information gets distributed. The remote DSA holding the original
object may become unavailable causing "holes" in the local database.
- The loose coupling case may cause data to get outdated. However,
with the existence of the seeAlso pointers, houseKeeping programs may
periodically check the correctness/integrity.
- The No coupling case is the easiest in terms of implementation. But
will be a nightmare in terms of ensuring integrity of the
information.
Along with coupling the problem of maintaining the intergrity of the
distributed database arises - the design has to incorporate pruning
tools that weed out dangling pointers.
4.4 Where Should the Organization-info go?
==========================================
The Organization-info is necessary, for all Internet related
organizations.
o It is not advisable/preferable/possible to rely on respective
organizations to maintain their part of the DIT and therefrom provide
the Organization-info. The following are the reasons
-organizations WILL be slow in joining the Directory
-reliability of the access to the org's DIT cannot be taken for
granted
o It is not possible for some specific organization(s) [ INTERNIC,
... ] to maintain DITs of all organizations, that would be an
Expires: January 8, 1994 [Page 9]
Internet Draft July 1993
unscalable solution.
o Keeping a copy of the pertinent Organization-info would run counter
to the Distributed DB concept. It would lead to duplication of data
and keeping data updated will be a problem.
A framework is proposed which can reasonably accomodate all the
requirements/conditions.
*a copy* of all the *necessary* Organization-info is retained. Since
only the *necessary* info will be kept the NIC will not be burdened
to act as the repository of the org's DIT. These objects may be kept
in a separate subtree of affiliated-organizations [organizations
affiliated to the NIC]
* The problem of information duplication/consistency will arise when
the organizational DITs/DSAs do come into existence. At that stage a
"shadow"ing mechanism which will attempt to maintain the data
consistency may be resorted to.
* The X.500/ISO 9594 :1993 implementations are expected to have
appropriate shadowing mechanisms
It may be noted that what is suggested is not a duplication of an entire
white-pages-like structure at the NIC. It suggests an "affiliated
organizations" node. The entries under this node will perhaps contain
only "nicOrgAttributeSet". And it certainly wont copy/contain "ou",
"pilot-person", ... entries except those for contact persons referred
to by the network description.
In effect, the affiliated organization objects will have the attributes
to hold the *necessary* organization info nothing more, nothing less.
Operationally, and content wise the NIC DSA will hold exactly the amount
of info that is desired by the NIC. When an organization sets up its DSA
and when the Organization informs the NIC about it, the NIC will set up
the shadowing arrangement to obtain info on changes of interest [ and
forget about it].
It may be emphasized that the entries under the "affiliated
organizations" are physical entities [replicated and refined from the
Master entries, if and when they exist..]. If an NIC dislikes the idea
of users poring over the entries in the affiliated organizations -
appropriate access control can be applied. Though duplication is
unavoidable, the proposal attempts to make it transparent, by delegating
the responsibility of maintaining the integrity to the Directory.
The directory prohibits updates on the shadow-objects. Only Master
Expires: January 8, 1994 [Page 10]
Internet Draft July 1993
objects can be updated... this suits us fine. Also, the shadowed subtree
depth/filter can be specified making it possible to specify single
objects as units of replication. Further, attributes to be shadowed can
be specifed, too - thus the shadow object attributes can be a subset of
those of the shaodwed object. That is just what we are looking for.
4.5 The DIT Structure.
======================
We introduce the concept of Internet Directory Management Domains. These
are entities that provide decentralized management of Internet related
information in the directory.
One IDMD will have o=Internet as the root, and will be referred to as
the root IDMD. Conceptually it represents the administrative areas of
the Internet Directory. Naturally, with the growing trend of delegation,
this administrative tree will be divided and further subdivided into
administrative sub-domains which are IDMDs too. For example the global
IDMD will be rooted at the root of the directory while a countries IDMD
will be rooted under the countries entry "c=US" for example. Thus the
IDMD will be a recurring structure with pointers showing the
relationship. The information content of an IDMD will cover ASNumber,
IPNumber, DNS, NIC information, etc. Each of these will be represented
as an organizational unit. For example ou=ASNo, ou = DNS, ... . The DIT
structure for the DNS, IpNumber trees are discussed separately. Just for
clarity, the ou = DNS@dc=jp component is likely to be mastered in the
c=JP@o=Internet@ou=DNS@ dc=jp sub tree.
:
:
o=Internet : c=JP c=XX
| ....................|.................
| : | :
+----------+--------+-------+ : o=Internet :
ou=NICs ou=IpNo ou=DNS ou=afOrg: | :
| +----+---+ | : +--------+---------+-------+ :
| | +----+----+ : ou=NICs ou=IpNo ou=DNS ou=afOrg:
| | | | | : | | | :
| | dc=jp --:----|--------|-----> dc=jp :
| dbl=abc-----------------:----|---->dbl=abc | :
| : | +----+----+ :
ou=JPNIC -------------------------:-> ou=JPNIC dc=ac dc=ad dc=co :
: :
: :
root IDMD : c=JPs IDMD :
========= : ========== :
Expires: January 8, 1994 [Page 11]
Internet Draft July 1993
Also the ou=NICs will likely have pointers to the national NICs.
4.6 Directory service infrastructure.
=====================================
A minimal Directory Services infrastructure is already in place.
According to a latest count of the Paradise/White Pages pilot DIT there
are approximately 482 DSAs in about 30 countries covering roughly 2760
organizations and with a total population of over a million entries [E-
mail].
At the final stage of deployment one can expect the active participation
of as many organizations participating in the Internet in the Directory.
However there is no denying that this goal will be hard to achieve.
Further the degree of difficulty will critically depend on the initial
success of deployment and subsequent application development.
At the initial stage of deployment we envisage large organizations that
are active in networking and related services and research to be
participants. We expect NICS - the larger ones to start with- [InterNic,
RIPE-NIC, APNIC, JPNIC ..] and others to provide infrastructural
support in the form of setting up and maintaining DSAs. Smaller
organizations will need to be supported. The large organizations may
possibly "rent" DIT space on their systems to the smaller organizations.
The root IDMD will possibly be administered by ISOC wherefrom the
administration of the subordinate parts of the IDMD tree will be
delegated to other organizations.
4.7 Administrative Requirements.
================================
- an administrator
- redundant DSAs
- registration at the higher level
To determine the higher level the general namespace guidelines will be followed.
4.8 Deployment Stages.
======================
Three stages of deployment are being contemplated
1. Put the NIC information in the Directory
Put the top level DNS info in the Directory
Expires: January 8, 1994 [Page 12]
Internet Draft July 1993
3. Couple the DNS and the Directory that will bring
the directory DNS info live.
4. Distribute the IDMD. At this stage more detailed
information on the Network will be expected.
5. Mapping NIC-INFO onto the Directory.
========================================
Below, mappings for the records of two huge NIC databases are given.
This might need revision when other odd NIC-records are considered.
5.1 InterNIC's database
=======================
Organization information
=======================================
| Attribute| X500Attribute |
========================================
| name | organizationName |
| Address | postalAttributeSet |
| Descr. | description |
========================================
Person information
=================================
| Attribute| X500Attribute |
=================================
| name | surname/CommonName |
| title | title |
| mail
| address| postalAddress |
| phone: | telephoneNumber |
| net
| mailbox| mail |
| nic-hdl | NIChandle |
| middle
| name | commonName |
| city | localityName |
| state | stateOrProvinceName |
| zip code| postalCode |
| country | country |
| hostname| ipNodeImage |
| fax-no: | facsimileNumber |
=================================
Expires: January 8, 1994 [Page 13]
Internet Draft July 1993
Node information
=======================================
| Attribute| X500Attribute |
========================================
| name | ipNodeImageName |
| address | ipPortAddress |
| hardware| CPU |
| software| applicationProcess |
| protocols| protocol |
========================================
Autonomous System information
=======================================
| Attribute| X500Attribute |
========================================
| ASN-no | asNumber |
| administ.| adminContact |
| Techn. C.| technContact |
| as name | asName |
| G/W Desc.| ipNodeImage |
| deploym.
| schedule | |
| conn. N/W| ipNetworkImage |
========================================
Domain information
=======================================
| Attribute| X500Attribute |
========================================
| topLevelDomain | domainComponent |
| completeDomName | domainName |
| org name | associatedName |
| date operational | |
| admin. co. | adminContact |
| techn co. | technContact |
| prim. server | primaryServer |
| sec. server | secondaryServer |
========================================
Expires: January 8, 1994 [Page 14]
Internet Draft July 1993
Host information
=======================================
| Attribute| X500Attribute |
========================================
| host | ipNodeName |
| addr | ipPortaddress |
| cputype | cpu |
| opsys | os |
| protocols| protocol |
========================================
IP number information
=======================================
| Attribute| X500Attribute |
========================================
| sponsor | provider |
| poc | adminContact/technContact |
| netw name| ipNetworkImageName |
| postal a.| postalAddress |
| org. | organizationName |
| NoOfHosts| |
| reason | description |
| typeOfNw | |
| purpose | |
========================================
5.2 RIPEs database
==================
Domain information
=======================================
| Attribute| X500Attribute |
========================================
| domain | assocDomain |
| descr | organization |
| admin-c | [adminContact] |
| tech-c | [technContact] |
| nserver | [primaryNameServer] |
| | [secondaryNameServer] |
| sub-dom:| domainComponent |
| dom-net:| [IpNwNumber] |
| | [IpNwNumber] |
| changed:| lastModifiedBy |
| | lastModifiedTime |
| source: | manager |
=======================================
Expires: January 8, 1994 [Page 15]
Internet Draft July 1993
Autonomous System information
=======================================
| Attribute| X500Attribute |
========================================
| AsNum | asNumber |
| descr | description |
| AsIn | asIn |
| AsOut | asOut |
| Default | asDefault |
| admin-c | [adminContact] |
| tech-c | [technContact] |
| guardIan| [asGuardian] |
| remarks | connects to Asxxx |<=
| | will connect to AsXXX |<=
| changed:| lastModifiedBy |
| | lastModifiedTime |
| source: | manager |
=======================================
Network information
==========================================
| Attribute| X500Attribute |
==========================================
| netname: | ipNetworkImagename |
| descr: | ------ |
| country: | country |
| admin-c: | [adminContact] |
| tech-c: | [technContact] |
| connect: | ---- |
| gateway: | [externalGateway] |
| remarks: | country is really Europe |<=
| rev-srv: | [inAddrServer] |
| changed: | lastModifiedBy |
| | lastModifiedTime |
| source: | manager |
=========================================
Expires: January 8, 1994 [Page 16]
Internet Draft July 1993
Person information
=================================
| Attribute| X500Attribute |
=================================
| person: | surname/CommonName |
| address | postalAddress |
| phone: | telephoneNumber |
| fax-no: | facsimileNumber |
| e-mail: | mail |
| nic-hdl | NIChandle |
| changed | lastModifiedBy |
| | lastModifiedTime |
| source: | manager |
=================================
6. References
=============
[STR] S. Hardcastle-Kille, et.al, A Strategic Plan for Deploying
an Internet X.500 Directory, RFC 1430, February, 1993.
service.
[ND] G. Mansfield, Johannsen, Th., Mark Knopper: Charting
Networks in the Directory, Work in Progress, OSI-DS-37
February 1993.
[IP] Johannsen, Th. et.al, Representing IP information in
the X.500 Directory, Work in Progress, OSI-DS-38
June 1993.
[DNS] S. Hardcastle-Kille, X.500 and Domains, RFC 1279,
November, 1991.
[X.500] CCITT: The Directory - Overview of Con-
cepts, Models and Services Recommendations X.500 - X.521
[IMP] Lang, R., and R. Wright, "A Catalog of Available X.500
Implementations", FYI 11, RFC 1292, SRI International,
Lawrence Berkeley Laboratory, January 1992.
[SPP] Johannsen, Th., G. Mansfield: The SoftPages Pro-
ject; Work in Progress, OSI-DS-39 February 1992.
[Schema] P. Barker, Kille, S. The COSINE and Internet
X.500 Schema RFC 1274, November 1991.
Expires: January 8, 1994 [Page 17]