RFC2148 日本語訳

Network Working Group                                   H. Alvestrand
Request for Comments: 2148                                    UNINETT
BCP: 15                                                       P. Jurg
Category: Best Current Practice                               SURFnet
                                                       September 1997

Alvestrandがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2148UNINETT BCP: 15P.ジュルグカテゴリ: 最も良い現在の練習SURFnet1997年9月

             Deployment of the Internet White Pages Service

インターネットホワイトページサービスの展開

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

1.  Summary and recommendations

1. 概要と推薦

   This document makes the following recommendations for organizations
   on the Internet:

このドキュメントはインターネットで組織のための以下の推薦状をします:

     (1)   An organization SHOULD publish public E-mail addresses and
           other public address information about Internet users
           within their site.

(1) 組織SHOULDは彼らのサイトの中でインターネットユーザに関する公共のEメールアドレスと他の公共のアドレス情報を発表します。

     (2)   Most countries have laws concerning publication of
           information about persons. Above and beyond these, the
           organization SHOULD follow the recommendations of [1].

(2) ほとんどの国には、人々の情報の公表に関して法があります。 これらを超えて、組織SHOULDは[1]の推薦に続きます。

     (3)   The currently preferable way for publishing the information
           is by using X.500 as its data structure and naming scheme
           (defined in [4] and discussed in [3], but some countries
           use a refinement nationally, like [15] for the US). The
           organization MAY additionally publish it using additional
           data structures such as whois++.

(3) そのデータ構造と命名が計画されながら(米国への[15]のように全国的に気品を[4]で定義して、しかし、[3]、何らかの国の使用で議論します)、情報を発表するための現在望ましい方法はX.500を使用することです。 whois++などの追加データ構造を使用して、組織はさらに、それを発行するかもしれません。

     (4)   The organization SHOULD make the published information
           available to LDAP clients, by allowing LDAP servers access
           to their data".

「(4) 組織SHOULDはそれらのデータへのサーバアクセスをLDAPに許すことによって、発行された情報をLDAPクライアントにとって利用可能にします。」

     (5)   The organization SHOULD NOT attempt to charge for simple
           access to the data.

(5) 組織SHOULD NOTは、簡単なデータへのアクセスに課金するのを試みます。

   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.

(1) メール業者SHOULDは彼らの製品の中、または、内蔵の機能性か翻訳施設を提供することでLDAPルックアップの機能性を含んでいます。

Alvestrand & Jurg        Best Current Practice                  [Page 1]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[1ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

     (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.

(2) インターネットのサービスプロバイダーSHOULDは、それらのデータをホスティングするためのサービスを前提とするか、彼らがそうするために相手を見つけるのを助けるか、または彼らがそれら自身のサービスをもたらすのを助けることによって、より小さい組織がオンラインでこの推薦に続くのを助けます。

     (3)   All interested parties SHOULD make sure there exists a core
           X.500 name space in the world, and that all names in this
           name space are resolvable. (National name spaces may
           elobarate on the core name space).

(3) コアX.500名前スペースが存在するのを確信しているのにSHOULDが世界で作って、すべてがこの名前スペースで命名する関係者一同は溶解性です。 (国家の名前空間はスペースというコア名でelobarateされるかもしれません。)

   The rest of this document is justification and details for this
   recommendation.

このドキュメントの残りは、この推薦のための正当化と詳細です。

   The words "SHOULD", "MUST" and "MAY", when written in UPPER CASE,
   have the meaning defined in RFC 2119 [17]

“MUST"と大文字で書かれると「5月」という“SHOULD"という単語には、RFC2119で定義された意味があります。[17]

2.  Introduction

2. 序論

   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.

インターネットはユーザの情報交換とコミュニケーションに使用されます。 単にユーザが互いのアドレスを見つけることができるなら、そういうものとして有効である場合があります。 したがって、インターネットが適切なホワイトページServiceのおかげで得する、すなわち、(インターネット)アドレス情報を提供する電話番号案内は人々と組織に関連しました。

   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.

このドキュメントは今日の経験、今日のプロトコル、今日の製品、および今日の手順を用いることでインターネットホワイトページService(これから先、IWPSが簡略化されている)を利用するのが最も良い方法を述べます。

   Experience [2] 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.

経験[2]はユーザの自己登録に基づいた集結されたサーバの上のホワイトページServiceが行き当たりばったりのやり方で資料を取り集める傾向があって、そのうえ、急速にその時代のデータを集めて、時代について行かないのを示しました。

   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 consists of all relevant
   IWPS information from within a particular organization 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 organizations. 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.

IWPSを設立する最も重大な試みは分配された(地方の)データベースがそれぞれIWPS情報の処理しやすい部分を保持しているモデルに基づいています。 そのような部分は特定の組織かインターネット接続サービス業者とそのユーザからのすべての関連IWPS情報からほとんど成ります。 データベースの上に、それらを接続して、アクセサリーをユーザに提供する電話番号案内プロトコルがあります。 今日、X.500はインターネットで最もポピュラーな電話番号案内プロトコルです、およそ1に関するアドレス情報、5000000人の個人、および3,000の組織に接して。 Whois++は2番目のポピュラーなプロトコルです。 また、X.500とWhois++はIWPS情報だけ以外の情報とインタコネクトするのに使用されるかもしれませんが、ここで、私たちはIWPSの特徴について議論するだけです。

Alvestrand & Jurg        Best Current Practice                  [Page 2]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[2ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

   Note: there are other, not interconnected, address databases on the
   Internet that are also very popular for storing address information
   about people. "Ph" is a popular protocol for use with a stand-alone
   database.  There are over 300 registered Ph databases on the
   Internet. Interconnection of databases however, is highly recommended
   for an IWPS, since it ensures that data can be found. Hence Ph as it
   is now is not considered to be a good candidate for an IWPS, but
   future developments may change this situation (see section 12).

以下に注意してください。 インタコネクトされているのではなく、他であります、インターネットに関するまた、人々に関するアドレス情報を格納するのに、非常にポピュラーなアドレスデータベース。 "Ph"はスタンドアロンのデータベースによる使用のためのポピュラーなプロトコルです。 300以上の登録されたPhデータベースがインターネットにあります。 しかしながら、データベースのインタコネクト、データを見つけることができるのを確実にするので、IWPSのために強く推薦されます。 それがあるとき、したがって、Phは現在、IWPSの良い候補であると考えられませんが、未来の発展はこの状況を変えるかもしれません(セクション12を見てください)。

   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.

電話番号案内がIWPSに使用されるために議定書を作るとき、現在の、X.500はお勧めであるに違いありません。しかしながら、未来の技術で、代わりにまた、他のプロトコルを使用するのは可能になるかもしれません。

   Since many people think that X.500 on the Internet will be replaced
   by other protocols in the near future, it should be mentioned here
   that currently LDAP is seen as the surviving component of today's
   implementations and the main access protocol for tomorrow's directory
   services. As soon as new technology (that will probably use LDAP)
   becomes available and experiments show that they work, this document
   will be updated.

多くの人々が、インターネットのX.500が近い将来の他のプロトコルに取り替えられると考えるので、今日の実現の生き残っているコンポーネントと主なアクセスが明日の電話番号案内のために議定書を作るとき現在のLDAPが見られるとここに言及されるべきです。 新技術(それはたぶんLDAPを使用する)が利用可能になって、実験が、それらが働いているのを示すとすぐに、このドキュメントをアップデートするでしょう。

   A summary of X.500 products can be found in [14] (a document that
   will be updated regularly).

[14](定期的にアップデートされるドキュメント)でX.500製品の概要を見つけることができます。

   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 sections 8-11 discuss X.500 specific
   issues. In section 12 some future developments are discussed as they
   can be foreseen at the time of writing this document.

下のセクション3-7は電話番号案内プロトコルから独立しているIWPSに情報の公表に関連する推薦を含みます。 セクション8-11はX.500の特定の問題について論じます。 セクション12で、このドキュメントを書く時点でそれらについて見通すことができるようにいくつかの未来の発展について議論します。

3.  Who should publish IWPS information and how?

3. だれがIWPS情報を発表するべきであるか、そして、どのようにですか?

   IWPS information is public address information regarding individuals
   and organizations. The IWPS information concerning an individual
   should be published and maintained by an organization that has a
   direct, durable link with this individual, like in the following
   cases:

IWPS情報は個人と組織の場内放送情報です。 個人のIWPS情報は、この個人とのダイレクトで、長持ちするリンクを持っている組織によって、発表されて、保守されるべきです、以下のケースなどのように:

   -    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

- 個人は維持装置のインターネットのサービスの(個人的)の加入者です。

Alvestrand & Jurg        Best Current Practice                  [Page 3]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[3ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

   The organization that maintains the data does not 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.

データを保守する組織はそれ自身のローカルのデータベースにデータを格納する必要はありません。 X.500かWhoisのローカルのデータベースを走らせて、+ + サービスは難し過ぎる仕事ではありませんが、インターネット接続サービス業者がIWPS情報の小さい部分を維持するか、または十分なシステム管理リソースを持っているだけではない顧客の中でそれらの組織にデータベース機能を提供するのは、お勧めです。 これは、そのような組織がIWPSに合流するよう奨励するでしょう。IWPS情報とこれまでそれを上がるように保つ収集が情報が関連する組織の手にいつもあるべきです。

   Within the current (national) naming schemes for X.500, entries of
   individuals reside under an organization. In the case of Internet
   service providers that hold the entries of their subscribers this
   would mean that individuals can only be found if one knows the name
   of the service provider.  The problem of this restriction could be
   solved by using a more topographical approach in the X.500 naming
   scheme, but will more likely be solved by a future index service for
   directory services, which will allow searches for individuals without
   organization names (see section 12).

X.500の現在(国家の)の命名計画の中では、個人のエントリーは組織中に住んでいます。 彼らの加入者のエントリーを保持するインターネット接続サービス業者の場合では、これは、人がサービスプロバイダーの名前を知っている場合にだけ個人を見つけることができることを意味するでしょう。 おそらく、電話番号案内のための今後のインデックスサービスで解決されるのを除いて、X.500命名計画により地誌的なアプローチを使用することによって、この制限の問題を解決できるでしょう(セクション12を見てください)。電話番号案内は組織名なしで個人の捜索を許すでしょう。

4.  What kind of information should be published?

4. どういう情報が発表されるべきですか?

   The information to be published about an individual should at least
   include:

個人に関して発行されるべき情報は以下を少なくとも含むべきです。

   -    The individual's name

- 個人の名前

   -    The individual's e-mail address, in RFC-822 format; if not
        present, some other contact information is to be included

- RFC-822形式における個人のEメールアドレス。 プレゼントでないなら、ある他の問い合わせ先は含まれることです。

   -    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 [3]) or by adding a special organizational unit to the
   local X.500 name space that reflects the relation (like ou=students
   or ou=employees).

電話番号案内が最後の要件について議定書の中で述べるので使用されるX.500がそうするかもしれないときには、「organizationalStatus」属性を使用することによって、実現しています。([3])を見てください。さもないと、スペースというローカルのX.500名に特別な組織的なユニットを追加することによって、それは関係(ou=学生やou=従業員のような)を反映します。

   Additionally some other public address information about individuals
   may be included in the IWPS:

さらに、個人のある他の場内放送情報はIWPSに含まれるかもしれません:

       -    The individual's phone number

- 個人の電話番号

       -    The individual's fax number

- 個人のファックス番号

       -    The individual's postal address

- 個人の郵便の宛先

Alvestrand & Jurg        Best Current Practice                  [Page 4]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[4ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

       -    The URL of the individual's home page on the Web

- ウェブに関する個人のホームページのURL

   In the near future it will be a good idea to also store public key
   information.

近い将来、また、公開鍵情報を格納するのは、名案でしょう。

   More information about a recommended Internet White Pages Schema is
   found in The Internet White Pages Schema [16]

お勧めのインターネットホワイトページSchemaに関する詳しい情報はインターネットホワイトページでSchemaを設立することです。[16]

   Organizations should publish the following information about
   themselves in the IWPS:

組織はIWPSで自分たちの以下の情報を発表するべきです:

    -    The URL of the organizations home page on the Web

- ウェブの組織ホームページのURL

    -    Postal address

- 郵便の宛先

    -    Fax numbers

- ファックス番号

    -    Internet domain

- インターネットドメイン

    -    Various names and abbreviations for the organization that
         people can be expected to search for, such as the English
         name, and often the domain name of an organization.

- イギリスの名前などのように捜し求めると人々を予想できる組織としばしば組織のドメイン名のための様々な名前と略語。

   Organizations may also publish phone numbers and a presentation of
   themselves.

また、組織は自分たちの電話番号とプレゼンテーションを発表するかもしれません。

5.  Data management

5. データ管理

   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:

データ管理、すなわち、IWPS情報を集めて、それを最新に保つのは、より大きい組織のために過小評価してはいけないタスクです。 これらの問題に関して以下の推薦状をすることができます:

   -    An organization should achieve an executive level commitment
        to start a local database with IWPS information. This will
        make it much easier to get cooperation from people within the
        organization that are to be involved in setting up a
        Directory Service.

- 組織はIWPS情報からローカルのデータベースを始める幹部社員レベル委任を実現するべきです。 これで、組織の中のディレクトリサービスをセットアップするのにかかわることになっている人々から協力を得るのははるかに簡単になるでしょう。

   -    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, [3] and [4] should be followed if X.500 is used as
        directory services protocol.

- 組織はデータベースが含むべきである情報とそれがどう構造化されるべきであるかに関する種類を決めるべきです。 それは情報を構造化するためのインターネット推薦に続くべきです。 前項の評価基準以外に、電話番号案内が議定書を作るときX.500が使用されているなら、[3]と[4]は続かれるべきです。

Alvestrand & Jurg        Best Current Practice                  [Page 5]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[5ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

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

- 組織の中の既存のデータベースは、IWPSとローカルの情報を可能な最大級の範囲まで検索するのに使用されるべきです。 組織は、それらのデータベースを維持する人々を伴って、それらのデータ送信端末を使用するためにそれらから正式な書かれた委任を得るのを確実にするべきです。 彼らには地方の、そして、利用可能なデータの管理とコントロールの経験があって、組織はこれらの人々に頼るべきです。

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

- 組織がIWPSに合流する最も良い動機は彼らにはローカルの目的のためのローカルのデータベースが同時にあるということです。 ローカルのデータベースは以上を含むかもしれません、必ず公共であるというわけではなく. IWPSへの接続における組織がIWPSで余分なローカルの情報とサービスを「無視しなければならない」ので、要求されているより多くの情報とサーブ目的は、公衆のために電話番号案内を使用するIWPSが議定書を作ることを意味しませんでした。

6.  Legal issues

6. 法律問題

   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.

ほとんどの国には、人々の情報の公表に関するプライバシー法があります。 彼らは伸びやかな米国法から情報が個人から特定アクセス許可を得ないならあなたが発行できないと言うノルウェーの法に正確であるべきであるというイギリスの要件まで及びます。 情報を保持するローカルのデータベースがある国の国内法令に従って、IWPS情報のあらゆる維持装置がデータを発表するはずです。

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

これらの或るものは[5]と[1]に記録されます。

   A maintainer of IWPS information should also follow some common
   rules, even when they are not legally imposed:

また、それらが法的にさえ課されないとき、IWPS情報の維持装置はいくつかの共通規則に従うはずです:

   -    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

Alvestrandと最も良い現在の練習[6ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

   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.

出版IWPS情報にかかわるデータ管理と法律問題の数を考えて、より小さい会社をIWPSにすぐに、効率的に加わらせるように、良いコンサルタント業務は重大です。インターネット接続サービス業者がそのようなサービスを提供するよう奨励されます。

7.  Do not charge for lookups

7. ルックアップに課金しないでください。

   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:

現在のIWPSでは、今日の技術的制約のために、ユーザを請求するのがサービスの生存力に有害であることは信じていました。 この信念のためのいくつかの議論があります:

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

したがって、IWPSのユーザによるすべてのルックアップがただであることが強く推薦されます。 これはもちろん何らかの方法で充電が適切であるかもしれないところで他のサービスを支持するのに同じIWPSデータセットを使用する能力を制限しません。

8.  Use X.500

8. 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".

X.500プロトコルに基づくIWPSは比較的広い展開を持っています。 当期の勤務はおよそ1、個人と3,000人の組織の5000000のエントリーを含んでいます。 それは、ダンテ、イギリスのインターネット接続サービス業者によって調整されて、「NameFLOW天国」として知られています。

   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:

機能性がそれが課す階層的な命名構造によって制限されるという事実によってX.500は時々批評されますが、それは今生産を走らせている組織[5]、[2]、[6]、[7]による数人のパイロットにまた、X.500 IWPSユーザインタフェースがX.500 IWPSが提供する機能性を決定するのが示されたかなり良い機能性を提供します。 通常、彼らは以下のユーザ入力に基づくIWPSでルックアップを提供します:

   -    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

Alvestrandと最も良い現在の練習[7ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

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

特定のユーザインタフェースは人々のEメールアドレスや組織の郵便の宛先のように他の入力に基づくルックアップを提供できます。 しかしながら、そのような可能性はプライバシー法に違反するかもしれません。 そして、電話番号案内サービスのプロバイダーは責任を負わせられるかもしれません。

   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.

計画を命名するX.500はそれに格納されたすべてのエントリーがユニークな名前(「命名計画」)を持たなければならないというインタコネクトされたIWPSに関する要件を課します。 これは「命名木」のすべてのエントリーをただ一つの根に登録することによって、最も容易に実現しています。 これはX.500 IWPSの情報の全体が時々「ディレクトリ情報木」か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.

組織がIWPSを接合するのにX.500プロトコルを使用するよう強く奨励されます。当期の勤務はローカルのデータベース[10]を接続するプロトコルと、そして、アクセス・プロトコル[9]へのX.500 1988規格[8]といくつかのインターネット特有の追加に基づいています。 組織は、これらの仕様に基づくX.500ソフトウェアを使用するべきであり、インターネットの上でさらに、OSIプロトコルの輸送のための[11]を支持します。

   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.

機構は[10]を実行しない1988DSAsと共にNameFLOW-天国インフラストラクチャに接続するかもしれませんが、彼らは知識参照の自動模写を欠くでしょう。 これが不便になりますが、重要な問題は不便ではありません。 1993年のX.500の規格は、[10]からの機能性を含んでいますが、異なったpotocolを使用します。 したがって、また、1993DSAと共にインフラストラクチャに接続する機構はこの短所に遭遇するでしょう。 セクション12 「未来の発展」で、インフラストラクチャがなぜさしあたり1993年の規格を使用しないかがわかります。

   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

中でどの属性にX.500とどのようにを使用するかにおける推薦に、それらを使用してください。(公共のIWPS情報か追加ローカルの情報に関しては、読者は特定の非公共のローカルの目的について3と4を参照されて、また、新しい属性(そして、物のクラス)は定義されてもよいです; 一般に、これがサービスの探索の機能性をかなり改良するので、X.500で属性の多価性をできるだけ使用するのはお勧めであるべきです。例えば、organizationalNameは名前を保持するものを結果と考えます。

Alvestrand & Jurg        Best Current Practice                  [Page 8]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[8ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

   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.

組織か人の名前を保持するcommonName属性が組織か人のためのすべての知られている別名を含むべきです。 人々が捜し求めると予想されるすべての属性の「読み込み可能な」異形を加えるのは特に、重要です、彼らが国民性を含むなら。

   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.

することができる別の推薦状はローカルのデータベースの間のデータ[10]の模写がサービスの性能を向上させるのに使用されているということです。 以来別のもので1つのローカルのデータベースからIWPSの一部のすべてのエントリーを模写すると、ローカルのプライバシー法は違反されるかもしれなくて、模写を国、組織的なエントリー、および知識参照(どこにIWPSのどの部分に行くかを言う)に制限するのはお勧めです。 模写データベースが情報を習得するものと同じ組織によって管理されるとき、もちろん、プライバシー法は違反されません。 同じ組織の中の2つのデータベースの間のとても地方の模写は非常にお勧めです。

   In general replication within one country will usually be less a
   legal problem than across country borders.

一般に、通常、1つの国の中の模写は以下が法律問題であったなら国の境界よりそうするでしょう。

   Recommendations for the operation of a database in the X.500
   infrastructure can be found in [12].

[12]でX.500インフラストラクチャにおける、データベースの操作のための推薦を見つけることができます。

   X.500 is not recommended to be used for:

以下にX.500が使用されることが勧められません。

    -    A Yellow Pages service with a large scope. See [5].

- 大きい範囲によるイエローページサービス。 [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.

- ASCII以外の文字の組と、ラテン語ベースのヨーロッパの文字と日本人(T.61文字の組)の何人かによる情報を発表します。 これらの文字の組のサポートはX.500の改訂版で利用可能ですが、改正を支持する製品は一般的にまだ利用可能ではありません。

9.  Use the global name space

9. スペースというグローバル名を使用してください。

   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.

例えば、いつがノベル4サーバを使用して、何人かの人々が、内部の命名メカニズムとしてX.500かX.500のようなサービスを利用すると決めました、外部のソースと共に調整しないで。

   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.

さらにしたがってだけ、これはプライベートIPアドレスと同じ問題の多くに苦しみます: あなたが、それらを外界に露出するといったん決めると、あなたのデータは重要な企業再構築を必要とするかもしれません。

Alvestrand & Jurg        Best Current Practice                  [Page 9]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[9ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

   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.

グローバルにアクセスしやすいX.500サービスはグローバルに関連しているX.500名前スペースを必要とします。 推薦のための[3]と[4]がオンであることを見てください。どのようにがスペースというグローバル名の地方の部分を作成するか。

   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.

規格はこれに関してそれほど明確ではありません、そして、最新のバージョン(93)は実際にはそれを支持しないように見えますが、共同契約で操作されたただ一つの根の文脈がある場合にだけ、スペースというX.500名は処理しやすいです。 しかしながら、1つはそこの上に縄張り争いがあるのを確信しているのが、コントロールであるということであるかもしれません。

   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.

このドキュメントは、より良いシステムに同意されて、場所に入る準備ができるまで単独で既存の習慣をさせるようにその分野のすべてのプレーヤーに求めます。 現在、1日の根の文脈はダンテNameFLOW-天国サービスで操作されます。

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

ダンテNameFLOW-天国サービスの詳しい情報はURLで見つけられます。

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

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

10.  Use LDAP

10. 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.

現在、[9]に記録されるLDAPは完全なOSIスタックを実行するのが可能でない場所で最も多くのX.500の機能性を提供するプロトコルです。

   It is implemented on a lot of platforms, including several PC-type
   platforms, and is popular in a multitude of commercial offerings.

それは、いくつかのPCタイププラットホームを含む多くのプラットホームで実行されて、商業提供の多数でポピュラーです。

   A concerted effort to make LDAP available is the publication method
   that gives the widest access to the data.

LDAPを利用可能にするための協力は最も広いデータへのアクセスを与える公表方法です。

   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.

さらに、X.500 DSAsはそれらが適切に命名/紹介木と統合されるのを確実にするために必要なリンケージを実行しなければなりません。 多くの場合、これは、彼らが少なくともX.500 DSPプロトコルを実行するべきであることを意味するでしょう。

   (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)

(DAPへの1ゲートウェイLDAPかLDAPへのDAPがこのような関係においては無関係であるかどうかについて; 大口使用者が皆、LDAPを使用するならLDAPだけサーバにデータを格納して、ゲートウェイを通してそれをDAP/DSP-走行世界に利用可能にするのがかなり適切であるかもしれないという質問)

Alvestrand & Jurg        Best Current Practice                 [Page 10]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[10ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

11.  Make services available

11. サービスを利用可能にしてください。

   The technical investment in running an X.500 service is not enormous,
   see for example [5].

X.500サービスを走らせることへの技術的な投資は莫大でなく、例えば、[5]を見てください。

12.  Future developments

12. 未来の発展

   Today [October 1996] there are several enhancements to be expected
   with respect to IWPS technology.

今日[1996年10月]、IWPS技術に関して予想されるために、いくつかの増進があります。

   The most important one to be mentioned here is the creation of a
   "Common Indexing Protocol" that must enable the integration of X.500,
   Whois++ and protocols that use stand-alone databases. Such a protocol
   would not only enable integration but would offer at the same time
   the possibility to explore yellow pages services and enhanced
   searches, even if used for X.500 only.

+ ここに言及されるべき最も重要なものがX.500の統合を可能にしなければならない「一般的なインデックスプロトコル」の創造であり、Whoisはスタンドアロンのデータベースを使用する+とプロトコルです。 そのようなプロトコルは、統合を可能にするだけではないでしょうが、同時に職業別広告欄サービスと高められた検索について調査する可能性を提供するでしょう、X.500だけに使用されても。

   In the context of the Common Indexing Protocol the stand-alone LDAP
   servers should be mentioned that are announced by several software
   developers. These are stand-alone address databases that can be
   accessed by LDAP. Currently also a public domain version is available
   from the University of Michigan.  Also announced is an LDAP-to-DAP
   gateway that can integrate a stand-alone LDAP server in an X.500
   infrastructure.

Common Indexingプロトコルの文脈では、数人のソフトウェア開発者によって発表されるスタンドアロンのLDAPサーバは言及されるべきです。 これらはLDAPがアクセスできるスタンドアロンのアドレスデータベースです。 また、現在、公共の場バージョンもミシガン大学から利用可能です。 また、発表されているのは、LDAPからDAPへのX.500インフラストラクチャにおけるスタンドアロンのLDAPサーバを統合できるゲートウェイです。

   Other improvements include defining a common core schema for multiple
   White Pages services, leading to the possibility of accessing data in
   multiple services through a single access protocol.

他の改良は、複数のホワイトのページサービスのために一般的なコア図式を定義するのを含んでいます、シングルアクセスプロトコルを通して複数のサービスでデータにアクセスする可能性に通じて。

   The 1993 version of the X.500 standard has already been implemented
   in several products. It is an enhancement over the 1988 standard in
   several ways, but has not been implemented in the NameFLOW-Paradise
   infrastructure yet.  The main reason is that the standard doesn't
   recognize the existence of a single root DSA, but assumes that the
   managers of first-level DSAs (the country DSA's) make bilateral
   contracts for interconnection. In the case of NameFLOW-Paradise such
   a situation would be unmanageable. In [13] an enhancement of the 1993
   standard is proposed that makes a single root possible. As soon as
   implementations of [13] are available, NameFLOW-Paradise will
   experiment with 1993 DSAs. This is expected in 1997.

1993年のX.500規格のバージョンは数個の製品の中に既に実装されました。 それは、1988年の規格の上のいくつかの道における増進ですが、NameFLOW-天国インフラストラクチャではまだ実装されていません。 主な理由は規格が、独身の根のDSAの存在を認識しませんが、最初に、レベルDSAs(国のDSAのもの)のマネージャがインタコネクトのために双務契約を作ると仮定するということです。 NameFLOW-天国の場合では、そのような状況は「非-処理しやす」でしょう。 [13]では、ただ一つの根を可能にする1993年の規格の増進は提案されます。 [13]の実装が利用可能であるとすぐに、NameFLOW-天国は1993DSAsを実験するでしょう。 これは1997年に予想されます。

   Once these developments reach stability, they may be referenced by
   later versions of this BCP document.

これらの開発がいったん安定性に達すると、それらはこのBCPドキュメントの後のバージョンによって参照をつけられるかもしれません。

Alvestrand & Jurg        Best Current Practice                 [Page 11]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[11ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

13.  Security considerations

13. セキュリティ問題

   The security implications of having a directory are many.

ディレクトリを持つセキュリティ含意は多いです。

   -    People will have a standard way to access the information
        published.

- 人々には、発表された情報にアクセスする標準の方法があるでしょう。

   -    People will be able to gather parts of the information for
        purposes you never intended (like publishing directories,
        building search engines, headhunting or making harassing
        phone calls).

- 人々はあなたが決して意図しなかった(サーチエンジン、ヘッドハンティングまたは作成いたずら電話を組み込んで、ディレクトリを発表するように)目的のための情報の部分を集めることができるでしょう。

   -    People will attempt to access more of the information than
        you intended to publish, by trying to break security
        functions or eavesdropping on conversations other users have
        with the Directory.

- 人々は、セキュリティ機能を壊そうとすることによって発行することを意図するか、または他のユーザがディレクトリで持っている会話を立ち聞きしながらあなたより情報の以上にアクセスするのを試みるでしょう。

   -    If modification over the Net is possible, people will attempt
        to change your information in unintended ways. Sometimes
        users will change data by mistake, too; not all undesired
        change is malicious.

- ネットの上の変更が可能であるなら、人々は、故意でない方法であなたの情報を変えるのを試みるでしょう。 時々、ユーザは間違っているデータも変えるでしょう。 すべての望まれない変化がどんな悪意があるというわけではありません。

   The first defense for directory security is to limit your publication
   to stuff you can live with having publicly available, whatever
   happens.

有が公的に利用可能な状態で最初のディフェンスはディレクトリセキュリティがあなたを詰めるためにあなたの公表を制限することであるので、生きることができます、何が起こっても。

   The second defense involves trying to impose access control. LDAP
   supports a few access control methods, including the use of cleartext
   passwords. Cleartext passwords are not a secure mechanism in the
   presence of eavesdroppers; this document encourages use of stronger
   mechanisms if modification is made available over the open Internet.
   Otherwise, modification rights should be restricted to the local
   intranet.

2番目のディフェンスは、アクセス規制を設けようとすることを伴います。 LDAPはcleartextパスワードの使用を含むいくつかのアクセス制御メソッドをサポートします。 Cleartextパスワードは立ち聞きする者の面前で安全なメカニズムではありません。 開いているインターネットの上で変更を利用可能にするなら、このドキュメントは、より強いメカニズムの使用を奨励します。 さもなければ、変更権利はローカルのイントラネットに制限されるべきです。

   The third defense involves trying to prevent "inappropriate" access
   to the directory such as limiting the number of returned search items
   or refuse list operations where they are not useful to prevent
   "trolling". Such defenses are rarely completely successful, because
   it is very hard to set limits that differentiate between an innocent
   user doing wasteful searching and a malicous data troller doing
   carefully limited searches.

3番目のディフェンスは、それらが「輪唱すること」を防ぐために役に立たないところで返された検索項目の数を制限などなどのディレクトリへの「不適当な」アクセスを防ごうとするか、またはリスト操作を拒否しようとすることを伴います。 そのようなディフェンスは完全にめったにうまくいくというわけではありません、潔白なユーザを区別する限界が慎重に限られた検索をしながら無駄な探すのとmalicousデータトローラをするように非常に設定しにくいので。

   Future enhancements may include using encrypted sessions, public key
   logins and signed requests; such mechanisms are not generally
   available today.

今後の増進は、暗号化されたセッション、公開鍵ログイン、および署名している要求を使用するのを含むかもしれません。 一般に、そのようなメカニズムは今日、利用可能ではありません。

Alvestrand & Jurg        Best Current Practice                 [Page 12]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[12ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

14.  Acknowlegdements

14. Acknowlegdements

   The authors wish to thank the following people for their constructive
   contributions to the text in this document:

作者はテキストへの彼らの建設的な貢献について本書では以下の人々に感謝したがっています:

         Peter Bachman <peterb@suport.psi.com>

ピーター Bachman <peterb@suport.psi.com 、gt。

         David Chadwick <D.W.Chadwick@iti.salford.ac.uk>

デヴィッド Chadwick <D.W.Chadwick@iti.salford.ac.uk 、gt。

         William Curtin <curtinw@ncr.disa.mil>

ウィリアム Curtin <curtinw@ncr.disa.mil 、gt。

         Patrik Faltstrom <paf@swip.net>

パトリク Faltstrom <paf@swip.net 、gt。

         Rick Huber <rvh@att.com>

リック Huber <rvh@att.com 、gt。

         Thomas Lenggenhager <lenggenhager@switch.ch>

トーマス Lenggenhager <lenggenhager@switch.ch 、gt。

         Sri Saluteri <sri@qsun.ho.att.com>

様の Saluteri <sri@qsun.ho.att.com 、gt。

         Mark Wahl <M.Wahl@critical-angle.com>

Wahl <M.Wahl@critical-angle.com をマークしてください、gt。

15.  Glossary

15. 用語集

   DAP  Directory Access Protocol; protocol used between a DUA and a
        DSA to access the Directory Information. Part of X.500.

ディレクトリアクセス・プロトコルをちょと浸してください。 プロトコルはDUAとDSAの間でディレクトリ情報をアクセスに使用しました。 X.500の一部。

   DSP  Directory System Protocol: the protocol used between two DSAs

DSPディレクトリシステムプロトコル: 2DSAsの間で使用されるプロトコル

   DSA  Directory System Agent - entity that provides DUAs and other
        DSAs access to the information stored in the Directory

DSAディレクトリSystemエージェント--ディレクトリで保存された情報へのアクセスをDUAsと他のDSAsに供給する実体

   LDAP Lightweight Directory Access Protocol - defined in RFC 1777

LDAPライトウェイト・ディレクトリ・アクセス・プロトコル--RFC1777では、定義されます。

   Further terms may be found in RFC 1983.

さらなる用語はRFC1983で見つけられるかもしれません。

16.  References

16. 参照

[1] Jeunik, E. and E. Huizer. Directory Services and Privacy
     Issues. Proceedings of Joint European Networking Conference
     1993, Trondheim,
     http://www.surfnet.nl/surfnet/diensten/x500/privacy.html

[1]Jeunik、E.、およびE.Huizer。 ディレクトリサービスとプライバシーの問題。 共同ヨーロッパのネットワークコンファレンス1993、トロンヘイム、 http://www.surfnet.nl/surfnet/diensten/x500/privacy.html の議事

[2]  Jennings, B. Building an X.500 Directory Service in the US,
     RFC1943, May 1996.

[2] ジョニングス、B. 米国、RFC1943でX.500ディレクトリサービスを組み込むのは1996がそうするかもしれません。

[3]  Barker, P., S. Kille, T. Lenggenhager, Building Naming and
     Structuring Guidelines for X.500 Directory Pilots, P.  Barker,
     S. Kille, T. Lenggenhager, RFC1617

[3] P. バーカー、S.Kille、T.LenggenhagerがX.500ディレクトリのパイロットS.Kille、T.Lenggenhager(P.バーカー)のためにガイドラインを命名して、構造化しながら建てるRFC1617

Alvestrand & Jurg        Best Current Practice                 [Page 13]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[13ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

[4]  The COSINE and Internet X.500 Schema. P. Barker & S. Kille,
     RFC1274

[4] コサインとインターネットX.500図式。 P。 バーカーとS.Kille、RFC1274

[5]  Introducing a Directory Service, SURFnet report 1995 (see
     URL:
     http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/)

[5] ディレクトリサービスを導入して、SURFnetは1995を報告します。(URL: http://info.nic.surfnet.nl/surfnet/projects/x500/introducing/ を見ます)

[6]  Paradise International Reports, University College London,
     April 1991 - April 1994

[6] 天国国際報道、1991年4月から1994年4月までのユニバーシティ・カレッジロンドン

[7]  Naming Guidelines for the AARNet X.500 Directory Service,
     Michaelson and Prior, RFC 1562

[7] AARNet X.500ディレクトリサービス、Michaelson、および先のRFC1562年のガイドラインを命名すること。

[8]  CCITT Blue Book, Volume VIII - Fascicle VIII.8, November 1988

[8]CCITT紳士録、巻VIII--分冊VIII.8、1988年11月

[9]  Lightweight Directory Access Protocol, W. Yeong, T. Howes, S.
     Kille, RFC1777

[9] ライトウェイト・ディレクトリ・アクセス・プロトコル、W.Yeong、T.ハウズ、S.Kille、RFC1777

[10] Replication and Distributed Operations extensions to provide
     an Internet Directory using X.500, S. Kille, RFC1276

X.500、S.Kille、RFC1276を使用することでインターネットディレクトリを提供する[10]模写とDistributed Operations拡張子

[11] ISO transport services on top of the TCP: Version: 3, M.
     Rose, D. Cass, RFC1006

[11] ISOはTCPの上でサービスを輸送します: バージョン: 3 M.ローズ、D.キャス、RFC1006

[12] Recommendations for an X.500 Production Directory Service, R.
     Wright et al., RFC1803

[12] X.500 Productionディレクトリサービス、R.ライト他、RFC1803のための推薦

[13] Managing the X.500 Root Naming Context, D. Chadwick, RFCxxxx

[13] 文脈、D.チャドウィックをRFCxxxxと命名するX.500根を管理すること。

[14] A Revised Catalog of Available X.500 Implementations, A.
     Getchell, S.  Sataluri, RFC1632

[14] 利用可能なX.500実装、A.ゲッチェル、S.Sataluri、RFC1632の改訂されたカタログ

[15] A Naming Scheme for c=US, The North American Directory Forum,
     RFC1255

[15] RFC1255、cの命名体系は米国、北米のディレクトリフォーラムと等しいです。

[16] A Common Schema for the Internet White Pages Service, T.
     Genovese, B. Jennings, Work In  Progress.

[16] インターネットホワイトページサービスのための一般的な図式、T.Genovese、B.ジョニングスは進行中で働いています。

[17] Key words for use in RFCs to Indicate Requirement Level, S.
     Bradner, RFC 2119,

[17] Indicate Requirement Level、S.ブラドナーRFC2119へのRFCsにおける使用のためのキーワード

Alvestrand & Jurg        Best Current Practice                 [Page 14]

RFC 2148              Internet White Pages Service        September 1997

Alvestrandと最も良い現在の練習[14ページ]RFC2148インターネットホワイトページサービスジュルグ1997年9月

17.  Authors address

17. アドレスを書きます。

   Harald Tveit Alvestrand
   UNINETT
   P.O.Box 6883 Elgeseter
   N-7002 TRONDHEIM
    NORWAY

ハラルドTveit Alvestrand UNINETT P.O.Box6883Elgeseter N-7002トロンヘイムノルウェー

   +47 73 59 70 94
   Harald.T.Alvestrand@uninett.no

+47 73 59 70 94 Harald.T.Alvestrand@uninett.no

   Peter Jurg
   SURFnet
   P.O.Box 19035
   NL-3501 DA UTRECHT
   THE NETHERLANDS

ピータージュルグSURFnet P.O.Box19035NL-3501 DAユトレヒトオランダ

   +31 30 2305305
   Peter.Jurg@surfnet.nl

+31 30 2305305 Peter.Jurg@surfnet.nl

Alvestrand & Jurg        Best Current Practice                 [Page 15]

AlvestrandとジュルグBest現在の習慣[15ページ]