RFC2756 日本語訳
2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT=32176 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Vixie
Request for Comments: 2756 ISC
Category: Experimental D. Wessels
NLANR
January 2000
Vixieがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2756年のISCカテゴリ: 実験的なD.ウェセルズNLANR2000年1月
Hyper Text Caching Protocol (HTCP/0.0)
プロトコルをキャッシュする超-テキスト(HTCP/0.0)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions.
このドキュメントはHTCPについて説明します、HTTPキャッシュとキャッシュされたデータを発見するためのプロトコル、HTTPキャッシュのセットを経営していて、キャッシュ活動をモニターして。 これは実験プロトコル、これらの機能を実行するといういくつかの提案の中の1です。
1. Definitions, Rationale and Scope
1. 定義、原理、および範囲
1.1. HTTP/1.1 (see [RFC2616]) permits the transfer of web objects from "origin servers," possibly via "proxies" (which are allowed under some circumstances to "cache" such objects for subsequent reuse) to "clients" which consume the object in some way, usually by displaying it as part of a "web page." HTTP/1.0 and later permit "headers" to be included in a request and/or a response, thus expanding upon the HTTP/0.9 (and earlier) behaviour of specifying only a URI in the request and offering only a body in the response.
1.1. HTTP/1.1([RFC2616]を見る)は何らかの方法で物を消費することによると「プロキシ」を通した「起源サーバ」(その後の再利用のためにそのような物を「キャッシュすること」がいくつかの状況で許容されている)から「クライアント」までのウェブ物の転送を可能にします、通常、「ウェブページ」の一部としてそれを表示することによって。 HTTP/1.0以降は、「ヘッダー」が要求、そして/または、応答に含まれていることを許可します、その結果、要求でURIだけを指定して、応答でボディーだけを提供するHTTP/0.9(より早くに)のふるまいのときに、広がります。
1.2. ICP (see [RFC2186]) permits caches to be queried as to their content, usually by other caches who are hoping to avoid an expensive fetch from a distant origin server. ICP was designed with HTTP/0.9 in mind, such that only the URI (without any headers) is used when describing cached content, and the possibility of multiple compatible bodies for the same URI had not yet been imagined.
1.2. ICP([RFC2186]を見る)は、キャッシュがそれらの内容と、通常他のキャッシュのように質問されて、遠方の起源サーバから高価なフェッチを避けることを望んでいて. ICPはHTTP/0.9で念頭に設計されました、キャッシュされた内容について説明するとき、URI(少しもヘッダーのない)だけが使用されていて、同じURIのための複数のコンパチブルボディーの可能性がまだ想像されていなかったようにことであることを可能にします。
Vixie & Wessels Experimental [Page 1] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[1ページ]RFC2756超-テキスト
1.3. This document specifies a Hyper Text Caching Protocol (HTCP) which permits full request and response headers to be used in cache management, and expands the domain of cache management to include monitoring a remote cache's additions and deletions, requesting immediate deletions, and sending hints about web objects such as the third party locations of cacheable objects or the measured uncacheability or unavailability of web objects.
1.3. このドキュメントは完全な要求と応答ヘッダがキャッシュ管理に使用されることを許可して、リモートキャッシュの追加と削除をモニターするのを含むようにキャッシュ管理のドメインを広くするHyper Text Cachingプロトコル(HTCP)を指定します、ウェブ物の測定「キャッシュ-可能」物の第三者位置、uncacheabilityまたは使用不能などのウェブ物に関して即座の削除を要求して、ヒントを送って。
2. HTCP Protocol
2. HTCPプロトコル
2.1. All multi-octet HTCP protocol elements are transmitted in network byte order. All RESERVED fields should be set to binary zero by senders and left unexamined by receivers. Headers must be presented with the CRLF line termination, as in HTTP.
2.1. すべてのマルチ八重奏HTCPプロトコル要素がネットワークバイトオーダーで伝えられます。 すべてのRESERVED野原が、送付者によって2進のゼロに設定されて、受信機によって非審査されるように残されるべきです。 HTTPのようにCRLFライン・ターミネーションをヘッダーに与えなければなりません。
2.2. Any hostnames specified should be compatible between sender and receiver, such that if a private naming scheme (such as HOSTS.TXT or NIS) is in use, names depending on such schemes will only be sent to HTCP neighbors who are known to participate in said schemes. Raw addresses (dotted quad IPv4, or colon-format IPv6) are universal, as are public DNS names. Use of private names or addresses will require special operational care.
2.2. 指定されたどんなホスト名も送付者と受信機の間で互換性があるべきです、個人的な命名計画(HOSTS.TXTかNISなどの)が使用中である場合にだけ、前述の計画に参加するのが知られているHTCP隣人にそのような計画による名前を送るように。 生のアドレス(回路IPv4、またはコロン形式IPv6に点を打たせる)は公共のDNS名のように普遍的です。 個人的な名前かアドレスの使用は特別な操作上の注意を必要とするでしょう。
2.3. HTCP messages may be sent as UDP datagrams, or over TCP connections. UDP must be supported. HTCP agents must not be isolated from NETWORK failures and delays. An HTCP agent should be prepared to act in useful ways when no response is forthcoming, or when responses are delayed or reordered or damaged. TCP is optional and is expected to be used only for protocol debugging. The IANA has assigned port 4827 as the standard TCP and UDP port number for HTCP.
2.3. UDPデータグラムか、TCP接続の上にHTCPメッセージを送るかもしれません。 UDPを支持しなければなりません。 NETWORKの故障と遅れからHTCPエージェントを隔離してはいけません。 応答がどんな応答も用意されていないか、遅らせられるか、再命令されるか、または破損するとき、HTCPエージェントは役に立つ方法で行動する用意ができているべきです。 TCPは任意であり、プロトコルデバッグにだけ使用されると予想されます。 IANAはHTCPのために標準のTCPとしての4827をポートに割り当てて、ポートナンバーをUDPに割り当てました。
2.4. A set of configuration variables concerning transport characteristics should be maintained for each agent which is capable of initiating HTCP transactions, perhaps with a set of per-agent global defaults. These variables are:
2.4. 1セットの輸送の特性に関する構成変数は各エージェントのために維持されるべきです(HTCP取引を開始できます)、恐らく1セットの1エージェントあたりのグローバルなデフォルトで。 これらの変数は以下の通りです。
Maximum number of unacknowledged transactions before a "failure" is imputed.
「失敗」の前の最大数の不承認の取引は転嫁されます。
Maximum interval without a response to some transaction before a "failure" is imputed.
「失敗」の前の何らかの取引への応答のない最大の間隔は転嫁されます。
Minimum interval before trying a new transaction after a failure.
失敗の後に新しい取引を試みる前の最小間隔。
Vixie & Wessels Experimental [Page 2] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[2ページ]RFC2756超-テキスト
2.5. An HTCP Message has the following general format:
2.5. HTCP Messageには、以下の一般形式があります:
+---------------------+ | HEADER | tells message length and protocol versions +---------------------+ | DATA | HTCP message (varies per major version number) +---------------------+ | AUTH | optional authentication for transaction +---------------------+
+---------------------+ | ヘッダー| メッセージ長とプロトコルバージョン+を言います。---------------------+ | データ| HTCPメッセージ(メジャーバージョン番号単位で変える)+---------------------+ | AUTH| 取引+のための任意の認証---------------------+
2.6. An HTCP/*.* HEADER has the following format:
2.6. . *HEADERが以下にフォーマットさせるHTCP/*:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+ + + + + + + + + + + + + + + + +
2: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | MAJOR | MINOR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 長さ| + + + + + + + + + + + + + + + + + 2: | 長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | 少佐| 未成年者| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the message length, inclusive of all header and data
octets, including the LENGTH field itself. This field will
be equal to the datagram payload size ("record length") if a
datagram protocol is in use, and can include padding, i.e.,
not all octets of the message need be used in the DATA and
AUTH sections.
LENGTHはすべてのヘッダーとデータ八重奏を包含LENGTH分野自体を含むメッセージ長です。 データグラムプロトコルが使用中であるなら、この分野はデータグラムペイロードサイズ(「レコード長」)と等しくなるでしょう、そして、DATAとAUTH部でインクルード詰め物、すなわち、メッセージの必要性のすべての八重奏は使用できるというわけではありませんか?
MAJOR is the major version number (0 for this specification). The
DATA section of an HTCP message need not be upward or
downward compatible between different major version numbers.
メージャーはメジャーバージョン番号(この仕様のための0)です。 HTCPメッセージのDATA部は、異なったメジャーバージョン番号の間で互換性があった状態で上向きであるか、または下向きである必要はありません。
MINOR is the minor version number (0 for this specification).
Feature levels and interpretation rules can vary depending on
this field, in particular RESERVED fields can take on new
(though optional) meaning in successive minor version numbers
within the same major version number.
MINORはマイナーバージョン番号(この仕様のための0)です。 このフィールドによって、特徴レベルと解釈規則は異なることができます、分野が同じメジャーバージョン番号の中で連続したマイナーバージョン番号における新しい(任意ですが)意味で取ることができる特定のRESERVEDで。
2.6.1. It is expected that an HTCP initiator will know the version number of a prospective HTCP responder, or that the initiator will probe using declining values for MINOR and MAJOR (beginning with the highest locally supported value) and locally cache the probed version number of the responder.
2.6.1. 創始者がHTCP創始者が将来のHTCP応答者のバージョン番号を知るか、MINORとメージャー(最も高い局所的に支持された値で、始まる)に減退している値を使用することで調べて、または局所的に応答者の調べられたバージョン番号をキャッシュすると予想されます。
2.6.2. Higher MAJOR numbers are to be preferred, as are higher MINOR numbers within a particular MAJOR number.
2.6.2. より大きいメージャー番号は、より大きいMINOR番号のように特定のメージャー番号の中で好まれることです。
Vixie & Wessels Experimental [Page 3] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[3ページ]RFC2756超-テキスト
2.7. An HTCP/0.* DATA has the following structure:
2.7. HTCP/0.*DATAには、以下の構造があります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPCODE | RESPONSE | RESERVED |F1 |RR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | TRANS-ID |
+ + + + + + + + + + + + + + + + +
6: | TRANS-ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
/ OP-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | OPCODE| 応答| 予約されます。|F1|RR| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | 移-ID| + + + + + + + + + + + + + + + + + 6: | 移-ID| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 8: | | /オプアートデータ///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the number of octets of the message which are reserved
for the DATA section, including the LENGTH field itself.
This number can include padding, i.e., not all octets
reserved by LENGTH need be used in OP-DATA.
LENGTHはDATA部へのメッセージの控えられる八重奏の数です、LENGTH分野自体を含んでいて。 この数は、そっと歩くのを含むことができます、すなわち、LENGTHによって控えられたというわけではないすべての八重奏がOP-DATAで使用されなければなりません。
OPCODE is the operation code of an HTCP transaction. An HTCP
transaction can consist of multiple HTCP messages, e.g., a
request (sent by the initiator), or a response (sent by the
responder).
OPCODEはHTCP取引の命令コードです。 HTCP取引は複数のHTCPメッセージ、例えば、要求(創始者で、発信する)、または応答(応答者で、発信する)から成ることができます。
RESPONSE is a numeric code indicating the success or failure of a
transaction. It should be set to zero (0) by requestors
and ignored by responders. Each operation has its own set
of response codes, which are described later. The overall
message has a set of response codes which are as follows:
RESPONSEは取引の成否を示す数字コードです。 それは、要請者で(0)のゼロを合わせるように設定されて、応答者によって無視されるべきです。 各操作には、それ自身の応答コードのセットがあります。(コードは後で説明されます)。 総合的なメッセージには、1セットの以下の通りである応答コードがあります:
0 authentication wasn't used but is required
1 authentication was used but unsatisfactorily
2 opcode not implemented
3 major version not supported
4 minor version not supported (major version is ok)
5 inappropriate, disallowed, or undesirable opcode
0 認証は、使用されませんでしたが、必要な1つの認証が使用されたということですが、不満足に、実行された3主要なバージョンではなく、2opcodeが支持された(主要なバージョンは間違いありません)5不適当であるか、禁じられたか、望ましくないopcodeではなく、4の小さい方のバージョンを支持しませんでした。
The above response codes all indicate errors and all depend
for their visibility on MO=1 (as specified below).
上の応答コードは、誤りをすべて示して、MO=1(以下で指定されるとしての)のそれらの目に見えることのためにすべて依存します。
RR is a flag indicating whether this message is a request (0)
or response (1).
RRはこのメッセージが要求(0)かそれとも応答(1)であるかを示す旗です。
Vixie & Wessels Experimental [Page 4] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[4ページ]RFC2756超-テキスト
F1 is overloaded such that it is used differently by
requestors than by responders. If RR=0, then F1 is defined
as RD. If RR=1, then F1 is defined as MO.
F1が積みすぎられるので、それは応答者より要請者によって異なって使用されます。 RR=0であるなら、F1はRDと定義されます。 RR=1であるなら、F1はMOと定義されます。
RD is a flag which if set to 1 means that a response is
desired. Some OPCODEs require RD to be set to 1 to be
meaningful.
RDは1に設定されるなら応答が望まれていることを意味する旗です。 いくつかのOPCODEsが、RDが重要であるように1に用意ができているのを必要とします。
MO (em-oh) is a flag which indicates whether the RESPONSE code
is to be interpreted as a response to the overall message
(fixed fields in DATA or any field of AUTH) [MO=1] or as a
response to fields in the OP-DATA [MO=0].
MO、(em、-、おお、)、RESPONSEコードが解釈されるかどうかことであることを示す旗は総合的なメッセージ(DATAの固定分野かAUTHのどんな分野も)[MO=1]かOP-DATAの分野への応答[MO=0]としたa応答ですか?
TRANS-ID is a 32-bit value which when combined with the initiator's
network address, uniquely identifies this HTCP transaction.
Care should be taken not to reuse TRANS-ID's within the
life-time of a UDP datagram.
TRANS-IDは唯一創始者のネットワーク・アドレスに結合されるとこのHTCP取引を特定する32ビットの値です。 UDPデータグラムの生涯中にIDのTRANS-ものを再利用しないように注意するべきです。
OP-DATA is opcode-dependent and is defined below, per opcode.
OP-DATAはopcode依存していて、以下でopcode単位で定義されます。
2.8. An HTCP/0.0 AUTH has the following structure:
2.8. HTCP/0.0 AUTHには、以下の構造があります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | SIG-TIME |
+ + + + + + + + + + + + + + + + +
4: | SIG-TIME |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SIG-EXPIRE |
+ + + + + + + + + + + + + + + + +
8: | SIG-EXPIRE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10: | |
/ KEY-NAME /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
n: | |
/ SIGNATURE /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | SIG時間| + + + + + + + + + + + + + + + + + 4: | SIG時間| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 6: | SIGで期限が切れてください。| + + + + + + + + + + + + + + + + + 8: | SIGで期限が切れてください。| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 10: | | /主要な名///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ n: | | /署名///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Vixie & Wessels Experimental [Page 5] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[5ページ]RFC2756超-テキスト
LENGTH is the number of octets used by the AUTH, including the
LENGTH field itself. If the optional AUTH is not being
transmitted, this field should be set to 2 (two). LENGTH
can include padding, which means that not all octets
reserved by LENGTH will necessarily be consumed by
SIGNATURE.
LENGTHはLENGTH分野自体を含むAUTHによって使用された八重奏の数です。 任意のAUTHが伝えられていないなら、この分野は2(2)に設定されるべきです。 LENGTHは、そっと歩くのを含むことができます(LENGTHによって控えられたというわけではないすべての八重奏が必ずSIGNATUREによって消費されることを意味します)。
SIG-TIME is an unsigned binary count of the number of seconds
since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
generated.
SIGNATUREが00:00:00 1970年1月1日UTC時間に発生するので、SIGタイム誌は秒数の無記名の2進のカウントです。
SIG-EXPIRE is an unsigned binary count of the number of seconds
since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
considered to have expired.
SIG-EXPIREはSIGNATUREが期限が切れたと考えられる00:00:00 1970年1月1日UTC時間の秒数の無記名の2進のカウントです。
KEY-NAME is a COUNTSTR [3.1] which specifies the name of a shared
secret. (Each HTCP implementation is expected to allow
configuration of several shared secrets, each of which
will have a name.)
KEY-NAMEは共有秘密キーの名前を指定するCOUNTSTR[3.1]です。 (それぞれのHTCP実現がいくつかの共有秘密キーの構成を許すと予想されます。)それのそれぞれには、名前が共有秘密キーのためにあるでしょう。
SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see
[RFC 2104]), with a B value of 64, of the following
elements, each of which is digested in its "on the wire"
format, including transmitted padding if any is covered
by a field's associated LENGTH:
SIGNATUREはHMAC-MD5ダイジェストを保持するCOUNTSTR[3.1]です([RFC2104]を見てください)、それのそれぞれがそれが「ワイヤ」であるという形式で読みこなされる64、以下の要素のB価値で、いずれかフィールドの関連LENGTHで覆われているなら伝えられた詰め物を含んでいて:
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]
IP SRC ADDR[4つの八重奏]IP SRC PORT[2つの八重奏]IP DST ADDR[4つの八重奏]IP DST PORT[2つの八重奏]HTCP MAJORバージョン番号[1つの八重奏]HTCP MINORバージョン番号[1つの八重奏]SIGタイム誌[4つの八重奏]SIG-EXPIRE[4つの八重奏]のHTCP DATAの[可変]のKEY-NAME、(全体のCOUNTSTR[3.1])[可変]です。
2.8.1. Shared secrets should be cryptorandomly generated and should be at least a few hundred octets in size.
2.8.1. 共有秘密キーは、cryptorandomlyに発生するべきであり、サイズが少なくともいくつかの100の八重奏であるべきです。
3. Data Types
3. データ型
HTCP/0.* data types are defined as follows:
HTCP/0.*データ型は以下の通り定義されます:
Vixie & Wessels Experimental [Page 6] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[6ページ]RFC2756超-テキスト
3.1. COUNTSTR is a counted string whose format is:
3.1. COUNTSTRは形式がある数えられたストリングです:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ TEXT /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | | /テキスト///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the number of octets which will follow in TEXT. This
field is *not* self-inclusive as is the case with other HTCP
LENGTH fields.
LENGTHはTEXTで続く八重奏の数です。 この分野は*ではなく、他のHTCP LENGTH分野があるケースのように自己包括的な*です。
TEXT is a stream of uninterpreted octets, usually ISO8859-1
"characters".
通常、TEXTは非解釈された八重奏の流れ、ISO8859-1「キャラクタ」です。
3.2. SPECIFIER is used with the TST and CLR request messages, defined below. Its format is:
3.2. SPECIFIERは以下で定義されたTSTとCLR要求メッセージと共に使用されます。 形式は以下の通りです。
+---------------------+
| METHOD | : COUNTSTR
+---------------------+
| URI | : COUNTSTR
+---------------------+
| VERSION | : COUNTSTR
+---------------------+
| REQ-HDRS | : COUNTSTR
+---------------------+
+---------------------+ | 方法| : COUNTSTR+---------------------+ | URI| : COUNTSTR+---------------------+ | バージョン| : COUNTSTR+---------------------+ | REQ-HDRS| : COUNTSTR+---------------------+
METHOD (Since HTCP only returns headers, methods GET and HEAD are
equivalent.)
方法(HTCPがヘッダーを返すだけであるので、方法のGETとHEADは同等です。)
URI (If the URI is a URL, it should always include a ":"<port>
specifier, but in its absense, port 80 should be imputed by
a receiver.)
URI(「URIがURLであるなら、いつもa」を含むべきです:、「<が>特許説明書の作成書を移植しますが、absenseでは、ポート80が受信機によって転嫁されるべきである、)、」
VERSION is an entire HTTP version string such as" HTTP/1.1".
VERSION strings with prefixes other than "HTTP/" or with
version numbers less than "1.1" are outside the domain of
this specification.
何HTTP/1.1インチも「バージョンはバージョンがそのようなものを結ぶ全体のHTTPです」。 バージョンは「この仕様のドメインの外に1.1インチがある」ほど「HTTP/」以外の接頭語かバージョンで数を結びません。
REQ-HDRS are those presented by an HTTP initiator. These headers
should include end-to-end but NOT hop-by-hop headers, and
they can be canonicalized (aggregation of "Accept:" is
permitted, for example.)
REQ-HDRSはHTTP創始者によって提示されたものです。 これらのヘッダーはホップごとのヘッダーではなく、終わらせる終わりを入れるべきです、そして、彼らはcanonicalizedされることができます。(例えば、「受け入れてください」の集合は受入れられます。)
Vixie & Wessels Experimental [Page 7] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[7ページ]RFC2756超-テキスト
3.3. DETAIL is used with the TST response message, defined below. Its format is:
3.3. DETAILは以下で定義されたTST応答メッセージと共に使用されます。 形式は以下の通りです。
+---------------------+
| RESP-HDRS | : COUNTSTR
+---------------------+
| ENTITY-HDRS | : COUNTSTR
+---------------------+
| CACHE-HDRS | : COUNTSTR
+---------------------+
+---------------------+ | RESP-HDRS| : COUNTSTR+---------------------+ | 実体-HDRS| : COUNTSTR+---------------------+ | キャッシュ-HDRS| : COUNTSTR+---------------------+
3.4. IDENTITY is used with the MON request and SET response message, defined below. Its format is:
3.4. IDENTITYは以下で定義された月曜日の要求とSET応答メッセージと共に使用されます。 形式は以下の通りです。
+---------------------+
| SPECIFIER |
+---------------------+
| DETAIL |
+---------------------+
+---------------------+ | 特許説明書の作成書| +---------------------+ | 詳細| +---------------------+
4. Cache Headers
4. キャッシュヘッダー
HTCP/0.0 CACHE-HDRS consist of zero or more of the following headers:
HTCP/0.0 CACHE-HDRSは以下のヘッダーのゼロか以上から成ります:
Cache-Vary: <header-name> ...
The sender of this header has learned that content varies on a set
of headers different from the set given in the object's Vary:
header. Cache-Vary:, if present, overrides the object's Vary:
header.
キャッシュで異なってください: <ヘッダー名の>… このヘッダーの送付者は、内容が物のVaryで与えられているセットと異なったヘッダーのセットで異なることを学びました: ヘッダー。 物のオーバーライドVary、存在しているなら、以下をキャッシュで変えてください: ヘッダー。
Cache-Location: <cache-hostname>:<port> ...
The sender of this header has learned of one or more proxy caches
who are holding a copy of this object. Probing these caches with
HTCP may result in discovery of new, close-by (preferrable to
current) HTCP neighbors.
キャッシュ位置: <キャッシュホスト名>: <ポート>… このヘッダーの送付者はこの物のコピーを持っている1つ以上のプロキシキャッシュを知っていました。 HTCPと共にこれらのキャッシュを調べると、新しくて、間近(電流に「前-フェリー-可能」な)のHTCP隣人の発見はもたらされるかもしれません。
Cache-Policy: [no-cache] [no-share] [no-cache-cookie]
The sender of this header has learned that the object's caching
policy has more detail than is given in its response headers.
キャッシュ方針: [キャッシュしません] [共有しません] [キャッシュクッキーがありません] このヘッダーの送付者は、物のキャッシング方針にはその他の詳細が応答ヘッダで与えるよりあることを学びました。
no-cache means that it is uncacheable (no reason given),
but may be shareable between simultaneous
requestors.
キャッシュがない手段は、(あげられなかった理由全く)を「非-キャッシュ-可能」しますが、同時の要請者の間で共有可能であるかもしれません。
no-share means that it is unshareable (no reason given),
and per-requestor tunnelling is always
required).
シェアがない手段が(あげられなかった理由全く)を非共有可能して、1要請者あたりのトンネルがいつも必要である、)
Vixie & Wessels Experimental [Page 8] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[8ページ]RFC2756超-テキスト
no-cache-cookie means that the content could change as a result
of different, missing, or even random cookies
being included in the request headers, and that
caching is inadvisable.
どんなキャッシュクッキーも内容が要求ヘッダーに含まれている異なったか、なくなったか、無作為のクッキーさえの結果、変化できて、キャッシュが勧められないことを意味しません。
Cache-Flags: [incomplete]
The sender of this header has modified the object's caching policy
locally, such that requesters may need to treat this response
specially, i.e., not necessarily in accordance with the object's
actual policy.
キャッシュ旗: [不完全な] このヘッダーの送付者は局所的に物のキャッシング方針を変更しました、リクエスタが、すなわち、物の実際の方針によると、特に、必ずないこの応答を扱う必要があることができるように。
incomplete means that the response headers and/or entity headers
given in this response are not known to be complete,
and may not be suitable for use as a cache key.
この応答で与えられている応答ヘッダ、そして/または、実体ヘッダーがそうである不完全な手段は、完全であることを知らないで、またキャッシュキーとして使用に適していないかもしれません。
Cache-Expiry: <date>
The sender of this header has learned that this object should be
considered to have expired at a time different than that indicated
by its response headers. The format is the same as HTTP/1.1
Expires:.
キャッシュ満期: このヘッダーの送付者の<日付>は、この物が応答ヘッダによって示されたそれからいろいろな時間に期限が切れたと考えられるべきであることを学びました。 形式はHTTP/1.1Expiresと同じです:
Cache-MD5: <discovered content MD5>
The sender of this header has computed an MD5 checksum for this
object which is either different from that given in the object's
Content-MD5: header, or is being supplied since the object has no
Content-MD5 header. The format is the same as HTTP/1.1 Content-
MD5:.
キャッシュ-MD5: <は、このヘッダーの送付者の満足しているMD5>がこの物のContent-MD5で与えられたそれと異なった物のためにMD5チェックサムを計算したと発見しました: ヘッダー、物にはContent-MD5ヘッダーが全くないので供給するのは、そうです。 形式はHTTP/1.1Content MD5と同じです:
Cache-to-Origin: <origin> <rtt> <samples> <hops>
The sender of this header has measured the round trip time to an
origin server (given as a hostname or literal address). The <rtt>
is the average number of seconds, expressed as decimal ASCII with
arbitrary precision and no exponent. <Samples> is the number of
RTT samples which have had input to this average. <Hops> is the
number of routers between the cache and the origin, expressed as
decimal ASCII with arbitrary precision and no exponent, or 0 if
the cache doesn't know.
起源に以下をキャッシュしてください。 このヘッダーの送付者の>にはある<起源><rtt><サンプル><ホップは起源サーバ(ホスト名か文字通りのアドレスとして、与える)に周遊旅行時間を測定しました。 <rtt>は任意の精度にもかかわらず、解説者がないと共に10進ASCIIとして表された平均した秒数です。 <サンプル>は入力をこれに平均するようにしたRTTのサンプルの数です。 キャッシュが知らないなら10進ASCIIとして任意の精度にもかかわらず、解説者、またはどんな0でも言い表されないで、<ホップス>はキャッシュと起源の間のルータの数です。
Vixie & Wessels Experimental [Page 9] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[9ページ]RFC2756超-テキスト
6. HTCP Operations
6. HTCP操作
HTCP/0.* opcodes and their respective OP-DATA are defined below:
HTCP/0.*opcodesとそれらのそれぞれのOP-DATAは以下で定義されます:
6.1. NOP (OPCODE 0):
6.1. NOP(OPCODE0):
This is an HTCP-level "ping." Responders are encouraged to process NOP's with minimum delay since the requestor may be using the NOP RTT (round trip time) for configuration or mapping purposes. The RESPONSE code for a NOP is always zero (0). There is no OP-DATA for a NOP. NOP requests with RD=0 cause no processing to occur at all.
これは「ピング」というHTCP-レベルです。 要請者が構成に、NOP RTT(周遊旅行時間)を使用するか、または目的を写像しているかもしれないので応答者が最小の遅れでNOPのものを処理するよう奨励されます。 NOPのためのRESPONSEコードはいつも(0)であるというわけではありません。 NOPのためのOP-DATAが全くありません。 RD=0とのNOP要求で、処理は全く起こりません。
6.2. TST (OPCODE 1):
6.2. TST(OPCODE1):
Test for the presence of a specified content entity in a proxy cache. TST requests with RD=0 cause no processing to occur at all.
プロキシキャッシュにおける、指定された満足している実体の存在がないかどうかテストしてください。 RD=0とのTST要求で、処理は全く起こりません。
TST requests have the following OP-DATA:
TST要求には、以下のOP-DATAがあります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | | /特許説明書の作成書///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE codes for TST are as follows:
TSTのためのRESPONSEコードは以下の通りです:
0 entity is present in responder's cache 1 entity is not present in responder's cache
0実体は応答者のキャッシュ1実体におけるプレゼントが応答者のキャッシュで存在していないということです。
TST responses have the following OP-DATA, if RESPONSE is zero (0):
TST応答には、以下のOP-DATAがRESPONSEが(0)でないならあります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ DETAIL /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | | /詳細///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Note: The response headers returned by a positive TST can be of a
stale object. Requestors should be prepared to cope with this
condition, either by using the responder as a source for this
object (which could cause the responder to simply refresh it)
or by choosing a different responder.
以下に注意してください。 積極的なTSTによって返された応答ヘッダは聞き古した物のものであることができます。 要請者はこの物(応答者にそれを単にリフレッシュさせることができた)にソースとして応答者を使用するか、または異なった応答者を選ぶことによってこの状態に対処する用意ができているべきです。
Vixie & Wessels Experimental [Page 10] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[10ページ]RFC2756超-テキスト
TST responses have the following OP-DATA, if RESPONSE is one (1):
TST応答には、以下のOP-DATAがRESPONSEが1つ(1)であるならあります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ CACHE-HDRS /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | | /キャッシュ-HDRS///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6.3. MON (OPCODE 2):
6.3. 月曜日(OPCODE2):
Monitor activity in a proxy cache's local object store (adds, deletes, replacements, etc). Since interleaving of HTCP transactions over a single pair of UDP endpoints is not supported, it is recommended that a unique UDP endpoint be allocated by the requestor for each concurrent MON request. MON requests with RD=0 are equivalent to those with RD=1 and TIME=0; that is, they will cancel any outstanding MON transaction.
プロキシキャッシュの地方の物の店で活動を監視してください、(加える、削除、交換など) 1組のUDP終点にわたるHTCP取引のインターリービングが支持されないので、ユニークなUDP終点がそれぞれの同時発生の月曜日の要求のために要請者によって割り当てられるのは、お勧めです。 月曜日に、RD=0との要求はRD=1とタイム誌=0があるそれらに同等です。 すなわち、彼らはどんな傑出している月曜日の取引も中止するでしょう。
MON requests have the following OP-DATA structure:
月曜日に、要求には、以下のOP-DATA構造があります:
+0 (MSB)
+---+---+---+---+---+---+---+---+
0: | TIME |
+---+---+---+---+---+---+---+---+
+0(MSB) +---+---+---+---+---+---+---+---+ 0: | 時間| +---+---+---+---+---+---+---+---+
TIME is the number of seconds of monitoring output desired by the
initiator. Subsequent MON requests from the same initiator
with the same TRANS-ID should update the time on a ongoing MON
transaction. This is called "overlapping renew."
タイム誌は創始者によって望まれていたモニターしている出力の秒数です。 同じTRANS-IDをもっている同じ創始者からのその後の月曜日の要求は進行中の月曜日の取引の時にアップデートするべきです。 これは「重なって、更新してください。」と呼ばれます。
RESPONSE codes for MON are as follows:
月曜日のRESPONSEコードは以下の通りです:
0 accepted, OP-DATA is present and valid 1 refused (quota error -- too many MON's are active)
0は受け入れました、そして、OP-DATAは存在しています、そして、有効な1は拒否しました。(割当て誤り、--、あまりに多くの月曜日がアクティブである)
MON responses have the following OP-DATA structure, if RESPONSE is zero (0):
月曜日に、応答には、以下のOP-DATA構造がRESPONSEが(0)でないならあります:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | TIME | ACTION | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 時間| 動作| 理由| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | | /アイデンティティ///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Vixie & Wessels Experimental [Page 11] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[11ページ]RFC2756超-テキスト
TIME is the number of seconds remaining for this MON
transaction.
タイム誌はこの月曜日の取引のために残っている秒数です。
ACTION is a numeric code indicating a cache population action.
Codes are:
ACTIONはキャッシュ人口動作を示す数字コードです。 コードは以下の通りです。
0 an entity has been added to the cache
1 an entity in the cache has been refreshed
2 an entity in the cache has been replaced
3 an entity in the cache has been deleted
0 実体はキャッシュ1に加えられて、キャッシュにおける実体がキャッシュにおける1実体あたり壮快な2が取り替えて、キャッシュにおける1実体あたり3が削除されたということであるということであるということです。
REASON is a numeric code indicating the reason for an ACTION.
Codes are:
REASONはACTIONの理由を示す数字コードです。 コードは以下の通りです。
0 some reason not covered by the other REASON codes
1 a proxy client fetched this entity
2 a proxy client fetched with caching disallowed
3 the proxy server prefetched this entity
4 the entity expired, per its headers
5 the entity was purged due to caching storage limits
何らかの理由が1人のaプロキシクライアントがキャッシュしながらこの実体2にとって来られたプロキシクライアントをとって来た他のREASONコードで関しなかった0がプロキシサーバが「前-とって」来た3を禁じた、この実体4、実体は期限が切れて、格納限界をキャッシュするため実体はヘッダー5に従って掃除されました。
6.4. SET (OPCODE 3):
6.4. (OPCODE3)を設定してください:
Inform a cache of the identity of an object. This is a "push" transaction, whereby cooperating caches can share information such as updated Age/Date/Expires headers (which might result from an origin "304 Not modified" HTTP response) or updated cache headers (which might result from the discovery of non-authoritative "vary" conditions or from learning of second or third party cache locations for this entity. RD is honoured.
物のアイデンティティのキャッシュを知らせてください。 これが「プッシュ」取引である、協力キャッシュがどうして最終更新日Age/期日の/などの情報を共有できるかがヘッダー(起源「変更された304Not」HTTP応答から生じるかもしれない)かアップデートされたキャッシュヘッダーを吐き出します。どれが状態かこの実体のために2番目か第三者キャッシュ位置を知るのからの非正式の「異なってください」の発見から生じるかもしれませんか?(RDは尊敬されます。
SET requests have the following OP-DATA structure:
SET要求には、以下のOP-DATA構造があります:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | | /アイデンティティ///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE codes are as follows:
RESPONSEコードは以下の通りです:
0 identity accepted, thank you
1 identity ignored, no reason given, thank you
0のアイデンティティを受け入れて、無視された1つのアイデンティティ、理由当然のことがない、ありがとうございますをありがとうございます。
SET responses have no OP-DATA.
SET応答には、OP-DATAが全くありません。
Vixie & Wessels Experimental [Page 12] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[12ページ]RFC2756超-テキスト
6.5. CLR (OPCODE 4):
6.5. CLR(OPCODE4):
Tell a cache to completely forget about an entity. RD is honoured.
実体を完全に忘れるようにキャッシュに言ってください。 RDは尊敬されます。
CLR requests have the following OP-DATA structure:
CLR要求には、以下のOP-DATA構造があります:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | RESERVED | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 予約されます。| 理由| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | | /特許説明書の作成書///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
REASON is a numeric code indicating the reason why the requestor
is asking that this entity be removed. The codes are as
follows:
REASONは要請者が、この実体が取り除かれるように頼んでいる理由を示す数字コードです。 コードは以下の通りです:
0 some reason not better specified by another code
1 the origin server told me that this entity does not
exist
0 別のコード1によって指定されないほうがよくて、起源サーバが、この実体が存在しないと私に言った何らかの理由
RESPONSE codes are as follows:
RESPONSEコードは以下の通りです:
0 i had it, it's gone now
1 i had it, i'm keeping it, no reason given.
2 i didn't have it
0 iには、それがあって、現在のiが持っていた1をどんどんやって、私はそれを保つ理由があげられませんでした。 2 iには、それがありませんでした。
CLR responses have no OP-DATA.
CLR応答には、OP-DATAが全くありません。
Clearing a URI without specifying response, entity, or cache headers means to clear all entities using that URI.
応答、実体、またはキャッシュヘッダーを指定しないでURIをクリアするのは、そのURIを使用することですべての実体をクリアすることを意味します。
7. Security Considerations
7. セキュリティ問題
If the optional AUTH element is not used, it is possible for unauthorized third parties to both view and modify a cache using the HTCP protocol.
任意のAUTH要素が使用されていないなら、権限のない第三者がともにHTCPプロトコルを使用するキャッシュを見て、変更するのは、可能です。
8. Acknowledgements
8. 承認
Mattias Wingstedt of Idonex brought key insights to the development of this protocol. David Hankins helped clarify this document.
IdonexのマティアスWingstedtはこのプロトコルの開発に主要な洞察をもたらしました。 デヴィッド・ハンキンズは、このドキュメントをはっきりさせるのを助けました。
Vixie & Wessels Experimental [Page 13] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[13ページ]RFC2756超-テキスト
9. References
9. 参照
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[RFC2616] 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.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February,
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
version 2", RFC 2186, September 1997.
[RFC2186] ウェセルズとD.とK.Claffy、「インターネットCacheプロトコル(ICP)、バージョン2インチ、RFC2186、1997年9月。」
10. Authors' Addresses
10. 作者のアドレス
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
通りレッドウッドシティー、ポールVixieインターネットソフトウェア共同体950Charterカリフォルニア 94063
Phone: +1 650 779 7001 EMail: vixie@isc.org
以下に電話をしてください。 +1 7001年の650 779メール: vixie@isc.org
Duane Wessels National Lab for Applied Network Research USCD, 9500 Gilman Drive La Jolla, CA 92093
カリフォルニア 適用されたネットワーク研究USCD、9500ギルマン・ドライブラ・ホーヤ、92093へのドウェイン・ウェセルズ国家の研究室
Phone: +1 303 497 1822 EMail: wessels@nlanr.net
以下に電話をしてください。 +1 1822年の303 497メール: wessels@nlanr.net
Vixie & Wessels Experimental [Page 14] RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) January 2000
2000年1月にプロトコル(HTCP/0.0)をキャッシュするVixieとウェセルズの実験的な[14ページ]RFC2756超-テキスト
11. Full Copyright Statement
11. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Vixie & Wessels Experimental [Page 15]
Vixieとウェセルズ実験的です。[15ページ]
一覧
スポンサーリンク
