[要約] RFC 3205は、HTTPを基盤として使用するためのガイドラインを提供しています。その目的は、HTTPを効果的に利用するためのベストプラクティスを示し、インターネット上の通信の効率と信頼性を向上させることです。
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
基質としてのHTTPの使用について
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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.
最近、他のアプリケーションレベルのプロトコルの基質としてHyperText Transfer Protocol（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:
最近、他のアプリケーションレベルのプロトコルの基質としてハイパーテキスト転送プロトコル（HTTP）[1]を使用することに広範な関心がありました。この関心のために引用されたさまざまな理由が含まれています。
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,
o CGIスクリプトと同様の拡張メカニズムを使用したサーバーのプロトタイピングの容易さ、
o ability to use existing security mechanisms such as HTTP digest authentication [2] and SSL or TLS [3],
o HTTPダイジェスト認証[2]やSSLまたはTLS [3]などの既存のセキュリティメカニズムを使用する能力
o the ability of HTTP to traverse firewalls, and
o HTTPがファイアウォールを通過する能力、および
o cases where a server often needs to support HTTP anyway.
o とにかくサーバーがHTTPをサポートする必要がある場合がある場合。
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:
インターネットコミュニティには、プロトコルの再利用の長い伝統があり、FTP [5]およびSMTP [6]の基質としてのTelnet [4]の使用にまでさかのぼります。 ただし、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メソッド（取得、投稿など）を使用する必要がありますか、それとも新しい方法を定義する必要がありますか？
o Should the application use http: URLs or define its own prefix?
o アプリケーションは、http：urlsを使用する必要がありますか、それとも独自のプレフィックスを定義する必要がありますか？
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は「リモートプロシージャコール」パラダイムのトランスポートとして使用できますが、HTTPのプロトコルオーバーヘッドは、TCPの接続セットアップのオーバーヘッドとともに、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は一見、良いセキュリティを提供できる数少ない「成熟した」インターネットプロトコルの1つであるように見えますが、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）のパブリックキー（Wired in "」に出荷され、それらのCASの1つによって公開キーが署名されたサーバーのIDを確認できます。これがうまく機能するためには、すべての安全なWebサーバーの公開キーに、キーが人気のあるブラウザに配線されたCASの1つによって署名される必要があります。この展開モデルは、アイデンティティを検証できる（比較的）少数のサーバーがある場合に機能し、少数の異なるブラウザにキーが含まれているCASの少数の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.
このスキームは、何百万人もの潜在的なクライアントをサーバーに認証するためにも機能しません。仕事をするにははるかに多くのCASが必要です。それぞれがサーバーによって広く信頼される必要があります。また、これらのCAは、安全なWebサーバーを実行する必要がある（少数の）商業およびその他の企業のアイデンティティを確認するよりも、通常のユーザーのアイデンティティを確認するのにより困難な時間があります。
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でクライアント認証が使用されることはめったにありません。一般的な手法は、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ビットのデス暗号でさえ、リソースへの控えめな投資により、数日間にわたって壊れています。したがって、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の不幸な結果の1つは、新しいプロトコルに対応するために明示的な許可（またはファイアウォールまたは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?)
（たとえば、リクエストはFilef-in HTMLフォームであるかのように送信されますか？返される応答は、Webブラウザーから表示可能です。
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を予約しています。HTTPを基板として使用しているサービスでさえ、従来の使用からポート80を奪うために、実質的に新しいサービスには適していません。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.
o 「新しいサービス」と従来のHTTPサービスは、両方が同じホストで動作している場合でも、さまざまなデータセットを参照する可能性があります。
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スキームは、URLの残りの部分の解釈を管理する「タグ」として機能するだけでなく、アクセスされているリソースまたはサービスの種類の粗い識別も提供します。たとえば、ユーザーが「MailTo」URLをクリックするときと同じように、ユーザーが「HTTP」URLにマウスクリックすると、Webブラウザーが異なる応答を提供します。
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.
o このURLスキームが広く使用される可能性が高いかどうかは、限られたコミュニティでのみ使用されるか、民間合意によって使用されるかどうかです。
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.
o 新しいサービスの使用には、通常のHTTPサービスとは、サーバーとの大幅に異なるセットアップまたはプロトコルの相互作用が必要になる可能性が高いかどうか。これには、ネットワークから異なるタイプのサービスを要求するか、帯域幅を予約するか、異なる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.
o ユーザーインターフェイス（Webブラウザーなど）がURLプレフィックスの違いを活用して、使いやすさの大幅な改善をもたらすことができるかどうか。
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：」はURLスキーム名の「IETFツリー」の一部であり、IETFは「IETFツリー」のメンテナーです。IESGはIETFの意思決定機関であるため、IESGにはHTTPの上に階層化されたプロトコルによってアクセスされるリソースがHTTP：または他のURLプレフィックスを使用するかどうかを判断する権限があります。
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.
「TLSまたはSSLを使用する」（「http： "vs" https： "のように）を意味する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 Media Type System [9]を使用してペイロードにラベルを付けるため、HTTPを重ねる多くのアプリケーションが、そのアプリケーションで使用するためにMIMEメディアタイプを定義または選択する必要があります。特にマルチパート構造を使用する場合、メディアタイプを選択するには慎重に検討する必要があります。特に：
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 同じペイロードが電子メールで送信される可能性が高い場合、ペイロードのHTTPエンコードとペイロードの電子メールエンコードの違いを最小限に抑える必要があります。理想的には、2つの環境で使用されている「標準形」に違いはないはずです。テキスト/*メディアタイプは、この点で問題が発生する可能性があります。これは、MIME電子メールにはテキスト/*ボディパーツのラインエンディングにCRLFが必要であるため、HTTPは従来LFのみを使用しています。
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コンテンツ分散ヘッダーフィールド、またはペイロードの一部として。
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を使用する主な理由の1つは、既存のHTTPクライアント、サーバー、またはプロキシコードの再利用を可能にすることです。ただし、HTTPはそのようなレイヤー用に設計されていません。既存のHTTPクライアントとコードには、それらに配線された「HTTP」仮定がある場合があります。たとえば、クライアントライブラリとプロキシは、層状プロトコルの名前とそのバージョン番号の名前とは対照的に、リクエストと応答で、「HTTP：」の「HTTP：」とクライアントとサーバーが「HTTP/1.1」をリクエストと応答で送信（および予想）することを期待する場合があります。
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」がポート###を使用してHTTPの上に階層化されている場合、XYZクライアントは、HTTPクライアントライブラリを呼び出すときに「XYZ：// host/何か」形式からurlを変換する必要がある場合があります。http：// host：###/何か」そのライブラリを呼び出す目的で。これは、HTTPクライアントライブラリを呼び出す場合にのみ行う必要があります。そのようなURLは、プロトコルの他の部分で使用されるべきではなく、ユーザーにさらされるべきではありません。
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.
クライアントがリクエストをOrigin Serverに直接送信している場合、URLプレフィックス（ "http："）は通常送信されないことに注意してください。したがって、xyz：urls：httpへの翻訳：クライアントライブラリを呼び出すときのURLは、実際にはHTTP：URLをワイヤー上に送信する必要はありません。ただし、同じクライアントがプロキシサーバーにリクエストを送信している場合、クライアントは通常、これらのリクエストでURL（HTTP：プレフィックスを含む）全体を送信します。プロキシは、リクエストがOrigin Serverに通知されたときに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ステータスコードを使用して、階層化されたアプリケーションの微妙なエラーを示すべきではありません。せいぜい、「一般的な」HTTPコード200（完全な成功のため）と500（完全な障害のため）を使用して、リクエストメッセージボディの内容に起因するエラーを示す必要があります。特定の状況では、エラーの性質に関する追加の詳細を応答メッセージボディに含めることができます。200または500を超える他のステータスコードは、HTTPサーバーまたは仲介者によってエラーが検出された場合にのみ表示されます。
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と同じ成功または失敗の概念を共有しない場合、問題があります。問題は、クライアントがOrigin Serverに直接接続しないであろうと、1つまたは複数のHTTPキャッシュまたはプロキシを介して存在します。（HTTPが仲介者を通じて通信する能力はしばしばHTTPを再利用する主な動機であるため、そのような仲介者の存在下でアプリケーションを動作させる能力は非常に重要であると考えられています。）そのようなキャッシュとプロキシはHTTPのエラーコードを解釈し、これらのコードに基づく追加のアクション。たとえば、Origin Serverから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.
3. 一般に、新しいプロトコルまたはサービスはHTTP：またはその他のURLスキームを再利用しないでください。
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.
4. 基質としてHTTPを使用する各プロトコル仕様は、クライアントとサーバーがプロキシと対話する方法など、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.
このドキュメントの多くはセキュリティに関するものです。セクション2.3では、HTTPセキュリティが特定のアプリケーションのニーズに適しているかどうかについて説明します。セクション2.4では、新しいHTTPベースのプロトコルとファイアウォールの間の相互作用について説明します。セキュリティレベルを指定するための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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[4] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[5] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[6] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[6] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[7] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[7] Myers、J。、「Simple Authentication and Security Layer（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. King、「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] Freed、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] Howes、T.、Smith、M。、およびF. Dawson、「ディレクトリ情報用のMIMEコンテンツタイプ」、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] Bray、T.、Paoli、J。and C. Sperberg-Mcqueen、「Extensible Markup Language（XML）」World Wide Web Consortiumの推奨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] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 USA
キースムーア大学テネシー大学コンピューターサイエンス部門1122ボランティアBlvd、スイート203ノックスビルTN、37996-3450 USA
EMail: moore@cs.utk.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。