[要約] RFC 2611は、URN名前空間の定義メカニズムに関する規格であり、URNの構造と解決方法を定義しています。その目的は、URNを一意に識別するための一貫した方法を提供することです。
Network Working Group L. Daigle
Request for Comments: 2611 Thinking Cat Enterprises
BCP: 33 D. van Gulik
Category: Best Current Practice ISIS/CEO, JRC Ispra
R. Iannella
DSTC Pty Ltd
P. Faltstrom
Tele2/Swipnet
June 1999
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). 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 ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces".
URN WGは、ユニフォームリソース名（URNS）[RFC2141]の構文と、インターネットアプリケーションでの解像度と使用のための提案されたメカニズムを定義しています（[RFC2168、RFC2169]）。全体は、ur構造内の個々の「名前空間」の概念に基づいています。概念の証明名空間とは別に、URNでの既存の識別子の使用が議論されており（[RFC2288]）、この文書は、uRN「名前空間」を確立するための一般的な定義とメカニズムを表しています。
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. There are 2 assumptions that are key to this document:
ユニフォームのリソース名（URN）は、リソースの場所に依存しない識別を可能にするための特定の要件と、参照の長寿です。このドキュメントの鍵となる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, along with the mechanism for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority, IANA.
このドキュメントの目的は、メカニズムの輪郭を描き、明示的な名前空間定義のテンプレートを提供することと、インターネットに割り当てられた番号当局IANAに登録されている識別子（「名前空間ID」またはNIDと呼ばれる）を関連付けるメカニズムとともにです。
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 NAPTR system [RFC2168], is necessary. See [NAPTR-REG] for information on obtaining registration in the NAPTR global NID directory.
このドキュメントは、urnネームスペースを作成するためのプロセスの説明に制限されていることに注意してください。いわゆるURN識別子の「解像度」が望まれる場合、NAPTRシステム[RFC2168]によって提供されるようなグローバルNIDディレクトリでの登録の個別のプロセスが必要です。NAPTRグローバルNIDディレクトリで登録を取得する詳細については、[Naptr-Reg]を参照してください。
For the purposes of URNs, a "namespace" is a collection of uniquely-assigned identifiers. A URN namespace itself has an identifier in order to
urnsの目的のために、「名前空間」は、一意に割り当てられた識別子のコレクションです。urnネームスペース自体には、
- ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier
- urのグローバルな一意性を確保 - （必要な場合）識別子の構造にキューを提供します
For example, ISBNs and ISSNs are both collections of identifiers used in the traditional publishing world; while there may be some number (or numbers) that is both a valid ISBN identifier and ISSN identifier, using different designators for the two collections ensures that no two URNs will be the same for different resources.
たとえば、ISBNとISSNはどちらも従来の出版界で使用されている識別子のコレクションです。有効なISBN識別子とISSN識別子の両方であるいくつかの数（または数字）がある場合がありますが、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; first, a template for the definition is provided.
このドキュメントでは、特定の制約（割り当ての一意性など）を満たす識別子のコレクションが、NIDを取得することにより真正なurnamesスペースになるプロセスの概要を説明します。一言で言えば、名前空間の定義のテンプレートがIANAに堆積するために完了し、NIDが割り当てられます。NID文字列のプロセスと可能性の詳細については、以下に概説します。まず、定義のテンプレートが提供されます。
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ネームスペースの一部を使用する可能性を評価するコミュニティにとって特に重要です。
Information in the template is as follows:
テンプレート内の情報は次のとおりです。
Namespace ID: Assigned by IANA. In some contexts, a particular one may be requested (see below).
名前空間ID：IANAによって割り当てられています。一部のコンテキストでは、特定のコンテキストが要求される場合があります（以下を参照）。
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 YYYY-MM-DD as outlined in [ISO8601].
- 登録バージョン番号：1から始まる新しいバージョンごとに1倍になる - 登録日：[ISO8601]で概説されている形式yyyy-mm-ddを使用して、IANAに提出されます。
Declared registrant of the namespace:
名前空間の登録者を宣言する：
Required: Name and e-mail address. Recommended: Affiliation, address, etc.
必須：名前と電子メールアドレス。推奨：所属、住所など
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:
関連する補助文書：
This section should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure.
このセクションでは、名前空間構造のすべてまたは一部を定義または説明するRFC、標準、またはその他の公開されたドキュメントをリストする必要があります。
Answers might include, but are not limited to:
回答には含まれる場合がありますが、以下に限定されません。
- RFCs outlining syntax of the namespace - Other of the defining community's (e.g., ISO) documents outlining syntax of the identifiers in the namespace - Explanatory material introducing the namespace
- 名前空間の構文を概説するRFCS-名前空間内の識別子の構文を概説するコミュニティの定義型コミュニティ（例えば、ISO）ドキュメント - 名前空間を紹介する説明資料
Identifier uniqueness considerations: This section should address the requirement that URN identifiers be assigned uniquely -- they are assigned to at most one resource, and are not reassigned.
識別子の一意性の考慮事項：このセクションでは、urn識別子が一意に割り当てられるという要件に対処する必要があります。最大1つのリソースに割り当てられ、再割り当てされていません。
(Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.)
（「リソース」の定義はかなり広いことに注意してください。たとえば、「今日の天気」に関する情報は、コンテンツは動的ですが、単一のリソースと見なされる可能性があります。）
Possible answers include, but are not limited to:
考えられる回答には含まれますが、これらに限定されません。
- exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules - identifiers are assigned sequentially - information is withheld; the namespace is opaque
- 識別子の構造の説明、および一意性規則を尊重することを個別に責任を負う割り当て当局間の識別子のスペースの分割 - 識別子は順次割り当てられます - 情報は源泉徴収されます。名前空間は不透明です
Identifier persistence considerations:
識別子の持続性の考慮事項：
Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after the "lifetime of the resource", some consideration should be given to the persistence of the usability of the URN. This is particularly important in the case of URN namespaces providing global resolution.
urn識別子の非定期は、「リソースの寿命」の後でも特定のリソースを識別するのに骨nが持続することを保証しますが、urの使いやすさの持続性を考慮する必要があります。これは、グローバルな解像度を提供するURNネームスペースの場合に特に重要です。
Possible answers include, but are not limited to:
考えられる回答には含まれますが、これらに限定されません。
- quality of service considerations
- サービスの質の考慮事項
Process of identifier assignment:
識別子割り当てのプロセス：
This section should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities. Answers could include, but are not limited to:
このセクションでは、urをリソースに割り当てるためのメカニズムおよび/または当局の詳細を詳述する必要があります。割り当てが完全にオープンであるか、制限されている場合、識別子の割り当て者になる方法、および/または既存の課題当局によって割り当てられたものを取得するかどうかを明確にする必要があります。回答には含まれる可能性がありますが、以下に限定されません。
- assignment is completely open, following a particular algorithm - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation) - assignment is completely closed (e.g., for a private organization)
- 特定のアルゴリズムに従って、割り当ては完全に開かれています - 割り当ては特定の組織によって認識された当局に委任されます（たとえば、Digital Object Identifier FoundationはDOI割り当てスペースとその代表団を制御します） - 割り当ては完全に閉じられています（例：民間組織の場合）
Process for identifier resolution:
識別子解像度のプロセス：
If a namespace is intended to be accessible for global resolution, it must be registerd in an RDS (Resolution Discovery System, see [RFC2276]) such as NAPTR. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so-listed in the RDS registry).
名前空間がグローバル解像度のためにアクセスできることを意図している場合、NAPTRなどのRDS（解像度発見システム、[RFC2276]を参照）に登録する必要があります。解像度は、標準のURI解像度プロセスとRDSのメカニズムに従って進行します。このセクションの概要は、この名前空間で認識されているurnsのリゾルバーになるための要件です（RDSレジストリでこのようにリストされています）。
Answers may include, but are not limited to:
回答には含まれる場合がありますが、以下に限定されません。
- the namespace is not listed with an RDS; this is not relevant - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS - resolution is controlled by entities to which assignment has been delegated
- 名前空間にはRDSがリストされていません。これは関連性がありません - 解像度ミラーリングは完全に開かれており、適切なRDSを更新するメカニズムを備えています - 解決は、割り当てが委任されたエンティティによって制御されます
Rules for Lexical Equivalence:
語彙の等価性のルール：
If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (hence, in the URN string itself), rules can be provided here.
基礎となる名前空間（したがって、urn文字列自体の）の2つの識別子間の等価性を決定するための特定のアルゴリズムがある場合、ここでルールを提供できます。
Some examples include:
いくつかの例は次のとおりです。
- equivalence between hyphenated and non-hyphenated groupings in the identifier string - equivalence between single-quotes and double-quotes - Namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks".
- 識別子文字列におけるハイフンと非麻痺のグループ化の等価 - 単一引用符と二重引用符の等価 - 「ダイアクリティックマークの有無にかかわらず」などの特定の文字間の名前空間定義の等価性。
Note that these are not normative statements for any kind of best practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules.
これらは、キャラクター間の同等性を処理するためのあらゆる種類のベストプラクティスの規範的な声明ではないことに注意してください。それらは、名前空間のルールを反映することに限定された声明です。
Conformance with URN Syntax:
urn構文への適合：
This section should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used in the context of URNs.
このセクションでは、URN構文に準拠するために必要な特別な考慮事項の概要を説明する必要があります。これは、URNのコンテキストで使用されるレガシーネーミングシステムの場合に特に適用されます。
For example, if a namespace is used in contexts other than URNs, it may make use of characters that are reserved in the URN syntax. This section should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by hex encoding the symbol.
たとえば、名前空間がurns以外のコンテキストで使用されている場合、urn構文に予約されている文字を使用する場合があります。このセクションは、そのような文字にフラグを立て、urn構文に準拠するために必要なマッピングの概要を説明する必要があります。通常、これはシンボルをエンコードするHEXによって処理されます。
For example, see the section on SICIs in [RFC2288].
たとえば、[RFC2288]のSICISのセクションを参照してください。
Validation mechanism:
検証メカニズム：
Apart from attempting resolution of a URN, a URN namespace may provide mechanism for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. For example, even if an ISBN URN namespace is created, it is not clear that all ISBNs will translate directly into "assigned URNs".
urnの解像度を試みることとは別に、urnネームスペースは、urnを「検証」するメカニズムを提供する場合があります。つまり、特定の文字列が現在有効に割り当てられたurnであるかどうかを判断します。たとえば、ISBN urnの名前空間が作成されたとしても、すべてのISBNが「割り当てられたurn」に直接翻訳されることは明らかではありません。
A validation mechanims might be:
検証メカニムは次のとおりです。
- a syntax grammar - an on-line service - an off-line service
- 構文文法 - オンラインサービス - オフラインサービス
Scope:
範囲：
This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN namespace for "this nation's social security numbers".
このセクションでは、この名前空間で識別子の使用範囲を概説する必要があります。プライベートネームスペースと公共の名前の考慮事項は別として、このセクションは、要求されたNIDの適用性を評価する上で重要です。たとえば、「社会保障番号」を扱うと主張する名前空間には、グローバルな範囲があり、すべての社会保障番号構造（ありそうもない）に対処する必要があります。一方、全国レベルでは、「この国の社会保障番号」のurnネームスペースを提案することは合理的です。
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 [RFC2434] document 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ネームスペースが割り当てられるか、特定の識別子を要求する場合があります。[RFC2434]ドキュメントは、登録の更新メカニズムを指定する必要性を示唆しています。登録機関は、そのための権限を随時与えられ、プロセスは何ですか。urnは持続的に有用であることを意図しているため、urn文字列の構造解釈に変更する必要があります（たとえば、すでに割り当てられているurn IDの解釈に影響を与える可能性のある語彙の同等性のルールを追加または削除します）。ただし、名前空間の生涯の自然な過程で、明確化を導入し、認定されたurn割り当て者のリストなどを拡張することが重要かもしれません。特定のプロセスを以下に概説します。
There are 3 categories of URN namespaces defined here, distinguished by expected level of service and required procedures for registration. Furthermore, registration maintenance procedures vary slightly from one category to another.
ここで定義されている3つのカテゴリには、予想されるサービスレベルと登録に必要な手順によって区別されます。さらに、登録メンテナンス手順は、カテゴリごとにわずかに異なります。
I. Experimental: These are not explicitly registered with IANA. They take the form
I.実験：これらは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.
登録がないため、登録メンテナンス手順は必要ありません。
II. Informal: These are registered with IANA and are assigned a number sequence as an identifier, in the format:
ii。非公式：これらは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 section 3.0), duly completed, to the
登録者は、登録テンプレートのコピーを送信する必要があります（セクション3.0を参照）、正式に記入してください。
urn-nid@apps.ietf.org
urn-nid@apps.ietf.org
mailing and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for improvements to the namespace proposal.
郵送および登録情報の表現と、名前空間提案の改善のための提案を明確にするための2週間の議論期間を許可します。
After suggestions for clarification of the registration information have been incorporated, the template may be submitted to: iana@iana.org
登録情報を明確にするための提案が組み込まれた後、テンプレートはiana@iana.orgに提出することができます
for assignment of a NID.
nidの割り当て用。
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 ([RFC2168]).
<number>の唯一の制限は、桁で厳密に構成され、nidがurn構文で概説されている長さの制限を超えないことです（[rfc2168]）。
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に再提出することにより、元の登録者または登録者が指定したエンティティによって更新される場合があります。
III. Formal: These are processed through an RFC review process. The RFC need not be standards-track. The template defined in section 3.0 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
iii。フォーマル：これらはRFCレビュープロセスを通じて処理されます。RFCは標準トラックである必要はありません。セクション3.0で定義されているテンプレートは、名前空間の他の側面を定義するRFCの一部として含まれている場合があります。または、それ自体がRFCとして提出される場合があります。提案されたテンプレートはに送信する必要があります
urn-nid@apps.ietf.org
urn-nid@apps.ietf.org
mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG progresses the document to RFC status.
IESGがドキュメントをRFCステータスに進める前に、登録情報の表現を明確にするための2週間の議論期間を許可するメーリングリスト。
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 updated by updating the RFC through standard IETF RFC update mechanisms. Thus, proposals for updates may be made by the original authors, other IETF participants, or the IESG. In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period.
登録は、標準のIETF RFC更新メカニズムを介してRFCを更新することにより更新できます。したがって、更新の提案は、元の著者、他のIETF参加者、またはIESGによって行われる場合があります。いずれにせよ、提案された更新されたテンプレートは、URN-NIDディスカッションリストに循環し、2週間のレビュー期間を可能にする必要があります。
URN namespace registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/".
urnネームスペース登録は、匿名のFTPディレクトリ「ftp://ftp.isi.edu/in-notes/iana/assignments/urn-namespaces/」に投稿されます。
The following example is provided for the purposes of illustration of the URN NID template described in section 3.0. 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.
次の例は、セクション3.0で説明されているURN NIDテンプレートの説明の目的で提供されています。これは、urn WG内で非公式に議論されている仮説的な「一般的なインターネットネームスペース」に基づいていますが、そのような名前空間が適切かつ完全に記述される前に解決する必要がある技術的およびインフラストラクチャの問題がまだあります。
Namespace ID: To be assigned
名前空間ID：割り当てられます
Registration Information:
登録情報：
Version 1 Date: <when submitted>
バージョン1日付：<送信時>
Declared registrant of the namespace:
名前空間の登録者を宣言する：
Required: Name and e-mail address. Recommended: Affiliation, address, etc.
必須：名前と電子メールアドレス。推奨：所属、住所など
Declared registrant of the namespace:
名前空間の登録者を宣言する：
Name: T. Cat E-mail: leslie@thinkingcat.com Affiliation: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry
名前：T。猫の電子メール：leslie@thinkingcat.com提携：思考猫の企業住所：1 ThinkingCat Way Trupville、NewCountry
Declaration of structure:
構造の宣言：
The identifier structure is as follows:
識別子構造は次のとおりです。
URN:<assigned number>:<FQDN>:<assigned US-ASCII string>
where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements.
FQDNは完全に資格のあるドメイン名であり、割り当てられた文字列はURN構文要件に適合しています。
Relevant ancillary documentation:
関連する補助文書：
Definition of domain names, found in:
で見つかったドメイン名の定義：
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC1035, November 1987.
P. Mockapetris、「ドメイン名 - 実装と仕様」、RFC1035、1987年11月。
Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned string is never reassigned for a given FQDN, and that the FQDN is never reassigned.
識別子の一意性に関する考慮事項：割り当てられた文字列が特定のFQDNに対して再割り当てされず、FQDNが再割り当てされない限り、一意性が保証されます。
N.B.: operationally, there is nothing that prevents a domain name from being reassigned; indeed, it is not an uncommon occurrence. This is one of the reasons that this example makes a poor URN namespace in practice, and is therefore not seriously being proposed as it stands. Identifier persistence considerations:
N.B。：操作的に、ドメイン名が再割り当てされるのを妨げるものは何もありません。確かに、それは珍しい出来事ではありません。これは、この例が実際に貧しいurnamesスペースを作る理由の1つであり、したがって、それが立っているときに真剣に提案されていません。識別子の持続性の考慮事項：
Persistence of identifiers is dependent upon suitable delegation of resolution at the level of "FQDN"s, and persistence of FQDN assignment.
識別子の持続性は、「FQDN」のレベルでの解像度の適切な委任、およびFQDN割り当ての持続に依存します。
Same note as above.
上記と同じメモ。
Process of identifier assignment:
識別子割り当てのプロセス：
Assignment of these URNs delegated to individual domain name holders (for FQDNs). The holder of the FQDN registration is required to maintain an entry (or delegate it) in the NAPTR RDS. Within each of these delegated name partitions, the string may be assigned per local requirements.
これらのurの割り当ては、個々のドメイン名保有者（FQDNSの場合）に委任されました。FQDN登録の所有者は、NAPTR RDSでエントリ（または委任）を維持するために必要です。これらの委任された各名前パーティション内で、文字列はローカル要件ごとに割り当てられる場合があります。
e.g. urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution:
識別子解像度のプロセス：
Domain name holders are responsible for operating or delegating resolution servers for the FQDN in which they have assigned URNs.
ドメイン名ホルダーは、URNを割り当てたFQDNの解像度サーバーを操作または委任する責任があります。
Rules for Lexical Equivalence:
語彙の等価性のルール：
FQDNs are case-insensitive. Thus, the portion of the URN
fqdnsは症例に依存しません。したがって、urの部分
urn:<assigned number>:<FQDN>:
urn：<割り当て番号>：<fqdn>：
is case-insenstive for matches. The remainder of the identifier must be considered case-sensitve.
一致の場合はケース非感受性です。識別子の残りの部分は、症例に敏感であると見なす必要があります。
Conformance with URN Syntax:
urn構文への適合：
No special considerations.
特別な考慮事項はありません。
Validation mechanism:
検証メカニズム：
None specified.
何も指定されていません。
Scope:
範囲：
Global.
グローバル。
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.
この文書は、主に公開情報の宣言にメカニズムを提供することに焦点を当てています。名目上、これらの宣言は比較的低いセキュリティプロファイルである必要がありますが、常に「スプーフィング」し、誤った情報を提供する危険があります。これらの宣言の情報は、アドバイザリーと見なされるべきです。
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[RFC2168] Daniel、R。およびM. Mealling、「ドメイン名システムを使用した均一なリソース識別子の解像度」、RFC 2168、1997年6月。
[RFC2169] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[RFC2169]ダニエル、R。、「urn解像度でHTTPを使用するための些細な慣習」、RFC 2169、1997年6月。
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times"
[ISO8601] ISO 8601：1988（e）、「データ要素と交換形式 - 情報交換 - 日付と時刻の表現」
[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月。
[NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS URI Resolution", Work in Progress.
[Naptr-Reg] Mealling、M。、「Naptr DNS URI解像度の割り当て手順」、進行中の作業。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。
[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月。
[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月。
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[RFC2276] Sollins、K。、「均一なリソース名の解決の建築原理」、RFC 2276、1998年1月。
Leslie L. Daigle Thinking Cat Enterprises
レスリーL.デイグル思考猫企業
EMail: leslie@thinkingcat.com
Dirk-Willem van Gulik ISIS/STA/CEO - TP 270 Joint Research Centre Ispra 21020 Ispra (Va) Italy.
Dirk -Willem Gulik ISIS/STA/CEO -TP 270共同研究センターISPRA 21020 ISPRA（VA）イタリア。
Phone: +39 332 78 9549 or 5044
Fax: +39 332 78 9185
EMail: Dirk.vanGulik@jrc.it
Renato Iannella DSTC Pty Ltd Gehrmann Labs, The Uni of Queensland AUSTRALIA, 4072
Renato Iannella Dstc Pty Ltd Gehrmann Labs、クイーンズランドオーストラリアの大学、4072
Phone: +61 7 3365 4310
Fax: +61 7 3365 4311
EMail: renato@dstc.edu.au
Patrik Faltstrom Tele2/Swipnet Borgarfjordsgatan 16 P.O. Box 62 S-164 94 Kista SWEDEN
Patrik Faltstrom Tele2/Swipnet borgarfjordsgatan 16 P.O.Box 62 SE-164 94 Kista Sweden
Phone: +46-5626 4000
Fax: +46-5626 4200
EMail: paf@swip.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。