RFC relevance of services

As per Relevance of the word services, we have this rfc below:

Network Working Group K.
Request for Comments: 1107 M.I.T. Laboratory for Computer
July 1989

A Plan for Internet Directory

Table of

1. Introduction 1
1.1. The Issues 1
1.2. Project Summary 3
2. Goals and Requirements for a White Pages Service 6
3. Pre-existing Services 9
4. Proposed Approach 11
4.1. Stage 1: The Field Test 12
4.2. Stage 2: Implementation 17
4.3. Stage 3: Deployment 17
5. Conclusion 18

Status of this

This memo proposes a program to develop a directory service for
Internet. It reports the results of a meeting held in February 1989,
which was convened to review requirements and options for such
service. This proposal is offered for comment, and does
represent a committed research activity of the Internet community
Activity in this area is anticipated, and comments should be
promptly. Distribution of this memo is unlimited

1.

1.1. The

As part of the planned growth of the Internet (in particular,
support of the full science research community in the U.S.),
increasing need is anticipated for various sorts of
services. The increase in the size of the community served by
Internet and the burgeoning demands for electronic mail lead to
need for a service to find people's computer mailboxes and
relevant facts, a so-called "White Pages" service. At the user
to date, there have been no such national or international
pages services in general use. As part of building the
Research Network (NRN), it is important that such a service exist
not only within the NRN community, but also crossing the
from the NRN to the more global network community. This will
communication not only among computer scientists, but also

Sollins [Page 1]

RFC 1107 A Plan for Internet Directory Services July 1989

scientists and engineers in other fields as well. Also important
related is a so-called "Yellow Pages" service, which permits
location of Internet resources based on their attributes

A "White Pages" service is one in which one can look up people
order to learn information about them for finding them. In
simplest form, a white pages service provides what the white
telephone book provides. Based on a name, one can find an
and a telephone number. In a network environment, there may be
other kinds of location information, such as electronic mailbox
electronic calendar, or file server, where one might leave a file
the recipient. In addition, the electronic white pages may support
much more sophisticated set of mechanisms for lookup. One
match on a more complex set of attributes than first and last name
In addition, the searching might span more than one local white
service. There are a number of naming and directory
specifications and implementations in the field. They have
functionality and mechanisms to address that functionality

Within the the world of networking today, there are a number
partial solutions to the directory service problem. Examples
these are the Internet Domain Naming Service (DNS), Clearinghouse
DECnet Network Architecture Naming Service (DNANS), Profile,
X.500. The Domain Naming Service provides a directory service
commonly used for host naming and mail delivery. Clearinghouse
DNANS are respectively the Xerox and DEC corporate naming services
originally for mail delivery, although having other uses as well,
both cases. Profile is part of the work of Larry Peterson to
descriptive naming in a non-hierarchical structure

There is a CCITT recommendation X.500 (ISO DIS 9594), which defines
general directory service. One of its primary goals is the
service needed for message handling (X.400). While X.500 is
developing, and would need further evolution to cover all
requirements of a service for the Internet, it will have an
impact on the Internet community. It will form the basis
commercial products, and it will almost certainly be the
service of many parts of the network world, which implies a need
interoperate at a minimum. There is some concern that despite
fact that X.500 is a recognized standard, there are a number of
and limitations of the approach, that in turn will cause it to
inadequate for the needs of the NRN

In this context, a meeting was held to review current
and solutions for directory services. This RFC reports the
of that meeting, including the possibilities for a program of work
this area

Sollins [Page 2]

RFC 1107 A Plan for Internet Directory Services July 1989

For two days, a group representing academic, commercial,
government interests in directory services discussed both
candidates for a white pages service and the issues in building
such service. The meeting was kept small by inviting only a
number of representatives of each perspective. By the conclusion
the second day, a consensus was reached on how one could achieve
white pages service in three years. This is summarized in the
section

1.2. Project

The consensus of the meeting can be summarized in the following
points

1. The standards and implementations are close enough to
complete that it is reasonable to undertake provision of an
"White Pages" service

2. Although we are close, an effort is needed to experiment
different levels of service, to flesh out the standards, and
develop code

3. An initial evaluation experiment is needed before making
detailed plans for a production version of the service

4. With strong funding and encouragement, a production service
possible in three years

5. It is important to act now to provide a coherent solution
This means both having an impact on the evolving
and providing a unified, wide-spread solution before a
of differing solutions appear

Although it has clearcut drawbacks, X.500 was identified as the
likely candidate directory service. The reasons for this are that
has rich semantics and is becoming the accepted
standard. However, there are problems with its incompleteness
with its strict hierarchy. Therefore, in order to explore these
become convinced of its viability, the consensus at the meeting
to propose field trials, as the project's first stage. The
trials would be limited in the user community, perhaps restricted
computer science departments because of their familiarity with
problems, and would be based on experimental or new software.
would include experiments with at least an X.500 implementation
Profile, and DNANS. Each of these services has strong points
must be considered as part of the evaluation. They are

Sollins [Page 3]

RFC 1107 A Plan for Internet Directory Services July 1989

X.500: International standard, hierarchy, search rules
filters for searching attributed based names

Profile: Descriptive naming with a richer semantics
describing search criteria, an arbitrary
of servers

DNANS: Access control, replication, caching, hierarchy

In summary, the plan would fall into three stages as follows

- Stage 1: Field Trials

There are two aspects to the field trials. The first is
explore several different architectures for a white
service. To this end, implementations of X.500, Profile,
DNANS should be included. The second aspect of the
trials is to distinguish issues inherent in the X.500
specification from artifacts of a particular implementation
it. Therefore, if possible, two implementations of X.500
should be included. Only one such implementation, Quipu,
identified as developed enough to be included in a field
at present, but others are under way, and will follow.
stage must also include a careful and objective review of
field trials

- Stage 2: Implementation

This stage will include work on both the service and
interfaces. The field trials could result in one of a
of conclusions about the service. These may range
concluding that one or another of the services suits the
of the NRN to proposing a compromise position based on
combination of shortcomings of any one service and the
of others to address those shortcomings. Because X.500
become the standard in other domains, an interface to X.500
will be necessary. Since all of these implementations
still under development, in order to provide production
code, more implementation work will be needed

Although some work will have been done on the user interfaces
much more will be needed in this stage to provide a variety
interfaces. Much emphasis should be placed on this in Stage 2.

- Stage 3: Deployment

Deployment of the full white pages service requires
gathering in order to fill the directory service, placement

Sollins [Page 4]

RFC 1107 A Plan for Internet Directory Services July 1989

servers, distribution of and training for use of client code
placement and management of services, and delegation
authority within the service for authority over the contents
Data collection and some delegation of authority as well
training for users of the client code would begin during
field trial. This stage would begin concurrently with
other two. During the second year, detailed planning
deployment must take place. This stage would conclude in
years, at which time widespread deployment would have occurred

In order to undertake this three stage program effectively, the
identified the following major projects

- Further implementation of code for the field trials

In each case (e.g., Quipu, Profile, and DNANS), programs exist
although modifications are likely to be necessary.
example, each will need to be modified to utilize the
file format into which the input data about users will
gathered

- Design, development and evaluation of user interfaces

- Design and development of data gathering and management tools

- Oversight and evaluation of the field trials

Careful thought and planning must go into the field trials,
guarantee that we learn what is needed to make an
and to plan for the white pages service. The evaluation
also produce a document that is both a general
(assuming no one alternative is chosen wholesale) and
information, in order for later interoperability
conformance testing

- Detailed planning and later management of deployment

This includes delegation of authority over parts of
namespace and arbitrating the shape of the
(addressing the questions about who gets what sorts of names).
This is in addition to the continued and extended
collection and management, distributing the data, placing
code, documentation and user education

- Standards participation is an important part of the program

It is critical as X.500 changes during the next 4 year
period that the United States take a strong stand on

Sollins [Page 5]

RFC 1107 A Plan for Internet Directory Services July 1989

changes we envision. It is encumbant on us to
effectively the results of the largest field trials of
work in the international arena. The group agreed that
could take up to one half of one person's time in a year

- A task force or working group is necessary to provide a
for communication and discussion

It is important to pursue this path now, both to architect a
solution before a collection of ad hoc solutions is deployed, and
provide effective input into the X.500 standards work based on
field trials

2. Goals and Requirements for a White Pages

The requirements of a white pages service are the following

- Functionality

The simple form of a white pages service is straightforward
one should be able to query the service with the name of
person, and have returned attributes of the person such
network mail address and phone number

- Correctness of information

The information in a white pages service is useless
untrusted if it is not updated regularly. A white
service will not be used, if the information it provides is
of date or incorrect. This will require a set of
tools. Data integrity is an especially difficult challenge
this area, in contrast with information that is
correct

- Size

The science and research community has been estimated at
million users. The number of organizations in the
States is on the order of ten to one hundred thousand

- Usage and query rate

In comparison with the typical telephone book pattern of
one lookup a week per person, users of electronic mail in
science and research community will send more electronic
messages than they currently make phone calls, leading to
estimate of ten searches a week per user for electronic as
as paper mail and telephone information. This leads to a

Sollins [Page 6]

RFC 1107 A Plan for Internet Directory Services July 1989

rate of 10**8 queries per week or 170 per second on average
with much higher peak rates. The average could probably
handled by a single server, but not the peak rates and
would leave little room for growth. Therefore, a distributed
multiple server solution is the only one that make sense

- Response time

The issue of overall query behavior must be
carefully. The issue arises when queries, in
searches, are not limited to tightly constrained sets
entries. Since the number of queries generated will
proportional to the number of users (and the size of
system), the white pages design must avoid costs per query
are related to the size of the system. The consequence
otherwise, will be quadratic behavior in response time

The response time of the service must also reflect the
usage. A phone book style query must respond in the
time tolerable to a user, perhaps ten seconds maximum, or
second desirable. If the service is incorporated as
component of a larger service, then the needs of that
determine the response time

- Partitioned Authority

The white pages service under discussion would be used by
wide variety of organizations, ranging from small and
companies, to network service providers, to
agencies. Many of these would find it unacceptable to
the authority over their namespaces to some other organization
Therefore, partitioned authority including some access control
name assignment, and information management must be possible

- Access Control

The access control required by the white pages falls into
categories, read access control, and write or modify
control. There are at least two reasons that read
control must be available. One is that organizations
require limiting the access to the actual entries or parts
them. This would be comparable to organizations not
willing to distribute their corporate phone books or
records. The other reason is that some organizations do
want to publicize or make public their
structure. Write and modify access control is
because both individuals and organizations may want to
inadvertent or malicious creation or modification

Sollins [Page 7]

RFC 1107 A Plan for Internet Directory Services July 1989

information. Access control is an issue for both
wanting to retain local control of personnel information
individuals wanting to control access to private
about themselves

- Multiple Transport Protocol Support

Within the next three years, one cannot expect all
organizations in the USA to convert to the OSI protocols.
the other hand, some will. It is therefore important that
white pages service provide interfaces on top of both
protocols and TCP/IP. There currently exists a partial
suite know as ISODE on top of TCP. This is being
widely enough that perhaps this should also be supported

In addition to these requirements, there are a number of
that would make a white pages service more useful. These are

- Additional Functionality

Descriptive naming with sophisticated searching based
attributes would support a more flexible human interface
simple name translation. Descriptive naming also would
a general yellow pages style service

The form of a yellow pages service is less certain.
definition of a yellow pages service is a directory that
a number of pre-computed inversions of the directory database
so that entries can be retrieved very efficiently using
predetermined attributes of the data. Another definition of
yellow pages service is one that provides a very powerful
of search primitives, somewhat in common with a
query language, to support retrieval of entries that
complex attribute conditions. In other words, one view of
yellow pages service is that it is constructed to
expensive searches, the other is that it is to
general searches

- Accountability

Accountability is important both for allocation and recovery
costs. Vendors may provide commercial directory services
therefore depending on accounting as part of their
commercial ventures

- Multiple Interfaces

There should be both human and programming interfaces to

Sollins [Page 8]

RFC 1107 A Plan for Internet Directory Services July 1989

white pages. For example, in addition to human lookups,
services could effectively use a naming service allow users
include human oriented names than the current electronic
addresses that are required, such as full domain names

- Multiple Clients

Several different clients should exist both to provide for
variety of styles of human usage, and to support selection
the most commonly used computer environments (e.g., UNIX, VMS
MSDOS, OS2, MAC/OS).

3. Pre-existing

This section identifies other naming services that have been
or implemented for naming people. Implementations of all of
exist, although some are still only experimental

Internet Domain Naming

The Internet Domain Name Service [6,1] is used today to
host machines. It is implemented to address the query
and database sizes consistent with looking up hosts as part
mail delivery. It provides a hierarchy with delegation
authority within the hierarchy. Aliases are also available
There is no access control, and the service is
distributed throughout the Internet. It supports management
distribution, replication and caching. It is operational,
provides a rich base of practical experience. It
originally intended to be extensible to cover naming of people
It runs on a variety of different operating systems
utilizes the TCP/IP protocol suite

The DECnet Network Architecture Naming Service (DNANS

There is a rather well developed specification [5,3] for
naming service that is part of the DECnet architecture,
in turn arose from work at the DEC SRC in Palo Alto.
architecture addresses some problems not yet covered by X.500,
such as access control, replication, and caching. It
explicitly defined to have great scalability and
features. It provides a global hierarchy of names, which
mapped into properties. Therefore, operations of
based on properties or attributes may be expensive
difficult. At present it is only implemented on VMS using
DNA protocols, but will be moved to UNIX and TCP in the
year

Sollins [Page 9]

RFC 1107 A Plan for Internet Directory Services July 1989

This service [7,2] is part of the Xerox network environment
It operates today as a global service for Xerox. They
considerable experience with its operation, including
of scale. Clearinghouse provides a three-level hierarchy
names that are mapped to sets of properties. Loose
is provided through slow propagation of updates. Both
service and the DEC service mentioned above are to some
based on an earlier Xerox service called Grapevine

A project at the University of Arizona run by Larry
[8] has produced a white pages name service called Profile.
supports descriptive naming and sophisticated lookup tools
Profile assumes the existence of some other service such as
DNS to navigate among Profile servers. This navigation
need not restrict the relationship among Profile servers to
hierarchical organization; Profile supports a non-
global structure. Names in Profile consist of sets
attributes. Experimental implementations are in
today, and the largest site currently contains about 10,000
entries. The Profile code has been available for long
that it has become stable. The implementation is UNIX-
only and uses TCP

X.500

X.500 is the CCITT recommendation (also ISO/IEC/DIS 9594) [4]
for a directory service. Because it is a CCITT recommendation
it evolves in four year study periods, one of which
recently come to a close. Thus, X.500 has a stable
for the next four years

In X.500, the set of all objects forms a single hierarchy,
each object being named relative to its parent and a
root as the topmost parent. An object consists of a set
attributes. Searching can be done by use of a
combination of attribute values, known as a filter. A
of these attributes comprise an object's distinguished
relative to its parent. The hierarchy as described in
CCITT recommendation is geographic at its top level
organizational within that. Alternatives can also be defined
although they are not part of the CCITT or ISO documents.
addition, there is no proposed mechanisms for
information about other attribute types or object classes.
with the other services, X.500 is a distributed service.

Sollins [Page 10]

RFC 1107 A Plan for Internet Directory Services July 1989

specifies cooperating servers or Directory Server Agents (DSAs
under local control and management each of which knows
one or more parts of the hierarchy. The clients are known
Directory User Agents (DUAs). It is defined to run on top
the OSI protocol stack. The demonstrations of X.500 in
context of Internet run on top of the ISODE package,
provides OSI transport on top of TCP

X.500 is incomplete in that there are a number of
areas in which the standard says nothing, but that need to
specified for a successful implementation. Some examples
these are: access control (although authentication
supported), replication, caching, the database itself (
shape of the hierarchy), tools to limit the scope and cost
searching, and database management tools

There are currently a small number of implementations of X.500
in progress at such locations as University College London (
Quipu project, on UNIX using ISODE), the University of
Columbia (UNIX based using their own full OSI suite),
(experimental, Symbolics Lisp Machine based, Lisp using TCP),
The Wollongong Group (offshoot of Quipu), The
Corporation, NIST, and at least several underway in Italy
Japan. There are probably others and a number of
American corporations have discussed building their own.
of these must make its own decision in the areas in which X.500
is silent. Quipu is probably the most complete
of X.500 to date. The pilot version has about 20 DUAs in
countries with an estimated 20,000 entries total

4. Proposed

The conclusion of this report is that some form of X.500 is the
likely candidate. The reasons for this decision are that it has
rich semantics and will become the international de facto standard
There are, however, serious problems with its incompleteness and
its strict hierarchy. Therefore, in order to explore these
become convinced of its viability, the attendees at the
agreed on field trials, as a first stage. Initially, this
include experiments with at least one X.500 implementation (Quipu),
Profile to explore a non-hierarchical structure and
descriptive naming, and DNANS in order to explore some of
incomplete aspects of X.500 for which DNANS has
solutions

A three-stage plan, with all three stages beginning
and as soon as possible, would provide such a service within the NRN
The first stage should be complete in a year, the second in two,

Sollins [Page 11]

RFC 1107 A Plan for Internet Directory Services July 1989

the third in three. Stage 1 would be field trials of
approaches to naming with an emphasis on distinguishing between
specification and a particular implementation of X.500, as well
Stage 2 would be a more complete implementation of a white
service base on the conclusions from Stage 1. Stage 3 would
widespread deployment of the implementation developed in Stage 2.
The planning for Stage 3 is not outlined here in detail, because
plan would be part of the proposed work to be done. If the
trials were to lead to the conclusion that none of the services
adequate, the plan for the remainder of the work would need to
rescheduled

If the Internet community is to adopt X.500 (or any other standard),
it is necessary to make a number of design and management decisions
above and beyond the implementation decisions for the DSA.
there are a number of such decisions to be resolved, and some
these are significant, the group recommended that this planning
management function should be recognized as a distinct activity

4.1. Stage 1: The Field

It was agreed that field trials would be a valuable form in which
explore the issues of building a white pages service for two reasons
First, the software is still in early stages of development
deployment. Some of it is production code, but still first release
the rest is part of research projects. Second, it is important
learn from experience with a limited and sympathetic community.
suggested community was the computer science community,
particular, computer science departments. That will not be the
completely, since the computer science community in general does
use DECnet. Therefore, for experiments with the DNANS, the NASA/
community was recommended. They will be using DNANS in any case,
they move to DECnet Phase V

The twofold purpose of the field trials is to explore
directory service architectures and to refine the study of X.500
specifically, to distinguish architectural aspects of it
features of a particular implementation of X.500. Initially,
trials would include the Quipu implementation of X.500, Profile,
the DNANS. A second implementation of X.500 should be identified
included as soon as possible. Part of the emphasis of the
trials would be on gathering and maintenance of naming information
To ease this, a single common file format for storage of and
to the naming information and use of a single set of data
tools was recommended, although no particular set was identified
The various directory services would need to be retrofitted to
file format. Such consistency in file format would mean that
services could all be co-resident, sharing files, thus

Sollins [Page 12]

RFC 1107 A Plan for Internet Directory Services July 1989

single locations to participate in several parts of the field trials
This, in turn, would allow for direct comparisons

There are a number of issues, which are not addressed in X.500,
would need to be resolved for a large scale deployment such as
white pages for the NRN. In particular, these are: clients of
service; data collection and maintenance; distribution,
and caching of information; access control, accountability,
information integrity; and support by non-OSI protocols. Each of
name services included in the field trials would include decisions
these areas, albeit different ones. The field trials will allow
evaluation of these different mechanisms

There are two other major issues that must also be addressed
functionality and size. Functionality encompasses both the
point of the nature of the interfaces to the service as well as
structure of the namespace (e.g., hierarchy). A discussion of
must include not only the number of entries handled by the service
a whole, but how those entries are distributed and the query
update patterns

In general, all of these issues are tightly coupled, but
separated here for the purposes of understanding the field trials
its potential effectiveness. They would also be the issues
would be the basis for the work done in Stage 2 of the project

- Functionality

X.500 and DNANS make strong statements about the
of the namespace. In both cases, it is a single,
hierarchy with soft links or aliases and attribute-based
useful both in searches of subtrees of the hierarchy and
storing information about the objects in the hierarchy.
searches are based on logical combinations of attribute values
Quipu implements the naming structure and search
as specified in X.500. In contrast, Profile, provides a
general facility that supports any form of relative names,
just hierarchical, and a small programming language to
the functions for searching. By including Profile in the
trials, these more general facilities can be tested

X.500 specifies that the service is separated into two
for implementation of the service, known as the
Service Agent (DSA), and the client, known as the
User Agent (DUA). DUAs can be implemented independently of
implementation of the white pages service. Quipu, Profile,
DNANS have taken different approaches to the presentation
for DUAs, so the three implementations will allow

Sollins [Page 13]

RFC 1107 A Plan for Internet Directory Services July 1989

additional experience

- Size

As discussed earlier, a white pages service must be prepared
handle a minimum of 10**7 entries, although they may
distributed, and a query rate of hundreds per second. It
also be prepared to handle much higher peak rates. If
address lookup that is presently provided by the DNS is
supported by the white pages service, the query rate will
much higher. The designers of the field trials must
whether or not such usage will be part of the final service
therefore must be examined in the field trials. If so,
may be part of the solution. In addition, the response
for DUAs must be reasonable for a human sitting at a console
Furthermore, modifications to the data should occur
reasonably short periods of time, although this could
measured in hours

The field trials must allow for experimentation under
stressful conditions. The environment for testing must
both large and small nodes, as well as both heavy and
load querying and situations in which reorganization can
tested. Such reorganization may be a simple as moving
piece of the hierarchy to another point and handling
conflicts in the new environment. X.500 does not address
issue, but it will be needed by the NRN

- Distribution, replication, and caching

These are areas in which X.500 has very little to say, but
great deal of work has been done in other distributed,
naming services, in particular both the DNS and DNANS.
seems to be general agreement that distribution of
services should be done on the basis of nodes in the
structure, which also provide the basis for
partitioning. All the naming services described here
distribution, partitioning of the information for placement
cooperating servers. Neither X.500 (and therefore Quipu)
Profile is prepared to redistribute portions of the namespace
for reallocation of administrative responsibilities or
balancing, although this should be possible and DNANS
prepared to do so. Replication is necessary for
in a large-scale or global namespace, although again X.500
not address this issue. Quipu has taken a stand on this,
defining master and slave copies of the data; it is similar to
but not the same as, the approach taken in the DNS. Caching
barely touched on in X.500 and not at all in Profile, but

Sollins [Page 14]

RFC 1107 A Plan for Internet Directory Services July 1989

experience with the DNS indicates that caching is critical
effective operation of a distributed name service. The
has an architected solution based on objects in the
as the unit of distribution and replication. Again, the
solution should be explored in the field test environment

- Access control, accountability, and integrity

Access control and accountability require some degree
authentication. X.500 supports authentication based on
an RSA public key algorithm, but does not address issues
universal registration, nor issues of access control
accountability themselves. These are left as a local issue
although depending on the design of the system, they may
global implications. The problem of integrity of
information in the name service is nowhere addressed.
also does not address these issues, although it
authentication based on UNIX authentication, involving user
and passwords. DNANS takes a strong stand on access control
architecting it in at the level of individual entries.
trials will force these issues out into the open

- Structure of the naming tree

In the deployment of the DNS, about one year was lost
arguments about the actual structure of the naming hierarchy
People form strong opinions about their name, and fight for
against certain hierarchical structures. The same issue
arise here, and advanced planning to deal with the problem
required

In this case, the problem is made harder by the fact that
hierarchy will be global; X.500 is an international standard
based on the assumption that there is only one example of
tree, partitioned by country. Probably the American
Pages Service, at least at its root, will be run by the NIST
its contractor. We must deal with the problem that in
short term, various implementations may not interwork, and
must work with NIST to support the needed services

Specific issues that come up related to the naming tree are

* How is delegation of control of the tree managed
For example, who decides what DSA holds what
of the tree

* How is the creation of new parts of the
(e.g., an organizational entry) controlled

Sollins [Page 15]

RFC 1107 A Plan for Internet Directory Services July 1989

- Support for Tree Search

Regardless of the defintion of the white pages service in
NRN, it will need to interface to the X.500 world. The X.500
naming hierarchy can be expected to become very large,
guidance is needed for users to help them navigate the tree
Users need help to find their way to unknown parts of
namespace. As in other naming services, a feature of X.500
that additional entries, aliases (similar to links in
systems) can be installed to provide an easy path for a user
one part of the tree to find other interesting parts of
tree. By establishing a consistent policy for the use of
entries, learning how to navigate the tree can be made
easier for a user. As part of setting up the tree, therefore
these sorts of policies need to be defined

- Definition of database structures

There are a number of data structures that need to be
as part of setting up each of the services. These include,
example, the types of information stored for the entry about
person. This information must be stored in the servers,
passed to the clients. These structures must thus
specified. In other words, the schema defining attributes
object classes must be specified for the NRN

- Load balancing

The dynamic performance of the Internet system must
estimated, so that the servers can be sized properly
Especially at the root of the tree, the query rate must
estimated carefully. Caching will have a strong influence
this. Therefore, traffic patterns are very dependent on
details of implementation

- Supporting multiple protocol suites

At least three protocol suites are and will continue to be
in the NRN environment. They are DECnet, TCP/IP, and the
suite of protocols. Since the white pages service is at
applications layer, it must run on top of at least these
protocol suites. It is important to understand
requirements of the white pages service for its
protocols

By addressing these issues within the field trials, we will
preparing for the further development of Stage 2. A result of
1 will be a detailed specification of the white pages service

Sollins [Page 16]

RFC 1107 A Plan for Internet Directory Services July 1989

possibly an extension to or modification of X.500. This
dovetail with the activities specifying the details required
implementation (known as "profiling") by the NIST Workshop
Implementors of OSI. In addition, in order to run the field trial
the information capture problem must be addressed, providing the
of the preliminary work of Stage 3.

4.2. Stage 2:

If the evaluation of Stage 1 concludes that some form of X.500
acceptable, at least one of the two X.500 implementations included
the field trials should provide the basis for a production
implementation of X.500 for general deployment. Further work
likely be needed on the basis of the evaluations of the field trials
A production version of an implementation requires both
servers as well as a variety of clients to provide
interfaces on a mixture of hardware and operating systems

In addition, especially because of the inclusion of Profile
DNANS, a variety of different DUAs will be explored by definition
Further investigation into the DUAs should begin in parallel with
in conjunction with the field trials. There should be distinct
for both programs and humans. In addition, there probably should
human-user DUAs geared both to the naive user with simple
patterns and the more sophisticated user who wants to perform
queries. It is also important to design DUAs that do not require
great deal of computing power for the small machines still in use
great quantity. Much of the user community may not be able to
expensive equipment upgrades

Assuming that X.500 is deemed to be the specification of the service
the field trials will address many issues not included in X.500 as
1989. Since it is important for the NRN to support
beyond its own bounds, it behooves us to feed what has been
back into the standards activities. This was identified as
separate activity because of the intellectual as well as
commitment that must be made to do this effectively

4.3. Stage 3:

A plan is required to develop the schedule of service introduction
and to co-ordinate the deployment as it is undertaken. This
mediating service problems, a significant task in its own right

The details of deployment were not discussed at the meeting,
several of the seeds of deployment lie in Stages 1 and 2. The
of these is the capture and management of information. The second
DUA development. Both of these must be included Stage 1 in order

Sollins [Page 17]

RFC 1107 A Plan for Internet Directory Services July 1989

support a usable environment for the trials. In addition,
information that will have been captured in Stage 1 could be
producing a hard copy of the white pages information. That could
distributed to all scientists and engineers involved; such a
would provide an early white pages service. During the
periods of both Stages 1 and 2, planning for deployment would
have to proceed, in order to provide a smooth transition to
third stage in the project

5.

The consensus of the meeting was that following a path that
X.500 was both the correct direction and feasible, although X.500
needs further elaboration. There were several important items
further study. The first is that there are many issues
unresolved in X.500 that have been addressed in other
services, and the NRN should take advantage of the solutions in
other services. The second is that there was some reservation
certain features of X.500, especially in the area of the
of a hierarchy for naming, and only limited flexibility
descriptive naming. The participants believe that is
understand whether X.500 provides enough mechanisms to work
such problems by finding a higher common ground that includes
best features of all the naming services included in the
trials. The final issue with respect to X.500 was that there
agreement that X.500 will be an accepted and utilized standard in
least part of the networked community and therefore interfacing to
will be necessary. Given that, and the other reasons for
X.500, the consensus was that the plan described above would
the NRN and its community of users a useful and usable white
service

1. Austein, R., "The Internet Domain Name System", Proceedings
USA Decus, Massachusetts Institute Technology/LCS, 1987.

2. Demers, A., D. Greene, C. Hauser, W. Irish, J. Larson, S
Shenker, H. Sturgis, D. Swinehart, and D. Terry, "
algorithms for replicated database maintenance", Proceedings
the 6th Symposium on Principles of Distributed Computing, ACM
Vancouver, B.C., Canada, pp. 12-21, August 1987.

3. Digital Equipment Corporation, "DNA Naming Service
Specification Version 1.0.1", Order number: EK-DNANS-FS-001,
Digital Equipment Corporation, 1988.

4. International Organization for Standardization, "

Sollins [Page 18]

RFC 1107 A Plan for Internet Directory Services July 1989

Processing Systems - Open Systems Interconnection -
Directory", Draft Standard (In 8 parts), Also
Recommendation X.500, 1988.

5. Lampson, B., "Desiging a Global Name Service," Proceedings of
5th Symposium on Principles of Distribute Computing, ACM
Calgary, Alberta, Canada, pp. 1-10, August 1986.

6. Mockapetris, P., "Domain Names - Concept and Facilities",
1034, USC/Information Sciences Institute, November 1987.

7. Oppen, D., and Y. Dalal, "The Clearinghouse: A
Agent for Locating Named Objects in a Distributed Environment",
Tech. Rept. OPD-T8103, Xerox Corporation, Palo Alto, CA,
1981.

8. Peterson, L., "Profile: A System for Naming Internet Resources",
Tech. Rept. 20, Department of Computer Science, University
Arizona, June 1987.

Author's

Karen R.
Massachusetts Institute of
Laboratory for Computer
545 Technology
Cambridge, MA 02139-1986

Phone: (617) 253-6006

EMail: SOLLINS@XX.LCS.MIT.

Sollins [Page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX