Network Working Group L. Masinter
Request for Comments: 2718 Xerox Corporation
Category: Informational H. Alvestrand
Maxware, Pirsenteret
D. Zigmond
WebTV Networks, Inc.
R. Petke
UUNET Technologies
November 1999
Guidelines for new URL Schemes
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. This document provides guidelines for the definition of new URL schemes.
ユニフォームリソースロケータ（URL）は、インターネットを介して利用可能であるリソースの位置のコンパクトな文字列表現です。この文書は、新しいURLスキームを定義するためのガイドラインを提供します。
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. RFC 2396 [1] defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a "<scheme>:" and then a "<scheme-specific-part>". Many URL schemes are already defined.
ユニフォームリソースロケータ（URL）は、インターネットを介して利用可能であるリソースの位置のコンパクトな文字列表現です。 RFC 2396 [1] URIの一般的な構文及びセマンティクスを定義し、そして、封入により、URLを。 「<スキーム>：」とし、「<スキーム固有の部分>」のURLが含むことによって指定されています。多くのURLスキームがすでに定義されています。
This document provides guidelines for the definition of new URL schemes, for consideration by those who are defining and registering or evaluating those definitions.
この文書では、それらの定義を定義し、登録または評価している人々によって検討のために、新しいURLスキームを定義するためのガイドラインを提供します。
The process by which new URL schemes are registered is defined in RFC 2717 [2].
新しいURLスキームが登録されるプロセスは、RFC 2717で定義されている[2]。
Because new URL schemes potentially complicate client software, new schemes must have demonstrable utility and operability, as well as compatibility with existing URL schemes. This section elaborates these criteria.
新しいURLスキームは、潜在的にクライアントソフトウェアを複雑にしているので、新しいスキームは、既存のURLスキームとの明白な有用性と操作性だけでなく、互換性を持っている必要があります。このセクションでは、これらの基準を詳しく説明します。
New URL schemes should follow the same syntactic conventions of existing schemes when appropriate. If a URI scheme that has embedded links in content accessed by that scheme does not share syntax with a different scheme, the same content cannot be served up under different schemes without rewriting the content. This can already be a problem, and with future digital signature schemes, rewriting may not even be possible. Deployment of other schemes in the future could therefore become extremely difficult.
適切なときに新しいURLスキームは、既存のスキームの同じ構文規則に従わなければなりません。そのスキームによってアクセスされるコンテンツ内のリンクが埋め込まれているURIスキームが異なる方式に構文を共有しない場合は、同じコンテンツがコンテンツを書き換えることなく、異なるスキームの下で提供することができません。これはすでにさえできないことがあり、書き換え、および将来のデジタル署名方式と、問題になる可能性があります。将来的には他のスキームの展開は極めて困難になる可能性があります。
Why should new URL schemes share as much of the generic URI syntax (that makes sense to share) as possible? Consider the following:
なぜ新しいURLスキームが可能と（それが共有することは理にかなって）一般的なURI構文の多くを共有する必要がありますか？次のことを考えてみます。
o If fragment syntax isn't shared between two schemes, (e.g. "<a href="#foo">"), you can't move individual completely self referential documents between schemes without rewriting the embedded references within the document. In the Web, the fragment syntax is a property of the media type, and evaluated by the client.
フラグメント構文が2つのスキームの間で共有されていない場合は、O、（例えば「<aのhref="#foo">」）は、ドキュメント内に埋め込まれた参照を書き換えることなく、制度間の完全個別の自己参照文書を移動することはできません。ウェブでは、フラグメントの構文は、メディアタイプのプロパティであり、そしてクライアントによって評価しました。
o If fragment syntax is not shared between different media types of the same capability (e.g. HTML, XML, Word, or image types such as GIF, JPEG, PNG) then you can't have a URI reference that can evolve to superior media types as they become available, or even likely work properly today with content negotiation.
フラグメントの構文は、同じ機能の異なるメディアタイプ（例えばGIF、JPEG、PNGなど例えばHTML、XML、ワード、または画像タイプ）との間で共有されていない場合は、O、あなたは、優れたメディアタイプに進化させることができURI参照を持つことはできません彼らはコンテンツネゴシエーションを適切に今日利用できるようになる、あるいはそうな作品として。
o If relative syntax (to the extent of understanding the URI is relative, and what part of the URI string is relative) isn't shared between two schemes, (e.g. "<a href="foo">"), you can't move sets of documents that are internally self referential between schemes without rewriting the embedded URIs.
相対的な構文は（URIの理解の程度の相対的であり、URI文字列のどの部分が相対的である）2つのスキーム（例えば「<aのhref="foo">」）との間で共有されていない場合は、O、あなたは」することができますトン埋め込まれたURIを書き換えることなく、内部のスキーム間の自己参照している文書のセットを移動します。
o If the ".." syntax as a path component in relative URI's isn't shared between schemes, you can't easily have sets of document sets and refer to them between schemes without rewriting the embedded references.
相対URIの中のパスの構成要素として「..」構文はスキームの間で共有されていない場合は、O、あなたは簡単にドキュメントセットのセットを持っており、組み込みの参照を書き換えることなくスキームの間にそれらを参照することはできません。
o If the "/" syntax (to the extent of understanding that the URI refers to a path relative to the current naming authority, see section 2.1.1) isn't shared, you can't have multiple sets of documents easily be moved up or down in a relative hierarchy of names and share a common set of documents between them, without rewriting the content, shared either in that scheme or between schemes. The best example is a site that has a common set of GIF's, JPEG and PNG images, and you want to reorganize the site changing the depth of a subtree from one depth to another, or from one directory to another where the depth isn't the same.
「/」構文が（URIは、現在の命名機関への相対パスを参照していることを理解の範囲内で、セクション2.1.1を参照）が共有されていない場合は、O、あなたは、文書の複数のセットを容易に移動させることはできませんアップまたは名前の相対的な階層におけるダウンとそれらの間の文書の共通セットを共有して、コンテンツを書き換えることなく、そのスキームまたはスキームの間のいずれかで共有。深さがない場合、最良の例では、GIFの、JPEGやPNG画像の共通セットを持つサイトで、あなたは別の深さからのサブツリーの深さを変えるサイトを再編成したい、または1つのディレクトリから別の同じ。
o If naming authority syntax (e.g. what comes after "//" in most URL schemes, see section 2.1.1) and relative path syntax is shared, to the extent of understanding that the URI has a naming authority, and what part of the URI string is the naming authority vs. path), isn't shared between two schemes, you can't share identical name spaces and serve them up via different schemes. (The naming authority syntax is a property of the scheme). The fact that HTTP, and FTP have the same syntax, for example, has often been exploited by sites transitioning from ftp archive service to HTTP archive service so that the URL's can be identical between schemes except for the scheme; the same content can be served via two schemes simultaneously.
O（セクション2.1.1を参照してください、ほとんどのURLスキームに「//」の後に来るものなど）権限の構文を命名し、相対パス構文場合がURIが命名権を持っていることを理解の範囲で、共有されている、とのどの部分URI文字列は、両方式の間で共有されていないパス対命名機関）である、あなたは、同じ名前空間を共有し、異なる方式を経由してそれらを提供することはできません。 （命名機関の構文は、スキームのプロパティです）。 URLのスキームを除くスキームの間で同一のものとすることができるように、HTTP、およびFTPは同じ構文を持っているという事実は、例えば、多くの場合、HTTPアーカイブサービスへのftpアーカイブサービスからの移行のサイトで利用されてきました。同じ内容は、同時に2つの方式を経由して提供することができます。
Contrary to some examples set in past years, the use of double slashes as the first component of the <scheme-specific-part> of a URL is not simply an artistic indicator that what follows is a URL: Double slashes are used ONLY when the syntax of the URL's <scheme-specific-part> contains a hierarchical structure as described in RFC 2396. In URLs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See section 3 of RFC 2396 for more details.) URL schemes which do not contain a conformant hierarchical structure in their <scheme-specific-part> should not use double slashes following the "<scheme>:" string.
過去数年間に設定されたいくつかの例とは異なり、URLの<スキーム固有の部分>の第一の成分として、ダブルスラッシュを使用することは、次にくるものがURLであることを単に芸術的な指標ではない：ダブルスラッシュがいる場合にのみ使用されていますそのようなスキームからのURLでRFC 2396に記載されたURLの<スキーム固有の部分>の構文は、階層構造を含む、二重のスラッシュの使用は、次にくるものが命名機関のトップの階層の要素であることを示しています。 （詳細は、RFC 2396のセクション3を参照してください。）その<スキーム固有の部分>に準拠階層構造を含まないURLスキーム「<スキーム>：」次、二重スラッシュを使用しないでください文字列。
URL schemes should use the generic URL syntax if they are intended to be used with relative URLs. A description of the allowed relative forms should be included in the scheme's definition. Many applications use relative URLs extensively. Specifically,
それらは、相対URLを使用することが意図されている場合はURLスキームは、一般的なURL構文を使用する必要があります。許可される相対的な形態の説明は、スキームの定義に含まれるべきです。多くのアプリケーションは広範囲に相対URLを使用します。具体的には、
o Can the scheme be parsed according to RFC 2396 - for example, if the tokens "//", "/", ";", or "?" are used, do they have the meaning given in RFC 2396?
OスキームはRFC 2396に従って解析することができます - 例えば、もしトークン「//」、「/」、「;」、または「？」使用されている、彼らはRFC 2396で与えられた意味を持っていますか？
o Does the scheme make sense to use it in relative URLs like those RFC 2396 specifies?
oはスキームは、これらのRFC 2396指定などの相対URLでそれを使用する意味がありますか？
o If the scheme syntax is designed to be broken into pieces, does the documentation for the scheme's syntax specify what those pieces are, why it should be broken in this way, and why the breaks aren't where RFC 2396 says that they usually should be?
Oスキームの構文は、断片に分割するように設計されているスキームの構文のドキュメントは、それがこのように分割する必要がありますなぜこれらの作品は、何であるかを指定しないと、RFC 2396には、彼らは通常べきであると述べているところ、なぜ休憩はしていない場合こと？
o If the scheme has a hierarchy, does it go left-to-right and with slash separators like RFC 2396?
スキームは階層を持っている場合は、O、それは左から右へ移動して、RFC 2396のようなスラッシュ区切りでありませんか？
It is important that the semantics of the "resource" that a URL
"locates" be well defined. This might mean different things
depending on the nature of the URL scheme.
In many cases, new URL schemes are defined as ways to translate
other protocols and name spaces into the general framework of
URLs. The "ftp" URL scheme translates from the FTP protocol,
while the "mid" URL scheme translates from the Message-ID field of
messages.
In either case, the description of the mapping must be complete, must describe how characters get encoded or not in URLs, must describe exactly how all legal values of the base standard can be represented using the URL scheme, and exactly which modifiers, alternate forms and other artifacts from the base standards are included or not included. These requirements are elaborated below.
いずれの場合も、マッピングの説明は正確にどの修飾、代替形式を、文字をURLでエンコードされたかを取得する方法を説明しなければならないURLスキームを使用してベースの標準のすべての法的な値を表すことができます正確にどのように記述しなければならない、と、完全でなければなりませんベース標準から他の成果物が含まれたり含まれていません。これらの要件は以下詳述されています。
Most new URL schemes are associated with network resources that
have one or several network protocols that can access them. The
'ftp', 'news', and 'http' schemes are of this nature. For such
schemes, the specification should completely describe how URLs are
translated into protocol actions in sufficient detail to make the
access of the network resource unambiguous. If an implementation
of the URL scheme requires some configuration, the configuration
elements must be clearly identified. (For example, the 'news'
scheme, if implemented using NTTP, requires configuration of the
NTTP server.)
In some cases, URL schemes do not have particular network
protocols associated with them, because their use is limited to
contexts where the access method is understood. This is the case,
for example, with the "cid" and "mid" URL schemes. For these URL
schemes, the specification should describe the notation of the
scheme and a complete mapping of the locator from its source.
Most URL schemes locate Internet resources that correspond to data
objects that can be retrieved or modified. This is the case with
"ftp" and "http", for example. However, some URL schemes do not;
for example, the "mailto" URL scheme corresponds to an Internet
mail address.
If a new URL scheme does not locate resources that are data objects, the properties of names in the new space must be clearly defined.
新しいURLスキームがデータオブジェクトであるリソースが見つからない場合は、新しい空間での名前のプロパティを明確に定義する必要があります。
When describing URL schemes in which (some of) the elements of the
URL are actually representations of sequences of characters, care
should be taken not to introduce unnecessary variety in the ways
in which characters are encoded into octets and then into URL
characters. Unless there is some compelling reason for a
particular scheme to do otherwise, translating character sequences
into UTF-8 (RFC 2279) [3] and then subsequently using the %HH
encoding for unsafe octets is recommended.
In some contexts (for example, HTML forms) it is possible to
specify any one of a list of operations to be performed on a
specific URL. (Outside forms, it is generally assumed to be
something you GET.)
The URL scheme definition should describe all well-defined operations on the URL identifier, and what they are supposed to do.
URLスキームの定義は、URL識別子にすべて明確に定義されたオペレーションを記述する必要があり、それらが行うことになっているもの。
Some URL schemes (for example, "telnet") provide location information for hooking onto bi-directional data streams, and don't fit the "infoaccess" paradigm of most URLs very well; this should be documented.
いくつかのURLスキーム（例えば、「telnetの」）の双方向のデータ・ストリーム上に引っ掛けるための位置情報を提供し、非常によく、ほとんどのURLの「infoaccess」パラダイムに適合しません。これは文書化されなければなりません。
NOTE: It is perfectly valid to say that "no operation apart from GET is defined for this URL". It is also valid to say that "there's only one operation defined for this URL, and it's not very GET-like". The important point is that what is defined on this type is described.
注：これは、「GETから離れて何も操作がこのURLのために定義されていない」と言うことは完全に有効です。と言うことも有効である「このURLのために定義された1つの操作のみがあります、それは非常にGETのようではありません」。重要な点は、このタイプに定義されているものを説明されていることです。
URL schemes should have demonstrated utility. New URL schemes are
expensive things to support. Often they require special code in
browsers, proxies, and/or servers. Having a lot of ways to say
the same thing needless complicates these programs without adding
value to the Internet.
The kinds of things that are useful include:
便利です物事の種類は次のとおりです。
o Things that cannot be referred to in any other way.
他の方法で参照することができない物事O。
o Things where it is much easier to get at them using this scheme than (for instance) a proxy gateway.
Oプロキシゲートウェイ（例えば）よりも、この方式を使用して、それらを取得する方がはるかに簡単である事。
One way to provide a demonstration of utility is via a gateway which provides objects in the new scheme for clients using an existing protocol. It is much easier to deploy gateways to a new service than it is to deploy browsers that understand the new URL object.
有用性の実証を提供するための一つの方法は、既存のプロトコルを使用して、クライアントのための新しい方式でオブジェクトを提供するゲートウェイを介してです。新しいURLオブジェクトを理解ブラウザを展開するよりも、新しいサービスへのゲートウェイを展開する方がはるかに簡単です。
Things to look for when thinking about a proxy are:
プロキシを考えるときに調べるべき事は、次のとおりです。
o Is there a single global resolution mechanism whereby any proxy can find the referenced object? o If not, is there a way in which the user can find any object of this type, and "run his own proxy"? o Are the operations mappable one-to-one (or possibly using modifiers) to HTTP operations? o Is the type of returned objects well defined? - as MIME content-types? - as something that can be translated to HTML? o Is there running code for a proxy?
oはどのプロキシが参照されるオブジェクトを見つけることができる単一のグローバル解決メカニズムはありますか？ない場合は、O、ユーザーがこのタイプの任意のオブジェクトを見つけて、「自分のプロキシを実行する」ことができる方法はありますか？ O操作は、HTTP操作に1対1（または可能性の修飾子を使用して）マップできていますか？ oが返されるオブジェクトの種類は、明確に定義されていますか？ - MIMEコンテンツ・タイプとして？ - HTMLに変換することができるものとして？ oはそこプロキシのコードを実行していますか？
Above and beyond the security considerations of the base mechanism a scheme builds upon, one must think of things that can happen in the normal course of URL usage.
スキームは上に構築の上に、ベースメカニズムのセキュリティの考慮事項を超えて、一つはURLの使用の通常の過程で発生する可能性が物事を考える必要があります。
In particular:
特に：
o Does the user need to be warned that such a thing is happening without an explicit request (GET for the source of an IMG tag, for instance)? This has implications for the design of a proxy gateway, of course.
oは、ユーザは、（例えば、IMGタグのソースのためにGET）そのようなことは、明示的な要求なしで起こっていることを警告する必要がありますか？これは当然のプロキシゲートウェイの設計のための意味を持っています。
o Is it possible to fake URLs of this type that point to different things in a dangerous way?
Oそれは危険な方法で異なるものを指し、このタイプの偽のURLをすることは可能ですか？
o Are there mechanisms for identifying the requester that can be used or need to be used with this mechanism (the From: field in a mailto: URL, or the Kerberos login required for AFS access in the AFS: URL, for instance)?
O使用またはこのメカニズム（：フィールドのmailtoで：URL、またはAFSでのAFSアクセスに必要なKerberosログイン：URL、例えばより）と一緒に使用する必要がありますすることができ、要求者を識別するためのメカニズムがありますか？
o Does the mechanism contain passwords or other security information that are passed inside the referring document in the clear (as in the "ftp" URL, for instance)?
Oメカニズムは、パスワードや（例えば、「FTP」URLのように）明確に言及する文書内渡された他のセキュリティ情報が含まれていますか？
Any scheme starting with the letters "U" and "R", in particular if it attaches any of the meanings "uniform", "universal" or "unifying" to the first letter, is going to cause intense debate, and generate much heat (but maybe little light).
最初の文字には意味「均一」のいずれかを付加した場合、「ユニバーサル」または「統一」特に、文字「U」と「R」で始まる任意のスキームは、激しい議論を引き起こし、多くの熱を発生させるために起こっています（多分少し軽いです）。
Any such proposal should either make sure that there is a large consensus behind it that it will be the only scheme of its type, or pick another name.
任意のこのような提案は、いずれか、それはそのタイプの唯一の方式であるか、または別の名前を選択することをその背後にある大きなコンセンサスがあることを確認してください。
Some issues that are often raised but are not relevant to new URL schemes include the following.
しばしば提起が、新しいURLスキームに関連していないされているいくつかの問題は、以下のものが含まれます。
Can all objects in the world that are validly identified by a scheme be accessed by any UA implementing it?
正当スキームによって識別され、世界のすべてのオブジェクトは、それを実装する任意のUAがアクセスすることはできますか？
Sometimes the answer will be yes and sometimes no; often it will depend on factors (like firewalls or client configuration) not directly related to the scheme itself.
時々、答えはイエス、時にはなしになります。多くの場合、それが直接のスキーム自体に関連しない（ファイアウォールやクライアントの設定など）の要因に依存します。
New URL schemes are required to address all security considerations in their definitions.
新しいURLスキームは、それらの定義ですべてのセキュリティ上の考慮事項に対処するために必要とされています。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[2] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[2] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年11月に。
[3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO 10646", RFC 2279, January 1998.
[3] Yergeau、F.、 "UTF-8、UnicodeとISO 10646の変換フォーマット"、RFC 2279、1998年1月。
Larry Masinter Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
ラリーMasinterゼロックス社のパロアルト研究所3333コヨーテヒルロードパロアルト、CA 94304
URL: http://purl.org/NET/masinter EMail: masinter@parc.xerox.com
URL：http://purl.org/NET/masinter Eメール：masinter@parc.xerox.com
Harald Tveit Alvestrand Maxware, Pirsenteret N-7005 Trondheim NORWAY
ハラルド・トバイット・アルベストランドMaxware、Pirsenteret N-7005トロンハイムノルウェー
Phone: +47 73 54 57 00 EMail: harald.alvestrand@maxware.no
電話：+47 73 54 57 00 Eメール：harald.alvestrand@maxware.no
Dan Zigmond WebTV Networks, Inc. 305 Lytton Avenue Palo Alto, CA 94301 USA
ダンZigmondのWebTVネットワークス株式会社305リットンアベニューパロアルト、CA 94301 USA
Phone: +1-650-614-6071 EMail: djz@corp.webtv.net
電話：+ 1-650-614-6071 Eメール：djz@corp.webtv.net
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000
リッチPetke UUNET Technologies社5000ブリトン道路P. O.ボックス5000ヒリアード、オハイオ州43026から5000
Phone: +1-614-723-4157 Fax: +1-614-723-8407 EMail: rpetke@wcom.net
電話：+ 1-614-723-4157ファックス：+ 1-614-723-8407 Eメール：rpetke@wcom.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。