RFC2964 日本語訳
2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Moore Request for Comments: 2964 University of Tennessee BCP: 44 N. Freed Category: Best Current Practice Innosoft October 2000
コメントを求めるワーキンググループK.ムーア要求をネットワークでつないでください: 2964年のテネシーBCP大学: 44のN.の解放されたカテゴリ: 最も良い現在の練習Innosoft2000年10月
Use of HTTP State Management
HTTP国家管理の使用
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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国家管理メカニズム」(RFC2965)、およびその前任者(RFC-2109)で説明されたメカニズムは使用できます。 しかしながら、それらには重要なユーザプライバシーとセキュリティ意味があるので、プロトコルのいくつかの現在の、そして、潜在的の用途が論議を呼んでいます。 このメモはIETFによって推薦されなかった(a)か有害であって、妨げると信じられている(b)のどちらかであるハイパーテキストTransferプロトコル(HTTP)州のManagementプロトコルの特定の用途を特定します。 また、このメモはHTTP州Managementプロトコル仕様でカバーされていない追加プライバシー問題を詳しく述べます。
1. Introduction
1. 序論
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
HTTP州Managementメカニズムは、役に立って、かつ論議を呼んでいます。 HTTPの頻繁なアプリケーションがHTTPトランザクションの間の状態を節約する能力の利益を得るので、それは役に立ちます、URLでそのような状態をコード化しないで。 メカニズムがそれが設計されなかったものを達成するのに使用されて、十分合っていないので、それは論議を呼んでいます。 ウェブのプライバシーに違反すると脅かすので、これらの用途のいくつかが大きな世論の批判を引き付けました。
Moore & Freed Best Current Practice [Page 1] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[1ページ]。
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州Managementの他の用途があります。
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州Managementプロトコルの用途を特定します。
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"という用語、「必須NOT」、“SHOULD"である、「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 用語“MUST"、“SHOULD"、および「5月」の意味の議論は[RFC-1123]に現れます。 そして、「必須NOT」という用語、「」 この用法は論理的な拡大があるべきですか?
2. Uses of HTTP State Management
2. HTTP国家管理の用途
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州Managementの目的はHTTPベースのサービスが複数のHTTPトランザクションの向こう側に固執するstateful「セッション」を作成するのを許容することです。 ただ一つのセッションは複数のサーバー・ホストにトランザクションにかかわるかもしれません。 また、複数のクライアントホストが特定のユーザへのセッションデータがクライアントホスト(例えば、ネットワークでつながれたファイルシステムを通した)の間で共有されるただ一つのセッションにかかわるかもしれません。 言い換えれば、「セッション」は特定のホストではなく、「ユーザ」と「サービス」の間の状態を保有します。
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を使用することで達成されるかもしれないとわかるのは重要です、州Management拡張子なしで。 例えば、ユーザに対するサービスからセッション識別子を1つに埋め込むことによって州の情報を伝えることができるか、またはHTTPに現れるより多くのURLが、HTMLであると向け直すか、ダイナミックに生成されます。 ユーザからサービスまでそのようなURLがいつGETかポストの要求に現れるかというそして、州の情報を返すかもしれません。 また、ユーザに対するサービスから州の情報を行き帰り通過するのに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州Management施設は普通の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) statefulセッションの間にそれらのセッションに関連している州の情報を漏らさないでアクセスされたリソースのユーザの間でURLを交換する能力。 (例えば、「ここに、あなたが欲しかったそれらのサンダルのためのFooCorpウェブ記入へのURLがあります」。)
Moore & Freed Best Current Practice [Page 2] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[2ページ]。
(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とセッション状態を切り離すのに、ウェブキャッシュは命名されたリソースのただ一つのコピーしか維持できません。 状態がセッション特有の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) したがって安定貯蔵にセッション情報を保存するクライアント実施か、システムリブートと、クライアントかシステムクラッシュの向こう側に「セッション」を維持できる能力。
2.1. Recommended Uses
2.1. お勧めの用途
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州Managementの使用が適切である、:
(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
そのようなお勧めの使用に関する例がショッピングカートの存在が明らかに明らかにユーザ、ユーザ缶に明らかにされる「ショッピングカート」「空」の彼のものか彼女のショッピングカートであるだろう、(それが空にされているよう要求するか、またはそれらを購入すること。
Moore & Freed Best Current Practice [Page 3] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[3ページ]。
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州Managementプロトコルでサービスを提供するのを拒否できることに注意するか、または減少しているレベルのサービスを前提としてください、ユーザかユーザのクライアントがセッション状態を維持するという要求を光栄に思わないなら。 それと反対な法的な禁止がなければ、サーバは、サービスを提供するか、または減少しているレベルのサービスを提供するのを拒否するかもしれません、これらの条件で。 純粋に実用的な考慮として、クライアントがそれを提供しないなら、HTTP州Managementを利用するように設計されたサービスは適切に機能できないかもしれません。 そのようなサーバSHOULDは、優雅にそのような状態を扱って、完全なレベルのサービスがなぜ利用可能でないかをユーザに説明します。
2.2. Problematic Uses
2.2. 問題の多い用途
The following uses of HTTP State Management are deemed inappropriate and contrary to this specification:
HTTP州Managementの以下の用途はこの仕様に不適当であって、反対であると考えられます:
2.2.1. Leakage of Information to Third Parties
2.2.1. 第三者への情報の漏出
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州Managementを使用してはいけません、ユーザの明白な同意なしで。 ユーザの名前か他の外部的に割り当てられた識別子が相手に暴露されないでも、そのような用法は禁止されます、国家管理メカニズム自体がユーザの情報をコンパイルするのに使用できる識別子を提供するので。
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州Managementメカニズムを破るよう奨励するので、それらは、HTTP州Managementの有効性を減少させる傾向があって、したがって、ウェブの操作に有害であると考えられます。
2.2.2. Use as an Authentication Mechanism
2.2.2. 認証機構としての使用
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州Managementプロトコルを使用するのは不適当です。 HTTP州Managementはそのような使用で念頭に設計されていません、そして、認証資格証明書の保護のための安全装置は両方でプロトコル仕様と広く配布しているHTTPクライアントとサーバで欠けています。 ほとんどのHTTPセッションは暗号化されていません、そして、したがって、「クッキー」は受け身の立ち聞きする者に暴露されるかもしれません。 その上、HTTPクライアントとサーバはcleartextに暴露に対する保護でまず「クッキー」を通常保存しません。 HTTP州Management、したがって、SHOULD
Moore & Freed Best Current Practice [Page 4] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[4ページ]。
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州Managementを使用することに対する禁止は、サービスの注意に任せられるユーザの潜在的に機密の情報を保護するためにサービスで提供される情報を保護する使用とその使用の両方を含んでいます。 例えば、クライアントへのユーザの名前、アドレス、電話番号、または支払い情報が以前にユーザに関連した単にそんなに提示されたクッキーであると暴露するのは不適当でしょう。
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州Management SHOULD NOTは権限のない要求でユーザにとって、望ましくないサイド効果があるかもしれなくて、ユーザがそのような副作用の可能性を意識していない場合ユーザ要求を認証するのに使用されて、明らかにそのような使用に承諾します。 例えば、クッキーが第三者に暴露される場合、ユーザがシングルで商品を注文したサービスは、「クリックし」て、保存された「クッキー」を完全にユーザのものに基礎づけて、彼女がクレジットカードに充電について議論するのを必要とすることによってユーザに迷惑をかける、そして/または、求められていない商品を返すかもしれないでしょうに。
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州Managementのいくつかの用途が比較的無害であるかもしれません、そして、サービスはそのような情報の暴露から害をほとんど受けないでしょう。
3. User Interface Considerations for HTTP State Management
3. 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州Managementは第三者へのユーザのブラウジング習慣の情報を暴露する可能性のために非常に論議を呼んでいます、ユーザの知識も同意なしで。 そのような暴露が可能ですが、これはプロトコル自体の欠点より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州Managementを使用して、したがって、ユーザのブラウジング習慣を追跡できる他の方法を使用すること以外のセッション状態を維持する方法があります。 本当に、HTTPプロトコルかHTTPクライアントが、実際にサービスが、そうするのを選んだならサービスがユーザの「クリック道」を相手に明らかにするのをどうしたら防ぐことができたかを想像するのは難しいです。 したがって、不適当な暴露からのそのような情報の保護はサービスの責任であるに違いありません。 HTTPクライアント実装は本来そのような保護を提供できません、HTTP州Managementがそのような情報が暴露されるメカニズムとして使用されるのをより難しくする対策を実装することができますが。
Moore & Freed Best Current Practice [Page 5] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[5ページ]。
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州Managementの使用かある他の手段で容易にされたかどうかにかかわらず。 しかしながら、他のメカニズムに関連する問題はこのメモの範囲を超えています。
3.1. Capabilities Required of an HTTP Client
3.1. 能力が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州Managementの使用に承諾するユーザの意欲は別のものに対する1つのサービスと異なりそうです、ユーザが適切に情報を使用して、暴露を相手に制限するためにサービスを信じるかどうかに従って。 したがって、ユーザSHOULD、彼のクライアントがHTTP州Managementを使用するというサービスの要求をサポートするかどうかを制御できてください、調査基準価格で。 特に:
(1) Clients MUST NOT respond to HTTP State Management requests unless explicitly enabled by the user.
(1) ユーザによって明らかに可能にされない場合、クライアントはHTTP州Management要求に応じてはいけません。
(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) クライアントSHOULDはユーザがサーバからどんな特定の要求も再検討して、承認するか、または州の情報を保守するために拒否する有効なインタフェースを、提供します、クライアントがどんな州の情報もサーバに提供する前に。
(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) クライアントSHOULDはユーザが州の情報を保守するために特定のサービスからすべての要求を無視するよう彼らのクライアントに命令できる有効なインタフェースを提供します、aで-、調査基準価格、すぐサーバからのどんな特定の要求に対応して、以前、クライアントがどんな州の情報もサーバに提供します。
(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) クライアントSHOULDはユーザがどんな州の情報の今後の伝達もサービスに無効にする、そして/または、そのサービスのためにどんな保存している州の情報も捨てることができる有効なインタフェースを提供します、ユーザが以前に、州の情報を保守するというサービスの要求を承認しましたが。
(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) クライアントSHOULDはユーザが与えられたサービスのための州の経営情報を保有しないという前の要求を終えることができる有効なインタフェースを提供します。
3.2. Limitations of the domain-match algorithm
3.2. ドメインマッチアルゴリズムの制限
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
ヒューリスティックとして、RFC-2965部2のドメインマッチアルゴリズムが、クライアントが、2つのドメインが同じサービスの一部であるかどうか「推測すること」を許容することを意図します。 どうドメイン名を使用できるかに関する規則がわずかしかなくて、ドメイン名とどうそれらを代表として派遣するかに関する構造が1つの最上位のドメインから別のものに異なる、(すなわち、クライアントは、ドメインの一部がどれに割り当てられたかわかりません。
Moore & Freed Best Current Practice [Page 6] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[6ページ]。
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.
サービス) したがって、特定のサービスに属すドメインを区別するために、ストリング比較アルゴリズム(ドメインマッチアルゴリズムを含んでいる)を全く当てにすることができません、別のパーティーのものであるドメインから。
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.
上に述べられているように、ユーザー情報が不適当に第三者に漏らされないのを確実にするのにそれぞれのサービスは結局、原因となります。 ドメイン名の厳選、または第三者によって維持されたホストにドメイン名を割り当てるのによる州Managementを通して第三者に情報を漏らすのは他の手段で同じ情報を漏らすのと少なくとも同じくらい不適当です。
4. Security Considerations
4. セキュリティ問題
This entire memo is about security considerations.
この全体のメモはセキュリティ問題に関するものです。
5. Authors' Addresses
5. 作者のアドレス
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450
ボランティアBlvd、キース・ムーア・テネシーコンピュータ理学部大学1122スイート203ノクスビルテネシー37996-3450
EMail: moore@cs.utk.edu
メール: moore@cs.utk.edu
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 81790
ネッドはDriveウエストコビナ、Innosoftの国際Inc.1050Lakesカリフォルニア 81790を解放しました。
EMail: ned.freed@innosoft.com
メール: ned.freed@innosoft.com
6. References
6. 参照
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
ブレーデン、[RFC1123]R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000.
[RFC2965] クリストルとD.とL.Montulli、「HTTP国家管理メカニズム」、RFC2965、2000年10月。
[RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997.
[RFC2109] クリストルとD.とL.Montulli、「HTTP国家管理メカニズム」、RFC2109、1997年2月。
Moore & Freed Best Current Practice [Page 7] RFC 2964 Use of HTTP State Management October 2000
ムーアと解放された最も良い電流は国家管理2000年10月にHTTPのRFC2964使用を練習します[7ページ]。
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Moore & Freed Best Current Practice [Page 8]
ムーアと解放された最も良い現在の習慣[8ページ]
一覧
スポンサーリンク