Network Working Group K. Moore
Request for Comments: 3205 University of Tennessee
BCP: 56 February 2002
Category: Best Current Practice
On the use of HTTP as a Substrate
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.
最近、他のアプリケーションレベルのプロトコルのための基質としてハイパーテキスト転送プロトコル（HTTP）を使用してで広く関心がありました。このドキュメントでは、デフォルトポート、URLスキーム、およびHTTPのセキュリティメカニズムの使用を含め、このような使用の技術的な詳細を、お勧めします。
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) [1] as a substrate for other applications-level protocols. Various reasons cited for this interest have included:
最近、他のアプリケーションレベルのプロトコルのための基質として、[1]ハイパーテキスト転送プロトコル（HTTP）を使用してで広く関心がありました。この関心のために引用した様々な理由が含まれています：
o familiarity and mindshare,
親しみやすさとマインドシェアO、
o compatibility with widely deployed browsers,
広く導入されているブラウザとOとの互換性、
o ability to reuse existing servers and client libraries,
O既存のサーバーおよびクライアントライブラリを再利用する能力は、
o ease of prototyping servers using CGI scripts and similar extension mechanisms,
CGIスクリプトを使用したプロトタイピング・サーバと同様の拡張メカニズムのOのしやすさ、
o ability to use existing security mechanisms such as HTTP digest authentication [2] and SSL or TLS [3],
ダイジェスト認証HTTPなどの既存のセキュリティ・メカニズムを使用するO能力[2]、SSLまたはTLS [3]
o the ability of HTTP to traverse firewalls, and
ファイアウォールを通過するHTTPの能力、およびo
o cases where a server often needs to support HTTP anyway.
サーバは、多くの場合、とにかくHTTPをサポートする必要がある場合に、O。
The Internet community has a long tradition of protocol reuse, dating back to the use of Telnet [4] as a substrate for FTP [5] and SMTP [6]. However, the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate. Specifically, for a given application that is layered on top of HTTP:
インターネットコミュニティは、[4] FTP [5]やSMTPのための基質としてバックとTelnetの使用にまで遡る、プロトコルの再利用の長い伝統を持っている[6]。そのような使用が適切であり、それが適切である状況でHTTPを使用するための適切な方法しかし、HTTP上で新しいプロトコルを階層化における最近の関心は、質問の数を調達しています。具体的には、HTTPの上に積層され、所与のアプリケーションのために：
o Should the application use a different port than the HTTP default of 80?
Oアプリケーションは、80のHTTPのデフォルト以外のポートを使用する必要がありますか？
o Should the application use traditional HTTP methods (GET, POST, etc.) or should it define new methods?
Oアプリケーションでは、伝統的なHTTPメソッドを使用する必要があります（など、POSTをGET）、またはそれは新しいメソッドを定義する必要がありますか？
o Should the application use http: URLs or define its own prefix?
Oアプリケーションの使用はhttpべき：URLまたはには、独自の接頭辞を定義しますか？
o Should the application define its own MIME-types, or use something that already exists (like registering a new type of MIME-directory structure)?
Oアプリケーションは、独自のMIMEタイプを定義する、またはすでに（MIME-ディレクトリ構造の新しいタイプを登録するように）存在しているものを使用する必要がありますか？
This memo recommends certain design decisions in answer to these questions.
このメモはこれらの質問への答えである設計上の決定を推奨しています。
This memo is intended as advice and recommendation for protocol designers, working groups, implementors, and IESG, rather than as a strict set of rules which must be adhered to in all cases. Accordingly, the capitalized key words defined in RFC 2119, which are intended to indicate conformance to a specification, are not used in this memo.
このメモは、プロトコル設計者は、ワーキンググループ、実装、およびIESGのためではなく、全ての場合においてに接着しなければならないルールの厳格なセットとして助言及び勧告として意図されています。従って、仕様への適合性を示すことが意図されているRFC 2119で定義された大文字のキーワードは、このメモでは使用されません。
Despite the advantages listed above, it's worth asking the question as to whether HTTP should be used at all, or whether the entire HTTP protocol should be used.
上記の利点にもかかわらず、それはHTTPを全く使用する必要があるかどうかについての質問をする価値がある、または全体のHTTPプロトコルを使用するかどうか。
HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. These features include persistent connections, byte ranges, content negotiation, and cache support. All of these are useful for traditional web applications but may not be useful for the layered application. The need to support (or circumvent) these features can add additional complexity to the design and implementation of a protocol layered on top of HTTP. Even when HTTP can be "profiled" to minimize implementation overhead, the effort of specifying such a profile might be more than the effort of specifying a purpose-built protocol which is better suited to the task at hand.
HTTPは単純なプロトコルとしてスタートしたが、すぐに、そのオリジナルのデザインで予期しないいくつかの機能のほかにはるかに複雑になりました。これらの機能は持続的な接続、バイト範囲、内容の交渉、およびキャッシュのサポートが含まれています。これらのすべては、従来のWebアプリケーションのための有用であるが、層状のアプリケーションのために有用ではないかもしれません。サポート（または回避）これらの機能はHTTPの上位層プロトコルの設計と実装に追加の複雑さを追加することができますする必要があります。 HTTPは、インプリメンテーションのオーバーヘッドを最小限にするために、「プロファイル」することができたとしても、そのようなプロファイルを指定しての努力は当面の作業に適してい専用のプロトコルを指定する努力よりもかもしれません。
Even if existing HTTP client and server code can often be re-used, the additional complexity of layering something over HTTP vs. using a purpose-built protocol can increase the number of interoperability problems.
既存のHTTPクライアントとサーバのコードは、多くの場合、再利用することができたとしても、相互運用性の問題の数を増やすことができ専用プロトコルを使用して対HTTP経由で何かを積層する追加の複雑さ。
Further, although HTTP can be used as the transport for a "remote procedure call" paradigm, HTTP's protocol overhead, along with the connection setup overhead of TCP, can make HTTP a poor choice. A protocol based on UDP, or with both UDP and TCP variants, should be considered if the payloads are very likely to be small (less than a few hundred bytes) for the foreseeable future. This is especially true if the protocol might be heavily used, or if it might be used over slow or expensive links.
さらに、HTTPが「リモートプロシージャコール」パラダイムのためのトランスポートとして使用することができ、TCPの接続設定オーバーヘッドと一緒にHTTPのプロトコルのオーバーヘッドは、お粗末な選択HTTPを作ることができます。 UDPプロトコルに基づいて、またはUDPおよびTCP変異型の両方を持つペイロードが小さくなる可能性が非常に高い場合は、予見可能な将来のために（数百バイト未満）を考慮すべきです。プロトコルが頻繁に使用されるかもしれない場合、これは特にそうですか、それは低速または高価なリンク上で使用される可能性がある場合。
On the other hand, the connection setup overhead can become negligible if the layered protocol can utilize HTTP/1.1's persistent connections, and if the same client and server are likely to perform several transactions during the time the HTTP connection is open.
階層プロトコルは、HTTP / 1.1の持続的接続を利用できる場合は、同じクライアントとサーバがHTTP接続が開いている時間の間に、いくつかのトランザクションを実行する可能性がある一方、接続セットアップのオーバーヘッドは無視できるようになることができます。
Although HTTP appears at first glance to be one of the few "mature" Internet protocols that can provide good security, there are many applications for which neither HTTP's digest authentication nor TLS are sufficient by themselves.
HTTPは、優れたセキュリティを提供することができますいくつかの「成熟した」インターネットプロトコルの一つであることが一目で表示されますが、どちらもHTTPの認証やTLSをダイジェストいる多くのアプリケーションがあり、それ自体で十分です。
Digest authentication requires a secret (e.g., a password) to be shared between client and server. This further requires that each client know the secret to be used with each server, but it does not provide any means of securely transmitting such secrets between the parties. Shared secrets can work fine for small groups where everyone is physically co-located; they don't work as well for large or dispersed communities of users. Further, if the server is compromised a large number of secrets may be exposed, which is especially dangerous if the same secret (or password) is used for several applications. (Similar concerns exist with TLS based clients or servers - if a private key is compromised then the attacker can impersonate the party whose key it has.)
ダイジェスト認証は、クライアントとサーバーの間で共有される秘密（例えば、パスワード）が必要です。これはさらに、各クライアントは、各サーバーで使用される秘密を知っている必要がありますが、それはしっかりと、当事者間のこのような秘密を送信する手段を提供していません。共有秘密は、誰もが物理的に同じ場所に配置された小グループのために正常に動作することができます。彼らは、ユーザーの大規模または分散コミュニティのために同様に動作しません。サーバーが危険にさらされている場合さらに、秘密の多数は同じ秘密（またはパスワード）は、いくつかの用途のために使用されている場合は特に危険である、露出することができます。 （同様の懸念がTLSベースのクライアントまたはサーバに存在する - 秘密鍵が侵害された場合、攻撃者は、そのキーそれが持っているパーティーを偽装することができます。）
TLS and its predecessor SSL were originally designed to authenticate web servers to clients, so that a user could be assured (for example) that his credit card number was not being sent to an imposter. However, many applications need to authenticate clients to servers, or to provide mutual authentication of client and server. TLS does have a capability to provide authentication in each direction, but such authentication may or may not be suitable for a particular application.
ユーザーが自分のクレジットカード番号を詐称者に送信されなかったこと（例えば）保証することができるように、TLSおよびその前身SSLはもともと、クライアントにWebサーバを認証するために設計されていました。しかし、多くのアプリケーションは、サーバにクライアントを認証するために、またはクライアントとサーバーの相互認証を提供する必要があります。 TLSは、各方向での認証を提供する能力を持っているが、そのような認証は、または特定の用途に適していてもいなくてもよいです。
Web browsers which support TLS or SSL are typically shipped with the public keys of several certificate authorities (CAs) "wired in" so that they can verify the identity of any server whose public key was signed by one of those CAs. For this to work well, every secure web server's public key has to be signed by one of the CAs whose keys are wired into popular browsers. This deployment model works when there are a (relatively) small number of servers whose identities can be verified, and their public keys signed, by the small number of CAs whose keys are included in a small number of different browsers.
TLSまたはSSLをサポートするWebブラウザは、一般的に、彼らは、公開鍵これらのCAのいずれかによって署名された任意のサーバの身元を確認できるように、いくつかの認証局（CA）の公開鍵は「で有線」に同梱されています。これがうまく機能するためには、すべてのセキュリティで保護されたWebサーバーの公開鍵は、鍵の一般的なブラウザに配線されているCAのいずれかによって署名されなければなりません。身元を検証できるサーバーの（比較的）小さな数がある場合に、この展開モデルでは動作し、その公開鍵は、キーが異なるブラウザの少数に含まれているCAの数が少ないことで、署名しました。
This scheme does not work as well to authenticate millions of potential clients to servers. It would take a much larger number of CAs to do the job, each of which would need to be widely trusted by servers. Those CAs would also have a more difficult time verifying the identities of (large numbers of) ordinary users than they do in verifying the identities of (a smaller number of) commercial and other enterprises that need to run secure web servers.
この方式では、サーバへの潜在的な顧客の何百万人を認証するために、同様に動作しません。それは、仕事をするためにCAのはるかに大きい数を取ることになるのそれぞれが広く、サーバから信頼される必要があるであろう。彼らは安全なWebサーバを実行する必要があり、商業及びその他の企業（の数が少ない）の身元を確認するに行うよりも、これらのCAはまた、一般ユーザ（多数）の身元を確認することがより困難な時期を持っているでしょう。
Also, in a situation where there were a large number of clients authenticating with TLS, it seems unlikely that there would be a set of CAs whose keys were trusted by every server. A client that potentially needed to authenticate to multiple servers would therefore need to be configured as to which key to use with which server when attempting to establish a secure connection to the server.
また、TLSで認証する多数のクライアントがあったような状況では、キーのすべてのサーバーによって信頼されたCAのセットがあるだろうとは考えにくいです。潜在的に複数のサーバーに認証するために必要なクライアントは、したがって、どのサーバへの安全な接続を確立しようとしたとき、どのサーバで使用するキーととして設定する必要があります。
For the reasons stated above, client authentication is rarely used with TLS. A common technique is to use TLS to authenticate the server to the client and to establish a private channel, and for the client to authenticate to the server using some other means - for example, a username and password using HTTP basic or digest authentication.
上記の理由により、クライアント認証はめったにTLSで使用されていません。基本またはダイジェスト認証をHTTPを使用して例えば、ユーザ名とパスワード - 一般的な手法は、クライアントにサーバーを認証するために、民間チャネルを確立するために、クライアントのためにいくつかの他の手段を使用して、サーバーの認証にTLSを使用することです。
For any application that requires privacy, the 40-bit ciphersuites provided by some SSL implementations (to conform to outdated US export regulations or to regulations on the use or export of cryptography in other countries) are unsuitable. Even 56-bit DES encryption, which is required of conforming TLS implementations, has been broken in a matter of days with a modest investment in resources. So if TLS is chosen it may be necessary to discourage use of small key lengths, or of weak ciphersuites, in order to provide adequate privacy assurance. If TLS is used to provide privacy for passwords sent by clients then it is especially important to support longer keys.
プライバシーを必要とするアプリケーションのために、いくつかのSSLの実装が提供する40ビットの暗号スイートは、（旧式の米国の輸出規制またはその他の国における暗号の使用や輸出規制に準拠するように）適していません。 TLSの実装を適合させる必要されていても、56ビットDES暗号化は、資源の適度な投資で数日のうちに破られています。 TLSが選択された場合には、適切なプライバシーの保証を提供するために、または弱い暗号スイートの小さな鍵長の使用を阻止する必要があるかもしれません。 TLSは、クライアントによって送信されたパスワードのプライバシーを提供するために使用されている場合、長いキーをサポートすることが特に重要です。
None of the above should be taken to mean that either digest authentication or TLS are generally inferior to other authentication systems, or that they are unsuitable for use in other applications besides HTTP. Many of the limitations of TLS and digest authentication also apply to other authentication and privacy systems. The point here is that neither TLS nor digest authentication is a "magic pixie dust" solution to authentication or privacy. In every case, an application's designers must carefully determine the application's users' requirements for authentication and privacy before choosing an authentication or privacy mechanism.
上記のいずれもダイジェスト認証をかTLSのどちらかということを意味すると解釈すべきではない、彼らはHTTP以外の用途での使用には適していないことが一般的に他の認証システムに劣っている、または。 TLSの多くの制限やダイジェスト認証は、他の認証とプライバシーのシステムに適用されます。ここでのポイントは、TLSもどちらもダイジェスト認証ということである認証やプライバシーへの「魔法の妖精の塵」ソリューションです。すべてのケースでは、アプリケーションの設計者は慎重に、認証やプライバシーメカニズムを選択する前に、認証とプライバシーのために、アプリケーションのユーザーの要件を決定する必要があります。
Note also that TLS can be used with other TCP-based protocols, and there are SASL [7] mechanisms similar to HTTP's digest authentication. So it is not necessary to use HTTP in order to benefit from either TLS or digest-like authentication. However, HTTP APIs may already support TLS and/or digest.
注またTLSが他のTCPベースのプロトコルで使用することができ、およびダイジェスト認証のをHTTPと同様SASL [7]のメカニズムが存在すること。だから、TLSやダイジェストのような認証のいずれかから利益を得るためにHTTPを使用する必要はありません。しかし、HTTP APIはすでにTLSをサポートおよび/または消化します。
One oft-cited reason for the use of HTTP is its ability to pass through proxies, firewalls, or network address translators (NATs). One unfortunate consequence of firewalls and NATs is that they make it harder to deploy new Internet applications, by requiring explicit permission (or even a software upgrade of the firewall or NAT) to accommodate each new protocol. The existence of firewalls and NATs creates a strong incentive for protocol designers to layer new applications on top of existing protocols, including HTTP.
HTTPを使用するための1つしばしば引用理由は、プロキシ、ファイアウォールまたはネットワークアドレス変換（NAT）を通過する能力です。ファイアウォールやNATの一つの不幸な結果は、彼らはそれが難しく、それぞれの新しいプロトコルに対応するために、明示的な許可（またはファイアウォールやNATのも、ソフトウェアのアップグレード）を必要とすることにより、新たなインターネットアプリケーションをデプロイするために作るということです。ファイアウォールやNATのの存在は、プロトコル設計者は、HTTPなどの既存のプロトコルの上に新しいアプリケーションを、層へのための強力なインセンティブを作成します。
However, if a site's firewall prevents the use of unknown protocols, this is presumably a conscious policy decision on the part of the firewall administrator. While it is arguable that such policies are of limited value in enhancing security, this is beside the point - well-known port numbers are quite useful for a variety of purposes, and the overloading of port numbers erodes this utility. Attempting to circumvent a site's security policy is not an acceptable justification for doing so.
サイトのファイアウォールが、未知のプロトコルの使用を妨げる場合は、これはおそらくファイアウォール管理者の一部に意識的な政策決定です。よく知られているポート番号は、様々な目的のために非常に有用であり、ポート番号のオーバーロードは、このユーティリティを侵食する - それは、このような政策は、セキュリティを強化するには限られた価値であることが議論の余地があるが、これはポイントの横にあります。サイトのセキュリティポリシーを回避しようとすると、そのようにするための許容可能な正当化ではありません。
It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
簡単に既存のファイアウォールは、新しいプロトコルと互換性ができるようにすること、「ファイアウォールに優しい」プロトコルのためのガイドラインを確立することは有用であろう。
o When considering payload size and traffic patterns, is HTTP an appropriate transport for the anticipated use of this protocol? (In other words: will the payload size be worth the overhead associated with TCP and HTTP? Or will the application be able to make use of HTTP persistent connections to amortize the cost of that overhead over several requests?)
ペイロードサイズとトラフィックパターンを考慮すると、O、HTTPは、このプロトコルの予想される使用のための適切な輸送でありますか？ （言い換えれば、ペイロードサイズは、TCPとHTTPに関連するオーバーヘッド価値があるだろうか、アプリケーションはいくつかの要求を超えるオーバーヘッドのコストを償却するためにHTTP持続的接続を利用することができるのだろうか？？）
o Is this new protocol usable by existing web browsers without modification?
Oこの新しいプロトコルは変更せずにWebブラウザを既存で使用可能ですか？
(For example: Is the request transmitted as if it were a filled-in HTML form? Is the response which is returned viewable from a web browser, say as HTML?)
（例：？リクエストが送信され、それが満たされ-にしているかのようにHTMLフォームWebブラウザから閲覧可能返される応答である、HTMLと言うの？）
o Are the existing HTTP security mechanisms appropriate for the new application?
O既存のHTTPのセキュリティメカニズムは、新たなアプリケーションに適していますか？
o Are HTTP status codes and the HTTP status code paradigm suitable for this application? (see section 8)
O HTTPステータスコードとHTTPステータスコードのパラダイムは、このアプリケーションに適していますか？ （セクション8を参照）
o Does the server for this application need to support HTTP anyway?
oがこのアプリケーションのサーバーはとにかくHTTPをサポートする必要がありますか？
IANA has reserved TCP port number 80 for use by HTTP. It would not be appropriate for a substantially new service, even one which uses HTTP as a substrate, to usurp port 80 from its traditional use. A new use of HTTP might be considered a "substantially new service", thus requiring a new port, if any of the following are true:
IANAは、HTTPで使用するためにTCPポート番号80を予約しました。それも、その伝統的な使用からポート80を奪うために、基質としてHTTPを使用していますつの実質的に新しいサービスのために適切ではありません。次のいずれかに該当する場合、HTTPの新しい使用は、このように新しいポートを必要とする、「実質的に新サービス」と見なされる可能性があります。
o The "new service" and traditional HTTP service are likely to reference different sets of data, even when they both operate on the same host.
「新サービス」と、伝統的なHTTPサービスoを、それらの両方が同じホスト上で動作した場合でも、データの異なるセットを参照する可能性があります。
o There is a good reason for the "new service" to be implemented by a separate server process, or separate code, than traditional HTTP service on the same host, at least on some platforms.
O別々のサーバプロセスによって実装される「新サービス」、または別々のコードのために、同じホスト上の伝統的なHTTPサービスよりも、少なくともいくつかのプラットフォーム上の正当な理由があります。
o There is a good reason to want to easily distinguish the traffic of the "new service" from traditional HTTP, e.g., for the purposes of firewall access control or traffic analysis.
O簡単にファイアウォールのアクセス制御やトラフィック分析のために、例えば、伝統的なHTTPから「新サービス」のトラフィックを区別したいのに良い理由があります。
o If none of the above are true, it is arguable that the new use of HTTP is an "extension" to traditional HTTP, rather than a "new service". Extensions to HTTP which share data with traditional HTTP services should probably define new HTTP methods to describe those extensions, rather than using separate ports. If separate ports are used, there is no way for a client to know whether they are separate services or different ways of accessing the same underlying service.
上記のいずれにも該当しない場合は、O、HTTPの新しい使用は、伝統的なHTTPに「拡張」ではなく、「新サービス」であることを議論の余地があります。伝統的なHTTPサービスとデータを共有するHTTPの拡張は、おそらく、むしろ別のポートを使用するよりも、これらの拡張子を記述するための新しいHTTPメソッドを定義する必要があります。別のポートが使用されている場合、クライアントは、彼らが別のサービス、または同じ基本サービスにアクセスするためのさまざまな方法であるかどうかを知る方法はありません。
A number of different URL schemes are in widespread use and many more are in the process of being standardized. In practice, the URL scheme not only serves as a "tag" to govern the interpretation of the remaining portion of the URL, it also provides coarse identification of the kind of resource or service which is being accessed. For example, web browsers typically provide a different response when a user mouse-clicks on an "http" URL, than when the user clicks on a "mailto" URL.
別のURLスキームの数は、広く使用されて、より多くのは、標準化されつつあります。実際には、URLスキームは、「タグ」は、URLの残りの部分の解釈を支配するように機能するだけでなく、それはまた、アクセスされているリソースまたはサービスの種類の粗い識別を提供します。たとえば、Webブラウザは、一般的に異なる応答を提供する場合は「http」URLにユーザーマウスクリック、ユーザーが「mailtoの」URLをクリックしたときよりも。
Some criteria that might be used in making this determination are:
この決意を作製する際に使用される可能性がありますいくつかの基準は、次のとおりです。
o Whether this URL scheme is likely to become widely used, versus used only in limited communities or by private agreement.
このURLスキームは広く使われている、対のみ限定された地域社会や民間の合意によって使用になりそうであるかどうか、O。
o Whether a new "default port" is needed. If reuse of port 80 is not appropriate (see above), a new "default port" is needed. A new default port in turn requires that a new URL scheme be registered if that URL scheme is expected to be widely used. Explicit port numbers in URLs are regarded as an "escape hatch", not something for use in ordinary circumstances.
新しい「デフォルトのポートは、」必要とされているかどうか、O。ポート80の再利用（上記参照）適切でない場合は、新しい「デフォルトのポートは」必要とされています。今度の新しいデフォルトのポートは、そのURLスキームが広く使用されることが予想される場合は、新しいURLスキームが登録されている必要があります。 URLでの明示的なポート番号は、「エスケープハッチ」、通常の状況下での使用のためではないものとして考えられています。
o Whether use of the new service is likely to require a substantially different setup or protocol interaction with the server, than ordinary HTTP service. This could include the need to request a different type of service from the network, or to reserve bandwidth, or to present different TLS authentication credentials to the server, or different kind of server provisioning, or any number of other needs.
新しいサービスの利用は、通常のHTTPサービスよりも、サーバと実質的に異なる設定やプロトコルの相互作用を必要とする可能性があるかどうか、O。これは、ネットワークからのサービスの異なるタイプを要求する、または帯域幅を確保するために、またはサーバー、またはサーバープロビジョニングの異なる種類、または他のニーズの任意の数の異なるTLS認証の資格情報を提示する必要性を含めることができます。
o Whether user interfaces (such as web browsers) are likely to be able to exploit the difference in the URL prefix to produce a significant improvement in usability.
（例えば、ウェブブラウザのような）ユーザインタフェースがユーザビリティの大幅な改善を生成するURLプレフィックスの差を利用することができる可能性があるかどうか、O。
According to the rules in [8] the "http:" URI is part of the "IETF Tree" for URL scheme names, and IETF is the maintainer of the "IETF Tree". Since IESG is the decision-making body for IETF, IESG has the authority to determine whether a resource accessed by a protocol that is layered on top of HTTP, should use http: or some other URL prefix.
[8]の規則によると、「HTTP：」URIはURLのスキーム名の「IETF木」の一部であり、IETFは、「IETFツリー」のメンテナです。またはいくつかの他のURL接頭辞：IESGは、IETFのための意思決定機関であるので、IESGは、HTTPの上に積層されているプロトコルでアクセスされたリソースは、HTTPを使用する必要があるかどうかを決定する権限を有します。
Note that the convention of appending an "s" to the URL scheme to mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and of limited value. For most applications, a single "use TLS or SSL" bit is not sufficient to adequately convey the information that a client needs to authenticate itself to a server, even if it has the proper credentials. For instance, in order to ensure that adequate security is provided with TLS an application may need to be configured with a list of acceptable ciphersuites, or with the client certificate to be used to authenticate to a particular server. When it is necessary to specify authentication or other connection setup information in a URL these should be communicated in URL parameters, rather than in the URL prefix.
（「のhttp：」「ます。https：」対中など）は非標準と制限された値である「TLSまたはSSLを使用する」を意味するURLスキームに「s」を追加するの慣例ことに注意してください。ほとんどのアプリケーションでは、シングル「TLSまたはSSLを使用する」のビットが適切にクライアントは、それが適切な資格情報を持っている場合でも、サーバーに対して自身を認証するために必要な情報を伝えるには十分ではありません。例えば、十分なセキュリティをアプリケーションが許容される暗号スイートのリストを、または特定のサーバへの認証に使用されるクライアント証明書を使用して構成する必要があるかもしれないTLSが設けられていることを保証するためです。それはURLに認証または他の接続設定情報を指定する必要がある場合にはこれらのではなく、URL接頭辞よりも、URLパラメータで伝達されなければなりません。
Since HTTP uses the MIME media type system [9] to label its payload, many applications which layer on HTTP will need to define, or select, MIME media types for use by that application. Especially when using a multipart structure, the choice of media types requires careful consideration. In particular:
HTTPは、MIMEメディアタイプのシステムを使用しているので[10]、そのペイロードそのアプリケーションで使用するために、MIMEメディアタイプを定義する、または選択する必要がありますHTTP上の層、多くのアプリケーションを標識します。マルチパート構造を使用する場合には特に、メディアタイプの選択は慎重に検討する必要があります。特に：
o Should some existing framework be used, such as text/directory [10], or XML [11,12], or should the new content-types be built from scratch? Just as with HTTP, it's useful if code can be reused, but protocol designers should not be over-eager to incorporate a general but complex framework into a new protocol. Experience with ASN.1, for example, suggests that the advantage of using a general framework may not be worth the cost.
oは[10]、テキスト/ディレクトリなど、いくつかの既存のフレームワークを使用しなければならない、またはXML [11,12]、または新しいコンテンツ・タイプは、ゼロから構築する必要がありますか？ただ、HTTPと同様に、コードを再利用することができればそれは便利だが、プロトコル設計者は、新しいプロトコルへの一般的なものの、複雑なフレームワークを組み込むことがオーバー熱心ではありません。 ASN.1の経験は、例えば、一般的なフレームワークを使用することの利点は、コストに見合わないかもしれないことを示唆しています。
o Should MIME multipart or message types be allowed? This can be an advantage if it is desirable to incorporate (for example) the multipart/alternative construct or the MIME security framework. On the other hand, these constructs were designed specifically for use in store-and-forward electronic mail systems, and other mechanisms may be more appropriate for the application being considered.
oはMIMEマルチパートまたはメッセージタイプが許可されるべきか？ （例えば）マルチパート/代替構築物またはMIMEのセキュリティフレームワークを組み込むことが望ましい場合、これは利点であり得ます。一方、これらの構築物は、具体的には、ストア・アンド・フォワードの電子メールシステムで使用するために設計された、および他のメカニズムは、アプリケーションが考慮されているため、より適切であるかもしれません。
The point here is that a decision to use MIME content-type names to describe protocol payloads (which is generally desirable if the same payloads may appear in other applications) does not imply that the application must accept arbitrary MIME content-types, including MIME multipart or security mechanisms. Nor does it imply that the application must use MIME syntax or that it must recognize or even tolerate existing MIME header fields.
ここでのポイントは、（同じペイロードは他のアプリケーションに表示される可能性がある場合、一般的に所望される）プロトコルペイロードを記述するためにMIMEコンテンツタイプ名を使用するという決定は、アプリケーションがMIMEマルチパートを含む任意のMIMEコンテンツタイプを受け入れなければならないことを意味しないということですまたはセキュリティ・メカニズム。また、それは、アプリケーションがMIMEの構文を使用するか、それが認識し、あるいは既存のMIMEヘッダフィールドを許容しなければならないことをしなければならないことを意味するものではありません。
o If the same payload is likely to be sent over electronic mail, the
differences between HTTP encoding of the payload and email
encoding of the payload should be minimized. Ideally, there
should be no differences in the "canonical form" used in the two
environments. Text/* media types can be problematic in this
regard because MIME email requires CRLF for line endings of text/*
body parts, where HTTP traditionally uses LF only.
o A MIME content-type label describes the nature of the object being labeled. It does not describe, and should not be used to describe, the semantics which should be applied when the object is received. For instance, the transmission of an object with a particular content-type using HTTP POST, should not be taken as a request for some operation based solely on the type. The request should be separate from the content-type label and it should be explicit.
O MIMEコンテンツタイプのラベルは、ラベル付けされているオブジェクトの性質を記述します。これは、説明されていない、そして、オブジェクトが受信されたときに適用されるべきセマンティクスを記述するために使用すべきではありません。例えば、HTTP POSTを使用して、特定のコンテンツタイプを持つオブジェクトの送信は、単にタイプに基づいて、いくつかの操作のための要求として解釈されるべきではありません。リクエストは、コンテンツタイプのラベルから分離する必要があり、それが明示的でなければなりません。
When it is necessary for a protocol layered on HTTP to allow different operations on the same type of object, this can be communicated in a number of different ways: HTTP methods, HTTP request-URI, HTTP request headers, the MIME Content-Disposition header field, or as part of the payload.
それは、オブジェクトの同じ種類の異なる操作を可能にするために、HTTP上に積層プロトコルのために必要である場合、これは多くの異なる方法で通信することができる：HTTPメソッド、HTTPリクエストURI、HTTPリクエスト・ヘッダー、MIMEのContent-Dispositionヘッダーフィールド、またはペイロードの一部として。
It has been suggested that a new service layered on top of HTTP should define one or more new HTTP methods, rather than allocating a new port. The use of new methods may be appropriate, but is not sufficient in all cases. The definition of one or more new methods for use in a new protocol, does not by itself alleviate the need for use of a new port, or a new URL type.
HTTPの上に重ね、新たなサービスではなく、新しいポートを割り当てるよりも、1つ以上の新しいHTTPメソッドを定義すべきであることが示唆されています。新しいメソッドを使用することは適切ではなく、すべてのケースでは十分ではないことがあります。新しいプロトコルで使用するための1つ以上の新しいメソッドの定義は、それ自体で新しいポート、または新しいURLタイプを使用する必要性を軽減していません。
As mentioned earlier, one of the primary reasons for the use of HTTP as a substrate for new protocols, is to allow reuse of existing HTTP client, server, or proxy code. However, HTTP was not designed for such layering. Existing HTTP client and code may have "http" assumptions wired into them. For instance, client libraries and proxies may expect "http:" URLs, and clients and servers may send (and expect) "HTTP/1.1", in requests and responses, as opposed to the name of the layered protocol and its version number.
先に述べたように、新しいプロトコル用の基板としてHTTPを使用するための主な理由の一つは、既存のHTTPクライアント、サーバー、またはプロキシコードの再利用を可能にすることです。しかし、HTTPは、そのようなレイヤーのために設計されていませんでした。 HTTPクライアントとコードを既存のそれらに有線「のhttp」の前提条件を有することができます。 URL、およびクライアントと階層型プロトコルの名前とそのバージョン番号とは対照的に、サーバは、要求と応答では、「HTTP / 1.1」を送信（と期待する）ことがあります。たとえば、クライアントライブラリとプロキシは、「HTTP」を期待することがあります。
Existing client libraries may not understand new URL types. In order to get a new HTTP-layered application client to work with an existing client library, it may be necessary for the application to convert its URLs to an "http equivalent" form. For instance, if service "xyz" is layered on top of HTTP using port ###, the xyz client may need, when invoking an HTTP client library, to translate its URLs from "xyz://host/something" format to "http://host:###/something" for the purpose of calling that library. This should be done ONLY when calling the HTTP client library - such URLs should not be used in other parts of the protocol, nor should they be exposed to users.
既存のクライアントライブラリは、新しいURLの種類を理解していないことがあります。アプリケーションは、「HTTP相当」フォームにそのURLを変換するために、既存のクライアントライブラリで動作する新しいHTTP層アプリケーションクライアントを取得するためには、それが必要な場合があります。 「：//ホスト/何かをXYZ」形式を "サービス「xyzは」HTTPのトップ###ポートを使用して上に積層されている場合たとえば、XYZクライアントは、HTTPクライアントライブラリを呼び出すときに、からそのURLを変換する必要があるかもしれませんhttp：//ホスト：### /何か」というライブラリを呼び出すの目的のために。このようなURLは、プロトコルの他の部分で使用すべきではない、また彼らは、ユーザーに公開されなければならない - HTTPクライアントライブラリを呼び出すときにのみ行われるべきです。
Note that when a client is sending requests directly to an origin server, the URL prefix ("http:") is not normally sent. So translating xyz: URLs to http: URLs when calling the client library should not actually cause http: URLs to be sent over the wire. But when the same client is sending requests to a proxy server, the client will normally send the entire URL (including the http: prefix) in those requests. The proxy will remove the http: prefix when the request is communicated to the origin server.
正常に送信されていません：クライアントがオリジンサーバに直接要求を送信している際に、URL接頭辞（「HTTP」）があることに注意してください。だから、XYZを変換します。httpのURL：URLのワイヤ上で送信されるように：URLのクライアントライブラリを呼び出すときに、実際にHTTPが発生することはありません。これらの要求に：同じクライアントがプロキシサーバーにリクエストを送信しているときしかし、クライアントは通常、（接頭辞のhttpを含む）全体のURLを送信します。要求がオリジンサーバに伝達されたときに接頭辞：プロキシは、httpを削除します。
Existing HTTP client libraries and servers will transmit "HTTP/1.1" (or a different version) in requests and responses. To facilitate reuse of such libraries and servers by a new protocol, such a protocol may therefore need to transmit and accept "HTTP/1.1" rather than its own protocol name and version number. Designers of protocols which are layered on top of HTTP should explicitly choose whether or not to accept "HTTP/1.1" in protocol exchanges.
既存のHTTPクライアントライブラリとサーバーは、要求と応答では、「HTTP / 1.1」（または異なるバージョン）を送信します。新しいプロトコルにより、このようなライブラリやサーバの再利用を容易にするために、そのようなプロトコルは、そのためではなく、独自のプロトコル名とバージョン番号より「HTTP / 1.1」を送信し、受諾する必要があるかもしれません。 HTTPの上に積層されたプロトコルの設計者は、明示的に「HTTP / 1.1」のプロトコル交換を受け入れるかどうかを選択する必要があります。
For certain applications it may be necessary to require or limit use of certain HTTP features, for example, to defeat caching of responses by proxies. Each protocol layered on HTTP must therefore specify the specific way that HTTP will be used, and in particular, how the client and server should interact with HTTP proxies.
特定の用途のためには、プロキシによって応答のキャッシングを無効にする、例えば、必要または特定のHTTP機能の使用を制限する必要があるかもしれません。 HTTP上に積層された各プロトコルは、したがって、HTTPが使用される特定の方法を指定する必要があり、特に、クライアントとサーバは、HTTPプロキシと対話する必要がありますか。
HTTP's three-digit status codes were designed for use with traditional HTTP applications (e.g., document retrieval, forms-based queries), and are unlikely to be suitable to communicate the specifics of errors encountered in dissimilar applications. Even when it seems like there is a close match between HTTP status codes and the codes needed by the application, experience with reuse of other protocols indicates that subtle variations in usage are likely; and that this is likely to degrade interoperability of both the original protocol (in this case HTTP) and any layered applications.
HTTPの3桁のステータスコードは、従来のHTTPアプリケーション（例えば、文書検索、フォームベースのクエリ）で使用するために設計されており、異なるアプリケーションで発生したエラーの内容を通信するために適切であることがにくいました。 HTTPステータスコードとアプリケーションが必要とするコードとの間には密接な一致があるようにそれはそう場合でも、他のプロトコルの再利用での経験は、使用中に微妙な変化がありそうであることを示しています。これが（この場合はHTTPで）元のプロトコルと任意の層状アプリケーションの両方の相互運用性を低下させる可能性があること。
HTTP status codes therefore should not be used to indicate subtle errors of layered applications. At most, the "generic" HTTP codes 200 (for complete success) and 500 (for complete failure) should be used to indicate errors resulting from the content of the request message-body. Under certain circumstances, additional detail about the nature of the error can then be included in the response message-body. Other status codes than 200 or 500 should only appear if the error was detected by the HTTP server or by an intermediary.
HTTPステータスコードは、従って、層状アプリケーションの微妙なエラーを示すために使用されるべきではありません。せいぜい、（完全な失敗のため）と500（完全な成功のための）「一般的な」HTTPコード200は、要求メッセージボディの内容から生じるエラーを示すために使用されなければなりません。特定の状況下では、エラーの性質に関する追加の詳細は、次に、応答メッセージボディに含めることができます。エラーがHTTPサーバーまたは仲介によって検出された場合は200または500以外のステータスコードは、のみ表示されます。
A layered application should not define new HTTP status codes. The set of available status codes is small, conflicts in code assignment between different layered applications are likely, and they may be needed by future versions of, or extensions to, mainstream HTTP.
多層アプリケーションは、新しいHTTPステータスコードを定義するべきではありません。利用可能なステータスコードのセットは、異なる層状アプリケーション間のコード割り当てで競合がありそうであり、それらは将来のバージョン、またはに対する拡張、主流HTTPによって必要とされ得る、小さいです。
Use of HTTP's error codes is problematic when the layered application does not share same notion of success or failure as HTTP. The problem exists when the client does not connect directly to the origin server, but via one or more HTTP caches or proxies. (Since the ability of HTTP to communicate through intermediaries is often the primary motivation for reusing HTTP, the ability of the application to operate in the presence of such intermediaries is considered very important.) Such caches and proxies will interpret HTTP's error codes and may take additional action based on those codes. For instance, on receipt of a 200 error code from an origin server (and under other appropriate conditions) a proxy may cache the response and re-issue it in response to a similar request. Or a proxy may modify the result of a request which returns a 500 error code in order to add a "helpful" error message. Other response codes may produce other behaviors.
多層アプリケーションは、HTTPなどの成功または失敗の同じ概念を共有していない場合、HTTPのエラーコードの使用には問題があります。クライアントはオリジンサーバに直接接続するが、1つ以上のHTTPキャッシュやプロキシを経由しない場合に問題が存在します。 HTTPのエラーコードを解釈するようなキャッシュとプロキシ（仲介者を介して通信するHTTPの能力は、多くの場合、HTTPを再利用するための主な動機であるので、そのような媒体の存在下で動作するアプリケーションの能力は非常に重要であると考えられる）と取ることができますこれらのコードに基づく追加措置。例えば、オリジンサーバ200からエラーコードを受信すると（および他の適切な条件下で）プロキシは、同様の要求に対する応答と再発行してキャッシュすることができます。またはプロキシは、「人」のエラーメッセージを追加するために、500エラーコードを返し、要求の結果を修正することができます。その他の応答コードは、他の行動を生成することができます。
A few guidelines are therefore in order:
いくつかのガイドラインは、順番に、したがって、次のとおりです。
o A layered application should use appropriate HTTP error codes to report errors resulting from information in the HTTP request-line and header fields associated with the request. This request information is part of the HTTP protocol and errors which are associated with that information should therefore be reported using HTTP protocol mechanisms.
O層状アプリケーションは、要求に関連付けられたHTTPリクエストラインとヘッダフィールドの情報に起因するエラーを報告するために適切なHTTPエラーコードを使用しなければなりません。この要求情報は、HTTPプロトコルの一部であり、その情報に関連付けられているエラーは、従って、HTTPプロトコルメカニズムを使用して報告されるべきです。
o A layered application for which all errors resulting from the message-body can be classified as either "complete success" or "complete failure" may use 200 and 500 for those conditions, respectively. However, the specification for such an application must define the mechanism which ensures that its successful (200) responses are not cached by intermediaries, or demonstrate that such caching will do no harm; and it must be able to operate even if the message-body of an error (500) response is not transmitted back to the client intact.
Oメッセージボディから生じるすべてのエラー「は、完全な成功」または「完全な失敗」のいずれかに分類することができるため、層状アプリケーションは、それぞれ、これらの条件200及び500を使用することができます。しかし、このようなアプリケーションのための仕様は、その成功した（200）応答は仲介によってキャッシュされないことを保証メカニズムを定義する、またはそのようなキャッシングが危害を与えないということを証明しなければなりません。それが動作することができなければならない場合でも、エラーのメッセージボディは、（500）応答は、無傷のクライアントに送信されません。
o A layered application may return a 200 response code for both successfully processed requests and errors (or other exceptional conditions) resulting from the request message-body (but not from the request headers). Such an application must return its error code as part of the response message body, and the specification for that application protocol must define the mechanism by which the application ensures that its responses are not cached by intermediaries. In this case a response other than 200 should be used only to indicate errors with, or the status of, the HTTP protocol layer (including the request headers), or to indicate the inability of the HTTP server to communicate with the application server.
O層状アプリケーションは、要求メッセージ・ボディ（ただし、リクエストヘッダから）から得られた正常に処理要求及び誤差（または他の例外条件）の両方に対する200レスポンスコードを返すことができます。そのようなアプリケーションは、応答メッセージ本体の一部としてのエラーコードを返す必要があり、そのアプリケーションプロトコルの仕様は、アプリケーションがその応答を仲介することによってキャッシュされないことを保証するメカニズムを定義する必要があります。この場合には200以外の応答が有する誤差、又は状態、（要求ヘッダーを含む）HTTPプロトコル層を示すために、またはアプリケーション・サーバと通信するHTTPサーバのできないことを示すためにのみ使用されるべきです。
o A layered application which cannot operate in the presence of intermediaries or proxies that cache and/or alter error responses, should not use HTTP as a substrate.
Oエラー応答をキャッシュおよび/または変更仲介またはプロキシの存在下で動作することができない層状のアプリケーションは、基質としてHTTPを使用しないでください。
1. All protocols should provide adequate security. The security needs of a particular application will vary widely depending on the application and its anticipated use environment. Merely using HTTP and/or TLS as a substrate for a protocol does not automatically provide adequate security for all environments, nor does it relieve the protocol developers of the need to analyze security considerations for their particular application.
1.すべてのプロトコルは、十分なセキュリティを提供する必要があります。特定のアプリケーションのセキュリティニーズは、アプリケーションとその予想される使用環境によって大きく異なります。単にプロトコルのための基質としてHTTPおよび/またはTLSを使用すると、自動的にすべての環境に十分なセキュリティを提供しません。また、その特定のアプリケーションのためのセキュリティの考慮事項を分析する必要のプロトコルの開発を緩和ありません。
2. New protocols - including but not limited to those using HTTP - should not attempt to circumvent users' firewall policies, particularly by masquerading as existing protocols. "Substantially new services" should not reuse existing ports.
2.新しいプロトコル - HTTPを使用したものを含むがこれらに限定されないが - 特に既存のプロトコルになりすましにより、ユーザーのファイアウォールポリシーを回避しようとはなりません。 「実質的に新しいサービスは、」既存のポートを再利用してはなりません。
3. In general, new protocols or services should not reuse http: or other URL schemes.
または他のURLスキーム：一般的な、新しいプロトコルやサービス3. HTTPを再利用してはなりません。
4. Each new protocol specification that uses HTTP as a substrate should describe the specific way that HTTP is to be used by that protocol, including how the client and server interact with proxies.
基質としてHTTPを使用しています。4.それぞれの新しいプロトコル仕様は、クライアントとサーバがプロキシと対話する方法を含め、HTTPは、そのプロトコルで使用することを具体的な方法を記述しなければなりません。
5. New services should follow the guidelines in section 8 regarding use of HTTP status codes.
5.新しいサービスは、HTTPステータスコードの使用に関するセクション8のガイドラインに従ってください。
Much of this document is about security. Section 2.3 discusses whether HTTP security is adequate for the needs of a particular application, section 2.4 discusses interactions between new HTTP-based protocols and firewalls, section 3 discusses use of separate ports so that firewalls are not circumvented, and section 4 discusses the inadequacy of the "s" suffix of a URL prefix for specifying security levels.
このドキュメントの多くは、セキュリティに関するものです。ファイアウォールを回避しないようにセクションは、HTTPのセキュリティは、特定のアプリケーションのニーズに適しているかどうか2.3で説明、セクション2.4は、新しいHTTPベースのプロトコルおよびファイアウォール、別のポートのセクション3で説明の使用の間の相互作用について説明し、セクション4は不十分について説明しセキュリティレベルを指定するためのURL接頭辞の「s」の接尾辞。
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[1]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[2]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証"、 RFC 2617、1999年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[4]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[5]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[6] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[6] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[7] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[7]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[8] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[8] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年11月に。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[9]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[10] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[10]ハウズ、T.、スミス、M.とF.ドーソン、 "ディレクトリ情報のMIMEのContent-Type"、RFC 2425、1998年9月。
[11] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC-xml-19980210, February 1998. http://www.w3.org/TR/1998/REC-xml-19980210.
[11]ブレイ、T.、パオリ、J.及びC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）、" World Wide Web Consortium（W3C）の勧告REC-XML-19980210、1998年2月http://www.w3.org / TR / 1998 / REC-XML-19980210。
[12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[12]村田、M.、サンローラン、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 USA
テネシーコンピュータサイエンスのキース・ムーア大学学部1122ボランティアブルバード、スイート203ノックスビルTN、37996から3450 USA
EMail: moore@cs.utk.edu
メールアドレス：moore@cs.utk.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。