RFC2972 日本語訳

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

コメントを求めるワーキンググループN.ポップの要求をネットワークでつないでください: 2972年のRealNames社のカテゴリ: ネットワークソリューションL.Masinter AT&T研究室K.Sollins MIT2000年10月に食事する情報のM.

              Context and Goals for Common Name Resolution

俗称解決の文脈と目標

Status of this Memo

この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)インターネット協会(2000)。 All rights reserved。

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.

このドキュメントは俗称Resolutionプロトコルの文脈と目標を確立します。 それは、「俗称」に関して使用される用語と1つがどう「決議されているかもしれないか」を定義して、「解決」と、より入念な検索メカニズムの区別を確立します。俗称Resolutionの使用のためのいくつかの予想された文脈、およびうまくいっているプロトコルを評価する評価基準を確立します。 また、それはサービスが公共の、そして、個人的なものと同様に商業の使用のための俗称解決を提供する様々な動機を分析します。

   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>

このドキュメントは俗称Resolutionプロトコルワーキンググループの構成に入力されるように意図します。 あらゆるコメントを cnrp-ietf@lists.internic.net に送ってください。 メールアーカイブを再検討するには、<http://lists.internic.net/アーカイブ/cnrp-ietf.html>を見てください。

1. Introduction

1. 序論

   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

人々はしばしば例えば一般名か句による本当の世界のもの、商号、会社名、または書名を参照します。 人々には、これらの名前は覚えていて、入るのはURLより時々簡単です。 多くの人々が、覚えているか、またはURLがタイプしにくいと考えます。 その上、URLの限られた構文のために、会社と個人は、そうするかもしれないものが最も妥当であることがわかっています。

Popp, et al.                 Informational                      [Page 1]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[1ページ]のRFC2972文脈と目標

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

それらのリソースが既にほかの場所で中古であって、したがって、入手できない状態であるので。 URIによって課された統語構造を欠いているので、一般名はURI(Uniform Resource Identifier)ではありません。 その上、一般名とリソースとの協会のユニークさか固執の要件は全くURNsと異なっていません。 これらの一般名は主として人間(マシンエージェントと対照的に)によって使用されると予想されます。

   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.

一般名「解決」は一般名からインターネット資料までのマッピングのプロセスです。 俗称Resolutionプロトコル(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の範囲は毎日(人間の言語)の辞書です。 これらは与えられた言語(名前空間)をカバーしています--恐らく話し言葉、または何らかの特定の部分集合(例えば、専門用語など)。 いくつかの辞書が定義を与えて、他のものは翻訳(例えば、他の言語への)を与えます。 異なった実体は同じ言語をカバーする辞書を発行します--例えば、ラルースとコリンズはともにフランスの言語辞書を発行できます。 したがって、辞書出版社は解決サービスプロバイダーへのアナログです--サービスは、値で加えた状態でaを提供して、それ自体のために知名度を確立できますが、言語で正確に同じストリングのための定義を提供するので、他の実体を妨害しません。

   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か少ない数のカテゴリかドメインで作動するか、またはクライアントが解決範囲を限られた数のカテゴリかドメインに制限すると予想するかもしれません。 例えば、「インターネット・エンジニアリング・タスク・フォース」という句は「組織」カテゴリにおいて一般名です、本のカテゴリにおける「白鯨」のように。 ただ一つの一般名は異なったデータレコードに関連しているかもしれません、そして、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

2つのクラスのそのようなサービスのクライアントは建てられています: ブラウザ改良とウェブのアクセスしやすいフロントエンドサービス。 ブラウザ増進は、URLの代わりに一般名を入れることができるようにブラウザの「戸外」か「アドレス」分野を変更します。 インターネット検索サイトは、探すために補数として一般名解決サービスを統合します。 どちらの場合も、これらはバックエンド解決サービスのクライアントであるかもしれません。 ブラウザ事件では、ブラウザは一般名を決議するサービスと話さなければなりません。 を通して検索サイトがアクセスされている。

Popp, et al.                 Informational                      [Page 2]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[2ページ]のRFC2972文脈と目標

   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.

ブラウザ。 また、いくつかの場合、検索サイトはバックエンド解決サービスであるかもしれませんが、他のものでは、検索サイトはバックエンドサービスの収集へのフロントエンドです。

   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.

解決プロトコル自体の外にあって、他のいくつかの問題が一般名解決サービスの展開への重要性についてある間、提案された取り組みの初期の範囲にありません。 これらはユニークな一般名を作成するか、特定するか、または保障するための解決サービスプロバイダーの発見と品揃え、解決サービスの管理、名前登録、名前所有権、およびメソッドを含んでいます。

2. Key Goals for a Common Name Resolution Protocol

2. 俗称解決プロトコルの主要な目標

   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:

主要な提出物はparameterized解決のためのプロトコルです。 「解決」は(先験的に)入力要求に合っている記述子に関連しているデータ検索と定義されます。 「Parameterizedしたこと」は質問の一部と応答として多成分系の記述子を持つ能力を意味します。 これらの記述子は属性値組です。 それらはユニークな識別を提供するのが必要ではありません、したがって、特定の入力質問を満たすために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

- parameterized入力質問の式

      - expression of result sets

- 結果セットの式

      - standard expression of error conditions

- エラー条件の定型の表現

Popp, et al.                 Informational                      [Page 3]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[3ページ]のRFC2972文脈と目標

   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つのサンプルサービスを定義するべきです--いわゆる「一般名」の解決、またはリソース記述への非ユニークで、登録されたストリングの解決。

3. CNRP goals

3. CNRP目標

   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で、より詳しくこの要件について議論します。

4. Example of common name namespaces

4. 一般名名前空間に関する例

   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

営利会社は、一般名がRealNames( http://www.realnames.com )やNetWords( http://www.netword.com )などの解決サービスであると既に開発して、配布しました。 そしてこれらの商業実装が主に会社名、ブランドなどの商号に焦点を合わせられる。

Popp, et al.                 Informational                      [Page 4]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[4ページ]のRFC2972文脈と目標

   trademarks.  These services constitute a concrete example of common
   name namespaces implementation and are useful to understand the scope
   of the CNRP effort.

商標登録します。 これらのサービスは、一般名名前空間実装に関する具体的な実例を構成して、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は検索入り口などの、より大きいウェブサイトへの統合でそれらの範囲を増強するこれらのサービスに関連しています。 例えば、IAtlasはそれがそのウェブサイトとインクトミを通して分配するビジネスのためにディレクトリサービスを開発しました。 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).

ディレクトリサービスはサーチエンジンに混乱してはいけません。 ディレクトリサービスは、リソースを特定するのに構造化された情報を非常に使用します。 この情報は、実際のリソースに外部であり、メタデータと呼ばれます。 対照的に、サーチエンジンはリソース(例えば、ウェブページのテキスト)の内容を主に当てにします。

   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は原文の識別子、タイトルまたは簡潔な記述(一般名)の形でディレクトリサービスで上手にリソースのそんなに現在の情報をプレーします。 多数の例は即座に思い浮かびます: 会社名、書名、人々名、歌、ISBNs、および社会保険番号。 ケース、一般名は全部で、ユーザのための生まれながらの特性です。ルックアップへのリソース。 一般名は、いつも簡単であって、直感的です: 構文が全くなくて、それは、多言語であって、忘れられなく、しばしば推測できます。

   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、ナスダック、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.

- ホワイトページ(BigFoot、WhoWhere、Switchboard): リソースa人(現在のアドレス、電話番号、Eメールアドレス雇い主、…)。 一般名は、姓、電話番号またはEメールアドレスです。

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

- 電子商取引ディレクトリ: リソースは売り物の製品(車、家、家具、実際にほとんどどんなタイプの消費項目も)です。 一般名は、ブランド名か記述です。

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

- ディレクトリを発表します: リソースは多くのものの1つです: 本、詩、CD、MP3ダウンロード。 一般名はISBN、曲名、芸術家の名前です。 通常、一般名は刊行物のタイトルです。

Popp, et al.                 Informational                      [Page 5]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[5ページ]のRFC2972文脈と目標

   - 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国名略号。

5. Private and public namespaces

5. 個人的で公共の名前空間

   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.

カテゴリ(本、ニュース、ビジネスなど)の中の1セットの一般名は一般名「名前空間」と呼ばれます。 「名前空間」という用語は名前のセットについて言及するだけです。 それは名前(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

- 本、映画、歌、詩、短編、劇、または編集のタイトル--地名--通り名--人々の名前

Popp, et al.                 Informational                      [Page 6]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[6ページ]のRFC2972文脈と目標

   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つの名前空間がカテゴリの下で名前を決議していると仮定しましょう: 「>のアンティークな>の本を集める趣味とInterests>。」 2番目の名前空間が、分類で同様のリソースの名前を組織化すると決めたと仮定してください: 「BooksとPrinting>骨董品の芸術>Humanities>Literature>歴史。」 2つの分類学が異なっていますが、カテゴリ_キーワードを指定する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.

この提案には、長所がありますが、それが立証されないままで残っていると言うのは公正です。 カテゴリ_キーワードの特性が解決サービスの向こう側に最大限のインターオペラビリティを保証するのは、特に、不明瞭です。 どんなケース、カテゴリを指定するための自由形式キーワードにも、ちょうど質問の範囲を制限するいくつかの可能な方法の1つがあります。 特定のメカニズムは同意されませんが、今回、CNRPは少なくとも1つの標準のメカニズムを範囲を制限するのに提供するでしょう。

6. Distributors/integrators of common name resolution services

6. 一般名解決サービスのディストリビュータ/インテグレーター

   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

私たちは一般的な名前空間のためにディストリビュータの2つの主なカテゴリを予期します。 最初のカテゴリはサーチエンジン(Yahoo、MSN、ライコスインフォシーク、AltaVista)などのウェブ入り口で作られています。 A

Popp, et al.                 Informational                      [Page 7]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[7ページ]のRFC2972文脈と目標

   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.

一般名解決サービスは検索の1つの非常に専門化している局面だけを通常扱うでしょう(会社名、書名または人々名)。 このタイプの集中しているルックアップサービスは、役に立ってジェネリック検索に理想的です。 したがって、入り口はいくつかのタイプの一般名サービスを統合しそうです。 CNRPは1つのウェブサイトの中の複数の外部の独立しているサービスを統合する難問を解決します。 今日、性能要件と質問インタフェースの標準化の不足はゆるい統合(バーチャル・ドメインでホスティングされたページと共同商標を付けられる)かメインテナンス問題(定期刊行のデータ憂鬱)を引き起こします。 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番目のカテゴリはウェブブラウザー会社で作られています。 Netscapeのきびきびしたブラウジング( http://home.netscape.com/communicator/v4.5/index.html#smart )とマイクロソフトのIE5自動検索機能( http://www.microsoft.com/windows/Ie/Features/AutoSearch/default.asp )は、2つの優位なウェブブラウザー会社がナビゲーションの値を理解して、ブラウザのコマンドラインから探すのを示します。 主なユーザーインタフェースとしてどのようにCNRPを通した一般名解決サービスにこのコマンドラインを使用できたかは非常に明確です。 様々な意味で、それは一般名を決議する実際に最も自然なユーザーインタフェースです。 ブラウザのユーザーインタフェースのこの戦略のコンポーネントが本当に、すべての一般名解決サービスに開かれていたままで残るように、標準の解決プロトコル(そして、サービス発見メカニズム)が存在するのは、主要です。 CNRPは別のものの上でサービスとプロバイダーの最も広い品揃えと特定の解決サービスを選択する能力へのアクセスをユーザに与えるでしょう。 独占実装からユーザを保存するために、CNRPの存在は前提条件です。

7. Example of cost recovery models for maintenance of namespaces

7. 名前空間のメインテナンスのための原価回収モデルに関する例

   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

そのようなモデルでは、データベース所有者の所有者は入り口へのデータと解決サービスを認可します。 これは立証されたモデルです。 例えば、Looksmart(ディレクトリサービス)は最近、それらのすべてのデータをMSNに認可しました。 別の可能性は直接ユーザに対するサービスへのアクセスを販売することです。 一般的の立形のために

Popp, et al.                 Informational                      [Page 8]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[8ページ]のRFC2972文脈と目標

      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.

名前サービス(例えば、特許調査)、また、特定のタイプのユーザ(例えば、弁護士)が、正確な解決サービスにアクセスする対価を支払っても構わないと思っているだろうというのが想像できます。

   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、ゴトー、RealNames、有という名前では、大きいユーザが達するので(サーチエンジンは例えばキーワードを販売します)Netword。

   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。 無料の「いくつか付帯条件つき」の名前

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

名前空間は他の何かと引き換えに無料の名前をユーザに与えるかもしれません(ユーザのプロフィールがそれであるとキャプチャするのを商人に販売できます、メールなどを広告に送るためにユーザのEメールアドレスを得て)。

8. Security and Intellectual Property Rights Considerations

8. セキュリティと知的所有権問題

   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.

このドキュメントはマルチ評価されたインターネット識別子のシステムの目標について説明します。 このドキュメントは解決について議論しません。 したがって、範囲の外に安全であるか認証された解決メカニズムの質問があります。 それは保全を有効にするか、またはソースを認証する手段か俗称の起源を扱いません。 様々な俗称によって特定されるオブジェクトに関連している知的所有権に関する問題はこのドキュメントの範囲を超えてもいます、レゾルバを組み立てるのに使用されるかもしれないデータベースへの権利に関する質問のように。

Popp, et al.                 Informational                      [Page 9]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[9ページ]のRFC2972文脈と目標

9. Authors' Addresses

9. 作者のアドレス

   Larry Masinter
   AT&T Labs
   75 Willow Road
   Menlo Park, CA 94025

メンローパーク、ラリーMasinter AT&T研究室75柳のRoadカリフォルニア 94025

   Phone: +1 650 463 7059
   EMail: LMM@acm.org
   http://larry.masinter.net

以下に電話をしてください。 +1 7059年の650 463メール: LMM@acm.org http://larry.masinter.net

   Michael Mealling
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA 22070

ネットワークソリューション505Huntmar公園Driveハーンドン、ヴァージニア 22070を荒びきにするマイケル

   Phone: (770) 935-5492
   Fax: (703) 742-9552
   EMail: michaelm@netsol.com

以下に電話をしてください。 (770) 935-5492 Fax: (703) 742-9552 メールしてください: michaelm@netsol.com

   Nicolas Popp
   RealNames Corporation
   2 Circle Star Way
   San Carlos, CA  94070-1350

ニコラスポップRealNames社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

カレンSollins MIT Laboratory for Computer Science545技術平方です。 ケンブリッジ、MA 02139

   Phone: +1 617 253 6006
   EMail: sollins@lcs.mit.edu

以下に電話をしてください。 +1 6006年の617 253メール: sollins@lcs.mit.edu

Popp, et al.                 Informational                     [Page 10]

RFC 2972       Context & Goals for Common Name Resolution   October 2000

ポップ、他 俗称解決2000年10月の情報[10ページ]のRFC2972文脈と目標

10. Full Copyright Statement

10. 完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Popp, et al.                 Informational                     [Page 11]

ポップ、他 情報[11ページ]