RFC3406 日本語訳
3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L.Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT=43707 bytes) (Obsoletes RFC2611) (Also BCP0066) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 3406の考え深い猫エンタープライズBCP: 66 D. w.Gulik Obsoletesをバンに積んでください: 2611年のWebWeavingカテゴリ: 最も良い現在の練習のIannella IPRシステムP.FaltstromコクチマスR.2002年10月
Uniform Resource Names (URN) Namespace Definition Mechanisms
一定のリソースは(つぼ)名前空間定義をメカニズムと命名します。
Status of this Memo
この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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはUniform Resource Namesを設立するための一般的な定義とメカニズム(URN)「名前空間」を広げます。 URN WGは構文がRFC2141のURNsのために定義されて、RFC3401とRFC3405のインターネットアプリケーションにおける彼らの解決と使用のためにいくつかの提案されたメカニズムを定義されました。 全体がURN構造の中で個々の「名前空間」の概念にかかっています。 概念の証拠名前空間は別として、RFC2288でURNsにおける既存の識別子の使用について議論しました。
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
1.0序論… 2 2.0 URN Namespaceは何ですか? ..................................... 3 3.0 つぼの名前空間(登録)タイプ… 3 3.1の実験的な名前空間… 4 3.2の非公式の名前空間… 4 3.3の正式な名前空間… 4 4.0のつぼの名前空間登録、アップデート、およびNID課題は処理されます… 6 4.1 実験的… 6 4.2 非公式… 6 4.3 正式… 7 5.0 セキュリティ問題… 9
Daigle, et. al. Best Current Practice [Page 1] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[1ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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
6.0 IANA問題… 9 7.0の参照箇所… 9 付録A--つぼの名前空間定義テンプレート… 11付録B--、イラスト… 15B.1例のテンプレート… 15 B.2登録は実際には踏まれます… 17 付録C--RFC2611からの変化… 18 C.1はドキュメント変化について詳述しました… 19人の作者のアドレス… 21 完全な著作権宣言文… 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.
一定のResource Names(URNs)はリソースの可能な位置の独立している識別のための決められた一定の要求があるリソース識別子です、参照の寿命と同様に。 URNsはリソースのしつこい命名を提供するという明確な目標がある、より大きいUniform Resource Identifier(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.
すなわち、すべてのシンタクス上正しいURN名前空間(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).
このドキュメントの目的は、明白な名前空間定義にメカニズムについて概説して、テンプレートを提供して、インターネットAssigned民数記Authorityに登録される識別子(「Namespace 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
このドキュメントがそれ自体をURN名前空間の創造のための過程の記述に制限することに注意してください。 どんなしたがって、作成されたURN識別子の「解決」も望まれているなら、それなどのグローバルなNIDディレクトリの登録の別々の過程は提供されました。
Daigle, et. al. Best Current Practice [Page 2] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[2ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
DDDS system [RFC3401], is necessary. See [RFC3405] for information on obtaining registration in the DDDS global NID directory.
DDDSシステム[RFC3401]が必要です。 DDDSのグローバルなNIDディレクトリにおける登録を得ることの情報に関して[RFC3405]を見てください。
2.0 What is a URN Namespace?
2.0 URN Namespaceは何ですか?
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つ以上のリソースに割り当てられません、そして、それらはかつて、異なったリソースに再選任されません。 しかしながら、ただ一つのリソースで、異なる役割のために1URNをそれに割り当てるかもしれません。 URN名前空間自体には識別子がある、:
- ensure global uniqueness of URNs
- (where desired) provide a cue for the structure of the
identifier
- URNsのグローバルなユニークさ--識別子の構造に手がかりを供給するのを(必要であるところ)確実にしてください。
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において異なった有効な識別子が異なったリソースのために同じようにいいえ、2URNsがあるシステム2つの収集に異なった指示子を使用すると確実にされる識別子を確立したという(各収集が唯一各識別子を割り当てるのに必要であるので)ことである数個の数があるのが想像できます。
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を入手することによって誠実なURN名前空間になることができる過程について概説します。 殻では、名前空間の定義のためのテンプレートはIANAとの預金で完成します、そして、NIDは割り当てられます。 NIDストリングのための過程と可能性の詳細は以下に概説されています。
3.0 URN Namespace (Registration) Types
3.0 つぼの名前空間(登録)タイプ
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.
登録のための予想水準のサービスと必要な手順によってここで定義されて、顕著なURN名前空間の3つのカテゴリがあります。 セクション4.0でこれらの名前空間タイプ各人のための登録手続を与えます。
Daigle, et. al. Best Current Practice [Page 3] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[3ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
実験的なNIDsの衝突を避けるのに備えます。 彼らは内部の、または、限られた実験関係の中の使用のために意図します。
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.
これらはそれに加えてすべての権利と要件が関連している完全なURN名前空間です。 グローバルな登録サービスで非公式の名前空間を登録できます。 リソースのしつこい識別、および識別子ストリングのユニークな課題を提供して、彼らはよく管理されたURN名前空間の綱領を上げなければなりません。 非公式の、そして、正式な名前空間(以下で、説明される)はNID課題において異なります。 IANAは1セクション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.
正式な名前空間は要求されたかもしれません、そして、IETFレビューは求めました、NID提案と基本的な名前空間の公表がインターネットでユーザの何らかの部分集合への利益を提供する場合で。 受け入れるなら、すなわち、正式な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.
いくつかの局面が完全に開くというわけではないところでFormal NIDsが名前空間に適用されるかもしれないと予想されます。 例えば、名前空間は名前空間における、URNsの課題に料金ベースの、または、個人的に管理されたか、独占である登録を利用するかもしれませんが、関連づけられたサービスがオープンにアクセス・プロトコルを発表したなら、それはまだ何人かのインターネットユーザへの利益を提供しているかもしれません。
Daigle, et. al. Best Current Practice [Page 4] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[4ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
登録テンプレート(Appendix 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共同体の集合的な経験は識別の寿命を防ぐ技術的な要素の豊富な情報を含んでいます。 または、IESGが、IETF共同体コンセンサスがそれが防ぐ技術的な欠点を含んでいるということであるなら提案された名前空間RFCを発行しないのを選ぶかもしれない、(真剣に可能性を損なう、)、しつこい識別。
The kinds of things the URN WG discussed included:
URN 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.
客観的に定量化しにくいのですが、これらの局面はFormal URN名前空間の開発を考える組織/人々によって考えられるべきです、そして、どんな提案されたFormal名前空間の技術的な長所も評価するとき、彼らは覚えておかれるでしょう。
Daigle, et. al. Best Current Practice [Page 5] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[5ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
4.0 URN Namespace Registration, Update, and NID Assignment Process
4.0のつぼの名前空間登録、アップデート、および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]は登録証明書(時々そうする権威は与えられている)と過程であることのためにアップデートメカニズムを指定する必要性を示します。 URNsが持続して役に立つことが意味されるので、わずかな(もしあれば)変更しか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:
登録されたURN名前空間に関する株式相場表はIANAによって維持されます。 URN名前空間登録証明書は現在、公開FTPディレクトリに掲示されています:
http://www.iana.org/assignments/urn-namespaces
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.
登録と保守手順は1つの名前空間タイプ(セクション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.
実験的なNIDsの衝突を避けるのに備えます。 彼らは内部の、または、限られた実験関係の中の使用のために意図します。
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>
「つぼ」<番号>。
Daigle, et. al. Best Current Practice [Page 6] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[6ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
where <number> is chosen by the IANA on a First Come First Served basis (see [RFC2434]).
<番号>がFirst Come First ServedベースのIANAによって選ばれている([RFC2434]を見てください)ところ。
Registrants should send a copy of the registration template (see Appendix A), duly completed, to:
記入者は以下のことのために正しく完成した登録テンプレート(Appendix Aを見る)のコピーを送るはずです。
urn-nid@apps.ietf.org
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
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]).
<番号>における唯一の制限はケタから厳密に成って、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]:
正式なNIDsは[RFC2434]で定義されるようにIETF Consensusを通して割り当てられます:
"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 Consensus--新しい値はIETFコンセンサスを得るためのプロセスで割り当てられます。」 明確に、IESGによって承認されたRFCsを通して新しい課題をします。 「通常、IESGは適切な人々から将来の課題に関する入力を求めるでしょう(例えば関連作業部会は1であるなら存在します)。」
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:
したがって、標準のIETFの過程でRFCの公表でFormal NIDアプリケーションをします。 RFCは規格道である必要はありませんが、ここ(標準のRFC公表ガイドラインと同様に)に書かれたガイドラインによると、それはIESGレビューと承認を受けることがあるでしょう。 Appendix Aで定義されたテンプレートが名前空間のある他の局面を定義するRFCの一部として含まれるかもしれませんか、またはそれはRFCとしてそれ自体で進められるかもしれません。 提案されたテンプレートを送るべきである、:
urn-nid@apps.ietf.org
urn-nid@apps.ietf.org
Daigle, et. al. Best Current Practice [Page 7] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[7ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
以下に注意してください。 1つ以上の名前空間が同じ「機能的な」目的に役立つかもしれないと予想されます。 「名前空間問題」セクションの意図は提案者の「適切な注意」に関する記録を既存の可能性を探るのに提供することです、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
- 「つぼ」(Type IIが上であることを見ます)(XYが2個のASCII手紙のあらゆる組み合わせである(注意を見てください、下)"XY"での始めでない)で既に登録されたNID(「x」(Type Iが上であることを見る)との始めでない)が始めでなかったなら、長い間、2個以上の手紙になってください。
Daigle, et. al. Best Current Practice [Page 8] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[8ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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文字の組み合わせ、およびcountrycodeベースのNIDsとしてのつぼの名前空間の最後の国家の登録証明書の「-」があとに続いた組み合わせと有効なNIDキャラクタのどんな系列も予約される2文字の潜在的使用。 そのような名前空間への責任の配分のための規則を定義と見ることはこのドキュメントの範囲を超えています。
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 RFC更新処理でRFCをアップデートすることによって、改訂されるかもしれません(IETFの過程の議論に関して[RFC2606]を見てください)。 どのような場合でも、新しいインターネット草稿の形で改訂されたドキュメントを発表しなければなりません、そして、提案されたアップデートされたテンプレートはつぼ-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が維持される意味を持っています。 すべての場合では、IANAは適切なNID(非公式の、または、正式な)を割り当てるはずです、上で説明されるように、IESGによって指定された専門家が、必要な登録工程段階が完成したといったん確認すると。 このドキュメントは、[RFC2611]に概説されたものを取り替えるために過程を定義します。
7.0 References
7.0の参照箇所
[ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats
- Information interchange - Representation of dates and
times"
[ISO8601]ISO8601: 1988(E)、「データ要素と置き換え形式--情報交換--日付と回の表現」
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC1737] SollinsとK.とL.Masinter、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
Daigle, et. al. Best Current Practice [Page 9] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[9ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998.
[RFC2276]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing
Bibliographic Identifiers as Uniform Resource Names", RFC
2288, February 1998.
[RFC2288] リンチとC.とプレストンとC.とR.ダニエル、「一定のリソース名として既存の図書目録の識別子を使用します」、RFC2288、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2611] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
"URN Namespace Definition Mechanisms", RFC 2611, June 1999.
[RFC2611]Daigle(L.)はGulikとD.とIannellaとR.とP.Faltstrom、「つぼの名前空間定義メカニズム」、RFC2611、1999年6月をバンに積みます。
[RFC3232] Reynolds, J, Editor, "Assigned Numbers: RFC 1700 is
Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232] レイノルズ、J、エディタ、「数は割り当てられました」。 「RFC1700はOn-線DatabaseによるReplacedです」、RFC3232、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]食事、M.編、およびR.Denenberg編は「共同W3C/IETF URI計画営利団体から以下を報告します」。 Uniform Resource Identifier(URI)、URL、および一定のリソース名(つぼ): 「明確化と推薦」、RFC3305、8月2002日
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", RFC 3405,
October 2002.
[RFC3405]食事、M.、「ダイナミックな代表団発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。
Daigle, et. al. Best Current Practice [Page 10] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[10ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
Appendix A -- URN Namespace Definition Template
付録A--つぼの名前空間定義テンプレート
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.
また、Formal URN名前空間のアプリケーションはセクション4.3で説明されるように「名前空間問題」、「共同体問題」、および「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によって割り当てられます。 Formal 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)
名前空間の宣言している記入者: これは: 組織のName Address Designated連絡窓口のName Coordinatesを登録します。(少なくとも1、: メール、電話、郵便の宛先)
Daigle, et. al. Best Current Practice [Page 11] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[11ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
このセクションはいずれもRFCs、規格、または名前空間構造のすべてか一部が定義するか、またはわかる他の発行されたドキュメンテーションを記載するべきです。
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
- 個別に識別子が連続して割り当てられるという情報が差し控えられるというユニークさの規則を尊敬するのに原因となる識別子の構造の博覧会、および課題当局の識別子のスペースの仕切り。 名前空間は不透明です。
Daigle, et. al. Best Current Practice [Page 12] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[12ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
このセクションは、URNsをリソースに割り当てるためにメカニズム、そして/または、当局について詳述するべきです。 課題が完全に開いているか、または制限されるなら、それは明らかにされるべきです、識別子の指定人になる、そして/または、既存の課題当局に1つを割り当てさせる方法。
Answers could include, but are not limited to:
含むことができましたが、答えは制限されません:
- 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財団はDOI課題スペースとその代表団を制御します)--課題は完全に終えられます。(例えば、民間のための)
Process for identifier resolution:
識別子解決には、処理してください:
If a namespace is intended to be accessible for global resolution,
it must be registered in an RDS (Resolution Discovery System, see
[RFC2276]) such as DDDS. 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).
名前空間がグローバルな解決にアクセスしやすいことを意図するなら、DDDSなどのRDS(解決ディスカバリーSystem、[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をアップデートするためのメカニズムで--解決は課題が代表として派遣された実体によって制御されます。
Daigle, et. al. Best Current Practice [Page 13] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[13ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
2つの識別子の間には、基本的な名前空間(したがって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:
つぼの構文との順応:
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構文に従うのに必要である特別な問題について概説するべきです。 これはURNsの文脈で使用される遺産命名システムの場合で特に適切です。
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.
例えば、名前空間がURNs以外の文脈で使用されるなら、それはURN構文で予約されるキャラクタを利用するかもしれません。
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構文に従うために必要なマッピングについて概説するべきです。 通常、これはシンボルをコード化する十六進法によって扱われるでしょう。
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 mechanisms for "validating" a URN -- i.e., determining
whether a given string is currently a validly-assigned URN. There
are 2 issues here: 1) users should not "guess" URNs in a
namespace; 2) when the URN namespace is based on an existing
identifier system, it may not be the case that all the existing
identifiers are assigned on Day 0. The reasonable expectation is
that the resource associated with each resulting URN is somehow
related to the thing identified by the original identifier system,
but those resources may not exist for each original identifier.
For example, even if a telephone number-based URN namespace was
created, it is not clear that all telephone numbers would
URNの解決を試みることは別として、URN名前空間はURNが「有効にする」であるのにメカニズムを提供するかもしれません--すなわち、現在与えられたストリングが確実に割り当てられたURNであるかどうか決定します。 2冊がここにあります: 1) ユーザは名前空間でURNsを「推測するべきではありません」。 2) URN名前空間が既存の識別子システムに基づいているとき、すべての既存の識別子がデー0で割り当てられるのは、事実でないかもしれません。 合理的な期待はそれぞれの結果として起こるURNに関連しているリソースがどうにかオリジナルの識別子システムによって特定されたものに関連するということですが、それらのリソースはそれぞれのオリジナルの識別子のために存在しないかもしれません。 例えば、電話番号ベースのURN名前空間が作成されたとしても、すべての電話番号がないのは明確ではありません。
Daigle, et. al. Best Current Practice [Page 14] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[14ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
immediately become "valid" URNs, that could be resolved using
whatever mechanisms are described as part of the namespace
registration.
至急、「有効な」URNsになってください、そして、名前空間登録の一部として記述されているどんなメカニズムも使用することでそれは決議できるでしょう。
Validation mechanisms 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名前空間を提案するのは妥当です。
Appendix B -- Illustration
付録B--イラスト
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.
以下の例がAppendix A.Althoughで説明されたURN NIDテンプレートを例証する目的のために、URN WGの中で非公式に議論した仮定している「一般的なインターネット名前空間」に基づいているかどうかということである、まだ、そのような名前空間について適切に、そして完全に説明できる前に解決されなければならない技術的でインフラストラクチャの問題があります。
Namespace ID:
名前空間ID:
To be assigned
割り当てられるために
Registration Information:
レジスト情報:
Version 1
Date: <when submitted>
バージョン1日付: <、いつが>を提出したか。
Daigle, et. al. Best Current Practice [Page 15] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[15ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
Declared registrant of the namespace:
名前空間の宣言している記入者:
Name: Thinking Cat Enterprises
Address: 1 ThinkingCat Way
Trupville, NewCountry
Contact: L. Daigle
E-mail: leslie@thinkingcat.com
以下を命名してください。 考え深い猫エンタープライズアドレス: Trupville、1つのThinkingCat方法に、NewCountryは以下に連絡します。 L。 Daigleはメールします: leslie@thinkingcat.com
Declaration of structure:
構造の宣言:
The identifier structure is as follows:
識別子構造は以下の通りです:
URN:<assigned number>:<FQDN>:<assigned string>
URN: <は数の>を割り当てました: <FQDN>: <はストリング>を割り当てました。
where FQDN is a fully-qualified domain name, and the assigned
string is conformant to URN syntax requirements.
FQDNが完全修飾ドメイン名であり、割り当てられたストリングがURN構文要件へのconformantであるところ。
Relevant ancillary documentation:
関連付属のドキュメンテーション:
Definition of domain names, found in:
以下で見つけられたドメイン名の定義
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC 1035, November 1987.
P.Mockapetris、「ドメイン名--、実現AND仕様、」、RFC1035、11月1987日
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.
N.B.: 操作上、何もドメイン名が再選任されるのを防ぐものがありません。 本当に、それはまれな出来事ではありません。 これはこの例が実際には貧しいURN名前空間を作って、したがって、立つように真剣に提案されていない理由の1つです。
Identifier persistence considerations:
識別子固執問題:
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.
上記の同じ注意。
Daigle, et. al. Best Current Practice [Page 16] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[16ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
Process of identifier assignment:
識別子課題の過程:
Assignment of these URNs is 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 DDDS.
Within each of these delegated name partitions, the string may be
assigned per local requirements.
個々のドメイン名所有者(FQDNsのための)へこれらのURNsの課題を代表として派遣します。 FQDN登録の所有者はDDDSでエントリー(それを代表として派遣する)を維持しなければなりません。 それぞれのこれらの代表として派遣された名前パーティションの中では、ストリングは地方の要件単位で割り当てられるかもしれません。
e.g., urn:<assigned number>:thinkingcat.com:001203
例えば、つぼ: <規定番号>: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.
ドメイン名所有者はそれらがURNsを割り当てたFQDNのために解決サーバを操作するか、または代表として派遣するのに責任があります。
Rules for Lexical Equivalence:
語彙等価性のための規則:
FQDNs are case-insensitive. Thus, the portion of the URN
FQDNsは大文字と小文字を区別しないです。 その結果、URNの一部
urn:<assigned number>:<FQDN>:
つぼ: <規定番号>: <FQDN>:
is case-insensitive for matches. The remainder of the identifier
must be considered case-sensitive.
マッチにおいて、大文字と小文字を区別しないです。 大文字と小文字を区別していると識別子の残りを考えなければなりません。
Conformance with URN Syntax:
つぼの構文との順応:
No special considerations.
特別な問題がありません。
Validation mechanism:
合法化メカニズム:
None specified.
なにも指定しませんでした。
Scope:
範囲:
Global.
グローバル。
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. 登録テンプレートを完成してください。 インターネット草稿の一部としてこれをするかもしれません。
Daigle, et. al. Best Current Practice [Page 17] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[17ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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. 技術審査のために発行されたI-D、またはテンプレートを含むテキストメールメッセージとして登録テンプレートを urn-nid@apps.ietf.org に伝えてください。
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に送って、RFCとしてI-Dを発行してください。 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として公表のためのドキュメントを承認するなら、要求をIANAに送って、要求されたNIDを登録してください。
Appendix C -- Changes from RFC 2611
付録C--RFC2611からの変化
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).
ドキュメント中では、DDDSと関連するドキュメンテーション(どのまとめて時代遅れの[RFC2168]と関連する草稿)の最新版に参照をアップデートしたか。
Daigle, et. al. Best Current Practice [Page 18] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[18ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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名前空間の定義、課題のユニークさ、およびそのaただ一つのリソースはそうしたかもしれません。1つの識別子がそれに関連づけたよりさらに。
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つのカテゴリを定義します--、実験的である、InformalとFormal。 このセクションは異なった名前空間タイプの意図している使用の記述を提供します、Formal名前空間(IETFレビューを必要とする)のためのいくつかの受容性ガイドラインと同様に。
Section 4.0
セクション4.0
Spelled out the name of RFC 2434 ("IANA Considerations").
RFC2434(「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 Syntaxドキュメント(RFC2168ではなく、RFC2141)の直っている参照。
Section 4.3
セクション4.3
Added clarifying text as to the intended nature of Formal namespaces and processes for registering them.
それらを登録するためのFormal名前空間と過程の意図している本質に関してテキストをはっきりさせながら、加えられます。
Added text to describe the requirement for a "Namespace Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.
Formal名前空間を定義するRFCsの「名前空間問題」セクションのための要件について説明するためにテキストを加えました。 そのセクションの必要な内容を定義しました。
Daigle, et. al. Best Current Practice [Page 19] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[19ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
Added text to describe the new requirement for a "Community Considerations" section in RFCs defining Formal namespaces. Defined the required content of that section.
Formal名前空間を定義するRFCsの「共同体問題」セクションのための新しい要件について説明するためにテキストを加えました。 そのセクションの必要な内容を定義しました。
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を警告して、明らかにそのようなRFCsの「IANA問題」セクションの必要性を呼び出すためにテキストを加えました。
Added text to further clarify the (IETF) process for revising Formal namespace registrations through the RFC and IETF review process.
さらにRFCとIETF吟味の過程によるFormal名前空間登録証明書を改訂するための(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.
「つぼの名前空間定義テンプレート」(RFC2611のセクション3)を付録に動かすことによって創設されたセクション。
Added references to the new requirements for "Namespace Considerations", "Community Considerations", and "IANA Considerations" sections for Formal namespace registrations.
Formal名前空間登録証明書のために新しい要件の「名前空間問題」、「共同体問題」、および「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は「RFC2611のセクション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.
例の名前空間の「名前空間の特定のストリング」の「米国-ASCII」の参照を取り除きました。
Daigle, et. al. Best Current Practice [Page 20] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[20ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
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.
この加えられたセクションはInformal名前空間とFormal名前空間を登録するための過程の段階的なウォークスルーです。
Authors' Addresses
作者のアドレス
Leslie L. Daigle Thinking Cat Enterprises
猫計画を考えるレスリーL.Daigle
EMail: leslie@thinkingcat.com
メール: leslie@thinkingcat.com
Dirk-Willem van Gulik WebWeaving Internet Engineering Nieuwsteeg 37A 2311 RZ Leiden The Netherlands
DirkウィレムバンGulik WebWeavingインターネットEngineering Nieuwsteeg 37A2311RZライデンオランダ
URL: http://www.webweaving.org/ Email: dirkx@webweaving.org
URL: http://www.webweaving.org/ メール: dirkx@webweaving.org
Renato Iannella IPR Systems Pty Ltd.
レナートIannella IPRシステムPty Ltd.
EMail: renato@iprsystems.com
メール: renato@iprsystems.com
Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA
パトリクFaltstromシスコシステムズInc170Wタスマン・ドライブSJ-13/2サンノゼカリフォルニア95134米国
EMail: paf@cisco.com
メール: paf@cisco.com
Daigle, et. al. Best Current Practice [Page 21] RFC 3406 URN Namespace Definition Mechanisms October 2002
et Daigle、アル。 最も良い現在の練習の[21ページ]RFC3406つぼの名前空間定義メカニズム2002年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daigle, et. al. Best Current Practice [Page 22]
et Daigle、アル。 最も良い現在の習慣[22ページ]
一覧
スポンサーリンク
