Network Working Group T. Hansen
Request for Comments: 4395 AT&T Laboratories
Obsoletes: 2717, 2718 T. Hardie
BCP: 115 Qualcomm, Inc.
Category: Best Current Practice L. Masinter
Adobe Systems
February 2006
Guidelines and Registration Procedures for New URI Schemes
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718.
この文書では、統一資源識別子（URI）スキームの定義のためのガイドラインと推奨事項を提供します。また、URIスキームのためのプロセスとIANAレジストリを更新します。これは、RFC 2717およびRFC 2718の両方を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Guidelines for Permanent URI Scheme Definitions . . . . . . . 4
2.1. Demonstratable, New, Long-Lived Utility . . . . . . . . . 4
2.2. Syntactic Compatibility . . . . . . . . . . . . . . . . . 5
2.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
2.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Internationalization and Character Encoding . . . . . . . 7
2.7. Clear Security Considerations . . . . . . . . . . . . . . 7
2.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 7
3. Guidelines for Provisional URI Scheme Registration . . . . . . 8
4. Guidelines for Historical URI Scheme Registration . . . . . . 8
5. URI Scheme Registration Procedure . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration Procedures . . . . . . . . . . . . . . . . . 9
5.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 10
5.4. URI Scheme Registration Template . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
The Uniform Resource Identifier (URI) protocol element and generic syntax is defined by RFC 3986 [5]. 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 may further restrict the syntax and semantics of identifiers using that scheme. This document provides guidelines for the definition of new URI schemes, for consideration by those who are defining, registering, or evaluating those definitions, as well as a process and mechanism for registering URI schemes within the IANA URI scheme registry. The registry has two parts: 'provisional' and 'permanent', with different requirements. Guidelines and requirements for both parts are given.
ユニフォームリソース識別子（URI）プロトコル要素と一般的な構文は、RFC 3986によって定義されている[5]。そのスキーム内の識別子の指定を意味するRFC 3986のセクション3.1で定義されるように各URIは、スキーム名で始まります。 URIの構文は、各スキームの仕様は、さらにその方式を使用して識別子の構文およびセマンティクスを制限してもよい連合と拡張ネーミングシステムを提供します。このドキュメントは、IANAのURIスキームレジストリ内のURIスキームを登録するため、定義の登録、またはそれらの定義を評価している人たちだけでなく、プロセスとメカニズムによる検討のため、新しいURIスキームの定義のためのガイドラインを提供します。 「暫定」と「パーマ」、さまざまな要件を持つ：レジストリは、2つの部分があります。両方の部分のためのガイドラインと要件が与えられています。
This document obsoletes both RFCs 2717 [7] and 2718 [8]. RFCs 2717 and 2718 drew a distinction between 'locators' (identifiers used for accessing resources available on the Internet) and 'names' (identifiers used for naming possibly abstract resources, independent of any mechanism for accessing them). The intent was to use the designation "URL" (Uniform Resource Locator) for those identifiers that were locators and "URN" (Uniform Resource Name) for those identifiers that were names. In practice, the line between 'locator' and 'name' has been difficult to draw: locators can be used as names, and names can be used as locators.
この文書では、[8] [7]と2718の両方のRFC 2717を時代遅れ。 RFC 2717と2718は、「ロケータ」（インターネット上で利用可能なリソースにアクセスするために使用される識別子）と「名前」（おそらく抽象リソースを命名するために使用される識別子、それらにアクセスするための任意のメカニズムとは無関係に）の区別を描きました。その意図は、名前だったこれらの識別子のためのロケータと「URN」（ユニフォームリソース名）となりましたこれらの識別子のために記号「URL」（ユニフォームリソースロケータ）を使用することでした。ロケータが名として使用することができ、そして名前がロケータとして使用することができます。実際には、「ロケータ」と「名前」の間のラインが描画することは困難でした。
As a result, 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 (RFC 2141 [2]). URN "namespaces" (RFC 3406 [9]) are specific to the "urn" scheme and not covered explicitly by this document.
その結果、最近の文書には、「URL」という用語を避け、すべてのリソース識別子のための用語「URI」を使用していると「壷」スキーム名使用してそれらのURIに対して明示的に「URN」という用語を予約する（RFC 2141 [2]）。 URN「名前空間」（RFC 3406 [9]）「壷」のスキームに特有ではなく、この文書で明示的に覆われています。
RFC 2717 defined a set of registration trees in which URI schemes could be registered, one of which was called the IETF Tree, to be managed by IANA. RFC 2717 proposed that additional registration trees might be approved by the IESG. However, no such registration trees have been approved.
RFC 2717は、IANAによって管理されるように、IETFツリーと呼ばれていたそのうちの一つのURIスキームを登録することができたに登録木のセットを定義しました。 RFC 2717には、追加登録の木がIESGによって承認されるかもしれないことを提案しました。しかし、そのような登録の木が承認されていません。
This document eliminates RFC 2717's distinction between different
'trees' for URI schemes; instead there is a single namespace for
registered values. Within that namespace, there are values that are
approved as meeting a set of criteria for URI schemes. Other scheme
names may also be registered provisionally, without necessarily
meeting those criteria. The intent of the registry is to: o provide a central point of discovery for established URI scheme
names, and easy location of their defining documents;
o discourage use of the same URI scheme name for different purposes;
o help those proposing new URI scheme names to discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o encourage registration by setting a low barrier for provisional
registrations.
RFC 3987 [6] introduced a new protocol element, the Internationalized Resource Identifier (IRI), and defined a mapping between URIs and IRIs. There is no separate registry or registration process for 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 RFC 3987.
RFC 3987 [6]新しいプロトコル要素、国際化リソース識別子（IRI）を導入し、URIのと虹彩との間のマッピングを定義しました。 IRIは用の個別のレジストリまたは登録プロセスはありません。 IRIとして有用なリソース識別子を記述するためにご希望の方は、対応するURIの構文を定義し、IRIの使用は、RFC 3987で定義された規則および変換に従うことに注意すべきです。
Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in RFC 2119 [1], within the context that they are requirements on future registration documents.
この文書の中で、キーワードMUST、MAY、SHOULD、REQUIRED、等々推奨、そして、それらが将来の登録書類上の要件でコンテキスト内で、[1] RFC 2119に設立された一般的な意味の範囲内で使用されています。
This section gives considerations for new URI schemes. Meeting these guidelines is REQUIRED for permanent URI scheme registration. Meeting these guidelines is also RECOMMENDED for provisional registration, as described in Section 3.
このセクションでは、新しいURIスキームのための注意事項を示します。これらのガイドラインを満たすすることは永久的なURIスキームの登録に必要です。第3節で説明したようにこれらのガイドラインを満たすことがまた、仮登録をお勧めします。
The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes.
インターネットインフラストラクチャで使用すると、新しいURIスキームの展開はコストがかかります。 URI処理の一部は、すでによく知られているスキームのURIを処理する方式に依存し、展開ソフトウェアであってもよいです。新しいURIスキームを導入するクライアントソフトウェアとユーザエージェントのためだけでなく、ネットワークインフラストラクチャの追加部品（ゲートウェイ、プロキシ、キャッシュ）[11]だけでなく、追加のソフトウェアを必要とし得ます。 URIスキームは、単一の、グローバルな名前空間を構成しています。短い、ニーモニックスキーム名の使用上の競合を避けることが望ましいです。これらの理由から、新しいスキームの無限の登録は有害です。新しいURIスキームは、既に登録されているURIスキームで利用できることを超えて、広範なインターネットコミュニティへの明確な有用性を有するべきです。
RFC 3986 [5] 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. All URI scheme specifications MUST define their own syntax such that all strings matching their scheme-specific syntax will also match the <absolute-URI> grammar described in Section 4.3 of RFC 3986.
RFC 3986 [5]階層識別子を定義するために多くのURIスキームで使用される一般的なURIコンポーネントの構文と一緒に、すべてのURIスキームのための一般的な構文を定義します。すべてのURIスキームの仕様は、彼らのスキーム固有の構文に一致するすべての文字列もRFC 3986のセクション4.3で説明した<絶対URI>の文法にマッチするような、独自の構文を定義しなければなりません。
New URI schemes SHOULD reuse the common URI components of RFC 3986 for the definition of hierarchical naming schemes. However, if there is a strong reason for a URI scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of previously registered schemes.
新しいURIスキームは階層命名スキームの定義については、RFC 3986の一般的なURIコンポーネントを再利用する必要があります。階層的な構文を使用しないURIスキームのための強力な理由がある場合は、その後、新しいスキームの定義は、以前に登録されたスキームの構文に従ってください。
URI schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments).
相対URIで使用するために意図されていないURIスキームは、階層区切り文字のために使用されているスラッシュ「/」の文字と、完全なパスセグメントの使用を避けるべきです「」そして「..」（ドットセグメント）。
Avoid improper use of "//". The use of double slashes in the first part of a URI is not an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's <scheme-specific-part> contains a hierarchical structure as described in RFC 3986. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See Section 3.2 of RFC 3986 for more details.) URI 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であることを芸術的指標ではありません：URIの<スキーム固有の部分>の構文は、階層構造が含まれている場合にのみ、RFCで説明したようにダブルスラッシュが使用されていますそのようなスキームからのURIで3986、ダブルスラッシュを使用すると、次にくるものが命名機関のトップの階層の要素であることを示しています。 （詳細は、RFC 3986のセクション3.2を参照してください。）「<スキーム>：」次、二重スラッシュを使用すべきではない彼らの<スキーム固有の部分>に準拠階層構造を含まないURIスキーム文字列を。
New URI schemes SHOULD clearly define the role of RFC 3986 [5] reserved characters in URIs of the scheme being defined. The syntax of the new scheme should be clear about which of the "reserved" set of characters (as defined in RFC 3986) are used as delimiters within the URIs of the new scheme, and when those characters must be escaped, versus when they may be used without escaping.
新しいURIスキームは明確スキームのURIの中に予約文字が定義されている[5] RFC 3986の役割を定義する必要があります。とき、彼らは可能性のある新しいスキームの構文は、対、新しいスキームのURIの内の区切り文字として使用されている（RFC 3986で定義されている）文字セット「予約」のこれ、およびそれらの文字をエスケープしなければならない場合について明確にする必要がありますエスケープせずに使用すること。
While URIs may or may not be useful as locators in practice, a URI 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スキームの定義自体は、機能することが期待される方法として明確でなければなりません。ロケータとして使用されることが意図されていないスキームは、識別されたリソースは、そのスキームのURIを取得するソフトウェアによって決定またはアクセスすることができる方法を記述するべきです。
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 URI scheme.
ロケータとして機能する方式の場合は、リソースロケーションのメカニズムを明確に定義することが重要です。これは、URIスキームの性質に応じて異なるものを意味するかもしれません。
In many cases, new URI schemes are defined as ways to translate between other namespaces or protocols and the general framework of URIs. For example, the "ftp" URI scheme translates into the FTP protocol, while the "mid" URI scheme translates into a Message-ID identifier of an email message. For such schemes, the description of the mapping must 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, might be represented in a valid URI. In particular, the mapping should describe the mechanisms for encoding binary or character strings within valid character sequences in a URI (See Section 2.6 for guidelines). If not all legal values or protocol interactions of the base standard can be represented using the URI scheme, the definition should be clear about which subset are allowed, and why.
多くの場合、新しいURIスキームは、他の名前空間またはプロトコルとURIの一般的なフレームワーク間の変換する方法として定義されています。 「中間」URIスキームは、電子メールメッセージのメッセージIDの識別子に変換しながら、例えば、「FTP」URIスキームは、FTPプロトコルに変換します。ターゲット名前空間のプロトコルアクションまたは名前の識別子またはセットにURIからマッピングする方法、および方法：両方向のマッピングは明らかであるように、このような方式のため、マッピングの説明は、完全な、そして十分詳細になければなりませんベースの名前空間での正当な値、または法的プロトコルの相互作用は、有効なURIで表現される可能性があります。具体的には、マッピングは、URIで有効な文字列（ガイドラインについては2.6節を参照）内のバイナリまたは文字列を符号化するためのメカニズムを記述する必要があります。ベース規格の全てではない正当な値またはプロトコル相互作用はURIスキームを使用して表すことができる場合には、定義が許可されているサブセットについて明確である、なぜべきです。
As part of the definition of how a URI identifies a resource, a URI scheme definition SHOULD define the applicable set of operations that may be performed on a resource using the URI as its identifier. A model for this is HTTP; an HTTP resource can be operated on by GET, POST, PUT, and a number of other operations available through the HTTP protocol. The URI scheme definition should describe all well-defined operations on the URI identifier, and what they are supposed to do.
URIのリソースを識別する方法の定義の一部として、URIスキームの定義は、その識別子としてURIを使用して、リソース上で実行される動作の適用可能なセットを定義する必要があります。このためのモデルはHTTPです。 HTTPリソースは、GET、POST、PUT、およびHTTPプロトコルを介して利用可能な他の操作の数によって操作することができます。 URIスキームの定義は、URI識別子にすべて明確に定義されたオペレーションを記述する必要があり、それらが行うことになっているもの。
Some URI schemes don't fit into the "information access" paradigm of URIs. For example, "telnet" provides location information for initiating a bi-directional data stream to a remote host; the only operation defined is to initiate the connection. In any case, the operations appropriate for a URI scheme should be documented.
いくつかのURIスキームは、URIの「情報アクセス」パラダイムに適合しません。例えば、「Telnetは」リモートホストへの双方向データストリームを開始するための位置情報を提供します。定義された動作のみが接続を開始することです。いずれの場合においても、URIスキームの適切な操作が文書化されるべきです。
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.
注意：「GETから離れて何も操作がこのURIのために定義されていない」と言うことは完全に有効です。と言うことも有効である「このURIのために定義された1つの操作のみがあります、それは非常にGETのようではありません」。重要な点は、この方式で定義されているものを説明されていることです。
In general, URIs are used within a broad range of protocols and applications. Most commonly, URIs are used as references to resources within directories or hypertext documents, as hyperlinks to other resources. In some cases, a URI 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.
一般に、URIはプロトコルとアプリケーションの広い範囲で使用されます。最も一般的には、URIは、他のリソースへのハイパーリンクとして、ディレクトリやハイパーテキスト文書内のリソースへの参照として使用されています。いくつかのケースでは、URIスキームは、プロトコルまたはアプリケーションの異なる、特定のセット内で使用するために意図されています。その場合、スキームの定義は、使用目的を説明し、引用したアプリケーションおよび/またはプロトコルを定義ドキュメントへの参照を含むべきです。
When describing URI 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 RFC 3987 [6] and Section 2.5 of RFC 3986 [5] 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の要素は、人間が読み取り可能なテキストの表現は、実際には、注意が文字が次にURI文字にオクテットに符号化された方法で、不要な多様性を導入しないように注意すべきです。 RFC 3987 [6]およびガイドラインについてはRFC 3986のセクション2.5 [5]を参照。スキームのURIは任意のテキストフィールドが含まれている場合は、スキームの定義は、スキームのIRIを持つ文字がエンコードされる方法、および互換性の問題を説明しなければなりません。
Definitions of URI schemes MUST be accompanied by a clear analysis of the security implications for systems that use the URI scheme; this follows the practice of Security Consideration sections within IANA registrations [3].
URIスキームの定義は、URIスキームを使用するシステムのセキュリティへの影響の明確な分析を添付しなければなりません。これは、IANA登録[3]内のセキュリティの考慮事項のセクションの練習に従っています。
In particular, Section 7 of RFC 3986 [5] describes general security considerations for URI schemes. The definition of an individual URI scheme should note which of these apply to the specified scheme.
具体的には、RFC 3986のセクション7 [5] URIスキームのための一般的なセキュリティ上の考慮事項が記載されています。個々のURIスキームの定義は、指定されたスキームに適用されるこれらのどの注意してください。
Section 3.1 of RFC 3986 defines the syntax of a URI scheme name. New scheme registrations MUST comply. Note that although scheme names are case insensitive, scheme names MUST be registered using lowercase letters.
RFC 3986のセクション3.1には、URIのスキーム名の構文を定義します。新しいスキームの登録が遵守しなければなりません。スキーム名は大文字小文字を区別しないものの、スキーム名は小文字を使用して登録しなければならないことに留意されたいです。
URI scheme names should be short, but also sufficiently descriptive and distinguished to avoid problems.
URIスキーム名は短いが、また、問題を回避するのに十分な記述と区別されるべきです。
Avoid 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 7.4 of RFC 3978 [4].)
名前やIETF仕様およびインターネット・プロトコルで名前を使用する権利を持つ問題を引き起こす可能性がある他のシンボルを避けてください。例えば、商標およびサービスマーク名に注意してください。 （RFC 3978のセクション7.4 [4]を参照）。
Avoid using names that are either very general purpose or associated in the community with some other application or protocol. Avoid scheme names that are overly general or grandiose in scope (e.g., that allude to their "universal" or "standard" nature when the described namespace is not.)
いずれかの非常に一般的な目的や他のアプリケーションやプロトコルにコミュニティに関連付けられている名前を使用しないでください。スコープに過度に一般的または壮大ですスキーム名は避けてください（説明名前空間がないときに彼らの「ユニバーサル」または「標準」は、自然界にほのめかすなどを、。）
Organizations that desire a private name space for URI scheme names are encouraged to use a prefix based on their domain name, expressed in reverse order. For example, a URI scheme name of com-example-info might be registered by the vendor that owns the example.com domain name.
URIスキーム名のプライベート名前空間を望む組織がドメイン名に基づいて接頭辞を使用することが推奨され、逆の順番で表されています。たとえば、COM-例-情報のURIスキーム名がexample.comドメイン名を所有しているベンダーによって登録される可能性があります。
While the guidelines in Section 2 are REQUIRED for permanent registration, they are RECOMMENDED for provisional registration. For a provisional registration, the following are REQUIRED:
第2節のガイドラインは永久登録のために必要とされるが、それらは、仮登録のために推奨されています。仮登録の場合は、以下が必要です。
o The scheme name meets the syntactic requirements of Section 2.8. o There is not already an entry with the same URI scheme name. (In the unfortunate case that there are multiple, different uses of the same scheme name, the IESG may approve a request to modify an existing entry to note the separate use.) o Contact information identifying the person supplying the registration is included. Previously unregistered URI schemes discovered in use may be registered by third parties on behalf of those who created the URI scheme; in this case, both the registering party and the scheme creator SHOULD be identified. o If no permanent, citable specification for the URI scheme definition is included, credible reasons for not providing it should be given. o A valid Security Considerations section, as required by Section 6 of [3]. o If the scheme definition does not meet the guidelines laid out in Section 2, the differences and reasons SHOULD be noted.
Oスキーム名は、2.8節の構文上の要件を満たしています。 O同じURIスキーム名を持つエントリがすでにありません。 （同じスキーム名の複数の異なる用途があることは残念場合、IESGは、別個の使用に注意する既存のエントリを変更する要求を承認することができる。）登録供給者を識別するO連絡先情報が含まれています。使用中の発見以前に登録されていないURIスキームは、URIスキームを作成した人たちに代わって第三者によって登録することができます。この場合には、登録パーティやスキームの作成者の両方が特定されるべきです。 URIスキームの定義のための永久的な、引用可能仕様が含まれていない場合は、O、それを提供しないための確かな理由が与えられるべきです。有効なセキュリティConsiderations部O、[3]のセクション6によって必要とされます。スキームの定義は、第2節にレイアウトガイドラインを満たしていない場合は、O、違いとその理由を注意すべきです。
In some circumstances, it is appropriate to note a URI scheme that was once in use or registered but for whatever reason is no longer in common use or the 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 to where the scheme was previously defined or documented.
いくつかの状況では、一度の使用ではなかったか、登録されたが、何らかの理由で一般的に使用されていないか、または使用は推奨されないURIスキームを注意することは適切です。個々のURIスキームは（新たに、または既存の登録の更新など）の歴史」として登録することを要求するため、この場合には、可能です。一般的に使用されなくなった任意のスキームは歴史として指定することができます。登録はスキームが以前に定義または文書化された場所への何らかの指示が含まれている必要があります。
The URI registration process is described in the terminology of [3]. The registration process is an optional mailing list review, followed by "Expert Review". The registration request should note the desired status. The Designated Expert will evaluate the request against the criteria of the requested status. In the case of a permanent registration request, the Designated Expert may:
URIの登録処理は、[3]の用語で説明されています。登録プロセスは、「エキスパートレビュー」に続いて、オプションのメーリング・リストの見直し、です。登録要求には、希望の状態に注意しなければなりません。指定エキスパートは、要求された状態の基準に対する要求を評価します。永久的な登録要求の場合には、指定の専門家があります。
o Accept the URI scheme name for permanent registration. o Suggest provisional registration instead. o Request IETF review and IESG approval; in the meanwhile, suggest provisional registration.
O永久登録のためのURIのスキーム名を受け入れます。 Oの代わりに仮登録を提案します。リクエストIETFレビューとIESG承認の。一方で、仮登録をお勧めします。
URI scheme definitions contained within other IETF documents (Informational, Experimental, or Standards-Track RFCs) must also undergo Expert Review; in the case of Standards-Track documents, permanent registration status approval is required.
他のIETFのドキュメント（情報、実験、またはスタンダードトラックのRFC）内に含まれるURIスキームの定義はまた、専門家のレビューを受けなければなりません。標準トラック文書の場合には、永久的な登録状況の承認が必要になります。
Someone wishing to register a URI scheme SHOULD:
SHOULD URIスキームを登録したい誰か：
1. Check the IANA URI scheme registry to see whether or not there is already an entry for the desired name. If there is already an entry under the name, choose a different URI scheme name. 2. Prepare a URI scheme registration template, as specified in Section 5.4. The URI scheme registration template may be contained in an Internet Draft, alone or as part of some other protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of RFC 3978 [4]. 3. Send a copy of the template or a pointer to the containing document (with specific reference to the section with the template) to the mailing list uri-review@ietf.org, requesting review. In addition, request review on other mailing lists as appropriate. For example, general discussion of URI syntactical issues could be discussed on uri@w3.org; schemes for a network protocol could 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 requests. 4. 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.
1.希望の名前のエントリがすでに存在しているかどうかを確認するためにIANAのURIスキームのレジストリを確認してください。名前の下のエントリがすでに存在する場合、異なるURIスキーム名を選択します。 2. 5.4節で指定され、URIスキームの登録テンプレートを準備します。 URIスキームの登録テンプレートは、単独で、または他のいくつかのプロトコル仕様の一部として、インターネットドラフトに含まれていてもよいです。 [4]テンプレートはまた、いくつかの他の形態（別の文書の一部として、またはスタンドアロン文書など）に提出することができるが、コンテンツは、RFC 3978のガイドラインの下で「IETF貢献」として扱われます。 3.審査を要求し、メーリングリストuri-review@ietf.orgに（テンプレートのセクションを具体的に参照して）を含む文書にテンプレートやポインタのコピーを送信します。また、必要に応じて他のメーリングリスト上で審査をリクエスト。例えば、URI構文の問題の一般的な議論はuri@w3.orgに議論することができ、ネットワークプロトコルのためのスキームは、そのプロトコルのためのメーリングリストで議論することができます。議論とコメントのための合理的な時間を許可します。四週間は、永久的な登録要求のための合理的です。コメントを確認し、この文書で指定されたガイドラインに沿っにそれを持って来るために、必要に応じて提案の登録に改訂を行うため4.応答します。
5. Submit the (possibly updated) registration template (or pointer to document containing it) to IANA at iana@iana.org, specifying whether 'permanent' or 'provisional' registration is requested.
5.「永久的な」または「暫定」の登録が要求されているかどうかを指定して、iana@iana.orgでIANAに（おそらく更新）登録テンプレート（またはそれを含むドキュメントへのポインタ）を提出してください。
Upon receipt of a URI scheme registration request,
URIスキームの登録要求を受信すると、
1. IANA checks the submission for completeness; if sections are missing or citations are not correct, IANA rejects the registration request. 2. IANA checks the current registry for a entry with the same name; if such a registry exists, IANA rejects the registration request. 3. IANA requests Expert Review of the registration request against the corresponding guidelines. 4. The Designated Expert may request additional review or discussion, as necessary. 5. If Expert Review recommends registration 'provisional' or 'permanent' registration, IANA adds the registration to the appropriate registry. 6. Unless Expert Review has explicitly rejected the registration request within two weeks, IANA should automatically add the registration in the 'provisional' registry.
1. IANAは、完全性について提出をチェックします。セクションが欠落しているか引用が正しくない場合、IANAは、登録要求を拒否します。 2. IANAは、同じ名前を持つエントリの現在のレジストリをチェックします。このようレジストリが存在する場合は、IANAは、登録要求を拒否します。 3. IANAは、対応するガイドラインに対する登録要求のエキスパートレビューを依頼します。 4.指定Expertは、必要に応じて、追加的なレビューや議論を要求することができます。 5.エキスパートレビューが登録「暫定的」または「パーマ」の登録を推奨していた場合は、IANAは、適切なレジストリへの登録を追加します。 6.専門家レビューが明示的に2週間以内に登録要求を拒否した場合を除き、IANAは、自動的に「暫定」レジストリに登録を追加する必要があります。
Either based on an explicit request or independently initiated, the Designated Expert or IESG may request the upgrade of a 'provisional' registration to a 'permanent' one. In such cases, IANA should move the corresponding entry from the provisional registry.
いずれかの明示的な要求に基づいて、または独立して開始され、指定エキスパートまたはIESGは「パーマ」一つに「暫定」登録のアップグレードを要求することができます。このような場合に、IANAは、仮登録から対応するエントリを移動しなければなりません。
Registrations may be updated in each 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 may be updated by the original registrant or anyone designated by the original registrant. In addition, the IESG may reassign responsibility for a provisional registration scheme, or may 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 may 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' may be requested by anyone authorized to update the provisional registration.
「パーマ」のステータスに「暫定」からの移行は、新しい「パーマ」の登録と同じように要求し、承認することができます。 「歴史的」状態に「永久」からの移行は、IESGの承認を必要とします。 「歴史」に「仮」からの遷移は、仮登録を更新する権限誰によって要求されてもよいです。
This template describes the fields that must be supplied in a URI scheme registration request:
このテンプレートは、URIスキームの登録要求に供給されなければならないフィールドについて説明します。
URI scheme name. See Section 2.8 for guidelines. Status. This reflects the status requested, and should be one of 'permanent', 'provisional', or 'historical'. URI scheme syntax. See Section 2.2 for guidelines. URI scheme semantics. See Section 2.3 and Section 2.4 for guidelines. Encoding considerations. See Section 2.3 and Section 2.6 for guidelines. Applications/protocols that use this URI scheme name. Applications and/or protocols that use this URI scheme name; see Section 2.5. Interoperability considerations. If you are aware of any details regarding your scheme that might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of any underlying protocol. Security considerations. See Section 2.7 for guidelines. Contact. Person (including contact information) to contact for further information. Author/Change controller. Person (including contact information) authorized to change this, if a provisional registration. References. Include full citations for all referenced documents. Registration templates for provisional registration may be included in an Internet Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated.
URIのスキーム名。ガイドラインについては、2.8節を参照してください。状態。これは、要求された状態を反映し、かつ、「永久的な」「暫定」、または「歴史」は1でなければなりません。 URIスキームの構文。ガイドラインについては、2.2節を参照してください。 URIスキームの意味。 2.3節とガイドラインについては、2.4節を参照してください。エンコーディングの考慮事項。 2.3節とガイドラインについては、2.6節を参照してください。このURIのスキーム名を使用するアプリケーション/プロトコル。このURIのスキーム名を使用するアプリケーションおよび/またはプロトコル。セクション2.5を参照してください。相互運用性の考慮。あなたが相互運用性に影響を与えるかもしれないあなたのスキームに関するあらゆる細部を認識している場合は、ここではそれらを識別してください。例えば：プロプライエタリまたは珍しい符号化方法。マルチバイト文字セットをサポートすることができません。任意の基礎となるプロトコルの種類やバージョンとの互換性がありません。セキュリティの考慮事項。ガイドラインについては、2.7節を参照してください。接触。 （連絡先情報を含む）の人は、詳細のために連絡します。著者/コントローラを変更します。 （連絡先情報を含む）の人は、仮登記場合は、これを変更する権限。参考文献。すべての参照文書の完全な引用を含めます。仮登録の登録テンプレートは、インターネットドラフトに含まれていてもよいです。文書の有効期限が切れるか、RFCとして公表のために承認された場合、登録が更新されます。
This document replaces the current "URL Scheme" registry with a new Uniform Resource Identifier scheme registry, and establishes a new registration template and a new process for registration. The process is based on [3] "Expert Review" with an initial (optional) mailing list review.
この文書は、新しい統一資源識別子スキームレジストリで現在の「URLスキーム」レジストリを置き換え、新たな登録テンプレートと登録のための新しいプロセスを確立します。プロセスは初期（別売）メーリングリストの口コミを[3]「エキスパートレビュー」に基づいています。
The template has an additional field for the status of the URI name scheme, and the procedures for entering new name schemes have been augmented. Section 5 establishes the process for new URI scheme registration.
テンプレートは、URI名スキームのステータスの追加フィールドを持ち、新しい名前スキームを入力するための手順が拡張されています。第5節では、新たなURIスキームの登録のためのプロセスを確立します。
To transition to the new registry, all URL name schemes in the existing table should be entered as URI schemes, with 'permanent' status.
新しいレジストリに移行するには、既存のテーブル内のすべてのURL名のスキームは「パーマ」の状態で、URIスキームとして入力する必要があります。
All registered values are expected to contain accurate security consideration sections; 'permanent' registered scheme names are expected to contain complete definitions.
すべての登録された値は、正確なセキュリティ考慮セクションを含むことが期待されています。 「パーマ」登録制度名は、完全な定義を含むことが期待されています。
Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered URI scheme may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered URI scheme.
プロトコルの可能なセキュリティの脆弱性に関する情報は、時間の経過とともに変化することがあります。これにより、登録されたURIスキームのセキュリティ特性として特許請求の範囲は、同様に変化してもよいです。新たな脆弱性が発見されているように、このような脆弱性に関する情報は、ユーザーが登録されたURIスキームの真のセキュリティ・プロパティへと誤解されないように、既存の文書に添付する必要があるかもしれません。
Many thanks to 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 versions.
ポール・ホフマン、アイラマクドナルド、ロイ・フィールディング、ステューヴァイベル、トニー・ハモンド、チャールズリンジー、マーク・ベイカー、およびそれ以前のバージョンの彼らのコメントのためのuri@w3.orgメーリングリストの他のメンバーに感謝します。
Parts of this document are based on [7], [8] and [10]. Some of the ideas about use of URIs were taken from the "Architecture of the World Wide Web" [11].
この文書の部分は基づいている[7]、[8]、[10]。 URIの使用に関するアイデアのいくつかは、[11]「ワールド・ワイド・ウェブのアーキテクチャ」から取られました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2]堀、R.、 "URN構文"、RFC 2141、1997年5月を。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[4] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[4]ブラドナー、S.、 "貢献におけるIETF権"、BCP 78、RFC 3978、2005年3月。
[5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[5]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[6] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[6] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[7] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[7] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年11月に。
[8] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[8] Masinter、L.、Alvestrand、H.、Zigmond、D.、およびR. Petke、 "新しいURLスキームのためのガイドライン"、RFC 2718、1999年11月。
[9] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[9] Daigle氏、L.、バンGulik、D.、Iannella、R.、およびP. Faltstrom、 "統一リソース名（URN）名前空間定義メカニズム"、BCP 66、RFC 3406、2002年10月。
[10] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[10] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、 "メッセージヘッダフィールドの登録手順"、BCP 90、RFC 3864、2004年9月。
[11] W3C Technical Architecture Group, "Architecture of the World Wide Web, Volume One", December 2004, <http://www.w3.org/TR/webarch/>.
[11] W3Cテクニカルアーキテクチャグループ、 "ワールド・ワイド・ウェブのアーキテクチャ1巻"、2004年12月、<http://www.w3.org/TR/webarch/>。
Authors' Addresses
著者のアドレス
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
トニー・ハンセンAT＆T研究所200ローレルアベニュー。ミドルタウン、NJ 07748 USA
EMail: tony+urireg@maillennium.att.com
メールアドレス：tony+urireg@maillennium.att.com
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Campbell, CA USA
テッドハーディークアルコム社675キャンベル・テクノロジー・パークウェイ・キャンベル、CA USA
EMail: hardie@qualcomm.com
メールアドレス：hardie@qualcomm.com
Larry Masinter Adobe Systems 345 Park Ave San Jose, CA 95110 US
ラリーMasinterアドビシステムズ345パークアベニューサンノゼ、CA 95110米国
Phone: +1 408 536 3024 EMail: LMM@acm.org URI: http://larry.masinter.net
電話：+1 408 536 3024 Eメール：LMM@acm.org URI：http://larry.masinter.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。