RFC 3406 - Uniform Resource Names (URN) Namespace Definition Mechanisms 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3406
タイトル : RFC 3406 - ユニフォームリソース名（URN）名前空間定義メカニズム
翻訳編集 : 自動生成

[要約] RFC 3406は、URNの名前空間定義メカニズムに関する規定です。その目的は、URNの一意性と持続性を確保し、インターネット上のリソースを一意に識別するための仕組みを提供することです。

Network Working Group                                          L. Daigle
Request for Comments: 3406                      Thinking Cat Enterprises
BCP: 66                                                   D.W. van Gulik
Obsoletes: 2611                                               WebWeaving
Category: Best Current Practice                              R. Iannella
                                                             IPR Systems
                                                            P. Faltstrom
                                                                   Cisco
                                                            October 2002

Uniform Resource Names (URN) Namespace Definition Mechanisms

ユニフォームリソース名（URN）名前空間定義メカニズム

Status of this Memo

本文書の位置付け

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288.

このドキュメントでは、ユニフォームのリソース名（URN）「名前空間」を確立するための一般的な定義とメカニズムを定めています。URN WGは、RFC 2141のURNの構文を定義しており、RFC 3401およびRFC 3405のインターネットアプリケーションでの解像度と使用のための提案されたメカニズムを定義しています。概念の証明名空間とは別に、URNでの既存の識別子の使用がRFC 2288で説明されています。

Table of Contents

   1.0 Introduction ................................................. 2
   2.0 What is a URN Namespace? ..................................... 3
   3.0 URN Namespace (Registration) Types ........................... 3
   3.1 Experimental Namespaces .....................................  4
   3.2 Informal Namespaces .........................................  4
   3.3 Formal Namespaces ...........................................  4
   4.0 URN Namespace Registration, Update, and NID Assignment
       Process .....................................................  6
   4.1 Experimental ................................................  6
   4.2 Informal ....................................................  6
   4.3 Formal ......................................................  7
   5.0 Security Considerations .....................................  9
      6.0 IANA Considerations .........................................  9
   7.0 References ..................................................  9
   Appendix A -- URN Namespace Definition Template ................. 11
   Appendix B -- Illustration ...................................... 15
   B.1 Example Template ............................................ 15
   B.2 Registration steps in practice .............................. 17
   Appendix C -- Changes from RFC 2611 ............................. 18
   C.1 Detailed Document Changes ................................... 19
   Authors' Addresses .............................................. 21
   Full Copyright Statement ........................................ 22

1.0 Introduction

1.0 はじめに

Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. URNs are part of the larger Uniform Resource Identifier (URI) family [RFC3305] with the specific goal of providing persistent naming of resources.

ユニフォームのリソース名（URN）は、リソースの場所に依存しない識別を可能にするための特定の要件と、参照の長寿です。URNは、リソースの永続的な命名を提供するという特定の目標を持つ、より大きな均一なリソース識別子（URI）ファミリー[RFC3305]の一部です。

There are 2 assumptions that are key to this document:

このドキュメントの鍵となる2つの仮定があります。

Assumption #1:

仮定＃1：

Assignment of a URN is a managed process.

URNの割り当ては管理されたプロセスです。

I.e., not all strings that conform to URN syntax are necessarily valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process).

つまり、urn構文に適合するすべての文字列が必ずしも有効なurnsであるわけではありません。URNは、特定の名前空間のルールに従って割り当てられます（構文、セマンティクス、およびプロセスの観点から）。

Assumption #2:

仮定＃2：

The space of URN namespaces is managed.

urnネームスペースのスペースが管理されています。

I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces. A URN namespace must have a recognized definition in order to be valid.

つまり、すべてが構文的に正しいurnamespaces（urn構文定義ごと）であるわけではありません。有効なurnネームスペースです。urnネームスペースには、有効になるために認識された定義が必要です。

The purpose of this document is to outline a mechanism and provide a template for explicit namespace definition, as well as provide the mechanism for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority (IANA).

このドキュメントの目的は、メカニズムの概要を示し、明示的な名前空間定義のテンプレートを提供するだけでなく、インターネットに割り当てられた番号当局に登録されている識別子（「名前空間ID」またはNID）を関連付けるメカニズムを提供することです。IANA）。

Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the DDDS system [RFC3401], is necessary. See [RFC3405] for information on obtaining registration in the DDDS global NID directory.

このドキュメントは、urnネームスペースを作成するためのプロセスの説明に制限されていることに注意してください。いわゆるURN識別子の「解像度」が必要な場合、DDDSシステム[RFC3401]によって提供されるようなグローバルNIDディレクトリでの登録の個別のプロセスが必要です。DDDSグローバルNIDディレクトリで登録を取得する詳細については、[RFC3405]を参照してください。

2.0 What is a URN Namespace?

2.0 urnネームスペースとは何ですか？

For the purposes of URNs, a "namespace" is a collection of uniquely-assigned identifiers. That is, the identifiers are not ever assigned to more than 1 resource, nor are they ever re-assigned to a different resource. A single resource, however, may have more than one URN assigned to it for different purposes. A URN namespace itself has an identifier in order to:

urnsの目的のために、「名前空間」は、一意に割り当てられた識別子のコレクションです。つまり、識別子は1つ以上のリソースに割り当てられておらず、別のリソースに再割り当てされることもありません。ただし、単一のリソースには、異なる目的で複数のurnが割り当てられている場合があります。urnネームスペース自体には、次のために識別子があります。

- ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier

- urのグローバルな一意性を確保 - （必要な場合）識別子の構造にキューを提供します

For example, many identifier systems may use strings of numbers as identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable that there might be some numbers that are valid identifiers in two different established identifier systems. Using different designators for the two collections ensures that no two URNs will be the same for different resources (since each collection is required to uniquely assign each identifier).

たとえば、多くの識別子システムは、数字の文字列を識別子（ISBN、ISSN、電話番号など）として使用する場合があります。2つの異なる確立された識別子システムに有効な識別子であるいくつかの数字があるかもしれないと考えられます。2つのコレクションに異なる設計者を使用すると、異なるリソースに対して2つのURNが同じではないことが保証されます（各識別子を一意に割り当てるには、各コレクションが必要なため）。

The development of an identifier structure, and thereby a collection of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they will be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define a namespace (e.g., publishing community, association of booksellers, protocol developers, etc); they are beyond the scope of the IETF URN work.

識別子構造の開発、およびそれによって識別子のコレクションは、識別子の割り当て方法、およびそれらが置かれる使用法を定義するコミュニティの要件に本質的に依存するプロセスです。これらの問題はすべて、名前空間を定義しようとする個々のコミュニティに固有のものです（例：公開コミュニティ、書店の協会、プロトコル開発者など）。それらは、IETF URNワークの範囲を超えています。

This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignment, etc) can become a bona fide URN namespace by obtaining a NID. In a nutshell, a template for the definition of the namespace is completed for deposit with IANA, and a NID is assigned. The details of the process and possibilities for NID strings are outlined below.

このドキュメントでは、特定の制約（割り当ての一意性など）を満たす識別子のコレクションが、NIDを取得することにより真正なurnamesスペースになるプロセスの概要を説明します。一言で言えば、名前空間の定義のテンプレートがIANAに堆積するために完了し、NIDが割り当てられます。NID文字列のプロセスと可能性の詳細については、以下に概説します。

3.0 URN Namespace (Registration) Types

3.0 urnネームスペース（登録）タイプ

There are three categories of URN namespaces defined here, distinguished by expected level of service and required procedures for registration. Registration processes for each of these namespace types are given in Section 4.0.

ここで定義されている3つのカテゴリには、予想されるサービスレベルと登録に必要な手順によって区別されます。これらの各名前空間タイプの登録プロセスは、セクション4.0に記載されています。

3.1 Experimental Namespaces

3.1 実験的な名前空間

These are not explicitly registered with IANA. They take the form:

これらはIANAに明示的に登録されていません。彼らはフォームを取る：

X-<NID>

x- <nid>

No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts.

実験NIDの衝突を回避するための規定はありません。それらは、内部または限られた実験的コンテキスト内で使用することを目的としています。

3.2 Informal Namespaces

3.2 非公式の名前空間

These are fully fledged URN namespaces, with all the rights and requirements associated thereto. Informal namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN namespace -- providing persistent identification of resources, and unique assignment of identifier strings. Informal and formal namespaces (described below) differ in the NID assignment. IANA will assign an alphanumeric NID to registered informal namespaces, per the process outlined in Section 4.0.

これらは、すべての権利と要件が関連付けられている完全に膨らんだ骨name空間です。非公式の名前空間は、グローバル登録サービスに登録できます。それらは、適切に管理されたURNネームスペースの一般原則を維持する必要があります - リソースの永続的な識別と識別子文字列の一意の割り当てを提供します。非公式および正式な名前空間（以下で説明）は、NIDの割り当てが異なります。IANAは、セクション4.0で概説されているプロセスに従って、登録された非公式の名前空間に英数字NIDを割り当てます。

3.3 Formal Namespaces

3.3 正式な名前空間

A formal namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to some subset of users on the Internet. That is, a formal NID proposal, if accepted, must be functional on and with the global Internet, not limited to users in communities or networks not connected to the Internet. For example, a NID that is meant for naming of physics research is requested. If that NID request required that the user use a proprietary network or service that was not at all open to the general Internet user, then it would make a poor request for a formal NID. The intent is that, while the community of those who may actively use the names assigned within that NID may be small (but no less important), the potential use of names within that NID is open to any user on the Internet.

NID提案と基礎となる名前空間の公開がインターネット上の一部のユーザーに利益をもたらす場合、IETFレビューが要求される場合があり、IETFレビューが求められます。つまり、正式なNID提案は、受け入れられた場合、インターネットに接続されていないコミュニティまたはネットワークのユーザーに限定されないグローバルインターネットで機能し、機能する必要があります。たとえば、物理学研究の命名を目的としたNIDが要求されます。そのNID要求が、ユーザーが一般的なインターネットユーザーにまったく開かれていない独自のネットワークまたはサービスを使用することを要求した場合、正式なNIDのリクエストが不十分になります。意図は、そのNID内で割り当てられた名前を積極的に使用する可能性のある人々のコミュニティは、そのNID内の名前の潜在的な使用がインターネット上のどのユーザーにも開かれている可能性がある（しかし、それほど重要ではない）ことです。

It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of a fee-based, privately managed, or proprietary registry for assignment of URNs in the namespace, but it may still provide benefit to some Internet users if the services associated have openly-published access protocols.

いくつかの側面が完全に開かれていない名前空間に正式なNIDが適用されることが期待されています。たとえば、名前空間は、名前空間でのURNを割り当てるための料金ベース、個人管理、または独自のレジストリを使用する場合がありますが、関連するサービスが公然と出版されたアクセスプロトコルを持っている場合、一部のインターネットユーザーに利益をもたらす場合があります。

In addition to the basic registration information defined in the registration template (in Appendix A), a formal namespace request must be accompanied by documented considerations of the need for a new namespace and of the community benefit from formally establishing the proposed URN namespace.

登録テンプレート（付録Aの）で定義されている基本的な登録情報に加えて、正式な名前空間要求には、新しい名前空間の必要性とコミュニティが提案されたURNネームスペースを正式に確立することでメリットがあるという文書化された考慮事項を添付する必要があります。

Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discussed at length the issue of finding objective measures for predicting (a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experience of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification.

さらに、urnsの目標は永続的な識別を提供することであるため、名前空間の長寿と保守性に関するいくつかの考慮事項を指定する必要があります。URN WGは、名前空間の継続的な成功を予測するための客観的な尺度を見つける問題について長々と説明しました。結論に達したことはありません。名前空間の技術的範囲を完全に超えた要因に大きく依存します。ただし、IETFコミュニティの集合的な経験には、識別の寿命を妨げる技術的要因に関する豊富な情報が含まれています。IETFコミュニティのコンセンサスには、持続的な識別を防止（または可能性を深刻に損なう）技術的欠陥が含まれているという場合、IESGは提案された名前空間RFCを公開しないことを選択する場合があります。

The kinds of things the URN WG discussed included:

議論された骨wgが含まれるものの種類：

- the organization maintaining the URN namespace should demonstrate stability and the ability to maintain the URN namespace for a long time, and/or it should be clear how the namespace can continue to be usable/useful if the organization ceases to be able to foster it;

- urnネームスペースを維持する組織は、安定性とurnネームスペースを長時間維持する能力を実証する必要があります。

- it should demonstrate ability and competency in name assignment. This should improve the likelihood of persistence (e.g. to minimize the likelihood of conflicts);

- 名前の割り当ての能力と能力を示す必要があります。これにより、持続性の可能性が向上するはずです（たとえば、競合の可能性を最小限に抑えるため）。

- it should commit to not re-assigning existing names and allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. This does not mean that there must be resolution of such names, but that they must not resolve the name to false or stale information, and that they must not be reassigned.

- それらの名前の所有者または譲受人がその組織のメンバーまたは顧客ではなくなったとしても、既存の名前を再割り当てせず、古い名前を有効にし続けることを約束する必要があります。これは、そのような名前の解決がなければならないことを意味するのではなく、名前を虚偽または古い情報に解決してはならず、再割り当てしてはならないことを意味します。

These aspects, though hard to quantify objectively, should be considered by organizations/people considering the development of a Formal URN namespace, and they will be kept in mind when evaluating the technical merits of any proposed Formal namespace.

これらの側面は、客観的に定量化するのは困難ですが、正式な骨nネームスペースの開発を考慮して組織/人々が考慮する必要があり、提案された正式な名前空間の技術的メリットを評価する際には留意されます。

4.0 URN Namespace Registration, Update, and NID Assignment Process

4.0 urnネームスペース登録、更新、およびNIDの割り当てプロセス

Different levels of disclosure are expected/defined for namespaces. According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The "IANA Considerations" document [RFC2434] suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes. Since URNs are meant to be persistently useful, few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc, over the natural course of a namespace's lifetime. Specific processes are outlined below.

名前空間に対して、さまざまなレベルの開示が予想されます/定義されています。開示を取り巻くオープンフォーラムの議論のレベルによれば、urnネームスペースが割り当てられるか、特定の識別子を要求する場合があります。「IANAの考慮事項」ドキュメント[RFC2434]は、登録の更新メカニズムを指定する必要性を示唆しています。urnは持続的に有用であることを意図しているため、urn文字列の構造解釈に変更する必要があります（たとえば、すでに割り当てられているurn IDの解釈に影響を与える可能性のある語彙の同等性のルールを追加または削除します）。ただし、名前空間の生涯の自然な過程で、明確化を導入し、認定されたurn割り当て者のリストなどを拡張することが重要かもしれません。特定のプロセスを以下に概説します。

The official list of registered URN namespaces is maintained by IANA. URN namespace registrations are currently being posted in the anonymous FTP directory:

登録済みのurnamesスペースの公式リストは、IANAによって維持されています。URNネームスペース登録は現在、匿名のFTPディレクトリに投稿されています。

http://www.iana.org/assignments/urn-namespaces

See [RFC3232] for the current location of IANA registry.

IANAレジストリの現在の場所については、[RFC3232]を参照してください。

The registration and maintenance procedures vary slightly from one namespace type (as defined in Section 3.0) to another.

登録およびメンテナンス手順は、名前空間タイプ（セクション3.0で定義されている）から別の名前までわずかに異なります。

4.1 Experimental

4.1 実験的

These are not explicitly registered with IANA. They take the form:

これらはIANAに明示的に登録されていません。彼らはフォームを取る：

X-<NID>

x- <nid>

No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts.

実験NIDの衝突を回避するための規定はありません。それらは、内部または限られた実験的コンテキスト内で使用することを目的としています。

As there is no registration, no registration maintenance procedures are needed.

登録がないため、登録メンテナンス手順は必要ありません。

4.2 Informal

4.2 非公式

These are registered with IANA and are assigned a number sequence as an identifier, in the format:

これらはIANAに登録されており、形式で識別子として数字シーケンスを割り当てられます。

"urn-" <number>

「urn-」<number>

where <number> is chosen by the IANA on a First Come First Served basis (see [RFC2434]).

ここで、<number>は最初の提供ベースでIANAによって選択されます（[rfc2434]を参照）。

Registrants should send a copy of the registration template (see Appendix A), duly completed, to:

登録者は、登録テンプレートのコピーを送信する必要があります（付録Aを参照）、正式に記入してください。

urn-nid@apps.ietf.org

and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for technical improvements to the namespace proposal.

登録情報の表現と、名前空間提案の技術的改善の提案を明確にするための2週間の議論期間を許可します。

After suggestions for clarification of the registration information have been incorporated, the template may be submitted for assignment of a NID to:

登録情報を明確にするための提案が組み込まれた後、テンプレートはNIDの割り当てのために提出される場合があります。

iana@iana.org

The only restrictions on <number> are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2141]).

<number>の唯一の制限は、桁で厳密に構成され、nidがurn構文で概説されている長さの制限を超えないことです（[rfc2141]）。

Registrations may be updated by the original registrant, or an entity designated by the registrant, by updating the registration template, submitting it to the discussion list for a further 2 week discussion period, and finally resubmitting it to IANA, as described above.

登録は、登録テンプレートを更新し、さらに2週間のディスカッション期間のためにディスカッションリストに提出し、最終的に上記のようにIANAに再提出することにより、元の登録者、または登録者が指定したエンティティによって更新される場合があります。

4.3 Formal

4.3 フォーマル

Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]:

[RFC2434]で定義されているように、正式なNIDはIETFコンセンサスによって割り当てられます。

"IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists)."

「IETFコンセンサス - 新しい値はIETFコンセンサスプロセスを通じて割り当てられます。具体的には、IESGによって承認されたRFCを介して新しい割り当てが行われます。通常、IESGは適切な人物からの将来の割り当てに関する意見を求めます（例えば、関連するワーキンググループが存在する場合、関連するワーキンググループが）。」

Thus, the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards-track, but it will be subject to IESG review and acceptance pursuant to the guidelines written here (as well as standard RFC publication guidelines). The template defined in Appendix A may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the:

したがって、正式なNIDアプリケーションは、標準のIETFプロセスを通じてRFCの公開を介して行われます。RFCは標準トラックである必要はありませんが、ここに書かれたガイドライン（および標準のRFC出版ガイドライン）に従ってIESGレビューと受け入れの対象となります。付録Aで定義されているテンプレートは、名前空間の他の側面を定義するRFCの一部として含まれている場合があります。または、それ自体がRFCとして提出される場合があります。提案されたテンプレートは、次のように送信する必要があります。

urn-nid@apps.ietf.org

mailing list to allow for a two week discussion period for clarifying the expression of the registration information, before the IESG reviews the document.

IESGがドキュメントをレビューする前に、登録情報の表現を明確にするための2週間の議論期間を許可するメーリングリスト。

The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements).

RFCには、新しい名前空間（つまり、既存の名前空間が提案者の要件に達していない場合）の認識された必要性の概要を概説する「名前空間考慮事項」セクションを含める必要があります。

Considerations might include:

考慮事項には以下が含まれます。

- URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported

- urn割り当て手順 - urn解像度/委任 - 特定するリソースの種類 - サポートされるサービスの種類

NOTE: It is expected that more than one namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration.

注：複数の名前空間が同じ「機能的な」目的に役立つ可能性があることが予想されます。「名前空間考慮事項」セクションの意図は、IESGの考慮のために、既存の可能性を探る際に提案者の「デューデリジェンス」の記録を提供することです。

The RFC must also include a "Community Considerations" section, which indicates the dimensions upon which the proposer expects its community to be able to benefit by publication of this namespace as well as how a general Internet user will be able to use the space if they care to do so. Potential considerations include:

RFCには、「コミュニティに関する考慮事項」セクションも含まれている必要があります。これには、提案者がこの名前空間の公開によりコミュニティが利益を得ることができると期待する寸法と、一般的なインターネットユーザーがどのようにスペースを使用できるかを示します。そうするように注意してください。潜在的な考慮事項は次のとおりです。

- open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client)

- 名前空間内の識別子のオープン割り当てと使用 - 名前空間の解像度サーバーのオープン操作（サーバー） - 名前空間のサービスを有意に解決およびアクセスできるソフトウェアの作成（クライアント）

The RFC must include an "IANA Considerations" section, indicating that the document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs.

RFCには、「IANAの考慮事項」セクションを含める必要があります。これには、ドキュメントにurn nidsのIANAレジストリに入力されるURN NID登録が含まれていることを示します。

A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must:

特定のNID文字列が要求され、IETFコンセンサス（[RFC2434]で定義されている）によって割り当てられます。NID文字列には次のような制約があります。

- not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long

- すでに登録されているnidではありません - 「x-」（上記のタイプIを参照）から始めない - 「urn」（上記のタイプIIを参照）で始めるのではなく、 "xy-"で始まりません。xyは任意の組み合わせです2 ascii文字（下記のメモを参照） - 長さ2文字を超える

NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters are reserved for potential use as countrycode-based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document.

注：すべての2文字の組み合わせ、および2文字の組み合わせに続いて「 - 」と有効なNID文字のシーケンスは、URNネームスペースの最終的な国家登録のためのカントリーコードベースのNIDとして使用する潜在的な使用のために予約されています。そのような名前空間に対する責任の割り当てのためのルールの定義と範囲は、このドキュメントの範囲を超えています。

Registrations may be revised by updating the RFC through standard IETF RFC update processes (see [RFC2606] for a discussion of IETF process). In any case, a revised document, in the form of a new Internet-Draft, must be published, and the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period before pursuing publication of the new RFC document.

登録は、IETFプロセスの議論については、標準のIETF RFC更新プロセスを介してRFCを更新することにより修正できます（[RFC2606]を参照）。いずれにせよ、新しいインターネットドラフトの形式で改訂されたドキュメントを公開する必要があり、提案された更新されたテンプレートをURN-NIDディスカッションリストに配布する必要があり、2週間のレビュー期間を許可する前に、新しいRFCドキュメント。

5.0 Security Considerations

5.0 セキュリティに関する考慮事項

This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile, however there is always the danger of "spoofing" and providing mis-information. Information in these declarations should be taken as advisory.

この文書は、主に公開情報の宣言にメカニズムを提供することに焦点を当てています。名目上、これらの宣言は比較的低いセキュリティプロファイルである必要がありますが、「スプーフィング」と誤情報を提供する危険性が常にあります。これらの宣言の情報は、アドバイザリーと見なされるべきです。

6.0 IANA Considerations

6.0 IANAの考慮事項

This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA should assign the appropriate NID (informal or formal), as described above, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. This document defines processes to replace those outlined in [RFC2611].

このドキュメントでは、urnネームスペースを登録するためのプロセスの概要を説明し、維持されるレジストリの観点からIANAに影響を与えます。すべての場合において、IESGが指定した専門家が必要な登録プロセスの手順が完了したことを確認した後、IANAは適切なNID（非公式または正式）を割り当てる必要があります。このドキュメントでは、[RFC2611]で概説されているプロセスを置き換えるプロセスを定義します。

7.0 References

7.0 参考文献

[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times"

[ISO8601] ISO 8601：1988（e）、「データ要素と交換形式 - 情報交換 - 日付と時刻の表現」

[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.

[RFC1737] Sollins、K。およびL. Masinter、「統一リソース名の機能要件」、RFC 1737、1994年12月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。

[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。

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

[RFC2276] Sollins、K。、「均一なリソース名の解決の建築原理」、RFC 2276、1998年1月。

[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing Bibliographic Identifiers as Uniform Resource Names", RFC 2288, February 1998.

[RFC2288] Lynch、C.、Preston、C。、およびR. Daniel、「既存の書誌識別子をユニフォームリソース名として使用する」、RFC 2288、1998年2月。

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

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

[RFC2611] Daigle、L.、Van Gulik、D.、Iannella、R。、およびP. Faltstrom、「urn Namepace Definition Mechanisms」、RFC 2611、1999年6月。

[RFC3232] Reynolds, J, Editor, "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.

[RFC3232] Reynolds、J、Editor、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。

[RFC3305] Mealling, M. (Ed.) and R. Denenberg (Ed.), "Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations", RFC 3305, August 2002.

[RFC3305] Mealling、M。（ed。）およびR. Denenberg（ed。）、「共同W3C/IETF URI計画利息グループからのレポート：ユニフォームリソース識別子（URIS）、URLS、およびユニフォームリソース名（URNS）：明確化と推奨事項」、RFC 3305、2002年8月。

[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[RFC3401] Mealling、M。、「動的委任発見システム（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。

[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

[RFC3405] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート5：URI.ARPA割り当て手順」、RFC 3405、2002年10月。

Appendix A -- URN Namespace Definition Template

付録A- urnネームスペース定義テンプレート

Definition of a URN namespace is accomplished by completing the following information template. Apart from providing a mechanism for disclosing structure of the URN namespace, this information is designed to be useful for

URNネームスペースの定義は、次の情報テンプレートを完成させることで実現されます。urnネームスペースの構造を開示するメカニズムを提供することとは別に、この情報は役立つように設計されています

- entities seeking to have a URN assigned in a namespace (if applicable) - entities seeking to provide URN resolvers for a namespace (if applicable)

- 名前空間にurnを割り当てようとするエンティティ（該当する場合） - 名前空間にurnリゾルバーを提供しようとするエンティティ（該当する場合）

This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own.

これは、独自に作成するのではなく、既存のURNネームスペースの一部を使用する可能性を評価するコミュニティにとって特に重要です。

Applications for Formal URN namespaces must also document "Namespace Considerations", "Community Considerations" and "IANA Considerations", as described in Section 4.3.

セクション4.3で説明されているように、正式なURNネームスペースのアプリケーションは、「名前空間考慮事項」、「コミュニティの考慮事項」、「IANAの考慮事項」も文書化する必要があります。

Information in the template is as follows:

テンプレート内の情報は次のとおりです。

Namespace ID:

名前空間ID：

Assigned by IANA. In the case of a Formal NID registration, a particular NID string may be requested.

IANAによって割り当てられています。正式なNID登録の場合、特定のNID文字列が要求される場合があります。

Registration Information:

登録情報：

This is information to identify the particular version of registration information:

これは、登録情報の特定のバージョンを特定するための情報です。

- registration version number: starting with 1, incrementing by 1 with each new version - registration date: date submitted to the IANA, using the format outlined in [ISO8601]:

- 登録バージョン番号：1からの開始、新しいバージョンごとに1を増やす - 登録日：[ISO8601]で概説されている形式を使用して、IANAに提出された日付：

YYYY-MM-DD

yyyy-mm-dd

Declared registrant of the namespace: This includes: Registering organization Name Address Designated contact person Name Coordinates (at least one of: e-mail, phone, postal address)

宣言された名前空間の登録者：これは次のとおりです。

Declaration of syntactic structure:

構文構造の宣言：

This section should outline any structural features of identifiers in this namespace. At the very least, this description may be used to introduce terminology used in other sections. This structure may also be used for determining realistic caching/shortcuts approaches; suitable caveats should be provided. If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these should be listed here.

このセクションでは、この名前空間の識別子の構造的特徴を概説する必要があります。少なくとも、この説明は、他のセクションで使用される用語を導入するために使用できます。この構造は、現実的なキャッシュ/ショートカットアプローチの決定にも使用できます。適切な注意事項を提供する必要があります。特定の文字エンコードルールがある場合（たとえば、どの文字を単一引用に使用する必要があるか）、これらをここにリストする必要があります。

Answers might include, but are not limited to:

回答には含まれる場合がありますが、以下に限定されません。

- the structure is opaque (no exposition) - a regular expression for parsing the identifier into components, including naming authorities

- 構造は不透明です（博覧会なし） - 識別子を命名当局を含むコンポーネントに解析するための正規表現

Relevant ancillary documentation:

B.1 Example Template

b.1テンプレートの例

The following example is provided for the purposes of illustrating the URN NID template described in Appendix A. Although it is based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described.

次の例は、付録Aで説明したURN NIDテンプレートを説明する目的で提供されています。これは、URN WG内で非公式に議論されている仮説的な「一般的なインターネット名空間」に基づいていますが、まだ技術的およびインフラストラクチャの問題があります。そのような名前空間が適切かつ完全に記述される前に、解決する必要があります。

Namespace ID:

名前空間ID：

To be assigned

割り当てられる

Registration Information:

登録情報：

Version 1 Date: <when submitted>

バージョン1日付：<送信時>

Declared registrant of the namespace:

名前空間の登録者を宣言する：

Name: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry Contact: L. Daigle E-mail: leslie@thinkingcat.com

名前：CAT Enterprisesの思考住所：1 ThinkingCat Way Trupville、NewCountry連絡先：L。Daigle電子メール：leslie@thinkingcat.com

Declaration of structure:

構造の宣言：

The identifier structure is as follows:

識別子構造は次のとおりです。

      URN:<assigned number>:<FQDN>:<assigned string>

where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements.

FQDNは完全に資格のあるドメイン名であり、割り当てられた文字列はURN構文要件に適合しています。

Relevant ancillary documentation:

B.2 Registration steps in practice

B.2登録手順実際の手順

The key steps for registration of informal or formal namespaces typically play out as follows:

非公式または正式な名前空間の登録の重要な手順は、通常、次のように展開されます。

Informal NID:

非公式のNID：

1. Complete the registration template. This may be done as part of an Internet-Draft.

1. 登録テンプレートを完了します。これは、インターネットドラフトの一部として行われる場合があります。

2. Communicate the registration template to urn-nid@apps.ietf.org for technical review -- as a published I-D, or text e-mail message containing the template.

2. テクニカルレビューのために、登録テンプレートをurn-nid@apps.ietf.orgに伝えます - 公開されたi-d、またはテンプレートを含むテキスト電子メールメッセージ。

3. Update the registration template as necessary from comments, and repeat steps 2 and 3 as necessary.

3. 必要に応じてコメントから登録テンプレートを更新し、必要に応じて手順2と3を繰り返します。

4. Once comments have been addressed (and the review period has expired), send a request to IANA with the revised registration template.

4. コメントが扱われたら（およびレビュー期間が失効した）、改訂された登録テンプレートを使用してIANAにリクエストを送信します。

Formal NID:

正式なnid：

1. Write an Internet-Draft describing the namespace and include the registration template, duly completed. Be sure to include "Namespace Considerations", "Community Considerations" and "IANA Considerations" sections, as described in Section 4.3.

1. 名前空間を説明するインターネットドラフトを作成し、正式に完了した登録テンプレートを含めます。セクション4.3で説明されているように、「名前空間の考慮事項」、「コミュニティの考慮事項」、「IANA考慮事項」セクションを必ず含めてください。

2. Send the Internet-Draft to the I-D editor, and send a copy to urn-nid@apps.ietf.org for technical review.

2. インターネットドラフトをI-Dエディターに送信し、技術レビューのためにurn-nid@apps.ietf.orgにコピーを送信します。

3. Update the Internet-Draft as necessary from comments, and repeat steps 2 and 3 as needed.

3. 必要に応じてコメントからインターネットドラフトを更新し、必要に応じて手順2と3を繰り返します。

4. Send a request to the IESG to publish the I-D as an RFC. The IESG may request further changes (published as I-D revisions) and/or direct discussion to designated working groups, area experts, etc.

4. IESGにリクエストを送信して、I-DをRFCとして公開します。IESGは、指定されたワーキンググループ、エリアの専門家などにさらなる変更（I-Dリビジョンとして公開）および/または直接的な議論を要求する場合があります。

5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID.

5. IESGがRFCとして公開のためにドキュメントを承認した場合、要求されたNIDを登録するためにIANAにリクエストを送信します。

Appendix C -- Changes from RFC 2611

付録C- RFC 2611からの変更

This revision of [RFC2611] adds more detail describing the process of registering a URN namespace identifier (in terms of mechanical steps).

[RFC2611]のこの改訂は、URNネームスペース識別子を登録するプロセス（機械的手順の観点から）を記述する詳細を追加します。

This version of the document also separates the process (mechanics) from the discussion of the requirements for namespaces, attempting to make the latter as objective as possible.

このバージョンのドキュメントは、プロセス（メカニック）を名前空間の要件の議論から分離し、後者を可能な限り客観的にしようとします。

Throughout the document, references have been updated to the current versions of the DDDS and related documentation (which collectively obsolete [RFC2168] and related drafts).

ドキュメント全体を通して、参照はDDDの現在のバージョンと関連するドキュメント（集合的に廃止された[RFC2168]および関連ドラフト）に更新されています。

C.1 Detailed Document Changes

C.1詳細なドキュメントの変更

Added table of contents

目次が追加されました

Section 2

第2節

Clarified the definition of a URN namespace, the uniqueness of assignment, and that a single resource may have more than one identifier associated with it.

urnネームスペースの定義、割り当ての一意性、および単一のリソースには複数の識別子がそれに関連付けられている可能性があることを明確にしました。

Clarified the "number example" -- that the same string may appear in 2 different namespaces, and be applied to different resources. Originally used ISBN/ISSN example, but structurally this is not possible.

「番号の例」を明確にしました。同じ文字列が2つの異なる名前空間に表示され、異なるリソースに適用される可能性があります。もともと使用されていたISBN/ISSNの例でしたが、構造的にはこれは不可能です。

Section 3 (new)

セクション3（新）

This section explicitly defines the 3 categories of namespace -- Experimental, Informal and Formal. This section provides a description of the intended use of the different namespace types, as well as some acceptability guidelines for Formal namespaces (which require IETF review).

このセクションでは、3つのカテゴリの名前空間を明示的に定義します - 実験的、非公式、フォーマル。このセクションでは、さまざまな名前空間タイプの意図した使用の説明と、正式な名前空間の許容性ガイドライン（IETFレビューが必要です）を説明します。

Section 4.0

セクション4.0

Spelled out the name of RFC 2434 ("IANA Considerations").

RFC 2434（「IANA考慮事項」）の名前を綴りました。

Provided a pointer to the IANA URN namespace registry.

IANA urnネームスペースレジストリへのポインターを提供しました。

Sections 4.1-4.3

セクション4.1-4.3

New subsection divisions of the existing discussion of individual namespace types.

個々の名前空間タイプの既存の議論の新しいサブセクション部門。

Section 4.2

セクション4.2

Corrected reference to URN Syntax document (RFC 2141, not RFC 2168).

URN構文ドキュメントへの参照（RFC 2141、RFC 2168ではなく）への参照。

Section 4.3

セクション4.3

Added clarifying text as to the intended nature of Formal namespaces and processes for registering them.

正式な名前空間とそれらを登録するためのプロセスの意図された性質に関する明確なテキストを追加しました。

Added text to describe the requirement for a "Namespace Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.

フォーマルネームスペースを定義するRFCの「名前空間考慮事項」セクションの要件を説明するテキストが追加されました。そのセクションの必要なコンテンツを定義しました。

Added text to describe the new requirement for a "Community Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.

正式な名前空間を定義するRFCの「コミュニティ考慮事項」セクションの新しい要件を説明するテキストが追加されました。そのセクションの必要なコンテンツを定義しました。

Added text to explicitly call out the need for an "IANA Considerations" section in such RFCs, in order to alert IANA to required action.

IANAに必要なアクションを警告するために、このようなRFCの「IANA考慮事項」セクションの必要性を明示的に呼び出すためのテキストが追加されました。

Added text to further clarify the (IETF) process for revising Formal namespace registrations through the RFC and IETF review process.

RFCおよびIETFレビュープロセスを通じて正式な名前空間登録を改訂するための（IETF）プロセスをさらに明確にするためのテキストを追加しました。

Section 6

セクション6

New section -- added text to describe the IANA considerations for this document.

新しいセクション - このドキュメントのIANAの考慮事項を説明するテキストが追加されました。

Section 7 -- References

セクション7-参照

Added references to revised NAPTR documentation ([RFC3401]), and the previous version of this document ([RFC2611]).

改訂されたNAPTRドキュメント（[RFC3401]）への参照を追加し、このドキュメントの以前のバージョン（[RFC2611]）を追加しました。

Appendix A

付録A

Section created by moving the "URN Namespace Definition Template" (RFC2611's Section 3) to an appendix.

「urnネームスペース定義テンプレート」（RFC2611のセクション3）を付録に移動して作成されたセクション。

Added references to the new requirements for "Namespace Considerations", "Community Considerations", and "IANA Considerations" sections for Formal namespace registrations.

正式な名前空間登録のための「名前空間考慮事項」、「コミュニティに関する考慮事項」、「IANA考慮事項」セクションの新しい要件への参照を追加しました。

Clarified the "Declared registrant of the namespace" template element.

「名前空間の登録者」テンプレート要素を明確にしました。

Added text to describe the purpose and scope of the "Validating Mechanism".

「検証メカニズム」の目的と範囲を説明するテキストが追加されました。

Appendix B

付録B

Section B.1 is the "example template" that was "Section 5" in RFC 2611.

セクションB.1は、RFC 2611の「セクション5」であった「サンプルテンプレート」です。

Update the sample "declared registrant" data per the changes to the template description.

テンプレートの説明の変更ごとに、サンプル「登録された登録者」データを更新します。

Removed the reference to "US-ASCII" in the "namespace specific string" of the example namespace.

サンプル名空間の「名前空間固有の文字列」で「us-ascii」への参照を削除しました。

Section B.2 (new)

セクションB.2（新）

This added section is a step-by-step walkthrough of the process for registering Informal namespaces and Formal namespaces.

この追加セクションは、非公式の名前空間と正式な名前空間を登録するためのプロセスの段階的なウォークスルーです。

Authors' Addresses

著者のアドレス

Leslie L. Daigle Thinking Cat Enterprises

レスリーL.デイグル思考猫企業

   EMail: leslie@thinkingcat.com

Dirk-Willem van Gulik WebWeaving Internet Engineering Nieuwsteeg 37A 2311 RZ Leiden The Netherlands

Dirk-Willem Gulik WebWeaving Internet Engineering NieuwSteeg 37a 2311 Rz Leiden The Netherlands

   URL:    http://www.webweaving.org/
   Email:  dirkx@webweaving.org

Renato Iannella IPR Systems Pty Ltd.

   EMail: renato@iprsystems.com

Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA

   EMail: paf@cisco.com

Full Copyright Statement

完全な著作権声明

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

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

RFCエディター機能の資金は現在、インターネット協会によって提供されています。