RFC1737 日本語訳

Network Working Group                                         K. Sollins
Request for Comments: 1737                                       MIT/LCS
Category: Informational                                      L. Masinter
                                                       Xerox Corporation
                                                           December 1994

Sollinsがコメントのために要求するワーキンググループK.をネットワークでつないでください: 1737 MIT/LCSカテゴリ: 情報のL.Masinterゼロックス社の1994年12月

           Functional Requirements for Uniform Resource Names

一定のリソース名のための機能条件書

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

1.  Introduction

1. 序論

   This document specifies a minimum set of requirements for a kind of
   Internet resource identifier known as Uniform Resource Names (URNs).
   URNs fit within a larger Internet information architecture, which in
   turn is composed of, additionally, Uniform Resource Characteristics
   (URCs), and Uniform Resource Locators (URLs).  URNs are used for
   identification, URCs for including meta-information, and URLs for
   locating or finding resources.  It is provided as a basis for
   evaluating standards for URNs.  The discussions of this work have
   occurred on the mailing list uri@bunyip.com and at the URI Working
   Group sessions of the IETF.

このドキュメントはUniform Resource Names(URNs)として知られている一種のインターネット資料識別子のための最小のセットの要件を指定します。 URNsは、より大きいインターネットインフォメーション・アーキテクチャ、どれが順番にさらに、構成されるか、そして、Uniform Resource Characteristics(URCs)、およびUniform Resource Locator(URL)の中で合います。 URNsは識別、メタ情報、およびリソースを場所を見つけるか、または見つけるためのURLを含むためのURCsに使用されます。 URNsの規格を評価する基礎としてそれを提供します。 この仕事の議論はメーリングリスト uri@bunyip.com とIETFのURI作業部会のセッションのときに起こりました。

   The requirements described here are not necessarily exhaustive; for
   example, there are several issues dealing with support for
   replication of resources and with security that have been discussed;
   however, the problems are not well enough understood at this time to
   include specific requirements in those areas here.

ここで説明された要件は必ず徹底的であるというわけではありません。 例えば、リソースと議論したセキュリティで模写のサポートに対処するいくつかの問題があります。 しかしながら、このとき、問題がここにそれらの領域に決められた一定の要求を含んでいるのが十分よく理解されていません。

   Within the general area of distributed object systems design, there
   are many concepts and designs that are discussed under the general
   topic of "naming". The URN requirements here are for a facility that
   addresses a different (and, in general, more stringent) set of needs
   than are frequently the domain of general object naming.

分散オブジェクトシステム・デザインの一般的な領域の中に、「命名」の一般的な話題の下で議論する多くの概念とデザインがあります。 頻繁の一般的な物の命名のドメインであるより異なって(一般にさらに厳しい)のセットの必要性を記述する施設にはここのURN要件があります。

   The requirements for Uniform Resource Names fit within the overall
   architecture of Uniform Resource Identification.  In order to build
   applications in the most general case, the user must be able to
   discover and identify the information, objects, or what we will call
   in this architecture resources, on which the application is to
   operate.  Beyond this statement, the URI architecture does not define
   "resource."  As the network and interconnectivity grow, the ability
   to make use of remote, perhaps independently managed, resources will

Uniform Resource Namesのための要件はUniform Resource Identificationの総合的な構造の中で合います。 最も一般的な場合におけるアプリケーションを組立てるために、ユーザは、情報、物、または私たちがこの構造で作動するアプリケーションがことであるリソースと呼ぶつもりであるものを発見して、特定できなければなりません。 この声明を超えて、URI構造は「リソース」を定義しません。 ネットワークと相互接続性が成長するので、リモートで、恐らく独自に管理されたリソースを利用する能力は成長するでしょう。

Sollins & Masinter                                              [Page 1]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[1ページ]RFC1737要件

   become more and more important.  This activity of discovering and
   utilizing resources can be broken down into those activities where
   one of the primary constraints is human utility and facility and
   those in which human involvement is small or nonexistent.  Human
   naming must have such characteristics as being both mnemonic and
   short.  Humans, in contrast with computers, are good at heuristic
   disambiguation and wide variability in structure.  In order for
   computer and network based systems to support global naming and
   access to resources that have perhaps an indeterminate lifetime, the
   flexibility and attendant unreliability of human-friendly names
   should be translated into a naming infrastructure more appropriate
   for the underlying support system.  It is this underlying support
   system that the Internet Information Infrastructure Architecture
   (IIIA) is addressing.

ますます重要になってください。 リソースを発見して、利用するこの活動は人間のかかわり合いが小さいか、または実在しない第一の規制の1つが人間のユーティリティであるそれらの活動、施設、およびそれらへ砕けている場合があります。 人間の命名で、両方であることのような特性は簡略記憶で短くならなければなりません。 コンピュータと比べて、人間は構造の発見的な曖昧さの解消と広い可変性が上手です。 コンピュータとネットワークの注文では、恐らく人間に優しい名前の不確定の生涯、柔軟性、および付き添いの非信頼性を持っているグローバルな命名とリソースへのアクセスを支持するベースのシステムは基本的なサポート・システムには、より適切な命名インフラストラクチャに翻訳されるべきです。 それはインターネット情報Infrastructure Architecture(IIIA)が記述しているこの基本的なサポート・システムです。

   Within the IIIA, several sorts of information about resources are
   specified and divided among different sorts of structures, along
   functional lines.  In order to access information, one must be able
   to discover or identify the particular information desired,
   determined both how and where it might be used or accessed.  The
   partitioning of the functionality in this architecture is into
   uniform resource names (URN), uniform resource characteristics (URC),
   and uniform resource locators (URL).  A URN identifies a resource or
   unit of information.  It may identify, for example, intellectual
   content, a particular presentation of intellectual content, or
   whatever a name assignment authority determines is a distinctly
   namable entity.  A URL identifies the location or a container for an
   instance of a resource identified by a URN.  The resource identified
   by a URN may reside in one or more locations at any given time, may
   move, or may not be available at all.  Of course, not all resources
   will move during their lifetimes, and not all resources, although
   identifiable and identified by a URN will be instantiated at any
   given time.  As such a URL is identifying a place where a resource
   may reside, or a container, as distinct from the resource itself
   identified by the URN.  A URC is a set of meta-level information
   about a resource.  Some examples of such meta-information are: owner,
   encoding, access restrictions (perhaps for particular instances),
   cost.

IIIAの中では、リソースの情報の数種類は、異なった種類の構造の中で指定されて、分割されます、機能的な線に沿って。 情報にアクセスするために、それが使用されるか、またはアクセスされるかもしれないどのように、ところで必要であって、断固としていた状態で特定の情報を発見しなければならないか、または特定できなければならないか。 ユニフォームリソース名(URN)、一定のリソースの特性(URC)、および一定のリソースロケータ(URL)にはこの構造における、機能性の仕切りがあります。 URNは情報のリソースかユニットを特定します。 それは例えば、知的な内容を特定するかもしれません、知的な内容の特定のプレゼンテーション、または、名前課題権威が決定することなら何でも明瞭に名づけられる実体です。 URLはURNによって特定されたリソースの例のために位置か容器を特定します。 URNによって特定されたリソースは、その時々で複数の位置に住むかもしれないか、動くかもしれないか、または全く利用可能でないかもしれません。 もちろん、身元保証可能ですが、すべてのリソースがすべてのリソースではなく、彼らの生涯動くというわけではないでしょう、そして、URNによって特定されて、その時々で例示されるでしょう。 そういうものとして、URLはリソースと異なるとしてのリソースがあるかもしれない場所、または容器自体がURNで特定した特定です。 URCは1セットのリソースのメタレベル情報です。 そのようなメタ情報に関するいくつかの例は以下の通りです。 所有者、コード化は制限(恐らく特定の例のための)、費用にアクセスします。

   With this in mind, we can make the following statement:

これが念頭にある場合、私たちは以下の声明を出すことができます:

   o  The purpose or function of a URN is to provide a globally unique,
      persistent identifier used for recognition, for access to
      characteristics of the resource or for access to the resource
      itself.

o URNの目的か機能が認識に使用されるグローバルにユニークで、しつこい識別子を提供することです、リソースの特性かリソース自体へのアクセスのためのアクセスのために。

Sollins & Masinter                                              [Page 2]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[2ページ]RFC1737要件

   More specifically, there are two kinds of requirements on URNs:
   requirements on the functional capabilities of URNs, and requirements
   on the way URNs are encoded in data streams and written
   communications.

より明確に、URNsに関する2種類の要件があります: URNsの機能的な能力に関する要件、およびURNsがデータ・ストリームでコード化されて、コミュニケーションに書かれている方法に関する要件。

2. Requirements for functional capabilities

2. 機能的な能力のための要件

   These are the requirements for URNs' functional capabilities:

これらはURNsの機能的な能力のための要件です:

   o Global scope: A URN is a name with global scope which does not
     imply a location.  It has the same meaning everywhere.

o グローバルな範囲: URNは位置を含意しないグローバルな範囲の名前です。 それはいたる所に同じ意味を持っています。

   o Global uniqueness: The same URN will never be assigned to two
     different resources.

o グローバルなユニークさ: 同じURNは2つの異なったリソースに決して割り当てられないでしょう。

   o Persistence: It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

o 固執: URNの寿命が永久的であることを意図します。 すなわち、URNはいつまでも、グローバルにユニークであり、名前の課題にかかわるそれが特定するリソースかどんな命名権威の生涯も、たぶんリソースの参照としてよく使用されるでしょう。

   o Scalability: URNs can be assigned to any resource that might
     conceivably be available on the network, for hundreds of years.

o スケーラビリティ: 多分ネットワークで何百年にも利用可能であるかもしれないどんなリソースにもURNsを割り当てることができます。

   o Legacy support: The scheme must permit the support of existing
     legacy naming systems, insofar as they satisfy the other
     requirements described here. For example, ISBN numbers, ISO
     public identifiers, and UPC product codes seem to satisfy the
     functional requirements, and allow an embedding that satisfies
     the syntactic requirements described here.

o 遺産サポート: 彼らがここで説明された他の要件を満たす限り、計画は既存の遺産命名システムのサポートを可能にしなければなりません。 例えば、ISBN番号、ISOの公共の識別子、およびUPC製品コードは、機能条件書を満たすように思えて、ここで説明された構文の要件を満たす埋め込みを許します。

   o Extensibility: Any scheme for URNs must permit future extensions to
     the scheme.

o 伸展性: URNsのどんな計画も今後の拡大を計画に可能にしなければなりません。

   o Independence: It is solely the responsibility of a name issuing
     authority to determine the conditions under which it will issue a
     name.

o 独立: それが名前を発行する状態を決定するのは、唯一名前発行機関の責任です。

   o Resolution: A URN will not impede resolution (translation into a
     URL, q.v.). To be more specific, for URNs that have corresponding
     URLs, there must be some feasible mechanism to translate a URN to a
     URL.

o 解決: URNは解決(URL、q.v.への翻訳)を妨害しないでしょう。 対応するURLを持っているURNsには、より特有に、なるように、URNをURLに翻訳する何らかの可能なメカニズムがあるに違いありません。

3. Requirements for URN encoding

3. URNコード化のための要件

   In addition to requirements on the functional elements of the URNs,
   there are requirements for how they are encoded in a string:

URNsの機能要素に関する要件に加えて、それらがストリングでどうコード化されるか要件があります:

Sollins & Masinter                                              [Page 3]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[3ページ]RFC1737要件

   o Single encoding: The encoding for presentation for people in clear
     text, electronic mail and the like is the same as the encoding in
     other transmissions.

o 以下をコード化するシングル クリアテキスト、電子メール、および同様のものにおける人々のためのプレゼンテーションのためのコード化は他のトランスミッションにおけるコード化と同じです。

   o Simple comparison: A comparison algorithm for URNs is simple,
     local, and deterministic. That is, there is a single algorithm for
     comparing two URNs that does not require contacting any external
     server, is well specified and simple.

o 簡単な比較: URNsのための比較アルゴリズムは、簡単で、地方的で、決定論的です。 すなわち、何か外部のサーバに連絡するのを必要としない2URNsを比較するためのただ一つのアルゴリズムがあって、井戸は、指定されていて簡単ですか?

   o Human transcribability: For URNs to be easily transcribable by
     humans without error, they should be short, use a minimum of
     special characters, and be case insensitive. (There is no strong
     requirement that it be easy for a human to generate or interpret a
     URN; explicit human-accessible semantics of the names is not a
     requirement.)  For this reason, URN comparison is insensitive to
     case, and probably white space and some punctuation marks.

o 人間のtranscribability: 彼らは、URNsが人間で誤りなしで容易に転写可能なように、短く、最小特殊文字を使用して、大文字と小文字を区別しないはずです。 (人間がURNを発生するか、または解釈するのが、簡単であるというどんな強い要件もありません; 名前の明白な人間アクセスしやすい意味論は要件ではありません。) この理由で、URN比較は、スペースといくつかの句読点をケースに入れて、たぶん空白にするために神経が鈍いです。

   o Transport friendliness: A URN can be transported unmodified in the
     common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as
     well as printed paper.

o 友情を輸送してください: 一般的なインターネットプロトコルで変更されていなくURNを輸送できます、TCP、SMTP、FTP、Telnetなどのように、印刷用紙と同様に。

   o Machine consumption: A URN can be parsed by a computer.

o 消費を機械加工してください: コンピュータはURNを分析できます。

   o Text recognition: The encoding of a URN should enhance the
     ability to find and parse URNs in free text.

o テキスト認識: URNのコード化は無料のテキストでURNsを見つけて、分析する能力を高めるべきです。

4. Implications

4. 含意

   For a URN specification to be acceptible, it must meet the previous
   requirements.  We draw a set of conclusions, listed below, from those
   requirements; a specification that satisfies the requirments without
   meetings these conclusions is deemed acceptable, although unlikely to
   occur.

URN仕様がacceptibleであるために、それは前の必要条件を満たさなければなりません。 私たちはそれらの要件から以下に記載された1セットの結論に達します。 それはミーティングなしでrequirmentsを満たします。仕様、起こりそうではありませんが、これらの結論は許容できると考えられます。

   o To satisfy the requirements of uniqueness and scalability, name
     assignment is delegated to naming authorities, who may then assign
     names directly or delegate that authority to sub-authorities.
     Uniqueness is guaranteed by requiring each naming authority to
     guarantee uniqueness.  The names of the naming authorities
     themselves are persistent and globally unique and top level
     authorities will be centrally registered.

o ユニークさとスケーラビリティの要件を満たすために、名前課題を当局を任命することへ代表として派遣します。(その当局は、次に、直接名前を割り当てるか、またはその権威をサブ当局へ代表として派遣するかもしれません)。 ユニークさは、ユニークさを保証するそれぞれの命名権威を必要とすることによって、保証されます。 命名当局の名前自体はしつこいです、そして、グローバルにユニークで最高な平らな当局は中心に登録されるでしょう。

   o Naming authorities that support scalable naming are encouraged, but
     not required.  Scalability implies that a scheme for devising names
     may be scalable both at its terminators as well as within the
     structure; e.g., in a hierarchical naming scheme, a naming
     authority might have an extensible mechanism for adding new
     sub-registries.

o スケーラブルな命名を支持する命名当局が、奨励されますが、必要ではありません。 スケーラビリティは、名前について工夫することの計画がターミネータにおいて構造の中でスケーラブルであるかもしれないことを含意します。 例えば、階層的な命名計画では、命名権威は新しい状態で加えるための広げることができるメカニズムをサブ登録するのに持っているかもしれません。

Sollins & Masinter                                              [Page 4]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[4ページ]RFC1737要件

   o It is strongly recommended that there be a mapping between the
     names generated by each naming authority and URLs.  At any specific
     time there will be zero or more URLs into which a particular URN
     can be mapped.  The naming authority itself need not provide the
     mapping from URN to URL.

o それはそこでそれぞれの命名権威とURLで発生する名前の間のマッピングがそうであることが強く推薦されます。 そこの特定の何時でも、ゼロか以上が特定のURNがそうすることができるURLであるつもりであったなら写像されてください。 命名権威自体はURNからURLまでマッピングを提供する必要はありません。

   o For URNs to be transcribable and transported in mail, it is
     necessary to limit the character set usable in URNs, although there
     is not yet consensus on what the limit might be.

o URNsが転写可能でメールで輸送されているのに、URNsで使用可能な文字の組を制限するのが必要です、限界がどのくらいであるかもしれないかに関するコンセンサスがまだありませんが。

   In assigning names, a name assignment authority must abide by the
   preceding constraints, as well as defining its own criteria for
   determining the necessity or indication of a new name assignment.

名前を割り当てる際に、名前課題権威は前の規制を守らなければなりません、新しい名前課題のそれ自身の必要性を決定する評価基準を定義するか、しるしと同様に。

5. Other considerations

5. 他の問題

   There are three issues about which this document has intentionally
   not taken a position, because it is believed that these are issues to
   be decided by local determination or other services within an
   information infrastructure.  These issues are equality of resources,
   reflection of visible semantics in a URN, and name resolution.

このドキュメントが故意にポジションを持っていない3冊があります、これらが情報インフラストラクチャの中で地方の決断か他のサービスで決められるべき問題であると信じられているので。 これらの問題はリソースの平等、URN、および名前解決で、目に見える意味論の反映です。

   One of the ways in which naming authorities, the assigners of names,
   may choose to make themselves distinctive is by the algorithms by
   which they distinguish or do not distinguish resources from each
   other.  For example, a publisher may choose to distinguish among
   multiple printings of a book, in which minor spelling and
   typographical mistakes have been made, but a library may prefer not
   to make that distinction.  Furthermore, no one algorithm for testing
   for equality is likely to applicable to all sorts of information.
   For example, an algorithm based on testing the equality of two books
   is unlikely to be useful when testing the equality of two
   spreadsheets.  Thus, although this document requires that any
   particular naming authority use one algorithm for determining whether
   two resources it is comparing are the same or different, each naming
   authority can use a different such algorithm and a naming authority
   may restrict the set of resources it chooses to identify in any way
   at all.

命名当局(名前の指定人)が自分たちを特有にするのを選ぶかもしれない方法の1つが彼らが区別するか、または互いとリソースを区別しないアルゴリズムであります。 例えば、出版社は、小さい方のスペルと印刷の誤り本の重ね焼の中で区別するのを選ぶかもしれませんが、ライブラリは、それを区別にしないのを好むかもしれません。 その上、平等がないかどうかテストするためのいいえ1、アルゴリズムはいろいろな情報に適切にありそうです。 2つのスプレッドシートの平等をテストするとき、例えば、2冊の本の平等をテストすることに基づいたアルゴリズムは役に立ちそうにはありません。 したがって、このドキュメントは、どんな特定の命名権威も1つのアルゴリズムを使用するのを必要としますが、それが比較している2つのリソースが同じであるか、または異なっていることにかかわらずそれぞれの命名権威が異なったそのようなものを使用できることを決定するために、アルゴリズムと命名権威はそれが何らかの方法で全く特定するのを選ぶリソースのセットを制限するかもしれません。

   A naming authority will also have some algorithm for actually
   choosing a name within its namespace.  It may have an algorithm that
   actually embeds in some way some knowledge about the resource.  In
   turn, that embedding may or may not be made public, and may or may
   not be visible to potential clients.  For example, an unreflective
   URN, simply provides monotonically increasing serial numbers for
   resources.  This conveys nothing other than the identity determined
   by the equality testing algorithm and an ordering of name assignment
   by this server.  It carries no information about the resource itself.

また、命名権威には、実際に名前空間の中で名前を選ぶための何らかのアルゴリズムがあるでしょう。 それには、実際に何らかの方法でリソースに関する何らかの知識を埋め込むアルゴリズムがあるかもしれません。 順番に、その埋め込みは、公表されるかもしれなくて、可能なクライアントにとって、目に見えるかもしれません。 例えば、無分別なURN、単に、リソースのための通し番号を単調に増加させながら、提供します。 これはこのサーバで平等テストアルゴリズムと名前課題の注文で決定しているアイデンティティ以外の何も運びません。それはリソース自体の情報を全く運びません。

Sollins & Masinter                                              [Page 5]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[5ページ]RFC1737要件

   An MD5 of the resource at some point, in and of itself may be
   reflective of its contents, and, in fact, the naming authority may be
   perfectly willing to publish the fact that it is using MD5, but if
   the resource is mutable, it still will be the case that any potential
   client cannot do much with the URN other than check for equality.
   If, in contrast, a URN scheme has much in common with the assignment
   ISBN numbers, the algorithm for assigning them is public and by
   knowing it, given a particular ISBN number, one can learn something
   more about the resource in question.  This full range of
   possibilities is allowed according to this requirements document,
   although it is intended that naming authorities be discouraged from
   making accessible to clients semantic information about the resource,
   on the assumption that that may change with time and therefore it is
   unwise to encourage people in any way to depend on that semantics
   being valid.

何らかのポイントのリソースのMD5、コンテンツでそういうものとして反射的であるかもしれなく、事実上、命名権威は、MD5を使用しているという事実を発表しても構わないと完全に思っているかもしれませんが、リソースが無常であるなら、どんな可能なクライアントも平等のためのチェック以外のURNをあまり処理できないのは、まだ事実でしょう。 課題ISBN番号と共用してURN計画に多くが対照的に、あるなら、それらを割り当てるためのアルゴリズムは公共です、そして、特定のISBN番号を考えて、それを知っていることによって、人は問題のリソースに関する何かより多いものを学ぶことができます。 この要件ドキュメントによると、この完全な可能性として考えられる範囲は許容されています、当局を任命するのがその意味論によるどんな有効な方法もリソースに関するクライアント意味情報にそれが時間を交換するかもしれなくて、したがって、人々を奨励するのが賢明でないという前提でアクセスしやすくするのでお勧めできないことを意図しますが。

   Last, this document intentionally does not address the problem of
   name resolution, other than to recommend that for each naming
   authority a name translation mechanism exist.  Naming authorities
   assign names, while resolvers or location services of some sort
   assist or provide URN to URL mapping.  There may be one or many such
   services for the resources named by a particular naming authority.
   It may also be the case that there are generic ones providing service
   for many resources of differing naming authorities.  Some may be
   authoritative and others not.  Some may be highly reliable or highly
   available or highly responsive to updates or highly focussed by other
   criteria such as subject matter.  Of course, it is also possible that
   some naming authorities will also act as resolvers for the resources
   they have named.  This document supports and encourages third party
   and distributed services in this area, and therefore intentionally
   makes no statements about requirements of URNs or naming authorities
   on resolvers.

最後に、このドキュメントは故意に名前解決のその問題を訴えません、それぞれ名前変換メカニズムと権威を命名するためのそれが存在することを勧めるのを除いて。 命名当局は名前を割り当てますが、ある種のレゾルバか位置のサービスが、URLマッピングにURNを補助するか、または提供します。 ものか特定の命名権威によって指定されたリソースのためのそのような多くのサービスがあるかもしれません。 また、当局を任命しながら異なる多くのリソースのためのサービスを提供する一般的なものがあるのは、事実であるかもしれません。 或るものが正式であるかもしれない、他のもの 或るものは、高信頼性か非常に利用可能であるかアップデートに非常に敏感であるか内容などの他の評価基準によって非常に焦点を合わせられるかもしれません。 もちろん、また、また、いくつかの命名当局が彼らが命名したリソースのためのレゾルバとして務めるのも、可能です。 このドキュメントは、この領域で第三者と分配されたサービスを支持して、奨励して、したがって、故意にレゾルバの上でURNsか命名当局の要件に関する声明を全く出しません。

Security Considerations

セキュリティ問題

   Applications that require translation from names to locations, and
   the resources themselves may require the resources to be
   authenticated. It seems generally that the information about the
   authentication of either the name or the resource to which it refers
   should be carried by separate information passed along with the URN
   rather than in the URN itself.

名前から位置までの翻訳、およびリソース自体を必要とするアプリケーションは必要であるかもしれません。認証されて、リソースは必要です。 一般に、それが参照される名前かリソースのどちらかの認証の情報がURN自身でというよりむしろURNと共に通過された別々の情報によって運ばれるべきであるように思えます。

Sollins & Masinter                                              [Page 6]

RFC 1737        Requirements for Uniform Resource Names    December 1994

一定のリソース名1994年12月のためのSollins&Masinter[6ページ]RFC1737要件

Authors' Addresses

作者のアドレス

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

ラリーMasinterゼロックスパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304

   Phone: (415) 812-4365
   Fax:   (415) 812-4333
   EMail: masinter@parc.xerox.com

以下に電話をしてください。 (415) 812-4365 Fax: (415) 812-4333 メールしてください: masinter@parc.xerox.com

   Karen Sollins
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139

正方形のケンブリッジ、カレンSollins MIT Laboratory for Computer Science545Technology MA 02139

   Voice: (617) 253-6006
   Phone: (617) 253-2673
   EMail: sollins@lcs.mit.edu

声: (617) 253-6006 以下に電話をしてください。 (617) 253-2673 メールしてください: sollins@lcs.mit.edu

Sollins & Masinter                                              [Page 7]

Sollins&Masinter[7ページ]