[要約] RFC 2964は、HTTP状態管理の使用に関するガイドラインであり、クライアントとサーバー間での状態情報の管理方法を定義しています。その目的は、セッションの状態を維持し、ユーザーエクスペリエンスを向上させることです。
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
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 (2000). All Rights Reserved.
Copyright（c）The Internet Society（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）を使用し、このメカニズムが実際の.localTLDがこれまでにある場合に期待される方法で機能しない可能性があることを指摘しています。登録されます。
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）有害であり、落胆していると考えられている（a）（a）推奨されていない、HyperText Transfer Protocol（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状態管理メカニズムは、有用で議論の余地があります。HTTPの多数のアプリケーションが、URLでそのような状態をエンコードせずに、HTTPトランザクション間で状態を救う能力から利益を得るため、これは有用です。メカニズムは、設計されておらず、適切ではないことを達成するためにメカニズムが使用されているため、議論の余地があります。これらの用途のいくつかは、特にユーザーが訪問したWebサイトなどの第三者に潜在的にデリケートな情報を漏らすことにより、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.
このドキュメントは、大文字に表示される用語を使用することがあります。「必要はない」、「そうでなければ」、「必要はない」、「そうでない」、および「そうでなければ」、「は」、「は」、「必要はない」が大文字に表示される場合、この仕様の特定の要件を示すために使用されています。[RFC-1123]に「必須」、「必須」、「可能性」という用語の意味の議論が表示されます。「そうでないでください」と「すべきではない」という用語は、この使用法の論理的な拡張です。
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リダイレクトに表示される1つ以上のURLにセッション識別子を埋め込むか、動的に生成されたHTMLに状態情報をサービスからユーザーに送信できます。また、そのような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 Webカタログエントリの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キャッシュが名前付きリソースのコピーのみを維持できます。状態がセッション固有の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 State Management Protocolは、ユーザーまたはユーザーのクライアントがセッション状態を維持するリクエストを尊重しない場合、サービスプロバイダーがサービスの提供を拒否するか、サービスのレベルの低下を拒否できるようにすることに注意してください。反対の法的禁止がなければ、サーバーは、これらの条件下でサービスの提供を拒否したり、サービスのレベルを下げたりすることを拒否する場合があります。純粋に実用的な考慮事項として、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州管理の有効性を低下させる傾向があるため、Webの運用に有害であると考えられています。
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 NOT be used as an authentication mechanism to protect information from being exposed to unauthorized parties, even if the HTTP sessions are encrypted.
一般に、HTTP状態管理プロトコルを認証メカニズムとして使用することは不適切です。HTTP州管理はそのような使用を念頭に置いて設計されておらず、認証資格の保護のための保護措置は、プロトコル仕様と広く展開されているHTTPクライアントとサーバーの両方に不足しています。ほとんどのHTTPセッションは暗号化されていないため、「Cookie」は受動的な盗聴者にさらされる可能性があります。さらに、HTTPクライアントとサーバーは通常、露出に対する保護がほとんどまたはまったくなく、「Cookie」をクリアテキストに保存します。したがって、HTTP州の管理は、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状態管理を認証に使用することに対する禁止には、サービスによって提供される情報を保護するための使用と、サービスのケアに委ねられているユーザーに関する潜在的に機密情報を保護するための使用の両方が含まれます。たとえば、ユーザーの名前、住所、電話番号、または請求情報を、以前にユーザーに関連付けられていたCookieを提示しただけのクライアントに公開することは不適切です。
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の状態管理を使用してユーザーリクエストを認証するために使用すべきではありません。たとえば、ユーザーが保存されている「Cookie」に完全に基づいて、ユーザーが1つの「Click」で商品を注文できるようにするサービスは、クレジットカードに料金に異議を唱えたり、不要なものを返したりすることを要求することでユーザーに不便をかける可能性があります。クッキーが第三者にさらされた場合の商品。
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州管理の使用に同意する意欲は、ユーザーがサービスを適切に使用し、他の当事者へのエクスポージャーを制限することを信頼しているかどうかに応じて、サービスによってサービスによって異なる可能性があります。したがって、ユーザーは、クライアントがサービスごとに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のドメインマッチアルゴリズムは、クライアントが同じサービスの一部であるかどうかをクライアントが「推測」できるようにするためのヒューリスティックとして意図されています。ドメイン名をどのように使用できるか、ドメイン名の構造とそれらがどのように委任されるかについてのルールはほとんどありません。つまり、トップレベルのドメインから別のドメインまでさまざまです（つまり、クライアントはドメインのどの部分がサービスに割り当てられたかを知ることができません）。したがって、文字列比較アルゴリズム（ドメインマッチアルゴリズムを含む）は、他のパーティに属するドメインと特定のサービスに属するドメインを区別するために依存することはできません。
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ボランティアBlvd、スイート203ノックスビルTN、37996-3450
EMail: moore@cs.utk.edu
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 81790
Ned Freed Innosoft International、Inc。1050 Lakes Drive West Covina、CA 81790
EMail: ned.freed@innosoft.com
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC 2965] Kristol、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] Kristol、D。およびL. Montulli、「HTTP州管理メカニズム」、RFC 2109、1997年2月。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。