RFC3305 日本語訳

Network Working Group                                   M. Mealling, Ed.
Request for Comments: 3305                             R. Denenberg, Ed.
Category: Informational                           W3C URI Interest Group
                                                             August 2002

エド、ワーキンググループM.食事をネットワークでつないでください。コメントのために以下を要求してください。 エド3305R.Denenberg、カテゴリ: 情報のW3C URI営利団体2002年8月

      Report from the Joint W3C/IETF URI Planning Interest Group:
 Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names
              (URNs): Clarifications and Recommendations

共同W3C/IETF URI計画営利団体から、報告してください: Uniform Resource Identifier(URI)、URL、および一定のリソース名(つぼ): 明確化と推薦

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 (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document, a product of the W3C Uniform Resource Identifier (URI)
   Interest Group, addresses and attempts to clarify issues pertaining
   to URIs.  This document addresses how URI space is partitioned and
   the relationship between URIs, URLs, and URNs, describes how URI
   schemes and URN namespaces ids are registered, and presents
   recommendations for continued work on this subject.

このドキュメント、W3C Uniform Resource Identifier(URI)関心Group、アドレス、およびはっきりさせる試みの成果はURIとの関係を発行します。 このドキュメントがURIスペースがどう仕切られるかを記述して、URIの間の関係(URL、およびURNs)は、URI計画とURN名前空間イドがどう登録されているかを説明して、この話題への継続的な作業のための推薦を提示します。

Mealling & Denenberg         Informational                      [Page 1]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[1ページ]のRFC3305URI、URL、およびつぼの2002年8月

Table of Contents

目次

   1.      The W3C URI Interest Group . . . . . . . . . . . . . . . .  2
   2.      URI Partitioning . . . . . . . . . . . . . . . . . . . . .  2
   2.1     Classical View . . . . . . . . . . . . . . . . . . . . . .  3
   2.2     Contemporary View  . . . . . . . . . . . . . . . . . . . .  3
   2.3     Confusion  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Registration . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1     URI Schemes  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1.1   Registered URI schemes . . . . . . . . . . . . . . . . . .  4
   3.1.2   Unregistered URI Schemes . . . . . . . . . . . . . . . . .  4
   3.1.2.1 Public Unregistered Schemes  . . . . . . . . . . . . . . .  4
   3.1.2.2 Private Schemes  . . . . . . . . . . . . . . . . . . . . .  5
   3.1.3   Registration of URI Schemes  . . . . . . . . . . . . . . .  5
   3.1.3.1 IETF Tree  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.3.2 Other Trees  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2     URN Namespaces . . . . . . . . . . . . . . . . . . . . . .  5
   3.2.1   Registered URN NIDs  . . . . . . . . . . . . . . . . . . .  5
   3.2.2   Pending URN NIDs . . . . . . . . . . . . . . . . . . . . .  6
   3.2.3   Unregistered NIDs  . . . . . . . . . . . . . . . . . . . .  7
   3.2.4   Registration Procedures for URN NIDs . . . . . . . . . . .  7
   4.      Additional URI Issues  . . . . . . . . . . . . . . . . . .  7
   5.      Recommendations  . . . . . . . . . . . . . . . . . . . . .  8
   6.      Security Considerations  . . . . . . . . . . . . . . . . .  8
   7.      Acknowledgements . . . . . . . . . . . . . . . . . . . . .  8
           References . . . . . . . . . . . . . . . . . . . . . . . .  9
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10
           Full Copyright Statement . . . . . . . . . . . . . . . . . 11

1. W3C URI営利団体. . . . . . . . . . . . . . . . 2 2。 URI仕切り. . . . . . . . . . . . . . . . . . . . . 2 2.1の古典的な視点. . . . . . . . . . . . . . . . . . . . . . 3 2.2の現代の視点. . . . . . . . . . . . . . . . . . . . 3 2.3混乱. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 登録. . . . . . . . . . . . . . . . . . . . . . . 4 3.1URI Schemes. . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1回のRegistered URI計画.43.1.2Unregistered URI Schemes. . . . . . . . . . . . . . . . . 4 3.1.2.1Public Unregistered Schemes. . . . . . . . . . . . . . . 4 3.1.2.2兵士のSchemes、.53.1、.3Registration、URI Schemes. . . . . . . . . . . . . . . 5 3.1; 他の.2本の木. . . . . . . . . . . . . . . . . . . . . . . 5 3.2の3.1IETF木. . . . . . . . . . . . . . . . . . . . . . . . 5 3.1の.3のつぼの名前空間. . . . . . . . . . . . . . . . . . . . . . 5 3.2.1登録されたつぼのNIDs、.53.2、.2、未定のつぼのNIDs. . . . . . . . . . . . . . . . . . . . . 6 3.2.3登録されていないNIDs、つぼのNIDs. . . . . . . . . . . 7 4のための.73.2の.4登録手順 追加URI問題. . . . . . . . . . . . . . . . . . 7 5。 推薦. . . . . . . . . . . . . . . . . . . . . 8 6。 セキュリティ問題. . . . . . . . . . . . . . . . . 8 7。 作者の.8の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . 9のものが.10の完全な著作権宣言文. . . . . . . . . . . . . . . . . 11を記述するという承認

1. The W3C URI Interest Group

1. W3C URI営利団体

   In October, 2000 the W3C formed a planning group whose mission was to
   evaluate the opportunities for W3C work in the area of Uniform
   Resource Identifiers (URIs) and to develop a proposal for continued
   work in this area.  The Interest Group was composed of W3C members
   and invited experts from the IETF to participate as well.  This
   document is a set of recommendations from this group, to the W3C and
   the IETF for work that can and should continue in this area.

2000年10月に、W3Cはこの領域で任務がUniform Resource Identifier(URI)の領域でのW3C仕事の機会を評価して、継続的な仕事のための提案を開発することになっていた計画グループを結成しました。 Interest Groupは、W3Cメンバーで構成されて、また、IETFからの専門家が参加するよう誘いました。 このドキュメントはこのグループからの1セットの推薦です、続くことができて、この領域で続くべきである仕事のためのW3CとIETFに。

2. URI Partitioning

2. URI仕切り

   There is some confusion in the web community over the partitioning of
   URI space, specifically, the relationship among the concepts of URL,
   URN, and URI.  The confusion owes to the incompatibility between two
   different views of URI partitioning, which we call the "classical"
   and "contemporary" views.

URIスペースの仕切りの上のウェブ共同体、明確にURL、URN、およびURIの概念の中の関係には何らかの混乱があります。 混乱は2の間でURI仕切りの異なった視点を不一致に負っています。(私たちは「古典的で」「現代」の視点を仕切りと呼びます)。

Mealling & Denenberg         Informational                      [Page 2]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[2ページ]のRFC3305URI、URL、およびつぼの2002年8月

2.1 Classical View

2.1 古典的な視点

   During the early years of discussion of web identifiers (early to mid
   90s), people assumed that an identifier type would be cast into one
   of two (or possibly more) classes.  An identifier might specify the
   location of a resource (a URL) or its name (a URN), independent of
   location.  Thus a URI was either a URL or a URN.  There was
   discussion about generalizing this by the addition of a discrete
   number of additional classes; for example, a URI might point to
   metadata rather than the resource itself, in which case the URI would
   be a URC (citation).  URI space was thus viewed as partitioned into
   subspaces:  URL, URN, and additional subspaces to be defined.  The
   only such additional space ever proposed was Uniform Resource
   Characteristics (URC) and there never was any buy-in; so without loss
   of generality, it's reasonable to say that URI space was thought to
   be partitioned into two classes: URL and URN.  Thus, for example,
   "http:" was a URL scheme, and "isbn:" would (someday) be a URN
   scheme.  Any new scheme would be cast into one of these two classes.

ウェブ識別子(前半から半ばの90年代)の議論の下積み時代の間、人々は、識別子タイプが2つ(ことによるとさらに)のクラスの1つに割り当てられると仮定しました。 識別子は位置の如何にかかわらずリソース(URL)かその名前(URN)の位置を指定するかもしれません。 したがって、URIは、URLかURNのどちらかでした。 離散的な数の追加クラスの参加でこれを一般化するのと議論がありました。 例えば、URIはリソース自体よりむしろメタデータを示すかもしれません、その場合、URIがURC(引用)でしょう。 URIスペースは部分空間に仕切られるようにこのようにして見られました: 定義されるべきURL、URN、および追加部分空間。 追加スペースが今までに提案した唯一のそのようなものはUniform Resource Characteristics(URC)でした、そして、中で少しも買うのが決してありませんでした。 それで、一般性の喪失がなければ、URIスペースによって2つのクラスに仕切られると考えられたと言うのは妥当です: URLとつぼ。 その結果、例えば、「以下をhttpします」。 URL計画であり、「以下をisbnします」。 (いつか)URN計画でしょう。 どんな新しい計画もこれらの2つのクラスの1つに投げかけられるでしょう。

2.2 Contemporary View

2.2 現代の視点

   Over time, the importance of this additional level of hierarchy
   seemed to lessen; the view became that an individual scheme did not
   need to be cast into one of a discrete set of URI types, such as
   "URL", "URN", "URC", etc.  Web-identifier schemes are, in general,
   URI schemes, as a given URI scheme may define subspaces.  Thus
   "http:" is a URI scheme.  "urn:" is also a URI scheme; it defines
   subspaces, called "namespaces".  For example, the set of URNs, of the
   form "urn:isbn:n-nn-nnnnnn-n", is a URN namespace.  ("isbn" is an URN
   namespace identifier.  It is not a "URN scheme", nor is it a "URI
   scheme.")

時間がたつにつれて、この追加レベルの階層構造の重要性は少なくなるように思えました。 個々の計画によって離散的なURIタイプのひとりに投げかけられる必要はなかったという意見はなりました、「URL」、「つぼ」、"URC"などのように 与えられたURI計画が部分空間を定義するかもしれないので、一般に、ウェブ識別子計画はURI計画です。 その結果、「以下をhttpします」。 URIは計画ですか? 「つぼ:」 また、URI計画です。 それは「名前空間」と呼ばれる部分空間を定義します。 例えば、URNs、フォーム「つぼ:isbn:n-nn-nnnnnn-n」のセットはURN名前空間です。 ("isbn"はURN名前空間識別子です。 それは「URN計画」ではありません、そして、「URI計画」ではありません。)

   Further, according to the contemporary view, the term "URL" does not
   refer to a formal partition of URI space; rather, URL is a useful but
   informal concept.  A URL is a type of URI that identifies a resource
   via a representation of its primary access mechanism (e.g., its
   network "location"), rather than by some other attributes it may
   have.  Thus, as we noted, "http:" is a URI scheme.  An http URI is a
   URL.  The phrase "URL scheme" is now used infrequently, usually to
   refer to some subclass of URI schemes which exclude URNs.

さらに、現代の視点によると、「URL」という用語はURIスペースの正式なパーティションについて言及しません。 むしろ、URLは役に立ちますが、非公式の概念です。 URLはそれが持っているかもしれないある他の属性でというよりむしろ第一のアクセス機構(例えば、ネットワーク「位置」)の表現でリソースを特定する一種のURIです。 その結果、私たちが注意したように、「以下をhttpします」。 URIは計画ですか? http URIはURLです。 「URL計画」という句は、現在、通常、URNsを除くURI計画の何らかのサブクラスについて言及するのにまれに使用されます。

2.3 Confusion

2.3 混乱

   The body of documents (RFCs, etc) covering URI architecture, syntax,
   registration, etc., spans both the classical and contemporary
   periods.  People who are well-versed in URI matters tend to use "URL"
   and "URI" in ways that seem to be interchangeable.  Among these
   experts, this isn't a problem, but among the Internet community at

URI構造、構文、登録などに関するドキュメント(RFCsなど)のボディーは両方の古典的で現代の期間にわたります。 URIの件に精通している人々は、交換可能であるように思える方法で「URL」と「ユリ」を使用する傾向があります。 これらの専門家の中では、問題ではありませんが、インターネットコミュニティの中でこれはそうです。

Mealling & Denenberg         Informational                      [Page 3]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[3ページ]のRFC3305URI、URL、およびつぼの2002年8月

   large, it is a problem.  People are not convinced that URI and URL
   mean the same thing, in documents where they (apparently) do.  When
   one RFC talks about URI schemes (e.g. "URI Syntax" (RFC 2396) [12]),
   another talks about URL schemes (e.g. "Registration Procedures for
   URL Schemes" (RFC 2717) [1]), and yet another talks of URN schemes
   ("Architectural Principles of URN Resolution" (RFC 2276) [13]), it is
   natural to wonder how they difference, and how they relate to one
   another.  While RFC 2396, section 1.2, attempts to address the
   distinction between URIs, URLs and URNs, it has not been successful
   in clearing up the confusion.

大きくて、それは問題です。 人々はそのURIとURLがそれらが(明らかに)するドキュメントで同じものを意味すると確信していません。 1RFCがURI計画に関して話す、(例えば、「URI構文」(RFC2396)[12])、別のものがURL計画に関して話す、(例えば、「URL計画のための登録手順」(RFC2717)[1])にもかかわらず、URN計画の別の会談、(「つぼの解決の建築プリンシプルズ」(RFC2276)[13])、その方法を不思議に思うのが当然である、それら、違いと、それらはどうお互いに関連するか。 RFC2396(セクション1.2)は、URIと、URLとURNsの区別を記述するのを試みますが、それは混乱を解決するのに成功していません。

3. Registration

3. 登録

   This section examines the state of registration of URI schemes and
   URN namespaces and the mechanisms by which registration currently
   occurs.

このセクションはURI計画とURN名前空間の登録の状態と登録が現在起こるメカニズムを調べます。

3.1 URI Schemes

3.1 URI計画

3.1.1 Registered URI schemes

3.1.1 登録されたURI計画

   The official register of URI scheme names is maintained by IANA, at
   http://www.iana.org/assignments/uri-schemes.  For each scheme, the
   RFC that defines the scheme is listed; for example "http:" is defined
   by RFC2616 [14].  The table lists  34 schemes (at time of publication
   of this RFC).  In addition, there are a few "reserved" scheme names;
   at one point in time, these were intended to become registered
   schemes but have since been dropped.

URI計画名の公式のレジスタは http://www.iana.org/assignments/uri-schemes でIANAによって維持されます。 各計画において、計画を定義するRFCは記載されています。 例えば、「以下をhttpします」。 RFC2616[14]によって定義されます。 テーブルは34回の計画(このRFCの公表の時間の)を記載します。 さらに、いくつかの「予約された」計画名があります。 時間内にの1ポイントでは、これらは、登録された計画になることを意図しましたが、以来、落とされています。

3.1.2 Unregistered URI Schemes

3.1.2 登録されていないURI計画

   We distinguish between public (unregistered) and private schemes.  A
   public scheme (registered or not) is one for which there is some
   public document describing it.

私たちは公共(登録されていない)の、そして、個人的な計画を見分けます。 公共の計画(登録された)はそれについて説明する何らかの官庁出版物があるものです。

3.1.2.1 Public Unregistered Schemes

3.1.2.1 公共の登録されていない計画

   Dan Conolly's paper, at http://www.w3.org/Addressing/schemes,
   provides a list of known public URI schemes, both registered and un-
   registered, a total of 85 schemes at time of publication of this RFC.
   50 or so of these are unregistered (not listed in the IANA register).
   Some of these URI schemes are obsolete (for example, "phone" is
   obsolete, superceded by "tel"), while some have an RFC, but are not
   included in the IANA list.

http://www.w3.org/Addressing/schemes では、ダン・コノリーの論文は知られている公共のURI計画のリストを提供します、登録されて、不-登録された両方、このRFCの公表の時間の合計85回の計画。 これらのおよそ50は登録されていないです(IANAレジスタでは、記載されていません)。 これらのURI計画のいくつかが時代遅れです(例えば、「電話」は時代遅れです、"tel"によってスーパー割譲されて)、或るものは、RFCを持っていますが、IANAリストに含まれていませんが。

Mealling & Denenberg         Informational                      [Page 4]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[4ページ]のRFC3305URI、URL、およびつぼの2002年8月

3.1.2.2 Private Schemes

3.1.2.2 個人的な計画

   It is probably impossible to determine all of these, and it's not
   clear that it's worthwhile to try, except perhaps to get some idea of
   their number.  In the minutes of the August 1997 IETF meeting is the
   observation that there may be 20-40 in use at Microsoft, with 2-3
   being added a day, and that WebTV has 24, with 6 added per year.

これらをすべて、決定するのがたぶん不可能であり、試みる価値があるのは、明確ではありません、恐らくそれらの番号の何らかの考えを得るのを除いて。 8月の議事録の間、1997年のIETFミーティングはマイクロソフトで使用中の2-3が加えられている状態で20-40が1日間あるかもしれないという観測です、そして、ウェブTVには6がある24があるのは1年単位で加えました。

3.1.3 Registration of URI Schemes

3.1.3 URI計画の登録

   "Registration Procedures for URL Scheme Names" (RFC 2717) [1]
   specifies procedures for registering scheme names and points to
   "Guidelines for new URL Schemes" (RFC 2718) [2], which supplies
   guidelines.  RFC 2717 describes an organization of schemes into
   "trees".  It is important to note that these two documents use the
   historical term 'URL' when in fact, they refer to URIs in general.
   In fact, one of the recommended tasks in Section 5 is for these
   documents to be updated to use the term 'URI' instead of 'URL'.

「URL Scheme Namesのための登録Procedures」(RFC2717)[1]は計画名を登録するための手順を指定して、「新しいURL Schemesのためのガイドライン」(RFC2718)[2]を示します。([2]はガイドラインを提供します)。 RFC2717は「木」に計画の組織について説明します。 これらの2通のドキュメントが'URL'という事実上彼らが一般に、URIについて言及する歴史的な用語を使用することに注意するのは重要です。 事実上、セクション5のお勧めのタスクの1つは'URL'の代わりに'URI'という用語を使用するためにこれらのドキュメントをアップデートすることです。

3.1.3.1 IETF Tree

3.1.3.1 IETF木

   The IETF tree is intended for schemes of general interest to the
   Internet community, and for those which require a substantive review
   and approval process.  Registration in the IETF tree requires
   publication of the scheme syntax and semantics in an RFC.

IETF木はインターネットコミュニティ、および実質的なレビューを必要とするものに関する一般的興味と承認審査方式の計画のために意図します。 IETF木での登録はRFCの計画構文と意味論の公表を必要とします。

3.1.3.2 Other Trees

3.1.3.2 他の木

   Although RFC 2717 describes "alternative trees", no alternative trees
   have been registered to date, although a vendor-supplied tree ("vnd")
   is pending.  URI schemes in alternative trees will be distinguished
   because they will have a "." in the scheme name.

RFC2717は「代替の木」について説明しますが、どんな代替の木もこれまで登録されていません、業者によって供給された木("vnd")は未定ですが。 計画名で「それらにはa」があるので、代替の木でのURI計画は区別されるでしょう」。

3.2 URN Namespaces

3.2 つぼの名前空間

   A URN namespace is identified by a "Namespace ID" (NID), which is
   registered with IANA (see Section 3.2.4).

URN名前空間は「Namespace ID」(NID)によって特定されます(セクション3.2.4を見てください)。(それは、IANAに登録されます)。

3.2.1 Registered URN NIDs

3.2.1 登録されたつぼのNIDs

   There are two categories of registered URN NIDs:

登録されたURN NIDsの2つのカテゴリがあります:

   o  Informal: These are of the form, "urn-<number>", where <number> is
      assigned by IANA.  There are four registered (at time of
      publication of this RFC) in this category  (urn-1, urn-2,  urn-3,
      and urn-4).

o 非公式: これらはフォーム、「つぼ-<は>に付番する」ものです。そこでは、<番号>がIANAによって割り当てられます。 登録された4(このRFCの公表の時間の)がこのカテゴリ(つぼ-1、つぼ-2、つぼ-3、およびつぼ-4)にあります。

Mealling & Denenberg         Informational                      [Page 5]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[5ページ]のRFC3305URI、URL、およびつぼの2002年8月

   o  Formal: The official list of registered NIDs is kept by IANA at
      http://www.iana.org/assignments/urn-namespaces.  At the time of
      publication of this RFC it lists ten registered NIDs:

o 正式: 登録されたNIDsに関する株式相場表は http://www.iana.org/assignments/urn-namespaces にIANAによって保たれます。 このRFCの公表時点で、10登録されたNIDsを記載します:

      *  'ietf', defined by "URN Namespace for IETF Documents" (RFC
         2648) [3]

* 「IETFドキュメントのためのつぼの名前空間」(RFC2648)によって定義された'ietf'[3]

      *  'pin', defined by "The Network Solutions Personal Internet Name
         (PIN): A URN Namespace for People and Organizations" (RFC 3043)
         [4]

* 「ネットワークソリューションパーソナルインターネットは以下を命名(ピンで止めます)」によって定義された'ピン' 「人々と組織のためのつぼの名前空間」(RFC3043)[4]

      *  'issn' defined by "Using The ISSN as URN within an ISSN-URN
         Namespace" (RFC 3043) [4]

* 「つぼとしてISSN-つぼの名前空間の中でISSNを使用します」で定義された'issn'(RFC3043)[4]

      *  'oid' defined by "A URN Namespace of Object Identifiers" (RFC
         3061) [6]

* 「物の識別子のつぼの名前空間」(RFC3061)によって定義された'oid'[6]

      *  'newsml' defined by "URN Namespace for NewsML Resources" (RFC
         3085) [7]

* 「NewsMLリソースのためのつぼの名前空間」(RFC3085)によって定義された'newsml'[7]

      *  'oasis' defined by "A URN Namespace for OASIS" (RFC 3121) [8]

* 「オアシスへのつぼの名前空間」(RFC3121)によって定義された'オアシス'[8]

      *  'xmlorg' defined by "A URN Namespace for XML.org" (RFC 3120)
         [9]

* 「XML.orgのためのつぼの名前空間」(RFC3120)によって定義された'xmlorg'[9]

      *  'publicid' defined by "A URN Namespace for Public Identifiers"
         (RFC 3151) [10]

* 「公共の識別子のためのつぼの名前空間」(RFC3151)によって定義された'publicid'[10]

      *  'isbn' defined by "Using International Standard Book Numbers as
         Uniform Resource Names" (RFC 3187) [15]

* 「一定のリソース名として国際標準図書番号を使用します」で定義された'isbn'(RFC3187)[15]

      *  'nbn' defined by "Using National Bibliography Numbers as
         Uniform Resource Names" (RFC 3188) [16]

* 「一定のリソース名として国語別書目番号を使用します」で定義された'nbn'(RFC3188)[16]

3.2.2 Pending URN NIDs

3.2.2 未定のつぼのNIDs

   There are a number of pending URN NID registration requests, but
   there is no reliable way to discover them, or their status.  It would
   be helpful if there were some formal means to track the status of NID
   requests such as 'isbn'.

多くの未定のURN NID登録要求がありますが、どんなそれらを発見する信頼できる方法も、またはそれらの状態もいません。 'isbn'などのNID要求の状態を追跡するいくつかの正式な手段があれば、助かるでしょうに。

Mealling & Denenberg         Informational                      [Page 6]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[6ページ]のRFC3305URI、URL、およびつぼの2002年8月

3.2.3 Unregistered NIDs

3.2.3 登録されていないNIDs

   In the "unregistered" category (besides the experimental case, not
   described in this paper), there are entities that maintain namespaces
   that, while completely appropriate as URNs, just haven't bothered to
   explore the process of NID registration.  The most prominent that
   comes to mind is 'hdl'.  In the case of 'hdl', it has been speculated
   that this scheme has not been registered because it is not clear to
   the owners whether it should be registered as a URI scheme or as a
   URN namespace.

「登録されていない」カテゴリ(この紙で説明されなかった実験ケース以外に)に、URNsとして完全に適切である間にちょうどわざわざNID登録の過程を探っていない名前空間を維持する実体があります。 気にするそれがなる中で最も際立ったものは'hdl'です。 'hdl'の場合では、所有者には、それがURI計画として、または、URN名前空間として登録されるべきであるかどうかは、明確でないのでこの計画が登録されていないと推測されました。

3.2.4 Registration Procedures for URN NIDs

3.2.4 つぼのNIDsのための登録手順

   "URN Namespace Definition Mechanisms" (RFC 2611) [11] describes the
   mechanism to obtain an NID for a URN namespace, which is registered
   with IANA.

「URN Namespace Definition Mechanisms」(RFC2611)[11]は、URN名前空間にNIDを入手するためにメカニズムについて説明します。(名前空間はIANAに登録されます)。

   A request for an NID should describe features including: structural
   characteristic of identifiers (for example, features relevant to
   caching/shortcuts approaches); specific character encoding rules
   (e.g., which character should be used for single-quotes); RFCs,
   standards, etc, that explain the namespace structure; identifier
   uniqueness considerations; delegation of assignment authority,
   including how to become an assigner of identifiers; identifier
   persistence considerations; quality of service considerations;
   process for identifier resolution; rules for lexical equivalence; any
   special considerations required for conforming with the URN syntax
   (particularly applicable in the case of legacy naming systems);
   validation mechanisms (determining whether a given string is
   currently a validly-assigned URN); and scope (for example,"United
   States social security numbers").

説明して、:NIDを求める要求は特徴について説明するべきです。 識別子(例えば、キャッシュ/近道のアプローチに関連している特徴)の構造的な特性。 特定のキャラクタコード化は統治されます(例えば、どのキャラクタがシングル・クォーテション・マークに使用されるべきですか)。 RFCs、名前空間構造がわかる規格など。 識別子ユニークさの問題。 識別子の指定人になる方法を含む課題権威の代表団。 識別子固執問題。 サービスの質問題。 識別子解決には、処理してください。 語彙等価性のための規則。 どんな特別な問題も(特に遺産命名システムの場合で適切)でURN構文に従うのに必要です。 合法化メカニズム(現在与えられたストリングが確実に割り当てられたURNであるかどうか決定します)。 そして、範囲(例えば、「合衆国社会保険番号」)。

4. Additional URI Issues

4. 追加URI問題

   There are additional unresolved URI issues not considered by this
   paper, which we hope will be addressed by a follow-on effort.  We
   have not attempted to completely enumerate these issues, however,
   they include (but are not limited to) the following:

私たちがフォローオンの努力で記述されることを望んでいるこの紙によって考えられなかった追加未定のURI問題があります。 しかし、私たちが、しかしながら、これらの問題を完全に列挙するのを試みていなくて、それらがインクルードである、(制限されない、)、以下:

   o  The use of URIs as identifiers that don't actually identify
      network resources (for example, they identify an abstract object,
      such as an XML namespace, or a physical object such as a book or
      even a person).

o 識別子としてのURIの実際にそうしない使用はネットワーク資源を特定します(例えば、それらはXML名前空間、または対象物などの本か人などさえの抽象的な物を特定します)。

   o  IRIs (International Resource Identifiers): the extension of URI
      syntax to non-ASCII.

o 虹彩(国際リソース識別子): 非ASCIIへのURI構文の拡大。

Mealling & Denenberg         Informational                      [Page 7]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[7ページ]のRFC3305URI、URL、およびつぼの2002年8月

5. Recommendations

5. 推薦

   We recommend the following:

私たちは以下を推薦します:

   1. The W3C and IETF should jointly develop and endorse a model for
      URIs, URLs, and URNs consistent with the "Contemporary View"
      described in section 1, and which considers the additional URI
      issues listed or alluded to in section 3.

1. W3CとIETFはURIのために共同でモデルを開発して、宣伝するはずです、URL、そして、「現代の視点」と一致したURNsは1とどれがセクション3で記載されたか、または暗示された追加URI問題を考えるかをセクションで説明しました。

   2. RFCs such as 2717 ("Registration Procedures for URL Scheme Names")
      and 2718 ("Guidelines for new URL Schemes") should both be
      generalized to refer to "URI schemes", rather than "URL schemes"
      and, after refinement, moved forward as Best Current Practices in
      the IETF.

2. 2717年などのRFCs(「URL計画名のための登録手順」)と2718(「新しいURL Schemesのためのガイドライン」)は、ともに「URL計画」よりむしろ「URI計画」について言及するために一般化されて、気品の後にBest Current PracticesとしてIETFを前方へ動くべきです。

   3. The registration procedures for alternative trees should be
      clarified in RFC 2717.

3. 代替の木のための登録手順はRFC2717ではっきりさせられるべきです。

   4. Public, but unregistered schemes, should become registered, where
      possible.  Obsolete schemes should be purged or clearly marked as
      obsolete.

4. 公衆(登録されていない計画だけ)は可能であるところで登録されるようになるべきです。 時代遅れの計画は、掃除されるべきであるか、または時代遅れであると明確にマークされるべきです。

   5. IANA registration information should be updated:

5. IANAレジスト情報をアップデートするべきです:

      *  Add 'urn' to the list of registered URI schemes with a pointer
         to the URN namespace registry.

* URN名前空間登録へのポインタで登録されたURI計画のリストに'つぼ'を追加してください。

      *  Maintain status information about pending registrations (URI
         schemes and URN NID requests ).

* 未定の登録証明書(URI計画とURN NID要求)の状態情報を保守してください。

      *  Insure that it is clear that the page is the official registry,
         e.g., by adding a heading to the effect "This is the Official
         IANA Registry of URI Schemes".

* ページが戸籍登記所であることが明確であることを保障してください、例えば、効果への「これはURI SchemesのOfficial IANA Registryです」という見出しを加えることによって。

6. Security Considerations

6. セキュリティ問題

   This memo does not raise any known security threats.

このメモは少しの知られている軍事的脅威も上げません。

7. Acknowledgements

7. 承認

   The participants in the URI Planning Interest Group are:

URI Planning Interest Groupの関係者は以下の通りです。

   o  Tony Coates

o トニー・コーツ

   o  Dan Connolly

o ダン・コノリー

   o  Diana Dack

o ダイアナDack

Mealling & Denenberg         Informational                      [Page 8]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[8ページ]のRFC3305URI、URL、およびつぼの2002年8月

   o  Leslie Daigle

o レスリーDaigle

   o  Ray Denenberg

o レイDenenberg

   o  Martin Duerst

o マーチンDuerst

   o  Paul Grosso

o ポール・グロッソ

   o  Sandro Hawke

o サンドロスホーク

   o  Renato Iannella

o レナートIannella

   o  Graham Klyne

o グラハムKlyne

   o  Larry Masinter

o ラリーMasinter

   o  Michael Mealling

o マイケルMealling

   o  Mark Needleman

o マーク・ニードルマン

   o  Norman Walsh

o ノーマン・ウォルシュ

References

参照

   [1]  Petke, R. and I. King, "Registration Procedures for URL Scheme
        Names", BCP 35, RFC 2717, November 1999.

[1]Petke、R.とI.キング、「URL計画名のための登録手順」BCP35、1999年11月のRFC2717。

   [2]  Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
        "Guidelines for new URL Schemes", RFC 2718, November 1999.

[2]MasinterとL.とAlvestrandとH.とZigmondとD.とR.Petke、「新しいURL Schemesのためのガイドライン」、RFC2718、1999年11月。

   [3]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
        August 1999.

[3] モウツ、R.、「IETFドキュメントのためのつぼの名前空間」、RFC2648、1999年8月。

   [4]  Mealling, M., "The Network Solutions Personal Internet Name
        (PIN): A URN Namespace for People and Organizations", RFC 3043,
        January 2001.

[4] 食事、M.、「ネットワークソリューションパーソナルインターネットは以下を命名(ピンで止めます)」。 「人々と組織のためのつぼの名前空間」、RFC3043、2001年1月。

   [5]  Rozenfeld, S., "Using The ISSN (International Serial Standard
        Number) as URN (Uniform Resource Names) within an ISSN-URN
        Namespace", RFC 3044, January 2001.

[5] S. Rozenfeld、「つぼ(一定のリソース名)としてISSN-つぼの名前空間の中でISSN(国際連続の標準の数)を使用すること」でのRFC3044(2001年1月)。

   [6]  Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061,
        February 2001.

[6] 食事、M.、「物の識別子のつぼの名前空間」、RFC3061、2001年2月。

   [7]  Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace for
        NewsML Resources", RFC 3085, March 2001.

[7] コーツとA.とアレンとD.とD.川ムーア、「NewsMLリソースのためのつぼの名前空間」、RFC3085、2001年3月。

Mealling & Denenberg         Informational                      [Page 9]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[9ページ]のRFC3305URI、URL、およびつぼの2002年8月

   [8]  Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121,
        June 2001.

[8] 最善とK.とN.ウォルシュ、「オアシスへのつぼの名前空間」、RFC3121、2001年6月。

   [9]  Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120,
        June 2001.

[9] 最善とK.とN.ウォルシュ、「XML.orgのためのつぼの名前空間」、RFC3120、2001年6月。

   [10] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public
        Identifiers", RFC 3151, August 2001.

[10] ウォルシュとN.とカウァンとJ.とP.グロッソ、「公共の識別子のためのつぼの名前空間」、RFC3151、2001年8月。

   [11] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN
        Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999.

[11] GulikとD.とIannellaとR.とP.Faltstrom、「つぼの名前空間定義メカニズム」をDaigle(L.)はバンに積みます、BCP33、RFC2611、1999年6月。

   [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[12]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。

   [13] Sollins, K., "Architectural Principles of Uniform Resource Name
        Resolution", RFC 2276, January 1998.

[13]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。

   [14] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

[14] フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [15] Hakala, J. and H. Walravens, "Using International Standard Book
        Numbers as Uniform Resource Names", RFC 3187, October 2001.

[15]HakalaとJ.とH.Walravens、「一定のリソース名として国際標準図書番号を使用します」、RFC3187、2001年10月。

   [16] Hakala, J., "Using National Bibliography Numbers as Uniform
        Resource Names", RFC 3188, October 2001.

[16]Hakala、J.、「一定のリソース名として国語別書目番号を使用します」、RFC3188、2001年10月。

Authors' Addresses

作者のアドレス

   Michael Mealling
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

ベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル

   EMail: michael@verisignlabs.com

メール: michael@verisignlabs.com

   Ray Denenberg
   Library of Congress
   Washington, DC  20540
   US

レイDenenberg議会図書館のDC20540ワシントン(米国)

   EMail: rden@loc.gov

メール: rden@loc.gov

Mealling & Denenberg         Informational                     [Page 10]

RFC 3305                  URIs, URLs, and URNs               August 2002

食事、Denenberg情報[10ページ]のRFC3305URI、URL、およびつぼの2002年8月

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Mealling & Denenberg         Informational                     [Page 11]

食事とDenenberg情報です。[11ページ]