Network Working Group K. Moore
Request for Comments: 2964 University of Tennessee
BCP: 44 N. Freed
Category: Best Current Practice Innosoft
October 2000
Use of HTTP State Management
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
IESG Note
IESG注意
The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered.
IESGは、このメカニズムは、任意のドットを含まないホスト名を処理するときに内部的に.localのトップレベルドメイン（TLD）を利用して、このメカニズムが期待通りに動作しない可能性があります、これまで実際の.local TLDなければならないことと指摘します登録します。
Abstract
抽象
The mechanisms described in "HTTP State Management Mechanism" (RFC-2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification.
「HTTP状態管理機構」（RFC-2965）、およびその前身（RFC-2109）で説明されたメカニズムは、多くの異なる目的のために使用することができます。彼らは重要なユーザーのプライバシーとセキュリティの意味を持っているのでしかし、プロトコルのいくつかの現在および潜在的な用途は、物議を醸すです。このメモは、（a）は、IETFによって推奨されていない、または（b）有害、および落胆することと考えられているハイパーテキスト転送プロトコル（HTTP）状態管理プロトコルの特定の用途を識別する。また、このメモはHTTP状態管理プロトコル仕様でカバーされていない追加のプライバシーの考慮事項について詳しく説明します。
The HTTP State Management mechanism is both useful and controversial. It is useful because numerous applications of HTTP benefit from the ability to save state between HTTP transactions, without encoding such state in URLs. It is controversial because the mechanism has been used to accomplish things for which it was not designed and is not well-suited. Some of these uses have attracted a great deal of public criticism because they threaten to violate the privacy of web users, specifically by leaking potentially sensitive information to third parties such as the Web sites a user has visited. There are also other uses of HTTP State Management which are inappropriate even though they do not threaten user privacy.
HTTP状態管理メカニズムは有用で物議両方です。これは、URLでこのような状態をエンコードせずに、HTTPトランザクション間で状態を保存する機能からのHTTP利益の多数のアプリケーションので便利です。メカニズムは、それが設計されていないと非常に適していないされたために何かを達成するために使用されてきたので、それは議論があります。彼らは具体的には、ユーザーが訪問したWebサイトとして第三者への機密情報の漏洩により、ウェブユーザーのプライバシーを侵害する脅かすため、これらの用途のいくつかは、国民の批判の多くを集めています。彼らは、ユーザーのプライバシーを脅かすていないにもかかわらず、不適切なHTTP状態管理の他の用途もあります。
This memo therefore identifies uses of the HTTP State Management protocol specified in RFC-2965 which are not recommended by the IETF, or which are believed to be harmful and are therefore discouraged.
このメモは、したがって、IETFによって推奨されていない、または有害であると考えられているので、落胆しているRFC-2965で指定されたHTTP状態管理プロトコルの使用を識別します。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
このドキュメントは時折大文字で現れる用語を使用しています。ときの用語は「MUST」、「SHOULD」「てはならない」、「べきではない」、と大文字表示される「MAY」、彼らは、この仕様の特定の要件を示すために使用されています。 「MUST」、「SHOULD」の用語の意味の議論、および[RFC-1123]に表示されます「MAY」。用語「MUST NOT」と、この使用法の論理的な拡張である「NOTべきです」。
The purpose of HTTP State Management is to allow an HTTP-based service to create stateful "sessions" which persist across multiple HTTP transactions. A single session may involve transactions with multiple server hosts. Multiple client hosts may also be involved in a single session when the session data for a particular user is shared between client hosts (e.g., via a networked file system). In other words, the "session" retains state between a "user" and a "service", not between particular hosts.
HTTP状態管理の目的は、HTTPベースのサービスは、複数のHTTPトランザクション間持続ステートフル「セッション」を作成できるようにすることです。単一のセッションでは、複数のサーバのホストとの取引を含むことができます。特定のユーザのセッションデータをクライアントホスト（例えば、ネットワークファイルシステムを介して）との間で共有されている場合、複数のクライアントホストは、単一のセッションに関与し得ます。換言すれば、「セッション」は、「ユーザ」と「サービス」との間ではなく、特定のホストとの間で状態を保持します。
It's important to realize that similar capabilities may also be achieved using the "bare" HTTP protocol, and/or dynamically-generated HTML, without the State Management extensions. For example, state information can be transmitted from the service to the user by embedding a session identifier in one or more URLs which appear in HTTP redirects, or dynamically generated HTML; and the state information may be returned from the user to the service when such URLs appear in a GET or POST request. HTML forms can also be used to pass state information from the service to the user and back, without the user being aware of this happening.
これは、同様の機能はまた、「裸」HTTPプロトコルを使用して達成することができることを認識することが重要だ、および/または状態管理の拡張機能なしで、HTMLを動的に生成します。例えば、状態情報は、HTTPリダイレクト、または動的に生成されたHTMLに表示される1つまたは複数のURLでセッション識別子を埋め込むことにより、ユーザへのサービスから送信することができます。このようなURLはGETまたはPOSTリクエストで表示された場合に、状態情報は、サービスへのユーザから返されてもよいです。 HTMLフォームは、ユーザーがこの出来事を意識することなく、ユーザーや背中へのサービスから状態情報を渡すために使用することができます。
However, the HTTP State Management facility does provide an increase in functionality over ordinary HTTP and HTML. In practice, this additional functionality includes:
しかし、HTTP状態管理機能は、通常のHTTPとHTMLを超える機能性の向上を提供します。実際には、この追加機能が含まれています：
(1) The ability to exchange URLs between users, of resources accessed during stateful sessions, without leaking the state information associated with those sessions. (e.g. "Here's the URL for the FooCorp web catalog entry for those sandals that you wanted.")
（1）それらのセッションに関連付けられた状態情報を漏洩することなく、ステートフル・セッション中にアクセスされるリソースの、ユーザ間URLを交換する能力。 （例えば、「ここにあなたが望んでいたそれらのサンダルのためのFooCorpウェブカタログエントリのURLです。」）
(2) The ability to maintain session state without "cache-busting". That is, separating the session state from the URL allows a web cache to maintain only a single copy of the named resource. If the state is maintained in session-specific URLs, the cache would likely have to maintain several identical copies of the resource.
（2）「キャッシュの無効化」することなく、セッション状態を維持する能力。これは、URLからセッション状態を分離することは、Webキャッシュは、名前付きリソースのコピーを1つだけ維持することを可能にしています。状態はセッション固有のURLで維持されている場合は、キャッシュはおそらくリソースのいくつかの同一のコピーを維持する必要があります。
(3) The ability to implement sessions with minimal server configuration and minimal protocol overhead, as compared to other techniques of maintaining session state.
（3）セッション状態を維持する他の技術と比較して、最小限のサーバ構成と最小プロトコルオーバーヘッドとのセッションを実施する能力。
(4) The ability to associate the user with session state whenever a user accesses the service, regardless of whether the user enters through a particular "home page" or "portal".
（4）ユーザにかかわらず、ユーザが特定の「ホーム・ページ」または「ポータル」を通って入るかどうか、サービスにアクセスするたびにセッション状態をユーザに関連付ける能力。
(5) The ability to save session information in stable storage, so that a "session" can be maintained across client invocations, system reboots, and client or system crashes.
（5）「セッション」がクライアント呼び出し、システムが再起動し、クライアントまたはシステムクラッシュにわたって維持することができるように、安定したストレージにセッション情報を保存する機能。
Use of HTTP State Management is appropriate whenever it is desirable to maintain state between a user and a service across multiple HTTP transactions, provided that:
ユーザーと複数のHTTPトランザクション間でサービス間の状態を維持することが望ましいときは常にHTTP状態管理の使用が適切である、それを提供します。
(1) the user is aware that session state is being maintained and consents to it,
（1）ユーザが、セッション状態がそれに維持され、同意されていることを認識しています
(2) the user has the ability to delete the state associated with such a session at any time,
（2）ユーザは、いつでも、セッションに関連付けられた状態を削除する能力を有し、
(3) the information obtained through the ability to track the user's usage of the service is not disclosed to other parties without the user's explicit consent, and
（3）サービスのユーザの使用状況を追跡する能力を介して得られた情報は、ユーザの明示的な同意なしに他の当事者に開示されていない、及び
(4) session information itself cannot contain sensitive information and cannot be used to obtain sensitive information that is not otherwise available to an eavesdropper.
（4）セッション情報自体は、機密情報を含むことができず、盗聴者にはそうでなければ利用できない機密情報を取得するために使用することができません。
This last point is important because cookies are usually sent in the clear and hence are readily available to eavesdroppers.
クッキーは、通常は平文で送信され、従って、盗聴者に容易に入手可能であるため、この最後の点は重要です。
An example of such a recommended use would be a "shopping cart", where the existence of the shopping cart is explicitly made known to the user, the user can explicitly "empty" his or her shopping cart (either by requesting that it be emptied or by purchasing those items) and thus cause the shared state to be discarded, and the service asserts that it will not disclose the user's shopping or browsing habits to third parties without the user's consent.
このよう推奨される使用の例は、ショッピングカートの存在が明示的にユーザーに知らされ、「ショッピングカート」、となり、ユーザーが明示的に「空」彼または彼女のショッピングカート（どちらか要求することにより、それが空にできることまたはしたがって、これらのアイテムを購入）とで共有状態を廃棄する、およびサービスは、ユーザーの同意なしに第三者にユーザーのショッピングやブラウジング習慣を開示することはありませんと主張している原因となります。
Note that the HTTP State Management protocol effectively allows a service provider to refuse to provide a service, or provide a reduced level of service, if the user or a user's client fails to honor a request to maintain session state. Absent legal prohibition to the contrary, the server MAY refuse to provide the service, or provide a reduced level of service, under these conditions. As a purely practical consideration, services designed to utilize HTTP State Management may be unable to function properly if the client does not provide it. Such servers SHOULD gracefully handle such conditions and explain to the user why the full level of service is not available.
ユーザーまたはユーザーのクライアントは、セッション状態を維持するための要求を称えるために失敗した場合、HTTP状態管理プロトコルが効果的に、サービスプロバイダがサービスを提供することを拒否、またはサービスレベルの低下を提供することを可能にすることに注意してください。逆に不在法的禁止、サーバがサービスを提供することを拒否、またはこれらの条件の下でのサービスレベルの低下を提供することができます。純粋に実用的な考慮事項として、HTTP状態管理を利用するように設計されたサービスは、クライアントがそれを提供しない場合は正常に機能できない場合があります。このようなサーバは、優雅に、このような条件を処理し、サービスの完全なレベルが使用できない理由をユーザーに説明する必要があります。
The following uses of HTTP State Management are deemed inappropriate and contrary to this specification:
HTTP状態管理の以下の使用は、本明細書に不適切と反するものとみなされます。
HTTP State Management MUST NOT be used to leak information about the user or the user's browsing habits to other parties besides the user or service, without the user's explicit consent. Such usage is prohibited even if the user's name or other externally-assigned identifier are not exposed to other parties, because the state management mechanism itself provides an identifier which can be used to compile information about the user.
HTTP状態管理は、ユーザーの明示的な同意なしに、ユーザーまたはサービス以外の他の当事者へのユーザーまたはユーザーのブラウジング習慣に関する情報を漏洩し使用してはいけません。状態管理機構自体は、ユーザに関する情報をコンパイルするために使用できる識別子を提供するため、このような使用は、ユーザの名前または他の外部から割り当てられた識別子が他の当事者に露出していない場合であっても禁止されます。
Because such practices encourage users to defeat HTTP State Management mechanisms, they tend to reduce the effectiveness of HTTP State Management, and are therefore considered detrimental to the operation of the web.
こうした慣行は、HTTP状態管理メカニズムを倒すために、ユーザーを奨励するので、彼らは、HTTP状態管理の有効性を減少させる傾向があるので、ウェブの動作に有害と考えられています。
It is generally inappropriate to use the HTTP State Management protocol as an authentication mechanism. HTTP State Management is not designed with such use in mind, and safeguards for protection of authentication credentials are lacking in both the protocol specification and in widely deployed HTTP clients and servers. Most HTTP sessions are not encrypted and "cookies" may therefore be exposed to passive eavesdroppers. Furthermore, HTTP clients and servers typically store "cookies" in cleartext with little or no protection against exposure. HTTP State Management therefore SHOULD
認証メカニズムとしてHTTP状態管理プロトコルを使用することが一般的に不適切です。 HTTP状態管理を念頭に置いて、そのような使用に設計されていない、と認証資格情報の保護のためのセーフガードは、両方のプロトコル仕様で、広く展開され、HTTPクライアントとサーバに欠けています。ほとんどのHTTPセッションは暗号化されていないと、「クッキー」ので、受動盗聴者に露出させることができます。さらに、HTTPクライアントとサーバは、一般的に露出に対してほとんど、あるいはまったく保護された平文で「クッキー」を格納します。したがって、HTTP状態管理SHOULD
NOT be used as an authentication mechanism to protect information from being exposed to unauthorized parties, even if the HTTP sessions are encrypted.
HTTPセッションが暗号化されている場合でも、権限のない者にさらされることからの情報を保護するために認証メカニズムとして使用することはできません。
The prohibition against using HTTP State Management for authentication includes both its use to protect information which is provided by the service, and its use to protect potentially sensitive information about the user which is entrusted to the service's care. For example, it would be inappropriate to expose a user's name, address, telephone number, or billing information to a client that merely presented a cookie which had been previously associated with the user.
認証にHTTP状態管理を使用を禁止する規定は、サービスによって提供される情報を保護するためのその使用、およびサービスのケアに委託されたユーザーに関する機密情報を保護するためのその使用の両方が含まれます。例えば、単に、予めユーザに関連付けられていたクッキーを提示し、クライアントにユーザーの名前、住所、電話番号、または課金情報を公開することは不適切だろう。
Similarly, HTTP State Management SHOULD NOT be used to authenticate user requests if unauthorized requests might have undesirable side-effects for the user, unless the user is aware of the potential for such side-effects and explicitly consents to such use. For example, a service which allowed a user to order merchandise with a single "click", based entirely on the user's stored "cookies", could inconvenience the user by requiring her to dispute charges to her credit card, and/or return the unwanted merchandise, in the event that the cookies were exposed to third parties.
同様に、HTTP状態管理には、ユーザは、このような副作用の可能性を認識しており、明示的な使用に納得していない限り、不正なリクエストは、ユーザにとって望ましくない副作用を持っている可能性がある場合、ユーザーの要求を認証するために使用しないでください。たとえば、ユーザーが単一で商品を注文することができ、サービスは、彼女のクレジットカードに料金を争うために彼女を要求することによって、ユーザを不便、および/または不要を返すことができ、完全にユーザの格納されている「クッキー」をもとに、「クリック」商品、イベントにクッキーを第三者に暴露されたこと。
Some uses of HTTP State Management to identify users may be relatively harmless, for example, if the only information which can be thus exposed belongs to the service, and the service will suffer little harm from the exposure of such information.
これを露光することができる唯一の情報は、サービスに属している場合、HTTP状態管理のいくつかの用途は、例えば、ユーザーが比較的無害であることを識別するために、サービスは、このような情報の暴露から少し害を被るだろう。
HTTP State Management has been very controversial because of its potential to expose information about a user's browsing habits to third parties, without the knowledge or consent of the user. While such exposure is possible, this is less a flaw in the protocol itself than a failure of HTTP client implementations (and of some providers of HTTP-based services) to protect users' interests.
HTTP状態管理ため、ユーザの知識や同意なしに、第三者にユーザーのブラウジング習慣に関する情報を公開するその可能性の非常に論争の的となっています。そのような露出が可能ではあるが、これは、ユーザーの利益を保護するためのHTTPクライアント実装（およびHTTPベースのサービスの一部のプロバイダの）の失敗よりもプロトコル自体にはあまり欠陥です。
As implied above, there are other ways to maintain session state than using HTTP State Management, and therefore other ways in which users' browsing habits can be tracked. Indeed, it is difficult to imagine how the HTTP protocol or an HTTP client could actually prevent a service from disclosing a user's "click trail" to other parties if the service chose to do so. Protection of such information from inappropriate exposure must therefore be the responsibility of the service. HTTP client implementations inherently cannot provide such protection, though they can implement countermeasures which make it more difficult for HTTP State Management to be used as the mechanism by which such information is exposed.
上記示唆されるように、HTTP状態管理を使用するよりも、セッション状態を維持する他の方法、およびユーザーのブラウジング習慣を追跡することができるので、他の方法があります。確かに、サービスがそうすることを選択した場合は、HTTPプロトコルまたはHTTPクライアントは、実際に他の当事者へのユーザの「クリックトレイル」公開からサービスを防ぐことができるか想像することは困難です。不適切な暴露からそのような情報の保護は、したがって、サービスの責任でなければなりません。彼らはそのような情報が公開されるメカニズムとして使用するにはHTTP状態管理のためにそれをより困難にする対策を実施することができますが、HTTPクライアントの実装は、本質的に、そのような保護を提供することはできません。
It is arguable that HTTP clients should provide more protection in general against inappropriate exposure of tracking information, regardless of whether the exposure were facilitated by use of HTTP State Management or by some other means. However, issues related to other mechanisms are beyond the scope of this memo.
HTTPクライアントに関係なく、露出がHTTP状態管理の使用により、または他の手段によって促進されたかどうかの、追跡情報の不適切な露出に対して、一般的にはより多くの保護を提供する必要があることを議論の余地があります。しかし、他のメカニズムに関連する問題は、このメモの範囲を超えています。
A user's willingness to consent to use of HTTP State Management is likely to vary from one service to another, according to whether the user trusts the service to use the information appropriately and to limit its exposure to other parties. The user therefore SHOULD be able to control whether his client supports a service's request to use HTTP State Management, on a per-service basis. In particular:
HTTP状態管理の使用に同意するユーザの意欲は、ユーザーが情報を適切に使用し、他の当事者に対するエクスポージャーを制限するサービスを信頼するかどうかに応じて、1つのサービスごとに異なる可能性があります。したがって、ユーザは、彼のクライアントは、サービスごとに、HTTP状態管理を使用するサービスの要求をサポートするかどうかを制御することができるべきです。特に：
(1) Clients MUST NOT respond to HTTP State Management requests unless explicitly enabled by the user.
ユーザーによって明示的に有効にしない限り、（1）クライアントがHTTP状態管理の要求に応じてはいけません。
(2) Clients SHOULD provide an effective interface which allows users to review, and approve or refuse, any particular requests from a server to maintain state information, before the client provides any state information to the server.
（2）クライアントは、クライアントがサーバーにすべての状態情報を提供する前に、サーバーからの特定の要求が状態情報を維持するために、ユーザーが確認し、承認または拒否することを可能にする効果的なインターフェイスを提供する必要があります。
(3) Clients SHOULD provide an effective interface which allows users to instruct their clients to ignore all requests from a particular service to maintain state information, on a per-service basis, immediately in response to any particular request from a server, before the client provides any state information to the server.
（3）クライアントは、クライアントの前に、ユーザーがすぐにサーバーからの特定の要求に応じて、サービスごとに、状態情報を維持するために、特定のサービスからのすべての要求を無視するように顧客に指示することを可能にする効果的なインターフェイスを提供する必要がありますサーバーへのすべての状態情報を提供します。
(4) Clients SHOULD provide an effective interface which allows a user to disable future transmission of any state information to a service, and/or discard any saved state information for that service, even though the user has previously approved a service's request to maintain state information.
（4）クライアントは、ユーザが以前の状態を維持するために、サービスの要求を承認しているにもかかわらず、ユーザがサービスにどのような状態情報の将来の送信を無効にすることを可能にする効果的なインターフェースを提供し、および/またはそのサービスのための任意の保存された状態情報を破棄すべきです情報。
(5) Clients SHOULD provide an effective interface which allows a user to terminate a previous request not to retain state management information for a given service.
（5）クライアントは、ユーザが所与のサービスのための状態管理情報を保持しない以前の要求を終了することを可能にする効果的なインターフェイスを提供すべきです。
The domain-match algorithm in RFC-2965 section 2 is intended as a heuristic to allow a client to "guess" whether or not two domains are part of the same service. There are few rules about how domain names can be used, and the structure of domain names and how they are delegated varies from one top-level domain to another (i.e. the client cannot tell which part of the domain was assigned to the service). Therefore NO string comparison algorithm (including the domain-match algorithm) can be relied on to distinguish a domain that belongs to a particular service, from a domain that belongs to another party.
RFC-2965のセクション2でドメインマッチアルゴリズムは、クライアントが2つのドメインが同じサービスの一部であるかどうかを「推測」することを可能にするヒューリスティックとして意図されています。そこドメイン名を使用する方法についていくつかのルールがあり、ドメイン名の構造とどのようにそれらが委任されている（つまり、クライアントがサービスに割り当てられたドメインの一部で伝えることはできません）1つのトップレベルドメインから別のものに変わります。したがって、（ドメインマッチアルゴリズムを含む）は、文字列比較アルゴリズムは、他の当事者に所属するドメインから、特定のサービスに属しているドメインを識別するために依拠することはできません。
As stated above, each service is ultimately responsible for ensuring that user information is not inappropriately leaked to third parties. Leaking information to third parties via State Management by careful selection of domain names, or by assigning domain names to hosts maintained by third parties, is at least as inappropriate as leaking the same information by other means.
上述したように、各サービスは、ユーザ情報が不適切に第三者に漏洩していないことを確実にするための最終的な責任です。ドメイン名を慎重に選択することによって、又は第三者によって維持されるホストにドメイン名を割り当てることにより、状態管理を介して、第三者への情報漏洩、他の手段によって同じ情報を漏洩、少なくともとして不適切です。
This entire memo is about security considerations.
この全体のメモはセキュリティ上の考慮事項についてです。
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450
テネシーコンピュータサイエンス学部のキース・ムーア大学1122ボランティアブルバード、スイート203ノックスビルTN、37996から3450
EMail: moore@cs.utk.edu
メールアドレス：moore@cs.utk.edu
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 81790
ネッドフリードInnosoftの国際、Inc.の1050湖ドライブウェストコヴィナ、CA 81790
EMail: ned.freed@innosoft.com
メールアドレス：ned.freed@innosoft.com
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1123]ブレーデン、R.、 "インターネットホストのための要件 - 、アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC 2965]クリストル、D.およびL. Montulli、 "HTTP状態管理機構"、RFC 2965、2000年10月。
[RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.
[RFC 2109]クリストル、D.およびL. Montulli、 "HTTP状態管理機構"、RFC 2109、1997年2月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。