[要約] RFC 2972は、共通名解決の文脈と目標について説明しています。その目的は、異なるネットワーク環境での名前解決の一貫性と相互運用性を確保することです。
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.
Copyright（c）The Internet Society（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.
このドキュメントは、共通名の解決プロトコルのコンテキストと目標を確立します。「共通名」と「解決」の方法に関して使用される用語を定義し、「解決」とより精巧な検索メカニズムの区別を確立します。共通名の解像度を使用するための予想されるコンテキスト、および成功したプロトコルを評価するための基準を確立します。また、サービスが公共、民間、商業用の両方に共通名の解決を提供するさまざまな動機を分析します。
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の構文が限られているため、企業と個人は、リソースにとって最も合理的なものがすでに他の場所で使用されており、したがって利用できないことを発見しています。一般名は、urisによって課される構文構造を欠いているという点で、uris（均一なリソース識別子）ではありません。さらに、urとは異なり、共通名とリソースの間に関連性の独自性や持続性の要件はありません。これらの一般的な名前は、主に人間によって使用されることが期待されています（機械エージェントとは対照的に）。
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の目的と範囲を理解するための有用な類推は、日常的な（人間の言語）辞書です。これらは特定の言語（名前空間）をカバーします - おそらく話し言葉、または特定のサブセット（例：技術用語など）。いくつかの辞書は定義を与え、他の辞書は翻訳を与えます（例：他の言語）。異なるエンティティは、同じ言語をカバーする辞書を公開します - 例えば、LarusseとCollinsはどちらもフランス語の辞書を公開できます。したがって、辞書パブリッシャーは解像度サービスプロバイダーとの類似点です。サービスは、付加価値を提供し、それ自体に対して名前の認識を築くことができますが、他のエンティティが言語のまったく同じ文字列の定義を提供することを妨げません。
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つまたは少数のカテゴリまたはドメインで動作する場合があります。また、クライアントが解像度スコープを限られた数のカテゴリまたはドメインに制限することを期待する場合があります。たとえば、「インターネットエンジニアリングタスクフォース」というフレーズは、「組織」カテゴリの一般名であり、本カテゴリの「Moby Dick」と同様です。単一の共通名が異なるデータレコードに関連付けられている場合があり、複数の解像度サービスが存在すると予想されます。任意の一般名は、任意の解像度サービスで使用できます。
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つのクラスのクライアントが構築されています：ブラウザの改善とWebアクセス可能なフロントエンドサービス。 ブラウザの拡張は、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.
さらに、ワーキンググループは、このプロトコルに基づいて1つのサンプルサービスを定義する必要があります - いわゆる「共通名」の解像度、または非不合理な登録文字列の解決策はリソースの説明に登録されています。
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の目標は、シンプルなクエリインターフェイスを備えた軽量検索プロトコルを作成することであり、単一の結果を最も効率的にサブストリング検索の一般的なケースにすることに重点を置いています。さらに、キー付きバリュー検索の効率的なサポートが重要です。各キーは、リソースの名前付きメタプロパティ（例：カテゴリ、言語、地理的領域など）です。これらのプロパティの一部は、標準化される可能性があります（例：共通名プロパティ）。目標は、クエリパラメーターの部分的な仕様、および名前の部分的およびファジーな一致をサポートすることです。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*TRADE、。）。リソースは、企業情報（住所、製品、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.
- ホワイトページ（Bigfoot、Whowhere、Switchboard、...）：リソースA（現在の住所、電話番号、電子メールアドレス、雇用主など）。一般名は、姓、電話番号、または電子メールアドレスです。
- 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ダウンロードなど、多くのことの1つです。一般名は、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:
単一の権限または決議プロバイダーによって制御されていない場合、名前空間は公開されます。名前の割り当てが配布されます。ただし、名前を割り当てる人は、最小限の衝突を持つ名前を選択する傾向があることを期待するのが合理的です。これらの名前空間のいくつかについては、重複する割り当てを阻止するメカニズムさえありますが、それらはすべて本質的に曖昧です。パブリックネームスペースは制御されていません。パブリックネームスペースの例は次のとおりです。
- 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.
1つの可能な検索フィルターは、カテゴリの概念に関連しています。カテゴリは名前のリソースを整理するための構造を作成するため、大規模な解像度サービスは、何らかの分類システム（フラットまたは階層のいずれか）をサポートする可能性があります。カテゴリは効率的な検索フィルターを構成しますが、共通名カテゴリの標準語彙を定義することは、プロトコル設計の範囲を超えています。CNRPのプロトコル設計では、効果的になるためにカテゴリの標準化された分類法を必要としないはずです。たとえば、CNRP解像度はフリーフォームキーワードを使用できます。エンドユーザーは、クエリの一部としてこれらのキーワードを使用します。各サービスは、キーワードをゼロにマッピングする責任があります。これは、独自の分類において1つまたは多くのカテゴリになります。キーワードは分類されたままであり、異なるサービスは、相互運用性を損なうことなく異なる分類スキームを使用する可能性があります。その後、独自のマッピングを提供するのはサービス次第です。たとえば、1つの名前空間がカテゴリの下で名前を解決していると仮定しましょう。「趣味と興味>コレクション>アンティーク>本」。セカンドネームスペースが分類の下で同様のリソースの名前を整理することを決定したと仮定します：「芸術>人文科学>文学>本と印刷の歴史>骨ant品」。2つの分類法は異なりますが、category_keywords = "Antique Books"を指定する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プロパティが解像度サービス全体の完全な相互運用性を保証することは不明です。いずれにせよ、カテゴリを指定するためのフリーフォームキーワードは、クエリの範囲を制限するいくつかの可能な方法の1つにすぎません。特定のメカニズムは今回は合意されていませんが、CNRPは範囲を制限するための少なくとも1つの標準メカニズムを提供します。
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つの主要なカテゴリが予想されます。最初のカテゴリは、検索エンジン（Yahoo、MSN、Lycos、Infoseek、Altavistaなど）などの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.
ディストリビューターの2番目のカテゴリは、Webブラウザー会社で作成されています。Netscapeのスマートブラウジング（http://home.netscape.com/communicator/v4.5/index.html#smart）およびMicrosoftのIE5 Auto-Search機能（http://www.microsoft.com/windows/ie/features/AutoSearch/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.
このようなモデルでは、データベース所有者の所有者がデータと解像度サービスにポータルにライセンスを与えます。これは実績のあるモデルです。たとえば、Lookmart（ディレクトリサービス）は最近、すべてのデータを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
e. 「Some Strings-atdached」無料の名前
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
Larry Masinter AT＆T Labs 75 Willow Road Menlo Park、CA 94025
Phone: +1 650 463 7059
EMail: LMM@acm.org
http://larry.masinter.net
Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070
Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon、VA 22070
Phone: (770) 935-5492 Fax: (703) 742-9552 EMail: michaelm@netsol.com
電話：（770）935-5492ファックス：（703）742-9552メール：michaelm@netsol.com
Nicolas Popp RealNames Corporation 2 Circle Star Way San Carlos, CA 94070-1350
ニコラス・ポップリアルネームズコーポレーション2サークルスターウェイサンカルロス、カリフォルニア94070-1350
Phone: 1-650-298-5549 EMail: nico@realnames.com
電話：1-650-298-5549メール：nico@realnames.com
Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139
Karen Sollins MITコンピュータサイエンスのための研究所545テクノロジーSq。ケンブリッジ、マサチューセッツ州02139
Phone: +1 617 253 6006
EMail: sollins@lcs.mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。