Network Working Group D. Wessels Request for Comments: 2186 K. Claffy Category: Informational National Laboratory for Applied Network Research/UCSD September 1997 Internet Cache Protocol (ICP), version 2 Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. このメモはインターネットコミュニティーに情報を提供するものです。この メモはいかなる種類のインターネットの標準も記載していません。このメモの 配布は無制限に行なって構いません。 Abstract This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object. この文章は、いくらかのWorld-Wide Webの代理キャッシュパッケージ[3,5]で 実現されているInternet Cache Protocol (ICPv2)について説明しています。 ICPはWebキャッシュの間の通信を行なうための軽量なメッセージ形式です。 ICPは近所のキャシュに存在するURLに関するヒントを交換するために使用 されます。キャッシュは取得しようとして探しているオブジェクトを得る のに、最も適切な場所を選択するために用いる情報を集めるために、 ICP問合せと応答を交換します。 This document describes only the format and fields of ICP messages. A companion document (RFC2187) describes the application of ICP to Web caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use for their own purposes. この文章はICPメッセージのフォーマットとフィールドについてのみ記述 しています。ICPのWebキャッシュへの応用は、対となっている文章(RFC2187) に記述しています。現在、いくつかの独立したキャッシュの実装がICPを 用いています。そして、それら自身の目的に合わせて実装し、展開し、拡張 しようとするために、我々は現存する現実的なICPの使用法に関して文章に まとめることが大切であると考えています。 1. Introduction ICP is a message format used for communicating between Web caches. Although Web caches use HTTP[1] for the transfer of object data, caches benefit from a simpler, lighter communication protocol. ICP is primarily used in a cache mesh to locate specific Web objects in neighboring caches. One cache sends an ICP query to its neighbors. The neighbors send back ICP replies indicating a "HIT" or a "MISS." ICPは、Webキャッシュ間の対話に使用されるメッセージフォーマットです。 Webキャッシュがオブジェクトデータの転送のためにHTTP[1]を使用するにも 関わらず、キャッシュはより小型で軽量なプロトコルによって恩恵を被り ます。ICPは、neighborキャッシュの中にある、特定のWebオブジェクトの 位置を捜し当てるために、主としてキャッシュの編目構造の中で利用され ます。neighborは、"HIT"か"MISS"を含んだICP応答を返送します。 In current practice, ICP is implemented on top of UDP, but there is no requirement that it be limited to UDP. We feel that ICP over UDP offers features important to Web caching applications. An ICP query/reply exchange needs to occur quickly, typically within a second or two. A cache cannot wait longer than that before beginning to retrieve an object. Failure to receive a reply message most likely means the network path is either congested or broken. In either case we would not want to select that neighbor. As an indication of immediate network conditions between neighbor caches, ICP over a lightweight protocol such as UDP is better than one with the overhead of TCP. 現時点での実装では、ICPはUDPの最上層で実行されていますが、UDPに限ら れるという制限はありません。「我々は、ICP over UDPはWebキャッシュの アプリケーションにとって重要な特徴を提供すると思っています。」 ICP問合せ／応答の交換は、典型的には1秒か2秒程度の間で、高速に行な われる必要があります。「キャッシュはオブジェクトの獲得を開始する前に それ以上待つとは出来ません。」応答メッセージの受信の失敗は、ほとんどの 場合、ネットワークの経路が一杯になっているか、切断されているかの どちらかを意味します。どちらの場合も、そのneighborを選択したいとは 思いません。neighborキャッシュ間のネットワークの瞬間の状態が示される ためには、ICPはTCPのようにオーバヘッドのあるものよりは、UDPのような 軽量なプロトコル上で実現された方がよい。 In addition to its use as an object location protocol, ICP messages can be used for cache selection. Failure to receive a reply from a cache may indicate a network or system failure. The ICP reply may include information that could assist selection of the most appropriate source from which to retrieve an object. オブジェクトの位置決めをするプロトコルとして、ICPを利用することに 加えて、ICPはキャッシュの選択にも利用できます。キャッシュからの 応答を受けとることに失敗するということは、ネットワークか、システムが おかしな状態にあるという兆候を示すかもしれません。ICP応答は、取得 しようとしているオブジェクトの、最も適切なソースを選択する助けとなる 情報を含んでいるかもしれません。 ICP was initially developed by Peter Danzig, et. al. at the University of Southern California as a central part of hierarchical caching in the Harvest research project[3]. ICPは最初に南カリフォルニア大のPeter Danzigらによって、Harvest research project[3]における階層キャッシュの中心的な部分として 開発されました。 ICP Message Format The ICP message format consists of a 20-octet fixed header plus a variable sized payload (see Figure 1). NOTE: All fields must be represented in network byte order. ICPのメッセージは20オクテットの固定長ヘッダーと自由長のpayloadから なると規定されている。(図1) 注意：全てのフィールドは、ネットワーク・バイト・オーダで表されている。 Opcode One of the opcodes defined below. 以下で定義される、opcodeのうちの1つ。 Version The ICP protocol version number. At the time of this writing, both versions two and three are in use. This document describes only version two. The version number field allows for future development of this protocol. ICPプロトコルのバージョン番号。この文章を書いている時点では、 2と3の両方のバージョンが利用されている。この文章は、バージョン2 についてのみ記述している。バージョン番号のフィールドは、この プロトコルの将来の拡張を認めている。 Message Length The total length (octets) of the ICP message. ICP messages MUST not exceed 16,384 octets in length. ICPメッセージの全長。ICPメッセージは、16,384オクテットの長さを 越えてはならない。 Request Number An opaque identifier. When responding to a query, this value must be copied into the reply message. 「不明瞭な識別子。」問合せに応答した際に、この値は応答メッセージに コピーしなければならない。 Options A 32-bit field of option flags that allows extension of this version of the protocol in certain, limited ways. See "ICP Option Flags" below. はっきりと制限された方法で、このバージョンのプロトコルの拡張を 認めるための32ビット長のオプションフラグ。以下の"ICP Options"を 見なさい。 Option Data A four-octet field to support optional features. The following ICP features make use of this field: The ICP_FLAG_SRC_RTT option uses the low 16-bits of Option Data to return RTT measurements. The ICP_FLAG_SRC_RTT option is further described below. オプションの仕組みをサポートするための4オクテットのフィールド。 以下のICPの仕組みがこのフィールドを使用する： ICP_FLAG_SRC_RTTオプションで、RTT計測の戻り値としてOption Dataの 下位16ビットに用いる。ICP_FLAG_SRC_RTTオプションについては、下方で 説明してある。 Sender Host Address The IPv4 address of the host sending the ICP message. This field should probably not be trusted over what is provided by getpeer- name(), accept(), and recvfrom(). There is some ambiguity over the original purpose of this field. In practice it is not used. ICPメッセージを送出したホストのIPv4アドレス。このフィールドは、 getpeername(), accept(), recvfrom()で得られたもの以上に 信用されることはない。このフィールドの本来の目的には、幾分の 曖昧さがある。実際には、このフィールドは使用されない。 Payload The contents of the Payload field vary depending on the Opcode, but most often it contains a null-terminated URL string. Payloadフィールドの中身は、Opcodeに著しく依存するが、ヌル終端の URL文字列が含まれることがほとんどである。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Host Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | / / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FIGURE 1: ICP message format. 2. ICP Opcodes The following table shows currently defined ICP opcodes: 以下の表は、現在定義されているICP opcodeを示している： Value Name ----- ----------------- 0 ICP_OP_INVALID 1 ICP_OP_QUERY 2 ICP_OP_HIT 3 ICP_OP_MISS 4 ICP_OP_ERR 5-9 UNUSED 10 ICP_OP_SECHO 11 ICP_OP_DECHO 12-20 UNUSED 21 ICP_OP_MISS_NOFETCH 22 ICP_OP_DENIED 23 ICP_OP_HIT_OBJ ICP_OP_INVALID A place holder to detect zero-filled or malformed messages. A cache must never intentionally send an ICP_OP_INVALID message. ICP_OP_ERR should be used instead. 0で埋められているか、おかしな形のメッセージを受信したという印。 キャッシュは、意識してICP_OP_INVALIDメッセージを送ることは、 決してありません。ICP_OP_ERRが、その代わりに使われるべきです。 ICP_OP_QUERY A query message. NOTE this opcode has a different payload format than most of the others. First is the requester's IPv4 address, followed by a URL. The Requester Host Address is not that of the cache generating the ICP message, but rather the address of the caches's client that originated the request. The Requester Host Address is often zero filled. An ICP message with an all-zero Requester Host Address address should be taken as one where the requester address is not specified; it does not indicate a valid IPv4 address. 問合せメッセージ。このopcodeのときは、他の大部分の時とは異なった payloadフォーマットをしていることに注意しなさい。まず始めは、 要求者のIPv4アドレスで、それにURLが続きます。要求者のホストアドレスは、 ICPメッセージを生成したキャッシュのものではなく、元の要求を出した クライアントであるキャッシュのアドレスです。要求者のホストアドレスは、 しばしば0で埋められます。要求者のホストアドレスが全て0で表された ICPメッセージは要求者のアドレスが特定されていない、つまり有効な IPv4アドレスが示されていないものとして取り扱われます。 ICP_OP_QUERY payload format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requester Host Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Null-Terminated URL / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In response to an ICP_OP_QUERY, the recipient must return one of: ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH, ICP_OP_DENIED, or ICP_OP_HIT_OBJ. ICP_OP_QUERYの応答に際しては、それを受けとったキャッシュは、 次のうちの1つを返さなければなりません。 ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH, ICP_OP_DENIED, ICP_OP_HIT_OBJ. ICP_OP_SECHO Similar to ICP_OP_QUERY, but for use in simulating a query to an origin server. When ICP is used to select the closest neighbor, the origin server can be included in the algorithm by bouncing an ICP_OP_SECHO message off it's echo port. The payload is simply the null-terminated URL. ICP_OP_QUERYと似ているが、元のサーバへの問合せのシミュレートの ために利用されます。ICPが最も近いneighborを選ぶのに利用される場合に、 元のサーバのechoポートに、反応を見るためにICP_OP_SECHOメッセージを 送りつけることで、アルゴリズムに元のサーバを含めることができます。 payloadは、単にnull-terminated URLです。 NOTE: the echo server will not interpret the data (i.e. we could send it anything). This opcode is used to tell the difference between a legitimate query or response, random garbage, and an echo response. 注意：echoサーバはデータを解釈しません。（つまり、何でも送ることが 出来ます。）このopcodeは、適切な問合せ、または、応答、乱数のゴミと、 echo応答とを区別するのに利用さます。 ICP_OP_DECHO Similar to ICP_OP_QUERY, but for use in simulating a query to a cache which does not use ICP. When ICP is used to choose the closest neighbor, a non-ICP cache can be included in the algorithm by bouncing an ICP_OP_DECHO message off it's echo port. The payload is simply the null-terminated URL. ICP_OP_QUERYと似ているが、ICPを使わないキャッシュへの問合せの シミュレートのために利用されます。ICPが最も近いneighborを選ぶのに 利用される場合に、ICPを使わないキャッシュのechoポートに、 反応を見るためにICP_OP_DECHOメッセージを送りつけることで、 アルゴリズムに元のサーバを含めることができます。payloadは、 単にnull-terminated URLです。 NOTE: one problem with this approach is that while a system's echo port may be functioning perfectly, the cache software may not be running at all. 注意：システムのechoポートが、完全に使用されている間は、キャッシュ ソフトはこの方法には、全く動かないという問題があります。 One of the following six ICP opcodes are sent in response to an ICP_OP_QUERY message. Unless otherwise noted, the payload must be the null-terminated URL string. Both the URL string and the Request Number field must be exactly the same as from the ICP_OP_QUERY message. 次の6つのICP opcodeのうちの1つが、ICP_OP_QUERYメッセージに対する 応答として送られます。「異なった記述でない限り」、payloadは null-terminated URL文字列でなければならない。URL文字列と Request Numberフィールドの両方とも、ICP_OP_QUERYメッセージからものと、 正確に一致していなければなりません。 ICP_OP_HIT An ICP_OP_HIT response indicates that the requested URL exists in this cache and that the requester is allowed to retrieve it. ICP_OP_HIT応答は、要求されたURLが、このキャッシュに存在して、 要求者がそれを取得することができることを示しています。 ICP_OP_MISS An ICP_OP_MISS response indicates that the requested URL does not exist in this cache. The querying cache may still choose to fetch the URL from the replying cache. ICP_OP_MISS応答は、要求されたURLが、このキャッシュに存在しない ことを示します。問い合わせを行なったキャッシュは、おそらくその 応答したキャッシュからそのURLをとってくることにするだろう。 ICP_OP_ERR An ICP_OP_ERR response indicates some kind of error in parsing or handling the query message (e.g. invalid URL). ICP_OP_ERR応答は、問合せのメッセージの解釈か取り扱いにおいて、 何らかのエラー（例えば無効なURL）が発生したことを示します。 ICP_OP_MISS_NOFETCH An ICP_OP_MISS_NOFETCH response indicates that this cache is up, but is in a state where it does not want to handle cache misses. An example of such a state is during a startup phase where a cache might be rebuilding its object store. A cache in such a mode may wish to return ICP_OP_HIT for cache hits, but not ICP_OP_MISS for misses. ICP_OP_MISS_NOFETCH essentially means "I am up and running, but please don't fetch this URL from me now." ICP_OP_MISS_NOFETCH応答は、このキャッシュは起動しているが、 キャッシュのmissを処理したくない状態にあることを示しています。 その様な状態の例として、キャッシュが蓄積しているオブジェクトを 再構築するような起動処理中の状態があります。そのような状態にある キャッシュは、キャッシュにヒットした場合に、ICP_OP_HITを返す だろうが、ミスした時には、ICP_OP_MISSを返さない。 ICP_OP_MISS_NOFETCHの本質的な意味は、“私は、起動していて 実行中ですが、今は私からこのURLを取っていかないで下さい。” ということです。 Note, ICP_OP_MISS_NOFETCH has a different meaning than ICP_OP_MISS. The ICP_OP_MISS reply is an invitation to fetch the URL from the replying cache (if their relationship allows it), but ICP_OP_MISS_NOFETCH is a request to NOT fetch the URL from the replying cache. ICP_OP_MISS_NOFETCHは、ICP_OP_MISSとは意味が違うことに注意しなさい。 ICP_OP_MISS応答は、（それらの関係が許しているのなら）応答した キャッシュから、URLを取得することを奨めているもので、 ICP_OP_MISS_NOFETCHは、応答したキャッシュからURL取らない要求です。 ICP_OP_DENIED An ICP_OP_DENIED response indicates that the querying site is not allowed to retrieve the named object from this cache. Caches and proxies may implement complex access controls. This reply must be be interpreted to mean "you are not allowed to request this particular URL from me at this particular time." ICP_OP_DENIED応答は、問合せを発したサイトは、このキャッシュから、 その名前のオブジェクトを取っていくことが許されていないことを 示しています。CacheやProxyでは、複雑なアクセス制御が施されます。 この応答は、“あなたは、この特定のURLを、私から、今この時に 要求することは許されていない。”という風に解釈出来るに過ぎない。 Caches receiving a high percentage of ICP_OP_DENIED replies are probably misconfigured. Caches should track percentage of all replies which are ICP_OP_DENIED and disable a neighbor which exceeds a certain threshold (e.g. 95% of 100 or more queries). ICP_OP_DENIED応答を受けとる比率が高いキャッシュは、おそらく設定を 間違えています。キャッシュは、ICP_OP_DENIEDの比率を記録し、 ある一定の閾値（例えば100回以上の問合せの95%）を越えた仲間は、 不可能であるとみなします。 Similarly, a cache should track the percent of ICP_OP_DENIED messages that are sent to a given address. If the percent of denied messages exceeds a certain threshold (e.g. 95% of 100 or more), the cache may choose to ignore all subsequent ICP_OP_QUERY messages from that address until some sort of administrative intervention occurs. 同様に、あるアドレスに送られたICP_OP_DENIEDメッセージの割合も キャッシュは記録すべきです。拒否メッセージの割合が一定の閾値 （例えば100回以上の問合せの95%）を越えた場合は、「管理的な仲裁」の ようなものが発生しない限り、キャッシュはそのアドレスから続いて 発生する全てのICP_OP_QUERYメッセージを無視するようになります。 ICP_OP_HIT_OBJ Just like an ICP_OP_HIT response, but the actual object data has been included in this reply message. Many requested objects are small enough that it is possible to include them in the query response and avoid the need to make a subsequent HTTP request for the object. ICP_OP_HIT応答とほとんど同じであるが、実際のオブジェクトデータが この応答メッセージに含まれている点が異なります。多くの要求された オブジェクトは、問い合わせに対する反応の中にそれを含めて、 そのオブジェクトに対するHTTP要求を続けて起こすのを避けた方が 良いくらい十分に小さい。 CAVEAT: ICP_OP_HIT_OBJ has some negative side effects which make its use undesirable. It transfers object data without HTTP and therefore bypasses the standard HTTP processing, including authorization and age validation. Another negative side effect is that ICP_OP_HIT_OBJ messages will often be much larger than the path MTU, thereby causing fragmentation to occur on the UDP packet. For these reasons, use of ICP_OP_HIT_OBJ is NOT recommended. 警告：ICP_OP_HIT_OBJは、良くない使い方により、少しまずい効果が あります。HTTPではなくオブジェクトデータを転送するため、 認証や年齢確認を含む標準的なHTTP処理を避けて通ってしまいます。 その他の良くない効果として、ICP_OP_HIT_OBJメッセージは、経路の MTUより大きくなってしまい、UDPパケットの分割化が起こってしまう ことがあります。こうしたことから、ICP_OP_HIT_OBJの利用は、 推奨されません。 A cache must not send an ICP_OP_HIT_OBJ unless the ICP_FLAG_HIT_OBJ flag is set in the query message Options field. キャッシュはICP_FLAG_HIT_OBJフラグが問合せメッセージのOptions フィールドにセットされない限り、ICP_OP_HIT_OBJを送ってはいけません。 ICP_OP_HIT_OBJ payload format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Null-Terminated URL / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Size | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Object Data / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The receiving application must check to make sure it actually receives Object Size octets of data. If it does not, then it should treat the ICP_OP_HIT_OBJ reply as though it were a normal ICP_OP_HIT. 受けとるアプリケーションは、データの本当に受けとるObject Sizeの オクテット数をきちんと確認しなければなりません。もし、そうしないの ならICP_OP_HIT_OBJ応答は、通常のICP_OP_HITをして処理すべきです。 NOTE: the Object Size field does not necessarily begin on a 32-bit boundary as shown in the diagram above. It begins immediately following the NULL byte of the URL string. 注意：Object Sizeフィールドは、上の図のように32 bitの境界で始まる 必要はない。そのフィールドは、URL文字列のNULLバイトの直後から始まる。 UNRECOGNIZED OPCODES ICP messages with unrecognized or unused opcodes should be ignored, i.e. no reply generated. The application may choose to note the anomalous behaviour in a log file. 認識できないか使用されていないopcodeを持ったICPメッセージは、例えば 応答をしないなどして無視すべきです。アプリケーションは、ログファイルに 異例な処理をしたと記述するのが良いかもしれない。 3. ICP Option Flags 0x80000000 ICP_FLAG_HIT_OBJ This flag is set in an ICP_OP_QUERY message indicating that it is okay to respond with an ICP_OP_HIT_OBJ message if the object data will fit in the reply. このフラグは、オブジェクトデータの大きさが合えば、ICP_OP_HIT_OBJ メッセージで応答しても良いことを示すために、ICP_OP_QUERYメッセージで セットされます。 0x40000000 ICP_FLAG_SRC_RTT This flag is set in an ICP_OP_QUERY message indicating that the requester would like the ICP reply to include the responder's measured RTT to the origin server. このフラグは、応答者が計測した元のサーバからのRTTを含めてICP応答を 返すことを要求者が望んでいることを示すために、ICP_OP_QUERY メッセージでセットされます。 Upon receipt of an ICP_OP_QUERY with ICP_FLAG_SRC_RTT bit set, a cache should check an internal database of RTT measurements. If available, the RTT value MUST be expressed as a 16-bit integer, in units of milliseconds. If unavailable, the responder may either set the RTT value to zero, or clear the ICP_FLAG_SRC_RTT bit in the ICP reply. The ICP reply MUST not be delayed while waiting for the RTT measurement to occur. ICP_FLAG_SRC_RTTビットがセットされたICP_OP_QUERYを受けとった際には、 キャッシュはRTT計測の内部データベースをチェックすべきです。もし 有効であったら、RTT値はミリ秒の単位で16ビットの整数値として表現 されなければなりません。もし有効でなければ、応答者はRTT値に0を セットするか、ICP応答の中のICP_FLAG_SRC_RTTビットをクリアします。 ICP応答はRTTの計測を待つような遅延を起こしてはならない。 This flag is set in an ICP reply message (ICP_OP_HIT, ICP_OP_MISS, ICP_OP_MISS_NOFETCH, or ICP_OP_HIT_OBJ) to indicate that the low 16-bits of the Option Data field contain the measured RTT to the host given in the requested URL. If ICP_FLAG_SRC_RTT is clear in the query then it MUST also be clear in the reply. If ICP_FLAG_SRC_RTT is set in the query, then it may or may not be set in the reply. このフラグは、要求されたURLを与えるホストまでのRTTの計測値を Option Dataフィールドの下位16ビット含めたことを示すために、ICP応答 メッセージ(ICP_OP_HIT, ICP_OP_MISS, ICP_OP_MISS_NOFETCH, or ICP_OP_HIT_OBJ)にセットされます。ICP_FLAG_SRC_RTTが問合せの中でクリア されていたなら、応答でもクリアされていなければなりません。 ICP_FLAG_SRC_RTTが問合せの中でセットされていたなら、応答ではセット されているかもしれないし、セットされていないかもしれません。 4. Security Considerations The security issues relating to ICP are discussed in the companion document, RFC2187. ICPに関係するセキュリティーの問題は、対となるドキュメントである RFC2187で議論している。 5. References [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, January 1997. [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wessels D., "The Harvest Information Discovery and Access System", Internet Research Task Force - Resource Discovery, http://harvest.transarc.com/. [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National Laboratory for Applied Network Research, http://www.nlanr.net/~wessels/Papers/icp-squid.ps.gz [5] Wessels D., "The Squid Internet Object Cache", National Laboratory for Applied Network Research, http://squid.nlanr.net/Squid/ 6. Acknowledgments The authors wish to thank Paul A Vixie for providing excellent feedback on this document. 7. Authors' Addresses Duane Wessels National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: wessels@nlanr.net K. Claffy National Laboratory for Applied Network Research 10100 Hopkins Drive La Jolla, CA 92093 EMail: kc@nlanr.net 翻訳者： 片山 健夫 / KATAYAMA, Takeo 東京工業大学 精密工学研究所 / P&I Lab., Tokyo Inst. of Tech. tkatayam@pi.titech.ac.jp 97/09/15 怪しいと思う所は、「」で括った。誤りがあると、日本語訳を作ったこと 自体が「百害あって、一利なし」になるので、誤字、誤訳は是非教えて欲しい。