home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ids-ds-bcp-01.txt < prev    next >
Text File  |  1996-10-02  |  26KB  |  812 lines
  1.  
  2. draft          BCP for the Internet White Pages Service   September 96
  3.  
  4.  
  5.     Best Current Practice for the Internet White Pages Service
  6.  
  7.              Tue Sep 24 15:29:10 MET DST 1996
  8.  
  9.  
  10.              Harald Tveit Alvestrand
  11.                  UNINETT
  12.               Harald.T.Alvestrand@uninett.no
  13.  
  14.  
  15.  
  16.  
  17.  
  18.                 Peter Jurg
  19.                  SURFnet
  20.               Peter.Jurg@surfnet.nl
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.     Status of this Memo
  28.  
  29.     Please send comments to the author.
  30.  
  31.     The following text is required by the Internet-draft rules:
  32.  
  33.     This document is an Internet Draft.  Internet Drafts are working
  34.     documents of the Internet Engineering Task Force (IETF), its
  35.     Areas, and its Working Groups. Note that other groups may also
  36.     distribute working documents as Internet Drafts.
  37.  
  38.     Internet Drafts are draft documents valid for a maximum of six
  39.     months. Internet Drafts may be updated, replaced, or obsoleted by
  40.     other documents at any time.  It is not appropriate to use
  41.     Internet Drafts as reference material or to cite them other than
  42.     as a "working draft" or "work in progress."
  43.  
  44.     Please check the I-D abstract listing contained in each Internet
  45.     Draft directory to learn the current status of this or any other
  46.     Internet Draft.
  47.  
  48.     The file name of this version is draft-ietf-ids-ds-bcp-01.txt
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Alvestrand, Jurg           Expires March 97                   [Page 1]
  55.  
  56. draft          BCP for the Internet White Pages Service   September 96
  57.  
  58.  
  59.     1.  Summary and recommendations
  60.  
  61.  
  62.     This document makes the following recommendations for
  63.     organizations on the Internet:
  64.  
  65.      (1)   An organization SHOULD publish public E-mail addresses and
  66.        other public address information about Internet users
  67.        within their site.
  68.  
  69.      (2)   The organization MUST do this in accordance with the laws
  70.        of the country in which it resides, and SHOULD also follow
  71.        the recommendations of [1]
  72.  
  73.      (3)   The preferable way for publishing the information is by
  74.        using X.500 as its data structure and naming scheme. The
  75.        organization MAY additionally publish it using additional
  76.        data structures such as whois++.
  77.  
  78.      (4)   The organization SHOULD make the published information
  79.        available to LDAP clients, by supporting an LDAP server for
  80.        those data.
  81.  
  82.      (5)   The organization SHOULD NOT attempt to charge for simple
  83.        access to the data.
  84.  
  85.     In addition, it makes the following recommendations for various
  86.     and sundry other parties:
  87.  
  88.  
  89.      (1)   E-mail vendors SHOULD include LDAP lookup functionality
  90.        into their products, either as built-in functionality or by
  91.        providing translation facilities.
  92.  
  93.      (2)   Internet Service providers SHOULD help smaller
  94.        organizations follow this recommendation, either by
  95.        providing services for hosting their data, by helping them
  96.        find other parties to do so, or by helping them bring their
  97.        own service on-line.
  98.  
  99.      (3)   All interested parties SHOULD make sure there exists a
  100.        single X.500 name space in the world, and that all names in
  101.        this name space are resolvable.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108. Alvestrand, Jurg           Expires March 97                   [Page 2]
  109.  
  110. draft          BCP for the Internet White Pages Service   September 96
  111.  
  112.  
  113.     The rest of this document is justification and details for this
  114.     recommendation.
  115.  
  116.  
  117.     2.  Introduction
  118.  
  119.     The Internet is used for information exchange and communication
  120.     between its users. It can only be effective as such if users are
  121.     able to find each others addresses. Therefore the Internet
  122.     benefits from an adequate White Pages Service, i.e., a directory
  123.     service offering (Internet) address information related to people
  124.     and organizations.
  125.  
  126.     This document describes the way in which the Internet White Pages
  127.     Service (from now on abbreviated as IWPS) is best exploited using
  128.     todays experience, todays protocols, todays products and todays
  129.     procedures.
  130.  
  131.     Experience [2] has shown that a White Pages Service based on self-
  132.     registration of users or on centralized servers tends to gather
  133.     data in a haphazard fashion, and, moreover, collects data that
  134.     ages rapidly and is not kept up to date.
  135.  
  136.     The most vital attempts to establish the IWPS are based on models
  137.     with distributed (local) databases each holding a manageable part
  138.     of the IWPS- information. Such a part mostly exists of all
  139.     relevant IWPS- information from within a particular organization
  140.     or from within an Internet service provider and its users. On top
  141.     of the databases there is a directory services protocol that
  142.     connects them and provides user access. Today X.500 is the most
  143.     popular directory services protocol on the Internet, connecting
  144.     the address information of about 1.5 million individuals and 3,000
  145.     organizations. Whois++ is the second popular protocol. X.500 and
  146.     Whois++ may also be used to interconnect other information than
  147.     only IWPS- information, but here we only discuss the IWPS
  148.     features.
  149.  
  150.     Note: there are other, not interconnected, address databases on
  151.     the Internet that are also very popular for storing address
  152.     information about people. "Ph" is a popular protocol for use with
  153.     a stand-alone database.  There are over 300 registered ph
  154.     databases on the Internet. Inter connection of databases however,
  155.     is highly recommended for an IWPS, since it ensures that data can
  156.     be found. Hence ph as such is not considered to be a good
  157.  
  158.  
  159.  
  160.  
  161.  
  162. Alvestrand, Jurg           Expires March 97                   [Page 3]
  163.  
  164. draft          BCP for the Internet White Pages Service   September 96
  165.  
  166.  
  167.     candidate for an IWPS, but future developments may change this
  168.     situation (see section 13).
  169.  
  170.     Currently X.500 must be recommended as the directory services
  171.     protocol to be used for the IWPS. However, future technology may
  172.     make it possible to use other protocols as well or instead. When
  173.     such technology becomes available and experiments show that they
  174.     work, this document will be updated.
  175.  
  176.     The sections 3-7 below contain recommendations related to the
  177.     publication of information in the IWPS that are independent of a
  178.     directory services protocol. The sections 8-12 discuss X.500
  179.     specific issues. In section 13 some future developments are
  180.     discussed as they can be foreseen at the time of writing this
  181.     document.
  182.  
  183.  
  184.  
  185.     3.  Who should publish IWPS- information and how?
  186.  
  187.     IWPS- information is public address information regarding
  188.     individuals and organizations. IWPS- information of an individual
  189.     should be published and maintained by an organization that has a
  190.     direct, durable link with this individual, like in the following
  191.     cases:
  192.  
  193.  
  194.     -    The individual is employed by the maintainers organization
  195.  
  196.     -    The individual is enrolled in the university/school that
  197.      maintains the data
  198.  
  199.     -    The individual is a (personal) subscriber of the maintainers
  200.      Internet service
  201.  
  202.     The organization that maintains the data does not have to store
  203.     the data in a local database of its own. Though running a local
  204.     database in the X.500 or Whois++ service is not a too difficult
  205.     job, it is recommended that Internet service providers provide
  206.     database facilities for those organizations among its customers
  207.     that only maintain a small part of the IWPS- information or dont
  208.     have enough system management resources. This will encourage such
  209.     organizations to join the IWPS. Collection of IWPS- information
  210.     and keeping it up-to-date should always be in the hands of the
  211.  
  212.  
  213.  
  214.  
  215.  
  216. Alvestrand, Jurg           Expires March 97                   [Page 4]
  217.  
  218. draft          BCP for the Internet White Pages Service   September 96
  219.  
  220.  
  221.     organization the information relates to.
  222.  
  223.  
  224.  
  225.     4.  What kind of information should be published?
  226.  
  227.     The information to be published about an individual should at
  228.     least include:
  229.  
  230.     -    The individuals name
  231.  
  232.     -    The individuals e-mail address, in RFC-822 format; if not
  233.      present, some other contact information is to be included
  234.  
  235.     -    Some indication of the individuals relationship with the
  236.      maintainer
  237.  
  238.     When X.500 is used as directory services protocol the last
  239.     requirement may be fulfilled by using the "organizationalStatus"
  240.     attribute (see [3]) or by adding a special organizational unit to
  241.     the local X.500 name space that reflects the relation (like
  242.     ou=students or ou=employees).
  243.  
  244.     Additionally some other public address information about
  245.     individuals may be included in the IWPS:
  246.  
  247.     -    The individuals phone number
  248.  
  249.     -    The individuals fax number
  250.  
  251.     -    The individuals postal address
  252.  
  253.     -    The URL of the individuals home page on the Web
  254.  
  255.     In the near future it will be a good idea to also store public key
  256.     information.  Organizations should publish the following
  257.     information about themselves in the IWPS:
  258.  
  259.     -    The URL of the organizations home page on the Web
  260.  
  261.     -    Postal address
  262.  
  263.      Fax numbers
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270. Alvestrand, Jurg           Expires March 97                   [Page 5]
  271.  
  272. draft          BCP for the Internet White Pages Service   September 96
  273.  
  274.  
  275.      Internet domain
  276.  
  277.      Various names and abbreviations for the organization that
  278.      people can be expected to search for, such as the English
  279.      name, and often the 1st component of the domain name.
  280.  
  281.  
  282.     Organizations may also publish phone numbers and a presentation of
  283.     themselves.
  284.  
  285.  
  286.     5.  Data management
  287.  
  288.     Data management, i.e.,  Collecting the IWPS- information and
  289.     keeping it up-to-date is a task that must not be underestimated
  290.     for larger organizations. The following recommendations can be
  291.     made with respect to these issues:
  292.  
  293.  
  294.     -    An organization should achieve an executive level commitment
  295.      to start a local database with IWPS- information. This will
  296.      make it much easier to get cooperation from people within the
  297.      organization that are to be involved in setting up a
  298.      Directory Service.
  299.  
  300.     -    An organization should decide on the kind of information the
  301.      database should contain and how it should be structured. It
  302.      should follow the Internet recommendations for structuring
  303.      the information. Besides the criteria in the previous
  304.      section, [3] and [4] should be followed if X.500 is used as
  305.      directory services protocol.
  306.  
  307.     -    An organization should define criteria for the quality of the
  308.      data in the Directory, like timeliness, update frequency,
  309.      correctness, etc. These criteria should be communicated
  310.      throughout the organization and contributing entities should
  311.      commit to the defined quality levels.
  312.  
  313.     -    Existing databases within an organization should be used to
  314.      retrieve IWPS- and local information, to the greatest extent
  315.      possible. An organization should involve the people who
  316.      maintain those databases and make sure to get a formal
  317.      written commitment from them to use their data source. The
  318.      organization should rely on these people, since they have the
  319.  
  320.  
  321.  
  322.  
  323.  
  324. Alvestrand, Jurg           Expires March 97                   [Page 6]
  325.  
  326. draft          BCP for the Internet White Pages Service   September 96
  327.  
  328.  
  329.      experience in management and control of local, available
  330.      data.
  331.  
  332.     -    The best motivation for an organization to join the IWPS is
  333.      that they will have a local database for local purposes at
  334.      the same time. A local database may contain more, not
  335.      necessarily public, information and serve more purposes than
  336.      is requested for in the IWPS. In connecting to the IWPS an
  337.      organization must "filter out" the extra local information
  338.      and services that is not meant for the public IWPS using the
  339.      directory services protocol.
  340.  
  341.     6.  Legal issues
  342.  
  343.     Most countries have privacy laws regarding the publication of
  344.     information about people. They range from the relaxed US laws to
  345.     the UK requirement that information should be accurate to the
  346.     Norwegian law that says that you cant publish unless you get
  347.     specific permission from the individual. Every maintainer of IWPS-
  348.     information should publish data according to the national law of
  349.     the country in which the local database which holds the
  350.     information resides.
  351.  
  352.     Some of these are documented in [5] and [1].
  353.  
  354.     A maintainer of IWPS- information should also follow some common
  355.     rules, even when they are not legally imposed:
  356.  
  357.     -    Publish only correct information.
  358.  
  359.     -    Give people the possibility to view the information stored
  360.      about themselves and the right to withhold information or
  361.      have information altered.
  362.  
  363.     -    Dont publish information "just because its there". Publish
  364.      whats needed and whats thought useful, and no more.
  365.  
  366.     Given the number of data management and legal issues that are
  367.     involved in publishing IWPS- information, good consulting services
  368.     are vital to have smaller companies quickly and efficiently join
  369.     the IWPS. Internet service providers are encouraged to provide
  370.     such services.
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378. Alvestrand, Jurg           Expires March 97                   [Page 7]
  379.  
  380. draft          BCP for the Internet White Pages Service   September 96
  381.  
  382.  
  383.     7.  Do not charge for lookups
  384.  
  385.     A very common question with respect to the IWPS is how it has to
  386.     be financed. In the current IWPS it believed that due to todays
  387.     technological constraints, charging users is harmful to the
  388.     viability of the service.  There are several arguments for this
  389.     belief:
  390.  
  391.     -    Micropayment technology is not available at the moment.
  392.  
  393.     -    Subscription services require either that the customer sign
  394.      up to multiple search services or that the services are
  395.      linked "behind the scene" with all kinds of bilateral
  396.      agreements; both structures have unacceptably high overhead
  397.      costs and increase the entry cost to the service.
  398.  
  399.     -    The current directory services protocols do not support
  400.      authentication to a level that would seem appropriate for a
  401.      service that charges.
  402.  
  403.     Therefore it is strongly recommended that all lookups by users in
  404.     the IWPS are for free.  This, of course, does not limit in any way
  405.     the ability to use the same IWPS dataset to support other services
  406.     where charging may be appropriate.
  407.  
  408.  
  409.  
  410.     8.  Use X.500
  411.  
  412.     The IWPS based on the X.500 protocol has a relatively wide
  413.     deployment. The current service contains about 3,5 million entries
  414.     of individuals and 3,000 of organizations. It is coordinated by
  415.     Dante, an Internet service provider in the UK, and known as
  416.     "Nameflow/Paradise".
  417.  
  418.     Though X.500 is sometimes criticized by the fact that its
  419.     functionality is restricted by the hierarchical naming structure
  420.     it imposes, it provides a reasonably good functionality as has
  421.     been shown in several pilots by organizations [5], [2], [6], [7]
  422.     that are now running a production X.500 IWPS. User interfaces also
  423.     determine the functionality the X.500 IWPS offers. Usually they
  424.     offer lookups in the IWPS based on the following user input:
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432. Alvestrand, Jurg           Expires March 97                   [Page 8]
  433.  
  434. draft          BCP for the Internet White Pages Service   September 96
  435.  
  436.  
  437.     -    The name of a person
  438.  
  439.     -    The name of an organization this person can be related to
  440.  
  441.     -    The name of a country
  442.  
  443.     As a result they will provide the publicly available information
  444.     about the person in question. Most user interfaces offer the
  445.     possibility to list organizations in a country and users in an
  446.     organization to help users to make their choice for the input. It
  447.     may also be possible to use part of the names as input or
  448.     approximate names.
  449.  
  450.     Specific user interfaces can provide lookups based on other input,
  451.     like e-mail addresses of people or postal addresses of
  452.     organizations. Such possibilities may however violate privacy
  453.     laws.
  454.  
  455.     Organizations are strongly encouraged to use the X.500 protocol
  456.     for joining the IWPS. The current service is based on the X.500
  457.     1988 standard [8] and some Internet-specific additions to the
  458.     protocol that connects the local databases [10] and to the access
  459.     protocol [9]. Organizations should use X.500 software based on
  460.     these specifications and additionally supports [11] for the
  461.     transportation of OSI protocols over the Internet.
  462.  
  463.     For recommendations on which attributes to use in X.500 and how to
  464.     use them (either for public IWPS- information or additional local
  465.     information the reader is referred to [3] and [4]. For specific
  466.     non-public local purposes also new attributes (and object classes)
  467.     may be defined.  Generally it should be recommended to use as much
  468.     as possible the multi-valuedness of attributes in X.500 as this
  469.     will improve the searching functionality of the service
  470.     considerably. For example, the organizationalName attribute which
  471.     holds the name of an organization or the commonName attribute
  472.     which holds the name of a person should contain all known aliases
  473.     for the organization or person. In particular it is important to
  474.     add "readable" variants of all attributes that people are expected
  475.     to search for, if they contain national characters.
  476.  
  477.     Another recommendation that can be made is that replication of
  478.     data [10] between local databases is used in order to improve the
  479.     performance of the service. Since replicating all entries of a
  480.     part of the IWPS from one local database in another may violate
  481.  
  482.  
  483.  
  484.  
  485.  
  486. Alvestrand, Jurg           Expires March 97                   [Page 9]
  487.  
  488. draft          BCP for the Internet White Pages Service   September 96
  489.  
  490.  
  491.     local privacy laws, it is recommended to restrict replication to
  492.     country and organizational entries and knowledge references (which
  493.     tell where to go for which part of the IWPS). Of course privacy
  494.     laws are not violated when the replicating database is managed by
  495.     the same organization as the one that masters the information. So
  496.     local replication between two databases within the same
  497.     organization is highly recommended.
  498.  
  499.     In general replication within one country will usually be less a
  500.     legal problem than across country borders.
  501.  
  502.     Recommendations fo the operation of a database in the in X.500
  503.     infrastructure can be found in [12].
  504.  
  505.     X.500 is not recommended to be used for:
  506.  
  507.  
  508.     -    A Yellow Pages service with a large scope. See [5].
  509.  
  510.     -    Searching outside the limited patterns listed here, in
  511.      particular searching for a person without knowing which
  512.      organization he might be affiliated to.
  513.  
  514.     -    Publishing information in other character sets than ASCII,
  515.      some of the Latin-based European scripts and Japanese (the
  516.      T.61 character sets). ISO is revising X.500, but products
  517.      that support the revision arent available yet.
  518.  
  519.     9.  Use the global name space
  520.  
  521.     Some people, for instance when using Novell 4 servers, have
  522.     decided that they will use X.500 or X.500-like services as an
  523.     internal naming mechanism, without coordinating with an outside
  524.     source.
  525.  
  526.     This suffers from many of the same problems as private IP
  527.     addresses, only more so: your data may need significant
  528.     restructuring once you decide to expose them to the outer world.
  529.  
  530.     A globally accessible X.500 service requires a globally connected
  531.     X.500 name space. See [3] and [4] for recommendations on how
  532.     create a local part of the global name space.
  533.  
  534.     Though the standard is not very clear about this and the most
  535.  
  536.  
  537.  
  538.  
  539.  
  540. Alvestrand, Jurg           Expires March 97                  [Page 10]
  541.  
  542. draft          BCP for the Internet White Pages Service   September 96
  543.  
  544.  
  545.     recent version (93) appears not to support it, in practice the
  546.     X.500 name space is only manageable if there is a single root
  547.     context operated under a cooperative agreement. However, one can
  548.     be sure that there will be turf battles over its control.
  549.  
  550.     If those turf battles arent decided outside the actual running
  551.     service, the effect on the service quality will be ruinous.
  552.  
  553.     This document appeals to all players in the field to let existing
  554.     practice alone until a better system is agreed and is ready to go
  555.     into place; at the moment, the root context of the day is operated
  556.     by the DANTE NameFlow project.
  557.  
  558.     More information on DANTE NameFlow is found at the URL
  559.  
  560.     http://www.dante.net/nameflow.html
  561.  
  562.  
  563.  
  564.     10.  Use LDAP
  565.  
  566.     At the moment, LDAP as documented in [9] is the protocol that
  567.     offers the most X.500 functionality in places where it is not
  568.     feasible to implement the full OSI stack.
  569.  
  570.     It is implemented on a lot of platforms, including several PC-type
  571.     platforms, and is popular in a multitude of commercial offerings.
  572.  
  573.     A concerted effort to make LDAP available is the publication
  574.     method that gives the widest access to the data.
  575.  
  576.     In addition, DSAs must implement the necessary linkages to make
  577.     sure they are properly integrated into the naming/referral tree;
  578.     in most cases, this will mean that they should implement the X.500
  579.     DSP protocol at least.
  580.  
  581.     (The question of whether one gateways LDAP to DAP or DAP to LDAP
  582.     is irrelevant in this context)
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594. Alvestrand, Jurg           Expires March 97                  [Page 11]
  595.  
  596. draft          BCP for the Internet White Pages Service   September 96
  597.  
  598.  
  599.     11.  Make services available
  600.  
  601.     The technical investment in running an X.500 service is not
  602.     enormous, see for example [5].
  603.  
  604.  
  605.  
  606.     12.  Future developments
  607.  
  608.     Today [September 1996] there are several enhancements to be
  609.     expected with respect to IWPS technology.
  610.  
  611.     The most important one to be mentioned here is the creation of a
  612.     "Common Indexing Protocol" that must enable the integration of
  613.     X.500, Whois++ and protocols that use stand-alone databases. Such
  614.     a protocol would not only enable integration but would offer at
  615.     the same time the possibility to explore yellow pages services and
  616.     enhanced searches, even if used for X.500 only.
  617.  
  618.     Once these developments reach stability, they may be referenced by
  619.     later versions of this BCP document.
  620.  
  621.  
  622.     13.  Security considerations
  623.  
  624.     The security implications of having a directory are many.
  625.  
  626.  
  627.     -    People will have a standard way to access the information
  628.      published.
  629.  
  630.     -    People will be able to gather parts of the information for
  631.      purposes you never intended (like publishing directories,
  632.      building search engines, headhunting or making harassing
  633.      phone calls).
  634.  
  635.     -    People will attempt to access more of the information than
  636.      you intended to publish, by trying to break security
  637.      functions or eavesdropping on conversations other users have
  638.      with the Directory.
  639.  
  640.     -    If modification over the Net is possible, people will attempt
  641.      to change your information in unintended ways. Sometimes
  642.      users will change data by mistake, too; not all change is
  643.  
  644.  
  645.  
  646.  
  647.  
  648. Alvestrand, Jurg           Expires March 97                  [Page 12]
  649.  
  650. draft          BCP for the Internet White Pages Service   September 96
  651.  
  652.  
  653.      malicious.
  654.  
  655.     The first defense for directory security is to limit your
  656.     publication to stuff you can live with having publicly available,
  657.     whatever happens.
  658.  
  659.     The second defense involves trying to impose access control. LDAP
  660.     supports a few access control methods, including the use of
  661.     cleartext passwords. Cleartext passwords are not a secure
  662.     mechanism in the presence of eavesdroppers; this document
  663.     encourages use of stronger mechanisms if modification is made
  664.     available over the open Internet.  Otherwise, modification rights
  665.     should be restricted to the local intranet.
  666.  
  667.     The third defense involves trying to prevent "inappropriate"
  668.     access to the directory such as limiting the number of returned
  669.     search items or refuse list operations where they are not useful
  670.     to prevent "trolling". Such defenses are rarely completely
  671.     successful, because it is very hard to set limits that
  672.     differentiate between an innocent user doing wasteful searching
  673.     and a malicous data troller doing carefully limited searches.
  674.  
  675.     Future enhancements may include using encrypted sessions, public
  676.     key logins and signed requests; such mechanisms are not generally
  677.     available today.
  678.  
  679.  
  680.     14.  References
  681.  
  682.  
  683.     [1]  Directory Services and Privacy Issues, E. Jeunik and E.
  684.      Huizer.  Proceedings of Joint European Networking Conference
  685.      1993, Trondheim
  686.  
  687.     [2]  Building an X.500 Directory Service in the US, B. Jennings,
  688.      RFC1943
  689.  
  690.     [3]  Building Naming and Structuring Guidelines for X.500
  691.      Directory Pilots, P.  Barker, S. Kille, T. Lenggenhager,
  692.      RFC1617
  693.  
  694.     [4]  The COSINE and Internet X.500 Schema. P. Barker & S. Kille,
  695.      RFC1274
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702. Alvestrand, Jurg           Expires March 97                  [Page 13]
  703.  
  704. draft          BCP for the Internet White Pages Service   September 96
  705.  
  706.  
  707.     [5]  Introducing a Directory Service, SURFnet report 1995
  708.  
  709.     [6]  Paradise International Reports, University College London,
  710.      April 1991 - April 1994
  711.  
  712.     [7]  Naming Guidelines for the AARNet X.500 Directory Service,
  713.      Michaelson and Prior, RFC 1562
  714.  
  715.     [8]  CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988
  716.  
  717.     [9]  Lightweight Directory Access Protocol, W. Yeong, T. Howes, S.
  718.      Kille, RFC1777
  719.  
  720.     [10] Replication and Distributed Operations extensions to provide
  721.      an Internet Directory using X.500, S. Kille, RFC1276
  722.  
  723.     [11] ISO transport services on top of the TCP: Version: 3, M.
  724.      Rose, D. Cass, RFC1006
  725.  
  726.     [12] Recommendations for an X.500 Production Directory Service, R.
  727.      Wright et al., RFC1803
  728.  
  729.  
  730.  
  731.     15.  Authors address
  732.  
  733.     Harald Tveit Alvestrand
  734.     UNINETT
  735.     P.O.Box 6883 Elgeseter
  736.     N-7002 TRONDHEIM
  737.     NORWAY
  738.  
  739.     +47 73 59 70 94
  740.     Harald.T.Alvestrand@uninett.no
  741.  
  742.     Peter Jurg
  743.     SURFnet
  744.     P.O.Box 19035
  745.     NL-3501 DA UTRECHT
  746.     THE NETHERLANDS
  747.  
  748.     +31 30 2305305
  749.     Peter.Jurg@surfnet.nl
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756. Alvestrand, Jurg           Expires March 97                  [Page 14]
  757.  
  758. draft          BCP for the Internet White Pages Service   September 96
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810. Alvestrand, Jurg           Expires March 97                  [Page 15]
  811.  
  812.