Network Working Group N. Popp
Request for Comments: 2972 RealNames Corporation
Category: Informational M. Mealling
Network Solutions
L. Masinter
AT&T Labs
K. Sollins
MIT
October 2000
Context and Goals for Common Name Resolution
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document establishes the context and goals for a Common Name Resolution Protocol. It defines the terminology used concerning a "Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of Common Name Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use.
この文書では、一般名解決プロトコルのための文脈と目標を確立します。これは、「一般名」について、どのように1が「解決」される可能性があります使用される用語を定義し、「解像度」、より精巧な検索メカニズムの区別を確立します。これは、一般的な名前解決を使用するためのいくつかの予想される状況、および成功したプロトコルを評価するための基準を設定しています。また、サービスは、公共、民間や商業の両方の使用のための一般的な名前解決を提供するために、原因となるさまざまな動機を分析します。
This document is intended as input to the formation of a Common Name Resolution Protocol working group. Please send any comments to cnrp-ietf@lists.internic.net. To review the mail archives, see <http://lists.internic.net/archives/cnrp-ietf.html>
この文書は、一般名解決プロトコルワーキンググループの形成への入力として意図されています。 cnrp-ietf@lists.internic.netに任意のコメントをお送りください。メールアーカイブを確認するには、<http://lists.internic.net/archives/cnrp-ietf.html>参照
People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and enter than URLs; many people consider URLs hard to remember or type. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are already being used elsewhere and therefore unavailable. Common names are not URIs (Uniform Resource Identifiers) in that they lack the syntactic structure imposed by URIs; furthermore, unlike URNs, there is no requirement of uniqueness or persistence of the association between a common name and a resource. These common names are expected to be used primarily by humans (as opposed to machine agents).
人々はしばしば、共通の名前やフレーズ、例えば、商品名、会社名、または書籍のタイトルで、現実の世界で物事を参照してください。これらの名前は覚えていて、URLを入力するよりも、人のために、時には簡単です。多くの人が覚えているか、入力するURLが難しいことを検討してください。また、理由のURLの限定された構文で、企業や個人は、そのリソースのための最も合理的であるかもしれないものは、すでに他の場所で、したがって、使用できない使用されていることを見つけています。彼らはのURIによって課される構文構造が不足しているという点で共通する名前はURI（Uniform Resource Identifiers）ではありません。さらに、のURNとは異なり、共通名とリソースとの間の関連付けの一意性又は永続性の必要はありません。これらの共通の名前は、（マシン・エージェントではなく）人間が主に使用されることが期待されます。
Common name "resolution" is a process of mapping from common names to Internet resources; a Common Name Resolution Protocol (CNRP) is a network protocol used in such a process.
一般名「解像度」のインターネットリソースへの共通名からのマッピングのプロセスです。共通名解決プロトコル（CNRP）は、このようなプロセスで使用されるネットワークプロトコルです。
A useful analogy for understanding the purpose and scope of common names, and CNRP, are everyday (human language) dictionaries. These cover a given language (namespace) -- perhaps a spoken language, or some specific subset (e.g., technical terms, etc). Some dictionaries give definitions, others give translations (e.g., to other languages). Different entities publish dictionaries that cover the same language -- e.g., Larousse and Collins can both publish French-language dictionaries. Thus, the dictionary publisher is the analog to the resolution service provider -- the service can provide a value-add and build up name recognition for itself, but does not impede other entities from providing definitions for precisely the same strings in the language.
便利な一般的な名前の目的と範囲を理解するための類推、及びCNRPは、日常の（人間の言語）辞書です。おそらく音声言語、またはいくつかの特定のサブセット（例えば、専門用語など） - これらは、特定の言語（名前空間）を覆います。いくつかの辞書には、他の人が（他の言語に、例えば）の翻訳を与える、定義を与えます。異なるエンティティは、同じ言語をカバーする辞書を公開 - 例えば、ラルースとコリンズは、両方のフランス語の辞書を公開することができます。このサービスは、それ自体のための付加価値とビルドアップ知名度を提供することができますが、言語で正確に同じ文字列の定義を提供するから、他のエンティティを妨げない - このように、辞書出版社は解決サービスプロバイダへのアナログです。
Services are arising that offer a mapping from common names to Internet resources (e.g., as identified by a URI). These services often resolve common name categories such as company names, trade names, or common keywords. Thus, such a resolution service may operate in one or a small number of categories or domains, or may expect the client to limit the resolution scope to a limited number of categories or domains. For example, the phrase "Internet Engineering Task Force" is a common name in the "organization" category, as is "Moby Dick" in the book category. A single common name may be associated with different data records, and more than one resolution service is expected to exist. Any common name may be used in any resolution service.
サービスは、（URIによって識別される、例えば）それは、インターネットのリソースに共通の名前からのマッピングを提供して生じています。これらのサービスは、多くの場合、会社名、商標名、または共通のキーワードとして一般名カテゴリを解決します。したがって、そのような解決サービスは、1つまたはカテゴリまたはドメインの少数で動作することができる、またはクライアントがカテゴリまたはドメインの限られた数の解像度の範囲を限定することを期待することができます。ブックカテゴリで「白鯨」であるとして、たとえば、句「インターネットエンジニアリングタスクフォース」には、「組織」カテゴリ内の共通の名前です。単一の共通名は、異なるデータ・レコードに関連付けられてもよく、複数の解像度のサービスが存在すると予想されます。任意の一般名は、任意の解像度サービスで使用することができます。
Two classes of clients of such services are being built: browser improvements and web accessible front-end services. Browser enhancements modify the "open" or "address" field of a browser so that a common name can be entered instead of a URL. Internet search sites integrate common name resolution services as a complement to search. In both cases, these may be clients of back-end resolution services. In the browser case, the browser must talk to a service that will resolve the common name. The search sites are accessed via a browser. In some cases, the search site may also be the back-end resolution service, but in others, the search site is a front-end to a collection of back-end services.
このようなサービスのクライアントの2つのクラスが構築されている：ブラウザの改善やウェブアクセスフロントエンドサービス。一般的な名前ではなくURLを入力することができるように、ブラウザの拡張機能は、ブラウザの「オープン」または「アドレス」フィールドを変更します。インターネット検索サイトが検索を補完するものとして、共通の名前解決サービスを統合します。どちらの場合も、これらは、バックエンド解決サービスのクライアントになることがあります。ブラウザの場合、ブラウザは一般的な名前を解決するサービスに相談しなければなりません。検索サイトは、ブラウザを介してアクセスされています。いくつかのケースでは、検索サイトでは、バックエンド解決サービスであってもよいが、他に、検索サイトには、バックエンドサービスのコレクションのフロントエンドです。
This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is intended to address the issues of internationalization, authentication and privacy as well. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is expected to be a simple, minimal interoperable core. Mechanisms for extension will be provided, so that additional capabilities can be added later.
この取り組みは、ブラウザの機能拡張と検索サイトパラダイムの両方に例示するように、一般的な名前解決サービスと通信するためのクライアントアプリケーションのためのプロトコルの作成についてです。プロトコルの主な機能は、解像度ではあるが、同様に国際化、認証とプライバシーの問題に対処することを意図しています。名前解決サービスは、一般的な検索サービスではありませんので、複雑なブールクエリ、関連性のランキングや同様の機能を提供する必要はありません。プロトコルは、単純な、最小限の相互運用性コアであることが期待されます。追加機能を後から追加することができるように拡張するためのメカニズムは、提供されます。
Several other issues, while of importance to the deployment of common name resolution services, are outside of the resolution protocol itself and are not in the initial scope of the proposed effort. These include discovery and selection of resolution service providers, administration of resolution services, name registration, name ownership, and methods for creating, identifying or insuring unique common names.
他のいくつかの問題、一般的な名前解決サービスの展開に重要で、解決プロトコル自体の外側にありながら、提案の努力の最初の範囲ではありません。これらは、発見と解決サービスプロバイダの選択、解決サービスの管理、名前登録、名前の所有権、および作成、同定またはユニークな共通の名前を保証するための方法を含みます。
The key deliverable is a protocol for parameterized resolution. "Resolution" is defined as the retrieval of data associated (a priori) with descriptors that match the input request. "Parameterized" means the ability to have a multi-component descriptor both as part of the query and the response. These descriptors are attribute-value pairs. They are not required to provide unique identification, therefore 0 or more records may be returned to meet a specific input query. The protocol will define:
キー成果は、パラメータ化された解決のためのプロトコルです。 「解像度」が入力された要求に一致する記述子に関連付けられたデータの検索（アプリオリ）として定義されます。 「パラメータ」は、両方のクエリの一部と応答として、マルチコンポーネント記述子を持っている能力を意味します。これらの記述子は、属性と値のペアです。従って、それらは0以上のレコードは、特定の入力クエリを満たすために返されることがあり、固有の識別を提供する必要はありません。プロトコルを定義します：
- client requests/server responses to identify the specific parameters accepted and/or required on input requests
- 入力要求に受け入れられ、および/または必要な特定のパラメータを識別するためのクライアント要求/サーバ応答
- client request/server responses to identify properties to be returned in the result set
- 結果セットに返される性質を識別するためのクライアントのリクエスト/サーバ応答
- expression of parameterized input query
- パラメータ化入力されたクエリの発現
- expression of result sets
- 結果セットの発現
- standard expression of error conditions
- エラー条件の標準的な発現
To avoid creating a general search protocol with unbounded complexity, and to keep the protocol simple enough so that different implementations will have similar behavior, the resolution protocol should be limited to sub-string matches against parameter values. To support full internationalization, UTF-8 encoding of strings and sub-strings is preferred.
無限の複雑さを持つ一般的な検索プロトコルを作成しないように、異なる実装が類似した挙動を有するように、十分な単純なプロトコルを維持するために、解決プロトコルは、パラメータ値に対する部分文字列の一致に限定すべきです。完全な国際化をサポートするために、文字列とサブ文字列のUTF-8エンコーディングが好ましいです。
In addition, the working group should define one sample service based on this protocol -- the resolution of so-called "common names", or resolution of non-unique, registered strings to resource descriptions.
いわゆる「普通名称」、またはリソース記述に一意でない、登録された文字列の解像度の解像度 - また、ワーキンググループは、このプロトコルに基づいて一つのサンプルサービスを定義する必要があります。
The goal of CNRP is to create a lightweight search protocol with a simple query interface, with a focus on making the common case of substring search with a single result most efficient. In addition, efficient support for keyed value search is important. Each key is a named meta property of the resource (e.g. category, language, geographical region.). Some of these properties could be standardized (e.g. the common name property). The goal is to support partial specification of query parameters and even partial and fuzzy matches on names. CNRP is intended to be simpler than LDAP for simple applications.
CNRPの目標は、最も効率的な単一の結果を部分文字列検索の一般的なケースを作るに焦点を当て、簡単なクエリインターフェイスで軽量な検索プロトコルを作成することです。また、鍵付き値探索のための効率的なサポートが重要です。各キーは、リソースの名前のメタプロパティである（例えば、カテゴリ、言語、地理的地域。）。これらのプロパティのいくつかは、（例えば、共通のnameプロパティ）を標準化することができます。目標は、クエリパラメータと名前でも、部分的およびあいまい一致の一部仕様をサポートすることです。 CNRPは、単純なアプリケーションのためのLDAPよりも単純であることを意図しています。
Besides simplicity, the CNRP protocol should be consistent with efficient implementation of a simple and intuitive user interface. The emphasis on the common name as the common denominator to find a wide range of resources reduces the UI to its minimal expression (the user types a few words in a text box and presses enter).
簡潔に加え、CNRPプロトコルは簡単で直感的なユーザーインタフェースの効率的な実装と一致しなければなりません。資源の広い範囲を見つけるための共通分母として、一般的な名前に重点がその最小限の表現（ユーザーの種類、数、テキストボックス内の単語とプレス入力します）にUIを低減します。
CNRP should provide interoperability with multiple common name databases (section 4 presents many examples of such databases). The query interface should be extensible and customizable to the specific needs of a specific type of resolution service. However, the need for interoperability across databases and resolution services combined with the need to ensure the scalability of search (across millions of names from multiple providers) have lead this group to consider the explicit requirement of supporting categories in CNRP. This requirement is discussed further in section 5.
CNRPは、複数の共通名データベースとの相互運用性を提供しなければならない（セクション4は、このようなデータベースの多くの例を示します）。クエリインタフェースは、解像度サービスの特定の種類の特定のニーズに拡張可能かつカスタマイズ可能であるべきです。しかし、（複数のプロバイダからの名前の何百万人を越え）検索のスケーラビリティを確保する必要性と組み合わせたデータベースと解決サービス間の相互運用性の必要性がCNRPにおける支持カテゴリの明示的な要件を検討するために、このグループをリードしてきました。この要件は、セクション5でさらに説明されます。
Commercial companies have already developed and deployed common name resolution services such as RealNames (http://www.realnames.com) and NetWords (http://www.netword.com). These commercial implementations are mainly focused on trade names, such as company names, brands and trademarks. These services constitute a concrete example of common name namespaces implementation and are useful to understand the scope of the CNRP effort.
商業企業は、すでに開発され、このようなRealNames（http://www.realnames.com）とNetWords（http://www.netword.com）などの一般的な名前解決サービスを展開しています。これらの商用の実装は、主に、会社名、ブランドおよび商標として商標名、に焦点を当てています。これらのサービスは、共通の名前の名前空間の実装の具体的な例を構成し、CNRPの努力の範囲を理解するのに有用です。
CNRP is also directly targeted at directory service providers. CNRP is relevant to these services to increase their reach through integration into larger Web sites such as the search portals. For example, IAtlas has developed a directory service for businesses that it distributes through its Web site and Inktomi. IAtlas could immediately leverage CNRP to distribute their service through their external distribution partners.
CNRPも直接、ディレクトリ・サービス・プロバイダを対象としています。 CNRPは、検索ポータルのような大きなWebサイトへの統合を通じて、リーチを高めるために、これらのサービスに関連しています。例えば、IAtlasは、そのWebサイトとInktomiのを通じて配布する企業のためのディレクトリ・サービスを開発しました。 IAtlasはすぐに外部の販売パートナーを通じてサービスを配布しCNRPを活用できます。
Directory services must not be confused with search engines. Directory services use highly structured information to identify a resource. This information is external to the actual resource and is called metadata. In contrast, search engines mainly rely on the content of the resource (e.g. the text of a Web page).
ディレクトリサービスは、検索エンジンと混同してはなりません。ディレクトリサービスは、リソースを識別するために、高度に構造化された情報を使用します。この情報は、実際のリソースの外部にあり、メタデータと呼ばれています。これとは対照的に、検索エンジンは、主にリソース（Webページのテキストなど）の内容に依存しています。
CNRP plays well with directory services that present a critical piece of information about the resource in the form of a textual identifier, a title or a terse description (the common name). Numerous examples come instantly to mind: company names, book titles, people names, songs, ISBNs, and social security numbers. In all cases, the common name is the natural property for users to lookup the resource. The common name is always simple and intuitive: it has no syntax, it is multilingual, memorable and can often be guessed.
CNRPは、テキスト識別子、タイトルや簡潔な説明（一般名）の形で資源に関する情報の重要な部分を提示ディレクトリサービスとよく果たしています。会社名、書名、人の名前、歌、ISBNコード、および社会保障番号：多数の例は、心に瞬時に来ます。すべての場合において、一般的な名前は、ユーザーがリソースを検索するための自然な性質です。一般名は、常にシンプルかつ直感的です：それは何の構文を持っていない、それは、多言語思い出に残ると、多くの場合、推測することが可能です。
The following list is intended to put in prospective the wide range of applications for CNRP:
以下のリストは、将来にCNRP用アプリケーションの広い範囲を置くことを目的としています。
- Business directories (SEC, NASDAQ, E*Trade, .). The resource is company information (address, products, SEC filings, stock quotes, etc.). The common name is the company name.
- ビジネスディレクトリ（SEC、NASDAQ、E *トレード、。）。リソースは、会社の情報（住所、製品、SECへの提出書類、株価など）です。共通名は会社名です。
- White pages (BigFoot, WhoWhere, Switchboard, ...): The resource a person (current address, telephone numbers, email addresses, employer, ...). The common name is a last name, a telephone number or an email address.
- ホワイトページ（ビッグフット、WhoWhere、配電盤、...）：リソース人（現在の住所、電話番号、電子メールアドレス、雇用主、...）。共通名は姓、電話番号や電子メールアドレスです。
- E-commerce directories: The resource is a product for sale (car, house, furniture, actually almost any type of consumption item). The common name is a brand name or a description.
- Eコマースディレクトリ：リソースは、販売用の製品（車、家、家具、実際にはほとんど消費項目のいずれかのタイプ）です。一般名は、ブランド名や説明です。
- Publishing directories: The resource is one of many things: a book, a poem, a CD, an MP3 download. The common name is an ISBN, a song title, an artist's name. The common name is typically the title of a publication.
- ディレクトリを公開：ブック、詩、CD、MP3のダウンロード：リソースは、多くのものの一つです。一般名はISBN、曲のタイトル、アーティスト名です。共通名は通常、出版物のタイトルです。
- Entertainment directories: The resource is an event (a movie, a concert, a TV show). The common name is the name or a description for the event, the movie title, a rock band name, a show.
- エンターテインメントディレクトリ：リソースはイベント（映画、コンサート、テレビ番組）です。一般的な名前は、名前やイベント、映画のタイトル、ロックバンド名、番組の説明です。
- Yellow pages services: Here again, the resource can be very diverse: a house for sale, a restaurant, a car dealership or other type of establishment or service that can be found in the traditional yellow pages. The common name can be a street address, the name of a business, or a description.
- イエローページサービス：ここでもう一度、資源は非常に多様であることができます。販売のための家、レストラン、カーディーラーや伝統的なイエローページで見ることができる確立またはサービスの他のタイプ。共通名は住所、ビジネスの名前、または説明することができます。
- News feeds: The resource is a press article. The common name is the headline.
- ニュースフィード：リソースは、プレス品です。一般的な名前は見出しです。
- Vertical directories: the DNS TLD categories, the ISO country codes.
- 垂直ディレクトリ：DNSのTLDカテゴリ、ISOの国コード。
A set of common names within a category (books, news, businesses, etc.) is called a common name "namespace". The term "namespace" only refers to the set of names. It does not encompass the bindings or associations between a name and data about the name (such as a resource, identified by a URI). Such bindings might be created and maintained by a common name resolution services. Resolution services may create binding that are relevant for the type of service that they offer.
カテゴリ（書籍、ニュース、ビジネス、など）内の共通名のセットは、共通の名前「名前空間」と呼ばれています。用語「名前空間は」名前だけのセットを指します。これは、名前（たとえば、URIで識別されるリソース、など）についての名称とデータ間のバインディングや団体を包含していません。このようなバインディングは、共通の名前解決サービスによって作成され、維持されることがあります。解決サービスは、彼らが提供するサービスの種類に関連するその結合作成することができます。
It is useful to distinguish between "private" and "public" namespaces. A namespace is private if owned by an authority that controls the right to assign the names. A namespace is private even if the right to assign those names is held by a neutral party.
「プライベート」と「公共」の名前空間を区別するのに便利です。名前を割り当てるための権利を制御機関が所有する場合、名前空間はプライベートです。名前空間は、それらの名前を割り当てる権利が中立パーティによって保持されている場合でも、プライベートです。
A namespace is public when not controlled by any single authority or resolution provider. Assignment of the names is distributed. However, it is reasonable to expect that people who assign names will tend to pick names that have a minimum of collisions. For some of these namespaces, there will even be mechanisms to discourage duplicate assignment, but all of them are inherently ambiguous. Public namespaces are not controlled. Examples of public namespaces are:
任意の単一の権限や解像度プロバイダによって制御されないとき、名前空間はpublicです。名前の割り当てが配布されています。しかし、名前を割り当てる人々は衝突の最小値を持っている名前を選択する傾向があることを期待するのは合理的です。これらの名前空間の一部について、でもそこに重複割り当てを阻止するためのメカニズムであってもよいが、それらのすべては、本質的に曖昧であるだろう。公共の名前空間は制御されません。公共の名前空間の例としては、以下のとおりです。
- Titles of books, movies, songs, poems, short stories, plays, or compilations - Place names - Street names - People's names
地名 - - ストリート名 - 人名 - 本、映画、歌、詩、短編小説、演劇、またはコンパイルのタイトル
Because these namespaces are unbounded and open to any types of name assignment, they will have scalability problems. To support these namespaces, CNRP must provide at least one standard mechanism to filter a large list of related results. A filtering mechanism must allow the user to narrow the search further down to a smaller result set, because the common name alone may not be enough.
これらの名前空間は無制限と名前の割り当てのいずれかの種類に開かれているので、彼らは、スケーラビリティの問題が発生します。これらの名前空間をサポートするために、CNRPは、関連する結果の大規模なリストをフィルタリングするための少なくとも1つの標準的なメカニズムを提供しなければなりません。フィルタリング機構だけでは、共通の名前が十分ではない可能性があるため、ユーザは、さらに下に小さい結果セットに検索を絞り込むことができなければなりません。
One possible search filter is related to the notion of categories. Because categories create a structure to organize named resources, large resolution services are likely to support some sort of categorization system (whether flat or hierarchical). Although categories constitute an efficient search filter, defining standard vocabularies for common name categories is beyond the scope of the protocol design. The protocol design for CNRP should not require a standardized taxonomy for categories in order to be effective. For example, CNRP resolution could use free-form keywords; the end-user would use these keywords as part of the query. Each service would then be responsible for mapping the keywords to zero, one or many categories in their own classification. The keywords would remain classification independent and different services could use different categorization schemes without compromising interoperability. It would then be up to the service to provide its own mapping. For example, let us assume that one namespace is resolving names under the category: "Hobby & Interests > collecting > antique > books". Assume that a second namespace has decided to organize the names of similar resources under the classification: "Arts > Humanities > Literature > History of Books and Printing > antiques". Although the two taxonomies are different, a CNRP query specifying category_keywords = "antique books" would allow each service to identify the appropriate category. This mechanism may ensure that the two result lists are small and coherent enough to be merged into one unique result set. It is important to note that this approach would work whether the classification is hierarchical or not.
一つの可能な検索フィルタは、カテゴリの概念に関連しています。カテゴリは名前付きリソースを整理するために構造を作成するので、大規模な解決サービスは、分類システム（フラットまたは階層的かどうか）のいくつかの並べ替えをサポートする可能性があります。カテゴリは、効率的な検索フィルタを構成しているが、共通名のカテゴリの標準語彙を定義するプロトコル設計の範囲を超えています。 CNRPためのプロトコルの設計が有効であるためにカテゴリの標準化された分類を必要とすべきではありません。例えば、CNRP解像度は自由形式のキーワードを使用することができます。エンドユーザーは、クエリの一部としてこれらのキーワードを使用します。各サービスは、その後、独自の分類では、ゼロ、1または多くのカテゴリにキーワードをマッピングするための責任を負うことになります。キーワードは分類が独立したままになり、異なるサービスは、相互運用性を損なうことなく、異なる分類スキームを使用することができます。その後、独自のマッピングを提供するために、最大のサービスになります。 「趣味・興味>収集>アンティーク>本」：たとえば、私たちは1つの名前空間がカテゴリの下に名前解決されたと仮定しましょう。 「芸術>人文>文学>本と印刷の歴史>アンティーク」：第二の名前空間は、分類の下に類似したリソースの名前を整理することを決定したとします。 2つの分類法は異なりますが、category_keywords =「アンティークブック」を指定CNRPクエリは、各サービスの適切なカテゴリを識別できるようになります。このメカニズムは、2つの結果リストが小さく、1つのユニークな結果セットにマージされるのに十分コヒーレントであることを保証することができます。このアプローチは、分類は階層的であるか否かがうまくいくことに注意することが重要です。
Although this suggestion has merit, it is fair to say that it remains unproven. In particular, it is unclear that the category_keywords property would guarantee full interoperability across resolution services. In any case, free form keywords for specifying categories is just one of several possible ways of limiting the scope of a query. Although the specific mechanisms are not agreed upon a this time, CNRP will provide at least one standard mechanism for limiting scope.
この提案はメリットがありますが、証明されていないままであることを言っても過言で。特に、category_keywordsプロパティは解決サービス間で完全な相互運用性を保証することは不明です。いずれの場合も、カテゴリを指定するための自由形式のキーワードは、クエリの範囲を制限するいくつかの可能な方法のひとつです。具体的なメカニズムは、この時間に合意されていないが、CNRPは、範囲を限定するための少なくとも一つの標準的なメカニズムを提供します。
We anticipate two main categories of distributors for common namespaces. The first category is made of the Web portals such as search engines (Yahoo, MSN, Lycos, Infoseek, AltaVista, ...). A common name resolution service will typically address only one very specialized aspect of search (company names or book titles or people names, ..). This type of focused lookup service is a useful complement to generic search. Hence, portals are likely to integrate several types of common name services. CNRP solves the difficult problem of integrating multiple external independent services within one Web site. Today, the lack of standardization in performance requirements and query interface leads to loose integration (co-branded pages hosted on virtual domains) or maintenance problems (periodical data dumps). CNRP is aimed at solving some of these issues. CNRP facilitates the deployment of embedded services by creating a common interface to all common name services.
私たちは、共通の名前空間のための代理店の2つの主なカテゴリを期待しています。最初のカテゴリは、検索エンジン（ヤフー、MSN、ライコス、インフォシーク、アルタビスタ、...）などのWebポータルで作られています。一般的な名前解決サービスは、通常、検索の唯一の非常に特殊な側面（会社名や本のタイトルや人の名前、..）を取り上げます。集中検索サービスのこのタイプは、一般的な検索に便利な補完するものです。したがって、ポータルは、共通のネームサービスのいくつかのタイプを統合する可能性があります。 CNRPは1つのWebサイト内に複数の外部の独立したサービスを統合の困難な問題を解決します。今日では、性能要件における標準化の欠如とクエリインターフェイスは、統合（仮想ドメインでホストされている共同ブランドページ）または保守の問題（定期的なデータ・ダンプ）を失うにつながります。 CNRPは、これらの問題の一部を解決することを目的とします。 CNRPは、すべての一般的な名前のサービスに共通のインターフェースを作成することにより、埋め込まれたサービスの展開を容易にします。
The second category of distributors is made of the Web browser companies. Netscape's smart browsing (http://home.netscape.com/communicator/v4.5/index.html#smart) and Microsoft's IE5 auto-search features (http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp) demonstrate that the two dominant Web browser companies understand the value of navigation and search from the command line of the browser. It is very clear how this command line could be used as the main user interface to common name resolution services through CNRP. In many ways, it is actually the most natural user interface to resolve a common name. For this strategic component of the browser's user interface to remain truly open to all common name resolution services, it is key that there exists a standard resolution protocol (and a service discovery mechanism). CNRP will give users access to the largest selection of services and providers and the ability to select a specific resolution service over another. To preserve the user from proprietary implementations, the existence of CNRP is a prerequisite.
代理店の第二のカテゴリーは、Webブラウザの企業で構成されています。ネットスケープのスマートブラウジング（http://home.netscape.com/communicator/v4.5/index.html#smart）とMicrosoftのIE5自動検索機能（http://www.microsoft.com/windows/Ie/Features/自動検索/ default.aspの）2つの主要なWebブラウザの企業は、ナビゲーションの価値を理解し、ブラウザのコマンドラインから検索することを示しています。このコマンドラインはCNRPを介して共通の名前解決サービスへのメインユーザーインターフェイスとして使用することができる方法は非常に明確です。多くの点で、実際に一般的な名前を解決するための最も自然なユーザーインターフェースです。ブラウザのユーザーインターフェースのこの戦略的なコンポーネントはすべて、共通の名前解決サービスに本当に開いたままにするためには、標準解像度プロトコル（およびサービス発見機構）が存在することが鍵となります。 CNRPは、ユーザーがサービスやプロバイダや他の上の特定の解決サービスを選択することの最大の選択へのアクセスを提供します。独自の実装からユーザーを維持するために、CNRPの存在が前提条件です。
The following discussion of possible business models for common name namespaces is intended to prove that they are commercially viable, hence that CNRP will be used in the market place. This section presents 5 different cost recovery models.
共通名の名前空間のための可能なビジネスモデルの以下の議論はCNRPは、市場の場所で使用されること、したがって、彼らは商業的に実現可能であることを証明することを意図しています。このセクションでは、5種類の原価回収モデルを提示します。
a. Licensing the lookup service
A。検索サービスのライセンス
In such model, the owner of the database owner licenses the data and the resolution service to a portal. This is a proven model. For example, Looksmart (a directory service) recently licensed all their data to MSN. Another possibility is to sell access to the service directly to the user. For some vertical type of common names service (e.g. patent search), it is also conceivable that a specific type of users (e.g., lawyers) would be willing to pay for accessing a precise resolution service.
そのようなモデルでは、データベース所有者の所有者は、ポータルへのデータ及び解像度サービスをライセンス。これは実績のあるモデルです。例えば、ルックスマート（ディレクトリサービス）は、最近、MSNにすべてのデータのライセンスを取得しました。別の可能性としては、ユーザに直接サービスへのアクセスを販売することです。一般的な名前のサービス（例えば、特許検索）の一部の縦型の場合は、ユーザーの特定のタイプ（例えば、弁護士は）正確な解決サービスにアクセスするために支払うことをいとわないということも考えられます。
b. Sharing revenue generated by banner advertising
B。バナー広告によって生成された共有収入
In this model, the database owner licenses his infrastructure (data and resolution service) to a portal. Prepaid banner ads are placed on the result pages. The revenue is shared between the resolution service provider and the portal that hosts the pages.
このモデルでは、データベース所有者は、ポータルに彼のインフラ（データおよび解像度サービス）をライセンス供与しています。プリペイドバナー広告は、結果ページに配置されています。収入は解決サービスプロバイダおよびページをホストするポータル間で共有されています。
c. Selling the names (charge the customer a fee for subscribing a name)
C。名前を売る（名前をサブスクライブするために顧客に料金を請求）
This is a proven business model as well (NSI, GOTO, RealNames, Netword, for of the name has a large user reach (search engines sell keywords for instance).
これは、（同様に実績のあるビジネスモデルである名前のためのNSI、GOTO、RealNames、ネットワークは、大規模なユーザーリーチを持っている（検索エンジンは、例えば、キーワードを販売します）。
d. Value added service
D。値は、サービスを追加しました
Another model is to build a common name as a free added value service in order to make a core service more compelling to users. For example, Amazon.com could create a common name namespace of book titles and make it freely available to its users. Amazon.com would not make any money from the resolution service per se. However, it would indirectly since the service would help the users find hence buy more books from Amazon.com.
別のモデルは、ユーザーにとってより魅力的なコアサービスを行うために、自由な付加価値サービスなどの一般的な名前を構築することです。例えば、Amazon.comは書籍のタイトルの共通名の名前空間を作成し、そのユーザーにそれを自由に利用できるようにすることができます。 Amazon.comは解決サービス自体から任意のお金を稼ぐことではないでしょう。しかし、それはサービスは、ユーザーがAmazon.comからより多くの本を買うので、見つけるのに役立つであろうから、間接的でしょう。
e. "Some-strings-attached" free names
電子。無料の名称「一部-文字列付」
A namespace may give users a name for free in exchange for something else (capturing the user's profile that can be sold to merchants, capturing the user's email address in order to send advertising emails, etc.).
名前空間は、何か他のもの（など、広告メールを送信するために、ユーザーの電子メールアドレスをキャプチャ、商人に売却することができ、ユーザーのプロファイルをキャプチャ）と引き換えに、ユーザーが自由に名前を与えることができます。
This document describes the goals of a system for multi-valued Internet identifiers. This document does not discuss resolution; thus questions of secure or authenticated resolution mechanisms are out of scope. It does not address means of validating the integrity or authenticating the source or provenance of Common Names. Issues regarding intellectual property rights associated with objects identified by the various Common Names are also beyond the scope of this document, as are questions about rights to the databases that might be used to construct resolvers.
この文書では、多値インターネット識別子のためのシステムの目標を説明します。この文書では、解像度については説明しません。したがって、セキュアまたは認証された解決メカニズムの問題は適用範囲外です。これは、整合性を検証したり共通の名前のソースまたは出所を認証する手段に対応していません。リゾルバを構築するために使用されるかもしれないデータベースへの権利についての質問がそうであるように、様々な共通の名前で識別されるオブジェクトに関連付けられた知的財産権に関する問題は、この文書の範囲外でもあります。
Larry Masinter AT&T Labs 75 Willow Road Menlo Park, CA 94025
ラリーMasinter AT＆T Labsの75ウィローロードメンロパーク、CA 94025
Phone: +1 650 463 7059 EMail: LMM@acm.org http://larry.masinter.net
電話：+1 650 463 7059 Eメール：LMM@acm.org http://larry.masinter.net
Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070
マイケル・メオーリングネットワークソリューション505 Huntmarパークドライブハーンドン、VA 22070
Phone: (770) 935-5492 Fax: (703) 742-9552 EMail: michaelm@netsol.com
電話：（770）935-5492ファックス：（703）742-9552 Eメール：michaelm@netsol.com
Nicolas Popp RealNames Corporation 2 Circle Star Way San Carlos, CA 94070-1350
ニコラスPoppのRealNames社2サークルスターウェイサンカルロス、カリフォルニア州94070から1350
Phone: 1-650-298-5549 EMail: nico@realnames.com
電話：1-650-298-5549 Eメール：nico@realnames.com
Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
コンピュータサイエンス545平方技術のためのカレンSollins MIT研究所。ケンブリッジ、MA 02139
Phone: +1 617 253 6006 EMail: sollins@lcs.mit.edu
電話：+1 617 253 6006 Eメール：sollins@lcs.mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。