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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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は、ユニフォームリソース名（のURN）[RFC2141]の構文、並びにそれらの解決のためにいくつかの提案されたメカニズムを定義し、インターネットアプリケーションで使用している（[RFC2168、RFC2169]）。全体がURN構造内の個々の「名前空間」をコンセプトにかかっています。離れてプルーフ・オブ・コンセプトの名前空間からの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に準拠していないすべての文字列は、必ずしも有効にURNです。 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.
すなわち、（URNの構文定義あたり）すべての構文的に正しい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
URNの目的のために、「名前空間は」一意に割り当てられた識別子のコレクションです。 URN名前空間自体がために、識別子を持っています
- ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier
- のURNのグローバル一意性を保証 - （所望の場合）識別子の構造のためのキューを提供
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コードとISSNsは、従来の出版の世界で使用される識別子の両方のコレクションです。 2つのコレクションのために異なる指定子を使用して、有効なISBN識別子とISSN識別子の両方でいくつかの番号（または番号）が存在してもよいしながら、どの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を求めることにより真正URN名前空間になることが可能なプロセスを概説します。一言で言えば、名前空間の定義のためのテンプレートは、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によってインクリメント - 登録日：IANAに提出された日付、[ISO 8601]で概説されるようにフォーマットYYYY-MM-DDを用いました。
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
- 当局の命名を含む成分に識別子を解析するための正規表現、 - 構造は（NO博覧会）不透明です
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
- 名前空間の構文を概説するRFC - 名前空間を導入する説明資料 - 名前空間の識別子の構文を概説定義コミュニティの（例えば、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識別子の非再割り当てがURNも「リソースの寿命」の後に特定のリソースを識別する際に持続することを保証するが、いくつかの考慮事項は、URNのユーザビリティの持続性に与えられるべきです。これは、世界的な解像度を提供する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:
このセクションの細部べきリソースへのURNを割り当てるためのメカニズム及び/又は当局。これは、割り当てが完全に開いているかどうかを明確にしなければならない、または制限された場合、どのように識別子のアサイになるために、および/または既存の割当当局によって割り当てられたものを得ます。回答には含めることができ、これらに限定されません：
- 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)
- 割り当ては、特定のアルゴリズム以下、完全に開いている - 割り当ては、特定の組織によって認識当局に委任された（例えば、デジタルオブジェクト識別子財団は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).
名前空間はグローバルな解決のためにアクセスできるように意図されている場合は、RDSにregisterdしなければならないなどNAPTRとして（決議発見システム、[RFC2276]を参照）。解像度は、次いで、標準的なURI解決プロセス、およびRDSの機構に従って進行します。何このセクションは概説すべきことは、この名前空間でのURNの認識リゾルバになる（と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文字列自体に）、ルールは、ここに提供することができます。
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".
- 識別子、文字列でハイフン付きと非ハイフネーションされたグループの間の等価 - 単一引用符と二重引用符の間の等価 - など「付加記号の有無にかかわらず、文字X」などの特定の文字の間の名前空間に定義された等価性、。
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.
名前空間がURNの以外のコンテキストで使用されている場合、それはURN構文で予約されている文字を使用してもよいです。このセクションでは、フラグは、どのような文字べき、と構文をURNに準拠するために必要なマッピングの概要を説明します。通常、これは、シンボルを符号化するヘクスによって処理されるであろう。
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コードは、「割り当てられたURNs」に直接翻訳することは明らかではありません。
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 IDの解釈に影響を与える可能性がある字句等価性のためのルールを追加または削除、例えば）URN文字列の構造的な解釈になされるべきです。しかし、名前空間の生涯の自然かけなど、許可されたURNのassignersのリストを展開し、明確化を導入することが重要です。具体的な処理の概要は以下のとおりです。
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.
サービスの期待水準と登録のために必要な手順で区別ここで定義されたURN名前空間の3つのカテゴリーがあります。さらに、登録保守手順は、一つのカテゴリから別のものにわずかに変化します。
I. Experimental: These are not explicitly registered with IANA. They take the form
I.実験：これらは明示的にIANAに登録されていません。彼らは形を取ります
X-<NID>
X <NOT>
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-" <番号>
where <number> is chosen by the IANA on a First Come First Served basis (see [RFC2434]).
<番号>最初に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
うｒんーにｄ＠あっｐｓ。いえｔｆ。おｒｇ
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]).
<番号>の唯一の制限は、それが数字で厳密に構成され、それは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
うｒんーにｄ＠あっｐｓ。いえｔｆ。おｒｇ
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
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文字の組み合わせ「 - 」と有効な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により作製することができます。いずれの場合も、提案更新されたテンプレートは、2週間の審査期間を考慮して、URN-NIDディスカッションリストに循環させなければなりません。
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.猫Eメール：leslie@thinkingcat.com所属：考える猫企業住所：1 ThinkingCatウェイTrupville、NewCountry
Declaration of structure:
構造体の宣言：
The identifier structure is as follows:
次のように識別子の構造は次のとおりです。
URN:<assigned number>:<FQDN>:<assigned US-ASCII string>
URN：<割り当てられた番号>：<FQDN>：<割り当てられたUS-ASCII文字列>
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：操作上、再割り当てされているからドメイン名を妨げるものは何もありません。確かに、それは珍しいことでは発生しません。これは、この例では、実際には貧しいURN名前空間を作り、それが立っているようので、真剣に提案されていないことを理由の一つです。識別子の永続性の考慮事項：
Persistence of identifiers is dependent upon suitable delegation of resolution at the level of "FQDN"s, and persistence of FQDN assignment.
識別子の持続性は、適切な「FQDN」Sのレベルで解像度の委任、及び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.
（FQDNのための）個々のドメイン名の所有者に委任これらのURNの割り当て。 FQDN登録のホルダがNAPTR RDSにエントリを維持する（又はそれを委譲）する必要があります。これらの委任名前のパーティションのそれぞれの中で、文字列は、地域の要件ごとに割り当てることもできます。
e.g. urn:<assigned number>:thinkingcat.com:001203
例えばURN：<割り当てられた番号>：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
FQDNが大文字と小文字を区別しません。したがって、URNの部分
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]ダニエル、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.、RFC 2169 "URNの解決にHTTPを使用するための些細な条約"、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]リンチ、C.、プレストン、C.とR.ダニエル、 "統一リソース名として既存の図書目録の識別子を使用する"、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]堀、R.、 "URN構文"、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. Daigle氏猫の企業を考えます
EMail: leslie@thinkingcat.com
メールアドレス：leslie@thinkingcat.com
Dirk-Willem van Gulik ISIS/STA/CEO - TP 270 Joint Research Centre Ispra 21020 Ispra (Va) Italy.
ダーク・ウィレム・バン・ガリクISIS / STA / CEO - TP 270共同研究センターイスプラ21020イスプラ（VA）イタリア。
Phone: +39 332 78 9549 or 5044 Fax: +39 332 78 9185 EMail: Dirk.vanGulik@jrc.it
電話：+39 332 78 9549または5044ファックス：+39 332 78 9185 Eメール：Dirk.vanGulik@jrc.it
Renato Iannella DSTC Pty Ltd Gehrmann Labs, The Uni of Queensland AUSTRALIA, 4072
レナートIannella DSTC Pty LtdのGehrmann研究所、クイーンズランド州オーストラリアのユニ、4072
Phone: +61 7 3365 4310 Fax: +61 7 3365 4311 EMail: renato@dstc.edu.au
電話：+61 7 3365 4310ファックス：+61 7 3365 4311 Eメール：renato@dstc.edu.au
Patrik Faltstrom Tele2/Swipnet Borgarfjordsgatan 16 P.O. Box 62 S-164 94 Kista SWEDEN
パトリックFaltstrom TELE2 / Swipnet Borgarfjordsgatan 16私書箱ボックス62のS-164 94シスタSWEDEN
Phone: +46-5626 4000 Fax: +46-5626 4200 EMail: paf@swip.net
電話：+ 46-5626 4000ファックス：+ 46-5626 4200 Eメール：paf@swip.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。