RFC4395 日本語訳

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

コメントを求めるワーキンググループT.ハンセン要求をネットワークでつないでください: 4395のAT&T研究所が以下を時代遅れにします。 2717、2718T.ハーディーBCP: 115クアルコムInc.カテゴリ: 最も良い現在の練習L.Masinterアドビ・システムズ2006年2月

       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.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはUniform Resource Identifier(URI)計画の定義のためのガイドラインと推薦を提供します。 また、それはURI計画のために過程とIANA登録をアップデートします。 それはRFC2717とRFC2718の両方を時代遅れにします。

Hansen, et al.           Best Current Practice                  [Page 1]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[1ページ]RFC4395の新しいURI計画2006年2月

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 永久的なURI計画定義. . . . . . . 4 2.1のためのガイドライン。 Demonstratableであって、新しくて、長命のユーティリティ. . . . . . . . . 4 2.2。 構文の互換性. . . . . . . . . . . . . . . . . 5 2.3。 明確な.52.4。 操作. . . . . . . . . . . . . . . . . 6 2.5の定義。 使用. . . . . . . . . . . . . . . . . . . . . . 6 2.6の文脈。 国際化とキャラクターコード化. . . . . . . 7 2.7。 セキュリティ問題. . . . . . . . . . . . . . 7 2.8をクリアしてください。 名前問題. . . . . . . . . . . . . . . . 7 3を計画してください。 暫定的なURI計画登録. . . . . . 8 4のためのガイドライン。 歴史的なURI計画登録. . . . . . 8 5のためのガイドライン。 URI計画登録手順. . . . . . . . . . . . . . 9 5.1。 一般.95.2。 登録手順. . . . . . . . . . . . . . . . . 9 5.3。 コントロール. . . . . . . . . . . . . . . . . . . . . . 10 5.4を変えてください。 URI計画登録テンプレート. . . . . . . . . . . . . 11 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 11 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 12 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 13 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 13

Hansen, et al.           Best Current Practice                  [Page 2]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[2ページ]RFC4395の新しいURI計画2006年2月

1.  Introduction

1. 序論

   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.

Uniform Resource Identifier(URI)プロトコル要素と一般的な構文はRFC3986[5]によって定義されます。 RFC3986のセクション3.1によって定義されるように各URIは計画名で始まって、それはその計画の中に識別子のための仕様を示します。 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.

このドキュメントはRFCs2717[7]と2718[8]の両方を時代遅れにします。 RFCs2717と2718は'ロケータ'(インターネットで利用可能なリソースにアクセスするのに使用される識別子)と'名前'(それらにアクセスするためのどんなメカニズムの如何にかかわらずことによると抽象的なリソースを命名するのに使用される識別子)の間で区別をつけました。 意図はロケータであったそれらの識別子のための名称「URL」(Uniform Resource Locator)と名前であったそれらの識別子のための「つぼ」(一定のリソース名)を使用することでした。 実際には、'ロケータ'と'名前'の間の線は描くのは難しいです: 名前としてロケータを使用できます、そして、ロケータとして名前を使用できます。

   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」という用語を避けて、それらのURIのために明らかに「つぼ」という用語を取っておいて。(RFC2141[2])。 URN、「名前空間、」 (RFC3406[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.

RFC2717はURI計画を登録できた登録木のセットを定義しました。IANAによって管理されるように、その1つはIETF Treeと呼ばれました。 RFC2717は、追加登録木が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:

このドキュメントはURI計画のために異なった'木'のRFC2717の区別を排除します。 代わりに、登録された値のためのただ一つの名前空間があります。 その名前空間の中に、URI計画のための1セットの評価基準を満たすと承認される値があります。 また、必ずそれらの評価基準を満たすというわけではなくて、他の計画名は臨時に登録されるかもしれません。 登録の意図は以下のことのためのことです。

Hansen, et al.           Best Current Practice                  [Page 3]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[3ページ]RFC4395の新しいURI計画2006年2月

   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.

o 確立したURI計画名のための発見の主要なポイント、およびそれらの定義文書の簡単な位置を提供してください。 o 同じURI計画名の異なる役割の使用に水をさしてください。 o ものが確立した傾向とコンベンションについて明察するために新しいURI計画名を提案するのを助けてください、そして、既存のものに混乱するかもしれない名前を避けてください。 o 暫定的な登録証明書に低いバリアを設定することによって、登録を奨励してください。

   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.

RFC3987[6]は新しいプロトコル要素、Internationalized Resource Identifier(IRI)を導入して、URIとIRIsの間のマッピングを定義しました。 IRIsのためのどんな別々の登録も登録手続もありません。 役に立つリソース識別子をIRIsとして記述したがっている人は、対応するURI構文を定義して、IRI用法がRFC3987で定義された規則と変化に従うことに注意するべきです。

   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.

このドキュメントの中では、キーワードはそうしなければなりません、5月、SHOULD、REQUIRED、RECOMMENDED、そして、使用されるなどが一般的な意味の中でそれらが将来の登録用書類に関する要件であることを文脈の中のRFC2119[1]に確証しました。

2.  Guidelines for Permanent URI Scheme Definitions

2. 永久的なURI計画定義のためのガイドライン

   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計画登録のためのREQUIREDです。 また、これらのガイドラインを満たすのは、セクション3で説明されるように仮登記のためのRECOMMENDEDです。

2.1.  Demonstratable, New, Long-Lived Utility

2.1. Demonstratableであって、新しくて、長命のユーティリティ

   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計画は単一の、そして、グローバルな名前空間を構成します。 短くて、簡略記憶の計画名の使用の上の主張を避けるのは望ましいです。 これらの理由で、新しい計画の限りない登録は有害です。 SHOULDにはある新しいURI計画はそれを超えた広いインターネットコミュニティに既に登録されたURI計画で利用可能な状態でユーティリティをクリアします。

Hansen, et al.           Best Current Practice                  [Page 4]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[4ページ]RFC4395の新しいURI計画2006年2月

2.2.  Syntactic Compatibility

2.2. 構文の互換性

   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.

RFC3986[5]はすべてのURI計画のために一般的な構文を定義します、多くのURI計画によって使用される、階層的な識別子を定義する一般的なURIコンポーネントの構文と共に。 すべてのURI計画仕様が、また、それらの計画特有の構文に合っているすべてのストリングが>文法がRFC3986のセクション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計画SHOULDは階層的な命名計画の定義のためにRFC3986の一般的なURIの部品を再利用します。 しかしながら、URI計画が階層的な構文を使用しない強い理由があれば、新しい計画定義SHOULDは以前に登録された計画の構文に従います。

   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 SHOULDとの使用がフォワードの使用を避けるので、意図しなかった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の<計画特有のパート>の構文がRFC3986で説明されるように階層構造を含むときだけ、二重スラッシュは使用されます。 そのような計画からのURIでは、二重スラッシュの使用は、続くことが命名権威のための最高階層的な要素であることを示します。 (その他の詳細に関してRFC3986のセクション3.2を見てください。) 続いて、それらの<計画特有のパート>SHOULD NOTにconformant階層構造を含まない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計画SHOULDは定義される計画のURIで明確に[5]の控え目なRFC3986キャラクタの役割を定義します。 新しい計画の構文は「予約された」セットのキャラクタ(RFC3986で定義されるように)のどれがデリミタとして新しい計画のURIの中で使用されるか、そして、いつそれらのキャラクタから逃げなければならないかに関して明確であるはずです、彼らが逃げないで使用されるかもしれない時に対して。

2.3.  Well-Defined

2.3. 明確

   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計画定義自体は明確であるに違いありません。 ロケータSHOULDとして使用されることを意図しない計画はその計画のURIを得るソフトウェアから特定されたリソースに決定するか、またはどうアクセスできるかを説明します。

Hansen, et al.           Best Current Practice                  [Page 5]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[5ページ]RFC4395の新しいURI計画2006年2月

   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プロトコルに翻訳されます、「中間」のURI計画がメールメッセージに関するMessage-ID識別子に翻訳されますが。 そのような計画において、マッピングの記述が完全であり、詳細に十分なそうしなければならないので、両方の指示のマッピングは明確です: ベース名前空間における法定価格をプロトコル動作の識別子かセットへのURIから写像するか、目標名前空間、およびどのようにでどう命名するか、そして、または法的なプロトコル相互作用が有効なURIで表されるかもしれません。 特に、マッピングは、URIにおける有効なキャラクタシーケンスの中でバイナリーか文字列をコード化するためにメカニズムについて説明するべきです(ガイドラインに関してセクション2.6を見てください)。 定義はどの部分集合が許容されているか、そして、なぜに関してそうでなければ、URI計画を使用することでベース規格のすべての法定価格かプロトコル相互作用を表すことができるのが明確であるはずであるか。

2.4.  Definition of Operations

2.4. 操作の定義

   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計画定義を特定するかに関する定義の一部と、SHOULDは識別子としてURIを使用することでリソースに実行されるかもしれない適切な操作を定義します。 これのためのモデルはHTTPです。 HTTPリソースでは、GET、ポスト、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のそれほどようではありません」と言うのも有効です。 重要なポイントはこの計画で定義されることが説明されるということです。

2.5.  Context of Use

2.5. 使用の文脈

   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

一般に、URIは広範囲なプロトコルとアプリケーションの中で使用されます。 最も一般的に、URIはディレクトリかハイパーテキストドキュメントの中のリソースの参照、ハイパーリンクとして使用されます。

Hansen, et al.           Best Current Practice                  [Page 6]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[6ページ]RFC4395の新しいURI計画2006年2月

   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計画は使用のためにプロトコルかアプリケーションの異なって、特定のセットの中で意図します。 そうだとすれば、計画定義SHOULDは意図している使用について説明して、ドキュメンテーションの引用されたアプリケーション、そして/または、プロトコルを定義する指示するものを含んでいます。

2.6.  Internationalization and Character Encoding

2.6. 国際化とキャラクターコード化

   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キャラクタの中にコード化される方法で不要なバラエティーを紹介しないように注意するべきです。 ガイドラインのためのRFC3986[5]のRFC3987[6]とセクション2.5を見てください。 計画のURIが何かテキストフィールドを含んでいるなら、計画定義はキャラクタがコード化される方法、および計画のIRIsのどんな互換性の問題も述べなければなりません。

2.7.  Clear Security Considerations

2.7. 明確なセキュリティ問題

   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]の中でSecurity Consideration部の習慣に続きます。

   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.

特に、RFC3986[5]のセクション7はURI計画のために総合証券問題について説明します。 個々のURI計画の定義は、これらのどれが指定された計画に適用されるかに注意するべきです。

2.8.  Scheme Name Considerations

2.8. 計画名前問題

   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.

RFC3986のセクション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仕様とインターネットプロトコルに名前を使用する権利で問題を起こすかもしれない名前か他のシンボルを避けてください。 例えば、商標とサービスマーク名に注意してください。 (RFC3978[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.)

共同体である他のアプリケーションかプロトコルに非常に汎用であることの、または、関連している名前を使用するのを避けてください。 範囲でひどく一般的であるか、または雄大な計画名を避けてください。(説明された名前空間が暗示しないとき、例えば、それは彼らの「普遍的である」か「標準」の本質について暗示します。)

Hansen, et al.           Best Current Practice                  [Page 7]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[7ページ]RFC4395の新しいURI計画2006年2月

   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ドメイン名を所有している業者によって登録されるかもしれません。

3.  Guidelines for Provisional URI Scheme Registration

3. 暫定的なURI計画登録のためのガイドライン

   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のガイドラインは永久的な登録のためのREQUIREDですが、それらは仮登記のためのRECOMMENDEDです。 仮登記のために、↓これはREQUIREDです:

   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の構文の必要条件を満たします。同じURI計画名でo Thereは既にエントリーではありません。 (ある不幸な場合では同じくらいの複数の、そして、異なった用途は名前を計画して、IESGは別々の使用に注意するように既存のエントリーを変更するという要求を承認するかもしれません。) o 登録を供給する人を特定する問い合わせ先は含まれています。 以前、使用中に発見された登録されていないURI計画はURI計画を作成した人を代表して第三者によって登録されるかもしれません。 特定されて. 永久的でないo If citable仕様は、URI計画定義がそれを提供しない含まれていて、確かな理由であるので、必要に応じてセクション6によって[3]を. o A有効なSecurity Considerations部に与えられるべきです。登録パーティーと計画創造者SHOULDの両方が、この場合、計画定義がするo Ifはセクション2で広げられたガイドラインを満たしません、違いということであり、SHOULDを推論します。注意されます。

4.  Guidelines for Historical URI Scheme Registration

4. 歴史的なURI計画登録のためのガイドライン

   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計画が'歴史的である'として登録されるよう(新たにか既存の登録へのアップデートとして)要求するのは、可能です。 どんなもう共用でない計画も歴史的に任じられるかもしれません。 登録は計画が以前に、定義されたか、または記録されたところに何らかの指示を含むべきです。

Hansen, et al.           Best Current Practice                  [Page 8]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[8ページ]RFC4395の新しいURI計画2006年2月

5.  URI Scheme Registration Procedure

5. URI計画登録手順

5.1.  General

5.1. 一般

   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]の用語で説明されます。 登録手続は「専門のレビュー」がいうことになった任意のメーリングリストレビューです。 登録要求は必要な状態に注意するべきです。 Designated Expertは要求された状態の評価基準に対して要求を評価するでしょう。 永久的な登録要求の場合では、Designated Expertはそうするかもしれません:

   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 永久的な登録代わりに. o Request IETFが見直すo Suggest仮登記とIESG承認のためにURI計画名を受け入れてください。 その間、仮登記を示してください。

   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ドキュメント(情報のExperimental、またはStandards-道のRFCs)の中に含まれたURI計画定義はExpert Reviewを受けなければなりません。 Standards-道のドキュメントの場合では、永久的な登録状態承認が必要です。

5.2.  Registration Procedures

5.2. 登録手順

   Someone wishing to register a URI scheme SHOULD:

URI計画SHOULDを登録したがっているだれか:

   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計画登録テンプレートは単独かインターネットDraftか、ある他のプロトコル仕様の一部として含まれるかもしれません。 また、ある他のフォーム(別のドキュメントの一部とした、または、スタンドアロンのドキュメントとした)でテンプレートを提出するかもしれませんが、RFC3978[4]のガイドラインの下で「IETF貢献」としてコンテンツを扱うでしょう。 3. メーリングリスト uri-review@ietf.org への含んでいるドキュメント(テンプレートがあるセクションの特定指示がある)にテンプレートかポインタのコピーを送ってください、レビューを要求して。 さらに、適宜他のメーリングリストに関するレビューを要求してください。 例えば、 uri@w3.org; でURIの構文の問題の一般的な議論について議論できました。 そのプロトコルのためのメーリングリストでネットワーク・プロトコルの計画について議論できました。 議論とコメントのための妥当な時間を許容してください。 永久的な登録要求に、4週間は妥当です。 4. 必要に応じて提案された登録に応じて、コメントを見直して、改正をして、本書では与えるガイドラインにそれを一致させてください。

Hansen, et al.           Best Current Practice                  [Page 9]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[9ページ]RFC4395の新しいURI計画2006年2月

   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は対応するガイドラインに対して登録要求のExpert Reviewを要求します。 4. Designated Expertは必要に応じて追加レビューか議論を要求するかもしれません。 5. Expert Reviewが登録の'暫定的である'か'永久的な'登録を推薦するなら、IANAは適切な登録に登録を加えます。 6. Expert Reviewが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.

明白な要求に基づくか独自に開始されています、Designated ExpertかIESGが'暫定的な'登録のアップグレードを'永久的な'ものまで要求するかもしれません。 そのような場合、IANAは暫定的な登録から対応するエントリーを動かすはずです。

5.3.  Change Control

5.3. 変化コントロール

   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承認を必要とします。 '暫定的'から'歴史的になる'までの変遷は仮登記をアップデートするのに権限を与えられただれによっても要求されているかもしれません。

Hansen, et al.           Best Current Practice                 [Page 10]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[10ページ]RFC4395の新しいURI計画2006年2月

5.4.  URI Scheme Registration Template

5.4. URI計画登録テンプレート

   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を見てください。 連絡します。 詳細のために連絡する人(問い合わせ先を含んでいます)。 コントローラを書くか、または変えてください。 仮登記であるならこれを変えるのに権限を与えられた人(問い合わせ先を含んでいます)。 参照。 すべての参照をつけられたドキュメントのための完全な引用を含めてください。 仮登記のための登録テンプレートはインターネットDraftに含まれるかもしれません。 ドキュメントを期限が切れるか、または公表のためにRFCとして承認するとき、登録をアップデートするでしょう。

6.  IANA Considerations

6. IANA問題

   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計画」登録を新しいUniform Resource Identifier計画登録に取り替えて、登録のために新規登録テンプレートとニュープロセスを確立します。 過程は[3] 初期(任意の)のメーリングリストレビューによる「専門のレビュー」に基づいています。

Hansen, et al.           Best Current Practice                 [Page 11]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[11ページ]RFC4395の新しいURI計画2006年2月

   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計画として入れられるべきです、'永久的な'状態で。

7.  Security Considerations

7. セキュリティ問題

   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計画の本当のセキュリティの特性に関してミスリードされないように。

8.  Acknowledgements

8. 承認

   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 メーリングリストについてポール・ホフマン、イラ・マクドナルド、ロイFielding、スチュー・ウェイベル、トニー・ハモンド、チャールズ・リンジー、マーク・ベイカー、および他のメンバーをありがとうございます。

   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]に基づいています。 「WWWの構造」[11]からURIの使用に関する考えのいくつかを取りました。

Hansen, et al.           Best Current Practice                 [Page 12]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[12ページ]RFC4395の新しいURI計画2006年2月

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[2]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。

   [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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [4]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978,
        March 2005.

[4] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。

   [6]  Duerst, M. and M. Suignard, "Internationalized Resource
        Identifiers (IRIs)", RFC 3987, January 2005.

[6]DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。

9.2.  Informative References

9.2. 有益な参照

   [7]   Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

[7]Petke、R.とI.キング、「URL計画名のための登録手順」BCP35、1999年11月のRFC2717。

   [8]   Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
         "Guidelines for new URL Schemes", RFC 2718, November 1999.

1999年11月の[8]MasinterとL.とAlvestrandとH.とZigmond、D.とR.Petke、「新しいURL Schemesのためのガイドライン」RFC2718。

   [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、「一定のリソースは(つぼ)名前空間定義をメカニズムと命名します」、BCP66、RFC3406、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.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90、2004年9月のRFC3864。

   [11]  W3C Technical Architecture Group, "Architecture of the World
         Wide Web, Volume One", December 2004,
         <http://www.w3.org/TR/webarch/>.

[11] W3C構造グループ、技術的な「WWWの構造、第1巻」2004年12月、<http://www.w3.org/TR/webarch/>。

Hansen, et al.           Best Current Practice                 [Page 13]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[13ページ]RFC4395の新しいURI計画2006年2月

Authors' Addresses

作者のアドレス

   Tony Hansen
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, NJ  07748
   USA

トニーハンセンAT&T研究所200ローレルAve。 ミドルタウン、ニュージャージー07748米国

   EMail: tony+urireg@maillennium.att.com

メール: しゃれた+ urireg@maillennium.att.com

   Ted Hardie
   Qualcomm, Inc.
   675 Campbell Technology Parkway
   Campbell, CA
   USA

テッドハーディークアルコムInc.675キャンベルTechnologyパークウェイのカリフォルニアキャンベル(米国)

   EMail: hardie@qualcomm.com

メール: hardie@qualcomm.com

   Larry Masinter
   Adobe Systems
   345 Park Ave
   San Jose, CA  95110
   US

ラリーMasinterアドビ・システムズ345公園Aveカリフォルニア95110サンノゼ(米国)

   Phone: +1 408 536 3024
   EMail: LMM@acm.org
   URI:   http://larry.masinter.net

以下に電話をしてください。 +1 3024年の408 536メール: LMM@acm.org ユリ: http://larry.masinter.net

Hansen, et al.           Best Current Practice                 [Page 14]

RFC 4395                    New URI Schemes                February 2006

ハンセン、他 最も良い現在の習慣[14ページ]RFC4395の新しいURI計画2006年2月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Hansen, et al.           Best Current Practice                 [Page 15]

ハンセン、他 最も良い現在の習慣[15ページ]