rfc2148.txt

中、英文RFC文档大全打包下载完全版 .


RFC 2148              Internet White Pages Service        September 1997


   -    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 organization 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 information resides.

   Some of these are documented in [5] and [1].

   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 withhold information or
        have information altered.

   -    Don't publish information "just because it's there". Publish
        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 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

   In the current IWPS it believed that due to today's 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.

   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 1,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 [5], [2], [6], [7] 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



Alvestrand & Jurg        Best Current Practice                  [Page 7]

RFC 2148              Internet White Pages Service        September 1997


   -    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. Providers of
   directory services services may then be held responsible.

   The X.500 naming scheme imposes the requirement on an interconnected
   IWPS that all entries stored in it must have unique names (the
   "naming scheme"). This is most easily fulfilled by registering all
   entries in a "naming tree" with a single root; this is the reason why
   the totality of information in an X.500 IWPS is sometimes referred to
   as the "Directory Information Tree"
    or DIT.

   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 [8] and some Internet-specific additions to the protocol
   that connects the local databases [10] and to the access protocol
   [9]. Organizations should use X.500 software based on these
   specifications and additionally supports [11] for the transportation
   of OSI protocols over the Internet.

   Organisations may connect to the NameFLOW-Paradise infrastructure
   with 1988 DSAs that don't implement [10], but they will lack
   automatic replication of knowledge references. This will be
   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 "Future
   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 to
   use them (either for public IWPS information or additional local
   information the reader is referred to [3] and [4]. 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 organizationalName attribute which holds the name of an



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 a
   person should contain all known aliases for the organization or
   person. In particular it is important to add "readable" variants of
   all attributes that people are expected to search for, if they
   contain national characters.

   Another recommendation that can be made is that replication of data
   [10] 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.

   In general replication within one country will usually be less a
   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, 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). While support for these character sets
         is available in revised versions of X.500, products that
         support the revision aren't commonly available yet.

9.  Use the global name space

   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.




Alvestrand & Jurg        Best Current Practice                  [Page 9]

RFC 2148              Internet White Pages Service        September 1997


   A globally accessible X.500 service requires a globally connected
   X.500 name space. See [3] and [4] for recommendations on how create a
   local part of the global name space.

   Though the standard is not very clear about this and the most recent
   version (93) appears not to support it, in practice the X.500 name
   space is only manageable if there is a single root context operated
   under a cooperative agreement. However, one can be sure that there
   will be turf battles over it's control.

   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-Paradise service.

   More information on the Dante NameFLOW-Paradise service is found at
   the URL

   http://www.dante.net/nameflow.html

10.  Use LDAP

   At the moment, LDAP as documented in [9] 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, X.500 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
   irrelevant in this context; it may be quite appropriate to store data
   on an LDAP-only server and make it available to the DAP/DSP-running
   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