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

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

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

      Uniform Resource Names (URN) Namespace Definition Mechanisms

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を指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2002）。全著作権所有。

Abstract

抽象

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

この文書では、一般の定義と統一リソース名（URN）「名前空間」を確立するためのメカニズムをレイアウトします。 URN WGは、RFC 2141でのURN、並びにその解決のためのいくつかの提案メカニズムのための構文を定義し、RFC 3401と全体のURN構造内の個々の「名前空間」をコンセプトにかかっているRFC 3405でインターネットアプリケーションで使用しています。別に概念実証の名前空間から、URNの中の既存の識別子を使用することは、RFC 2288で説明されています。

Table of Contents

   1.0 Introduction ................................................. 2
   2.0 What is a URN Namespace? ..................................... 3
   3.0 URN Namespace (Registration) Types ........................... 3
   3.1 Experimental Namespaces .....................................  4
   3.2 Informal Namespaces .........................................  4
   3.3 Formal Namespaces ...........................................  4
   4.0 URN Namespace Registration, Update, and NID Assignment
       Process .....................................................  6
   4.1 Experimental ................................................  6
   4.2 Informal ....................................................  6
   4.3 Formal ......................................................  7
   5.0 Security Considerations .....................................  9

   6.0 IANA Considerations .........................................  9
   7.0 References ..................................................  9
   Appendix A -- URN Namespace Definition Template ................. 11
   Appendix B -- Illustration ...................................... 15
   B.1 Example Template ............................................ 15
   B.2 Registration steps in practice .............................. 17
   Appendix C -- Changes from RFC 2611 ............................. 18
   C.1 Detailed Document Changes ................................... 19
   Authors' Addresses .............................................. 21
   Full Copyright Statement ........................................ 22

1.0 Introduction

1.0はじめに

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

ユニフォームリソース名（URNの）位置独立資源の識別、ならびに参照の寿命を可能にするための特定の要件を有するリソース識別子です。 URNのは、資源の持続的な命名を提供するという具体的な目標を持つ大規模のURI（Uniform Resource Identifier）の家族[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に準拠していないすべての文字列は、必ずしも有効に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, as well as provide the mechanism for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority (IANA).

この文書の目的は、機構の概要を説明し、明示的な名前空間定義のためのテンプレートを提供し、ならびにインターネット割り当て番号機関（登録されている（「名前空間ID」、またはNIDと呼ばれる）識別子を関連付けるための機構を提供することですIANA）。

Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the

この文書はURN名前空間を作成するためのプロセスの説明に自分自身を制限することに注意してください。任意のそのように作成されたURN識別子の「解像度」が望まれる場合、そのようなにより提供されるようなグローバルNIDディレクトリに登録の別個のプロセス、

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名前空間とは何ですか？

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:

URNの目的のために、「名前空間は」一意に割り当てられた識別子のコレクションです。それは、識別子は、これまで以上の1つのリソースに割り当てられていない、また彼らは、これまでさまざまなリソースに再割り当てされている、です。単一のリソースは、しかし、異なる目的のためにそれに割り当てられた複数のURNを有することができます。 URN名前空間自体がために、識別子があります。

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

- のURNのグローバル一意性を保証 - （所望の場合）識別子の構造のためのキューを提供

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

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

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

識別子構造の開発、およびそれによって、識別子の集合、それらが置かれるためにそれらが割り当てられることになるか、識別子を定義するコミュニティの要件、および使用に本質的に依存しているプロセスがあります。これらの問題のすべては、名前空間を定義しようとしている個々のコミュニティに固有である（例えば、出版コミュニティ、書店の関連、プロトコルの開発者、など）。彼らは、IETF URNの仕事の範囲を超えています。

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

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

3.0 URN Namespace (Registration) Types

3.0 URN名前空間（登録）タイプ

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

サービスの期待水準と登録のために必要な手順で区別ここで定義されたURN名前空間の3つのカテゴリがあります。これらの名前空間の種類ごとに、登録プロセスは、セクション4.0に記載されています。

3.1 Experimental Namespaces

3.1実験名前空間

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

これらは、明示的に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の衝突を回避するために行われません。彼らは内部または限定された実験的なコンテキスト内での使用を目的としています。

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はセクション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.

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

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

（付録Aで）登録テンプレートで定義された基本登録情報に加えて、正式な名前空間の要求は、新しい名前空間の必要性と正式に提案したURN名前空間を確立するから、コミュニティの利益の文書化について考慮しなければなりません。

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

URNの目標は、永続的な識別情報を提供することであるため、また、名前空間の長寿と保守性に関しては、いくつかの考慮が与えられなければなりません。 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.

これらの態様は、客観的に定量化するのは難しいものの、正式なURN名前空間の開発を検討組織/人によって考慮されるべきであり、任意の提案の正式な名前空間の技術的なメリットを評価するとき、彼らは心の中で保持されます。

4.0 URN Namespace Registration, Update, and NID Assignment Process

4.0 URN名前空間の登録、更新、およびNID割り当てプロセス

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

開示の異なるレベルの名前空間のために定義/期待されています。開示を囲むオープンフォーラムのディスカッションのレベルに応じて、URN名前空間を割り当てることができるか、または特定の識別子を要求することができます。時々、そうする権威を与えられ、そしてプロセスはどのようなものさ - 「IANAの考慮事項」ドキュメント[RFC2434]は登録の更新メカニズムを指定する必要性を示唆しています。 URNのが持続的に有用であることが意図されているので、いくつかの（もしあれば）の変更が（すでに割り当てられたURN IDの解釈に影響を与える可能性がある字句等価性のためのルールを追加または削除、例えば）URN文字列の構造的な解釈になされるべきです。しかし、名前空間の生涯の自然かけなど、許可されたURNのassignersのリストを展開し、明確化を導入することが重要です。具体的な処理の概要は以下のとおりです。

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

ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／うｒんーなめｓぱせｓ

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

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

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

登録および保守手順（セクション3.0で定義されるように）の名前空間のタイプから別のものに若干異なります。

4.1 Experimental

4.1実験

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

これらは、明示的にIANAに登録されていません。彼らは形をとります。

X-<NID>

X <NOT>

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

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

何も登録がないので、何も登録保守手順は必要ありません。

4.2 Informal

非公式4.2

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

これらは、IANAに登録された形式で、識別子として数列が割り当てられます。

"urn-" <number>

"urn-" <番号>

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 Appendix A), duly completed, to:

登録者は、登録テンプレート（付録Aを参照）、正式に、完成のコピーを送信する必要があります。

urn-nid@apps.ietf.org

うｒんーにｄ＠あっｐｓ。いえｔｆ。おｒｇ

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

そして、名前空間の提案への技術的な改善のための登録情報や提案の発現を明確にするための2週間の議論の期間を可能にします。

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

登録情報の明確化のための提案が組み込まれた後、テンプレートはNIDへの割り当てのために提出することができます。

iana@iana.org

いあな＠いあな。おｒｇ

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

<番号>の唯一の制限は、それが数字で厳密に構成され、それはNIDはURN構文（[RFC2141]）で概説長さの制限を超えることがないようにということです。

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

上記のように登録は、登録テンプレートを更新し、さらに2週間の議論期間のディスカッションリストにそれを提出し、最終的にIANAにそれを再送信することによって、元の登録、又は登録者により指定されたエンティティによって更新されてもよいです。

4.3 Formal

フォーマル4.3

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

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

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

「IETFコンセンサス - 新値はIETFの合意プロセスを経て割り当てられている具体的には、新しい割り当てがIESGによって承認されたRFCを介して行われ一般的に存在する場合、IESGは、例えば（適切な人物からの将来の割り当てに関連する作業部会を入力を求めます。）。」

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

従って、正式なNIDアプリケーションは、標準的なIETF RFC工程を経ての刊行を介して行われます。 RFCは標準トラックである必要はないが、それはIESGレビューと受け入れ、ここで書かれたガイドラインに従った（だけでなく、標準のRFC公開ガイドライン）の対象となります。付録Aで定義されたテンプレートは、名前空間の他のいくつかの側面を定義するRFCの一部として含まれてもよいし、あるいは、それ自体でRFCとして提唱することができます。提案されたテンプレートはに送信する必要があります。

urn-nid@apps.ietf.org

うｒんーにｄ＠あっｐｓ。いえｔｆ。おｒｇ

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

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

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

RFCは、（既存の名前空間が提案の要件に満たない、すなわち、）新しい名前空間の認知の必要性を概説し、「名前空間の考慮事項」のセクションを含める必要があります。

Considerations might include:

検討事項は、次のものがあります

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

- URNの割り当て手順 - URN解像度/委任 - リソースの種類を識別する - サービスの種類がサポートされるように

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

注：これは、複数の名前空間が同じ「機能」の目的を果たすことが期待されています。「名前空間の考慮事項」のセクションの意図は、IESGの検討のために、既存の可能性を探求して提案の「デュー・ディリジェンス」の記録を提供することです。

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

RFCはまた、一般のインターネット利用者は、彼ら場合はスペースを使用することができますどのようにだけでなく、提案者は、そのコミュニティがこの名前空間の出版によって恩恵を受けることができるように期待していた時に寸法を示し、「コミュニティの考慮事項」のセクションを含める必要がありますそうする気に。潜在的な考慮事項は次のとおりです。

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

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

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

RFC文書はURNのNIDのIANAレジストリに入力されるURN NID登録を含むことを示し、「IANAの考慮事項」の項を含んでいなければなりません。

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文字の長さで - 2つのASCII文字（以下、注を参照）

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 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プロセスの議論のために[RFC2606]を参照）標準IETF RFC更新プロセスを通してRFCを更新することによって変更することができます。いずれの場合も、改訂された文書は、新しいインターネットドラフトの形で、公開されている必要があり、提案更新されたテンプレートは、の出版を要請する前に、2週間の審査期間を考慮して、URN-NIDディスカッションリストに循環させる必要があります新しいRFCドキュメント。

5.0 Security Considerations

5.0セキュリティの考慮事項

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

この文書では、主に公開情報の宣言するための機構を提供することに焦点を当てています。名目上は、これらの宣言は、比較的低いセキュリティプロファイルのものでなければならない、しかしそこに「なりすまし」の危険性は常にあると誤情報を提供します。これらの宣言内の情報は助言として解釈されるべきです。

6.0 IANA Considerations

6.0 IANAの考慮事項

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

この文書では、URN名前空間を登録するためのプロセスを概説し、レジストリの面でIANAのための含意が維持されなければなりません。 IESGが指定した専門家が必要な登録処理の手順が完了していることを確認した後、上記のようにすべての場合において、IANAは、（非公式または正式な）適切なNIDを割り当てる必要があります。この文書では、[RFC2611]に概説したものを置き換えるためのプロセスを定義します。

7.0 References

7.0参考資料

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

[ISO8601] ISO 8601：1988（E）、 "データ要素と交換フォーマット - 情報交換 - 日付と時刻の表現"

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

[RFC1737] Sollins、K.とL. Masinter、 "統一リソース名のための機能要件"、RFC 1737、1994年12月。

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

[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。

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

[RFC2141]堀、R.、 "URN構文"、RFC 2141、1997年5月。

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

[RFC2276] Sollins、K.、 "ユニフォームリソース名前解決の建築原則"、RFC 2276、1998年1月。

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

[RFC2288]リンチ、C.、プレストン、C.とR.ダニエル、 "統一リソース名として既存の図書目録の識別子を使用する"、RFC 2288、1998年2月。

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

[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。

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

[RFC2611] Daigle氏、L.、バンGulik、D.、Iannella、R.とP. Faltstrom、 "URN名前空間定義メカニズム"、RFC 2611、1999年6月。

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

[RFC3232]レイノルズ、J、エディタは、：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。

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

[RFC3305] Mealling、M.（エド）とR. Denenberg（編）、「共同W3C / IETF URI計画インタレストグループからのレポート：ユニフォームリソース識別子（URI）、URL、およびリソース名（URNの）制服：明確化と提言」、RFC 3305、2002年8月。

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

[RFC3401] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。

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

[RFC3405] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、RFC 3405、2002年10月。

Appendix A -- URN Namespace Definition Template

付録A - URN名前空間の定義テンプレート

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

URN名前空間の定義は、以下の情報テンプレートを完了することによって達成されます。 URN名前空間の構造を開示するための機構を提供することから離れて、この情報は、のために有用であるように設計されています

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

- 実体が名前空間のURNレゾルバを提供しようとしている（該当する場合） - URNは（該当する場合）の名前空間に割り当てられているしようとしているエンティティ

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

これは、既存のURN名前空間の一部を使用してではなく、自分自身を作成する可能性を評価するコミュニティにとって特に重要です。

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

4.3節で説明したように正式なURN名前空間のためのアプリケーションはまた、「名前空間の考慮事項」、「コミュニティの考慮事項」および「IANAの考慮事項」を文書化する必要があります。

Information in the template is as follows:

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

Namespace ID:

名前空間ID：

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

IANAによって割り当てられました。フォーマルNID登録の場合には、特定のNID文字列が要求されてもよいです。

Registration Information:

登録情報：

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

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

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

- 登録バージョン番号：1から始まる、それぞれの新しいバージョンと1によってインクリメント - 登録日：IANAに提出された日付、[ISO 8601]で概説フォーマットを使用：

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)

名前空間の宣言された登録者：これは含まれています：登録組織名アドレス指定の接触人の名前の座標を（の少なくとも1つの電子メール、電話、郵便アドレス）

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:

関連の補助ドキュメント：

Definition of domain names, found in:

で見つかったドメイン名の定義：

P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, November 1987.

P. Mockapetris、 "ドメイン名 - 実装と仕様"、RFC 1035、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.

N.B：操作上、再割り当てされているからドメイン名を妨げるものは何もありません。確かに、それは珍しいことでは発生しません。これは、この例では、実際には貧しいURN名前空間を作り、それが立っているようので、真剣に提案されていないことを理由の一つです。

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.

上記と同じノート。

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.

これらのURNの割り当て（FQDNのために）個々のドメイン名の所有者に委任されます。 FQDN登録のホルダがエントリを維持する（又はそれを委任）DDDSにする必要があります。これらの委任名前のパーティションのそれぞれの中で、文字列は、地域の要件ごとに割り当てることもできます。

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-insensitive for matches. The remainder of the identifier must be considered case-sensitive.

大文字と小文字を区別しない一致するものです。識別子の残りは大文字と小文字を区別考慮しなければなりません。

Conformance with URN Syntax:

URN構文に準拠：

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:

非公式ありません：

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

1.登録テンプレートを完了します。これは、インターネットドラフトの一環として行われてもよいです。

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

公表I-Dとして、またはテキストの電子メールメッセージテンプレートを含む - 2.技術的なレビューのために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.

改訂された登録テンプレートをIANAに要求を送信、コメント一度4.対処されている（と審査期間が満了しています）。

Formal 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. RFCとしてI-Dを公開するためにIESGにリクエストを送信します。 IESG等指定ワーキンググループ、地域の専門家に（I-Dの改訂として公開）さらなる変更及び/又は直接議論を要求することができます

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

5. IESGがRFCとして公表のための文書を承認した場合、要求されたNIDを登録するにはIANAにリクエストを送信します。

Appendix C -- Changes from RFC 2611

付録C - RFC 2611からの変更点

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

[RFC2611]のこの改訂は、（機械的ステップに関して）URN名前空間識別子を登録する処理を説明する詳細を追加します。

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

文書のこのバージョンは、できるだけ目的として、後者を作成しようとすると、名前空間の要件の説明から工程（力学）を分離します。

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

文書全体を通して、参照がDDDSと関連ドキュメント（総称廃止[RFC2168]および関連するドラフト）の現在のバージョンに更新されています。

C.1 Detailed Document Changes

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

Added table of contents

目次を追加

Section 2

第2節

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

URN名前空間、割り当ての一意の定義を明確にし、単一のリソースは、それに関連付けられた複数の識別子を有することができます。

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

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

Section 3 (new)

第3節（新）

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

、実験非公式と正式な - このセクションでは、明示的に名前空間の3つのカテゴリーを定義します。このセクションでは、別の名前空間の種類の使用目的の説明と同様に、（IETF審査が必要）正式な名前空間のためのいくつかの受容性のガイドラインを提供します。

Section 4.0

セクション4.0

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

RFC 2434（「IANAの考慮事項」）の名前をスペルアウト。

Provided a pointer to the IANA URN namespace registry.

IANA URN名前空間のレジストリへのポインタを提供します。

Sections 4.1-4.3

セクション4.1から4.3

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

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

Section 4.2

4.2節

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

URN構文ドキュメントに補正された基準（RFC 2141、RFC 2168ではありません）。

Section 4.3

4.3節

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

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

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

正式な名前空間を定義するRFCの「名前空間の考慮事項」セクションの要件を説明するテキストを追加しました。そのセクションの必要な内容を定義しました。

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

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

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

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

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

さらにRFCとIETF審査プロセスを経て正式な名前空間の登録を見直すための（IETF）のプロセスを明確にするテキストを追加しました。

Section 6

セクション6

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

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

Section 7 -- References

セクション7 - 参考文献

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

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

Appendix A

付録A

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

付録に「URN名前空間の定義テンプレート」（RFC2611のセクション3）を移動することで作成されたセクション。

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

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

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

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

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

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

Appendix B

付録B

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

B.1節はRFC 2611で「第5」であった「例のテンプレート」です。

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

サンプルを更新したテンプレートの説明を変更あたりのデータ「登録者を宣言しました」。

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

例えば、名前空間の「名前空間の特定の文字列」の「US-ASCII」への参照を削除しました。

Section B.2 (new)

B.2節（新）

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

この追加されたセクションは、非公式の名前空間と正式な名前空間を登録する処理のステップバイステップのチュートリアルです。

Authors' Addresses

著者のアドレス

Leslie L. Daigle Thinking Cat Enterprises

レスリーL. Daigle氏猫の企業を考えます

EMail: leslie@thinkingcat.com

メールアドレス：leslie@thinkingcat.com

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

ダーク・ウィレム・バン・ガリクWebWeavingインターネット技術Nieuwsteeg 37A 2311 RZライデン、オランダ

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

URL：http://www.webweaving.org/ Eメール：dirkx@webweaving.org

Renato Iannella IPR Systems Pty Ltd.

レナートIannella IPRシステムのPty株式会社

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シスコシステムズ株式会社170 WタスマンドライブSJ-2分の13サンノゼCA 95134 USA

EMail: paf@cisco.com

メールアドレス：paf@cisco.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2002）。全著作権所有。

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機能のための基金は現在、インターネット協会によって提供されます。