As per Relevance of the word services, we have this rfc below:
Network Working Group H.
Request for Comments: 2148
BCP: 15 P.
Category: Best Current Practice
September 1997
Deployment of the Internet White Pages
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
1. Summary and
This document makes the following recommendations for
on the Internet
(1) An organization SHOULD publish public E-mail addresses
other public address information about Internet
within their site
(2) Most countries have laws concerning publication
information about persons. Above and beyond these,
organization SHOULD follow the recommendations of [1].
(3) The currently preferable way for publishing the
is by using X.500 as its data structure and naming
(defined in [4] and discussed in [3], but some
use a refinement nationally, like [15] for the US).
organization MAY additionally publish it using
data structures such as whois++.
(4) The organization SHOULD make the published
available to LDAP clients, by allowing LDAP servers
to their data".
(5) The organization SHOULD NOT attempt to charge for
access to the data
In addition, it makes the following recommendations for various
sundry other parties
(1) E-mail vendors SHOULD include LDAP lookup
into their products, either as built-in functionality or
providing translation facilities
Alvestrand & Jurg Best Current Practice [Page 1]
RFC 2148 Internet White Pages Service September 1997
(2) Internet Service providers SHOULD help
organizations follow this recommendation, either by
services for hosting their data, by helping them find
parties to do so, or by helping them bring their own
on-line
(3) All interested parties SHOULD make sure there exists a
X.500 name space in the world, and that all names in
name space are resolvable. (National name spaces
elobarate on the core name space).
The rest of this document is justification and details for
recommendation
The words "SHOULD", "MUST" and "MAY", when written in UPPER CASE
have the meaning defined in RFC 2119 [17]
2.
The Internet is used for information exchange and
between its users. It can only be effective as such if users are
to find each other's addresses. Therefore the Internet benefits
an adequate White Pages Service, i.e., a directory service
(Internet) address information related to people and organizations
This document describes the way in which the Internet White
Service (from now on abbreviated as IWPS) is best exploited
today's experience, today's protocols, today's products and today'
procedures
Experience [2] has shown that a White Pages Service based on self
registration of users or on centralized servers tends to gather
in a haphazard fashion, and, moreover, collects data that
rapidly and is not kept up to date
The most vital attempts to establish the IWPS are based on
with distributed (local) databases each holding a manageable part
the IWPS information. Such a part mostly consists of all
IWPS information from within a particular organization or from
an Internet service provider and its users. On top of the
there is a directory services protocol that connects them
provides user access. Today X.500 is the most popular
services protocol on the Internet, connecting the address
of about 1,5 million individuals and 3,000 organizations. Whois++
the second popular protocol. X.500 and Whois++ may also be used
interconnect other information than only IWPS information, but
we only discuss the IWPS features
Alvestrand & Jurg Best Current Practice [Page 2]
RFC 2148 Internet White Pages Service September 1997
Note: there are other, not interconnected, address databases on
Internet that are also very popular for storing address
about people. "Ph" is a popular protocol for use with a stand-
database. There are over 300 registered Ph databases on
Internet. Interconnection of databases however, is highly
for an IWPS, since it ensures that data can be found. Hence Ph as
is now is not considered to be a good candidate for an IWPS,
future developments may change this situation (see section 12).
Currently X.500 must be recommended as the directory
protocol to be used for the IWPS. However, future technology may
it possible to use other protocols as well or instead
Since many people think that X.500 on the Internet will be
by other protocols in the near future, it should be mentioned
that currently LDAP is seen as the surviving component of today'
implementations and the main access protocol for tomorrow's
services. As soon as new technology (that will probably use LDAP
becomes available and experiments show that they work, this
will be updated
A summary of X.500 products can be found in [14] (a document
will be updated regularly).
The sections 3-7 below contain recommendations related to
publication of information in the IWPS that are independent of
directory services protocol. The sections 8-11 discuss X.500
issues. In section 12 some future developments are discussed as
can be foreseen at the time of writing this document
3. Who should publish IWPS information and how
IWPS information is public address information regarding
and organizations. The IWPS information concerning an
should be published and maintained by an organization that has
direct, durable link with this individual, like in the
cases
- The individual is employed by the maintainer's
- The individual is enrolled in the university/school
maintains the
- The individual is a (personal) subscriber of the maintainer'
Internet
Alvestrand & Jurg Best Current Practice [Page 3]
RFC 2148 Internet White Pages Service September 1997
The organization that maintains the data does not have to store
data in a local database of its own. Though running a local
in the X.500 or Whois++ service is not a too difficult job, it
recommended that Internet service providers provide
facilities for those organizations among its customers that
maintain a small part of the IWPS information or don't have
system management resources. This will encourage such
to join the IWPS. Collection of IWPS information and keeping it up
to-date should always be in the hands of the organization
information relates to
Within the current (national) naming schemes for X.500, entries
individuals reside under an organization. In the case of
service providers that hold the entries of their subscribers
would mean that individuals can only be found if one knows the
of the service provider. The problem of this restriction could
solved by using a more topographical approach in the X.500
scheme, but will more likely be solved by a future index service
directory services, which will allow searches for individuals
organization names (see section 12).
4. What kind of information should be published
The information to be published about an individual should at
include
- The individual's
- The individual's e-mail address, in RFC-822 format; if
present, some other contact information is to be
- Some indication of the individual's relationship with
When X.500 is used as directory services protocol the
requirement may be fulfilled by using the "organizationalStatus
attribute (see [3]) or by adding a special organizational unit to
local X.500 name space that reflects the relation (like ou=
or ou=employees).
Additionally some other public address information about
may be included in the IWPS
- The individual's phone
- The individual's fax
- The individual's postal
Alvestrand & Jurg Best Current Practice [Page 4]
RFC 2148 Internet White Pages Service September 1997
- The URL of the individual's home page on the
In the near future it will be a good idea to also store public
information
More information about a recommended Internet White Pages Schema
found in The Internet White Pages Schema [16]
Organizations should publish the following information
themselves in the IWPS
- The URL of the organizations home page on the
- Postal
- Fax
- Internet
- Various names and abbreviations for the organization
people can be expected to search for, such as the
name, and often the domain name of an organization
Organizations may also publish phone numbers and a presentation
themselves
5. Data
Data management, i.e. collecting the IWPS information and keeping
up-to-date, is a task that must not be underestimated for
organizations. The following recommendations can be made with
to these issues
- An organization should achieve an executive level
to start a local database with IWPS information. This
make it much easier to get cooperation from people within
organization that are to be involved in setting up
Directory Service
- An organization should decide on the kind of information
database should contain and how it should be structured.
should follow the Internet recommendations for
the information. Besides the criteria in the
section, [3] and [4] should be followed if X.500 is used
directory services protocol
Alvestrand & Jurg Best Current Practice [Page 5]
RFC 2148 Internet White Pages Service September 1997
- An organization should define criteria for the quality of
data in the Directory, like timeliness, update frequency
correctness, etc. These criteria should be
throughout the organization and contributing entities
commit to the defined quality levels
- Existing databases within an organization should be used
retrieve IWPS and local information, to the greatest
possible. An organization should involve the people
maintain those databases and make sure to get a
written commitment from them to use their data source.
organization should rely on these people, since they have
experience in management and control of local,
data
- The best motivation for an organization to join the IWPS
that they will have a local database for local purposes
the same time. A local database may contain more,
necessarily public, information and serve more purposes
is requested for in the IWPS. In connecting to the IWPS
organization must "filter out" the extra local
and services that is not meant for the public IWPS using
directory services protocol
6. Legal
Most countries have privacy laws regarding the publication
information about people. They range from the relaxed US laws to
UK requirement that information should be accurate to the
law that says that you can't publish unless you get
permission from the individual. Every maintainer of IWPS
should publish data according to the national law of the country
which the local database which holds the information resides
Some of these are documented in [5] and [1].
A maintainer of IWPS information should also follow some
rules, even when they are not legally imposed
- Publish only correct information
- Give people the possibility to view the information
about themselves and the right to withhold information
have information altered
- Don't publish information "just because it's there".
what is needed and what is thought useful, and no more
Alvestrand & Jurg Best Current Practice [Page 6]
RFC 2148 Internet White Pages Service September 1997
Given the number of data management and legal issues that
involved in publishing IWPS information, good consulting services
vital to have smaller companies quickly and efficiently join
IWPS. Internet service providers are encouraged to provide
services
7. Do not charge for
In the current IWPS it believed that due to today's
constraints, charging users is harmful to the viability of
service. There are several arguments for this belief
- Micropayment technology is not available at the moment
- Subscription services require either that the customer
up to multiple search services or that the services
linked "behind the scene" with all kinds of
agreements; both structures have unacceptably high
costs and increase the entry cost to the service
- The current directory services protocols do not
authentication to a level that would seem appropriate for
service that charges
Therefore it is strongly recommended that all lookups by users in
IWPS are for free. This, of course, does not limit in any way
ability to use the same IWPS dataset to support other services
charging may be appropriate
8. Use X.500
The IWPS based on the X.500 protocol has a relatively
deployment. The current service contains about 1,5 million entries
individuals and 3,000 of organizations. It is coordinated by Dante
an Internet service provider in the UK, and known as "NameFLOW
Paradise".
Though X.500 is sometimes criticized by the fact that
functionality is restricted by the hierarchical naming structure
imposes, it provides a reasonably good functionality as has
shown in several pilots by organizations [5], [2], [6], [7] that
now running a production X.500 IWPS. User interfaces also
the functionality the X.500 IWPS offers. Usually they offer
in the IWPS based on the following user input
- The name of a
- The name of an organization this person can be related
Alvestrand & Jurg Best Current Practice [Page 7]
RFC 2148 Internet White Pages Service September 1997
- The name of a
As a result they will provide the publicly available
about the person in question. Most user interfaces offer
possibility to list organizations in a country and users in
organization to help users to make their choice for the input. It
also be possible to use part of the names as input or
names
Specific user interfaces can provide lookups based on other input
like e-mail addresses of people or postal addresses of organizations
Such possibilities may however violate privacy laws. Providers
directory services services may then be held responsible
The X.500 naming scheme imposes the requirement on an
IWPS that all entries stored in it must have unique names (
"naming scheme"). This is most easily fulfilled by registering
entries in a "naming tree" with a single root; this is the reason
the totality of information in an X.500 IWPS is sometimes referred
as the "Directory Information Tree
or DIT
Organizations are strongly encouraged to use the X.500 protocol
joining the IWPS. The current service is based on the X.500 1988
standard [8] and some Internet-specific additions to the
that connects the local databases [10] and to the access
[9]. Organizations should use X.500 software based on
specifications and additionally supports [11] for the
of OSI protocols over the Internet
Organisations may connect to the NameFLOW-Paradise
with 1988 DSAs that don't implement [10], but they will
automatic replication of knowledge references. This will
inconvenient, but not a big problem. The 1993 standard of X.500
includes the functionality from [10], but uses a different potocol
Hence organisations that connect to the infrastructure with a 1993
DSA will also encounter this shortcoming. Section 12 "
developments" explains why the infrastructure doesn't use the 1993
standard for the moment
For recommendations on which attributes to use in X.500 and how
use them (either for public IWPS information or additional
information the reader is referred to [3] and [4]. For specific non
public local purposes also new attributes (and object classes) may
defined. Generally it should be recommended to use as much
possible the multi-valuedness of attributes in X.500 as this
improve the searching functionality of the service considerably.
example, the organizationalName attribute which holds the name of
Alvestrand & Jurg Best Current Practice [Page 8]
RFC 2148 Internet White Pages Service September 1997
organization or the commonName attribute which holds the name of
person should contain all known aliases for the organization
person. In particular it is important to add "readable" variants
all attributes that people are expected to search for, if
contain national characters
Another recommendation that can be made is that replication of
[10] between local databases is used in order to improve
performance of the service. Since replicating all entries of a
of the IWPS from one local database in another may violate
privacy laws, it is recommended to restrict replication to
and organizational entries and knowledge references (which tell
to go for which part of the IWPS). Of course privacy laws are
violated when the replicating database is managed by the
organization as the one that masters the information. So
replication between two databases within the same organization
highly recommended
In general replication within one country will usually be less
legal problem than across country borders
Recommendations for the operation of a database in the X.500
infrastructure can be found in [12].
X.500 is not recommended to be used for
- A Yellow Pages service with a large scope. See [5].
- Searching outside the limited patterns listed here,
particular searching for a person without knowing
organization he might be affiliated to
- Publishing information in other character sets than ASCII
some of the Latin-based European scripts and Japanese (
T.61 character sets). While support for these character
is available in revised versions of X.500, products
support the revision aren't commonly available yet
9. Use the global name
Some people, for instance when using Novell 4 servers, have
that they will use X.500 or X.500-like services as an internal
mechanism, without coordinating with an outside source
This suffers from many of the same problems as private IP addresses
only more so: your data may need significant restructuring once
decide to expose them to the outer world
Alvestrand & Jurg Best Current Practice [Page 9]
RFC 2148 Internet White Pages Service September 1997
A globally accessible X.500 service requires a globally
X.500 name space. See [3] and [4] for recommendations on how create
local part of the global name space
Though the standard is not very clear about this and the most
version (93) appears not to support it, in practice the X.500
space is only manageable if there is a single root context
under a cooperative agreement. However, one can be sure that
will be turf battles over it's control
If those turf battles aren't decided outside the actual
service, the effect on the service quality will be ruinous
This document appeals to all players in the field to let
practice alone until a better system is agreed and is ready to
into place; at the moment, the root context of the day is operated
the Dante NameFLOW-Paradise service
More information on the Dante NameFLOW-Paradise service is found
the
http://www.dante.net/nameflow.
10. Use
At the moment, LDAP as documented in [9] is the protocol that
the most X.500 functionality in places where it is not feasible
implement the full OSI stack
It is implemented on a lot of platforms, including several PC-
platforms, and is popular in a multitude of commercial offerings
A concerted effort to make LDAP available is the publication
that gives the widest access to the data
In addition, X.500 DSAs must implement the necessary linkages to
sure they are properly integrated into the naming/referral tree;
most cases, this will mean that they should implement the X.500
protocol at least
(The question of whether one gateways LDAP to DAP or DAP to LDAP
irrelevant in this context; it may be quite appropriate to store
on an LDAP-only server and make it available to the DAP/DSP-
world through a gateway if the major users all use LDAP
Alvestrand & Jurg Best Current Practice [Page 10]
RFC 2148 Internet White Pages Service September 1997
11. Make services
The technical investment in running an X.500 service is not enormous
see for example [5].
12. Future
Today [October 1996] there are several enhancements to be
with respect to IWPS technology
The most important one to be mentioned here is the creation of
"Common Indexing Protocol" that must enable the integration of X.500,
Whois++ and protocols that use stand-alone databases. Such a
would not only enable integration but would offer at the same
the possibility to explore yellow pages services and
searches, even if used for X.500 only
In the context of the Common Indexing Protocol the stand-alone
servers should be mentioned that are announced by several
developers. These are stand-alone address databases that can
accessed by LDAP. Currently also a public domain version is
from the University of Michigan. Also announced is an LDAP-to-
gateway that can integrate a stand-alone LDAP server in an X.500
infrastructure
Other improvements include defining a common core schema for
White Pages services, leading to the possibility of accessing data
multiple services through a single access protocol
The 1993 version of the X.500 standard has already been
in several products. It is an enhancement over the 1988 standard
several ways, but has not been implemented in the NameFLOW-
infrastructure yet. The main reason is that the standard doesn'
recognize the existence of a single root DSA, but assumes that
managers of first-level DSAs (the country DSA's) make
contracts for interconnection. In the case of NameFLOW-Paradise
a situation would be unmanageable. In [13] an enhancement of the 1993
standard is proposed that makes a single root possible. As soon
implementations of [13] are available, NameFLOW-Paradise
experiment with 1993 DSAs. This is expected in 1997.
Once these developments reach stability, they may be referenced
later versions of this BCP document
Alvestrand & Jurg Best Current Practice [Page 11]
RFC 2148 Internet White Pages Service September 1997
13. Security
The security implications of having a directory are many
- People will have a standard way to access the
published
- People will be able to gather parts of the information
purposes you never intended (like publishing directories
building search engines, headhunting or making
phone calls).
- People will attempt to access more of the information
you intended to publish, by trying to break
functions or eavesdropping on conversations other users
with the Directory
- If modification over the Net is possible, people will
to change your information in unintended ways.
users will change data by mistake, too; not all
change is malicious
The first defense for directory security is to limit your
to stuff you can live with having publicly available,
happens
The second defense involves trying to impose access control.
supports a few access control methods, including the use of
passwords. Cleartext passwords are not a secure mechanism in
presence of eavesdroppers; this document encourages use of
mechanisms if modification is made available over the open Internet
Otherwise, modification rights should be restricted to the
intranet
The third defense involves trying to prevent "inappropriate"
to the directory such as limiting the number of returned search
or refuse list operations where they are not useful to
"trolling". Such defenses are rarely completely successful,
it is very hard to set limits that differentiate between an
user doing wasteful searching and a malicous data troller
carefully limited searches
Future enhancements may include using encrypted sessions, public
logins and signed requests; such mechanisms are not
available today
Alvestrand & Jurg Best Current Practice [Page 12]
RFC 2148 Internet White Pages Service September 1997
14.
The authors wish to thank the following people for their
contributions to the text in this document
Peter Bachman
David Chadwick
William Curtin
Patrik Faltstrom
Rick Huber
Thomas Lenggenhager
Sri Saluteri
Mark Wahl critical-angle.com
15.
DAP Directory Access Protocol; protocol used between a DUA and
DSA to access the Directory Information. Part of X.500.
DSP Directory System Protocol: the protocol used between two
DSA Directory System Agent - entity that provides DUAs and
DSAs access to the information stored in the
LDAP Lightweight Directory Access Protocol - defined in RFC 1777
Further terms may be found in RFC 1983.
16.
[1] Jeunik, E. and E. Huizer. Directory Services and
Issues. Proceedings of Joint European Networking
1993, Trondheim
http://www.surfnet.nl/surfnet/diensten/x500/privacy.
[2] Jennings, B. Building an X.500 Directory Service in the US
RFC1943, May 1996.
[3] Barker, P., S. Kille, T. Lenggenhager, Building Naming
Structuring Guidelines for X.500 Directory Pilots, P. Barker
S. Kille, T. Lenggenhager, RFC1617
Alvestrand & Jurg Best Current Practice [Page 13]
RFC 2148 Internet White Pages Service September 1997
[4] The COSINE and Internet X.500 Schema. P. Barker & S. Kille
RFC1274
[5] Introducing a Directory Service, SURFnet report 1995 (
URL
http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/)
[6] Paradise International Reports, University College London
April 1991 - April 1994
[7] Naming Guidelines for the AARNet X.500 Directory Service
Michaelson and Prior, RFC 1562
[8] CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988
[9] Lightweight Directory Access Protocol, W. Yeong, T. Howes, S
Kille, RFC1777
[10] Replication and Distributed Operations extensions to
an Internet Directory using X.500, S. Kille, RFC1276
[11] ISO transport services on top of the TCP: Version: 3, M
Rose, D. Cass, RFC1006
[12] Recommendations for an X.500 Production Directory Service, R
Wright et al., RFC1803
[13] Managing the X.500 Root Naming Context, D. Chadwick,
[14] A Revised Catalog of Available X.500 Implementations, A
Getchell, S. Sataluri, RFC1632
[15] A Naming Scheme for c=US, The North American Directory Forum
RFC1255
[16] A Common Schema for the Internet White Pages Service, T
Genovese, B. Jennings, Work In Progress
[17] Key words for use in RFCs to Indicate Requirement Level, S
Bradner, RFC 2119,
Alvestrand & Jurg Best Current Practice [Page 14]
RFC 2148 Internet White Pages Service September 1997
17. Authors
Harald Tveit
P.O.Box 6883
N-7002
+47 73 59 70 94
Harald.T.Alvestrand@uninett.
Peter
P.O.Box 19035
NL-3501 DA
THE
+31 30 2305305
Peter.Jurg@surfnet.
Alvestrand & Jurg Best Current Practice [Page 15]
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
