[要約] RFC 2345は、ドメイン名と会社名の検索に関する要件を定義しています。このRFCの目的は、効率的で正確なドメイン名と会社名の検索を可能にすることです。

Network Working Group                                        J. Klensin
Request for Comments: 2345                                          MCI
Category: Experimental                                          T. Wolf
                                                       Dun & Bradstreet
                                                             G. Oglesby
                                                                    MCI
                                                               May 1998
        

Domain Names and Company Name Retrieval

ドメイン名と会社名の取得

Status of this Memo

本文書の状態

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準も規定していません。改善のための議論と提案が要求されます。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1998). All Rights Reserved.

Copyright(C)The Internet Society(1998)。全著作権所有。

Abstract

概要

Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed.

特定の企業の名前に基づいたWeb情報の場所は、インターネットとWebの成長に伴い、ますます困難な問題になっています。そのために命名規則とドメインネームシステム(DNS)を使用すると、後者の問題は解決しませんが複雑になります。 DNS規則への依存を減らすために、現代的な高機能のディレクトリサービスおよび検索プロトコルを使用するいくつかの提案がありましたが、それらのどれも大幅に展開されていません。

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed.

このドキュメントは、複雑で強力なオプションが失敗したり、過度に機能したりした場合に、非常にシンプルで広く展開されているプロトコルが成功するかどうかを調査するために、最も古くて複雑でないインターネットディレクトリプロトコル、whoisに基づく会社名からURLへのマッピングサービスを提案します遅延。

1. Introduction and Context
1. はじめに

In recent months, there have been many discussions in various segments of the Internet community about "the top level domain problem". Perhaps characteristically, that term is used by different groups to identify different, and perhaps nearly orthogonal, issues. Those issues include: 1.1. A "domain administration policy" issue.

ここ数か月間、「トップレベルドメインの問題」についてインターネットコミュニティのさまざまなセグメントで多くの議論が行われてきました。おそらく特徴的に、その用語は異なるグループによって使用され、異なる、そしておそらくほぼ直交する問題を識別します。これらの問題は次のとおりです。 「ドメイン管理ポリシー」の問題。

1.2. A "name ownership" issue, of which the trademark issue may constitute a special case.

1.2. 「名前の所有権」の問題。この商標の問題は特別なケースとなる場合があります。

1.3. An information location issue, specifically the problem of locating the appropriate domain, or information tied to a domain, for an entity given the name by which that entity is usually known.

1.3. 情報の場所の問題、具体的には、そのエンティティが通常知られている名前が付けられたエンティティの、適切なドメイン、またはドメインに関連付けられた情報を見つける問題。

Of these, controversies about the first two may be inevitable consequences of the growth of the Internet. There have been intermittent difficulties with top level domain adminstration and various attempts to use the domain registry function as a mechanism for control of service providers or services from time to time since a large number of such domains started being allocated. Those problems led to the publication of the policy guidelines of [RFC1591].

これらのうち、最初の2つについての論争は、インターネットの成長の必然的な結果かもしれません。トップレベルのドメイン管理や、ドメインレジストリ機能をサービスプロバイダーやサービスを制御するメカニズムとして使用しようとするさまざまな試みが断続的に困難になり、そのようなドメインの多数が割り当てられ始めてから時々です。これらの問題は、[RFC1591]のポリシーガイドラインの発行につながりました。

The third appears to be largely a consequence of the explosive growth of the World Wide Web and, in particular, the exposure of URL formats [URL] to the end user because no other mechanisms have been available. The absence of an appropriate and adequately-deployed directory service has led to the assumption that it should be possible to locate the web pages for a company by use of a naming convention involving that company's name or product name, i.e., for the XYZ Company, a web page located at

3番目の原因は、主にWorld Wide Webの爆発的な成長の結果であり、特に、他のメカニズムを利用できなかったために、URL形式[URL]がエンドユーザーに公開されたためです。適切かつ適切に展開されたディレクトリサービスがないため、企業の名前または製品名、つまりXYZ Companyを含む命名規則を使用して、企業のWebページを見つけることができるはずであるという想定に至りました。にあるウェブページ

        http://www.xyz.com/
   or
        http://www.xyz-company.com/
        

has been assumed.

想定されています。

However, as the network grows and as increasing numbers of web sites are rooted in domains other than ".COM", this convention becomes difficult to sustain: there will be too many organizations or companies with legitimate claims --perhaps in different lines of business or jurisdictions-- to the same short descriptive names. For that reason, there has been a general sense in the community for several years that the solution to this information location problem lies, not in changes to the domain name system, but in some type of directory service.

ただし、ネットワークが拡大し、「。COM」以外のドメインにルートが置かれるWebサイトの数が増えるにつれて、この規則を維持することが難しくなります。正当な主張を持つ組織や企業が多すぎるため、おそらく異なる事業分野に存在します。または管轄区域-同じ短い説明的な名前に。そのため、コミュニティでは、この情報の場所の問題に対する解決策がドメインネームシステムの変更ではなく、ある種のディレクトリサービスにあるというのが数年前からありました。

But such directory services have not come into being. There has been ongoing controversy about choices of protocols and accessing mechanisms. IETF has published specifications for several different directory and search protocols, including [WHOIS++], [RWHOIS],

しかし、そのようなディレクトリサービスは実現していません。プロトコルの選択とメカニズムへのアクセスについては、論争が続いています。 IETFは、[WHOIS ++]、[RWHOIS]、

[LDAP], [X500], [GOPHER]. One hypothesis about why this has not happened is that these mechanisms have been hard to select and deploy because they are much more complex than is necessary. This document proposes an extremely simple alternative.

[LDAP]、[X500]、[GOPHER]。これが起こらなかった理由についての1つの仮説は、これらのメカニズムは必要以上に複雑であるため、選択と展開が困難であったというものです。このドキュメントでは、非常にシンプルな代替案を提案しています。

2. Using WHOIS
2. WHOISの使用

The WHOIS protocol is the oldest directory access protocol in use on the Internet, dating in published form to March 1982 and first implemented somewhat earlier. The procotol itself is simple and minimalist: the client opens a telnet connection to the WHOIS port (43) and transmits a line over it. The server looks up the line in a fashion that it defines, returns one or more lines of information to the client, and closes the connection.

WHOISプロトコルは、インターネットで使用されている最も古いディレクトリアクセスプロトコルであり、1982年3月に公開された形式で、最初はやや早く実装されました。 procotol自体はシンプルでミニマリストです。クライアントはWHOISポート(43)へのtelnet接続を開き、それを介して回線を送信します。サーバーは、定義された方法で行を検索し、1つ以上の情報行をクライアントに返し、接続を閉じます。

We suggest that modifications or add-ins be created to Web browsers that would access a new, commercially-provided Whois server, sending a putative company name and receiving back one or more lines, each containing a URL followed by one or more blanks and then a matching company name (that order was chosen to minimize parsing problems: since URLs cannot contain blanks, the first blank character marks the end of the URL and the next non-blank marks the beginning of the company name). As is usual with Whois, the criteria used by the server to match the incoming string is at the server's discretion. The difference between this and the protocol as documented in [WHOIS] is that exactly one company name is returned per line (see section 3 for details of syntax).

新しい商用のWhoisサーバーにアクセスするWebブラウザーに変更またはアドインを作成し、推定の会社名を送信し、1つ以上の行を受信することをお勧めします。各行にはURLとそれに続く1つ以上の空白が含まれ、次に一致する会社名(この問題は、解析の問題を最小限に抑えるために選択されました。URLには空白を含めることができないため、最初の空白文字はURLの終わりを示し、次の非空白文字は会社名の始まりを示します)。 Whoisで通常行われるように、サーバーが着信文字列を照合するために使用する基準は、サーバーの裁量にあります。 [WHOIS]に記載されているプロトコルとの違いは、1行に1つの会社名しか返されないことです(構文の詳細については、セクション3を参照)。

The client would then be expected to:

その後、クライアントは次のことが期待されます。

(i) If a single line (company name and URL) is returned, either ask for confirmation or simply fetch the associated URL as if it had been typed by the user.

(i)1行(会社名とURL)が返された場合は、確認を求めるか、単にユーザーが入力したかのように関連するURLをフェッチします。

(ii) If multiple lines (names) are returned, present the user with a choice, presumably showing company names rather than (or supplemented by) URLs, then fetch using the URL selected.

(ii)複数の行(名前)が返される場合は、選択肢をユーザーに提示し、おそらくURLではなく(またはURLで補完された)会社名を表示してから、選択したURLを使用してフェッチします。

Obviously, while the most convenient use of the services contemplated in this document would occur through a client that was part of, or intimately connected with, a Web browser, a user without that type of facility could utilize a traditional WHOIS client and paste or otherwise transfer the relevant information into the target location of a browser.

明らかに、このドキュメントで検討されているサービスの最も便利な使用は、Webブラウザーの一部または密接に接続されたクライアントを介して行われますが、そのタイプの機能を持たないユーザーは、従来のWHOISクライアントを利用して貼り付けたり、その他の方法で行うことができます。関連情報をブラウザのターゲットの場所に転送します。

3. Formats, versions, and international character sets
3. フォーマット、バージョン、および国際文字セット

Preliminary work with the approach suggested above suggests that some specific conventions about syntax and variations would be useful.

上記で提案されたアプローチを用いた予備作業は、構文とバリエーションに関するいくつかの特定の規則が役立つことを示唆しています。

3.1 Line sent from client to server.

3.1 クライアントからサーバーに送信される回線。

These lines may take either of two forms:

これらの行は、次の2つの形式のいずれかになります。

(i) A simple 7-bit ASCII string, containing a "company name"

(i)「会社名」を含む単純な7ビットASCII文字列

(ii) A string in the format (using the ABNF notation of RFC 2234 [ABNF]):

(ii)次の形式の文字列(RFC 2234 [ABNF]のABNF表記を使用):

Variation "/" 1*Octet

バリエーション "/" 1 *オクテット

           Variation :== "0" | ( Non-zero-digit 1*Digit)
           Non-zero-digit :== 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
           Digit :== 0 | Non-zero-digit
        

Where Octet is any eight-bit sequence, representing a prefixed variation number.

Octetは8ビットのシーケンスで、プレフィックス付きのバリエーション番号を表します。

The first form will be construed as equivalent to the second form with the leading string "0/". Variation numbers are specified in section 3.3.

最初の形式は、先頭の文字列が「0 /」である2番目の形式と同等であると解釈されます。バリエーション番号はセクション3.3で指定されています。

In all cases, the interpretation of what "company name" might mean and, in particular, what variations of form or spelling, abbreviations, and so on, might be accepted is strictly up to the interpretation of the server. If rules driving the server lead to the conclusion that a string matches some company in its data, the correctness or incorrectness of that decision is not covered by this specification.

すべての場合において、「会社名」が意味する可能性のある解釈、特に、形式やスペル、省略形などのバリエーションが受け入れられる可能性のある解釈は、厳密にサーバーの解釈次第です。サーバーを駆動するルールにより、文字列がそのデータの一部の会社と一致するという結論に至る場合、その決定の正確性または不正確さはこの仕様ではカバーされていません。

For variation 0 and, by default, for all others, any alphabetic text in lines is to be construed in a case-insensitive fashion.

バリエーション0の場合、およびデフォルトで他のすべての場合、行内のすべてのアルファベットテキストは、大文字と小文字を区別しない方法で解釈されます。

3.2 Lines sent from server to client.

3.2 サーバーからクライアントに送信される回線。

The server is expected to return one or more lines to the client, depending on its interpretation of the input string. In general, each line will consist, as described above, of a URL, a space, and a "company name". This document deliberately does not specify the content or semantics of the "company name" string. It might be a name, or a name and descriptive information such as location and type of business, or other information at the option of the server. The expectation, as mentioned above, is that the information will be displayed by the client to aid users in selecting the appropriate URL.

サーバーは、入力文字列の解釈に応じて、クライアントに1行以上を返すことが期待されています。一般に、各行は、上記のように、URL、スペース、および「会社名」で構成されます。このドキュメントでは、「会社名」の文字列の内容や意味を意図的に指定していません。これは、名前、または場所とビジネスの種類などの名前と説明情報、またはサーバーのオプションでのその他の情報です。上記のように、ユーザーが適切なURLを選択するのに役立つ情報がクライアントによって表示されることが期待されています。

These lines, consistent with normal Internet practice, will be terminated by a CR LF sequence (rather than one or the other of those control characters).

これらの行は、通常のインターネットの慣行と一致して、CR LFシーケンス(これらの制御文字のいずれかではなく)で終了します。

When and if different variation numbers are introduced, their specifications may include variations on what the server is expected to return.

異なるバリエーション番号が導入された場合、その仕様には、サーバーが返すと予想されるもののバリエーションが含まれる場合があります。

In lieu of "URL and company name" responses, the Server may also return "error messages". These take the form of lines containing:

「URLと会社名」の応答の代わりに、サーバーは「エラーメッセージ」を返すこともあります。これらは以下を含む行の形式を取ります。

         "///" SP String
        

where the String is 7-bit ASCII with no control characters other than SP, unless the variation associated with the variation number specifies otherwise. For this experiment, all "error messages" but the following two are discouraged:

文字列は7ビットのASCIIで、SP以外の制御文字はありません。ただし、バリエーション番号に関連付けられたバリエーションが別の方法で指定されている場合を除きます。この実験では、次の2つを除くすべての「エラーメッセージ」は推奨されません。

/// Not found Indicating that the "company name" does not match anything /// Variation not supported Indicating that the variation number supplied by the client is not recognized by the server.

///見つかりません「会社名」が何にも一致しないことを示します///サポートされていないバリエーションクライアントが提供したバリエーション番号がサーバーによって認識されていないことを示します。

3.3. Registered variations
3.3. 登録されたバリエーション

The following two variations are established as part of this specification:

この仕様の一部として、次の2つのバリエーションが確立されています。

0/ Query and response are in 7-bit ASCII, no controls other than SP, "Company name" separated from URL by one or more SP characters.

0 /クエリと応答は7ビットASCIIであり、SP以外のコントロールはありません。「会社名」は、URLから1つ以上のSP文字で区切られています。

1/ Query and response are in UTF-8, no controls other than SP, "Company name" separated from URL by one or more SP characters, no specification of language on either input or output.

1 /クエリと応答はUTF-8であり、SP以外のコントロールはありません。「会社名」はURLから1つ以上のSP文字で区切られており、入力または出力に言語の指定はありません。

The IANA will maintain a registry of additional variations which it is hoped will be very short. Requests for additional variations should be sent via email to: iana@iana.org.

IANAは、追加のバリエーションのレジストリを維持しますが、これは非常に短くなることが望まれます。追加のバリエーションのリクエストは、電子メールでiana@iana.orgに送信してください。

4. Alternatives not chosen
4. 選択されていない選択肢

Few comments on the initial drafts of this document addressed the basic model or protocol design for the service discussed. Instead, they focused on inquiring about the decisions we didn't make and about beliefs about the protocol specification that were not intended by the authors. The latter have been, we hope, corrected. Questions of the following three types predominated in the first category.

このドキュメントの最初のドラフトに対するコメントはほとんどなく、議論されたサービスの基本モデルまたはプロトコル設計を扱っていました。その代わり、彼らは私たちがしなかった決定について、そして著者が意図していないプロトコル仕様についての信念について尋ねることに焦点を合わせました。後者は修正されていると思います。最初のカテゴリーでは、次の3つのタイプの質問が優勢でした。

4.1. Why didn't you use <insert-favorite-directory-protocol-here>?
4.1. なぜ<挿入-お気に入り-ディレクトリ-プロトコル-ここ>を使用しなかったのですか?

Many notes raised the question of how much more could be done with a higher-powered directory protocol rather than the extremely simple WHOIS. Questions were raised about LDAP, X.500 DAP, CCSO, RWHOIS, and WHOIS++. We had several reasons for avoiding them. The most important has been a strong commitment to see how much can be done with an extremely simplistic approach, and WHOIS represented the most simplistic approach we could find. If it turns out to be too simple in practice, things can always evolve to one or more of the more advanced protocols. But, if we started with one of them, we would never get that information. Other issues included:

多くのノートは、非常に単純なWHOISではなく、より強力なディレクトリプロトコルでどれだけ多くのことができるかという疑問を提起しました。 LDAP、X.500 DAP、CCSO、RWHOIS、およびWHOIS ++に関する質問がありました。それらを回避する理由はいくつかありました。最も重要なのは、非常に単純なアプローチでどれだけのことができるかを確認するという強い決意です。WHOISは、私たちが見つけた最も単純なアプローチを表しています。実際に単純すぎると判明した場合、常に1つ以上のより高度なプロトコルに進化する可能性があります。しかし、それらの1つから始めた場合、その情報を取得することはできません。その他の問題が含まれます:

* None of the existing directory proposals has really emerged as the "right" solution with a large installed base. The deployed base of WHOIS and WHOIS clients is huge, and using it avoids either having to make a premature choice of "winner" or to become embroiled in the debate.

* 既存のディレクトリの提案はどれも、実際に大規模なインストールベースを持つ「正しい」ソリューションとして浮上していません。 WHOISおよびWHOISクライアントの展開ベースは膨大であり、それを使用することで、「勝者」を時期尚早に選択したり、議論に巻き込まれたりする必要がなくなります。

* For the casual user, the mechanisms needed to activate the extensive attribute-based directory searches of the stronger protocols are just too complicated and may actually act as a deterrent to effective use.

* カジュアルなユーザーにとって、より強力なプロトコルの広範な属性ベースのディレクトリ検索をアクティブにするために必要なメカニズムは、あまりに複雑であり、実際には効果的な使用を妨げる可能性があります。

* Substantially since the dawn of the ARPANET, the Internet experience has been that setting up a directory service is easy, but that maintaining one and keeping the records up-to-date is extremely difficult. The economics of operating an effective directory service and keeping everything up to date may will require a revenue-producing product. Use of a very simple protocol for the basic service creates a situation in which basic service can rationally be given away while more advanced service are operated on a charge or subscription basis.

* 実質的にARPANETの黎明以来、ディレクトリサービスの設定は簡単ですが、サービスを維持して最新の状態に保つことは非常に困難でした。効果的なディレクトリサービスを運用し、すべてを最新の状態に保つ経済性には、収益を生み出す製品が必要になる場合があります。基本サービスに非常に単純なプロトコルを使用すると、基本サービスを合理的に提供できる一方で、より高度なサービスが有料またはサブスクリプションベースで運用される状況が生じます。

4.2 And why not use a Web search engine?
4.2 そして、なぜウェブ検索エンジンを使用しないのですか?

Web search engines are immensely effective and powerful, but address a different problem than this protocol. The protocol model here does involve a directory lookup, using a presumed company name as a key.

Web検索エンジンは非常に効果的で強力ですが、このプロトコルとは異なる問題に対処します。ここでのプロトコルモデルには、推定される会社名をキーとして使用したディレクトリルックアップが含まれます。

The quality of the result will depend on the quality of the underlying directory and the editorial and research work that goes into its construction (neither of which are matters for the protocol itself -- we trust that marketplace pressures will separate good servers from poor ones). Web search engines are often more effective at locating information about companies than the specific company-designated web pages.

結果の品質は、基礎となるディレクトリの品質と、その構築に入る編集および調査作業に依存します(どちらもプロトコル自体の問題ではありません。市場の圧力によって、良いサーバーと悪いサーバーが分離されると信じています)。 。多くの場合、Web検索エンジンは、特定の会社が指定したWebページよりも、会社に関する情報を見つけるのに効果的です。

4.3 Why not return a more highly structured information format rather than a simple pair of URL and "company name"?

4.3 URLと「会社名」の単純なペアではなく、より高度に構造化された情報形式を返さないのはなぜですか?

Again, the goal was to keep things extremely simple and, in particular, permit minimal interpretation between the user's input and the query and between the response and a display or action. Some of the inquiries on this subject were due to misunderstandings about the implications of the "company name" field; the semantics of that field have been clarified above. We also wanted to avoid the level of standardization implied by a tagging scheme: highly-structured fields might lead either to interoperability problems or excessive restriction on what might be returned.

繰り返しになりますが、目標は物事を非常にシンプルに保つことであり、特に、ユーザーの入力とクエリの間、および応答と表示またはアクションの間の解釈を最小限にすることを許可することでした。この件に関するいくつかの問い合わせは、「会社名」フィールドの意味についての誤解によるものでした。そのフィールドのセマンティクスは上記で明確にされています。また、タグ付けスキームが意味する標準化のレベルを回避したいと考えました。高度に構造化されたフィールドは、相互運用性の問題または返される可能性のあるものに対する過度の制限のいずれかにつながる可能性があります。

5. Thoughts on Directory Providers
5. ディレクトリプロバイダーについての考え

There is no technical reason why there should be only one provider of company name to URL mapping services using this protocol, nor is there any reason for registries of such providers. Presumably, servers that provide the best-quality mappings will eventually prevail in the marketplace. However, as with most traditional uses of WHOIS, it is desirable for implementations of clients (or Web browsers supporting this protocol) to allow for user choice of servers through configuration options or the equivalent.

このプロトコルを使用するURLマッピングサービスへの会社名のプロバイダーを1つだけにする必要がある技術的な理由も、そのようなプロバイダーのレジストリの理由もありません。おそらく、最高品質のマッピングを提供するサーバーが、最終的には市場で普及するでしょう。ただし、WHOISのほとんどの従来の使用と同様に、クライアント(またはこのプロトコルをサポートするWebブラウザー)の実装では、ユーザーが構成オプションまたは同等のものを使用してサーバーを選択できるようにすることが望ましいです。

6. Demo Application
6. デモアプリケーション

To illustrate the proposed functionality of this document, a prototype of both the server and client have been made able for demonstration purposes.

このドキュメントの提案された機能を説明するために、サーバーとクライアントの両方のプロトタイプがデモ目的で使用できるようになっています。

6.1 Server
6.1 サーバ

The TLD-WHOIS demonstration server is available at "companies.mci.net". The server contains a database of approximately 209,000 company entries provided by Dun and Bradstreet.

TLD-WHOISデモサーバーは、「companies.mci.net」から入手できます。サーバーには、ダンとブラッドストリートが提供する約209,000の企業エントリのデータベースが含まれています。

The server will generally respond back to a query within 15 seconds. If the server has the response cached from a previous query, the return time will be significantly shorter.

サーバーは通常、15秒以内にクエリに応答します。サーバーが前のクエリからキャッシュされた応答を持っている場合、戻り時間は大幅に短くなります。

If 10 or more entries are found in the database for the query, only the top 10 will be returned in the response.

クエリのデータベースで10以上のエントリが見つかった場合、上位10のみが応答で返されます。

For the purposes of this demonstration, there is no provision for submitting additions or changes to the database. The authors and the sponsoring companies are not responsible for the accuracy of the data provided by this prototype. Our apologies if your company is not listed.

このデモでは、データベースへの追加または変更を送信するための規定はありません。著者とスポンサー企業は、このプロトタイプによって提供されるデータの正確性について責任を負いません。上場していない場合はお詫びします。

6.2 Client
6.2 クライアント

6.2.1 Download Location:

6.2.1 ダウンロード場所:

A demonstration client for the Windows 95/Nt platforms is available for public download through anonymous ftp at: ftp.mci.net/pub/ietf/company/demo.exe, or via the web: ftp://ftp.mci.net/pub/ietf/company/demo.exe File size is approximately 1.9 MB.

Windows 95 / Ntプラットフォームのデモンストレーションクライアントは、ftp.mci.net / pub / ietf / company / demo.exeの匿名ftpまたはWeb:ftp://ftp.mci.netから公開ダウンロードできます。 /pub/ietf/company/demo.exeファイルサイズは約1.9 MBです。

6.2.2 Setup Instructions:

6.2.2 セットアップ手順:

a) Download the client installation software from the site mentioned above to a local 32 bit Windows computer. The client installation software has been compressed using the self-extracting archive application from InstallShield The default name for the download is "demo.exe".

a) 上記のサイトからクライアントインストールソフトウェアをローカルの32ビットWindowsコンピューターにダウンロードします。クライアントインストールソフトウェアは、InstallShieldの自己解凍型アーカイブアプリケーションを使用して圧縮されています。ダウンロードのデフォルト名は「demo.exe」です。

b) Double click on the file through File Explorer or run the program through the START menu.

b) エクスプローラーでファイルをダブルクリックするか、スタートメニューからプログラムを実行します。

c) Select "Setup" to allow InstallShield to uncompress the files needed to install the demonstration client to a temporary directory. InstallShield will then automatically launch the main application Setup program.

c) 「セットアップ」を選択して、InstallShieldがデモンストレーションクライアントを一時ディレクトリにインストールするために必要なファイルを解凍できるようにします。 InstallShieldは、メインアプリケーションのセットアッププログラムを自動的に起動します。

d) The main setup program will install the demo application files and make the necessary additions to the Windows Registry. No user action is required.

d) メインセットアッププログラムは、デモアプリケーションファイルをインストールし、Windowsレジストリに必要な追加を行います。ユーザーの操作は必要ありません。

e) Upon completion of installation you will be prompted to run the application or to exit setup.

e) インストールが完了すると、アプリケーションを実行するか、セットアップを終了するように求められます。

6.2.3 Paranoia:

6.2.3 パラノイア:

What did you just do to my computer?

私のコンピューターに何をしたの?

Files Copied:

コピーされたファイル:

companyname.exe Main program executable whois.ocx WhoIs module from Mabry Software led.ocx LED module from Mabry Software msvbvm50.dll Microsoft Visual Basic 5.0 runtime file stdole2.tlb Microsoft Visual Basic 5.0 runtime file oleaut32.dll Microsoft Visual Basic 5.0 runtime file olepro32.dll Microsoft Visual Basic 5.0 runtime file comcat.dll Microsoft Visual Basic 5.0 runtime file asyncfilt.dll Microsoft Visual Basic 5.0 runtime file crtl3d32.dll Installshield control used for installation only

companyname.exeメインプログラムの実行可能ファイルmaisy Softwareのwhois.ocx WhoIsモジュールmabry Softwareのled.ocx LEDモジュールmsvbvm50.dll Microsoft Visual Basic 5.0ランタイムファイルstdole2.tlb Microsoft Visual Basic 5.0ランタイムファイルoleaut32.dll Microsoft Visual Basic 5.0ランタイムファイルolepro32 .dll Microsoft Visual Basic 5.0ランタイムファイルcomcat.dll Microsoft Visual Basic 5.0ランタイムファイルasyncfilt.dll Microsoft Visual Basic 5.0ランタイムファイルcrtl3d32.dll Installshieldコントロールはインストールにのみ使用されます

Registry Changes:

レジストリの変更:

Created key under HKEY_CLASSES_ROOT called Who

WhoというHKEY_CLASSES_ROOTの下に作成されたキー

This entry is used to enable the Microsoft Internet Explorer's pluggable protocol handler. The key contains several sub-entries that list the path and command to the companyname executable. The pluggable protocol hander provides the necessary hooks to launch the companyname application whenever the WHO:// URL is submitted in the address line of Internet Explorer.

このエントリは、Microsoft Internet Explorerのプラグ可能なプロトコルハンドラを有効にするために使用されます。キーには、companyname実行可能ファイルへのパスとコマンドをリストするいくつかのサブエントリが含まれています。プラグ可能なプロトコルハンドラーは、Internet Explorerのアドレス行でWHO:// URLが送信されるたびに、companynameアプリケーションを起動するために必要なフックを提供します。

6.2.4 Using the Program
6.2.4 プログラムの使用

6.2.4.1 Standalone Operation:

6.2.4.1 スタンドアロン操作:

From the Start Menu, select the Programs \ Companyname \ companyname. Alternatively, it can be launched from Start: Run c:\windows\companyname.exe

スタートメニューから、Programs \ Companyname \ companynameを選択します。または、スタートから起動することもできます。c:\ windows \ companyname.exeを実行します。

Enter the name of the company that you are attempting to locate and press OK.

検索しようとしている会社の名前を入力して、[OK]を押します。

A status box will be displayed while the client is communicating with the server until a response is returned. The possible returns are:

ステータスボックスは、クライアントがサーバーと通信している間、応答が返されるまで表示されます。可能なリターンは次のとおりです。

a) Message box saying that, "Your request was not found." This means that the company information that was submitted was not found in the database.

a) 「リクエストが見つかりませんでした」というメッセージボックス。これは、送信された会社情報がデータベースに見つからなかったことを意味します。

b) A list box containing 2 - 10 company names sorted high to low by score. Highlight one of the names and press the launch button. The program will launch the default web browser for your computer and navigate to the site.

b) スコアの高い順に並べられた2〜10の会社名を含むリストボックス。名前の1つを強調表示して、起動ボタンを押します。プログラムは、コンピューターのデフォルトのWebブラウザーを起動し、サイトに移動します。

c) The default web browser launches and navigates to a site. This means that only one match was found in the database and that match is opened directly without user intervention.

c) デフォルトのWebブラウザーが起動し、サイトに移動します。つまり、データベースで一致が1つだけ見つかったため、ユーザーの介入なしにその一致が直接開かれます。

6.2.4.2 Within Internet Explorer
6.2.4.2 Internet Explorer内

From the Address Line within the web browser, enter "WHO://" followed by the name of the company that you wish to search for and press the enter key.

Webブラウザー内のアドレス行から、「WHO://」と入力し、続いて検索する会社の名前を入力して、Enterキーを押します。

Note: Since the company name is entered within the URL space of the browser, it can not contain spaces.

注:会社名はブラウザーのURLスペース内に入力されるため、スペースを含めることはできません。

If you wish to send a search string that contains spaces, enter "WHO://" with no company information. The application will display the dialogue window as described in standalone mode for you to enter the search criteria.

スペースを含む検索文字列を送信する場合は、会社情報なしで「WHO://」と入力します。アプリケーションは、スタンドアロンモードで説明したように、検索条件を入力するためのダイアログウィンドウを表示します。

A status box will be displayed while the client is communicating with the server until a response is returned. The possible returns are:

ステータスボックスは、クライアントがサーバーと通信している間、応答が返されるまで表示されます。可能なリターンは次のとおりです。

a) Message box saying that, "Your request was not found." This means that the company information that was submitted was not found in the database.

a) 「リクエストが見つかりませんでした」というメッセージボックス。これは、送信された会社情報がデータベースに見つからなかったことを意味します。

b) A list box containing 2 - 10 company names sorted high to low by score. Highlight one of the names and press the launch button. The program will launch the default web browser for your computer and navigate to the site.

b) スコアの高い順に並べられた2〜10の会社名を含むリストボックス。名前の1つを強調表示して、起動ボタンを押します。プログラムは、コンピューターのデフォルトのWebブラウザーを起動し、サイトに移動します。

c) The default web browser launches and navigates to a site. This means that only one match was found in the database and that match is opened directly without user intervention.

c) デフォルトのWebブラウザーが起動し、サイトに移動します。つまり、データベースで一致が1つだけ見つかったため、ユーザーの介入なしにその一致が直接開かれます。

6.2.5 Client Customization
6.2.5 クライアントのカスタマイズ

The name of the Whois server is hardcoded within the application to "companies.mci.net". No initialization file or registry keys are needed for the default configuration. Realizing that some testers may have proxy servers on their corporate systems and that others may wish to test the client against a different Whois server, the client supports a mechanism for changing the default server. To enable the server customization, follow these steps:

Whoisサーバーの名前は、アプリケーション内で "companies.mci.net"にハードコードされています。デフォルト構成では、初期化ファイルやレジストリキーは必要ありません。一部のテスターは自社のシステムにプロキシサーバーを持っている場合があり、別のテスターは別のWhoisサーバーに対してクライアントをテストしたい場合があることを理解すると、クライアントはデフォルトサーバーを変更するメカニズムをサポートします。サーバーのカスタマイズを有効にするには、次の手順に従います。

a) Create a new directory in the root of the C: Drive called "companyname"

a) C:ドライブのルートに「companyname」という新しいディレクトリを作成します。

b) Using Notepad or any text editor create a new file called "whois.ini"

b) メモ帳または任意のテキストエディタを使用して、「whois.ini」という新しいファイルを作成します。

      c) Add a new line to the file beginning with
         "SERVER= <server name>". Do not include the double quotes
         around the tag. <server name> would be the IP Address or DNS
         name of the new Whois or proxy server.
        

d) End the line with a carriage return.

d) 改行で行を終了します。

e) Save the file as a plain text file back to "c:\companyname\whois.ini"

e) ファイルをプレーンテキストファイルとして「c:\ companyname \ whois.ini」に保存します。

6.2.6 Client Limitations:

6.2.6 クライアントの制限:

The demonstration software and database are provided "as is". No warranties are stated or implied. Use at your own risk.

デモンストレーションソフトウェアとデータベースは「現状のまま」提供されます。保証は明示または暗示されていません。自己責任。

The demonstration client is supported only on 32 bit Intel Windows platforms. It has been tested on Windows 95, Windows NT 4.0 and Windows 98 beta RC0.

デモクライアントは、32ビットIntel Windowsプラットフォームでのみサポートされています。 Windows 95、Windows NT 4.0、およびWindows 98ベータRC0でテストされています。

Use of the WHO:// URL moniker from within the web browser is supported only under Microsoft Internet Explorer.

Webブラウザー内からのWHO:// URLモニカーの使用は、Microsoft Internet Explorerでのみサポートされています。

TCP Port 43 must be cleared through firewalls for client to communicate with the server. Refer to the section on client customization if you need to utilize a proxy server to traverse a firewall.

クライアントがサーバーと通信するには、ファイアウォールを介してTCPポート43をクリアする必要があります。プロキシサーバーを利用してファイアウォールを通過する必要がある場合は、クライアントのカスタマイズに関するセクションを参照してください。

When using the Address Line entry method within Microsoft Internet Explorer, spaces are not permitted within the search string.

Microsoft Internet Explorer内で住所行入力メソッドを使用する場合、検索文字列内にスペースを使用することはできません。

7. References
7. 参考文献

[ABNF] Crocker, D., and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[ABNF] Crocker、D。、およびP. Overell、編、「構文仕様の拡張BNF:ABNF」、RFC 2234、1997年11月。

[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.

[RFC1591] Postel、J。、「ドメインネームシステムの構造と委任」、RFC 1591、1994年3月。

[GOPHER] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., John, D., Torrey, D., and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.

[ゴファー]アンクルサリア、F。、マッカヒル、M。、リンドナー、P。、ジョンソン、D。、ジョン、D。、トーリー、D。、およびB.アルベルティ、「インターネットGopherプロトコル(分散ドキュメントの検索と検索プロトコル)」、RFC 1436、1993年3月。

[LDAP] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.

[LDAP] Yeong、W.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol」、RFC 1777、1995年3月。

[RWHOIS] Williamson, S., and M. Kosters, "Referral Whois Protocol (RWhois)", RFC 1714, December 1994.

[RWHOIS] Williamson、S.、and M. Kosters、 "Referral Whois Protocol(RWhois)"、RFC 1714、December 1994。

[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[URL] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators(URL)」、RFC 1738、1994年12月。

[WHOIS] Feinler, E., Harrenstien, K., and M. Stahl, "NICNAME/WHOIS", RFC 954, October 1985.

[WHOIS] Feinler、E.、Harrenstien、K。、およびM. Stahl、「NICNAME / WHOIS」、RFC 954、1985年10月。

[WHOIS++] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.

[WHOIS ++] Deutsch、P.、Schoultz、R.、Faltstrom、P。、およびC. Weider、「Architecture of the WHOIS ++ service」、RFC 1835、1995年8月。

[X500] Wright, R., Getchell, A., Howes, T., Sataluri, S., Yee, P., and W. Yeong, "Recommendations for an X.500 Production Directory Service", RFC 1803, June 1995.

[X500] Wright、R.、Getchell、A.、Howes、T.、Sataluri、S.、Yee、P。、およびW. Yeong、「X.500 Production Directory Serviceの推奨事項」、RFC 1803、1995年6月。

[Z39.50] Lynch, C., "Using the Z39.50 Information Retrieval Protocol in the Internet Environment", RFC 1729, December 1994.

[Z39.50] Lynch、C。、「Using the Z39.50 Information Retrieval Protocol in the Internet Environment」、RFC 1729、1994年12月。

8. Security Considerations
8. セキュリティに関する考慮事項

This suggested use of the WHOIS protocol adds no significant security risks to those of traditional applications of the protocol which is one of the most widely-deployed applications on the Internet. As usual, servers should expect to use the string sent to them as an information retrieval key, not as a function to be executed in some way. A more significant risk would arise if the server supporting the translation function were somehow spoofed; in that case, an incorrect URL might be returned for a particular company. As with the possibility of finding an incorrect page using naming conventions, the best protection against the risks that could then occur is careful attention to certificates, signatures, and other authenticity-indicating information.

この推奨されるWHOISプロトコルの使用は、インターネット上で最も広く展開されているアプリケーションの1つである、プロトコルの従来のアプリケーションに重大なセキュリティリスクを追加しません。通常のように、サーバーは、サーバーに送信された文字列を、何らかの方法で実行される関数としてではなく、情報検索キーとして使用することを期待する必要があります。翻訳機能をサポートするサーバーが何らかの方法で偽装された場合、さらに重大なリスクが発生します。その場合、特定の会社に対して誤ったURLが返される可能性があります。命名規則を使用して誤ったページを見つける可能性と同様に、発生する可能性のあるリスクに対する最善の保護は、証明書、署名、およびその他の信頼性を示す情報に注意することです。

9. IANA Considerations
9. IANAに関する考慮事項

As provided in section 3.3, above, this experiment requests that IANA maintain a registry of query variation forms and that the registry be initialized with the two values specified in that section.

上記のセクション3.3で説明したように、この実験では、IANAがクエリバリエーションフォームのレジストリを維持し、レジストリをそのセクションで指定された2つの値で初期化するように要求します。

10. Acknowledgements
10. 謝辞

This memo was inspired by a many discussions over the last few years about the status and uses of the domain name system, information location using conventions about domain names, exposure of URLs to end users, and convergence of directory and search protocols. While the people involved are too numerous to attempt to list, the authors would like to acknowledge their contributions and comments.

このメモは、ドメインネームシステムのステータスと使用、ドメイン名に関する規則を使用した情報の場所、エンドユーザーへのURLの公開、およびディレクトリと検索プロトコルの収束に関する過去数年間の多くの議論に触発されました。関係者は多すぎてリストに載せることができませんが、著者は彼らの貢献とコメントを認めたいと思います。

Martin Hamilton, Keith Moore, Tom Thornbury and Ed Trembicki-Guy made important suggestions that have contributed to the revision of this memo.

マーティンハミルトン、キースムーア、トムソーンベリー、エドトレンビッキーガイは、このメモの改訂に貢献した重要な提案をしました。

11. Authors' Addresses
11. 著者のアドレス

John C. Klensin MCI Internet Architecture 800 Boylston St, 7th floor Boston, MA 02199 USA

John C. Klensin MCIインターネットアーキテクチャ800 Boylston St、7階Boston、MA 02199 USA

   Phone: +1 617 960 1011
   EMail: klensin@mci.net
        

Ted Wolf, Jr. Electronic Commerce Dun & Bradstreet Information Services 3 Sylvan Way Parsippany, NJ 07054 USA

Ted Wolf、Jr. Electronic Commerce Dun&Bradstreet Information Services 3 Sylvan Way Parsippany、NJ 07054 USA

   Phone: +1 201 605 6308
   EMail: ted@usa.net
        

Gary W. Oglesby MCI Internet Architecture 842 N. Ahoy Dr. Gilbert, AZ 85234 USA

Gary W. Oglesby MCI Internet Architecture 842 N. Ahoy Dr. Gilbert、AZ 85234 USA

   Phone: +1 415 538 1100
   EMail: gary@mci.net
        
12. 完全な著作権表示

Copyright (C) The Internet Society (1998). All Rights Reserved.

Copyright(C)The Internet Society(1998)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。