draft BCP for the Internet White Pages Service April 96
Best Current Practice for the Internet White Pages Service
Tue Feb 13 14:38:43 MET 1996
Harald Tveit Alvestrand
UNINETT
Harald.T.Alvestrand@uninett.no
Peter Jurg
SURFnet
Peter.Jurg@surfnet.nl
<draft-ietf-ids-ds-bcp-00.txt>
Status of this Memo
Please send comments to the author.
The following text is required by the Internet-draft rules:
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."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
The file name of this version is draft-ietf-ids-ds-bcp-00.txt
Alvestrand, Jurg Expires September 96 [Page 1]
draft BCP for the Internet White Pages Service April 96
*** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
WARNING: This document contains text that might be harmful to
senior persons' blood pressure. Distribute with care!
*** DRAFT *** DRAFT *** DRAFT *** DRAFT ***
1. Summary and recommendations
This document makes the following recommendations for
organizations on the Internet:
(1) An organization SHOULD publish the E-mail addresses and
some other info about Internet users within their site.
(2) It MUST do this in accordance with the laws of the land,
and SHOULD also follow the recommendations of [PRIVACY]
(3) It SHOULD publish the information using X.500 as its data
structure and naming scheme. It MAY additionally publish it
using additional data structures such as whois++.
(4) It SHOULD make the published information available to LDAP
clients, by supporting an LDAP server for those data.
(5) It SHOULD NOT attempt to charge for simple access to the
data.
In addition, it makes the following recommendations for various
and sundry other parties:
(1) E-mail vendors SHOULD include LDAP lookup functionality
into their products, either as built-in functionality or by
providing translation facilities.
(2) Internet Service providers SHOULD help smaller
organizations follow this recommendation, either by
providing services for hosting their data, by helping them
find other parties to do so, or by helping them bring their
own service on-line.
(3) All interested parties SHOULD make sure there only exists
one X.500 namespace in the world, and that all names in
Alvestrand, Jurg Expires September 96 [Page 2]
draft BCP for the Internet White Pages Service April 96
this namespace are resolvable.
The rest of this document is justification and details for this
recommendation.
2. Introduction
The Internet is used for information exchange and communication
between its users. It can only be effective as such if users are
able to find each other's addresses. Therefore the Internet
benefits from an adequate White Pages Service, i.e. a directory
service offering (Internet) address information related to people
and organizations.
This document describes the way in which the Internet White Pages
Service (from now on abbreviated as IWPS) is best exploited using
today's experience, today's protocols, today's products and
today's procedures.
Experience ([SURFNET], [ESNET]....) has shown that a White Pages
Service based on self-registration of users or on centralized
servers tends to gather data in a haphazard fashion, and,
moreover, collects data that ages rapidly and is not kept up to
date.
The most vital attempts to establish the IWPS are based on models
with distributed (local) databases each holding a manageable part
of the IWPS- information. Such a part mostly exists of all
relevant IWPS- information from within a particular organisation
or from within an Internet service provider and its users. On top
of the databases there is a directory services protocol that
connects them and provides user access. Today X.500 is the most
popular directory services protocol on the Internet, connecting
the address information of about 1.5 million individuals and 3,000
organisations. Whois++ is the second popular protocol. X.500 and
Whois++ may also be used to interconnect other information than
only IWPS- information, but here we only discuss the IWPS
features.
Currently X.500 must be recommended as the directory services
protocol to be used for the IWPS. However, future technology may
make it possible to use other protocols as well or instead. When
Alvestrand, Jurg Expires September 96 [Page 3]
draft BCP for the Internet White Pages Service April 96
such technology becomes available and experiments show that they
work, this document will be updated.
The sections 3-7 below contain recommendations related to the
publication of information in the IWPS that are independent of a
directory services protocol. The remainig sections discuss X.500
specific issues.
3. Who should publish IWPS- information and how?
IWPS- information is public address information regarding
individuals and organizations. IWPS- information of an individual
should be published and maintained by an organization that has a
direct, durable link with this individual, like in the following
cases:
- The individual is employed by the maintainer's organization
- The individual is enrolled in the university/school that
maintains the data
- The individual is a (personal) subscriber of the maintainer's
Internet service
The organization that maintains the data doesn't have to store the
data in a local database of its own. Though running a local
database in the X.500 or Whois++ service is not a too difficult
job, it is recommended that Internet service providers provide
database facilities for those organizations among its customers
that only maintain a small part of the IWPS- information or don't
have enough system management resources. This will encourage such
organizations to join the IWPS. Collection of IWPS- information
and keeping it up-to-date should always be in the hands of the
organization the information relates to.
4. What kind of information should be published?
The information to be published about an individual should at
least include:
Alvestrand, Jurg Expires September 96 [Page 4]
draft BCP for the Internet White Pages Service April 96
- The individual's name
- The individual's e-mail address, in RFC-822 format
- Some indication of the individual's relationship with the
maintainer
When X.500 is used as directory services protocol the last
requirement may be fulfilled by using the "organizationalStatus"
attribute (see [RFC1617]) or by adding a special organizational
unit to the local X.500 namespace that reflects the the relation
(like ou=students or ou=employees).
Additionally some other public address information about
individuals may be included in the IWPS:
- The individual's phone number
- The individual's fax number
- The individual's postal address
- The URL of the individual's home page on the Web
Organizations should publish the following information about
themselves in the IWPS:
- The URL of the organization's home page on the Web
- Postal address
Organizations may also publish phone numbers.
5. Data management
Data management, i.e. collecting the IWPS- information and keeping
it up-to-date is a task that must not be underestimated for larger
organizations. The following recommendations can be made with
respect to these issues:
- An organization should achieve an executive level commitment
to start a local database with IWPS- information. This will
Alvestrand, Jurg Expires September 96 [Page 5]
draft BCP for the Internet White Pages Service April 96
make it much easier to get cooperation from people within the
organisation that are to be involved in setting up a
Directory Service.
- An organization should decide on the kind of information the
database should contain and how it should be structured. It
should follow the Internet recommendations for structuring
the information. Besides the criteria in the previous
section, [RFC-1274] and [RFC-1617]] should be followed if
X.500 is used as directory services protocol.
- An organization should define criteria for the quality of the
data in the Directory, like timeliness, update frequency,
correctness, etc. These criteria should be communicated
throughout the organization and contributing entities should
commit to the defined quality levels.
- Existing databases within an organisation should be used to
retrieve IWPS- and local information, to the greatest extent
possible. An organization should involve the people who
maintain those databases and make sure to get a formal
written commitment from them to use their data source. The
organization should rely on these people, since they have the
experience in management and control of local, available
data.
- The best motivation for an organization to join the IWPS is
that they will have a local database for local purposes at
the same time. A local database may contain more, not
necessarily public, information and serve more purposes than
is requested for in the IWPS. In connecting to the IWPS an
organization must "filter out" the extra local information
and services that is not meant for the public IWPS using the
directory services protocol.
6. Legal issues
Most countries have privacy laws regarding the publication of
information about people. They range from the relaxed US laws to
the UK requirement that information should be accurate to the
Norwegian law that says that you can't publish unless you get
specific permission from the individual. Every maintainer of IWPS-
information should publish data according to the national law of
the country in which the local database which holds the
Alvestrand, Jurg Expires September 96 [Page 6]
draft BCP for the Internet White Pages Service April 96
information resides.
Some of these are documented in [SURFNET] and [PRIVACY].
A maintainer of IWPS- information should also follow some common
rules, even when they are not legally imposed:
- Publish only correct information.
- Give people the possibility to view the information stored
about themselves and the right to withold information or have
information altered.
- Don't publish information "just because it's there". Publish
what's needed and what's thought useful, and no more.
Given the number of data management and legal issues that are
involved in publishing IWPS- information, good consulting services
are vital to have smaller companies quickly and efficiently join
the IWPS. Internet service providers are encouraged to provide
such services.
7. Do not charge for lookups
A very common question with respect to the IWPS is how it has to
be financed. In the current IWPS it believed that due to todays
technological constraints, charging users is harmful to the
viability of the service. There are several arguments for this
belief:
- Micropayment technology is not available at the moment.
- Subscription services require either that the customer sign
up to multiple search services or that the services are
linked "behind the scene" with all kinds of bilateral
agreements; both structures have unacceptably high overhead
costs and increase the entry cost to the service.
- The current directory services protocols do not support
authentication to a level that would seem appropriate for a
service that charges.
Alvestrand, Jurg Expires September 96 [Page 7]
draft BCP for the Internet White Pages Service April 96
Therefore it is strongly recommended that all lookups by users in
the IWPS are for free. This, of course, does not limit in any way
the ability to use the same IWPS dataset to support other services
where charging may be appropriate.
8. Use X.500
The IWPS based on the X.500 protocol has a relatively wide
deployment. The current service contains about 3,5 million entries
of 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 its
functionality is restricted by the hierarchical naming structure
it imposes, it provides a reasonably good functionality as has
been shown in several pilots by organizations [SURFNET], [ESNET],
[PARADISE], [AARNET] that are now running a production X.500 IWPS.
User interfaces also determine the functionality the X.500 IWPS
offers. Usually they offer lookups in the IWPS based on the
following user input:
- The name of a person
- The name of an organization this person can be related to
- The name of a country
As a result they will provide the publicly available information
about the person in question. Most user interfaces offer the
possibility to list organizations in a country and users in an
organization to help users to make their choice for the input. It
may also be possible to use part of the names as input or
approximate 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.
See Appendix A for the algorithms used to achieve the
functionality that is mentioned.
Alvestrand, Jurg Expires September 96 [Page 8]
draft BCP for the Internet White Pages Service April 96
Organizations are strongly encouraged to use the X.500 protocol
for joining the IWPS. The current service is based on the X.500
1988 standard [xxx] and some Internet-specific additions to the
protocol that connects the local databases [Kille] and to the
access protocol [LDAP]. Organizations should use X.500 software
based on these specifications and additionally supports [RFC1006]
for the transportation of OSI protocols over the Internet.
For recommendations on which attributes to use in X.500 and how to
use them (either for public IWPS- information or additional local
information the reader is referred to [RFC1274] and [RFC1617]. For
specific non-public local purposes also new attributes (and object
classes) may be defined. Generally it should be recommended to
use as much as possible the multi-valuedness of attributes in
X.500 as this will improve the searching functionality of the
service considerably. For example, the commonName attribute which
can hold the common name of an organisation or person should
contain all known aliases for the organization or person.
Another recommendation that can be made is that replication of
data [Kille] between local databases is used in order to improve
the performance of the service. Since replicating all entries of a
part of the IWPS from one local database in another may violate
local privacy laws, it is recommended to restrict replication to
country and organizational entries and knowledge references (which
tell where to go for which part of the IWPS). Of course privacy
laws are not violated when the replicating database is managed by
the same organization as the one that masters the information. So
local replication between two databases within the same
organization is highly recommended.
X.500 is not recommended to be used for:
- A Yellow Pages service with a large scope. See [SURFnet].
- Searching outside the limited patterns listed here, in
particular searching for a person without knowing which
organization he might be affiliated to.
- Publishing information in other character sets than ASCII,
some of the Latin-based European scripts and Japanese (the
T.61 character sets). ISO is revising X.500, but products
that support the revision aren't available yet.
Alvestrand, Jurg Expires September 96 [Page 9]
draft BCP for the Internet White Pages Service April 96
9. Use the global namespace
Some people, for instance when using Novell 4 servers, have
decided that they will use X.500 or X.500-like services as an
internal naming 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 you decide to expose them to the outer world.
A globally accessible X.500 service requires a globally connected
X.500 namespace.
10. Use LDAP
At the moment, LDAP as documented in [LDAP] is the protocol that
offers the most X.500 functionality in places where it is not
feasible to implement the full OSI stack.
It is implemented on a lot of platforms, including several PC-type
platforms, and is popular in a multitude of commercial offerings.
A concerted effort to make LDAP available is the publication
method that gives the widest access to the data.
In addition, DSAs must implement the necessary linkages to make
sure they are properly integrated into the naming/referral tree;
in most cases, this will mean that they should implement the X.500
DSP protocol at least.
(The question of whether one gateways LDAP to DAP or DAP to LDAP
is irrelvant in this context)
11. Make services available
The technical investment in running an X.500 service is not
enormous.
Alvestrand, Jurg Expires September 96 [Page 10]
draft BCP for the Internet White Pages Service April 96
12. Name globally
Given that X.500 practically dictates that there should be a
single root context operated under a cooperative agreement, one
can be sure that there will be turf battles over its control.
However, if those turf battles aren't decided outside the actual
running service, the effect on the service quality will be
ruinous.
This document appeals to all players in the field to let existing
practice alone until a better system is agreed and is ready to go
into place; at the moment, the root context of the day is operated
by the DANTE NameFlow project.
13. Security considerations
Security issues WILL BE considered in this memo.
14. References
[DUMMY REFERENCE]
Here is the title of the reference
15. Author's address
Harald Tveit Alvestrand
UNINETT
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
+47 73 59 70 94
Harald.T.Alvestrand@uninett.no
Peter Jurg
SURFnet
P.O.Box 19035
NL-3501 DA UTRECHT
THE NETHERLANDS
Alvestrand, Jurg Expires September 96 [Page 11]
draft BCP for the Internet White Pages Service April 96
+31 30 2305305
Peter.Jurg@surfnet.nl
APPENDIX A - Algorithms
In pseudocode, the algorithms for X.500 searches used go like
this:
To get from (country, company, name) to entry:
1) Search, single-level, the Root context for the country.
Set the current location to this country.
2) Search, single-level, the current context for the Organization and
any Locality entries.
Add the Locality entries to the list of possible search contexts.
3) If the organization is not found, take the first context in the
list of possible search contexts and go to 2).
4) When the organization is found, search, whole subtree, for the
person name.
This algorithm requires:
- That the company name be unique within the country.
Otherwise, first match may be returned.
- That the person name be unique within the company. Otherwise,
multiple matches will be returned.
- That the whole subtree search is allowed across the whole
company.
This process can be considerably speeded up by a periodic
searching of the country for all Organizations and storing these
in a cache or private alias tree; however, this requires special
code in the client.
To get from E-mail address to entry:
1) Take the last component of the domainname as the search object,
and the root context as the only possible search context.
Alvestrand, Jurg Expires September 96 [Page 12]
draft BCP for the Internet White Pages Service April 96
2) Search, single-level, all the currently possible search contexts
for the attribute "AssociatedDomain" with the value of the search object.
3) If at least one search was successful, take the list of found objects as
the list of possible search contexts.
Otherwise, keep the old set.
4) If there are more components of the domainname, add one more
component of the domainname to the search object, and go to 2)
5) If the search failed, or there are no more domain components,
search, whole-subtree, for the attribute "RFC822Address" with the
whole E-mail address as its value.
This algorithm requires:
- That AssociatedDomain be populated throughout the tree. Note
that jumps are allowed; having "nexor.co.uk" directly under
"C=gb/assocDomain=uk" is not a problem.
- That *all* entries having some entry under them in a given
domain have the corresponding shortened AssociatedDomain; for
instance, many countries would need to show the "com"
AssociatedDomain.
Alvestrand, Jurg Expires September 96 [Page 13]
