RFC2345 日本語訳
2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G.Oglesby. May 1998. (Format: TXT=29707 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Klensin
Request for Comments: 2345 MCI
Category: Experimental T. Wolf
Dun & Bradstreet
G. Oglesby
MCI
May 1998
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2345年のMCIカテゴリ: 実験T.オオカミ灰褐色とブラッドストリートG.オグレスビMCI1998年5月
Domain Names and Company Name Retrieval
ドメイン名と会社名検索
Status of this Memo
この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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
インターネットとウェブが発展するのに応じて、それらの名前に基づく特定の会社のためのウェブ情報の位置はますます難しい問題になりました。 命名規則とドメイン名システム(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.
このドキュメントは最も古くて最も複雑でないインターネットディレクトリプロトコルに基づくURLマッピングサービスに会社名を提案します、whois、非常に簡単で広く配布しているプロトコルが、より複雑で強力なオプションが失敗されるか、または過度に遅らせているところで成功できるか否かに関係なく、探検するために。
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:
最近の数カ月には、「トップ・レベル・ドメイン問題」に関してインターネットコミュニティの様々なセグメントに多くの議論がありました。 恐らく特徴として、その用語は、異なって、恐らくほとんど直交した問題を特定するのに異なったグループによって使用されます。 それらの問題は:
Klensin, et. al. Experimental [Page 1] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[1ページ]RFC2345ドメイン名と会社名検索1998年5月
1.1. A "domain administration policy" issue.
1.1. 「ドメイン管理方針」問題。
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に関する論争はインターネットの成長の必然の結果であるかもしれません。 トップ・レベル・ドメインadminstrationにおける間欠困難とそのような多くのドメインが割り当てられ始めたのでサービスプロバイダーの、または、サービスのコントロールにメカニズムとして時々ドメイン登録機能を使用する様々な試みがありました。 それらの問題は[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番目は他のどんなメカニズムも利用可能でないので主にWWWの爆発的成長の結果とエンドユーザへのURL形式[URL]の特に暴露であるように見えます。 適切で適切に配布しているディレクトリサービスの不在はそれがウェブページがすなわち、XYZ社に関して場所を見つけたその会社の商号か製品名にかかわる命名規則の使用で会社のためのウェブページの場所を見つけるのにおいて可能であるべき仮定につながりました。
http://www.xyz.com/
or
http://www.xyz-company.com/
http://www.xyz.com/ か 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"を除いたドメインに根づくのに従って、このコンベンションは支えるのが難しくなります: あまりに多くの組織か会社が恐らく適法の要償ビジネスの異なった系列か同じ短い描写的である名前への管内にあるでしょう。 その理由で、ドメイン名システムへの変化にあったのではなく、一般的な感覚がこの情報位置問題への解決がある数年間の共同体、タイプのディレクトリサービスにありました。
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]
Klensin, et. al. Experimental [Page 2] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[2ページ]RFC2345ドメイン名と会社名検索1998年5月
[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。][リス] これが起こっていない理由に関する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プロトコルはインターネットで使用中の最も古いディレクトリアクセス・プロトコルです、発行されたフォームでいくらか早く実装された3月1982日と1日までデートして。 そして、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サーバにアクセスするウェブブラウザに作成されることを提案します、推定の会社名を送って、1つ以上の台詞を受け返して、それぞれ1回以上の空白と次に、合っている会社名があとに続いたURLを含んでいて(そのオーダーは構文解析問題を最小にするために選ばれました: URLが空白を含むことができないので、最初のブランクは、URLの端と次の非空白のマークが会社名の始まりであるとマークします)。 ご多分に漏れず、Whois、サーバによって使用される、合っている評価基準と共にサーバの裁量には入って来るストリングがあります。 [WHOIS]に記録されるこれとプロトコルの違いは系列単位でまさに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) 単線(会社名と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が選択した使用をとって来てください。
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.
本書では熟考されたサービスの最も便利な使用がクライアントを通して起こるでしょうが、明らかに、それがウェブブラウザに離れているか、または親密に接することであった、そのタイプの施設のないユーザは伝統的なWHOISクライアントとペーストを利用するか、またはそうでなければ、ブラウザの目標位置に関連情報を移すことができました。
Klensin, et. al. Experimental [Page 3] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[3ページ]RFC2345ドメイン名と会社名検索1998年5月
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]):
形式(RFC2234[ABNF]のABNF記法を使用する)の(ii)五弦:
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
変化:==、「0インチ」| (非無ケタ1*ケタ) 非無ケタ:==1| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ケタ:==0| 非無ケタ
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.
最初のフォームが主なひもで2番目のフォームと同等物に理解される、「0/、」 変化番号はセクション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
サーバが1つ以上の系列をクライアントに返すと予想されます、入力ストリングの解釈によって。 一般に、各系列は上でURL、スペース、および「会社名」について説明されるように成るでしょう。 このドキュメントは故意に「会社名」ストリングの内容か意味論を指定しません。 それは、名前、位置や業種などの名前と記述的な情報、またはサーバの選択で他の情報であるかもしれません。
Klensin, et. al. Experimental [Page 4] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[4ページ]RFC2345ドメイン名と会社名検索1998年5月
expectation, as mentioned above, is that the information will be displayed by the client to aid users in selecting the appropriate 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系列(それらの制御文字の1かもう片方よりむしろ)によって正常なインターネット習慣と一致したこれらの系列は終えられるでしょう。
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と会社名」応答の代わりに、Serverは「エラーメッセージ」を返すかもしれません。 これらは以下を含む系列の形を取ります。
"///" SP String
「///」SPストリング
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:
変化番号に関連している変化がSP別の方法で指定しない場合Stringが制御文字がなければ7ビットのASCIIであるところで。 この実験において、すべての「エラーメッセージ」にもかかわらず、以下の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.
///は、クライアントによって供給された変化番号が///変化がIndicatingをサポートしなかった何かですが、「会社名」が合っていないIndicatingがサーバによって認識されているのがわかりませんでした。
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.
7ビットのASCIIには0/質問と応答があって、SP以外のコントロールがない、「会社名」は1つ以上のSPキャラクタでURLから分離しました。
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、1つ以上のSPキャラクタ(入力か出力のどちらかでの言語の仕様がない)によってURLと切り離された「会社名」以外のどんなコントロール中ではありません。
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 。
Klensin, et. al. Experimental [Page 5] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[5ページ]RFC2345ドメイン名と会社名検索1998年5月
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.
* 実質的に、アルパネットの夜明け以来、インターネット経験はディレクトリサービスをセットアップするのが簡単ですが、1つを維持して、記録を最新につけるのが非常に難しいということです。 有効なディレクトリサービスとすべてが時代について行かせるのがそうする作動の経済学は収入を生産する製品を必要とするでしょう。 非常に簡単なプロトコルの基本サービスの使用は、より高度なサービスが充電か購読ベースで操作されている間合理的に基本サービスをあげることができる状況を作成します。
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.
インターネット検索エンジンは、非常に効果的であって、強力ですが、そのこのプロトコルと異なった問題を訴えてください。 キーとして推定された会社名を使用して、ここのプロトコルモデルはディレクトリルックアップにかかわります。
Klensin, et. al. Experimental [Page 6] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[6ページ]RFC2345ドメイン名と会社名検索1998年5月
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.
結果の品質は工事に入る基本的なディレクトリの品質、社説、および研究に依存するでしょう(どちらも、件はプロトコル自体のためのどれの、ものでないか--私たちは、市場圧力が貧しいものと良いサーバを切り離すと信じます)。 会社の情報の場所を見つけるところでは、インターネット検索エンジンは特定の会社がウェブページを指定したよりしばしば効果的です。
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のほとんどの伝統的な用途のように、クライアント(または、このプロトコルをサポートするウェブブラウザ)の実装が設定オプションか同等物を通したサーバのユーザ選択を考慮するのは、望ましいです。
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"で利用可能です。 サーバはDunとブラッドストリートによって提供されたおよそ20万9000の会社のエントリーに関するデータベースを含んでいます。
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秒以内に質問に反応して戻るでしょう。 サーバで前の質問から応答をキャッシュすると、再実行時間はかなり短くなるでしょう。
Klensin, et. al. Experimental [Page 7] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[7ページ]RFC2345ドメイン名と会社名検索1998年5月
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.
アノニマスFTPのを通した公共のダウンロードについて、Windows95/Ntプラットホームへのデモンストレーションクライアントが以下にいます。 ftp.mci.net/パブ/は、/会社/demo.exeをietfするか、またはウェブでそうします: ftp://ftp.mci.net/pub/ietf/company/demo.exe ファイルサイズはおよそ1.9MBです。
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) Fileエクスプローラーを通してファイルの上をダブルクリックするか、またはスタートメニューを通したプログラムを動かしてください。
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は自動的に主要出願Setupプログラムを実行するでしょう。
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 Registryにするでしょう。 ユーザ動作は全く必要ではありません。
e) Upon completion of installation you will be prompted to run the
application or to exit setup.
e) インストールの完成のときに、アプリケーションを実行するか、またはあなたがセットアップを出るようにうながされるでしょう。
Klensin, et. al. Experimental [Page 8] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[8ページ]RFC2345ドメイン名と会社名検索1998年5月
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 MainはメイブリーSoftware led.ocx LEDモジュールからコントロールがインストールだけのために費やしたメイブリーSoftware msvbvm50.dllマイクロソフトVisual Basic5.0ファイルstdole2.tlbマイクロソフトVisual Basic5.0ファイルoleaut32.dllマイクロソフトVisual Basic5.0ファイルolepro32.dllマイクロソフトVisual Basic5.0ファイルcomcat.dllマイクロソフトVisual Basic5.0ファイルasyncfilt.dllマイクロソフトVisual Basic5.0ランタイムファイルcrtl3d32.dll Installshieldランタイムランタイムランタイムランタイムランタイムから実行可能なwhois.ocx WhoIsモジュールをプログラムします。
Registry Changes:
登録変化:
Created key under HKEY_CLASSES_ROOT called Who
ROOTがWhoと呼んだHKEY_CLASSES_の下で主要な状態で、作成されます。
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のpluggableプロトコル操作者を可能にするのに使用されます。 キーは経路とコマンドを実行可能なcompanynameに記載するいくつかのサブエントリーを含んでいます。 pluggableプロトコルhanderは、インターネット・エクスプローラーのアドレス記入欄で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を選択してください。 あるいはまた、Startからそれを始めることができます: 走行c: \窓の\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) メッセージボックスがそれを示して、「あなたの要求は見つけられませんでした」。 これは、提出された会社の情報がデータベースで見つけられなかったことを意味します。
Klensin, et. al. Experimental [Page 9] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[9ページ]RFC2345ドメイン名と会社名検索1998年5月
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つを強調してください、そして、発射ボタンを押してください。 プログラムは、あなたのコンピュータのためにデフォルトウェブブラウザを実行して、サイトへナビゲートするでしょう。
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) デフォルトウェブブラウザは、サイトへ始めて、ナビゲートします。 これは、データベースと1一致するだけであるものが探されて、そのマッチが直接ユーザ介入なしで開けられることを意味します。
6.2.4.2 Within Internet Explorer
6.2.4.2 インターネット・エクスプローラーの中で
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.
ウェブブラウザの中のAddress線から、あなたが捜し求めたい会社の名前があとに続いた「WHO://」に入ってください、そして、エンターキーを押してください。
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つを強調してください、そして、発射ボタンを押してください。 プログラムは、あなたのコンピュータのためにデフォルトウェブブラウザを実行して、サイトへナビゲートするでしょう。
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) デフォルトウェブブラウザは、サイトへ始めて、ナビゲートします。 これは、データベースと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"へのアプリケーションの中でhardcodedされます。 どんな初期化ファイルも登録キーもデフォルト設定に必要ではありません。 何人かのテスターがそれらの法人のシステムの上にプロキシサーバを持っているかもしれなくて、他のものが異なったWhoisサーバに対してクライアントをテストしたがっているかもしれないとわかって、クライアントは、標準サーバーを変えるためにメカニズムをサポートします。サーバ改造を可能にするには、これらの方法に従ってください:
Klensin, et. al. Experimental [Page 10] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[10ページ]RFC2345ドメイン名と会社名検索1998年5月
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) Notepadかどんなテキストエディタも使用して、"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.
c) 「SERVERは<サーバー名>と等しいこと」で始まるファイルに復帰改行を追加してください。 タグの周りで二重引用符を含めないでください。 <サーバー名>は新しいWhoisかプロキシサーバのIP AddressかDNS名でしょう。
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ビットのインテルWindowsプラットホームだけでサポートされます。それはWindows95、Windows NT4.0、およびWindows 98ベータRC0でテストされました。
Use of the WHO:// URL moniker from within the web browser is supported only under Microsoft Internet Explorer.
ウェブブラウザからの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 Port43をきれいにしなければなりません。ファイアウォールを横断するのにプロキシサーバを利用する必要があるなら、クライアント改造のときにセクションを参照してください。
When using the Address Line entry method within Microsoft Internet Explorer, spaces are not permitted within the search string.
Microsoft Internet Explorerの中でAddress線記入要領を使用するとき、空間は検索ストリングの中に受入れられません。
7. References
7. 参照
[ABNF] Crocker, D., and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.とP.Overell、Eds、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591] ポステルと、J.と、「ドメインネームシステム構造と委譲」(RFC1591)は1994を行進させます。
[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.
[ゴーファー] Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、ジョン、D.、トーリー、D.、およびB.アルベルティ、「インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)」、RFC1436(1993年3月)。
Klensin, et. al. Experimental [Page 11] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[11ページ]RFC2345ドメイン名と会社名検索1998年5月
[LDAP] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[LDAP] YeongとW.とハウズ、T.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[RWHOIS] Williamson, S., and M. Kosters, "Referral Whois Protocol (RWhois)", RFC 1714, December 1994.
[RWHOIS]ウィリアムソン、S.とM.Kosters、「紹介Whoisプロトコル(RWhois)」、RFC1714、1994年12月。
[URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[WHOIS] Feinler, E., Harrenstien, K., and M. Stahl, "NICNAME/WHOIS", RFC 954, October 1985.
1985年10月の[WHOIS]FeinlerとE.とHarrenstien、K.とM.スタール、「NICNAME/WHOIS」RFC954。
[WHOIS++] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
[1995年8月のWHOIS+ +] ドイツ語とP.とSchoultzとR.とFaltstrom、P.とC.ワイダー、「WHOIS++サービスのアーキテクチャ」RFC1835。
[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]ライトとR.とゲッチェルとA.とハウズとT.とSataluriとS.とイー、P.とW.Yeong、「X.500生産ディレクトリサービスのための推薦」RFC1803(1995年6月)。
[Z39.50] Lynch, C., "Using the Z39.50 Information Retrieval Protocol in the Internet Environment", RFC 1729, December 1994.
[Z39.50] リンチ、C.、「インターネット環境でZ39.50情報検索プロトコルを使用します」、RFC1729、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つの値がそのセクションで指定されている状態で登録が初期化されるよう要求します。
Klensin, et. al. Experimental [Page 12] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[12ページ]RFC2345ドメイン名と会社名検索1998年5月
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.
マーチン・ハミルトン、キース・ムーア、トムThornbury、およびエド・Trembicki-ガイはこのメモの改正に貢献した重要な提案をしました。
11. Authors' Addresses
11. 作者のアドレス
John C. Klensin MCI Internet Architecture 800 Boylston St, 7th floor Boston, MA 02199 USA
ジョンC.Klensin MCIインターネットArchitecture800Boylston通り、7階のボストン、MA02199米国
Phone: +1 617 960 1011 EMail: klensin@mci.net
以下に電話をしてください。 +1 1011年の617 960メール: klensin@mci.net
Ted Wolf, Jr. Electronic Commerce Dun & Bradstreet Information Services 3 Sylvan Way Parsippany, NJ 07054 USA
テッドオオカミ、Jr.電子通商灰褐色、およびブラッドストリート情報は3つの森の方法でパーシッパニー、ニュージャージー07054米国にサービスを提供します。
Phone: +1 201 605 6308 EMail: ted@usa.net
以下に電話をしてください。 +1 6308年の201 605メール: ted@usa.net
Gary W. Oglesby MCI Internet Architecture 842 N. Ahoy Dr. Gilbert, AZ 85234 USA
おーい、ゲーリーW.オグレスビMCIインターネットアーキテクチャ842N.ギルバートアリゾナ85234博士(米国)
Phone: +1 415 538 1100 EMail: gary@mci.net
以下に電話をしてください。 +1 1100年の415 538メール: gary@mci.net
Klensin, et. al. Experimental [Page 13] RFC 2345 Domain Names and Company Name Retrieval May 1998
et Klensin、アル。 実験している[13ページ]RFC2345ドメイン名と会社名検索1998年5月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
Klensin, et. al. Experimental [Page 14]
一覧
スポンサーリンク
