RFC2817 日本語訳

Network Working Group                                           R. Khare
Request for Comments: 2817                     4K Associates / UC Irvine
Updates: 2616                                                S. Lawrence
Category: Standards Track                          Agranat Systems, Inc.
                                                                May 2000

Khareがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2817の4Kの仲間/UCアーバインアップデート: 2616秒間ローレンスCategory: 標準化過程AgranatシステムInc.2000年5月

                    Upgrading to TLS Within HTTP/1.1

HTTP/1.1の中でTLSにアップグレードします。

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
   initiate Transport Layer Security (TLS) over an existing TCP
   connection. This allows unsecured and secured HTTP traffic to share
   the same well known port (in this case, http: at 80 rather than
   https: at 443). It also enables "virtual hosting", so a single HTTP +
   TLS server can disambiguate traffic intended for several hostnames at
   a single IP address.

このメモで、既存のTCP接続の上でTransport Layer Security(TLS)を開始するのにHTTP/1.1にUpgradeメカニズムを使用する方法がわかります。 非機密保護していて機密保護しているHTTPトラフィックがこれで同じよく知られているポートを共有できる、(この場合、80歳のときに443で)以下をhttpsするよりむしろ以下をhttpします。 また、それが「仮想の接待」を可能にするので、独身のHTTP+TLSサーバはただ一つのIPアドレスのいくつかのホスト名のために意図するトラフィックのあいまいさを除くことができます。

   Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
   memo also documents the HTTP CONNECT method for establishing end-to-
   end tunnels across HTTP proxies. Finally, this memo establishes new
   IANA registries for public HTTP status codes, as well as public or
   private Upgrade product tokens.

HTTP/1.1[1]がホップごとのメカニズムとUpgradeを定義するので、また、このメモはHTTPプロキシの向こう側に終わりから端へのトンネルを確立するためのHTTP CONNECTメソッドを記録します。 最終的に、このメモは公共のHTTPステータスコードのために新しいIANA登録を確立します、公共の、または、個人的なUpgrade製品トークンと同様に。

   This memo does NOT affect the current definition of the 'https' URI
   scheme, which already defines a separate namespace
   (http://example.org/ and https://example.org/ are not equivalent).

このメモは'https'URI体系の現在の定義に影響しません( http://example.org/ と https://example.org/ は同等ではありません)。(既に、体系は別々の名前空間を定義します)。

Khare & Lawrence            Standards Track                     [Page 1]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[1ページ]。

Table of Contents

目次

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . .  4
   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
   3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2 Mandatory Upgrade  . . . . . . . . . . . . . . . . . . . . . .  4
   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  4
   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
   4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
   4.2 Mandatory Advertisement  . . . . . . . . . . . . . . . . . . .  5
   5.  Upgrade across Proxies . . . . . . . . . . . . . . . . . . . .  6
   5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
   5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . .  7
   6.  Rationale for the use of a 4xx (client error) Status Code  . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. 動機. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1要件用語. . . . . . . . . . . . . . . . . . . 4 3 クライアントはアップグレード要求. . . . . . . . . . . . . 4 4のTLS. . . . . . . . . . 4 3.1の任意のアップグレード. . . . . . . . . . . . . . . . . . . . . . . 4 3.2の義務的なアップグレード.43.3サーバ承認の上でHTTPにアップグレードを要求しました。 サーバはTLS. . . . . . . . . . 5 4.1の任意の広告. . . . . . . . . . . . . . . . . . . . 5 4.2の義務的な広告. . . . . . . . . . . . . . . . . . . 5 5の上のHTTPにアップグレードを要求しました。 プロキシの向こう側にホップアップグレード. . . . . . . . . . . . . . 6 5.2でホップの.65.1の含意をアップグレードさせてください。aがトンネルを堀るよう要求して、.65.3を接続してください。aがトンネルを堀る設立は.7 6を接続します。 4xx(クライアント誤り)状態Code. . 7 7の使用のための原理。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 7.1HTTPステータスコード登録.87.2HTTPアップグレードトークン登録. . . . . . . . . . . . . . . . . 8 8。 httpsのためのセキュリティConsiderations. . . . . . . . . . . . . . . . . . . 9 8.1Implications: URIが.108.2のセキュリティ問題を計画する、.10の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . 10の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 11A.承認. . . . . . . . . . . . . . . . . . . . . . . 12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13を接続してください。

1. Motivation

1. 動機

   The historical practice of deploying HTTP over SSL3 [3] has
   distinguished the combination from HTTP alone by a unique URI scheme
   and the TCP port number. The scheme 'http' meant the HTTP protocol
   alone on port 80, while 'https' meant the HTTP protocol over SSL on
   port 443.  Parallel well-known port numbers have similarly been
   requested -- and in some cases, granted -- to distinguish between
   secured and unsecured use of other application protocols (e.g.
   snews, ftps). This approach effectively halves the number of
   available well known ports.

SSL3[3]の上でHTTPを配布する歴史的な習慣はユニークなURI体系とTCPポートナンバーでHTTPと組み合わせを単独で区別しました。 体系'http'はポート80の上で単独でHTTPプロトコルを意味しました、'https'はポート443の上のSSLの上でHTTPプロトコルを意味しましたが。 平行なウェルノウン・ポート番号は、同様に要求されていて、いくつかの場合でそうしました、与えて--他のアプリケーション・プロトコル(例えば、snews、ftps)の機密保護していて非機密保護している使用を見分けるために。 事実上、このアプローチは利用可能なよく知られているポートの数を半分にします。

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security [6] to an open
   HTTP connection.

1997年12月のワシントンD.C.IETFミーティングでは、Applications AreaディレクターとIESGは、平行な「安全な」ポートナンバーを発行する習慣が推奨しないはずであるのを再び断言しました。 HTTP/1.1UpgradeメカニズムはオープンなHTTP接続にTransport Layer Security[6]を適用できます。

Khare & Lawrence            Standards Track                     [Page 2]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[2ページ]。

   In the nearly two years since, there has been broad acceptance of the
   concept behind this proposal, but little interest in implementing
   alternatives to port 443 for generic Web browsing. In fact, nothing
   in this memo affects the current interpretation of https: URIs.
   However, new application protocols built atop HTTP, such as the
   Internet Printing Protocol [7], call for just such a mechanism in
   order to move ahead in the IETF standards process.

およそ2年には、少ししかジェネリックウェブブラウジングのための443人を移植する代替手段を実装するのに関心がないので、以来、この提案の後ろに概念の広い承認があります。 事実上、このメモによる何もhttpsの現在の解釈に影響しません: URI。 しかしながら、インターネットPrintingプロトコル[7]などのHTTPの上で築き上げられた新しいアプリケーション・プロトコルは、IETF標準化過程に前方に入って来るためにまさしくそのようなメカニズムを求めます。

   The Upgrade mechanism also solves the "virtual hosting" problem.
   Rather than allocating multiple IP addresses to a single host, an
   HTTP/1.1 server will use the Host: header to disambiguate the
   intended web service. As HTTP/1.1 usage has grown more prevalent,
   more ISPs are offering name-based virtual hosting, thus delaying IP
   address space exhaustion.

また、Upgradeメカニズムは「仮想の接待」問題を解決します。 複数のIPアドレスを独身のホストに割り当てるよりむしろ、HTTP/1.1サーバはHostを使用するでしょう: 意図しているウェブサービスのあいまいさを除くヘッダー。 HTTP/1.1用法が、より一般的になったとき、より多くのISPが名前ベースの仮想の接待を提供していて、その結果、IPアドレス空間疲労困憊を遅らせます。

   TLS (and SSL) have been hobbled by the same limitation as earlier
   versions of HTTP: the initial handshake does not specify the intended
   hostname, relying exclusively on the IP address. Using a cleartext
   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
   certificates based on the initial Host: header -- will allow ISPs to
   provide secure name-based virtual hosting as well.

TLS(そして、SSL)はHTTPの以前のバージョンと同じ制限でびっこを引かされました: 排他的にIPアドレスを当てにして、初期の握手は意図しているホスト名を指定しません。 cleartext HTTP/1.1Upgradeを使用します: TLS握手への序文--証明書を選ぶと、初期のHostは基づきました: ヘッダー--ISPがまた、安全な名前ベースの仮想の接待を提供するのを許容するでしょう。

2. Introduction

2. 序論

   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
   to-end connection, optionally including strong mutual authentication,
   using a variety of cryptosystems. Initially, a handshake phase uses
   three subprotocols to set up a record layer, authenticate endpoints,
   set parameters, as well as report errors.  Then, there is an ongoing
   layered record protocol that handles encryption, compression, and
   reassembly for the remainder of the connection. The latter is
   intended to be completely transparent. For example, there is no
   dependency between TLS's record markers and or certificates and
   HTTP/1.1's chunked encoding or authentication.

TLS(通称SSL(セキュリティソケットレイヤー))は終わりまでの個人的な終わりの接続を確立します、任意に強い互いの認証を含んでいて、さまざまな暗号系を使用して。初めは、握手フェーズは、記録的な層をセットアップして、終点を認証して、パラメタを設定して、誤りを報告するのに3「副-プロトコル」を使用します。 そして、接続の残りのために暗号化、圧縮、および再アセンブリを扱う進行中の層にされた記録的なプロトコルがあります。 後者が完全に透明であることを意図します。 例えば、いいえか依存がコード化しながらTLSの記録的なマーカーの間、そして、または、証明書とHTTP/1.1chunkedした認証があります。

   Either the client or server can use the HTTP/1.1 [1] Upgrade
   mechanism (Section 14.42) to indicate that a TLS-secured connection
   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
   token, and a new HTTP Status Code, "426 Upgrade Required".

クライアントかサーバが、TLSによって機密保護された接続が必要であるか、または必要であることを示すのに、HTTP/1.1[1]アップグレードメカニズム(セクション14.42)を使用できます。 このメモが定義する、「TLS/1インチがトークン、および新しいHTTPステータスコードをアップグレードさせるのが「426アップグレードが必要」でした」。

   Section 3 and Section 4 describe the operation of a directly
   connected client and server. Intermediate proxies must establish an
   end-to-end tunnel before applying those operations, as explained in
   Section 5.

セクション3とセクション4は直接接続されたクライアントとサーバの操作について説明します。それらの操作を適用する前に中間的プロキシは終わりから端へのトンネルを確立しなければなりません、セクション5で説明されるように。

Khare & Lawrence            Standards Track                     [Page 3]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[3ページ]。

2.1 Requirements Terminology

2.1 要件用語

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC 2119 [11].

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 中に解釈されて、このドキュメントには説明されるとしてあるコネに現れる「5月」RFC2119[11]であるべきではありません。

3. Client Requested Upgrade to HTTP over TLS

3. クライアントはTLSの上のHTTPにアップグレードを要求しました。

   When the client sends an HTTP/1.1 request with an Upgrade header
   field containing the token "TLS/1.0", it is requesting the server to
   complete the current HTTP/1.1 request after switching to TLS/1.0.

クライアントがUpgradeヘッダーフィールドがトークンを含んでいるHTTP/1.1要求を送るとき、「何TLS/1インチも、TLS/1.0に切り替わった後に、現在のHTTP/1.1要求を終了するようサーバに要求しています」。

3.1 Optional Upgrade

3.1 任意のアップグレード

   A client MAY offer to switch to secured operation during any clear
   HTTP request when an unsecured response would be acceptable:

クライアントは、非機密保護している応答が許容できるだろうというとき、どんな明確なHTTP要求の間も、機密保護している操作に切り替わると申し出るかもしれません:

       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1ホストを手に入れてください: example.bank.com Upgrade: TLS/1.0接続: アップグレード

   In this case, the server MAY respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   section).

この場合、通常、サーバは明確なHTTP操作に反応するかもしれません、機密保護している操作へのORスイッチ(次のセクションで詳しく述べられるように)。

   Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
   supplied within a Connection header field (section 14.10) whenever
   Upgrade is present in an HTTP/1.1 message".

HTTP/1.1[1]が指定することに注意してください。「UpgradeがHTTP/1.1メッセージに存在しているときはいつも、Connectionヘッダーフィールド(セクション14.10)の中でアップグレードキーワードを提供しなければなりません」。

3.2 Mandatory Upgrade

3.2 義務的なアップグレード

   If an unsecured response would be unacceptable, a client MUST send an
   OPTIONS request first to complete the switch to TLS/1.0 (if
   possible).

非機密保護している応答が容認できないなら、クライアントは最初に、TLS/1.0(できれば)にスイッチを完成するというOPTIONS要求を送らなければなりません。

       OPTIONS * HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

オプション*HTTP/1.1ホスト: example.bank.com Upgrade: TLS/1.0接続: アップグレード

3.3 Server Acceptance of Upgrade Request

3.3 アップグレード要求のサーバ承認

   As specified in HTTP/1.1 [1], if the server is prepared to initiate
   the TLS handshake, it MUST send the intermediate "101 Switching
   Protocol" and MUST include an Upgrade response header specifying the
   tokens of the protocol stack it is switching to:

HTTP/1.1[1]で指定されるように、サーバがTLS握手を開始するように準備されるなら、それは、中間的「101切り換えプロトコル」を送らなければならなくて、以下のことのためにそれが切り換えているプロトコル・スタックのトークンを指定するUpgrade応答ヘッダを含まなければなりません。

Khare & Lawrence            Standards Track                     [Page 4]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[4ページ]。

       HTTP/1.1 101 Switching Protocols
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

HTTP/1.1 101の切り換えプロトコルがアップグレードします: TLS/1.0、HTTP/1.1接続: アップグレード

   Note that the protocol tokens listed in the Upgrade header of a 101
   Switching Protocols response specify an ordered 'bottom-up' stack.

101Switchingプロトコル応答のUpgradeヘッダーに記載されたプロトコルトークンが命令された'ボトムアップ'スタックを指定することに注意してください。

   As specified in  HTTP/1.1 [1], Section 10.1.2: "The server will
   switch protocols to those defined by the response's Upgrade header
   field immediately after the empty line which terminates the 101
   response".

HTTP/1.1[1]、セクション10.1.2で指定されるように: 「サーバは101応答を終える空の系列直後応答のUpgradeヘッダーフィールドによって定義されたものにプロトコルを切り換えるでしょう。」

   Once the TLS handshake completes successfully, the server MUST
   continue with the response to the original request. Any TLS handshake
   failure MUST lead to disconnection, per the TLS error alert
   specification.

一度、握手が首尾よく完成するTLS、サーバはオリジナルの要求への応答を続行しなければなりません。 どんなTLS握手の故障もTLS誤り警戒仕様あたりの断線につながらなければなりません。

4. Server Requested Upgrade to HTTP over TLS

4. サーバはTLSの上のHTTPにアップグレードを要求しました。

   The Upgrade response header field advertises possible protocol
   upgrades a server MAY accept. In conjunction with the "426 Upgrade
   Required" status code, a server can advertise the exact protocol
   upgrade(s) that a client MUST accept to complete the request.

Upgrade応答ヘッダーフィールドはサーバが受け入れるかもしれない可能なプロトコルアップグレードの広告を出します。 「アップグレードが必要とした426」ステータスコードに関連して、サーバはクライアントが要求を終了するために受け入れなければならない正確なプロトコルアップグレードの広告を出すことができます。

4.1 Optional Advertisement

4.1 任意の広告

   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed.

HTTP/1.1[1]で指定されるように、サーバはプロトコルのどんな(組み合わせ)にも切り替わる意欲が記載したのを示すために101か426以外のどんな応答にもUpgradeヘッダーを含むかもしれません。

4.2 Mandatory Advertisement

4.2 義務的な広告

   A server MAY indicate that a client request can not be completed
   without TLS using the "426 Upgrade Required" status code, which MUST
   include an an Upgrade header field specifying the token of the
   required TLS version.

サーバは、クライアント要求がTLSなしで「アップグレードが必要とした426」ステータスコードを使用することで終了できないのを示すかもしれません、Upgradeを含まなければならないもの。必要なTLSバージョンのトークンを指定するヘッダーフィールド。

       HTTP/1.1 426 Upgrade Required
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

HTTP/1.1 426アップグレードはアップグレードを必要としました: TLS/1.0、HTTP/1.1接続: アップグレード

   The server SHOULD include a message body in the 426 response which
   indicates in human readable form the reason for the error and
   describes any alternative courses which may be available to the user.

サーバSHOULDは人間の読み込み可能なフォームで誤りの理由を示して、どんな利用可能であるかもしれない二筋道についてもユーザに説明する426応答にメッセージ本体を含んでいます。

   Note that even if a client is willing to use TLS, it must use the
   operations in Section 3 to proceed; the TLS handshake cannot begin
   immediately after the 426 response.

クライアントが、TLSを使用しても構わないと思っても、続くのにセクション3で操作を使用しなければならないことに注意してください。 TLS握手は426応答直後始まることができません。

Khare & Lawrence            Standards Track                     [Page 5]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[5ページ]。

5. Upgrade across Proxies

5. プロキシの向こう側のアップグレード

   As a hop-by-hop header, Upgrade is negotiated between each pair of
   HTTP counterparties.  If a User Agent sends a request with an Upgrade
   header to a proxy, it is requesting a change to the protocol between
   itself and the proxy, not an end-to-end change.

ホップごとのヘッダーとして、Upgradeはそれぞれの組のHTTPカウンターパーティの間で交渉されます。 UserエージェントがUpgradeヘッダーをもって要求をプロキシに送るなら、それは終わりから終わりへの変化ではなく、それ自体とプロキシの間のプロトコルへの変化を要求しています。

   Since TLS, in particular, requires end-to-end connectivity to provide
   authentication and prevent man-in-the-middle attacks, this memo
   specifies the CONNECT method to establish a tunnel across proxies.

TLSが認証を提供して、介入者攻撃を防ぐために終わりから終わりへの接続性を特に必要とするので、このメモはプロキシの向こう側にトンネルを確立するCONNECTメソッドを指定します。

   Once a tunnel is established, any of the operations in Section 3 can
   be used to establish a TLS connection.

トンネルがいったん確立されると、TLS接続を証明するのにセクション3における操作のいずれも使用できます。

5.1 Implications of Hop By Hop Upgrade

ホップごとの5.1の含意がアップグレードします。

   If an origin server receives an Upgrade header from a proxy and
   responds with a 101 Switching Protocols response, it is changing the
   protocol only on the connection between the proxy and itself.
   Similarly, a proxy might return a 101 response to its client to
   change the protocol on that connection independently of the protocols
   it is using to communicate toward the origin server.

発生源サーバがプロキシからUpgradeヘッダーを受けて、101Switchingプロトコル応答で反応するなら、それは単にプロキシとそれ自体との接続のときにプロトコルを変えます。 同様に、プロキシは、その接続のときにそれが発生源サーバに向かって伝えるのに使用しているプロトコルの如何にかかわらずプロトコルを変えるためにクライアントへの101応答を返すかもしれません。

   These scenarios also complicate diagnosis of a 426 response.  Since
   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
   might remove the accompanying Upgrade header and prevent the client
   from determining the required protocol switch.  If a client receives
   a 426 status without an accompanying Upgrade header, it will need to
   request an end to end tunnel connection as described in Section 5.2
   and repeat the request in order to obtain the required upgrade
   information.

また、これらのシナリオは426応答の診断を複雑にします。 Upgradeがホップごとのヘッダーであるので、クライアントは、426を認めないプロキシによって、付随のUpgradeヘッダーを取り除いて、必要なプロトコルスイッチを決定できないかもしれません。 クライアントが付随のUpgradeヘッダーなしで426状態を取ると、それは、セクション5.2で説明されるようにトンネル接続を終わらせて、必要なアップグレード情報を得るために要求を繰り返すよう終わりに要求する必要があるでしょう。

   This hop-by-hop definition of Upgrade was a deliberate choice.  It
   allows for incremental deployment on either side of proxies, and for
   optimized protocols between cascaded proxies without the knowledge of
   the parties that are not a part of the change.

ホップごとのUpgradeのこの定義は慎重な選択でした。 それは変化の一部でないパーティーに関する知識なしでプロキシのどちらかの側面、およびどっと落しているプロキシの間の最適化されたプロトコルのための増加の展開を考慮します。

5.2 Requesting a Tunnel with CONNECT

aがトンネルを堀るよう要求する5.2が接続します。

   A CONNECT method requests that a proxy establish a tunnel connection
   on its behalf. The Request-URI portion of the Request-Line is always
   an 'authority' as defined by URI Generic Syntax [2], which is to say
   the host name and port number destination of the requested connection
   separated by a colon:

CONNECTメソッドは、プロキシがそのに代わってトンネル接続を確立するよう要求します。 要求された接続のホスト名とポートナンバーの目的地がコロンで分離したと言うことになっているURI Generic Syntax[2]によって定義されるようにいつもRequest-線のRequest-URI一部が'権威'です:

      CONNECT server.example.com:80 HTTP/1.1
      Host: server.example.com:80

CONNECT server.example.com: 80 HTTP/1.1Host: server.example.com: 80

Khare & Lawrence            Standards Track                     [Page 6]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[6ページ]。

   Other HTTP mechanisms can be used normally with the CONNECT method --
   except end-to-end protocol Upgrade requests, of course, since the
   tunnel must be established first.

終わりから終わりへのプロトコルUpgrade要求を除いて、通常、CONNECTメソッドで他のHTTPメカニズムを使用できる、もちろん、最初にトンネルを確立しなければならないので。

   For example, proxy authentication might be used to establish the
   authority to create a tunnel:

例えば、プロキシ認証はトンネルを作成する権威を証明するのに使用されるかもしれません:

      CONNECT server.example.com:80 HTTP/1.1
      Host: server.example.com:80
      Proxy-Authorization: basic aGVsbG86d29ybGQ=

CONNECT server.example.com: 80 HTTP/1.1Host: server.example.com: 80Proxy-承認: 基本的なaGVsbG86d29ybGQ=

   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
   sent immediately after the blank line. The usual caveats also apply:
   data may be discarded if the eventual response is negative, and the
   connection may be reset with no response if more than one TCP segment
   is outstanding.

いかなる他のもHTTP/1.1要求をpipelinedしたように、空白行直後トンネルを堀られるべきデータを送るかもしれません。 また、いつもの警告は適用されます: 最後の応答が否定的であるなら、データは捨てられるかもしれません、そして、1つ以上のTCPセグメントが傑出しているなら、接続は応答なしでリセットされるかもしれません。

5.3 Establishing a Tunnel with CONNECT

aを設立するのがトンネルを堀る5.3は接続します。

   Any successful (2xx) response to a CONNECT request indicates that the
   proxy has established a connection to the requested host and port,
   and has switched to tunneling the current connection to that server
   connection.

CONNECT要求へのどんなうまくいっている(2xx)応答も、プロキシが要求されたホストとポートに取引関係を築いて、そのサーバ接続に現在の接続にトンネルを堀るのに切り替わったのを示します。

   It may be the case that the proxy itself can only reach the requested
   origin server through another proxy.  In this case, the first proxy
   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
   to the authority.  A proxy MUST NOT respond with any 2xx status code
   unless it has either a direct or tunnel connection established to the
   authority.

プロキシ自体が別のプロキシを通して要求された発生源サーバに達することができるだけであるのは、事実であるかもしれません。 この場合、最初のプロキシSHOULDは次期プロキシの、そして、そんなに要求しているトンネルのCONNECT要求を権威にします。 それに権威に確立されたダイレクトであるかトンネル接続がない場合、プロキシはどんな2xxステータスコードでも応じてはいけません。

   An origin server which receives a CONNECT request for itself MAY
   respond with a 2xx status code to indicate that a connection is
   established.

それ自体を求めるCONNECT要求を受け取る発生源サーバは、接続が確立されるのを示すために2xxステータスコードで反応するかもしれません。

   If at any point either one of the peers gets disconnected, any
   outstanding data that came from that peer will be passed to the other
   one, and after that also the other connection will be terminated by
   the proxy. If there is outstanding data to that peer undelivered,
   that data will be discarded.

同輩のどちらか任意な点で切断されると、その同輩から来たどんな傑出しているデータももう片方と、その後に通過されるでしょう、また、もう片方の接続はプロキシによって終えられるでしょう。 非提供されたその同輩への傑出しているデータがあると、そのデータは捨てられるでしょう。

6. Rationale for the use of a 4xx (client error) Status Code

6. 4xx(クライアント誤り)状態Codeの使用のための原理

   Reliable, interoperable negotiation of Upgrade features requires an
   unambiguous failure signal. The 426 Upgrade Required status code
   allows a server to definitively state the precise protocol extensions
   a given resource must be served with.

Upgradeの特徴の信頼できて、共同利用できる交渉は明白な失敗信号を必要とします。 426Upgrade Requiredステータスコードで、サーバは決定的に与えられたリソースに役立たなければならない正確なプロトコル拡大を述べることができます。

Khare & Lawrence            Standards Track                     [Page 7]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[7ページ]。

   It might at first appear that the response should have been some form
   of redirection (a 3xx code), by analogy to an old-style redirection
   to an https: URI.  User agents that do not understand Upgrade:
   preclude this.

初めに応答が何らかの形式のリダイレクションであるべきであった(3xxコード)ように見えるかもしれません、httpsへの古いスタイルリダイレクションへの類推で: ユリ。 Upgradeを理解していないユーザエージェント: これを排除してください。

   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
   user agent that did not recognize it would treat it as 300.  It would
   then properly look for a "Location" header in the response and
   attempt to repeat the request at the URL in that header field. Since
   it did not know to Upgrade to incorporate the TLS layer, it would at
   best fail again at the new URL.

「アップグレードが必要である」ように3xxコードを割り当ててあったと仮定してください。 それを認識しなかったユーザエージェントは300としてそれを扱うでしょう。 それは、次に、応答で適切に「位置」ヘッダーを探して、URLでそのヘッダーフィールドで要求を繰り返すのを試みるでしょう。 TLS層を組み込むのをUpgradeにおいて知らなかったので、それは再び新しいURLでせいぜい失敗するでしょう。

7. IANA Considerations

7. IANA問題

   IANA shall create registries for two name spaces, as described in BCP
   26 [10]:

IANAはBCP26[10]で説明されるように2つの名前空間への登録を作成するものとします:

   o  HTTP Status Codes
   o  HTTP Upgrade Tokens

o HTTP Status Codes o HTTP Upgrade Tokens

7.1 HTTP Status Code Registry

7.1 HTTPステータスコード登録

   The HTTP Status Code Registry defines the name space for the Status-
   Code token in the Status line of an HTTP response.  The initial
   values for this name space are those specified by:

HTTP Status Code RegistryはStatusコードトークンのためにHTTP応答のStatus系列でスペースという名前を定義します。 この名前スペースへの初期の値は以下によって指定されたものです。

   1.  Draft Standard for HTTP/1.1 [1]
   2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
   4.  Section 6 [defines 426]

1. HTTP/1.1[1]2の規格を作成してください。 ウェブはオーサリングとVersioning[4][420-424に、定義します]3を分配しました。 WebDAVは収集[5](処理中の作業)[425を定義する]4を進めました。 セクション6[426を定義します]

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1 [1].

これに加えられるべき値はフォームで論評する対象がIETF Applications Areaの中の標準化過程ドキュメントであったならスペースをSHOULDと命名します。 どんなそのようなものもSHOULDを記録します。'時代遅れに'か'アップデート'のどちらかの状態を通してHTTP/1.1[1]においてDraft Standardに起因してください。

7.2 HTTP Upgrade Token Registry

7.2 HTTPアップグレードトークン登録

   The HTTP Upgrade Token Registry defines the name space for product
   tokens used to identify protocols in the Upgrade HTTP header field.
   Each registered token should be associated with one or a set of
   specifications, and with contact information.

HTTP Upgrade Token RegistryはUpgrade HTTPヘッダ分野でプロトコルを特定するのに使用される製品トークンのためにスペースという名前を定義します。 それぞれの登録されたトークンは仕様の1かセット、および問い合わせ先に関連しているべきです。

   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
   the production for 'product':

HTTP/1.1[1]のためのDraft Standardは、これらのトークンが'製品'のための生産に従うと指定します:

Khare & Lawrence            Standards Track                     [Page 8]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[8ページ]。

      product         = token ["/" product-version]
      product-version = token

製品=トークン[「/」製品バージョン]製品バージョン=トークン

   Registrations should be allowed on a First Come First Served basis as
   described in BCP 26 [10]. These specifications need not be IETF
   documents or be subject to IESG review, but should obey the following
   rules:

登録証明書はBCP26[10]で説明されるようにFirst Come First Servedベースに許容されるべきです。 これらの仕様は、IETFドキュメントであるかまたはIESGレビューを受けることがある必要はありませんが、以下の規則に従うべきです:

   1.  A token, once registered, stays registered forever.
   2.  The registration MUST name a responsible party for the
       registration.
   3.  The registration MUST name a point of contact.
   4.  The registration MAY name the documentation required for the
       token.
   5.  The responsible party MAY change the registration at any time.
       The IANA will keep a record of all such changes, and make them
       available upon request.
   6.  The responsible party for the first registration of a "product"
       token MUST approve later registrations of a "version" token
       together with that "product" token before they can be registered.
   7.  If absolutely required, the IESG MAY reassign the responsibility
       for a token. This will normally only be used in the case when a
       responsible party cannot be contacted.

1. 一度登録されたトークンであり、滞在はいつまでも. 2を登録しました。 登録は責任があるパーティーを登録にちなんで命名しなければなりません。 3. 登録は連絡先を命名しなければなりません。 4. 登録はトークンに必要であるドキュメンテーションを命名するかもしれません。 5. 責任があるパーティーはいつでも、登録を変えるかもしれません。 IANAはそのようなすべての変化に関する記録をつけて、それらを要求のときに利用可能にするでしょう。 6. それらを登録できる前に「製品」トークンの最初の登録のための責任があるパーティーはその「製品」トークンと共に「バージョン」トークンの後の登録証明書を承認しなければなりません。 7. 絶対に必要であるなら、IESG MAYはトークンへの責任を再選任します。 責任があるパーティーに連絡できないときだけ、通常、これは場合に使用されるでしょう。

   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol [6].

この仕様はプロトコルトークン「TLSプロトコル[6]によって指定されたプロトコルのための識別子としてのTLS/1インチ」を定義します。

   It is NOT required that specifications for upgrade tokens be made
   publicly available, but the contact information for the registration
   SHOULD be.

公的にアップグレードトークンのための仕様を利用可能にするのが必要でなく、登録のための唯一の問い合わせ先はSHOULDです。いてください。

8. Security Considerations

8. セキュリティ問題

   The potential for a man-in-the-middle attack (deleting the Upgrade
   header) remains the same as current, mixed http/https practice:

介入者攻撃(Upgradeヘッダーを削除する)の可能性は現在の、そして、混ぜられたhttp/https習慣と同じままで残っています:

   o  Removing the Upgrade header is similar to rewriting web pages to
      change https:// links to http:// links.
   o  The risk is only present if the server is willing to vend such
      information over both a secure and an insecure channel in the
      first place.
   o  If the client knows for a fact that a server is TLS-compliant, it
      can insist on it by only sending an Upgrade request with a no-op
      method like OPTIONS.
   o  Finally, as the https: specification warns, "users should
      carefully examine the certificate presented by the server to
      determine if it meets their expectations".

o Upgradeヘッダーを取り除くのはhttp://リンクへのhttps://リンクを変えるためにウェブページを書き直すのと同様です。○ サーバが、第一に両方の安全で不安定なチャンネルの上にそのような情報を販売しても構わないと思っている場合にだけ、リスクは存在しています。○ クライアントのIfは、サーバがTLS対応であることを事実として知って、OPTIONS o FinallyのようなオプアートがないメソッドでUpgrade要求を送るだけでそれを主張できます、httpsとして: 「ユーザは慎重にサーバによって提示された、それが彼らの期待に合うかどうか決定した証明書を調べるべきです。」と、仕様は警告します。

Khare & Lawrence            Standards Track                     [Page 9]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[9ページ]。

   Furthermore, for clients that do not explicitly try to invoke TLS,
   servers can use the Upgrade header in any response other than 101 or
   426 to advertise TLS compliance. Since TLS compliance should be
   considered a feature of the server and not the resource at hand, it
   should be sufficient to send it once, and let clients cache that
   fact.

その上、明らかにTLSを呼び出そうとしないクライアントに関して、サーバは、TLSコンプライアンスの広告を出すのに101か426以外のどんな応答にもUpgradeヘッダーを使用できます。 TLSコンプライアンスが手元のリソースではなく、サーバの特徴であると考えられるべきであるので、一度それを送って、クライアントにその事実をキャッシュさせるのは、十分であるべきです。

8.1 Implications for the https: URI Scheme

httpsのための8.1の含意: URI体系

   While nothing in this memo affects the definition of the 'https' URI
   scheme, widespread adoption of this mechanism for HyperText content
   could use 'http' to identify both secure and non-secure resources.

このメモによる何も'https'URI体系の定義に影響していない間、HyperText内容のためのこのメカニズムの広範囲の採用は、安全なものと同様に非安全なリソースを特定するのに'http'を使用するかもしれません。

   The choice of what security characteristics are required on the
   connection is left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the security of the network such as 'TLS required
   on all POST operations not on my local net', or servers may apply
   resource access rules such as 'the FORM on this page must be served
   and submitted using TLS'.

選択はどんなセキュリティの特性が接続のときに必要であるかをクライアントとサーバに残されます。これは、何れの当事者がこの決断をするのにおいて利用可能などんな情報も使用するのを許容します。 例えば、ユーザエージェントが'TLSが地元のネットにおけるすべてのポストの操作のときに必要であることなど'のネットワークのセキュリティのユーザー選択設定か情報を当てにするかもしれませんか、またはサーバは'TLSを使用することでこのページのFORMに役立って、提出などでなければならないことなど'のリソースアクセス規則を当てはまるかもしれません。

8.2 Security Considerations for CONNECT

8.2のセキュリティ問題、接続

   A generic TCP tunnel is fraught with security risks. First, such
   authorization should be limited to a small number of known ports.
   The Upgrade: mechanism defined here only requires onward tunneling at
   port 80. Second, since tunneled data is opaque to the proxy, there
   are additional risks to tunneling to other well-known or reserved
   ports. A putative HTTP client CONNECTing to port 25 could relay spam
   via SMTP, for example.

ジェネリックTCPトンネルはセキュリティリスクについて悲惨です。 まず最初に、そのような承認は少ない数の知られているポートに制限されるべきです。 アップグレード: ここで定義されたメカニズムはポート80で前方のトンネリングを必要とするだけです。 2番目に、プロキシに、トンネルを堀られたデータが不明瞭であるので、他のよく知られるか予約されたポートにトンネルを堀ることへの追加リスクがあります。 25を移植する推定のHTTPクライアントCONNECTingは例えば、SMTPを通してスパムをリレーできました。

References

参照

   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

[1] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
        Syntax", RFC 2396, August 1998.

[2]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「URIジェネリック構文」、RFC2396、1998年8月。

   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[3] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。

   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
        "Web Distributed Authoring and Versioning", RFC 2518, February
        1999.

[4] Goland、Y.、ホワイトヘッド、E.、Faizi、A.、カーター、S.、およびD.ジェンセン、「ウェブはオーサリングとVersioningを分配しました」、RFC2518、1999年2月。

Khare & Lawrence            Standards Track                    [Page 10]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[10ページ]。

   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
        Protocol",  Work In Progress.

[5]Slein、J.、ホワイトヘッド、E.J.、他、「WebDAVの高度な収集プロトコル」、Work In Progress。

   [6]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
        1999.

[6]DierksとT.とC.アレン、「TLSプロトコル」、RFC2246、1999年1月。

   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
        1999.

[7] エリオとR.とバトラーとS.とムーアとP.とR.ターナー、「プロトコル/1.0に以下を印刷するインターネット」 「コード化と輸送」、RFC2565、4月1999日

   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)

[8]Luotonen、A.、「トンネリングTCPはウェブプロキシサーバを通してプロトコルを基礎づけた」Work In Progress。 (利用可能も: Luotonen、アリ。 ウェブProxyサーバ、新米のホール、1997ISBN: 0136806120。)

   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
        1999.

[9] M. ローズ、RFC2629、「XMLを使用することでI-DsとRFCsに書く」6月1999日

   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[10]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[11] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Authors' Addresses

作者のアドレス

   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

Rohit Khare4K仲間/UCアーバイン3207パロヴェルデカリフォルニア92612アーバイン(米国)

   Phone: +1 626 806 7574
   EMail: rohit@4K-associates.com
   URI:   http://www.4K-associates.com/

以下に電話をしてください。 +1 7574年の626 806メール: rohit@4K-associates.com ユリ: http://www.4K-associates.com/

   Scott Lawrence
   Agranat Systems, Inc.
   5 Clocktower Place
   Suite 400
   Maynard, MA  01754
   US

スコットローレンスAgranat Systems Inc.5Clocktower場所Suite400MA01754メイナード(米国)

   Phone: +1 978 461 0888
   EMail: lawrence@agranat.com
   URI:   http://www.agranat.com/

以下に電話をしてください。 +1 0888年の978 461メール: lawrence@agranat.com ユリ: http://www.agranat.com/

Khare & Lawrence            Standards Track                    [Page 11]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[11ページ]。

Appendix A. Acknowledgments

付録A.承認

   The CONNECT method was originally described in a Work in Progress
   titled, "Tunneling TCP based protocols through Web proxy servers",
   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
   widely implemented by HTTP proxies, but was never made a part of any
   IETF Standards Track document. The method name CONNECT was reserved,
   but not defined in [1].

CONNECT方法は元々「ウェブプロキシサーバを通してTCPのベースのプロトコルにトンネルを堀っ」て、題をつけられたProgressのWorkで説明されました、ネットスケープ社のアリLuotonenによる[8]。 それはHTTPプロキシによって広く実行されましたが、決して人工のaでないのは何かIETF Standards Trackドキュメントの一部でしたか? CONNECTという方法名は、予約されましたが、[1]では定義されませんでした。

   The definition provided here is derived directly from that earlier
   memo, with some editorial changes and conformance to the stylistic
   conventions since established in other HTTP specifications.

ここに提供された定義は直接その以前のメモから引き出されます、他のHTTP仕様に設立されて以来の文体上のコンベンションへの何らかの編集の変化と順応で。

   Additional Thanks to:

追加、以下にありがとうございます。

   o  Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP.
   o  Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.
   o  Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.
   o  Marshall Rose, for the xml2rfc document type description and tools
      [9].
   o  Jim Whitehead, for sorting out the current range of available HTTP
      status codes.
   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
      mechanism pointed out a hop-by-hop Upgrade still requires
      tunneling.
   o  Harald Alvestrand for improvements to the token registration
      rules.

o Upgradeの後ろに原理がある支援のためのESMTP oロイFieldingのためのSTARTTLSコマンド拡張子に対する彼の仕事のためのポール・ホフマン: OPTIONS○ 既存のhttpsを標準化することに対する彼の仕事のためのエリック・レスコラとの相互作用: 利用可能なHTTPステータスコード○ Henrik Frystykニールセンの現在の範囲を整理するために. ○ xml2rfcドキュメント型記述のためのマーシャル・ローズとツール[9]○ ジム・ホワイトヘッドと比較するために練習してください。Mandatory拡大メカニズムへのニールセンの作業は、ホップごとのUpgradeが、トンネルを堀るのをまだ必要としていると指摘しました。象徴登録への改良のためのoハラルドAlvestrandは統治します。

Khare & Lawrence            Standards Track                    [Page 12]

RFC 2817                  HTTP Upgrade to TLS                   May 2000

KhareとローレンスStandardsは2000年5月にRFC2817HTTPアップグレードをTLSに追跡します[12ページ]。

Full Copyright Statement

完全な著作権宣言文

   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機能のための基金は現在、インターネット協会によって提供されます。

Khare & Lawrence            Standards Track                    [Page 13]

Khareとローレンス標準化過程[13ページ]