[要約] RFC 8141は、URN（Uniform Resource Names）の標準化に関するものであり、URNの構文と解決方法を定義しています。その目的は、URNを使用して永続的で一意な識別子を作成し、インターネット上のリソースの一貫性と持続性を確保することです。
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 8141 Filament
Obsoletes: 2141, 3406 J. Klensin
Category: Standards Track April 2017
ISSN: 2070-1721
Uniform Resource Names (URNs)
ユニフォームリソース名（URN）
Abstract
概要
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.
Uniform Resource Name（URN）は、「urn」URIスキームと特定のURN名前空間の下で割り当てられるUniform Resource Identifier（URI）であり、URNは場所に依存しない永続的なリソース識別子になることを意図しています。 URN構文に関して、このドキュメントでは、URNの標準的な構文を（URI構文と一貫した方法で）定義し、URNとの同等性を判断する方法を指定し、URIへの準拠について説明します。このドキュメントでは、URN名前空間に関して、URN名前空間を定義して名前空間識別子に関連付ける方法を指定し、名前空間識別子をInternet Assigned Numbers Authority（IANA）に登録する手順について説明します。このドキュメントは、RFC 2141と3406の両方を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8141.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8141で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Design Trade-offs . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Resolution . . . . . . . . . . . . . . . . . . . . . 8
1.2.2. Character Sets and Encodings . . . . . . . . . . . . 9
2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Namespace Identifier (NID) . . . . . . . . . . . . . . . 10
2.2. Namespace Specific String (NSS) . . . . . . . . . . . . . 10
2.3. Optional Components . . . . . . . . . . . . . . . . . . . 12
2.3.1. r-component . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. q-component . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. f-component . . . . . . . . . . . . . . . . . . . . . 15
3. URN-Equivalence . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
4. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Use in URI Protocol Slots . . . . . . . . . . . . . . . . 18
4.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. URNs and Relative References . . . . . . . . . . . . . . 19
4.4. Transport and Display . . . . . . . . . . . . . . . . . . 19
4.5. URI Design and Ownership . . . . . . . . . . . . . . . . 20
5. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Formal URN Namespaces . . . . . . . . . . . . . . . . . . 22
5.2. Informal URN Namespaces . . . . . . . . . . . . . . . . . 23
6. Defining and Registering a URN Namespace . . . . . . . . . . 24
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Registration Policy and Process: Community Registrations 25
6.3. Registration Policy and Process: Fast Track for Standards
Development Organizations, Scientific Societies, and
Similar Bodies . . . . . . . . . . . . . . . . . . . . . 26
6.4. Completing the Template . . . . . . . . . . . . . . . . . 27
6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.3. Assignment . . . . . . . . . . . . . . . . . . . . . 29
6.4.4. Security and Privacy . . . . . . . . . . . . . . . . 29
6.4.5. Interoperability . . . . . . . . . . . . . . . . . . 30
6.4.6. Resolution . . . . . . . . . . . . . . . . . . . . . 30
6.4.7. Additional Information . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
7.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Registration of URN Namespaces . . . . . . . . . . . . . 31
7.3. Discussion List for New and Updated NID Registrations . . 31
8. Security and Privacy Considerations . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Registration Template . . . . . . . . . . . . . . . 37
Appendix B. Changes from RFC 2141 . . . . . . . . . . . . . . . 38
B.1. Syntax Changes from RFC 2141 . . . . . . . . . . . . . . 38
B.2. Other Changes from RFC 2141 . . . . . . . . . . . . . . . 39
Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . 39
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) [RFC3986] that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. A URN namespace is a collection of such URNs, each of which is (1) unique, (2) assigned in a consistent and managed way, and (3) assigned according to a common definition. (Some URN namespaces create names that exist only as URNs, whereas others assign URNs based on names that were already created in non-URN identifier systems, such as ISBNs [RFC3187], ISSNs [RFC3044], or RFCs [RFC2648].)
Uniform Resource Name（URN）は、「urn」URIスキームと特定のURN名前空間の下で割り当てられるUniform Resource Identifier（URI）[RFC3986]であり、URNは場所に依存しない永続的なリソース識別子になることを意図しています。 。 URNネームスペースは、そのようなURNのコレクションであり、それぞれが（1）一意、（2）一貫性のある管理された方法で割り当てられ、（3）共通の定義に従って割り当てられます。 （一部のURNネームスペースは、URNとしてのみ存在する名前を作成しますが、ISBN [RFC3187]、ISSN [RFC3044]、RFC [RFC2648]など、URN以外の識別子システムですでに作成された名前に基づいてURNを割り当てるものもあります。）
The assignment of URNs is done by an organization (or, in some cases, according to an algorithm or other automated process) that has been formally delegated a URN namespace within the "urn" scheme (e.g., a URN in the "example" URN namespace [RFC6963] might be of the form "urn:example:foo").
URNの割り当ては、「urn」スキーム内でURN名前空間を正式に委任された組織（または場合によっては、アルゴリズムまたは他の自動プロセス）によって行われます（たとえば、「example」URNのURN）名前空間[RFC6963]は、「urn：example：foo」の形式である場合があります。
This document rests on two key assumptions:
このドキュメントは、次の2つの主要な前提に基づいています。
1. Assignment of a URN is a managed process.
1. URNの割り当ては、管理されたプロセスです。
2. The space of URN namespaces is itself managed.
2. URN名前空間のスペース自体が管理されます。
While other URI schemes may allow resource identifiers to be freely chosen and assigned, such is not the case for URNs. The syntactical correctness of a name starting with "urn:" is not sufficient to make it a URN. In order for the name to be a valid URN, the namespace identifier (NID) needs to be registered in accordance with the rules defined here, and the remaining parts of the assigned-name portion of the URN need to be generated in accordance with the rules for the registered URN namespace.
他のURIスキームではリソース識別子を自由に選択して割り当てることができますが、これはURNには当てはまりません。 「urn：」で始まる名前の構文的な正確さは、それをURNにするのに十分ではありません。名前が有効なURNになるためには、ここで定義されている規則に従って名前空間識別子（NID）を登録する必要があり、URNの割り当てられた名前部分の残りの部分は、登録されたURN名前空間のルール。
So that information about both URN syntax and URN namespaces is available in one place, this document does the following:
URN構文とURN名前空間の両方に関する情報が1か所で利用できるように、このドキュメントでは次のことを行います。
1. Defines the canonical syntax for URNs in general (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance.
1. URNの一般的な構文を（URI構文と一貫性のある方法で）一般的に定義し、URNとの同等性を判断する方法を指定し、URIへの準拠について説明します。
2. Specifies a method for defining a URN namespace and associating it with a particular NID, and describes procedures for registering URN NIDs with the Internet Assigned Numbers Authority (IANA).
2. URNネームスペースを定義して特定のNIDに関連付ける方法を指定し、URN NIDをInternet Assigned Numbers Authority（IANA）に登録する手順を説明します。
For URN syntax and URN namespaces, this document modernizes and replaces the original specifications for URN syntax [RFC2141] and for the definition and registration of URN namespaces [RFC3406]. These modifications build on the key requirements provided in the original functional description for URNs [RFC1737] and on the lessons of many years of experience. In those original documents and in the present one, the intent is to define URNs in a consistent manner so that, wherever practical, the parsing, handling, and resolution of URNs can be independent of the URN namespace within which a given URN is assigned.
URN構文とURNネームスペースについては、このドキュメントはURN構文[RFC2141]とURNネームスペースの定義と登録[RFC3406]の元の仕様を最新化し、置き換えます。これらの変更は、URNの元の機能説明[RFC1737]で提供された主要な要件と、長年の経験の教訓に基づいています。これらの元のドキュメントと現在のドキュメントでは、一貫した方法でURNを定義することを意図しているため、URNの解析、処理、および解決は、所定のURNが割り当てられているURNネームスペースから独立して実行できます。
Together with input from several key user communities, the history and experiences with URNs dictated expansion of the URN definition to support new functionality, including the use of syntax explicitly reserved for future standardization in RFC 2141. All URN namespaces and URNs that were valid under the earlier specifications remain valid, even though it may be useful to update the definitions of some URN namespaces to take advantage of new features.
いくつかの主要なユーザーコミュニティからの入力とともに、URNの履歴と経験は、RFC 2141の将来の標準化のために明示的に予約された構文の使用を含む、新しい機能をサポートするためのURN定義の拡張を指示しました。新しい機能を利用するために一部のURN名前空間の定義を更新すると役立つ場合がありますが、以前の仕様は引き続き有効です。
The foregoing considerations, together with various differences between URNs and URIs that are locators (specifically URLs) as well as the greater focus on URLs in RFC 3986 as the ultimate successor to [RFC1738] and [RFC1808], may lead to some interpretations of RFC 3986 and this specification that appear (or perhaps actually are) not completely consistent, especially with regard to actions or semantics other than the basic syntax itself. If such situations arise, discussions of URNs and URN namespaces should be interpreted according to this document and not by extrapolation from RFC 3986.
前述の考慮事項は、ロケーター（具体的にはURL）であるURNとURIのさまざまな違い、および[RFC1738]と[RFC1808]の後継としてRFC 3986のURLにさらに重点を置くと、RFCのいくつかの解釈につながる可能性があります。 3986と表示される（または実際にはおそらく）この仕様は完全に一貫していません。特に、基本的な構文自体以外のアクションまたはセマンティクスに関してはです。このような状況が発生した場合、URNおよびURN名前空間の説明は、RFC 3986からの外挿ではなく、このドキュメントに従って解釈する必要があります。
Summaries of changes from RFCs 2141 and 3406 appear in Appendices B and C, respectively. This document obsoletes both [RFC2141] and [RFC3406]. While it does not explicitly update or replace [RFC1737] or [RFC2276], the reader who references those documents should be aware that the conceptual model of URNs in this document is slightly different from those older specifications.
RFC 2141および3406からの変更の要約は、それぞれ付録BおよびCに記載されています。このドキュメントは[RFC2141]と[RFC3406]の両方を廃止します。 [RFC1737]または[RFC2276]を明示的に更新または置換するものではありませんが、これらのドキュメントを参照する読者は、このドキュメントのURNの概念モデルが以前の仕様と少し異なることに注意してください。
The following terms are distinguished from each other as described below:
以下の用語は、以下で説明するように互いに区別されます。
URN: A URI (as defined in RFC 3986) using the "urn" scheme and with the properties of a "name" as described in that document as well as the properties described in this one. The term applies to the entire URI including its optional components. Note to the reader: the term "URN" has been used in other contexts to refer to a URN namespace, the namespace identifier, the assigned-name, and URIs that do not use the "urn" scheme. All but the last of these is described using more specific terminology elsewhere in this document, but, because of those other uses, the term should be used and interpreted with care.
URN：「urn」スキームを使用し、そのドキュメントで説明されている「名前」のプロパティと、このドキュメントで説明されているプロパティを使用したURI（RFC 3986で定義）。この用語は、オプションのコンポーネントを含むURI全体に適用されます。読者への注意：「URN」という用語は、URN名前空間、名前空間識別子、割り当てられた名前、および「urn」スキームを使用しないURIを指すために他のコンテキストで使用されています。これらの最後以外はすべて、このドキュメントの他の場所でより具体的な用語を使用して説明されていますが、他の使用法のため、この用語は注意して使用および解釈する必要があります。
Locator: An identifier that provides a means of accessing a resource.
ロケーター：リソースにアクセスする手段を提供する識別子。
Identifier system: A managed collection of names. This document refers to identifier systems outside the context of URNs as "non-URN identifier systems".
識別子システム：管理された名前のコレクション。このドキュメントでは、URNのコンテキスト外の識別子システムを「非URN識別子システム」と呼びます。
URN namespace: An identifier system that is associated with a URN NID.
URN名前空間：URN NIDに関連付けられている識別子システム。
NID: The identifier associated with a URN namespace.
NID：URN名前空間に関連付けられた識別子。
NSS: The URN-namespace-specific part of a URN.
NSS：URNのURN名前空間固有の部分。
Assigned-name: The combination of the "urn:" scheme, the NID, and the namespace specific string (NSS). An "assigned-name" is consequently a substring of a URN (as defined above) if that URN contains any additional components (see Section 2).
割り当てられた名前：「urn：」スキーム、NID、および名前空間固有の文字列（NSS）の組み合わせ。 「割り当てられた名前」は、そのURNに追加のコンポーネントが含まれている場合（セクション2を参照）、その結果、URN（上記で定義）のサブストリングになります。
The term "name" is deliberately not defined here and should be (and, in practice, is) used only very informally. RFC 3986 uses the term as a category of URI distinguished from "locator" (Section 1.1.3) but also uses it in other contexts. If those uses are treated as definitional, they would conflict with, e.g., the idea of URN namespace names (i.e., NIDs) and with terms associated with non-URN identifier systems.
「名前」という用語はここでは意図的に定義されていないため、非常に非公式にのみ使用する必要があります（実際には使用します）。 RFC 3986は、この用語を「ロケーター」（セクション1.1.3）と区別されるURIのカテゴリとして使用しますが、他のコンテキストでも使用します。これらの使用が定義的なものとして扱われる場合、それらは、たとえば、URN名前空間名（つまり、NID）の概念および非URN識別子システムに関連付けられた用語と競合します。
This document uses the terms "resource", "identifier", "identify", "dereference", "representation", and "metadata" roughly as defined in the URI specification [RFC3986].
このドキュメントでは、URI仕様[RFC3986]で大まかに定義されている「リソース」、「識別子」、「識別」、「逆参照」、「表現」、および「メタデータ」という用語を使用します。
This document uses the terms "resolution" and "resolver" in roughly the sense in which they were used in the original discussion of architectural principles for URNs [RFC2276], i.e., "resolution" is the act of supplying services related to the identified resource, such as translating the persistent URN into one or more current locators for the resource, delivering metadata about the resource in an appropriate format, or even delivering a representation of the resource (e.g., a document) without requiring further intermediaries. At the time of this writing, resolution services are described in [RFC2483].
このドキュメントでは、URN [RFC2276]のアーキテクチャの原則に関する最初の議論で使用されたのとほぼ同じ意味で「解決」および「リゾルバ」という用語を使用します。つまり、「解決」は、特定されたリソースに関連するサービスを提供する行為ですたとえば、永続的なURNをリソースの1つ以上の現在のロケーターに変換する、リソースに関するメタデータを適切な形式で配信する、さらには仲介者を必要とせずにリソース（ドキュメントなど）の表現を配信するなどです。この記事の執筆時点では、解決サービスは[RFC2483]で説明されています。
On the distinction between representations and metadata, see Section 1.2.2 of [RFC3986].
表現とメタデータの違いについては、[RFC3986]のセクション1.2.2を参照してください。
Several other terms related to "normalization" operations that are not part of the Unicode Standard [UNICODE] are also used here as they are in RFC 3986.
Unicode標準[UNICODE]の一部ではない「正規化」操作に関連する他のいくつかの用語も、RFC 3986と同様にここで使用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
To a degree much greater than when URNs were first considered and their uses outlined (see [RFC1737]), issues of persistent identifiers on the Internet involve fundamental design trade-offs that are much broader than URNs or the URN approach and even touch on open research questions within the information sciences community. Ideal and comprehensive specifications about what should be done or required across the entire universe of URNs would require general agreement about, and solutions to, a wide range of such issues. Although some of those issues were introduced by the Internet or computer-age approaches to character encodings and data abstraction, others predate the Internet and computer systems by centuries; there is unlikely to be agreement about comprehensive solutions in the near future.
URNが最初に検討され、その使用法が概説されたとき（[RFC1737]を参照）よりもはるかに大きい、インターネット上の永続的な識別子の問題には、URNまたはURNアプローチよりもはるかに広い基本的な設計トレードオフが含まれ、オープン情報科学コミュニティ内の研究質問。 URNの全領域にわたって何を行うか、または必要とするかについての理想的で包括的な仕様では、このような幅広い問題についての一般的な合意と解決策が必要です。これらの問題の一部は、文字エンコーディングとデータ抽象化へのインターネットまたはコンピューター時代のアプローチによって導入されましたが、他の問題は何世紀にもわたってインターネットとコンピューターシステムに先行していたものです。近い将来、包括的なソリューションについて合意が得られる可能性はほとんどありません。
Although this specification consequently contains some requirements and flexibility that would not be present in a more perfect world, this has been necessary in order to produce a consensus specification that provides a modernized definition of URNs (the unattractive alternative would have been to not modernize the definition in spite of widespread deployment).
したがって、この仕様には、より完全な世界には存在しないいくつかの要件と柔軟性が含まれていますが、これは、URNの最新の定義を提供するコンセンサス仕様を作成するために必要でした（魅力的でない代替案は、定義を最新化しないことでした）広範な展開にもかかわらず）。
The following sub-sections describe two of the relevant issues in greater detail.
次のサブセクションでは、関連する2つの問題について詳しく説明します。
One issue that is specific to URNs (as opposed to naming systems in general) is the fairly difficult topic of "resolution", discussed in Sections 1.1, 2.3.1, 6.4.6, and elsewhere below.
（一般的なネーミングシステムとは対照的に）URNに固有の1つの問題は、セクション1.1、2.3.1、6.4.6、および以下で説明されている「解決」のかなり難しいトピックです。
With traditional Uniform Resource Locators (URLs), i.e., with most URIs that are locators, resolution is relatively straightforward because it is used to determine an access mechanism that in turn is used to dereference the locator by (typically) retrieving a representation of the associated resource, such as a document (see Section 1.2.2 of [RFC3986]).
従来のUniform Resource Locator（URL）、つまりロケーターであるほとんどのURIでは、関連付けられた表現を（通常）取得することによってロケーターを逆参照するために使用されるアクセスメカニズムを決定するために使用されるため、解決は比較的簡単です。ドキュメントなどのリソース（[RFC3986]のセクション1.2.2を参照）。
By contrast, resolution for URNs is more flexible and varied.
対照的に、URNの解像度はより柔軟で多様です。
One important case involves the mapping of a URN to one or more locators. In this case, the end result is still a matter of dereferencing the mapped locator(s) to one or more representations. The primary difference here is persistence: even if a mapped locator has changed (e.g., a DNS domain name has changed hands and a URL has not been modified to point to a new location or, in a more extreme and hypothetical case, the DNS is replaced entirely), a URN user will be able to obtain the correct representation (e.g., a document) as long as the resolver has kept its URN-to-locator mappings up to date. Consequently, the relevant relationships can be defined quite precisely for URNs that resolve to locators that in turn are dereferenced to a representation.
1つの重要なケースは、URNを1つ以上のロケーターにマッピングすることです。この場合でも、最終結果は、マップされたロケーターを1つ以上の表現に逆参照することです。ここでの主な違いは永続性です。たとえば、マップされたロケーターが変更された場合（たとえば、DNSドメイン名が変更され、URLが新しい場所を指すように変更されていない場合、またはさらに極端で架空のケースでは、DNSは完全に置き換えられます）、リゾルバがURNとロケータのマッピングを最新に保つ限り、URNユーザーは正しい表現（ドキュメントなど）を取得できます。その結果、関連する関係は、ロケーターに解決されるURNに対して非常に正確に定義でき、そのロケーターは、表現に逆参照されます。
However, this specification permits several other cases of URN resolution as well as URNs for resources that do not involve information retrieval systems. This is true either individually for particular URNs or (as defined below) collectively for entire URN namespaces.
ただし、この仕様では、情報検索システムに関係しないリソースのURNだけでなく、URN解決の他のいくつかのケースも許可しています。これは、特定のURNに対して個別に、または（以下で定義されているように）URN名前空間全体に対して集合的に当てはまります。
Consider a namespace of URNs that resolve to locators that in turn are dereferenced only to metadata about resources because the underlying systems contain no representations of those resources; an example might be a URN namespace for International Standard Name Identifiers (ISNIs) as that identifier system is defined in the relevant standard [ISO.27729.2012], wherein by default a URN would be resolved only to a metadata record describing the public identity identified by the ISNI.
基礎となるシステムにはそれらのリソースの表現が含まれていないため、リソースに関するメタデータのみに逆参照されるロケーターに解決されるURNの名前空間を検討してください。その例は、国際標準名識別子（ISNI）のURN名前空間である可能性があります。その識別子システムは関連する標準[ISO.27729.2012]で定義されているため、デフォルトでは、URNは以下によって識別されるパブリックIDを記述するメタデータレコードにのみ解決されます。 ISNI。
Consider also URNs that resolve to representations only if the requesting entity is authorized to obtain the representation, whereas other entities can obtain only metadata about the resource; an example might be documents held within the legal depository collection of a national library.
他のエンティティはリソースに関するメタデータのみを取得できるのに対し、要求元のエンティティが表現を取得することを許可されている場合にのみ、表現に解決されるURNも検討してください。例としては、国立図書館の法定保管庫に保管されている文書があります。
Finally, some URNs might not be intended to resolve to locators at all; examples might include URNs identifying XML namespace names (e.g., the "dgiwg" URN namespace specified by [RFC6288]), URNs identifying application features that can be supported within a communications protocol (e.g., the "alert" URN namespace specified by [RFC7462]), and URNs identifying enumerated types such as values in a registry (e.g., a URN namespace could be used to individually identify the values in all IANA registries, as provisionally proposed in [IANA-URN]).
最後に、一部のURNはロケーターへの解決をまったく意図していない場合があります。例には、XML名前空間名を識別するURN（たとえば、[RFC6288]によって指定された「dgiwg」URN名前空間）、通信プロトコル内でサポートできるアプリケーション機能を識別するURN（たとえば、[RFC7462]によって指定された「アラート」URN名前空間）が含まれる場合があります。 ）、およびレジストリの値などの列挙型を識別するURN（たとえば、[IANA-URN]で暫定的に提案されているように、URN名前空間を使用して、すべてのIANAレジストリの値を個別に識別できます）。
Various types of URNs and multiple resolution services that may be available for them leave the concept of "resolution" more complicated but also much richer for URNs than the straightforward case of resolution to a locator that is dereferenced to a representation.
さまざまなタイプのURNおよびそれらに使用可能な複数の解決サービスは、「解決」の概念をより複雑にしますが、表現に逆参照されるロケーターへの解決の単純な場合よりも、URNの方がはるかに豊富です。
A similar set of considerations apply to character sets and encodings. URNs, especially URNs that will be used as user-facing identifiers, should be convenient to use in local languages and writing systems, easily specified with a wide range of keyboards and local conventions, and unambiguous. There are trade-offs among those goals, and it is impossible at present to see how a simple and readily understandable set of rules could be developed that would be optimal, or even reasonable, for all URNs. The discussion in Section 2.2 defines an overall framework that should make generalized parsing and processing possible but also makes recommendations about rules for individual URN namespaces.
同様の考慮事項が文字セットとエンコーディングにも適用されます。 URN、特にユーザーが直面する識別子として使用されるURNは、さまざまなキーボードとローカルの規則で簡単に指定でき、明確であるローカル言語および書記体系で使用するのに便利です。これらの目標の間にはトレードオフがあり、現在のところ、すべてのURNにとって最適な、または合理的な、シンプルで容易に理解できるルールのセットを開発する方法を確認することは不可能です。セクション2.2の説明では、一般的な解析と処理を可能にする全体的なフレームワークを定義しますが、個々のURN名前空間のルールについての推奨も行います。
As discussed above, the syntax for URNs in this specification allows significantly more functionality than was the case in the earlier specifications, most recently [RFC2141]. It is also harmonized with the general URI syntax [RFC3986] (which, it must be noted, was completed after the earlier URN specifications).
上で述べたように、この仕様のURNの構文は、以前の仕様（最近の場合[RFC2141]）の場合よりも大幅に多くの機能を許可します。また、一般的なURI構文[RFC3986]とも調和しています（これは、以前のURN仕様の後に完成したことに注意してください）。
However, this specification does not extend the URN syntax to allow direct use of characters outside the ASCII range [RFC20]. That restriction implies that any such characters need to be percent-encoded as described in Section 2.1 of the URI specification [RFC3986].
ただし、この仕様では、URN構文を拡張して、ASCII範囲[RFC20]外の文字を直接使用することはできません。この制限は、URI仕様[RFC3986]のセクション2.1で説明されているように、そのような文字はパーセントエンコードする必要があることを意味します。
The basic syntax for a URN is defined using the Augmented Backus-Naur Form (ABNF) as specified in [RFC5234]. Rules not defined here (specifically: alphanum, fragment, and pchar) are defined as part of the URI syntax [RFC3986] and used here to point out the syntactic relationship with the terms used there. The definitions of some of the terms used below are not comprehensive; additional restrictions are imposed by the prose that can be found in sections of this document that are specific to those terms (especially r-component in Section 2.3.1 and q-component in Section 2.3.2).
URNの基本的な構文は、[RFC5234]で指定されているAugmented Backus-Naur Form（ABNF）を使用して定義されます。ここで定義されていないルール（具体的には、alphanum、fragment、pchar）は、URI構文[RFC3986]の一部として定義され、ここで使用される用語との構文関係を示すために使用されます。以下で使用されるいくつかの用語の定義は包括的ではありません。これらの用語に固有のこのドキュメントのセクション（特に、セクション2.3.1のr-componentおよびセクション2.3.2のq-component）にある散文によって、追加の制限が課されます。
namestring = assigned-name
[ rq-components ]
[ "#" f-component ]
assigned-name = "urn" ":" NID ":" NSS
NID = (alphanum) 0*30(ldh) (alphanum)
ldh = alphanum / "-"
NSS = pchar *(pchar / "/")
rq-components = [ "?+" r-component ]
[ "?=" q-component ]
r-component = pchar *( pchar / "/" / "?" )
q-component = pchar *( pchar / "/" / "?" )
f-component = fragment
The question mark character "?" can be used without percent-encoding inside r-components, q-components, and f-components. Other than inside those components, a "?" that is not immediately followed by "=" or "+" is not defined for URNs and SHOULD be treated as a syntax error by URN-specific parsers and other processors.
疑問符文字「？」 rコンポーネント、qコンポーネント、およびfコンポーネント内では、パーセントエンコードなしで使用できます。これらのコンポーネントの内部以外では、「？」その直後に「=」または「+」が続かない場合は、URNに対して定義されておらず、URN固有のパーサーおよびその他のプロセッサーによって構文エラーとして扱われる必要があります（SHOULD）。
The following sections provide additional information about the syntactic elements of URNs.
次のセクションでは、URNの構文要素に関する追加情報を提供します。
NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent).
NIDは大文字と小文字を区別しません（たとえば、「ISBN」と「isbn」は同等です）。
Characters outside the ASCII range [RFC20] are not permitted in NIDs, and no encoding mechanism for such characters is supported.
ASCII範囲[RFC20]以外の文字はNIDで許可されておらず、そのような文字のエンコードメカニズムはサポートされていません。
Sections 5.1 and 5.2 impose additional constraints on the strings that can be used as NIDs, i.e., the syntax shown above is not comprehensive.
セクション5.1および5.2では、NIDとして使用できる文字列に追加の制約を課しています。つまり、上記の構文は包括的ではありません。
The NSS is a string, unique within a URN namespace, that is assigned and managed in a consistent way and that conforms to the definition of the relevant URN namespace. The combination of the NID (unique across the entire "urn" scheme) and the NSS (unique within the URN namespace) ensures that the resulting URN is globally unique.
NSSは、URN名前空間内で一意の文字列であり、一貫した方法で割り当ておよび管理され、関連するURN名前空間の定義に準拠します。 NID（「urn」スキーム全体で一意）とNSS（URN名前空間内で一意）の組み合わせにより、結果のURNはグローバルに一意になります。
The NSS as specified in this document allows several characters not permitted by earlier specifications (see Appendix B). In particular, the "/" character, which is now allowed, effectively makes it possible to encapsulate hierarchical names from non-URN identifier systems. For instance, consider the hypothetical example of a hierarchical identifier system in which the names take the form of a sequence of numbers separated by the "/" character, such as "1/406/47452/2". If the authority for such names were to use URNs, it would be natural to place the existing name in the NSS, resulting in URNs such as "urn:example:1/406/47452/2".
このドキュメントで指定されているNSSでは、以前の仕様では許可されていないいくつかの文字を使用できます（付録Bを参照）。特に、現在許可されている「/」文字は、非URN識別子システムからの階層名をカプセル化することを効果的に可能にします。たとえば、名前が「1/406/47452/2」などの「/」文字で区切られた一連の数字の形式をとる階層識別子システムの架空の例を考えてみます。そのような名前の権限がURNを使用することである場合、NSSに既存の名前を配置することは当然であり、その結果、「urn：example：1/406/47452/2」などのURNになります。
Those changes to the syntax for the NSS do not modify the encoding rules for URN namespaces that were defined in accordance with [RFC2141]. If any such URN namespace whose names are used outside of the URN context (i.e., in a non-URN identifier system) also allows the use of "/", "~", or "&" in the native form within that identifier system, then the encoding rules for that URN namespace are not changed by this specification.
NSSの構文に対するこれらの変更は、[RFC2141]に従って定義されたURN名前空間のエンコーディングルールを変更しません。その名前がURNコンテキスト外で（つまり、非URN識別子システムで）使用されるそのようなURN名前空間でも、その識別子システム内のネイティブ形式で「/」、「〜」、または「＆」の使用が許可されている場合の場合、そのURN名前空間のエンコーディングルールは、この仕様によって変更されません。
Depending on the rules governing a non-URN identifier system and its associated URN namespace, names that are valid in that identifier system might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or, consistent with the restrictions in RFC 3986, the characters "/", "?", "#", "[", and "]"). While such a name might be valid within the non-URN identifier system, it is not a valid URN until it has been translated into an NSS that conforms to the rules of that particular URN namespace. In the case of URNs that are formed from names that exist separately in a non-URN identifier system, translation of a name from its "native" format to a URN format is accomplished by using the canonicalization and encoding methods defined for URNs in general or specific rules for that URN namespace. Software that is not aware of namespace-specific canonicalization and encoding rules MUST NOT construct URNs from the name in the non-URN identifier system.
非URN識別子システムとそれに関連付けられたURN名前空間を管理するルールによっては、その識別子システムで有効な名前に、上記の「pchar」の生成で許可されていない文字が含まれている場合があります（ASCII範囲外の文字、またはRFC 3986の制限に従い、文字「/」、「？」、「＃」、「[」、および「]」）。このような名前は非URN識別子システム内で有効である可能性がありますが、その特定のURN名前空間の規則に準拠するNSSに変換されるまで、有効なURNではありません。非URN識別子システムに個別に存在する名前から形成されたURNの場合、「ネイティブ」形式からURN形式への名前の変換は、一般的にURNに定義されている正規化およびエンコード方式を使用して行われます。そのURN名前空間の特定のルール。名前空間固有の正規化およびエンコード規則を認識しないソフトウェアは、非URN識別子システムの名前からURNを構築してはなりません（MUST NOT）。
In particular, with regard to characters outside the ASCII range, URNs that appear in protocols or that are passed between systems MUST use only Unicode characters encoded in UTF-8 and further encoded as required by RFC 3986. To the extent feasible and consistent with the requirements of names defined and standardized elsewhere, as well as the principles discussed in Section 1.2, the characters used to represent names SHOULD be restricted to either ASCII letters and digits or to the characters and syntax of some widely used models such as those of Internationalizing Domain Names in Applications (IDNA) [RFC5890], Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) [RFC7613], or the Unicode Identifier and Pattern Syntax specification [UAX31].
特に、ASCII範囲外の文字に関しては、プロトコルに表示される、またはシステム間で渡されるURNは、UTF-8でエンコードされ、RFC 3986で要求されるようにさらにエンコードされたUnicode文字のみを使用する必要があります。他の場所で定義および標準化されている名前の要件、およびセクション1.2で説明されている原則、名前を表すために使用される文字は、ASCII文字と数字、または国際化ドメインのモデルなどの広く使用されているモデルの文字と構文に制限する必要があります。アプリケーションでの名前（IDNA）[RFC5890]、準備、施行、国際化文字列の比較（PRECIS）[RFC7613]、またはUnicode識別子とパターン構文の仕様[UAX31]。
In order to make URNs as stable and persistent as possible when protocols evolve and the environment around them changes, URN namespaces SHOULD NOT allow characters outside the ASCII range [RFC20] unless the nature of the particular URN namespace makes such characters necessary.
プロトコルが進化し、その周囲の環境が変化したときにURNをできるだけ安定して永続的にするために、特定のURN名前空間の性質によってそのような文字が必要でない限り、URN名前空間はASCII範囲[RFC20]外の文字を許可しないでください。
This specification includes three optional components in the URN syntax. They are known as r-component, q-component, and f-component and are described in more detail below. Because this specification focuses almost exclusively on URN syntax, it does not define detailed semantics of these components for URNs in general. However, each of these components has a distinct role that is independent of any given URN and its URN namespace. It is intended that clients will be able to handle these components uniformly for all URNs. These components MAY be used with URNs from existing URN namespaces, whether or not a URN namespace explicitly supports them. However, consistent with the approach taken in RFC 3986, the behavior of a URN that contains components that are undefined or meaningless for a particular URN namespace or resource is not defined. The following sections describe these optional components and their interpretation in greater detail.
この仕様には、URN構文の3つのオプションコンポーネントが含まれています。これらは、r-コンポーネント、q-コンポーネント、f-コンポーネントとして知られており、以下で詳しく説明します。この仕様はURN構文にほとんど専念しているため、URNの一般的なこれらのコンポーネントの詳細なセマンティクスは定義していません。ただし、これらの各コンポーネントには、特定のURNとそのURN名前空間から独立した別個の役割があります。クライアントがこれらのコンポーネントをすべてのURNで均一に処理できるようにすることを目的としています。これらのコンポーネントは、URN名前空間で明示的にサポートされているかどうかに関係なく、既存のURN名前空間のURNで使用できます。ただし、RFC 3986で採用されているアプローチと一致して、特定のURN名前空間またはリソースに対して未定義または無意味なコンポーネントを含むURNの動作は定義されていません。次のセクションでは、これらのオプションコンポーネントとその解釈について詳しく説明します。
The r-component is intended for passing parameters to URN resolution services (taken broadly, see Section 1.2) and interpreted by those services. (By contrast, passing parameters to the resources identified by a URN, or to applications that manage such resources, is handled by q-components as described in the next section.)
rコンポーネントは、URN解決サービス（広義にはセクション1.2を参照）にパラメーターを渡し、それらのサービスによって解釈されることを目的としています。 （対照的に、URNによって識別されたリソース、またはそのようなリソースを管理するアプリケーションにパラメーターを渡すことは、次のセクションで説明するようにqコンポーネントによって処理されます。）
The URN r-component has no syntactic counterpart in any other known URI scheme.
URN rコンポーネントには、他の既知のURIスキーマに構文上の対応物はありません。
The sequence "?+" introduces the r-component. The r-component ends with a "?=" sequence (which begins a q-component) or a "#" character (number sign, which begins an f-component). If neither of those appear, the r-component continues to the end of the URN. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986].
シーケンス「？+」は、r成分を導入します。 rコンポーネントは、「？=」シーケンス（qコンポーネントを開始）または「＃」文字（番号記号、fコンポーネントを開始）で終わります。どちらも表示されない場合、rコンポーネントはURNの最後まで続きます。 ASCII範囲[RFC20]の外の文字は、汎用URI仕様[RFC3986]のセクション2.1で定義された方法を使用してパーセントエンコードする必要があることに注意してください。
As described in Section 3, the r-component SHALL NOT be taken into account when determining URN-equivalence. However, the r-component SHALL be supplied along with the URN when presenting a request to a URN resolution service.
セクション3で説明されているように、URNと同等のものを決定するとき、rコンポーネントは考慮に入れられません。ただし、URN解決サービスに要求を提示するときは、r-componentをURNとともに提供する必要があります（SHALL）。
This document defines only the syntax of the r-component and reserves it for future use. The exact semantics of the r-component and its use in URN resolution protocols are a matter for potential standardization in separate specifications, presumably including specifications that define conventions and a registry for resolution service identifiers.
このドキュメントでは、rコンポーネントの構文のみを定義し、将来の使用のために予約します。 rコンポーネントの正確なセマンティクスとURN解決プロトコルでのその使用は、おそらく規則を定義する仕様と解決サービス識別子のレジストリを含む、個別の仕様での潜在的な標準化の問題です。
Consider the hypothetical example of passing parameters to a resolution service (say, an ISO alpha-2 country code [ISO.3166-1] in order to select the preferred country in which to search for a physical copy of a book). This could perhaps be accomplished by specifying the country code in the r-component, resulting in URNs such as:
パラメータを解決サービスに渡すという架空の例を考えてみます（たとえば、書籍の物理的なコピーを検索する優先国を選択するために、ISO alpha-2国コード[ISO.3166-1]）。これは、rコンポーネントで国コードを指定することによって実現でき、次のようなURNになります。
urn:example:foo-bar-baz-qux?+CCResolve:cc=uk
While the above should serve as a general explanation and illustration of the intent for r-components, there are many open issues with them, including their relationship to resolution mechanisms associated with the particular URN namespace at registration time. Thus, r-components SHOULD NOT be used for URNs before their semantics have been standardized.
上記は、rコンポーネントの意図の一般的な説明と図として役立つはずですが、登録時に特定のURN名前空間に関連付けられている解決メカニズムとの関係を含め、それらには多くの未解決の問題があります。したがって、セマンティクスが標準化される前に、URNにrコンポーネントを使用しないでください。
The q-component is intended for passing parameters to either the named resource or a system that can supply the requested service, for interpretation by that resource or system. (By contrast, passing parameters to URN resolution services is handled by r-components as described in the previous section.)
qコンポーネントは、指定されたリソースまたは要求されたサービスを提供できるシステムにパラメーターを渡し、そのリソースまたはシステムによる解釈を目的としています。 （対照的に、URN解決サービスへのパラメーターの受け渡しは、前のセクションで説明したように、rコンポーネントによって処理されます。）
The URN q-component has the same syntax as the URI query component but is introduced by "?=", not "?" alone. For a URN that may be resolved to a URI that is a locator, the semantics of the q-component are identical to those for the query component of that URI. Thus, URN resolvers returning a URI that is a locator for a URN with a q-component do this by copying the q-component from the URN to the query component of the URI. An example of the copying operation appears below.
URN q-componentの構文はURIクエリコンポーネントと同じですが、「？」ではなく「？=」によって導入されます。一人で。ロケーターであるURIに解決できるURNの場合、q-componentのセマンティクスは、そのURIのqueryコンポーネントのセマンティクスと同じです。したがって、q-componentを持つURNのロケーターであるURIを返すURNリゾルバーは、URNからURIのクエリコンポーネントにq-componentをコピーすることでこれを行います。コピー操作の例を以下に示します。
This specification does not specify a required behavior in the case of URN resolution to a URI that is a locator when the original URN has a q-component and the URI has a query string. Different circumstances may require different approaches. Resolvers SHOULD document their strategy in such cases.
この仕様では、元のURNにq-componentがあり、URIにクエリ文字列がある場合、ロケーターであるURIへのURN解決の場合に必要な動作を指定していません。異なる状況では異なるアプローチが必要になる場合があります。リゾルバーは、そのような場合の戦略を文書化する必要があります。
If the URN does not resolve to a URI that is a locator, the interpretation of the q-component is undefined by this specification. For URNs that may be resolved to a URI that is a locator, the semantics of the q-component are identical to those for queries to the resource located via that URI.
URNがロケーターであるURIに解決されない場合、qコンポーネントの解釈はこの仕様では定義されていません。ロケーターであるURIに解決される可能性のあるURNの場合、qコンポーネントのセマンティクスは、そのURIを介して検索されたリソースへのクエリのセマンティクスと同じです。
For the sake of consistency with RFC 3986, the general syntax and the semantics of q-components are not defined by, or dependent on, the URN namespace of the URN. In parallel with RFC 3986, specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular URN namespace or even a particular resource.
RFC 3986との整合性を保つため、q-componentの一般的な構文とセマンティクスは、URNのURN名前空間によって定義されたり、それに依存したりすることはありません。 RFC 3986と並行して、構文やセマンティクスの詳細（どのキーワードや用語が意味があるかなど）は、もちろん、特定のURN名前空間や特定のリソースに依存する場合があります。
The sequence "?=" introduces the q-component. The q-component ends with a "#" character (number sign, which begins an f-component). If that character does not appear, the q-component continues to the end of the URN. The characters slash ("/") and question mark ("?") may represent data within the q-component. Note that characters outside the ASCII range [RFC20] MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986].
シーケンス「？=」は、qコンポーネントを紹介します。 qコンポーネントは、「＃」文字（番号コンポーネント、fコンポーネントで始まる）で終わります。その文字が表示されない場合、qコンポーネントはURNの最後まで続きます。スラッシュ（「/」）と疑問符（「？」）は、qコンポーネント内のデータを表す場合があります。 ASCII範囲[RFC20]の外の文字は、汎用URI仕様[RFC3986]のセクション2.1で定義された方法を使用してパーセントエンコードする必要があることに注意してください。
As described in Section 3, the q-component SHALL NOT be taken into account when determining URN-equivalence.
セクション3で説明されているように、URNと同等のものを決定するとき、qコンポーネントは考慮に入れられません。
URN namespaces and associated information placement in syntax SHOULD be designed to avoid any need for a resolution service to consider the q-component. Namespace-specific and more generic resolution systems MUST NOT require that q-component information be passed to them for processing.
URNネームスペースおよび関連する情報の配置は、解決サービスがqコンポーネントを考慮する必要がないように設計する必要があります（SHOULD）。名前空間固有のより一般的な解決システムでは、処理のためにq-component情報を渡す必要はありません（MUST NOT）。
Consider the hypothetical example of passing parameters to an application that returns weather reports from different regions or for different time periods. This could perhaps be accomplished by specifying latitude and longitude coordinates and datetimes in the URN's q-component, resulting in URNs such as the following.
さまざまな地域またはさまざまな期間の天気予報を返すアプリケーションにパラメーターを渡すという架空の例を考えてみましょう。これはおそらく、URNのqコンポーネントで緯度と経度の座標と日時を指定することによって実現でき、次のようなURNが生成されます。
urn:example:weather?=op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
If this example resolved to an HTTP URI, the result might look like:
この例がHTTP URIに解決された場合、結果は次のようになります。
https://weatherapp.example?op=map&lat=39.56
&lon=-104.85&datetime=1969-07-21T02:56:15Z
The f-component is intended to be interpreted by the client as a specification for a location within, or region of, the named resource. It distinguishes the constituent parts of a resource named by a URN. For a URN that resolves to one or more locators that can be dereferenced to a representation, or where the URN resolver directly returns a representation of the resource, the semantics of an f-component are defined by the media type of the representation.
fコンポーネントは、クライアントによって、名前付きリソース内またはその領域の場所の仕様として解釈されることを目的としています。 URNで指定されたリソースの構成部分を区別します。表現に逆参照できる1つ以上のロケーターに解決するURN、またはURNリゾルバーがリソースの表現を直接返す場合、fコンポーネントのセマンティクスは、表現のメディアタイプによって定義されます。
The URN f-component has the same syntax as the URI fragment component. If a URN containing an f-component resolves to a single URI that is a locator associated with the named resource, the f-component from the URN can be applied (usually by the client) as the fragment of that URI. If the URN does not resolve to a URI that is a locator, the interpretation of the f-component is undefined by this specification. Thus, for URNs that may be resolved to a URI that is a locator, the semantics of f-components are identical to those of fragments for that resource.
URN fコンポーネントの構文は、URIフラグメントコンポーネントと同じです。 fコンポーネントを含むURNが名前付きリソースに関連付けられたロケーターである単一のURIに解決される場合、URNからのfコンポーネントは、そのURIのフラグメントとして（通常はクライアントによって）適用できます。 URNがロケーターであるURIに解決されない場合、fコンポーネントの解釈はこの仕様では定義されていません。したがって、ロケーターであるURIに解決できるURNの場合、fコンポーネントのセマンティクスは、そのリソースのフラグメントのセマンティクスと同じです。
For the sake of consistency with RFC 3986, neither the general syntax nor the semantics of f-components are defined by, or dependent on, the URN namespace of the URN. In parallel with RFC 3986, specifics of syntax and semantics, e.g., which keywords or terms are meaningful, of course may depend on a particular URN namespace or even a particular resource.
RFC 3986との一貫性を保つために、fコンポーネントの一般的な構文もセマンティクスも、URNのURN名前空間によって定義または依存されていません。 RFC 3986と並行して、構文やセマンティクスの詳細（どのキーワードや用語が意味があるかなど）は、もちろん、特定のURN名前空間や特定のリソースに依存する場合があります。
The f-component is introduced by the number sign ("#") character and terminated by the end of the URI. Any characters outside the ASCII range [RFC20] that appear in the f-component MUST be percent-encoded using the method defined in Section 2.1 of the generic URI specification [RFC3986].
fコンポーネントは、番号記号（ "＃"）文字で始まり、URIの終わりで終了します。 fコンポーネントに表示されるASCII範囲[RFC20]の外の文字は、汎用URI仕様[RFC3986]のセクション2.1で定義されている方法を使用してパーセントエンコードする必要があります。
As described in Section 3, the f-component SHALL NOT be taken into account when determining URN-equivalence.
セクション3で説明したように、URNと同等のものを決定するとき、f成分は考慮に入れられないものとします（SHALL）。
Clients SHOULD NOT pass f-components to resolution services unless those services also perform object retrieval and interpretation functions.
クライアントは、それらのサービスがオブジェクトの取得および解釈機能も実行しない限り、fサービスを解決サービスに渡すべきではありません（SHOULD NOT）。
Consider the hypothetical example of obtaining resources that are part of a larger entity (say, the chapters of a book). Each part could be specified in the f-component, resulting in URNs such as:
より大きなエンティティ（たとえば、本の章）の一部であるリソースを取得する架空の例を考えてみます。各部品はfコンポーネントで指定でき、次のようなURNになります。
urn:example:foo-bar-baz-qux#somepart
For various purposes such as caching, it is often desirable to determine if two URNs are "the same". This is done most generally (i.e., independent of the scheme) by testing for equivalence (see Section 6.1 of [RFC3986]).
キャッシングなどのさまざまな目的で、2つのURNが「同じ」かどうかを判断することが望ましい場合がよくあります。これは、同等性をテストすることにより、最も一般的に（つまり、スキームとは無関係に）行われます（[RFC3986]のセクション6.1を参照）。
The generic URI specification [RFC3986] is very flexible about equality comparisons, putting the focus on allowing false negatives and avoiding false positives. If comparisons are made in a scheme-independent way, i.e., as URI comparisons only, many URNs that this specification considers equal would be rejected. The discussion below applies when the URIs involved are known to be URNs and thus uses the terms "URN-equivalent" and "URN-equivalence" to refer to equivalence as specified in this document.
汎用URI仕様[RFC3986]は、等価比較に関して非常に柔軟性があり、偽陰性の許可と偽陽性の回避に重点を置いています。スキームに依存しない方法で比較が行われる場合、つまり、URI比較のみとして、この仕様が等しいと見なす多くのURNは拒否されます。以下の説明は、関係するURIがURNであることがわかっている場合に適用されるため、「URN同等」および「URN同等」という用語を使用して、このドキュメントで指定されている同等を指します。
Two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of [RFC3986]) to the following constructs:
2つのURNは、次の構成に大文字と小文字の正規化（[RFC3986]のセクション6.2.2.1で指定）を適用した後、名前の割り当て部分がオクテットごとに等しい場合、URNと同等です。
1. the URI scheme "urn", by conversion to lower case
1. 小文字への変換によるURIスキーム「urn」
2. the NID, by conversion to lower case
2. 小文字への変換によるNID
3. any percent-encoded characters in the NSS (that is, all character triplets that match the <pct-encoding> production found in Section 2.1 of the base URI specification [RFC3986]), by conversion to upper case for the digits A-F.
3. NSS内のパーセントでエンコードされた文字（つまり、ベースURI仕様[RFC3986]のセクション2.1にある<pct-encoding>プロダクションに一致するすべての文字トリプレット）。数字A〜Fを大文字に変換する。
Percent-encoded characters MUST NOT be decoded, i.e., percent-encoding normalization (as specified in Section 6.2.2.2 of [RFC3986]) MUST NOT be applied as part of the comparison process.
パーセントエンコードされた文字はデコードしてはいけません。つまり、パーセントエンコードの正規化（[RFC3986]のセクション6.2.2.2で指定）は、比較プロセスの一部として適用してはなりません。
If an r-component, q-component, or f-component (or any combination thereof) is included in a URN, it MUST be ignored for purposes of determining URN-equivalence.
r-component、q-component、またはf-component（またはそれらの任意の組み合わせ）がURNに含まれている場合、URNとの同等性を判断するために無視する必要があります。
URN namespace definitions MAY include additional rules for URN-equivalence, such as case insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not "the same" if the procedure here says they are URN-equivalent. For related considerations with regard to NID registration, see below.
URN名前空間の定義には、NSS（またはその一部）の大文字と小文字を区別しないなど、URNと同等の追加のルールを含めることができます（MAY）。そのようなルールは常に、上記の手順で得られたいくつかの偽陰性を排除する効果がなければならず、ここで手順がそれらがURNと同等であると言った場合、2つのURNを「同じではない」として処理してはなりません。 NID登録に関連する考慮事項については、以下を参照してください。
This section shows a variety of URNs (using the "example" NID defined in [RFC6963]) that highlight the URN-equivalence rules.
このセクションでは、URN同等ルールを強調するさまざまなURN（[RFC6963]で定義された「例」NIDを使用）を示します。
First, because the scheme and NID are case insensitive, the following three URNs are URN-equivalent to each other:
まず、スキームとNIDでは大文字と小文字が区別されないため、次の3つのURNは互いにURNと同等です。
o urn:example:a123,z456
o urn：example：a123、z456
o URN:example:a123,z456
o URN：例：a123、z456
o urn:EXAMPLE:a123,z456
o urn：EXAMPLE：a123、z456
Second, because the r-component, q-component, and f-component are not taken into account for purposes of testing URN-equivalence, the following three URNs are URN-equivalent to the first three examples above:
2つ目は、URNとの同等性をテストする目的でrコンポーネント、qコンポーネント、およびfコンポーネントが考慮されないため、次の3つのURNは、上記の最初の3つの例とURNと同等です。
o urn:example:a123,z456?+abc
o urn：example：a123、z456？+ abc
o urn:example:a123,z456?=xyz
o urn：example：a123、z456？= xyz
o urn:example:a123,z456#789
o urn：example：a123、z456＃789
Third, because the "/" character (and anything that follows it) in the NSS is taken into account for purposes of URN-equivalence, the following URNs are not URN-equivalent to each other or to the six preceding URNs:
3番目に、NSSの「/」文字（およびそれに続くもの）はURNと同等の目的で考慮されるため、以下のURNは、互いに、または先行する6つのURNとURNで同等ではありません。
o urn:example:a123,z456/foo
o urn：example：a123、z456 / foo
o urn:example:a123,z456/bar
o urn：example：a123、z456 / bar
o urn:example:a123,z456/baz
o urn：example：a123、z456 / baz
Fourth, because of percent-encoding, the following URNs are URN-equivalent only to each other and not to any of those above (note that, although %2C is the percent-encoded transformation of "," from the previous examples, such sequences are not decoded for purposes of testing URN-equivalence):
4番目に、パーセントエンコーディングのため、以下のURNは互いにのみ同等であり、上記のいずれのものとも同等ではありません（ただし、％2Cは、前の例の「、」のパーセントエンコード変換ですが、このようなシーケンスはURNと同等であることをテストする目的でデコードされません）：
o urn:example:a123%2Cz456
o urn：example：a123％2Cz456
o URN:EXAMPLE:a123%2cz456 Fifth, because characters in the NSS other than percent-encoded sequences are treated in a case-sensitive manner (unless otherwise specified for the URN namespace in question), the following URNs are not URN-equivalent to the first three URNs:
o URN：EXAMPLE：a123％2cz456第5に、パーセントエンコードされたシーケンス以外のNSS内の文字は大文字と小文字が区別される方法で処理されるため（問題のURN名前空間に特に指定されていない限り）、次のURNはURNと同等ではありません最初の3つのURN：
o urn:example:A123,z456
o urn：example：A123、z456
o urn:example:a123,Z456
o urn：example：a123、Z456
Sixth, on casual visual inspection of a URN presented in a human-oriented interface, the following URN might appear the same as the first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be confused with U+0061 LATIN SMALL LETTER A), but it is not URN-equivalent to the first three URNs:
6番目に、人間向けのインターフェースで提示されたURNのカジュアルな目視検査では、次のURNは最初の3つのURNと同じように見える可能性があります（U + 0430キリル文字AがU + 0061ラテン文字Aと混同される可能性があるため） 、しかしそれは最初の3つのURNに相当するURNではありません。
o urn:example:%D0%B0123,z456
o urn：example：％D0％B0123、z456
Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI (to name just a few, the "href" and "src" attributes in HTML, the base element in HTML, the "xml:base" attribute in XML [XML-BASE], and the "xmlns" attribute in XML for XML namespace names [XML-NAMES]).
URNは構文的には「urn」スキームの下のURIであるため、理論的には、URNはURIを許可する任意のプロトコルスロットに配置できます（ほんの数例を挙げると、HTMLの「href」属性と「src」属性、HTMLの基本要素、XMLの "xml：base"属性[XML-BASE]、およびXML名前空間名のXMLの "xmlns"属性[XML-NAMES]）。
However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource (e.g., the aforementioned "href" and "src" attributes).
ただし、これは意味的には、特定のURIプロトコルスロットにURNを配置することが常に意味をなすことを意味するものではありません。特に、URNはリソースの場所を指定しない場合や、リソースの場所を間接的に指す場合もあるので、リソースを指すURIプロトコルスロットにURNを配置することは適切ではない場合があります（たとえば、前述の「href」と「 src "属性）。
Ultimately, guidelines regarding when it is appropriate to use URIs under the "urn" scheme (or any other scheme) are the responsibility of specifications for individual URI protocol slots (e.g., the specification for the "xml:base" attribute in XML might recommend that it is inappropriate to use URNs in that protocol slot). This specification cannot possibly anticipate all of the relevant cases, and it is not the place of this specification to require or restrict usage for individual protocol slots.
最終的に、「urn」スキーム（またはその他のスキーム）でURIを使用するのが適切な場合に関するガイドラインは、個々のURIプロトコルスロットの仕様の責任です（たとえば、XMLの「xml：base」属性の仕様は、そのプロトコルスロットでURNを使用することは不適切です。この仕様は、関連するすべてのケースを予想することはできません。個々のプロトコルスロットの使用を要求または制限するのは、この仕様の場所ではありません。
In part because of the separation of URN semantics from more general URI syntax, generic URI processors need to pay special attention to the parsing and analysis rules of RFC 3986 and, in particular, must treat the URI as opaque unless the scheme and its requirements are recognized. In the latter case, such processors may be in a position to invoke scheme-appropriate processing, e.g., by a URN resolver. A URN resolver can either be an external resolver that the URI resolver knows of or be functionality built into the URI resolver. Note that this requirement might impose constraints on the contexts in which URNs are appropriately used; see Section 4.1.
URNセマンティクスがより一般的なURI構文から分離されているため、汎用URIプロセッサはRFC 3986の解析および分析ルールに特別な注意を払う必要があり、特に、スキームとその要件が満たされていない限り、URIを不透明として扱う必要があります。認識した。後者の場合、そのようなプロセッサは、例えば、ＵＲＮリゾルバによって、スキームに適切な処理を呼び出す立場にあるかもしれない。 URNリゾルバーは、URIリゾルバーが認識している外部リゾルバーでも、URIリゾルバーに組み込まれた機能でもかまいません。この要件は、URNが適切に使用されるコンテキストに制約を課す可能性があることに注意してください。セクション4.1を参照してください。
Section 5.2 of [RFC3986] describes an algorithm for converting a URI reference that might be relative to a given base URI into "parsed components" of the target of that reference, which can then be recomposed per RFC 3986, Section 5.3 into a target URI. This algorithm is problematic for URNs because their syntax does not support the necessary path components. However, if the algorithm is applied independent of a particular scheme, it should work predictably for URNs as well, with the following understandings (syntax production terminology taken from RFC 3986):
[RFC3986]のセクション5.2は、特定のベースURIに関連している可能性があるURI参照を、その参照のターゲットの「解析済みコンポーネント」に変換するアルゴリズムについて説明しています。これは、RFC 3986のセクション5.3に従ってターゲットURIに再構成できます。 。このアルゴリズムは、その構文が必要なパスコンポーネントをサポートしていないため、URNに問題があります。ただし、アルゴリズムが特定のスキームに関係なく適用される場合は、次の理解があれば、URNでも予測どおりに機能するはずです（RFC 3986から取られた構文生成用語）：
1. A system that encounters a <URI-reference> that obeys the syntax for <relative-ref>, whether it explicitly has the scheme "urn" or not, will convert it into a target URI as specified in RFC 3986.
1. スキーマ「urn」が明示的にあるかどうかに関係なく、<relative-ref>の構文に従う<URI-reference>に遭遇したシステムは、RFC 3986で指定されているターゲットURIに変換します。
2. Because of the persistence and stability expectations of URNs, authors of documents, etc., that utilize URNs should generally avoid the use of the "urn" scheme in any <URI-reference> that is not strictly a <URI> as specified in RFC 3986, specifically including those that would require processing of <relative-ref>.
2. URNの永続性と安定性の期待のため、URNを利用するドキュメントの作成者などは、RFCで指定されている<URI>以外の<URI-reference>での "urn"スキームの使用を通常は避ける必要があります。 3986、特に<relative-ref>の処理を必要とするものを含みます。
When URNs are transported and exchanged, they MUST be represented in the format defined herein. Further, URN-aware applications are strongly encouraged to offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by copy-and-paste techniques). Such applications might support the display of URNs in a more human-friendly form and might use a character set that includes characters that are not permitted in URN syntax as defined in this specification (e.g., when displaying URNs to humans, such applications might replace percent-encoded strings with characters from an extended character repertoire such as Unicode [UNICODE]).
URNが転送および交換されるとき、それらはここで定義されたフォーマットで表現されなければなりません（MUST）。さらに、URN対応のアプリケーションでは、直接的な転記を可能にするために、この正規形式でURNを表示するオプションを提供することを強くお勧めします（たとえば、コピーアンドペースト技術による）。そのようなアプリケーションは、より人間にやさしい形式でURNの表示をサポートし、この仕様で定義されているURN構文で許可されていない文字を含む文字セットを使用する場合があります（たとえば、URNを人間に表示する場合、そのようなアプリケーションはパーセントを置き換える可能性がありますUnicode [UNICODE]などの拡張文字レパートリーの文字を含む、エンコードされた文字列。
To minimize user confusion, any application displaying URIs SHOULD display the complete URI (including, for URNs, the "urn" scheme and any components) to ensure that there is no confusion between URN NIDs and URI scheme identifiers. For example, a URI beginning with "urn:xmpp:" [RFC4854] is very different from a URI beginning with "xmpp:" [RFC5122]. Similarly, a potential Digital Object Identifier (DOI) URI scheme [DOI-URI] is different from, and possibly completely unrelated to, a possible DOI URN namespace.
ユーザーの混乱を最小限に抑えるために、URIを表示するすべてのアプリケーションは、完全なURI（URNの場合は「urn」スキームとコンポーネントを含む）を表示して、URN NIDとURIスキーム識別子が混同しないようにする必要があります。たとえば、「urn：xmpp：」で始まるURI [RFC4854]は、「xmpp：」で始まるURI [RFC5122]とは大きく異なります。同様に、潜在的なデジタルオブジェクト識別子（DOI）URIスキーム[DOI-URI]は、可能なDOI URN名前空間とは異なり、DOI URNの名前空間とは完全に無関係である可能性があります。
As mentioned, the assignment of URNs within a URN namespace is a managed process, as is the assignment of URN namespaces themselves. Although design of the URNs to be assigned within a given URN namespace is ceded by this specification to the URN namespace manager, doing so in a managed way avoids the problems inherent in unmanaged generation of URIs as described in the recommendations regarding URI design and ownership [RFC7320].
前述のように、URN名前空間内でのURNの割り当ては、URN名前空間自体の割り当てと同様に、管理されたプロセスです。特定のURNネームスペース内で割り当てられるURNの設計は、この仕様によりURNネームスペースマネージャに委譲されますが、管理された方法で行うことで、URIの設計と所有権に関する推奨事項で説明されているように、URIのアンマネージド生成に固有の問題を回避できます。 RFC7320]。
A URN namespace is a collection of names that obey three constraints: each name is (1) unique, (2) assigned in a consistent way, and (3) assigned according to a common definition.
URN名前空間は、3つの制約に従う名前のコレクションです。各名前は、（1）一意、（2）一貫した方法で割り当てられ、（3）共通の定義に従って割り当てられます。
1. The "uniqueness" constraint means that a name within the URN namespace is never assigned to more than one resource and never reassigned to a different resource (for the kind of "resource" identified by URNs assigned within the URN namespace). This holds true even if the name itself is deprecated or becomes obsolete.
1. 「一意性」制約とは、URN名前空間内の名前が複数のリソースに割り当てられたり、別のリソースに再度割り当てられたりしないことを意味します（URN名前空間内で割り当てられたURNによって識別される「リソース」の種類の場合）。これは、名前自体が廃止されたり廃止されたりした場合でも当てはまります。
2. The "consistent assignment" constraint means that a name within the URN namespace is assigned by an organization or created in accordance with a process or algorithm that is always followed.
2. 「一貫した割り当て」制約とは、URN名前空間内の名前が組織によって割り当てられるか、常に従うプロセスまたはアルゴリズムに従って作成されることを意味します。
3. The "common definition" constraint means that there are clear definitions for the syntax of names within the URN namespace and for the process of assigning or creating them.
3. 「共通定義」制約は、URN名前空間内の名前の構文と、それらの割り当てまたは作成のプロセスに明確な定義があることを意味します。
A URN namespace is identified by a particular NID in order to ensure the global uniqueness of URNs and, optionally, to provide a cue regarding the structure of URNs assigned within a URN namespace.
URNのグローバルな一意性を確保し、オプションで、URN名前空間内で割り当てられたURNの構造に関する手掛かりを提供するために、URN名前空間は特定のNIDによって識別されます。
With regard to global uniqueness, using different NIDs for different collections of names ensures that no two URNs will be the same for different resources, because each collection is required to uniquely assign each name. However, a single resource MAY have more than one URN assigned to it, either in the same URN namespace (if the URN namespace permits it) or in different URN namespaces, and for either similar purposes or different purposes. (For example, if a publisher assigns an ISBN [RFC3187] to an electronic publication and that publication is later incorporated into a digital long-term archive operated by a national library, the library might assign the publication a national bibliography number (NBN) [RFC3188], resulting in two URNs referring to the same book.) Subject to other constraints, such as those imposed by the URI syntax [RFC3986], the rules of the URN scheme are intended to allow preserving the normal and natural form of names specified in non-URN identifier systems when they are treated as URNs.
グローバルな一意性に関して、名前のコレクションごとに異なるNIDを使用すると、コレクションごとに名前を一意に割り当てる必要があるため、リソースごとに2つのURNが同じになることはありません。ただし、単一のリソースには、同じURN名前空間（URN名前空間で許可されている場合）または異なるURN名前空間のいずれかで、同様の目的または異なる目的で、複数のURNが割り当てられている場合があります。 （たとえば、出版社がISBN [RFC3187]を電子出版物に割り当て、その出版物が後で国立図書館が運営するデジタル長期アーカイブに組み込まれた場合、図書館はその出版物に全国書誌番号（NBN）を割り当てます。 RFC3188]、その結果、2つのURNが同じ本を参照するようになります。）URI構文[RFC3986]によって課される制約などの他の制約に従い、URNスキーマの規則は、指定された名前の通常の自然な形式を維持できるようにすることを目的としています非URN識別子システムでは、URNとして扱われる場合。
With regard to the structure of names assigned within a URN namespace, the development of a naming structure (and thereby a collection of names) depends on the requirements of the community defining the names, how the names will be assigned and used, etc. These issues are beyond the scope of URN syntax and the general rules for URN namespaces, because they are specific to the community defining a non-URN identifier system or a particular URN namespace (e.g., the bibliographic and publishing communities in the case of the "ISBN" URN namespace [RFC3187] and the "ISSN" URN namespace [RFC3044] or the developers of extensions to the Extensible Messaging and Presence Protocol [RFC6120] in the case of the "XMPP" URN namespace [RFC4854]).
URNネームスペース内で割り当てられる名前の構造に関して、名前付け構造（および名前のコレクション）の開発は、名前を定義するコミュニティの要件、名前の割り当て方法および使用方法などに依存します。問題は、URN構文の範囲およびURN名前空間の一般的なルールの範囲外です。これは、非URN識別子システムまたは特定のURN名前空間を定義するコミュニティに固有であるためです（たとえば、「ISBNの場合は書誌および出版コミュニティ」 "URNネームスペース[RFC3187]および" ISSN "URNネームスペース[RFC3044]または" XMPP "URNネームスペース[RFC4854]の場合の拡張メッセージングおよびプレゼンスプロトコル[RFC6120]の拡張の開発者）。
Because the colon character (":") is used to separate "urn" from the NID and the NID from the NSS, it's tempting to think of the entire URN as being structured by colon characters and to assume that colons create a structure or hierarchy within the NSS portion of the URN. Such structure could be specified by a particular NID specification, but there is no implicit structure. In a URN such as
コロン文字（ "："）はNIDから "urn"とNSSからNIDを区切るために使用されるため、URN全体をコロン文字で構成されていると考え、コロンが構造または階層を作成すると想定するのは魅力的です。 URNのNSS部分内。このような構造は特定のNID仕様で指定できますが、暗黙の構造はありません。次のようなURN内
urn:example:apple:pear:plum:cherry
the NSS string is "apple:pear:plum:cherry" as a whole, and there is no specific meaning to the colon characters within that NSS string unless such meaning is described in the specification of the "example" namespace.
NSS文字列は全体として「apple：pear：plum：cherry」であり、「example」名前空間の仕様でそのような意味が説明されていない限り、そのNSS文字列内のコロン文字に特定の意味はありません。
URN namespaces inherit certain rights and responsibilities by the nature of URNs, in particular:
URN名前空間は、URNの性質により、特定の権利と責任を継承します。特に、次のとおりです。
1. They uphold the general principles of a well-managed URN namespace by providing persistent identification of resources and unique assignment of names in accordance with a common definition.
1. 彼らは、共通の定義に従ってリソースの永続的な識別と名前の一意の割り当てを提供することにより、適切に管理されたURN名前空間の一般原則を支持します。
2. Optionally, they can be registered in global registration services such as those described in [RFC2483].
2. オプションで、[RFC2483]で説明されているようなグローバル登録サービスに登録できます。
There are two types of URN namespaces: formal and informal. These are distinguished by the expected level of service, the information needed to define the URN namespace, and the procedures for registration. Because the majority of the URN namespaces registered so far have been formal, this document concentrates on formal URN namespaces.
URNネームスペースには、公式と非公式の2つのタイプがあります。これらは、期待されるサービスのレベル、URN名前空間を定義するために必要な情報、および登録の手順によって区別されます。これまでに登録されたURN名前空間の大部分は正式なものであるため、このドキュメントでは正式なURN名前空間に焦点を当てています。
A formal URN namespace provides benefit to some subset of users on the Internet. In particular, it would not make sense for a formal URN namespace to be used only by a community or network that is not connected to the Internet. For example, it would be inappropriate for a URN namespace to effectively force someone to use a proprietary network or service not open to the general Internet user. The intent is that, while the community of those who might actively use the URNs assigned within that URN namespace might be small, the potential use of names within that URN namespace is open to any user on the Internet. Formal URN namespaces might be appropriate even when some aspects are not fully open. For example, a URN namespace might make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the URN namespace. However, it might still benefit some Internet users if the associated services have openly published names.
正式なURN名前空間は、インターネット上の一部のユーザーにメリットをもたらします。特に、正式なURN名前空間を、インターネットに接続されていないコミュニティまたはネットワークだけが使用することは意味がありません。たとえば、URN名前空間が、一般のインターネットユーザーには公開されていない専用のネットワークまたはサービスを使用するように強制することは不適切です。その意図は、そのURN名前空間内で割り当てられたURNを積極的に使用する可能性のあるコミュニティは小さいかもしれませんが、そのURN名前空間内での名前の潜在的な使用は、インターネット上のすべてのユーザーに開かれているということです。一部の側面が完全に開いていない場合でも、正式なURN名前空間が適切な場合があります。たとえば、URN名前空間では、URN名前空間でのURNの割り当てに、有料の、個人的に管理された、または独自のレジストリを使用できます。ただし、関連するサービスが公開された名前を持っている場合は、一部のインターネットユーザーにメリットがある可能性があります。
An organization that will assign URNs within a formal URN namespace SHOULD meet the following criteria:
正式なURN名前空間内でURNを割り当てる組織は、次の基準を満たす必要があります。
1. Organizational stability and the ability to maintain the URN namespace for a long time; absent such evidence, it ought to be clear how the URN namespace can remain viable if the organization can no longer maintain the URN namespace.
1. 組織の安定性とURN名前空間を長期間維持する機能。そのような証拠がない場合、組織がURN名前空間を維持できなくなった場合に、URN名前空間がどのように存続できるかを明確にする必要があります。
2. Competency in URN assignment. This will improve the likelihood of persistence (e.g., to minimize the likelihood of conflicts).
2. URN割り当てのコンピテンシー。これにより、永続化の可能性が向上します（たとえば、競合の可能性を最小限に抑えるため）。
3. Commitment to not reassigning existing URNs and to allowing old URNs to continue to be valid (e.g., if the assignee of a URN is no longer a member or customer of the assigning organization, if various information about the assignee or named entity happens to change, or even if the assignee or the named entity itself is no longer in existence; in all these cases, the URN is still valid).
3. 既存のURNを再割り当てしないこと、および古いURNが引き続き有効であることを許可することへのコミットメント（たとえば、URNの譲受人が譲渡組織のメンバーまたは顧客ではなくなった場合、譲受人または指名エンティティに関するさまざまな情報が変更された場合）または、譲受人または名前付きエンティティ自体が存在しなくなった場合でも、これらすべてのケースでURNは有効です）。
A formal URN namespace establishes a particular NID, subject to the following constraints (above and beyond the syntax rules already specified):
正式なURNネームスペースは、特定のNIDを確立します。次の制約に従います（すでに指定されている構文規則の範囲を超えています）。
1. It MUST NOT be an already-registered NID.
1. すでに登録されているNIDであってはなりません。
2. It MUST NOT start with "urn-" (which is reserved for informal URN namespaces).
2. 「urn-」（非公式のURNネームスペース用に予約されています）で始めてはいけません。
3. It MUST be more than two characters long, and it MUST NOT start with ALPHA ALPHA "-", i.e., any string consisting of two letters followed by one hyphen; such strings are reserved for potential use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for eventual national registrations of URN namespaces (however, the definition and scoping of rules for allocation of responsibility for such country-code-based URN namespaces are beyond the scope of this document). As a consequence, it MUST NOT start with the string "xn--" or any other string consisting of two letters followed by two hyphens; such strings are reserved for potential representation of DNS A-labels and similar strings in the future [RFC5890].
3. 2文字以上である必要があり、ALPHA ALPHA "-"で開始することはできません。つまり、2つの文字とそれに続く1つのハイフンで構成される文字列です。そのような文字列は、URN名前空間の最終的な全国登録のためのISO alpha-2国コード[ISO.3166-1]に基づくNIDとしての潜在的な使用のために予約されています（ただし、そのような国コードの責任の割り当てに関する規則の定義とスコープ）ベースのURN名前空間は、このドキュメントの範囲外です。結果として、文字列「xn--」または2つの文字とそれに続く2つのハイフンで構成されるその他の文字列で開始してはなりません。そのような文字列は、将来DNS Aラベルおよび類似の文字列を表す可能性があるために予約されています[RFC5890]。
4. It MUST NOT start with the string "X-" so that it will not be confused with or conflict with any experimental URN namespace previously permitted by [RFC3406].
4. [RFC3406]で以前に許可されていた実験的なURN名前空間と混同したり、競合したりしないように、文字列「X-」で始めてはなりません。
Applicants and reviewers considering new NIDs should also be aware that they may have semantic implications and hence be a source of conflict. Particular attention should be paid to strings that might be construed as identifiers for, or registered under the authority of, countries (including ISO 3166-1 alpha-3 codes) and to strings that might imply association with existing URI schemes, non-URN identifier systems, or trademarks. However, in line with traditional policies, disputes about "ownership" of particular strings are disagreements among the parties involved; neither IANA nor the IETF will become involved in such disputes except in response to orders from a court of competent jurisdiction.
新しいNIDを検討している申請者とレビューアは、それらが意味的に影響を与える可能性があり、したがって競合の原因となる可能性があることも認識しておく必要があります。国の識別子として解釈されたり、国の権限の下で登録されたりする可能性のある文字列（ISO 3166-1 alpha-3コードを含む）、および既存のURIスキームとの関連を示唆する可能性のある文字列、非URN識別子には特に注意を払う必要がありますシステム、または商標。ただし、従来のポリシーと同様に、特定の文字列の「所有権」に関する紛争は、関係する当事者間の意見の相違です。 IANAもIETFも、管轄権のある裁判所からの命令に応じる場合を除き、このような紛争に関与することはありません。
Informal URN namespaces are full-fledged URN namespaces, with all the associated rights and responsibilities. Informal URN namespaces differ from formal URN namespaces in the process for assigning the NID: for an informal URN namespace, the registrant does not designate the NID; instead, IANA assigns the NID consisting of the string "urn-" followed by one or more digits (e.g., "urn-7") where the digits consist of the next available number in the sequence of positive integers assigned to informal URN namespaces. Thus, the syntax of an informal URN namespace identifier is:
非公式のURN名前空間は、すべての関連する権利と責任を持つ、本格的なURN名前空間です。非公式のURN名前空間は、NIDを割り当てるプロセスにおいて公式のURN名前空間とは異なります。非公式のURN名前空間の場合、登録者はNIDを指定しません。代わりに、IANAは、文字列 "urn-"とそれに続く1つ以上の数字（ "urn-7"など）で構成されるNIDを割り当てます。ここで、数字は、非公式のURN名前空間に割り当てられた正の整数のシーケンスで次に利用可能な数字で構成されます。したがって、非公式のURN名前空間識別子の構文は次のとおりです。
InformalNamespaceName = "urn-" Number
Number = DigitNonZero 0*Digit
DigitNonZero = "1"/ "2" / "3" / "4"/ "5"
/ "6" / "7" / "8" / "9"
Digit = "0" / DigitNonZero
The only restrictions on <Number> are that it (1) consist strictly of ASCII digits, (2) not have leading zeros, and (3) not cause the NID to exceed the length limitations defined for the URN syntax (see Section 2).
<Number>の唯一の制限は、（1）厳密にASCII数字で構成されている、（2）先頭にゼロがない、（3）NIDがURN構文に定義されている長さ制限を超えないことです（セクション2を参照）。 。
Because the space of URN namespaces is itself managed, the definition of a URN namespace SHOULD pay particular attention to:
URNネームスペースのスペースはそれ自体が管理されるため、URNネームスペースの定義は次のことに特に注意する必要があります。
1. The purpose of the URN namespace.
1. URN名前空間の目的。
2. The syntax of URNs assigned within the URN namespace, including the internal syntax and anticipated effects of r-components or q-components. (The syntax and interpretation of f-components are defined in RFC 3986.)
2. URN名前空間内で割り当てられたURNの構文。r-componentsまたはq-componentsの内部構文と予想される影響を含みます。 （f-コンポーネントの構文と解釈はRFC 3986で定義されています。）
3. The process for assigning URNs within the URN namespace.
3. URN名前空間内でURNを割り当てるプロセス。
4. The security implications of assigning URNs within the URN namespace and of using the assigned URNs.
4. URN名前空間内でURNを割り当てること、および割り当てられたURNを使用することのセキュリティへの影響。
5. Any potential interoperability issues with URNs assigned within the URN namespace.
5. URN名前空間内で割り当てられたURNとの潜在的な相互運用性の問題。
6. Optionally, the process for resolving URNs assigned within the URN namespace.
6. 必要に応じて、URN名前空間内で割り当てられたURNを解決するプロセス。
The section on completing the template (Section 6.4) explains these matters in greater detail. Although the registration templates are the same in all cases, slightly different procedures are used depending on the source of the registration.
テンプレートの完成に関するセクション（セクション6.4）では、これらの問題について詳しく説明しています。登録テンプレートはすべての場合で同じですが、登録のソースに応じて少し異なる手順が使用されます。
The basic registration policy for URN namespaces is Expert Review as defined in the IANA Considerations document [RFC5226]. For URN namespaces or their definitions that are intended to become standards or constituent parts of standards, the output of the Expert Review process is intended to be a report rather than instructions to IANA to take action (see below). The key steps are:
URN名前空間の基本的な登録ポリシーは、IANAの考慮事項ドキュメント[RFC5226]で定義されているExpert Reviewです。標準または標準の構成要素になることを目的としたURN名前空間またはその定義の場合、エキスパートレビュープロセスの出力は、アクションを実行するためのIANAへの指示ではなく、レポートを目的としています（以下を参照）。主な手順は次のとおりです。
1. Fill out the URN namespace registration template (see Section 6.4 and Appendix A). This can be done as part of an Internet-Draft or a specification in another series, although that is not a requirement.
1. URNネームスペース登録テンプレートに入力します（セクション6.4および付録Aを参照）。これは、必須ではありませんが、インターネットドラフトまたは別のシリーズの仕様の一部として行うことができます。
2. Send the completed template to the urn@ietf.org discussion list for review.
2. 完成したテンプレートをurn@ietf.orgディスカッションリストに送信して確認してください。
3. If necessary to address comments received, repeat steps 1 and 2.
3. 受け取ったコメントに対処する必要がある場合は、ステップ1と2を繰り返します。
4. If the Designated Experts approve the request and no standardization action is involved, the IANA will register the requested NID. If standardization is anticipated, the Designated Experts will prepare a report and forward it to the appropriate standards approval body (the IESG in the case of the IETF); IANA will register the requested NID only after receiving directions from that body and a copy of the Expert Review report.
4. 指定専門家が要求を承認し、標準化アクションが含まれていない場合、IANAは要求されたNIDを登録します。標準化が予想される場合、指定専門家はレポートを作成し、それを適切な標準承認機関（IETFの場合はIESG）に転送します。 IANAは、その機関からの指示とExpert Reviewレポートのコピーを受け取った後にのみ、要求されたNIDを登録します。
A URN namespace registration can be revised by updating the registration template, following the same steps outlined above for new registrations. A revised registration MUST describe differences from prior versions and SHOULD make special note of any relevant changes in the underlying technologies or URN namespace management processes.
URN名前空間の登録は、登録テンプレートを更新して、新しい登録について上記で概説したのと同じ手順に従って改訂できます。改訂された登録は、以前のバージョンとの違いを記述しなければならず（MUST）、基礎となるテクノロジーまたはURN名前空間管理プロセスの関連する変更について特別な注意を払う必要があります。
Experience to date with URN namespace registration requests has shown that registrants sometimes do not initially understand some of the subtleties of URN namespaces and that defining the URN namespace in the form of a specification enables the registrants to clearly formulate their "contract" with the intended user community. Therefore, although the registration policy for formal URN namespaces is Expert Review and a specification (as distinct from the registration template) is not strictly required, registrants SHOULD provide a stable specification documenting the URN namespace definition and expanding upon the issues described herein.
これまでのURN名前空間登録リクエストの経験から、登録者は最初はURN名前空間の微妙な点の一部を理解していないことがあり、URN名前空間を仕様の形式で定義すると、登録者は目的のユーザーとの「契約」を明確に形成できることがわかりましたコミュニティ。したがって、正式なURN名前空間の登録ポリシーはエキスパートレビューであり、（登録テンプレートとは異なる）仕様は厳密には必要ありませんが、登録者は、URN名前空間の定義を文書化し、ここで説明する問題を拡張する安定した仕様を提供する必要があります。
Because naming can be difficult and contentious, URN namespace registrants and the Designated Experts are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus (see [RFC7282]) on handling registration requests. They are also encouraged to bring additional expertise into the discussion if that would be helpful in providing perspective or otherwise resolving issues.
命名は困難で論争の的となる可能性があるため、URN名前空間登録者とDesignated Expertsは、登録要求の処理に関して大まかなコンセンサス（[RFC7282]を参照）を達成するために、誠意と相互理解の精神で協力することを強く推奨します。また、パースペクティブの提供や問題の解決に役立つ場合は、ディスカッションに専門知識を追加することをお勧めします。
Especially when iterations in the registration process are prolonged, Designated Experts are expected to take reasonable precautions to avoid "race conditions" on proposed NIDs and, if such situations arise, to encourage applicants to work out any conflicts among themselves.
特に、登録プロセスの反復が長引く場合、指定された専門家は、提案されたNIDの「競合状態」を回避するために妥当な予防策を講じ、そのような状況が発生した場合、申請者同士の競合を解決するよう奨励します。
6.3. Registration Policy and Process: Fast Track for Standards Development Organizations, Scientific Societies, and Similar Bodies
6.3. 登録ポリシーとプロセス：標準化開発組織、科学協会、および類似の団体のファストトラック
The IETF recognizes that situations will arise in which URN namespaces will be created to either embed existing and established standards, particularly identifier standards, or reflect knowledge, terminology, or methods of organizing information that lie well outside the IETF's scope or the likely subject matter knowledge of its Designated Experts. In situations in which the registration request originates from, or is authorized by, a recognized standards development organization, scientific society, or their designees, a somewhat different procedure is available at the option of that body:
IETFは、既存の確立された標準、特に識別子標準を組み込むため、またはIETFの範囲外にある情報、または対象となる可能性のある主題の知識を整理する知識、用語、または方法を反映するためにURN名前空間が作成される状況が発生することを認識しています指定された専門家の。登録要求が、承認された標準策定組織、科学協会、またはそれらの被指名人から発せられた、または承認された状況では、その機関のオプションでやや異なる手順を利用できます。
1. The URN namespace registration template is filled out and submitted as in steps 1 and 2 of Section 6.2.
1. セクション6.2のステップ1および2のように、URN名前空間登録テンプレートに入力して送信します。
2. A specification is required that reflects or points to the needed external standards or specifications. Publication in the RFC Series or through an IETF process (e.g., posting as an Internet-Draft) is not expected and would be appropriate only under very unusual circumstances.
2. 必要な外部規格または仕様を反映または指す仕様が必要です。 RFCシリーズでの公開またはIETFプロセス（インターネットドラフトとしての投稿など）による公開は予期されておらず、非常に異常な状況でのみ適切です。
3. The reviews on the discussion list and by the Designated Experts are strictly advisory, with the decisions about what advice to accept and the length of time to allocate to the process strictly under the control of the external body.
3. ディスカッションリストおよび指定専門家によるレビューは、厳密に助言であり、受け入れるべきアドバイスや、外部機関の管理下でプロセスに割り当てる時間の長さに関する決定を行います。
4. When that body concludes that the application is sufficiently mature, its representative(s) will request that IANA complete the registration for the NID, and IANA will do so.
4. その機関がアプリケーションが十分に成熟していると結論付けると、その代表者はIANAにNIDの登録を完了するよう要求し、IANAはそうします。
Decisions about whether to recognize the requesting entity as a standards development organization or scientific society are the responsibility of the IESG.
要求しているエンティティを標準策定組織として認識するか科学社会として認識するかについての決定は、IESGの責任です。
A model similar to this has already been defined for recognized standards development organizations that wish to register media types. The document describing that mechanism [RFC6838] provides somewhat more information about the general approach.
これと同様のモデルは、メディアタイプを登録することを希望する認められた標準開発組織のためにすでに定義されています。そのメカニズムを説明するドキュメント[RFC6838]は、一般的なアプローチについての情報をいくらか提供しています。
A template for defining and registering a URN namespace is provided in Appendix A. This section describes considerations for completing the template.
URNネームスペースを定義および登録するためのテンプレートは、付録Aにあります。このセクションでは、テンプレートを完了するための考慮事項について説明します。
The "Purpose" section of the template describes matters such as:
テンプレートの「目的」セクションでは、次のような事項について説明しています。
1. The kinds of resources identified by URNs assigned within the URN namespace.
1. URN名前空間内で割り当てられたURNによって識別されるリソースの種類。
2. The scope and applicability of the URNs assigned within the URN namespace; this might include information about the community of use (e.g., a particular nation, industry, technology, or organization), whether the assigned URNs will be used on public networks or private networks, etc.
2. URN名前空間内で割り当てられたURNのスコープと適用性。これには、使用するコミュニティ（特定の国、産業、テクノロジー、組織など）、割り当てられたURNがパブリックネットワークで使用されるかプライベートネットワークで使用されるかなどの情報が含まれる場合があります。
3. How the intended community (and the Internet community at large) will benefit from using or resolving the assigned URNs.
3. 割り当てられたURNを使用または解決することにより、対象となるコミュニティ（およびインターネットコミュニティ全体）がどのように役立つか。
4. How the URN namespace relates to and complements existing URN namespaces, URI schemes, and non-URN identifier systems.
4. URNネームスペースが既存のURNネームスペース、URIスキーム、および非URN識別子システムにどのように関連し、補足するか。
5. The kinds of software applications that can use or resolve the assigned URNs (e.g., by differentiating among disparate URN namespaces, identifying resources in a persistent fashion, or meaningfully resolving and accessing services associated with the URN namespace).
5. 割り当てられたURNを使用または解決できるソフトウェアアプリケーションの種類（たとえば、異種のURN名前空間を区別する、永続的な方法でリソースを識別する、またはURN名前空間に関連付けられているサービスを有意義に解決してアクセスするなど）。
6. Whether resolution services are available or will be available (and, if so, the nature or identity of the services). Examples of q-component and (when they are standardized) r-component semantics and syntax are helpful here, even if detailed definitions are provided elsewhere or later.
6. 解決サービスを利用できるか、利用できるか（利用できる場合は、サービスの性質またはID）。詳細な定義が他の場所や後で提供されている場合でも、qコンポーネントと（標準化されている場合）rコンポーネントのセマンティクスと構文の例がここで役立ちます。
7. Whether the URN namespace or its definition is expected to become a constituent part of a standard being developed in the IETF or some other recognized standards body.
7. URN名前空間またはその定義が、IETFまたはその他の認められた標準化団体で開発されている標準の構成要素になることが期待されるかどうか。
The "Syntax" section of the template contains:
テンプレートの「構文」セクションには以下が含まれます。
1. A description of the structure of URNs within the URN namespace, in conformance with the fundamental URN syntax. The structure might be described in terms of a formal definition (e.g., using ABNF [RFC5234]), an algorithm for generating conformant URNs, or a regular expression for parsing the name into constituent parts; alternatively, the structure might be opaque.
1. 基本的なURN構文に準拠した、URN名前空間内のURNの構造の説明。構造は、正式な定義（ABNF [RFC5234]を使用するなど）、適合URNを生成するためのアルゴリズム、または名前を構成部分に解析するための正規表現の観点から説明できます。または、構造が不透明な場合があります。
2. Any special character encoding rules for assigned URNs (e.g., which character ought to always be used for quotes).
2. 割り当てられたURNの特殊な文字エンコードルール（たとえば、引用符として常に使用する必要がある文字）。
3. Rules for determining URN-equivalence between two names in the URN namespace. Such rules ought to always have the effect of eliminating false negatives that might otherwise result from comparison. If it is appropriate and helpful, reference can be made to particular equivalence rules defined in the URI specification [RFC3986] or to Section 3 of this document. Examples of URN-equivalence rules include equivalence between uppercase and lowercase characters in the NSS, between hyphenated and non-hyphenated groupings in the name, or between single quotes and double quotes. There may also be namespace-specific special encoding considerations, especially for URNs that contain embedded forms of names from non-URN identifier systems. (Note that these are not normative statements for any kind of best practice related to handling of relationships between characters in general; such statements are limited to one particular URN namespace only.)
3. URNネームスペース内の2つの名前間のURN等価を決定するためのルール。このようなルールは、比較の結果として生じる可能性がある偽陰性を排除する効果を常に持っているべきです。それが適切で役立つ場合は、URI仕様[RFC3986]で定義されている特定の同等性ルールまたはこのドキュメントのセクション3を参照できます。 URN等価ルールの例には、NSS内の大文字と小文字の間、名前のハイフン付きグループとハイフンなしグループの間、または一重引用符と二重引用符の間の等価性が含まれます。特に非URN識別子システムからの名前の埋め込み形式を含むURNの場合は特に、名前空間固有の特別なエンコーディングの考慮事項がある場合があります。 （これらは、一般的な文字間の関係の処理に関連するあらゆる種類のベストプラクティスの規範的なステートメントではないことに注意してください。このようなステートメントは、特定の1つのURN名前空間のみに限定されます。）
4. Any special considerations necessary for conforming with the URN syntax. This is particularly applicable in the case of existing, non-URN identifier systems that are used in the context of URNs. For example, if a non-URN identifier system is used in contexts other than URNs, it might make use of characters that are reserved in the URN syntax. This section ought to note any such characters and outline necessary mappings to conform to URN syntax. Normally, this will be handled by percent-encoding the character as specified in Section 2.1 of the URI specification [RFC3986] and as discussed in Section 1.2.2 of this specification.
4. URN構文に準拠するために必要な特別な考慮事項。これは、URNのコンテキストで使用される既存の非URN識別子システムの場合に特に当てはまります。たとえば、非URN識別子システムがURN以外のコンテキストで使用されている場合、URN構文で予約されている文字を使用する可能性があります。このセクションでは、そのような文字に注意し、URN構文に準拠するために必要なマッピングの概要を説明します。通常、これは、URI仕様[RFC3986]のセクション2.1で指定され、この仕様のセクション1.2.2で説明されているように、文字をパーセントエンコードすることで処理されます。
5. Any special considerations for the meaning of q-components (e.g., keywords) or f-components (e.g., predefined terms) in the context of this URN namespace.
5. このURN名前空間のコンテキストにおけるqコンポーネント（たとえば、キーワード）またはfコンポーネント（たとえば、事前定義された用語）の意味に関する特別な考慮事項。
The "Assignment" section of the template describes matters such as:
テンプレートの「割り当て」セクションでは、次のような事項について説明します。
1. Mechanisms or authorities for assigning URNs to resources. It ought to make clear whether assignment is completely open (e.g., following a particular procedure such as first-come, first-served (FCFS)), completely closed (e.g., for a private organization), or limited in various ways (e.g., delegated to authorities recognized by a particular organization); if limited, it ought to explain how to become an assigner of names or how to request assignment of names from existing assignment authorities.
1. URNをリソースに割り当てるメカニズムまたは権限。割り当てが完全に開いているか（たとえば、先着順（FCFS）などの特定の手順に従って）、完全に閉じているか（たとえば、民間組織の場合）、またはさまざまな方法で制限されているか（たとえば、特定の組織によって承認された当局に委任された）;制限されている場合は、名前の割り当て者になる方法、または既存の割り当て機関に名前の割り当てを要求する方法を説明する必要があります。
2. Methods for ensuring that URNs within the URN namespace are unique. For example, names might be assigned sequentially or in accordance with some well-defined process by a single authority, assignment might be partitioned among delegated authorities that are individually responsible for respecting uniqueness rules, or URNs might be created independently following an algorithm that itself guarantees uniqueness.
2. URN名前空間内のURNが一意であることを確認するためのメソッド。たとえば、名前が順番に割り当てられたり、明確なプロセスに従って単一の機関によって割り当てられたり、割り当てが、一意性ルールの尊重を個別に担当する委任された機関間で分割されたり、URN自体が保証するアルゴリズムに従って独立して作成されたりする場合があります。独自性。
The "Security and Privacy" section of the template describes any potential issues related to security and privacy with regard to assignment, use, and resolution of names within the URN namespace. Examples of such issues include:
テンプレートの「セキュリティとプライバシー」セクションでは、URN名前空間内の名前の割り当て、使用、解決に関するセキュリティとプライバシーに関連する潜在的な問題について説明します。このような問題の例は次のとおりです。
o The consequences of producing false negatives and false positives during comparison for URN-equivalence (see Section 3.1 of this specification and "Issues in Identifier Comparison for Security Purposes" [RFC6943]).
o URNとの同等性の比較中に偽陰性と偽陽性を生成することの結果（この仕様のセクション3.1と「セキュリティ目的の識別子比較の問題」[RFC6943]を参照）。
o Leakage of private information when names are communicated on the public Internet.
o 名前が公衆インターネット上で伝達されるときの個人情報の漏洩。
o The potential for directory harvesting.
o ディレクトリ収集の可能性。
o Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. In particular, note the privacy considerations text for the Global System for Mobile Communications Association (GSMA) / International Mobile station Equipment Identity (IMEI) namespace [RFC7254], which may provide a useful model for such cases.
o RFC [RFC3552]のセキュリティに関する考慮事項のガイドラインとインターネットプロトコル[RFC6973]のプライバシーに関する考慮事項で説明されているさまざまな問題。特に、Mobile Communications Association（GSMA）/ International Mobile Station Equipment Identity（IMEI）名前空間[RFC7254]のプライバシーに関する考慮事項のテキストに注意してください。これは、このような場合に役立つモデルを提供します。
The "Interoperability" section MUST specify any known potential issues related to interoperability. Examples include possible confusion with other URN namespaces, non-URN identifier systems, or URI schemes because of syntax (e.g., percent-encoding of certain characters) or scope (e.g., overlapping areas of interest). If at all possible, concerns that arise during the registration of a URN namespace (e.g., due to the syntax or scope of a non-URN identifier system) should be resolved as part of or in parallel to the registration process.
「相互運用性」セクションでは、相互運用性に関する既知の潜在的な問題を指定する必要があります。例としては、構文（特定の文字のパーセントエンコーディングなど）またはスコープ（関心のある領域の重複など）が原因で、他のURN名前空間、非URN識別子システム、またはURIスキームと混同される可能性があります。可能であれば、URN名前空間の登録中に発生する問題（たとえば、非URN識別子システムの構文またはスコープが原因）は、登録プロセスの一部として、または並行して解決する必要があります。
The "Resolution" section MUST specify whether resolution mechanisms are intended or anticipated for URNs assigned within the URN namespace.
「解決」セクションでは、解決メカニズムがURN名前空間内で割り当てられたURNに対して意図されているか、予期されるかを指定する必要があります。
If resolution is intended, then this section SHOULD specify whether the organization that assigns URNs within the URN namespace intends to operate or recommend any resolution services for URNs within that URN namespace. In addition, if the assigning organization intends to implement registration for publicly advertised resolution services (for example, using a system developed in the spirit of the original architectural principles and service descriptions for URN resolution [RFC2276] [RFC2483]), then this section SHOULD list or reference the requirements for being publicly advertised by the assigning organization. In addition, this section SHOULD describe any special considerations for the handling of r-components in the context of this URN namespace.
解決が意図されている場合、このセクションでは、URN名前空間内でURNを割り当てる組織が、そのURN名前空間内のURNの解決サービスを運用または推奨するかどうかを指定する必要があります（SHOULD）。さらに、割り当て組織が公に公表された解決サービスの登録を実装する予定の場合（たとえば、URN解決[RFC2276] [RFC2483]の元のアーキテクチャの原則とサービスの説明の精神で開発されたシステムを使用して）、このセクションは割り当て組織によって公に宣伝されるための要件をリストまたは参照します。さらに、このセクションでは、このURN名前空間のコンテキストでのrコンポーネントの処理に関する特別な考慮事項について説明する必要があります（SHOULD）。
The "Additional Information" section includes information that would be useful to those trying to understand this registration or its relationship to other registrations, such as comparisons to existing URN namespaces that might seem to overlap.
「追加情報」セクションには、この登録または他の登録との関係を理解しようとする人に役立つ情報が含まれています。たとえば、重複しているように見える既存のURN名前空間との比較などです。
This section of the template is optional.
テンプレートのこのセクションはオプションです。
This section updates the registration of the "urn" URI scheme in the Permanent URI Registry [URI-Registry].
このセクションでは、永続URIレジストリ[URI-Registry]の「urn」URIスキームの登録を更新します。
URI Scheme Name: urn
URIスキーム名：urn
Status: permanent
ステータス：永続的
URI Scheme Syntax: See Section 2 of RFC 8141.
URIスキームの構文：RFC 8141のセクション2をご覧ください。
URI Scheme Semantics: The "urn" scheme identifies Uniform Resource Names, which are persistent, location-independent resource identifiers.
URIスキームのセマンティクス：「urn」スキームは、場所に依存しない永続的なリソース識別子であるUniform Resource Nameを識別します。
Encoding Considerations: See Section 2 of RFC 8141.
エンコードに関する考慮事項：RFC 8141のセクション2をご覧ください。
Applications/Protocols That Use This URI Scheme Name: Uniform Resource Names are used in a wide variety of applications, including bibliographic reference systems and as names for Extensible Markup Language (XML) namespaces.
このURIスキームを使用するアプリケーション/プロトコルスキーム名：Uniform Resource Namesは、書誌参照システムを含むさまざまなアプリケーションで使用され、Extensible Markup Language（XML）名前空間の名前として使用されます。
Interoperability Considerations: See Section 4 of RFC 8141.
相互運用性に関する考慮事項：RFC 8141のセクション4をご覧ください。
Security Considerations: See Sections 6.4.4 and 8 of RFC 8141.
セキュリティに関する考慮事項：RFC 8141のセクション6.4.4および8を参照してください。
Contact: URNBIS working group [mailto:urn@ietf.org]
Author/Change Controller: This scheme is registered under the IETF tree. As such, the IETF maintains change control.
作成者/変更コントローラ：このスキームはIETFツリーの下に登録されています。そのため、IETFは変更管理を維持します。
References: None.
参照：なし。
This document outlines the processes for registering URN namespaces and has implications for the IANA in terms of registries to be maintained (see especially Section 6). In all cases, the IANA ought to assign the appropriate NID (formal or informal) once the procedures outlined in Section 6 have been completed.
このドキュメントでは、URN名前空間を登録するプロセスの概要を説明し、維持するレジストリの観点からIANAに影響を与えます（特にセクション6を参照）。すべての場合において、セクション6で概説されている手順が完了したら、IANAは適切なNID（公式または非公式）を割り当てる必要があります。
As discussed elsewhere in this document, the discussion list specified in RFC 3406 (urn-nid@apps.ietf.org) is discontinued and replaced by the discussion list urn@ietf.org.
このドキュメントの他の場所で説明されているように、RFC 3406（urn-nid@apps.ietf.org）で指定されているディスカッションリストは廃止され、ディスカッションリストurn@ietf.orgに置き換えられています。
The definition of a URN namespace needs to account for potential security and privacy issues related to assignment, use, and resolution of names within the URN namespace (e.g., some URN resolvers might assign special meaning to certain characters in the NSS); see Section 6.4.4 for further discussion.
URN名前空間の定義は、URN名前空間内の名前の割り当て、使用、および解決に関連する潜在的なセキュリティとプライバシーの問題を考慮する必要があります（たとえば、一部のURNリゾルバーはNSSの特定の文字に特別な意味を割り当てる場合があります）;詳細については、セクション6.4.4を参照してください。
In most cases, URN namespaces provide a way to declare public information. Normally, these declarations will have a relatively low security profile; however, there is always the danger of "spoofing" and providing misinformation. Information in these declarations ought to be taken as advisory.
ほとんどの場合、URN名前空間は公開情報を宣言する方法を提供します。通常、これらの宣言のセキュリティプロファイルは比較的低くなります。ただし、「なりすまし」や誤った情報を提供する危険は常にあります。これらの宣言の情報は助言として取られるべきです。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、DOI 10.17487 / RFC0020、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[DOI-URI] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The "doi" URI Scheme for the Digital Object Identifier (DOI)", Work in Progress, draft-paskin-doi-uri-04, June 2003.
[DOI-URI] Paskin、N.、Neylon、E.、Hammond、T。、およびS. Sun、「デジタルオブジェクト識別子（DOI）の「doi」URIスキーム」、進行中の作業、draft-paskin- doi-uri-04、2003年6月。
[IANA-URN] Saint-Andre, P. and M. Cotton, "A Uniform Resource Name (URN) Namespace for IANA Registries", Work in Progress, draft-saintandre-iana-urn-01, February 2013.
[IANA-URN]セントアンドレ、P。およびM.コットン、「IANAレジストリのUniform Resource Name（URN）名前空間」、Work in Progress、draft-saintandre-iana-urn-01、2013年2月。
[ISO.27729.2012] ISO, "Information and documentation - International standard name identifier (ISNI)", ISO 27729:2012, Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, Identification and description, March 2012.
[ISO.27729.2012] ISO、「情報とドキュメント-国際標準名識別子（ISNI）」、ISO 27729：2012、技術委員会ISO / TC 46、情報とドキュメント、小委員会SC 9、識別と説明、2012年3月。
[ISO.3166-1] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1:2013, November 2013.
[ISO.3166-1] ISO、「国名とその下位区分の名前を表すコード-パート1：国コード」、ISO 3166-1：2013、2013年11月。
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, DOI 10.17487/RFC1737, December 1994, <http://www.rfc-editor.org/info/rfc1737>.
[RFC1737] Sollins、K。およびL. Masinter、「Uniform Resource Namesの機能要件」、RFC 1737、DOI 10.17487 / RFC1737、1994年12月、<http://www.rfc-editor.org/info/rfc1737>。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, December 1994, <http://www.rfc-editor.org/info/rfc1738>.
[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、DOI 10.17487 / RFC1738、1994年12月、<http：//www.rfc-editor .org / info / rfc1738>。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, DOI 10.17487/RFC1808, June 1995, <http://www.rfc-editor.org/info/rfc1808>.
[RFC1808] Fielding、R。、「Relative Uniform Resource Locators」、RFC 1808、DOI 10.17487 / RFC1808、1995年6月、<http://www.rfc-editor.org/info/rfc1808>。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141] Moats、R。、「URN Syntax」、RFC 2141、DOI 10.17487 / RFC2141、1997年5月、<http://www.rfc-editor.org/info/rfc2141>。
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, DOI 10.17487/RFC2276, January 1998, <http://www.rfc-editor.org/info/rfc2276>.
[RFC2276] Sollins、K。、「Architectural Principles of Uniform Resource Name Resolution」、RFC 2276、DOI 10.17487 / RFC2276、1998年1月、<http://www.rfc-editor.org/info/rfc2276>。
[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, DOI 10.17487/RFC2483, January 1999, <http://www.rfc-editor.org/info/rfc2483>.
[RFC2483] Mealling、M。およびR. Daniel、「URN解決に必要なURI解決サービス」、RFC 2483、DOI 10.17487 / RFC2483、1999年1月、<http://www.rfc-editor.org/info/rfc2483> 。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, DOI 10.17487/RFC2648, August 1999, <http://www.rfc-editor.org/info/rfc2648>.
[RFC2648] Moats、R。、「IETFドキュメントのURNネームスペース」、RFC 2648、DOI 10.17487 / RFC2648、1999年8月、<http://www.rfc-editor.org/info/rfc2648>。
[RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, DOI 10.17487/RFC3044, January 2001, <http://www.rfc-editor.org/info/rfc3044>.
[RFC3044] Rozenfeld、S。、「ISSN-URN名前空間内でISSN（国際シリアル標準番号）をURN（Uniform Resource Names）として使用する」、RFC 3044、DOI 10.17487 / RFC3044、2001年1月、<http：// www .rfc-editor.org / info / rfc3044>。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, DOI 10.17487/RFC3187, October 2001, <http://www.rfc-editor.org/info/rfc3187>.
[RFC3187] Hakala、J。およびH. Walravens、「Using International Standard Book Numbers as Uniform Resource Names」、RFC 3187、DOI 10.17487 / RFC3187、2001年10月、<http://www.rfc-editor.org/info/ rfc3187>。
[RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC3188] Hakala、J。、「Using National Bibliography Numbers as Uniform Resource Names」、RFC 3188、DOI 10.17487 / RFC3188、2001年10月、<http://www.rfc-editor.org/info/rfc3188>。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[RFC3406] Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「Uniform Resource Names（URN）Namespace Definition Mechanisms」、BCP 66、RFC 3406、DOI 10.17487 / RFC3406、2002年10月、 <http://www.rfc-editor.org/info/rfc3406>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの作成ガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<http://www.rfc-editor.org/ info / rfc3552>。
[RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", RFC 4854, DOI 10.17487/RFC4854, April 2007, <http://www.rfc-editor.org/info/rfc4854>.
[RFC4854] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の拡張のためのUniform Resource Name（URN）名前空間」、RFC 4854、DOI 10.17487 / RFC4854、2007年4月、<http：// www .rfc-editor.org / info / rfc4854>。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, DOI 10.17487/RFC5122, February 2008, <http://www.rfc-editor.org/info/rfc5122>.
[RFC5122] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）の国際化リソース識別子（IRI）およびUniform Resource Identifiers（URIs）」、RFC 5122、DOI 10.17487 / RFC5122、2008年2月、<http： //www.rfc-editor.org/info/rfc5122>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<http://www.rfc-editor.org/info/ rfc5890>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120 >。
[RFC6288] Reed, C., "URN Namespace for the Defence Geospatial Information Working Group (DGIWG)", RFC 6288, DOI 10.17487/RFC6288, August 2011, <http://www.rfc-editor.org/info/rfc6288>.
[RFC6288] Reed、C。、「URN Namespace for the Defense Geospatial Information Working Group（DGIWG）」、RFC 6288、DOI 10.17487 / RFC6288、2011年8月、<http://www.rfc-editor.org/info/rfc6288 >。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, DOI 10.17487/RFC6648, June 2012, <http://www.rfc-editor.org/info/rfc6648>.
[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、DOI 10.17487 / RFC6648、2012年6月、 <http://www.rfc-editor.org/info/rfc6648>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.
[RFC6943] Thaler、D。、編、「セキュリティ上の目的での識別子比較の問題」、RFC 6943、DOI 10.17487 / RFC6943、2013年5月、<http://www.rfc-editor.org/info/rfc6943>。
[RFC6963] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Examples", BCP 183, RFC 6963, DOI 10.17487/RFC6963, May 2013, <http://www.rfc-editor.org/info/rfc6963>.
[RFC6963] Saint-Andre、P。、「例のUniform Resource Name（URN）名前空間」、BCP 183、RFC 6963、DOI 10.17487 / RFC6963、2013年5月、<http://www.rfc-editor.org/ info / rfc6963>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. Gosden, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, <http://www.rfc-editor.org/info/rfc7254>.
[RFC7254] Montemurro、M.、Ed。、Allen、A.、McDonald、D.、and P. Gosden、 "A Uniform Resource Namenamespace for the Global System for Mobile Communications Association（GSMA）and the International Mobile Station Equipment Identity （IMEI）」、RFC 7254、DOI 10.17487 / RFC7254、2014年5月、<http://www.rfc-editor.org/info/rfc7254>。
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/RFC7282, June 2014, <http://www.rfc-editor.org/info/rfc7282>.
[RFC7282] Resnick、P。、「IETFにおける合意とハミングについて」、RFC 7282、DOI 10.17487 / RFC7282、2014年6月、<http://www.rfc-editor.org/info/rfc7282>。
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <http://www.rfc-editor.org/info/rfc7320>.
[RFC7320]ノッティンガム、M。、「URI Design and Ownership」、BCP 190、RFC 7320、DOI 10.17487 / RFC7320、2014年7月、<http://www.rfc-editor.org/info/rfc7320>。
[RFC7462] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and P. Kyzivat, "URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)", RFC 7462, DOI 10.17487/RFC7462, March 2015, <http://www.rfc-editor.org/info/rfc7462>.
[RFC7462] Liess、L.、Ed。、Jesske、R.、Johnston、A.、Worley、D。、およびP. Kyzivat、「Session Initiation Protocol（SIP）のAlert-InfoヘッダーフィールドのURN」、 RFC 7462、DOI 10.17487 / RFC7462、2015年3月、<http://www.rfc-editor.org/info/rfc7462>。
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <http://www.rfc-editor.org/info/rfc7613>.
[RFC7613] Saint-Andre、P。およびA. Melnikov、「ユーザー名とパスワードを表す国際化された文字列の準備、適用、比較」、RFC 7613、DOI 10.17487 / RFC7613、2015年8月、<http：//www.rfc- editor.org/info/rfc7613>。
[UAX31] The Unicode Consortium, "Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax", Unicode 9.0.0, June 2015, <http://unicode.org/reports/tr31/>.
[UAX31] Unicodeコンソーシアム、「Unicode Standard Annex＃31：Unicode Identifier and Pattern Syntax」、Unicode 9.0.0、2015年6月、<http://unicode.org/reports/tr31/>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[URI-Registry] IANA, "Uniform Resource Identifier (URI) Schemes", <http://www.iana.org/assignments/uri-schemes>.
[URIレジストリ] IANA、「Uniform Resource Identifier（URI）Schemes」、<http://www.iana.org/assignments/uri-schemes>。
[XML-BASE] Marsh, J. and R. Tobin, "XML Base (Second Edition)", W3C Recommendation REC-xmlbase-20090128, January 2009, <http://www.w3.org/TR/2009/REC-xmlbase-20090128>.
[XML-BASE] Marsh、J.、R。Tobin、「XML Base（Second Edition）」、W3C勧告REC-xmlbase-20090128、2009年1月、<http://www.w3.org/TR/2009/REC -xmlbase-20090128>。
[XML-NAMES] Thompson, H., Hollander, D., Layman, A., Bray, T., and R. Tobin, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XML-NAMES] Thompson、H.、Hollander、D.、Layman、A.、Bray、T.、and R. Tobin、 "Namespaces in XML 1.0（Third Edition）"、W3C Recommendation REC-xml-names-20091208 、2009年12月、<http://www.w3.org/TR/2009/REC-xml-names-20091208>。
Namespace Identifier: Requested of IANA (formal) or assigned by IANA (informal).
名前空間識別子：IANAから要求（正式）またはIANAによって割り当て（非公式）。
Version: The version of the registration, starting with 1 and incrementing by 1 with each new version.
バージョン：登録のバージョン。1から始まり、新しいバージョンごとに1ずつ増加します。
Date: The date when the registration is requested of IANA, using the format YYYY-MM-DD.
日付：IANAの登録が要求された日付。形式はYYYY-MM-DDです。
Registrant: The person or organization that has registered the NID, including the name and address of the registering organization, as well as the name and contact information (email, phone number, or postal address) of the designated contact person. If the registrant is a recognized standards development organization, scientific society, or similar body requesting the fast-track registration procedure (see Section 6.3), that information should be clearly indicated in this section of the template.
登録者：NIDを登録した個人または組織。登録組織の名前と住所、および指定された連絡先の名前と連絡先情報（電子メール、電話番号、または住所）が含まれます。登録者が承認済みの標準開発組織、科学協会、またはファストトラック登録手順を要求する同様の機関である場合（セクション6.3を参照）、その情報はテンプレートのこのセクションに明確に示されている必要があります。
Purpose: Described in Section 6.4.1 of this document.
目的：このドキュメントのセクション6.4.1で説明されています。
Syntax: Described in Section 6.4.2 of this document. Unless the registration explicitly describes the semantics of r-components, q-components, and f-components in the context of this URN namespace, those semantics are undefined.
構文：このドキュメントのセクション6.4.2で説明されています。登録で、このURN名前空間のコンテキストでrコンポーネント、qコンポーネント、およびfコンポーネントのセマンティクスが明示的に記述されていない限り、これらのセマンティクスは定義されていません。
Assignment: Described in Section 6.4.3 of this document.
割り当て：このドキュメントのセクション6.4.3で説明されています。
Security and Privacy: Described in Section 6.4.4 of this document.
セキュリティとプライバシー：このドキュメントのセクション6.4.4で説明されています。
Interoperability: Described in Section 6.4.5 of this document.
相互運用性：このドキュメントのセクション6.4.5で説明されています。
Resolution: Described in Section 6.4.6 of this document.
解決策：このドキュメントのセクション6.4.6に記載されています。
Documentation: A pointer to an RFC, a specification published by another standards development organization, or another stable document that provides further information about this URN namespace.
ドキュメント：RFC、別の標準開発組織によって公開された仕様、またはこのURN名前空間に関する詳細情報を提供する別の安定したドキュメントへのポインタ。
Additional Information: Described in Section 6.4.7 of this document.
追加情報：このドキュメントのセクション6.4.7で説明されています。
Revision Information: Description of changes from prior version(s). (Applicable only when earlier registrations have been revised.)
リビジョン情報：以前のバージョンからの変更点の説明。 （以前の登録が変更された場合にのみ適用されます。）
This document makes substantive changes from the syntax and semantics of [RFC2141]:
このドキュメントは、[RFC2141]の構文とセマンティクスから実質的な変更を加えます。
The syntax of URNs as provided in [RFC2141] was defined before the updated specification of URIs in [RFC3986]. The definition of URN syntax is updated in this document to do the following:
[RFC2141]で提供されるURNの構文は、[RFC3986]でのURIの更新された仕様の前に定義されました。このドキュメントでは、URN構文の定義が次のように更新されています。
o Ensure consistency with the URI syntax.
o URI構文との整合性を確保してください。
o Facilitate the use of URNs with parameters similar to URI queries and fragments.
o URIクエリおよびフラグメントに類似したパラメーターを使用してURNの使用を容易にします。
o Permit parameters influencing URN resolution.
o URN解決に影響を与えるパラメータを許可します。
o Ease the use of URNs with non-URN identifier systems that include the "/" character.
o 「/」文字を含む非URN識別子システムでURNの使用を容易にします。
In particular, this specification does the following:
特に、この仕様は次のことを行います。
o Extends URN syntax to explicitly allow the characters "/", "?", and "#", which were reserved for future use by RFC 2141. This change also effectively allows several components of the URI syntax although without necessarily tying those components to URI semantics.
o URN構文を拡張して、RFC 2141で将来使用するために予約された文字「/」、「？」、および「＃」を明示的に許可します。この変更により、URI構文のいくつかのコンポーネントも事実上許可されますが、これらのコンポーネントを必ずしもURIに関連付ける必要はありませんセマンティクス。
o Defines general syntax for an additional component that can be used in interactions with a URN resolution service.
o URN解決サービスとのやり取りで使用できる追加コンポーネントの一般的な構文を定義します。
o Disallows "-" at the end of the NID.
o NIDの最後の「-」を許可しません。
o Allows the "/", "~", and "&" characters in the NSS.
o NSSで「/」、「〜」、および「＆」の文字を許可します。
o Makes several smaller syntax adjustments.
o いくつかの小さな構文の調整を行います。
o Formally registers "urn" as a URI scheme.
o "urn"をURIスキームとして正式に登録します。
o Allows what are now called r-components, q-components, and f-components.
o 現在rコンポーネント、qコンポーネント、およびfコンポーネントと呼ばれるものを許可します。
In addition, some of the text has been updated to be consistent with the definition of URIs [RFC3986] and the processes for registering information with the IANA [RFC5226], as well as more modern guidance with regard to security [RFC3552], privacy [RFC6973], and identifier comparison [RFC6943].
さらに、一部のテキストは、URI [RFC3986]の定義とIANAに情報を登録するプロセス[RFC5226]、およびセキュリティ[RFC3552]、プライバシー[ RFC6973]、および識別子の比較[RFC6943]。
This document makes the following substantive changes from [RFC3406]:
このドキュメントは、[RFC3406]から次の実質的な変更を加えます。
1. Relaxes the registration policy for formal URN namespaces from "IETF Review" to "Expert Review" as discussed in Section 6.2.
1. セクション6.2で説明されているように、正式なURN名前空間の登録ポリシーを「IETFレビュー」から「エキスパートレビュー」に緩和します。
2. Removes the category of experimental URN namespaces, consistent with [RFC6648]. Experimental URN namespaces were denoted by prefixing the namespace identifier with the string "X-". Because experimental URN namespaces were never registered, removing the experimental category has no impact on the existing registries. Because experimental URN namespaces are not managed, strings conforming to URN syntax within experimental URN namespaces are not valid URNs. Truly experimental usages may, of course, employ the "example" namespace [RFC6963].
2. [RFC6648]と一貫性のある、実験的なURN名前空間のカテゴリを削除します。実験的なURN名前空間は、名前空間識別子の前に文字列「X-」を付けることで示されていました。実験的なURN名前空間は登録されなかったため、実験的なカテゴリを削除しても、既存のレジストリに影響はありません。試験的なURN名前空間は管理されないため、試験的なURN名前空間内のURN構文に準拠する文字列は有効なURNではありません。もちろん、実際に実験的に使用する場合は、「example」名前空間を使用できます[RFC6963]。
3. Adds some information to, but generally simplifies, the URN namespace registration template.
3. 一部の情報をURN名前空間登録テンプレートに追加しますが、通常は簡略化します。
Acknowledgements
謝辞
Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other participants in the URNBIS working group for their input. Alfred Hoenes in particular edited an earlier draft version of this document and served as co-chair of the URNBIS working group.
マーク・ブランシェ、レスリー・デイグル、マーティン・デュエルスト、ジュハ・ハカラ、テッド・ハーディ、アルフレッド・ホーネス、ポール・ジョーンズ、バリー・レイバ、ショーン・レナード、ラリー・マシンター、キース・ムーア、マーク・ノッティンガム、ジュリアン・レシュケ、ラース・スベンソン、ヘンリー・S・トンプソン、 Dale Worley、およびURNBISワーキンググループの他の参加者の意見。特にアルフレッド・ホーネスは、この文書の以前のドラフト版を編集し、URNBISワーキンググループの共同議長を務めました。
Juha Hakala deserves special recognition for his dedication to successfully completing this work, as do Andrew Newton and Melinda Shore in their roles as working group co-chairs and Barry Leiba in his role as area director and then as co-chair.
Juha Hakalaは、この作業を成功裏に完了するための彼の献身と同様に、ワーキンググループの共同議長としてのAndrew NewtonとMelinda Shore、エリアディレクターとしての共同議長としてのBarry Leibaと同様に、特別な表彰に値します。
Contributors
貢献者
RFC 2141, which provided the basis for the syntax portion of this document, was authored by Ryan Moats.
このドキュメントの構文部分の基礎を提供するRFC 2141は、Ryan Moatsによって作成されました。
RFC 3406, which provided the basis for the namespace portion of this document, was authored by Leslie Daigle, Dirk-Willem van Gulik, Renato Iannella, and Patrik Faltstrom.
このドキュメントの名前空間部分の基礎を提供するRFC 3406は、レスリーデイグル、ダークウィレムファングリク、レナートイアンネラ、パトリックファルクストロムによって作成されました。
Their work is gratefully acknowledged.
彼らの仕事は感謝されている。
Authors' Addresses
著者のアドレス
Peter Saint-Andre Filament P.O. Box 787 Parker, CO 80134 United States of America
ピーターセントアンドレフィラメントP.O. Box 787 Parker、CO 80134アメリカ合衆国
Phone: +1 720 256 6756
Email: peter@filament.com
URI: <https://filament.com/>
John C. Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America
John C. Klensin 1770 Massachusetts Ave、Ste 322 Cambridge、MA 02140アメリカ合衆国
Phone: +1 617 245 1457
Email: john-ietf@jck.com