[要約] RFC 7595は、URIスキームのガイドラインと登録手続きに関するものであり、URIスキームの一貫性と互換性を確保することを目的としています。
Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 7595 Microsoft
Obsoletes: 4395 T. Hansen
BCP: 35 AT&T Laboratories
Category: Best Current Practice T. Hardie
ISSN: 2070-1721 Google
June 2015
Guidelines and Registration Procedures for URI Schemes
URIスキームのガイドラインと登録手順
Abstract
概要
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.
このドキュメントは、Uniform Resource Identifier（URI）スキームの定義に関するガイドラインと推奨事項、およびIANA登録プロセスを更新します。 RFC 4395は廃止されました。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7595.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7595で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Permanent Scheme Definitions . . . . . . . . 4
3.1. Demonstrable, New, Long-Lived Utility . . . . . . . . . . 4
3.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 4
3.3. Well Defined . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Definition of Operations . . . . . . . . . . . . . . . . 6
3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . 6
3.6. Internationalization and Character Encoding . . . . . . . 7
3.7. Clear Security and Privacy Considerations . . . . . . . . 7
3.8. Scheme Name Considerations . . . . . . . . . . . . . . . 8
3.9. Interoperability Considerations . . . . . . . . . . . . . 9
4. Guidelines for Provisional URI Scheme Registration . . . . . 9
5. Guidelines for Historical URI Scheme Registration . . . . . . 10
6. Guidelines for Private URI Scheme Use . . . . . . . . . . . . 10
7. URI Scheme Registration Procedure . . . . . . . . . . . . . . 10
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Registration Procedures . . . . . . . . . . . . . . . . . 11
7.3. Change Control . . . . . . . . . . . . . . . . . . . . . 13
7.4. URI Scheme Registration Template . . . . . . . . . . . . 13
8. The "example" URI Scheme . . . . . . . . . . . . . . . . . . 14
8.1. "example" URI Scheme Registration Request . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributor . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
The Uniform Resource Identifier (URI) protocol element and generic syntax is defined by [RFC3986]. Each URI begins with a scheme name, as defined by Section 3.1 of RFC 3986, that refers to a specification for identifiers within that scheme. The URI syntax provides a federated and extensible naming system, where each scheme's specification can further restrict the syntax and define the semantics of identifiers using that scheme.
Uniform Resource Identifier（URI）プロトコル要素と一般的な構文は、[RFC3986]で定義されています。各URIは、RFC 3986のセクション3.1で定義されているスキーム名で始まり、そのスキーム内の識別子の仕様を参照しています。 URI構文は、統合された拡張可能な命名システムを提供します。各スキーマの仕様では、構文をさらに制限し、そのスキーマを使用する識別子のセマンティクスを定義できます。
This document obsoletes [RFC4395], which in turn obsoleted [RFC2717] and [RFC2718]. Recent documents have used the term "URI" for all resource identifiers, avoiding the term "URL" and reserving the term "URN" explicitly for those URIs using the "urn" scheme name
このドキュメントは[RFC4395]を廃止し、[RFC2717]と[RFC2718]を廃止しました。最近のドキュメントでは、すべてのリソース識別子に「URI」という用語を使用しており、「URL」という用語を避け、「urn」スキーム名を使用するURIに対して「URN」という用語を明示的に予約しています。
[RFC2141]. URN "namespaces" [RFC3406] are specific to the "urn" scheme and are not covered explicitly by this specification.
[RFC2141]。 URN "名前空間" [RFC3406]は "urn"スキームに固有であり、この仕様では明示的にカバーされていません。
This document provides updated guidelines for the definition of new schemes, for consideration by those who are defining, registering, or evaluating those definitions. In addition, this document provides an updated process and mechanism for registering schemes within the IANA URI Schemes registry. There is a single namespace for registered schemes. The intent of the registry is to:
このドキュメントは、新しいスキームの定義に関する更新されたガイドラインを提供し、それらの定義を定義、登録、または評価している人が検討できるようにします。さらに、このドキュメントは、IANA URIスキームレジストリ内のスキームを登録するための更新されたプロセスとメカニズムを提供します。登録されたスキームには単一の名前空間があります。レジストリの目的は次のとおりです。
o provide a central point of discovery for established URI scheme names and easy location of defining documents for schemes;
o 確立されたURIスキーム名の発見の中心点とスキームの定義ドキュメントの簡単な場所を提供します。
o discourage multiple separate uses of the same scheme name;
o 同じスキーム名を複数に分けて使用しないでください。
o help those proposing new scheme names to discern established trends and conventions and to avoid names that might be confused with existing ones; and
o 新しいスキーム名を提案する人々が確立された傾向と慣習を識別し、既存のものと混同される可能性のある名前を回避するのを助けます。そして
o encourage registration by setting a low barrier for registration.
o 登録の障壁を低く設定して、登録を奨励します。
As originally defined, URIs only allowed a limited repertoire of characters chosen from US-ASCII. An Internationalized Resource Identifier (IRI), as defined by [RFC3987], extends the URI syntax to allow characters from a much greater repertoire to accommodate resource identifiers from the world's languages. RFC 3987 [RFC3987] also defined a mapping between URIs and IRIs. IRIs use the same scheme names as URIs. Thus, there is no separate independent registry or registration process for IRI schemes: the URI Schemes registry is used for both URIs and IRIs. Those who wish to describe resource identifiers that are useful as IRIs should define the corresponding URI syntax and note that the IRI usage follows the rules and transformations defined in [RFC3987].
最初に定義されたように、URIはUS-ASCIIから選択された文字の限られたレパートリーのみを許可しました。国際化リソース識別子（IRI）は、[RFC3987]で定義されているように、URI構文を拡張して、はるかに幅広いレパートリーの文字が世界中の言語のリソース識別子に対応できるようにします。 RFC 3987 [RFC3987]は、URIとIRI間のマッピングも定義しています。 IRIは、URIと同じスキーム名を使用します。したがって、IRIスキームには個別のレジストリまたは登録プロセスはありません。URIスキームレジストリは、URIとIRIの両方に使用されます。 IRIとして役立つリソース識別子を記述したい人は、対応するURI構文を定義し、IRIの使用法が[RFC3987]で定義されている規則と変換に従うことに注意してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document distinguishes between a "scheme specification", which is a document defining the syntax and semantics of a scheme, and a "scheme registration request", which is the completed template submitted to IANA. The term "scheme definition" refers generically to the syntax and semantics of a scheme and is typically documented in a scheme specification.
このドキュメントは、スキーマの構文とセマンティクスを定義するドキュメントである「スキーマ仕様」と、IANAに送信される完成したテンプレートである「スキーマ登録リクエスト」を区別します。 「スキーム定義」という用語は、一般的にスキームの構文とセマンティクスを指し、通常はスキーム仕様に文書化されています。
This section gives considerations for new schemes. Meeting these guidelines is REQUIRED for 'permanent' scheme registration. 'Permanent' status is appropriate for, but not limited to, use in standards. For URI schemes defined or normatively referenced by IETF Standards Track documents, 'permanent' registration status is REQUIRED.
このセクションでは、新しいスキームに関する考慮事項を示します。これらのガイドラインを満たすことは、「恒久的な」スキーム登録に必要です。 「永続的」ステータスは、標準での使用に適していますが、これに限定されません。 IETF Standards Trackドキュメントで定義または参照されているURIスキームの場合、「永続的な」登録ステータスが必要です。
[RFC3986] defines the overall syntax for URIs as:
[RFC3986]は、URIの全体的な構文を次のように定義しています。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be reused outside the generic syntax restrictions and that fragment identifiers are not scheme specific. A scheme definition must specify the scheme name and the syntax of the scheme-specific part, which is clarified as follows:
スキーマ定義は、URIの全体的な構文をオーバーライドできません。たとえば、これは、フラグメント識別子は一般的な構文の制限外で再利用できないこと、およびフラグメント識別子はスキーム固有ではないことを意味します。スキーマ定義では、スキーマ名とスキーマ固有の部分の構文を指定する必要があります。これは次のように明確にされています。
URI = scheme ":" scheme-specific-part [ "#" fragment ]
scheme-specific-part = hier-part [ "?" query ]
スキーム固有部分= hier-part ["？"クエリ]
In general, the use and deployment of new schemes in the Internet infrastructure can be costly; some parts of URI processing are often scheme dependent. Introducing a new scheme might require additional software not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [W3CWebArch]. Since scheme names share a single, global namespace, it is desirable to avoid contention over use of short, mnemonic scheme names. New schemes ought to have utility to the Internet community beyond that available with already registered schemes. The scheme specification SHOULD discuss the utility of the scheme being registered.
一般に、インターネットインフラストラクチャでの新しいスキームの使用と展開にはコストがかかる可能性があります。多くの場合、URI処理の一部はスキームに依存しています。新しいスキームを導入するには、クライアントソフトウェアとユーザーエージェントだけでなく、ネットワークインフラストラクチャの追加部分（ゲートウェイ、プロキシ、キャッシュ）[W3CWebArch]にも追加のソフトウェアが必要になる場合があります。スキーム名は単一のグローバル名前空間を共有するため、短いニーモニックスキーム名の使用を巡る競合を避けることが望ましいです。新しいスキームは、すでに登録されているスキームで利用可能なものを超えて、インターネットコミュニティに役立つはずです。スキーム仕様は、登録されているスキームの有用性について議論する必要があります。
[RFC3986] defines the generic syntax for all URI schemes, along with the syntax of common URI components that are used by many URI schemes to define hierarchical identifiers. [RFC3987] extended this generic syntax to cover IRIs. All scheme specifications MUST define their own URI <scheme-specific-part> syntax. Care must be taken to ensure that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar described in [RFC3986].
[RFC3986]は、すべてのURIスキームの一般的な構文と、階層的な識別子を定義するために多くのURIスキームで使用される一般的なURIコンポーネントの構文を定義します。 [RFC3987]はこの一般的な構文を拡張してIRIをカバーしました。すべてのスキーマ仕様は、独自のURI <scheme-specific-part>構文を定義する必要があります。スキーム固有の構文に一致するすべての文字列が、[RFC3986]で説明されている<absolute-URI>文法にも一致するように注意する必要があります。
New schemes SHOULD reuse the common URI components of [RFC3986] for the definition of hierarchical naming schemes. If there is a strong reason for a scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of similar previously registered schemes.
新しいスキームは、[RFC3986]の共通のURIコンポーネントを階層的な命名スキームの定義に再利用する必要があります（SHOULD）。スキーマが階層構文を使用しない強い理由がある場合、新しいスキーマ定義は、以前に登録された同様のスキーマの構文に従う必要があります。
Schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character in order to avoid unintended processing, such as resolution of "." and ".." (dot segments).
相対URIでの使用を意図していないスキームは、「。」の解決などの意図しない処理を回避するために、スラッシュ「/」文字の使用を回避する必要があります（SHOULD）。および「..」（ドットセグメント）。
Schemes SHOULD avoid improper use of "//". The use of double slashes in the first part of a URI is not a stylistic indicator that what follows is a URI: double slashes are intended for use ONLY when the syntax of the <scheme-specific-part> contains a hierarchical structure. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority (Section 3.2 of RFC 3986 has more details). Schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the "<scheme>:" string.
スキームは、「//」の不適切な使用を回避する必要があります。 URIの最初の部分でのダブルスラッシュの使用は、URIが続くことを示すスタイルのインジケータではありません。ダブルスラッシュは、<scheme-specific-part>の構文に階層構造が含まれている場合にのみ使用することを目的としています。このようなスキームのURIでは、二重スラッシュを使用することで、次のものが命名機関の最上位の階層要素であることを示します（RFC 3986のセクション3.2に詳細が記載されています）。 <scheme-specific-part>に適合する階層構造が含まれていないスキームは、「<scheme>：」文字列に続く二重スラッシュを使用してはなりません（SHOULD NOT）。
New schemes SHOULD clearly define the role of reserved characters (see Section 2.2 of [RFC3986]) in URIs of the scheme being defined. The syntax of the new scheme should be clear about which of the "reserved" set of characters are used as delimiters within the URIs of the new scheme, and when those characters must be escaped, versus when they can be used without escaping.
新しいスキームは、定義されるスキームのURIにおける予約文字（[RFC3986]のセクション2.2を参照）の役割を明確に定義する必要があります（SHOULD）。新しいスキームの構文は、「予約された」文字セットのどれが新しいスキームのURI内の区切り文字として使用されるか、およびそれらの文字をエスケープする必要がある場合とエスケープせずに使用できる場合について明確にする必要があります。
While URIs might or might not be defined as locators in practice, a scheme definition itself MUST be clear as to how it is expected to function. Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme.
URIは実際にはロケーターとして定義される場合と定義されない場合がありますが、スキーマ定義自体は、それがどのように機能することが期待されるかについて明確でなければなりません。ロケーターとして使用することを意図していないスキームは、そのスキームのURIを取得するソフトウェアが、識別されたリソースをどのように決定またはアクセスできるかを記述すべきです（SHOULD）。
For schemes that function as locators, it is important that the mechanism of resource location be clearly defined. This might mean different things depending on the nature of the scheme.
ロケーターとして機能するスキームの場合、リソースのロケーションのメカニズムを明確に定義することが重要です。これは、スキームの性質によって異なることを意味する場合があります。
In many cases, new schemes are defined as ways to translate between other namespaces or protocols and the general framework of URIs. For example, the "ftp" scheme translates into the FTP protocol while the "mid" scheme translates into a Message-ID identifier of an email message. For such schemes, the description of the mapping SHOULD be complete and in sufficient detail so that the mapping in both directions is clear: how to map from a URI into an identifier or set of protocol actions or name in the target namespace, and how legal values in the base namespace, or legal protocol interactions, are represented in a valid URI. See Section 3.6 for guidelines for encoding strings or sequences of bytes within valid character sequences in a URI. If not all legal values or protocol interactions of the base standard can be represented using the scheme, the definition SHOULD be clear about which subset is allowed and why.
多くの場合、新しいスキームは、他の名前空間またはプロトコルとURIの一般的なフレームワークとの間を変換する方法として定義されています。たとえば、「ftp」スキームはFTPプロトコルに変換され、「mid」スキームは電子メールメッセージのメッセージID識別子に変換されます。そのようなスキームの場合、マッピングの説明は完全かつ十分に詳細である必要があります。これにより、双方向のマッピングが明確になります。URIからターゲットネームスペース内の識別子またはプロトコルアクションまたは名前のセットにマッピングする方法、および適切な方法基本名前空間の値、または有効なプロトコルの相互作用は、有効なURIで表されます。 URIの有効な文字シーケンス内の文字列またはバイトシーケンスをエンコードするためのガイドラインについては、セクション3.6を参照してください。基本標準のすべての正当な値またはプロトコルの相互作用をスキームを使用して表すことができない場合、定義は、許可されるサブセットとその理由について明確にする必要があります（SHOULD）。
As part of the definition of how a URI identifies a resource, a scheme definition SHOULD define the applicable set of operations that can be performed on a resource using the URI as its identifier. A model for this is HTTP methods; an HTTP resource can be operated on by GET, POST, PUT, and a number of other methods available through the HTTP protocol. The scheme definition SHOULD describe all well-defined operations on the resource identifier and what they are supposed to do.
URIがリソースを識別する方法の定義の一部として、スキーマ定義は、URIを識別子として使用してリソースで実行できる適用可能な操作のセットを定義する必要があります（SHOULD）。このモデルはHTTPメソッドです。 HTTPリソースは、GET、POST、PUT、およびHTTPプロトコルを介して利用可能な他の多くのメソッドで操作できます。スキーマ定義は、リソース識別子に対するすべての明確に定義された操作と、それらが何をすることになっているのかを記述すべきです（SHOULD）。
Some schemes don't fit into the "information access" paradigm of URIs. For example, "telnet" provides location information for initiating a bidirectional data stream to a remote host; the only operation defined is to initiate the connection. In any case, the operations appropriate for a scheme SHOULD be documented.
一部のスキームは、URIの「情報アクセス」パラダイムに適合しません。たとえば、「telnet」は、リモートホストへの双方向データストリームを開始するための位置情報を提供します。定義されている唯一の操作は、接続を開始することです。いずれの場合も、スキームに適切な操作を文書化する必要があります。
Note: It is perfectly valid to say that "no operation apart from GET is defined for this URI." It is also valid to say that "there's only one operation defined for this URI, and it's not very GET-like." The important point is that what is defined on this scheme is described.
注：「このURIには、GET以外の操作は定義されていません」と言っても完全に有効です。 「このURIに対して定義されている操作は1つしかなく、GETに非常に似ているわけではない」と言っても有効です。重要な点は、このスキームで定義されていることが記述されていることです。
Scheme definitions SHOULD define a "default" operation for when a URI is invoked (or "dereferenced") by an application. For example, a common "default" operation today is to launch an application associated with the scheme name and let it use the other URI components as inputs to do something. The default invocation, or dereferencing, of a URI SHOULD be "safe" in the sense described by Section 3.4 of [W3CWebArch]; i.e., performing such an invocation should not incur any additional obligations by doing so.
スキーム定義は、URIがアプリケーションによって呼び出される（または「逆参照される」）ときの「デフォルト」操作を定義する必要があります（SHOULD）。たとえば、今日の一般的な「デフォルト」操作は、スキーム名に関連付けられたアプリケーションを起動し、他のURIコンポーネントを入力として使用して何かを実行することです。 [W3CWebArch]のセクション3.4で説明されている意味で、URIのデフォルトの呼び出しまたは逆参照は「安全」である必要があります。つまり、そのような呼び出しを実行しても、そうすることによって追加の義務が発生することはありません。
In general, URIs are used within a broad range of protocols and applications. For example, URIs are commonly used within hypertext documents as references to other resources. In some cases, a scheme is intended for use within a different, specific set of protocols or applications. If so, the scheme definition SHOULD describe the intended use and include references to documentation that define the applications and/or protocols cited. This does not obviate the need for documentation on applications and/or protocols to discuss URI schemes relevant to them.
一般に、URIは幅広いプロトコルとアプリケーションで使用されます。たとえば、URIは通常、ハイパーテキストドキュメント内で他のリソースへの参照として使用されます。場合によっては、スキームは異なる特定のプロトコルまたはアプリケーションのセット内での使用を目的としています。もしそうなら、スキームの定義は、意図された使用を記述し、引用されたアプリケーションやプロトコルを定義するドキュメントへの参照を含める必要があります。これにより、アプリケーションやプロトコルに関するドキュメントを作成して、それらに関連するURIスキームを議論する必要がなくなります。
When describing schemes in which (some of) the elements of the URI are actually representations of human-readable text, care should be taken not to introduce unnecessary variety in the ways in which characters are encoded into octets and then into URI characters; see [RFC3987] and Section 2.5 (especially the last paragraph) of [RFC3986] for guidelines. If URIs of a scheme contain any text fields, the scheme definition MUST describe the ways in which characters are encoded and any compatibility issues with IRIs of the scheme.
URIの要素の一部が実際に人間が読めるテキストの表現であるスキームを説明する場合、文字がオクテットにエンコードされてからURI文字にエンコードされる方法に不必要な多様性を導入しないように注意する必要があります。ガイドラインについては、[RFC3987]および[RFC3986]のセクション2.5（特に最後の段落）を参照してください。スキームのURIにテキストフィールドが含まれている場合、スキームの定義では、文字のエンコード方法とスキームのIRIとの互換性の問題を記述しなければなりません（MUST）。
The scheme specification SHOULD be as restrictive as possible regarding what characters are allowed in the URI because some characters can create several different security issues (see, for example, [RFC4690]).
一部の文字はいくつかの異なるセキュリティ問題を引き起こす可能性があるため、スキーマ仕様はURIで許可される文字に関して可能な限り制限する必要があります（たとえば、[RFC4690]を参照）。
Percent-encoded character sequences are automatically included by definition for characters given in IRI productions. This means that if you want to restrict the URI percent-encoded forms in some way, you must restrict the Unicode forms that would lead to them. In most cases, it is advisable to define the actual characters allowed in an IRI production in order to allow the 'pct-encoded' definition from Section 2.1 of [RFC3986] at the same places and to add prose that limits percent escapes to those that can be created by converting valid UTF-8 character sequences to percent-encoding.
パーセントエンコードされた文字シーケンスは、IRIプロダクションで提供される文字の定義により自動的に含まれます。つまり、何らかの方法でURIパーセントエンコードフォームを制限する場合は、それらにつながるUnicodeフォームを制限する必要があります。ほとんどの場合、同じ場所で[RFC3986]のセクション2.1の「pctエンコード」定義を許可し、パーセントエスケープを制限する散文を追加するために、IRIプロダクションで許可される実際の文字を定義することをお勧めします。有効なUTF-8文字シーケンスをパーセントエンコーディングに変換することで作成できます。
Definitions of schemes MUST be accompanied by a clear analysis of the security and privacy implications for systems that use the scheme; this follows the practice of Security Consideration sections within IANA registrations [RFC5226].
スキームの定義には、そのスキームを使用するシステムのセキュリティとプライバシーへの影響の明確な分析が伴う必要があります。これは、IANA登録[RFC5226]内のセキュリティに関する考慮事項セクションの実践に従います。
In particular, Section 7 of RFC 3986 [RFC3986] describes general security considerations for URIs while [RFC3987] gives those for IRIs. The definition of an individual scheme should note which of these apply to the specified scheme, in addition to any more scheme-specific concerns. For example, if the scheme-specific part is privacy sensitive, then that should be documented.
特に、RFC 3986 [RFC3986]のセクション7では、URIの一般的なセキュリティの考慮事項について説明し、[RFC3987]ではIRIのセキュリティに関する考慮事項を示しています。個々のスキームの定義では、スキーム固有の問題に加えて、これらのどれが指定されたスキームに適用されるかに注意する必要があります。たとえば、スキーム固有の部分がプライバシーに敏感な場合は、それを文書化する必要があります。
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this syntax remains the same for IRIs. New scheme registrations MUST follow this syntax, which only allows a limited repertoire of characters (taken from US-ASCII). Although the syntax for the scheme name in URIs is case insensitive, the scheme name itself MUST be registered using lowercase letters.
RFC 3986のセクション3.1は、URIスキーム名の構文を定義しています。この構文はIRIでも同じです。新しいスキームの登録はこの構文に従う必要があります。これにより、（US-ASCIIから取得された）文字の限られたレパートリーのみが許可されます。 URIのスキーマ名の構文では大文字と小文字が区別されませんが、スキーマ名自体は小文字で登録する必要があります。
Scheme names SHOULD be short but also sufficiently descriptive and distinguished to avoid problems.
スキーム名は短くする必要がありますが、問題を回避するために十分に説明的で区別すべきです。
Schemes SHOULD NOT use names or other symbols that might cause problems with rights to use the name in IETF specifications and Internet protocols. For example, be careful with trademark and service mark names. (See Section 3.4 of [RFC5378]).
スキームは、名前またはIETF仕様およびインターネットプロトコルでの名前の使用権に問題を引き起こす可能性があるその他の記号を使用しないでください。たとえば、商標やサービスマークの名前には注意してください。 （[RFC5378]のセクション3.4をご覧ください）。
Schemes SHOULD NOT use names that are either very general purpose or associated in the community with some other application or protocol. Schemes also SHOULD NOT use names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature).
スキームは、非常に汎用的な名前、またはコミュニティで他のアプリケーションやプロトコルと関連付けられている名前を使用しないでください。スキームは、範囲が過度に一般的または壮大な名前を使用してはなりません（たとえば、「普遍的」または「標準」の性質をほのめかす名前）。
A scheme name is not a "protocol." However, like a service name as defined in Section 5 of [RFC6335], it often identifies a particular protocol or application. If a scheme name has a one-to-one correspondence with a service name, then the names SHOULD be the same.
スキーム名は「プロトコル」ではありません。ただし、[RFC6335]のセクション5で定義されているサービス名と同様に、特定のプロトコルまたはアプリケーションを識別することがよくあります。スキーム名がサービス名と1対1で対応している場合、名前は同じである必要があります（SHOULD）。
Some organizations desire their own namespace for URI scheme names for private use (see Section 6). In doing so, it is important to prevent collisions and to make it possible to identify the owner of a private-use scheme. To accomplish these two goals, such organizations SHOULD use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com.example.mything might be used by the organization that owns the example.com domain name. Care must be taken, however, if the organization later loses the domain name embedded in their scheme names since domain name registrations are not permanent. To associate the private-use scheme name with the original organization, the private-use scheme can be registered using the registration procedure in Section 7.
一部の組織は、プライベートな使用のためにURIスキーム名に独自の名前空間を望んでいます（セクション6を参照）。その際、衝突を防ぎ、私用スキームの所有者を特定できるようにすることが重要です。これらの2つの目標を達成するために、そのような組織はドメイン名に基づいて、逆の順序で表現されたプレフィックスを使用する必要があります（SHOULD）。たとえば、com.example.mythingというURIスキーム名は、example.comドメイン名を所有する組織によって使用される場合があります。ただし、ドメイン名の登録は永続的ではないため、組織がスキーム名に埋め込まれたドメイン名を後で失う場合は注意が必要です。私用スキーム名を元の組織に関連付けるために、セクション7の登録手順を使用して私用スキームを登録できます。
Furthermore, to prevent collisions with private-use scheme names, new scheme names registered MUST NOT contain a "." unless actually constructed from a reversed domain name.
さらに、私用のスキーマ名との衝突を防ぐために、登録された新しいスキーマ名には「。」を含めてはなりません（MUST NOT）。逆にされたドメイン名から実際に構築されない限り。
If the person or group registering the scheme is aware of any details regarding the scheme that might impact interoperability, identify them, for example, proprietary or uncommon encoding methods, or incompatibility with types or versions of any underlying protocol.
スキームを登録している個人またはグループが、相互運用性に影響を与える可能性のあるスキームに関する詳細を認識している場合は、それらを特定します。たとえば、独自のエンコーディング方式や一般的でないエンコーディング方式、基になるプロトコルのタイプやバージョンとの非互換性などです。
'Provisional' registration can be used for schemes that are not part of any standard but that are intended for use (or observed to be in use) that is not limited to a private environment within a single organization. 'Provisional' registration can also be used as an intermediate step on the way to 'permanent' registration, e.g., before the scheme specification is finalized as a standard.
「暫定」登録は、標準の一部ではないが、単一の組織内のプライベート環境に限定されない使用を目的とする（または使用が確認されている）スキームに使用できます。 「仮」登録は、「スキーム」仕様が標準として確定する前など、「永久」登録への途中の中間ステップとして使用することもできます。
For a 'provisional' registration, the following apply:
「仮」登録の場合、以下が適用されます。
o The scheme name must meet the syntactic requirements of Section 3.8.
o スキーム名は、セクション3.8の構文要件を満たしている必要があります。
o There must not already be an entry with the same scheme name. In the unfortunate case that there are multiple, different uses of the same scheme name, the Designated Expert can approve a request to modify an existing entry to note the separate use.
o 同じスキーム名のエントリがすでに存在していてはなりません。残念ながら、同じスキーム名の複数の異なる使用法がある場合、Designated Expertは、既存のエントリを変更するリクエストを承認して、個別の使用法を記録できます。
o Contact information identifying the person supplying the registration must be included. Previously unregistered schemes discovered in use can be registered by third parties (even if not on behalf of those who created the scheme). In this case, both the registering party and the scheme creator SHOULD be identified.
o 登録の提供者を特定する連絡先情報を含める必要があります。以前に未登録のスキームが使用中に発見された場合は、それをサードパーティが登録できます（スキームを作成した人の代理ではない場合でも）。この場合、登録当事者とスキーム作成者の両方を識別する必要があります。
o If no permanent, citable specification for the scheme definition is included, credible reasons for not providing it SHOULD be given.
o スキーム定義の恒久的で引用可能な仕様が含まれていない場合は、それを提供しないことの信頼できる理由を示す必要があります。
o The scheme definition SHOULD include clear security considerations (Section 3.7) or explain why a full security analysis is not available (e.g., in a third-party scheme registration).
o スキームの定義には、明確なセキュリティの考慮事項（セクション3.7）を含めるか、完全なセキュリティ分析が利用できない理由を説明する必要があります（たとえば、サードパーティのスキームの登録で）。
o If the scheme definition does not meet the guidelines laid out in Section 3, the differences and reasons SHOULD be noted.
o スキームの定義がセクション3に示されたガイドラインを満たしていない場合は、違いと理由に注意する必要があります。
In some circumstances, it is appropriate to note a scheme that was once in use or registered but for whatever reason is no longer in common use or whose use is not recommended. In this case, it is possible for an individual to request that the URI scheme be registered (newly, or as an update to an existing registration) as 'historical'. Any scheme that is no longer in common use MAY be designated as 'historical'; the registration SHOULD contain some indication as to where the scheme was previously defined or documented.
状況によっては、以前は使用または登録されていたが、何らかの理由でもはや一般的に使用されていない、またはその使用が推奨されていないスキームに注意することが適切です。この場合、個人がURIスキームを「履歴」として（新規に、または既存の登録の更新として）登録することを要求できます。もはや一般的に使用されなくなったスキームは、「歴史的」として指定されるかもしれません。登録には、スキームが以前に定義または文書化された場所に関する何らかの指示が含まれている必要があります。
Unregistered schemes can cause problems if use is not limited to a private environment within a single organization since the use could leak out beyond the closed environment. Even within a closed environment, other colliding uses of the same scheme name could occur. As such, a unique namespace MUST be used and 'provisional' registration is strongly encouraged (unless the scheme name is constructed from a domain name), as discussed in Section 3.8.
登録されていないスキームは、使用が単一の組織内のプライベート環境に限定されていない場合に問題を引き起こす可能性があります。これは、使用が閉じた環境を超えて漏出する可能性があるためです。閉じた環境内でも、同じスキーム名の他の衝突する使用が発生する可能性があります。そのため、セクション3.8で説明するように、一意の名前空間を使用する必要があり、「スキーム名がドメイン名から構築されない限り」「仮」登録を強くお勧めします。
The IANA policy (using terms defined in [RFC5226]) for 'provisional' registration was formerly Expert Review; this document changes the policy to First Come First Served. The policy for 'permanent' and 'historical' registration continues to be Expert Review.
「仮」登録に関するIANAポリシー（[RFC5226]で定義された用語を使用）は、以前は専門家によるレビューでした。このドキュメントはポリシーを先着順に変更します。 「恒久的」および「歴史的」登録のポリシーは、引き続きエキスパートレビューです。
The registration procedure is intended to be very lightweight for noncontentious registrations. For the most part, we expect the good sense of submitters and reviewers, guided by these procedures, to achieve an acceptable and useful consensus for the community.
登録手順は、問題のない登録のために非常に軽量になることを目的としています。ほとんどの場合、私たちはこれらの手順に導かれて、投稿者とレビューアの良識がコミュニティに受け入れ可能で有用なコンセンサスを達成することを期待しています。
In exceptional cases, where the negotiating parties cannot form a consensus, the final arbiter of any contested registration shall be the IESG.
例外的なケースでは、交渉当事者が合意を形成できない場合、競合する登録の最終的な仲裁人はIESGです。
If standardization is anticipated, the working group or individuals concerned are advised to submit an early 'permanent' registration request rather than waiting until the standardization process has run its course. IANA will pass this to the Designated Expert who may recommend 'provisional' registration until the specification is approved as a standard. This will provide an opportunity for feedback while specification development and review is still active, and while the submitter(s) are still in a position to respond to any issues that might be raised. If and when the specification is approved as a standard, the submitters should submit a request to change the registration status to 'permanent'.
標準化が予想される場合、ワーキンググループまたは関係者は、標準化プロセスが完了するまで待つのではなく、早期の「永続的な」登録要求を提出することをお勧めします。 IANAはこれをDesignated Expertに渡し、仕様が標準として承認されるまで「暫定」登録を推奨する場合があります。これは、仕様の開発とレビューがまだアクティブであり、提出者がまだ発生している可能性のある問題に対応する立場にある間、フィードバックの機会を提供します。仕様が標準として承認された場合、提出者は登録ステータスを「永続的」に変更するリクエストを送信する必要があります。
The role of the Designated Expert in the procedure for 'permanent' registrations described here is to ensure that the normal open review process has been properly followed and to raise possible concerns about wider implications of proposals for the use and deployment of URIs. Nothing in the procedure empowers the Designated Expert to override properly arrived-at IETF or working group consensus.
ここで説明する「恒久的」登録の手順における指定専門家の役割は、通常のオープンレビュープロセスが適切に行われていることを確認し、URIの使用と展開に関する提案の幅広い影響について考えられる懸念を提起することです。手順の何も指定されたエキスパートが適切に到着したIETFまたはワーキンググループのコンセンサスを無効にする権限を与えません。
Someone wishing to register a new scheme MUST:
新しいスキームを登録したい人は以下のことをしなければなりません：
1. Check the IANA "Uniform Resource Identifier (URI) Schemes" registry to see whether there is already an entry for the desired name. If there is already an entry under the name, choose a different scheme name or update the existing scheme specification.
1. IANAの「Uniform Resource Identifier（URI）Schemes」レジストリをチェックして、目的の名前のエントリがすでに存在するかどうかを確認します。名前の下にすでにエントリがある場合は、別のスキーム名を選択するか、既存のスキーム仕様を更新します。
2. Prepare a scheme registration request using the template specified in Section 7.4. The scheme registration request can be contained in an Internet-Draft, submitted alone, or as part of some other permanently available, stable, protocol specification. The scheme registration request can also be submitted in some other form (as part of another document or as a stand-alone document), but the scheme registration request will be treated as an "IETF Contribution" under the guidelines of [RFC5378].
2. セクション7.4で指定されたテンプレートを使用して、スキーム登録リクエストを準備します。スキーム登録要求は、インターネットドラフトに含めるか、単独で送信するか、または永続的に利用できる他の安定したプロトコル仕様の一部として送信できます。スキーム登録要求は、他の形式で（別のドキュメントの一部として、または独立したドキュメントとして）送信することもできますが、スキーム登録要求は、[RFC5378]のガイドラインの下で「IETF寄稿」として扱われます。
3. If the registration request is for a 'permanent' registration (or, optionally, for any other registration if desired):
3. 登録要求が「永続的な」登録（またはオプションで、必要に応じて他の登録）の場合：
1. Review the requirements in Section 3.
1. セクション3の要件を確認します。
2. Send a copy of the scheme registration request or a pointer to the document containing the request (with specific reference to the section that requests the scheme registration) to the mailing list uri-review@ietf.org, requesting review. In addition, request review on other relevant mailing lists as appropriate. For example, general discussion of URI syntactical issues can be discussed on uri@w3.org; schemes for a network protocol can be discussed on a mailing list for that protocol. Allow a reasonable time for discussion and comments. Four weeks is reasonable for a 'permanent' registration request.
2. スキーム登録リクエストのコピー、またはリクエストを含むドキュメントへのポインタ（スキーム登録をリクエストするセクションへの具体的な参照付き）を、レビューを要求するメーリングリストuri-review@ietf.orgに送信します。さらに、必要に応じて、他の関連するメーリングリストのレビューをリクエストします。たとえば、URI構文の問題に関する一般的な議論は、uri @ w3.orgで議論できます。ネットワークプロトコルのスキームは、そのプロトコルのメーリングリストで議論できます。ディスカッションとコメントのために適切な時間を与えてください。 「永続的な」登録要求の場合、4週間が妥当です。
3. Respond to review comments and make revisions to the proposed registration as needed to bring it into line with the guidelines given in this document.
3. このドキュメントに記載されているガイドラインに沿うようにするために、必要に応じて、レビューコメントに返信し、提案された登録を修正します。
4. Submit the (possibly updated) scheme registration request (or pointer to document containing it) to IANA at iana@iana.org.
4. （おそらく更新された）スキーム登録要求（またはそれを含むドキュメントへのポインター）をiana@iana.orgのIANAに送信します。
Upon receipt of a scheme registration request, the following steps MUST be followed:
スキーム登録要求を受け取ったら、次の手順に従う必要があります。
1. IANA checks the submission for completeness; if required sections of the scheme registration request are missing or any citations are not correct, IANA will reject the registration request. A registrant can resubmit a corrected request if desired.
1. IANAは提出物の完全性をチェックします。スキーム登録要求の必要なセクションが欠落している場合、または引用が正しくない場合、IANAは登録要求を拒否します。登録者は、必要に応じて修正されたリクエストを再送信できます。
2. If the request is for 'provisional' registration and no entry already exists in the current registry for the same name, IANA adds the registration to the registry under the First Come First Served policy.
2. リクエストが「仮」登録で、現在のレジストリに同じ名前のエントリがまだ存在しない場合、IANAは先着順ポリシーでレジストリに登録を追加します。
3. Otherwise, IANA enters the registration request in the IANA registry with the status marked as "Pending Review", and the remainder of this section applies.
3. それ以外の場合、IANAは「保留中のレビュー」とマークされたステータスでIANAレジストリに登録要求を入力し、このセクションの残りの部分が適用されます。
4. IANA requests Expert Review of the registration request against the corresponding guidelines from this document.
4. IANAは、このドキュメントの対応するガイドラインに対する登録要求のエキスパートレビューを要求します。
5. The Designated Expert will evaluate the request against the criteria of the requested status.
5. 指定エキスパートは、要求されたステータスの基準に照らして要求を評価します。
6. In the case of a 'permanent' registration request, the Designated Expert may:
6. 「恒久的」登録要求の場合、指定専門家は以下を行うことができます。
* Accept the specification of the scheme for 'permanent' registration.
* 「恒久的」登録のスキームの仕様を受け入れます。
* Suggest 'provisional' registration instead.
* 代わりに「仮」登録を提案してください。
* Request IETF review and IESG approval; in the meanwhile, suggest 'provisional' registration.
* IETFレビューとIESG承認をリクエストします。その間、「仮」登録を提案してください。
* Request additional review or discussion as necessary.
* 必要に応じて、追加のレビューまたはディスカッションをリクエストしてください。
7. If an entry already exists for the same name, the Designated Expert will determine whether the request should be rejected or whether the existing entry should be modified to note the separate use. This conflict process applies regardless of the requested status or the status of the existing entry.
7. 同じ名前のエントリがすでに存在する場合、指定エキスパートは、リクエストを拒否する必要があるかどうか、または既存のエントリを変更して別の用途に注意する必要があるかどうかを判断します。この競合プロセスは、要求されたステータスまたは既存のエントリのステータスに関係なく適用されます。
8. Once the Designated Expert approves registration for a given status, IANA updates the registration to indicate the approved status. If the Designated Expert instead rejects the registration, the "Pending Review" request is removed from the registry.
8. 指定専門家が特定のステータスの登録を承認すると、IANAは登録を更新して承認ステータスを示します。指定されたエキスパートが代わりに登録を拒否した場合、「保留中のレビュー」リクエストはレジストリから削除されます。
Either based on an explicit request or independently initiated, the Designated Expert or the IESG can request the upgrade of a 'provisional' registration to a 'permanent' one. In such cases, IANA will update the status of the corresponding entry. Typically, this would only occur if the use is considered a standard (not necessarily an IETF standard).
明示的な要求に基づいて、または独立して開始された、指定専門家またはIESGは、「仮」登録から「永久」登録へのアップグレードを要求できます。そのような場合、IANAは対応するエントリのステータスを更新します。通常、これは、使用が標準（必ずしもIETF標準ではない）と見なされる場合にのみ発生します。
Registrations can be updated in the registry by the same mechanism as required for an initial registration. In cases where the original definition of the scheme is contained in an IESG-approved document, update of the specification also requires IESG approval.
登録は、最初の登録に必要なのと同じメカニズムでレジストリで更新できます。スキームの元の定義がIESG承認のドキュメントに含まれている場合、仕様の更新にはIESGの承認も必要です。
'Provisional' registrations can be updated by the original registrant or anyone designated by the original registrant. In addition, the IESG can reassign responsibility for a 'provisional' registration scheme or can request specific changes to a scheme registration. This will enable changes to be made to schemes where the original registrant is out of contact or unwilling or unable to make changes.
「仮」登録は、元の登録者または元の登録者によって指定された誰でも更新できます。さらに、IESGは「暫定」登録スキームの責任を再割り当てしたり、スキーム登録の特定の変更を要求したりできます。これにより、元の登録者が連絡できない、または変更を望まない、または変更できないスキームに変更を加えることができます。
Transition from 'provisional' to 'permanent' status can be requested and approved in the same manner as a new 'permanent' registration. Transition from 'permanent' to 'historical' status requires IESG approval. Transition from 'provisional' to 'historical' can be requested by anyone authorized to update the 'provisional' registration.
「暫定」ステータスから「永続」ステータスへの移行は、新しい「永続」登録と同じ方法でリクエストおよび承認できます。 「永続的」から「歴史的」ステータスへの移行には、IESGの承認が必要です。 「仮」から「歴史的」への移行は、「仮」登録の更新を許可された誰もが要求できます。
This template describes the fields that MUST be supplied in a scheme registration request suitable for adding to the registry:
このテンプレートは、レジストリに追加するのに適したスキーム登録リクエストで提供する必要があるフィールドを記述します：
Scheme name: See Section 3.8 for guidelines.
スキーム名：ガイドラインについては、セクション3.8を参照してください。
Status: This reflects the status requested and must be one of 'Permanent', 'Provisional', or 'Historical'.
ステータス：これはリクエストされたステータスを反映しており、「永続的」、「暫定的」、または「歴史的」のいずれかでなければなりません。
Applications/protocols that use this scheme name: See Section 3.5.
このスキーム名を使用するアプリケーション/プロトコル：セクション3.5を参照してください。
Contact: Person (including contact information) to contact for further information.
連絡先：詳細について連絡する人（連絡先情報を含む）。
Change controller: Organization or person (often the author), including contact information, authorized to change this.
変更管理者：連絡先情報を含む、これを変更する権限を持つ組織または個人（多くの場合は作成者）。
References: Include full citations for all referenced documents. Scheme registration requests for 'provisional' registration can be included in an Internet-Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. A scheme specification is only required for 'permanent' registration.
参照：すべての参照ドキュメントの完全な引用を含めます。 「仮」登録のスキーム登録リクエストは、インターネットドラフトに含めることができます。ドキュメントが期限切れになるか、RFCとしての公開が承認されると、登録が更新されます。スキーム仕様は、「永久」登録にのみ必要です。
The previous version of this specification required the following additional fields in a scheme registration request. These fields are no longer part of the template. The answers instead belong in the scheme specification.
この仕様の以前のバージョンでは、スキーム登録リクエストに次の追加フィールドが必要でした。これらのフィールドは、テンプレートの一部ではなくなりました。代わりに、答えはスキーム仕様に属します。
Scheme syntax: See Section 3.2 for guidelines.
スキーム構文：ガイドラインについては、セクション3.2を参照してください。
Scheme semantics: See Section 3.3 and Section 3.4 for guidelines.
スキームのセマンティクス：ガイドラインについては、セクション3.3およびセクション3.4を参照してください。
Encoding considerations: See Section 3.3 and Section 3.6 for guidelines.
エンコーディングに関する考慮事項：ガイドラインについては、セクション3.3およびセクション3.6を参照してください。
Interoperability considerations: See Section 3.9 for guidelines.
相互運用性に関する考慮事項：ガイドラインについては、セクション3.9を参照してください。
Security considerations: See Section 3.7 for guidelines.
セキュリティに関する考慮事項：ガイドラインについては、3.7項を参照してください。
There is a need for a scheme name that can be used for examples in documentation without fear of conflicts with current or future actual schemes. The scheme "example" is hereby registered as a 'permanent' scheme for that purpose.
現在または将来の実際のスキームとの競合を恐れずに、ドキュメントの例に使用できるスキーム名が必要です。スキーム「例」は、その目的のために「永続的な」スキームとしてここに登録されています。
The "example" scheme is specified as follows:
「サンプル」スキームは次のように指定されます。
Scheme syntax: The entire range of allowable syntax specified in [RFC3986] is allowed for "example" URIs. Similarly, the entire range of allowable syntax specified in [RFC3987] is allowed for "example" IRIs. For example, <example:foo>, <example:/foo>, and <example://foo> are all valid.
スキーム構文：[RFC3986]で指定されている許容される構文の全範囲は、「サンプル」URIで許可されています。同様に、[RFC3987]で指定されている許容構文の全範囲は、「サンプル」IRIに許可されています。たとえば、<example：foo>、<example：/ foo>、<example：// foo>はすべて有効です。
Scheme semantics: URIs in the "example" scheme are to be used for documentation purposes only. The use of "example" URIs must not be used as locators, identify any resources, or specify any particular set of operations.
スキームのセマンティクス：「example」スキームのURIは、文書化の目的でのみ使用されます。 「サンプル」URIの使用は、ロケーターとして使用したり、リソースを識別したり、特定の操作セットを指定したりしてはなりません。
Encoding considerations: See Section 2.5 of [RFC3986] for guidelines.
エンコードに関する考慮事項：ガイドラインについては、[RFC3986]のセクション2.5をご覧ください。
Interoperability considerations: None.
相互運用性に関する考慮事項：なし。
Security considerations: None.
セキュリティに関する考慮事項：なし。
Scheme name: example
スキーム名：例
Status: permanent
ステータス：永続的
Applications/protocols that use this scheme name: An "example" URI is to be used for documentation purposes only. It MUST NOT be used for any protocol.
このスキーム名を使用するアプリケーション/プロトコル：「サンプル」URIは、文書化の目的でのみ使用されます。どのプロトコルにも使用してはなりません。
Contact: N/A
連絡先：なし
Change controller: IETF
コントローラの変更：IETF
References: Section 8 of this document (RFC 7595).
参照：このドキュメントのセクション8（RFC 7595）。
Previously, the former "URL Scheme" registry was replaced by the "Uniform Resource Identifier (URI) Schemes" registry. The process was based on "Expert Review" [RFC5226] with an initial (optional) mailing list review.
以前は、以前の「URLスキーム」レジストリは、「Uniform Resource Identifier（URI）スキーム」レジストリに置き換えられました。このプロセスは、「エキスパートレビュー」[RFC5226]に基づいており、最初の（オプションの）メーリングリストレビューが行われました。
The updated template has an additional field for the status of the scheme, and the procedures for entering new name schemes have been augmented. Section 7 establishes the process for new scheme registration.
更新されたテンプレートには、スキームのステータスの追加フィールドがあり、新しい名前スキームを入力するための手順が拡張されました。セクション7では、新しいスキーム登録のプロセスを確立します。
IANA has done the following:
IANAは次のことを行いました。
o Updated the URI Schemes registry to point to this document.
o このドキュメントを指すようにURIスキームレジストリを更新しました。
o Combined the "Permanent URI Schemes", "Provisional URI Schemes", and "Historical URI Schemes" subregistries into a single common registry with an additional "Status" column containing the status ('Permanent', 'Provisional', 'Historical', or 'Pending Review'), and an additional "Notes" column that is normally empty but may contain notes approved by the Designated Expert.
o 「Permanent URI Schemes」、「Provisional URI Schemes」、および「Historical URI Schemes」のサブレジストリを単一の共通レジストリに結合し、追加の「Status」列にステータス（「Permanent」、「Provisional」、「Historical」、または「保留中のレビュー」）、および通常は空ですが、指定された専門家によって承認されたメモが含まれる可能性がある追加の「メモ」列。
o Added the "example" URI scheme to the registry (see the template in Section 8.1 for registration).
o レジストリに「サンプル」URIスキームを追加しました（登録については、セクション8.1のテンプレートを参照してください）。
All registered values are expected to contain clear security considerations as discussed in Section 3.7. However, information concerning possible security vulnerabilities of a protocol might change over time. Consequently, claims as to the security properties of a registered scheme might change as well. As new vulnerabilities are discovered, information about such vulnerabilities might need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered scheme.
セクション3.7で説明するように、登録されたすべての値には、明確なセキュリティ上の考慮事項が含まれていることが期待されます。ただし、プロトコルの潜在的なセキュリティの脆弱性に関する情報は、時間の経過とともに変化する可能性があります。その結果、登録済みスキームのセキュリティプロパティに関する主張も変更される可能性があります。新しい脆弱性が発見されると、そのような脆弱性に関する情報を既存のドキュメントに添付して、ユーザーが登録済みスキームの真のセキュリティプロパティを誤解しないようにする必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141] Moats、R。、「URN Syntax」、RFC 2141、DOI 10.17487 / RFC2141、1997年5月、<http://www.rfc-editor.org/info/rfc2141>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>.
[RFC5378]ブラドナー、S。、エド。およびJ. Contreras、編、「IETFトラストに提供する権利」、BCP 78、RFC 5378、DOI 10.17487 / RFC5378、2008年11月、<http://www.rfc-editor.org/info/rfc5378>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, DOI 10.17487/RFC2717, November 1999, <http://www.rfc-editor.org/info/rfc2717>.
[RFC2717] Petke、R。およびI. King、「URLスキーム名の登録手順」、RFC 2717、DOI 10.17487 / RFC2717、1999年11月、<http://www.rfc-editor.org/info/rfc2717>。
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, DOI 10.17487/RFC2718, November 1999, <http://www.rfc-editor.org/info/rfc2718>.
[RFC2718] Masinter、L.、Alvestrand、H.、Zigmond、D。、およびR. Petke、「新しいURLスキームのガイドライン」、RFC 2718、DOI 10.17487 / RFC2718、1999年11月、<http：//www.rfc -editor.org/info/rfc2718>。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[RFC3406] Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「Uniform Resource Names（URN）Namespace Definition Mechanisms」、BCP 66、RFC 3406、DOI 10.17487 / RFC3406、2002年10月、 <http://www.rfc-editor.org/info/rfc3406>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、DOI 10.17487 / RFC3864、2004年9月、<http：//www.rfc- editor.org/info/rfc3864>。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、DOI 10.17487 / RFC3987、2005年1月、<http://www.rfc-editor.org/info/rfc3987>。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, February 2006, <http://www.rfc-editor.org/info/rfc4395>.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、RFC 4395、DOI 10.17487 / RFC4395、2006年2月、<http：//www.rfc-editor .org / info / rfc4395>。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <http://www.rfc-editor.org/info/rfc4690>.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「レビューおよび国際化ドメイン名（IDN）の推奨事項」、RFC 4690、DOI 10.17487 / RFC4690、2006年9月、<http：// www.rfc-editor.org/info/rfc4690>。
[W3CWebArch] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", W3C Recommendation, December 2004, <http://www.w3.org/TR/webarch/>.
[W3CWebArch] W3C Technical Architecture Group、「Architecture of the World Wide Web、Volume One」、W3C勧告、2004年12月、<http://www.w3.org/TR/webarch/>。
Acknowledgements
謝辞
Thanks to Mark Nottingham and Graham Klyne and other members of the apps-discuss@ietf.org mailing list for their comments on this document.
このドキュメントに関するコメントを提供してくれたMark NottinghamとGraham Klyne、およびapps-discuss@ietf.orgメーリングリストの他のメンバーに感謝します。
Many thanks to Patrik Faltstrom, Paul Hoffmann, Ira McDonald, Roy Fielding, Stu Weibel, Tony Hammond, Charles Lindsey, Mark Baker, and other members of the uri@w3.org mailing list for their comments on earlier draft versions of this document.
Patrik Faltstrom、Paul Hoffmann、Ira McDonald、Roy Fielding、Stu Weibel、Tony Hammond、Charles Lindsey、Mark Baker、および他のuri@w3.orgメーリングリストのメンバーに、このドキュメントの以前のドラフトバージョンに関するコメントをお寄せいただきありがとうございます。
Parts of this document are based on [RFC2717], [RFC2718] and [RFC3864]. Some of the ideas about use of URIs were taken from the "Architecture of the World Wide Web" [W3CWebArch].
このドキュメントの一部は、[RFC2717]、[RFC2718]、および[RFC3864]に基づいています。 URIの使用に関するアイデアの一部は、「World Wide Webのアーキテクチャ」[W3CWebArch]から引用されました。
Contributor
寄稿者
Larry Masinter was an author of the document from which this work is derived, and he continued as author of this version through the working group and IESG evaluation period. His many contributions are gratefully acknowledged.
ラリー・マシンターは、この作品の元となったドキュメントの作者であり、ワーキンググループとIESG評価期間を通じて、このバージョンの作者として継続しました。彼の多くの貢献が感謝されます。
Authors' Addresses
著者のアドレス
Dave Thaler (editor) Microsoft One Microsoft Way Redmond, WA 98052 United States
Dave Thaler（編集者）Microsoft One Microsoft Way Redmond、WA 98052アメリカ合衆国
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 United States
Tony Hansen AT＆T Laboratories 200 Laurel Ave. Middletown、NJ 07748アメリカ
EMail: tony+urireg@maillennium.att.com
Ted Hardie Google
テッドハーディグーグル
Phone: +1 408 628 5864
EMail: ted.ietf@gmail.com