[要約] RFC 4395は、新しいURIスキームのガイドラインと登録手続きに関するものであり、URIスキームの作成者や登録者に対して指針を提供することを目的としています。
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
新しいURIスキームのガイドラインと登録手順
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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]によって定義されています。各URIは、RFC 3986のセクション3.1で定義されているスキーム名で始まります。これは、そのスキーム内の識別子の仕様を指します。URI構文は、フェデレートで拡張可能な命名システムを提供します。この命名システムでは、各スキームの仕様により、そのスキームを使用して識別子の構文とセマンティクスがさらに制限される場合があります。このドキュメントは、これらの定義を定義、登録、または評価している人々による検討のための新しいURIスキームの定義のガイドラインと、IANA 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.
この文書は、RFCS 2717 [7]と2718 [8]の両方を廃止します。RFCS 2717と2718は、「ロケーター」（インターネット上で利用可能なリソースにアクセスするために使用される識別子）と「名前」（それらにアクセスするためのメカニズムとは無関係に、抽象リソースの命名に使用される識別子）の区別を引き出しました。意図は、ロケーターである識別子に指定「URL」（均一なリソースロケーター）を使用し、名前である識別子に「URN」（ユニフォームリソース名）を使用することでした。実際には、「ロケーター」と「名前」の間の線を描画するのは困難です。ロケーターは名前として使用でき、名前はロケーターとして使用できます。
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.
その結果、最近のドキュメントでは、すべてのリソース識別子に「URI」という用語を使用して、「URL」という用語を避け、「URN」スキーム名（RFC 2141 [2]）を使用して「URN」という用語を明示的に予約しました。urn "namespaces"（RFC 3406 [9]）は、「URN」スキームに固有であり、このドキュメントで明示的にカバーされていません。
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は、URIスキームを登録できる登録ツリーのセットを定義しました。その1つはIETFツリーと呼ばれ、IANAによって管理されました。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）を導入し、URISとIRISの間のマッピングを定義しました。IRISの別のレジストリまたは登録プロセスはありません。IRISとして役立つリソース識別子を説明したい場合は、対応する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.
このドキュメント内では、キーワードは、将来の登録文書の要件であるというコンテキスト内で、RFC 2119 [1]で確立された一般的な意味内で使用される、必要、必要は、必要に応じて、推奨される可能性があります。
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で説明されている<Absolute-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スキームは、階層的区切り文字と完全なパスセグメントに使用されるフォワードスラッシュ "/"文字の使用を避ける必要があります。および ".."（dot-segments）。
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：ダブルスラッシュがURIの<スキーム特異的パート>の構文がRFCに記載されているように階層構造を含む場合にのみ使用されるという芸術的指標ではありません。3986.そのようなスキームからのURIでは、二重スラッシュの使用は、命名権限の最上位階層要素であることを示しています。（詳細については、RFC 3986のセクション3.2を参照してください。）<スキーム固有のパート>にコンフォーマルな階層構造を含めないURIスキームは、「<scheme>：」文字列に続いて二重スラッシュを使用してはなりません。
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のRFC 3986 [5]予約文字の役割を明確に定義する必要があります。新しいスキームの構文は、（RFC 3986で定義されているように）「予約済み」の文字セットのどれが新しいスキームのURI内の区切り文字として使用され、それらの文字が逃げなければならないときと、いつに対して逃げなければならないかについて明確にする必要があります。逃げることなく使用します。
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の一般的な枠組みを翻訳する方法として定義されています。たとえば、「FTP」URIスキームはFTPプロトコルに変換され、「Mid」URIスキームは電子メールメッセージのメッセージID識別子に変換されます。このようなスキームの場合、マッピングの説明は完全に、そして両方向のマッピングが明確になるように十分に詳細でなければなりません。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.
注：「このURIについては、GET以外の操作は定義されていない」と言うのは完全に有効です。また、「この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 [5]のセクション2.5を参照してください。スキームのurisにテキストフィールドが含まれている場合、スキーム定義は、文字がエンコードされる方法と、スキームの虹彩との互換性の問題を説明する必要があります。
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 [5]のセクション7では、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 [4]のセクション7.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.
他のアプリケーションまたはプロトコルを使用して、コミュニティで非常に汎用的または関連付けられている名前の使用を避けてください。範囲が過度に一般的または壮大なスキーム名を避けてください（例えば、記載されている名前空間がそうでない場合、「普遍的な」または「標準的な」性質を暗示しています）。逆順序で表現されたドメイン名に基づいたプレフィックス。たとえば、com-example-infoの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スキームを作成した人々に代わって第三者によって登録される場合があります。この場合、登録当事者とスキーム作成者の両方を特定する必要があります。o URIスキーム定義の永続的で引用可能な仕様が含まれていない場合、それを提供しないという信頼できる理由を指定する必要があります。o [3]のセクション6で要求されるように、有効なセキュリティ上の考慮事項セクション。oスキーム定義がセクション2で定められたガイドラインを満たしていない場合、違いと理由に注意する必要があります。
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]の用語で説明されています。登録プロセスは、オプションのメーリングリストリストのレビューであり、その後に「Expert Review」が続きます。登録リクエストは、目的のステータスに注意する必要があります。指定された専門家は、要求されたステータスの基準に対する要求を評価します。恒久的な登録要求の場合、指定された専門家は次の場合があります。
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ドキュメント（情報、実験、または標準トラックRFCS）に含まれるURIスキーム定義も、専門家のレビューを受ける必要があります。標準トラック文書の場合、恒久的な登録ステータスの承認が必要です。
Someone wishing to register a URI scheme 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スキーム登録テンプレートは、単独または他のプロトコル仕様の一部として、インターネットドラフトに含まれる場合があります。テンプレートは、他の形式（別のドキュメントの一部またはスタンドアロンドキュメントとして）で提出することもできますが、内容はRFC 3978のガイドラインで「IETF貢献」として扱われます[4]。3.テンプレートまたはポインターのコピーを含むドキュメント（テンプレートのあるセクションを特定の参照）に送信して、レビューを要求します。さらに、必要に応じて、他のメーリングリストでレビューをリクエストします。たとえば、URIの構文問題に関する一般的な議論は、uri@w3.orgで議論できます。ネットワークプロトコルのスキームについては、そのプロトコルのメーリングリストで説明できます。議論やコメントの合理的な時間を確保してください。恒久的な登録リクエストには4週間が合理的です。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.指定された専門家は、必要に応じて追加のレビューまたはディスカッションを要求する場合があります。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.
Paul Hoffmann、Ira McDonald、Roy Fielding、Stu Weibel、Tony Hammond、Charles Lindsey、Mark Baker、および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の使用に関するアイデアのいくつかは、「World Wide Webのアーキテクチャ」から取られました[11]。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats、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] Bradner、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[6] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[6] Duerst、M。and M. Suignard、「Internationalized Resource Identiers（IRIS）」、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. King、「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.、Van 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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、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テクニカルアーキテクチャグループ、「World Wide Webのアーキテクチャ、ボリューム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ローレルアベニュー、ミドルタウン、ニュージャージー07748 USA
EMail: tony+urireg@maillennium.att.com
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Campbell, CA USA
Ted Hardie Qualcomm、Inc。675 Campbell Technology Parkway Campbell、CA米国
EMail: hardie@qualcomm.com
Larry Masinter Adobe Systems 345 Park Ave San Jose, CA 95110 US
Larry Masinter Adobe Systems 345 Park Ave San Jose、CA 95110 US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。