RFC2718 日本語訳
2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D.Zigmond, R. Petke. November 1999. (Format: TXT=19208 bytes) (Obsoleted by RFC4395) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Masinterがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2718年のゼロックス社のカテゴリ: 情報のH.Alvestrand Maxware、Pirsenteret D.Zigmond WebTV Networks Inc.R.Petke UUNET技術1999年11月
Guidelines for new URL Schemes
新しいURL Schemesのためのガイドライン
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
Uniform Resource Locator(URL)はインターネットを通して利用可能なリソースのための位置のコンパクトなストリング表現です。 このドキュメントは新しいURL計画の定義のためのガイドラインを提供します。
1. Introduction
1. 序論
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.
Uniform Resource Locator(URL)はインターネットを通して利用可能なリソースのための位置のコンパクトなストリング表現です。 RFC2396[1]はURIの一般的な構文と意味論、および包含によるURLを定義します。 URLはaを含んでいることによって指定されて、「<は>を計画する」ということです。 そして、「<の計画特有の部分>。」 多くの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計画が登録されている過程はRFC2717[2]で定義されます。
Masinter, et al. Informational [Page 1] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[1ページ]のRFC2718Guidelines
2. Guidelines for new URL schemes
2. 新しいURL計画のためのガイドライン
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計画との互換性と同様に。 このセクションはこれらの評価基準について詳しく説明します。
2.1 Syntactic compatibility
2.1 構文の互換性
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計画が異なった計画と構文を共有しないなら、内容を書き直さないで、異なった計画の下で同じ内容を供給できません。 これは既に問題であるかもしれません、そして、将来のデジタル署名計画では、書き直しは可能でさえないかもしれません。 したがって、他の計画の展開は将来、非常に難しくなることができました。
2.1.1 Motivations for syntactic compatibility
2.1.1 構文の互換性に関する動機
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.
o 断片構文が2つの計画、(例えば、「<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.
o 断片構文が同じ能力の異なったメディアタイプの間で共有されないなら(GIF、JPEG、PNGなどの例えば、HTML、XML、Word、またはイメージタイプ)、あなたは満足している交渉に応じて彼らが今日適切に利用可能であるか、ありそうな仕事にさえなるのに従って優れたメディアタイプに発展できる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.
o 相対的な構文(URIが親類的であってURIストリングのどんな一部が相対的であるかということであることを理解する範囲への)が2つの計画の間で共有されないなら(例えば、「<a hrefが等しい、「foo">")、あなたは本質的に、間の参考の自己が埋め込まれた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.
o 「」 . . 」 ユリの親類ところの経路コンポーネントとしての構文が計画の間で分配していなくて、埋め込まれた参照を書き直さないで、あなたは、容易に文献集合のセットを持って、計画の間でそれらについて言及できません。
Masinter, et al. Informational [Page 2] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[2ページ]のRFC2718Guidelines
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.
o 「」 分配していて、あなたが階層構造の上、または、名前の相対的な階層構造で複数のセットのドキュメントを容易に動かさせることができないということでなく、」 構文(URIが現在の命名権威に比例して経路について言及するのを理解する範囲まで、セクション2.1.1を見る)がその計画か計画の間でそれらの間の共有された内容を書き直すことのない一般的なセットのドキュメントを共有する/。 最も良い例は一般的なセットのGIF、JPEG、およびPNGイメージを持っているサイトです、そして、あなたは深さが同じでない1つの深さから別のものまで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 「権威を構文と命名する、(例えば、ことが」 //に続いている、」 大部分のURLが計画するコネ、セクション2.1.1を)見てください。そうすれば、相対パス構文は分配しています、URIには命名権威があって、命名権威対経路がURIストリングのどんな一部であるかを理解する範囲に)、2つの計画の間で分配していて、あなたが同じ名前空間を共有して、異なった計画でそれらを供給できないということではありません。 (命名権威構文は計画の特性です。) そのHTTP、およびFTPはそうしました。事実、例えば同じ構文はサイトによってURLが計画以外の計画の間で同じになるようにHTTPアーカイブサービスに対するftpアーカイブサービスから移行するのがしばしば利用されました。 2つの計画で同時に、同じ内容に役立つことができます。
2.1.2 Improper use of "//" following "<scheme>:"
「2.1.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.
過去の数年に設定されたいくつかの例とは逆に、1つのURLの<計画特有のパート>の最初の部品としての二重スラッシュの使用は単に続くことがURLであるという芸術的なインディケータではありません: URL<計画特有のパート>の構文がRFC2396で説明されるように階層構造を含むときだけ、二重スラッシュは使用されます。 そのような計画からのURLでは、二重スラッシュの使用は、続くことが命名権威のための最高階層的な要素であることを示します。 (その他の詳細に関してRFC2396のセクション3を見てください。) 続いて、それらの<計画特有のパート>にconformant階層構造を含まないURL計画が二重スラッシュを使用するべきでない、「<計画>:」 結びます。
2.1.3 Compatibility with relative URLs
2.1.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 「RFC2396によると、例えば象徴であるなら計画を分析できる」//、」、」、/、」 」 ; 」 使用される“?"、それらはRFC2396に意味当然のことを持っていますか?
Masinter, et al. Informational [Page 3] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[3ページ]のRFC2718Guidelines
o Does the scheme make sense to use it in relative URLs like those
RFC 2396 specifies?
o 計画はそれらのRFC2396が指定するように相対的な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 計画構文がばらばらに壊れるように設計されるなら、計画の構文のためのドキュメンテーションはそれらの断片が何であるか、そして、それがなぜこのように壊れるべきであるか、そして、中断がなぜRFC2396が通常、それらがそうであるべきであると言うところでないかを指定しますか?
o If the scheme has a hierarchy, does it go left-to-right and with
slash separators like RFC 2396?
o 計画に階層構造があるなら、それはRFC2396のように真直に出られて、スラッシュ分離符で行って行きますか?
2.2 Is the scheme well defined?
2.2 計画はよく定義されますか?
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.
URLが「場所を見つける」「リソース」の意味論がよく定義されるのは、重要です。 これはURL計画の本質による別物を意味するかもしれません。
2.2.1 Clear mapping from other name spaces
2.2.1 他の名前から空間を写像して、クリアしてください。
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.
多くの場合、新しいURL計画は他のプロトコルと名前空間をURLの一般的な枠組みに翻訳する方法と定義されます。 "ftp"URL計画はFTPプロトコルから翻訳されます、「中間」のURL計画がメッセージのMessage-ID分野から翻訳されますが。
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計画を使用することでどうベース規格のすべての法定価格を表すことができるか、そして、およびまさにどの修飾語、交互のフォームが説明しなければならないか、そして、ベース規格からの他の人工物は、含まれているか、または含まれていません。 これらの要件は以下に詳しく説明されます。
2.2.2 URL schemes associated with network protocols
2.2.2 ネットワーク・プロトコルに関連している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.)
ほとんどの新しいURL計画が1つを持っているネットワーク資源かそれらにアクセスできるいくつかのネットワーク・プロトコルに関連しています。 'ftp'、'ニュース'、および'http'計画はこの種のものです。 そのような計画のために、仕様はネットワーク資源のアクセスを明白にすることができるくらいの詳細におけるプロトコル動作にURLがどう翻訳されるかを完全に説明するべきです。 URL計画の実現が何らかの構成を必要とするなら、明確に構成要素を特定しなければなりません。 (例えば、NTTPを使用することで実行されるなら、'ニュース'計画はNTTPサーバの構成を必要とします。)
Masinter, et al. Informational [Page 4] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[4ページ]のRFC2718Guidelines
2.2.3 Definition of non-protocol URL schemes
2.2.3 非プロトコルURL計画の定義
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.
いくつかの場合、URL計画には、それらに関連している特定のネットワーク・プロトコルがありません、彼らの使用がアクセス法が理解されている文脈に制限されるので。 例えば、これは「Cid」と「中間」のURL計画を伴うそうです。 これらのURL計画のために、仕様はソースから計画の記法とロケータの完全なマッピングについて説明するべきです。
2.2.4 Definition of URL schemes not associated with data resources
2.2.4 データ源に関連づけられなかったURL計画の定義
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.
ほとんどのURL計画が検索するか、または変更できるデータ・オブジェクトに対応するインターネット資料の場所を見つけます。 これは"ftp"と例えば、"http"があるそうです。 しかしながら、いくつかのURL計画はそうしません。 例えば、"mailto"URL計画はインターネット郵便の宛先に対応しています。
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計画がデータ・オブジェクトであるリソースの場所を見つけないなら、明確に新しいスペースの名前の特性を定義しなければなりません。
2.2.5 Character encoding
2.2.5 キャラクターコード化
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.
URLについて説明するとどれが中に計画されるか、(いくつか、)、URLの要素が実際にキャラクタの系列の表現である、キャラクタが八重奏の中と、そして、そして、URLキャラクタの中にコード化される方法で不要なバラエティーを紹介しないように注意するべきです。 特定の計画が別の方法でする何らかのやむにやまれない理由がない場合、UTF-8(RFC2279)[3]にキャラクタシーケンスを翻訳して、次に、次に%HHを使用して、危険な八重奏のためのコード化はお勧めです。
2.2.6 Definition of operations
2.2.6 操作の定義
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.)
いくつかの文脈(例えば、HTMLは形成される)では、特定のURLに実行されるために操作のリストのどれかを指定するのは可能です。 (フォームの外では、一般に、それが何かであると思われる、あなた、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"パラダイムによく合いません。 これは記録されるべきです。
Masinter, et al. Informational [Page 5] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[5ページ]のRFC2718Guidelines
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のそれほどようではありません」と言うのも有効です。 重要なポイントはこのタイプの上で定義されることが説明されるということです。
2.3 Demonstrated utility
2.3 示されたユーティリティ
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.
URL計画はユーティリティを実施説明するべきでした。 新しいURL計画は支える高価なものです。 しばしば、彼らはブラウザ、プロキシ、そして/または、サーバの特別なコードを必要とします。 同じことを言う多くの方法を不必要にすると、インターネットに価値を高めないで、これらのプログラムは複雑にされます。
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 この計画を使用することでそれが(例えば、)プロキシゲートウェイよりはるかにそれらに達しやすいもの。
2.3.1 Proxy into HTTP/HTML
2.3.1 HTTP/HTMLへのプロキシ
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.
既存のプロトコルを使用することでクライアントの新しい計画に物を提供するゲートウェイを通してユーティリティのデモンストレーションを提供する1つの方法があります。 それは新しい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 Ifであることを見つけることができるただ一つのグローバルな解決メカニズムがある、ユーザがこのタイプのどんな物も見つけて、「彼自身のプロキシを車で送ることができる」方法(返された物のタイプがよく定義した操作が1〜1(ことによると修飾語を使用して)にHTTP操作にmappableするo Are--o Is)があります。 - MIMEの満足しているタイプとして? - そこでHTML?o Isに翻訳できるプロキシのためにコードを走らせることとして?
Masinter, et al. Informational [Page 6] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[6ページ]のRFC2718Guidelines
2.4 Are there security considerations?
2.4 セキュリティ問題がありますか?
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のFrom:分野、またはAFS: URLにおけるAFSアクセスに必要であるケルベロスログイン)と共に使用される必要があることができるリクエスタを特定するためのメカニズムがありますか?
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のように例えば)、--
2.5 Does it start with UR?
2.5 それはURから始まりますか?
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.
どんなそのような提案も、タイプの唯一の計画になるというそれの後ろの大きいコンセンサスがあるのを確実にするべきであるか、または別の名前を選ぶべきです。
2.6 Non-considerations
2.6 非問題
Some issues that are often raised but are not relevant to new URL schemes include the following.
しばしば上げられましたが、新しいURL計画に関連していないいくつかの問題が以下を含んでいます。
Masinter, et al. Informational [Page 7] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[7ページ]のRFC2718Guidelines
2.6.1 Are all objects accessible?
2.6.1 すべての物がアクセスしやすいですか?
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.
答えは、時々、時々はい、そして、いいえになるでしょう。 しばしば、それは直接計画自体に関連しない要素(ファイアウォールやクライアント構成のような)に依存するでしょう。
3. Security Considerations
3. セキュリティ問題
New URL schemes are required to address all security considerations in their definitions.
新しいURL計画が、彼らの定義におけるすべてのセキュリティ問題を記述するのに必要です。
4. References
4. 参照
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、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計画名のための登録手順」BCP35、1999年11月のRFC2717。
[3] Yergeau, F., "UTF-8, A Transformation Format of Unicode and ISO
10646", RFC 2279, January 1998.
[3]、1998年1月のYergeau、F.、「UTF-8、ユニコードとISO10646の変化形式」RFC2279。
Masinter, et al. Informational [Page 8] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[8ページ]のRFC2718Guidelines
5. Authors' Addresses
5. 作者のアドレス
Larry Masinter Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304
ラリーMasinterゼロックス社のパロアルト研究センター3333コヨーテヒル・Roadパロアルト、カリフォルニア 94304
URL: http://purl.org/NET/masinter EMail: masinter@parc.xerox.com
URL: http://purl.org/NET/masinter メール: masinter@parc.xerox.com
Harald Tveit Alvestrand Maxware, Pirsenteret N-7005 Trondheim NORWAY
ハラルドTveit Alvestrand Maxware、Pirsenteret N-7005トロンヘイムノルウェー
Phone: +47 73 54 57 00 EMail: harald.alvestrand@maxware.no
以下に電話をしてください。 +47 73 54 57 00はメールされます: harald.alvestrand@maxware.no
Dan Zigmond WebTV Networks, Inc. 305 Lytton Avenue Palo Alto, CA 94301 USA
ダンZigmond WebTV Networks Inc.305リットンAvenueカリフォルニア94301パロアルト(米国)
Phone: +1-650-614-6071 EMail: djz@corp.webtv.net
以下に電話をしてください。 +1-650-614-6071 メールしてください: djz@corp.webtv.net
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000
豊かなPetke UUNET技術5000ブリトン道路P. O. Box5000ヒラード、OH43026-5000
Phone: +1-614-723-4157 Fax: +1-614-723-8407 EMail: rpetke@wcom.net
以下に電話をしてください。 +1-614-723-4157 Fax: +1-614-723-8407 メールしてください: rpetke@wcom.net
Masinter, et al. Informational [Page 9] RFC 2718 Guidelines for new URL Schemes November 1999
Masinter、他 新しいURL Schemes1999年11月のための情報[9ページ]のRFC2718Guidelines
6. Full Copyright Statement
6. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Masinter, et al. Informational [Page 10]
Masinter、他 情報[10ページ]
一覧
スポンサーリンク
