idnits 2.17.1 draft-vixie-htcp-proto-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 166 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 365 has weird spacing: '...o-cache mea...' == Line 369 has weird spacing: '...o-share mea...' == Line 372 has weird spacing: '...okie-ok mean...' == Line 382 has weird spacing: '...omplete mean...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2068' on line 592 looks like a reference -- Missing reference section? 'RFC2186' on line 601 looks like a reference -- Missing reference section? 'RFC1630' on line 588 looks like a reference -- Missing reference section? 'RFC2104' on line 597 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ICP Working Group Paul Vixie 2 INTERNET-DRAFT Vayu 3 Duane Wessels 4 NLANR 5 September, 1998 7 Hyper Text Caching Protocol (HTCP/0.0) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This draft describes HTCP, a protocol for discovering HTTP caches and 30 cached data, managing sets of HTTP caches, and monitoring cache 31 activity. 33 1 - Definitions, Rationale and Scope 35 1.1. HTTP/1.1 (see [RFC2068]) permits the transfer of web objects from 36 ``origin servers'', possibly via ``proxies'' (which are allowed under 37 some circumstances to ``cache'' such objects for subsequent reuse) to 38 ``clients'' which consume the object in some way, usually by displaying 39 it as part of a ``web page.'' HTTP/1.0 and later permit ``headers'' to 40 be included in a request and/or a response, thus expanding upon the 41 HTTP/0.9 (and earlier) behaviour of specifying only a URI in the request 42 and offering only a body in the response. 44 1.2. ICP (see [RFC2186]) permits caches to be queried as to their 45 content, usually by other caches who are hoping to avoid an expensive 46 fetch from a distant origin server. ICP was designed with HTTP/0.9 in 47 mind, such that only the URI (without any headers) is used when 48 describing cached content, and the possibility of multiple compatible 49 bodies for the same URI had not yet been imagined. 51 1.3. This document specifies a Hyper Text Caching Protocol (HTCP or 52 simply HoT CraP) which permits full request and response headers to be 53 used in cache management, and expands the domain of cache management to 54 include monitoring a remote cache's additions and deletions, requesting 55 immediate deletions, and sending hints about web objects such as the 56 third party locations of cacheable objects or the measured 57 uncacheability or unavailability of web objects. 59 2 - HTCP Protocol 61 2.1. All multi-octet HTCP protocol elements are transmitted in network 62 byte order. All RESERVED fields should be set to binary zero by senders 63 and left unexamined by receivers. Headers must be presented with the 64 CRLF line termination, as in HTTP. 66 2.2. Any hostnames specified should be compatible between sender and 67 receiver, such that if a private naming scheme (such as HOSTS.TXT or 68 NIS) is in use, names depending on such schemes will only be sent to 69 HTCP neighbors who are known to participate in said schemes. Raw 70 addresses (dotted quad IPv4, or colon-format IPv6) are universal, as are 71 public DNS names. Use of private names or addresses will require 72 special operational care. 74 2.3. UDP must be supported. HTCP agents must not be isolated from 75 NETWORK failures and delays. An HTCP agent should be prepared to act in 76 useful ways when no response is forthcoming, or when responses are 77 delayed or reordered or damaged. TCP is optional and is expected to be 78 used only for protocol debugging. The IANA has assigned port 4827 as 79 the standard TCP and UDP port number for HTCP. 81 2.4. A set of configuration variables concerning transport 82 characteristics should be maintained for each agent which is capable of 83 initiating HTCP transactions, perhaps with a set of per-agent global 84 defaults. These variables are: 86 Maximum number of unacknowledged transactions before a ``failure'' is 87 imputed. 89 Maximum interval without a response to some transaction before a 90 ``failure'' is imputed. 92 Should ICMP-Portunreach be treated as a failure? 94 Should RESPONSE=5 && MO=1 be treated as a failure? 96 Minimum interval before trying a new transaction after a failure 98 2.5. An HTCP Message has the following general format: 100 +---------------------+ 101 | HEADER | tells message length and protocol versions 102 +---------------------+ 103 | DATA | HTCP message (varies per major version number) 104 +---------------------+ 105 | AUTH | optional authentication for transaction 106 +---------------------+ 108 2.6. An HTCP/*.* HEADER has the following format: 110 +0 (MSB) +1 (LSB) 111 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 112 0: | LENGTH | 113 + + + + + + + + + + + + + + + + + 114 2: | LENGTH | 115 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 116 2: | MAJOR | MINOR | 117 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 119 LENGTH is the message length, inclusive of all header and data octets, 120 including the LENGTH field itself. This field will be equal to 121 the datagam payload size (``record length'') if a datagram 122 protocol is in use, and can include padding, i.e., not all 123 octets of the message need be used in the DATA and AUTH 124 sections. 126 MAJOR is the major version number (0 for this specification). The 127 DATA section of an HTCP message need not be upward or downward 128 compatble between different major version numbers. 130 MINOR is the minor version number (0 for this specification). Feature 131 levels and interpretation rules can vary depending on this 132 field, in particular RESERVED fields can take on new (though 133 optional) meaning in successive minor version numbers within the 134 same major version number. 136 2.6.1. It is expected that an HTCP initiator will know the version 137 number of a prospective HTCP responder, or that the initiator will probe 138 using declining values for MINOR and MAJOR (beginning with the highest 139 locally supported value) and locally cache the probed version number of 140 the responder. 142 2.6.2. Higher MAJOR numbers are to be preferred, as are higher MINOR 143 numbers within a particular MAJOR number. 145 2.7. An HTCP/0.* DATA has the following structure: 147 +0 (MSB) +1 (LSB) 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 149 0: | LENGTH | 150 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 151 2: | OPCODE | RESPONSE | RESERVED |F1 |RR | 152 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 153 4: | MSG-ID | 154 + + + + + + + + + + + + + + + + + 155 6: | MSG-ID | 156 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 157 8: | | 158 / OP-DATA / 159 / / 160 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 162 LENGTH is the number of octets of the message which are reserved for 163 the DATA section, including the LENGTH field itself. This 164 number can include padding, i.e., not all octets reserved by 165 LENGTH need be used in OP-DATA. 167 OPCODE is the operation code of an HTCP transaction. An HTCP 168 transaction can consist of multiple HTCP messages, e.g., a 169 request (sent by the initiator), or a response (sent by the 170 responder). 172 RESPONSE is a numeric code indicating the success or failure of a 173 transaction. It should be set to zero (0) by requestors and 174 ignored by responders. Each operation has its own set of 175 response codes, which are described later. The overall 176 message has a set of response codes which are as follows: 178 0 authentication wasn't used but is required 179 1 authentication was used but unsatisfactorily 180 2 opcode not implemented 181 3 major version not supported 182 4 minor version not supported (major version is ok) 183 5 inappropriate, disallowed, or undesirable opcode 185 The above response codes all indicate errors and all depend 186 for their visibility on MO=1 (as specified below). 188 RR is a flag indicating whether this message is a request (0) or 189 response (1). 191 F1 is overloaded such that it is used differently by requestors 192 than by responders. If RR=0, then F1 is defined as RD. If 193 RR=1, then F1 is defined as MO. 195 RD is a flag which if set to 1 means that a response is desired. 196 Some OPCODEs require RD to be set to 1 to be meaningful. 198 MO (em-oh) is a flag which indicates whether the RESPONSE code is 199 to be interpreted as a response to the overall message (fixed 200 fields in DATA or any field of AUTH) [MO=1] or as a response 201 to fields in the OP-DATA [MO=0]. 203 MSG-ID is a 32-bit value which when combined with the initiator's 204 network address, uniquely identifies this HTCP transaction. 205 care should be taken not to reuse MSG-ID's within the life- 206 time of a UDP datagram. 208 OP-DATA is opcode-dependent and is defined below, per opcode. 210 2.8. An HTCP/0.0 AUTH has the following structure: 212 +0 (MSB) +1 (LSB) 213 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 214 0: | LENGTH | 215 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 216 2: | SIG-TIME | 217 + + + + + + + + + + + + + + + + + 218 4: | SIG-TIME | 219 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 220 6: | SIG-EXPIRE | 221 + + + + + + + + + + + + + + + + + 222 8: | SIG-EXPIRE | 223 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 224 10: | | 225 / KEY-NAME / 226 / / 227 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 228 n: | | 229 / SIGNATURE / 230 / / 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 233 LENGTH is the number of octets used by the AUTH, including the 234 LENGTH field itself. If the optional AUTH is not being 235 transmitted, this field should be set to 2 (two). LENGTH 236 can include padding, which means that not all octets 237 reserved by LENGTH will necessarily be consumed by 238 SIGNATURE. 240 SIG-TIME is an unsigned binary count of the number of seconds since 241 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is 242 generated. 244 SIG-EXPIRE is an unsigned binary count of the number of seconds since 245 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is 246 considered to have expired. 248 KEY-NAME is a COUNTSTR which specifies the name of a shared secret. 249 (Each HTCP implementation is expected to allow configuration 250 of several shared secrets, each of which will have a name.) 252 SIGNATURE is a COUNTSTR which holds the HMAC-MD5 digest (see [RFC 253 2104]), with a B value of 64, of the following elements, 254 each of which is digested in its ``on the wire'' format, 255 including transmitted padding if any is covered by a field's 256 associated LENGTH: 258 IP SRC ADDR [4 octets] 259 IP SRC PORT [2 octets] 260 IP DST ADDR [4 octets] 261 IP DST PORT [2 octets] 262 HTCP MAJOR version number [1 octet] 263 HTCP MINOR version number [1 octet] 264 SIG-TIME [4 octets] 265 SIG-EXPIRE [4 octets] 266 HTCP DATA [variable] 267 KEY-NAME (the whole COUNTSTR) [variable] 269 2.8.1. Shared secrets should be cryptorandomly generated and should be 270 at least a few hundred octets in size. 272 3 - Data Types 274 HTCP/0.* data types are defined as follows: 276 3.1. COUNTSTR is a counted string whose format is: 278 +0 (MSB) +1 (LSB) 279 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 280 0: | LENGTH | 281 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 282 2: | | 283 / TEXT / 284 / / 285 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 287 LENGTH is the number of octets which will follow in TEXT. This field 288 is *not* self-inclusive as is the case with other HTCP LENGTH 289 fields. 291 TEXT is a stream of uninterpreted octets, usually ISO8859-1 292 ``characters''. 294 3.2. SPECIFIER is used with the TST and CLR request messages, defined 295 below. Its format is: 297 +---------------------+ 298 | METHOD | : COUNTSTR 299 +---------------------+ 300 | URI | : COUNTSTR 301 +---------------------+ 302 | VERSION | : COUNTSTR 303 +---------------------+ 304 | REQ-HDRS | : COUNTSTR 305 +---------------------+ 307 METHOD (Since HTCP only returns headers, methods GET and HEAD are 308 equivilent.) 310 URI (If the URI is a URL, it should always include a ``:'' 311 specifier, but in its absense, port 80 should be imputed by a 312 receiver.) 314 VERSION is an entire HTTP version string such as ``HTTP/1.1''. 315 VERSION strings with prefixes other than ``HTTP/'' or with 316 version numbers less than ``1.1'' are outside the domain of 317 this specification. 319 REQ-HDRS are those presented by an HTTP initiator. These headers 320 should include end-to-end but NOT hop-by-hop headers, and they 321 can be canonicalized (aggregation of ``Accept:'' is permitted, 322 for example.) 324 3.3. DETAIL is used with the TST response message, defined below. Its 325 format is: 327 +---------------------+ 328 | RESP-HDRS | : COUNTSTR 329 +---------------------+ 330 | ENTITY-HDRS | : COUNTSTR 331 +---------------------+ 332 | CACHE-HDRS | : COUNTSTR 333 +---------------------+ 335 3.4. IDENTITY is used with the MON request and SET response message, 336 defined below. Its format is: 338 +---------------------+ 339 | SPECIFIER | 340 +---------------------+ 341 | DETAIL | 342 +---------------------+ 344 4 - Cache Headers 346 HTCP/0.0 CACHE-HDRS consist of zero or more of the following headers: 348 Cache-Vary: ... 349 The sender of this header has learned that content varies on a set of 350 headers different from the set given in the object's Vary: header. 351 If Cache-Vary: specifies the null set, then the origin server has 352 been found to issue identical results no matter what request headers 353 are given to it. 355 Cache-Location: : ... 356 The sender of this header has learned of one or more proxy caches who 357 are holding a copy of this object. Probing these caches with HTCP 358 may result in discovery of new, close-by (preferrable to current) 359 HTCP neighbors. 361 Cache-Policy: [no-cache] [no-share] [cookie-ok] 362 The sender of this header has learned that the object's policy has 363 more detail than is given in its response headers. 365 no-cache means that it is uncacheable (no reason given), 366 but may be shareable between simultaneous 367 requestors. 369 no-share means that it is unshareable (no reason given), 370 and per-requestor tunnelling is always required). 372 cookie-ok means that the content is not going to change as a 373 result of different, missing, or even random 374 cookies being included in the request headers, and 375 that caching may be possible. 377 Cache-Flags: [incomplete] 378 The sender of this header has modified the object's policy locally, 379 such that requesters may need to treat this response specially, i.e., 380 not necessarily in accordance with the object's actual policy. 382 incomplete means that the response headers and/or entity 383 headers given in this response are not known to be 384 complete, and may not be suitable for use as a 385 cache key. 387 Cache-Expiry: 388 The sender of this header has learned that this object should be 389 considered to have expired at a time different than that indicate by 390 its response headers. The format is the same as HTTP/1.1 Expires:. 392 Cache-MD5: 393 The sender of this header has computed an MD5 checksum for this 394 object which is either different from that given in the object's 395 Content-MD5: header, or is being supplied since the object has no 396 Content-MD5 header. The format is the same as HTTP/1.1 Content-MD5:. 398 Cache-to-Origin: [,...] 399 The sender of this header has measured the round trip time to a set 400 of origin servers (given as a comma separated list of 401 hostnames). The is the average number of seconds, expressed as 402 decimal ASCII with arbitrary precision and no exponent. is 403 the number of RTT samples which have had input to this average. 404 is the number of routers between the cache and the origin, 405 expressed as decimal ASCII with arbitrary precision and no exponent, 406 or 0 if the cache doesn't know. 408 6 - HTCP Operations 410 HTCP/0.* opcodes and their respective OP-DATA are defined below: 412 6.1. NOP (OPCODE 0): 414 This is an HTCP-level ``ping.'' Responders are encouraged to process 415 NOP's with minimum delay since the requestor may be using the NOP RTT 416 (round trip time) for configuration or mapping purposes. The RESPONSE 417 code for a NOP is always zero (0). There is no OP-DATA for a NOP. NOP 418 requests with RD=0 cause no processing to occur at all. 420 6.2. TST (OPCODE 1): 422 Test for the presence of a specified content entity in a proxy cache. 423 TST requests with RD=0 cause no processing to occur at all. 425 TST requests have the following OP-DATA: 427 +0 (MSB) +1 (LSB) 428 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 429 0: | | 430 / SPECIFIER / 431 / / 432 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 434 RESPONSE codes for TST are as follows: 436 0 entity is present in responder's cache 437 1 entity is not present in responder's cache 439 TST responses have the following OP-DATA, if RESPONSE is zero (0): 441 +0 (MSB) +1 (LSB) 442 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 443 0: | | 444 / DETAIL / 445 / / 446 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 448 TST responses have the following OP-DATA, if RESPONSE is one (1): 450 +0 (MSB) +1 (LSB) 451 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 452 0: | | 453 / CACHE-HDRS / 454 / / 455 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 457 DETAIL is a set of cache, entity, and response headers. The cache 458 headers are described above. Entity and response headers are 459 defined by HTTP. 461 6.3. MON (OPCODE 2): 463 Monitor activity in a proxy cache (adds, deletes, replacements, etc). 464 Since interleaving of HTCP transaction over a single pair of UDP 465 endpoints is not supported, it is recommended that a unique UDP endpoint 466 be allocated by the requestor for each concurrent MON request. MON 467 requests with RD=0 are equivilent to those with RD=1 and TIME=0; that 468 is, they will cancel any outstanding MON transaction. 470 MON requests have the following OP-DATA structure: 472 +0 (MSB) 473 +---+---+---+---+---+---+---+---+ 474 0: | TIME | 475 +---+---+---+---+---+---+---+---+ 477 TIME is the number of seconds of monitoring output desired by the 478 initiator. Subsequent MON requests from the same initiator with 479 the same MSG-ID should update the time on a ongoing MON 480 transaction. This is called ``overlapping renew.'' 482 RESPONSE codes for MON are as follows: 484 0 accepted, OP-DATA is present and valid 485 1 refused (quota error -- too many MON's are active) 487 MON responses have the following OP-DATA structure, if RESPONSE is zero 488 (0): 490 +0 (MSB) +1 (LSB) 491 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 492 0: | TIME | ACTION | REASON | 493 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 494 2: | | 495 / IDENTITY / 496 / / 497 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 499 TIME is the number of seconds remaining for this MON transaction. 501 ACTION is a numeric code indicating a cache population action. Codes 502 are: 504 0 an entity has been added to the cache 505 1 an entity in the cache has been refreshed 506 2 an entity in the cache has been replaced 507 3 an entity in the cache has been deleted 509 REASON is a numeric code indicating the reason for an ACTION. Codes 510 are: 512 0 some reason not covered by the other REASON codes 513 1 a proxy client fetched this entity 514 2 a proxy client fetched with caching disallowed 515 3 the proxy server prefetched this entity 516 4 the entity expired, per its headers 517 5 the entity was purged due to caching storage limits 519 6.4. SET (OPCODE 3): 521 Inform a cache of the identity of an object. This is a ``push'' 522 transaction, whereby cooperating caches can share information such as 523 updated Age/Date/Expires headers (which might result from an origin 524 ``304 Not modified'' response) or updated cache headers (which might 525 result from the discovery of non-authoritative ``vary'' conditions or 526 from learning of second or third party cache locations for this entity. 527 RD is honoured. 529 SET requests have the following OP-DATA structure: 531 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 532 0: | | 533 / IDENTITY / 534 / / 535 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 537 RESPONSE codes are as follows: 539 0 identity accepted, thank you 540 1 identity ignored, no reason given, thank you 542 SET responses have no OP-DATA. 544 6.5. CLR (OPCODE 4): 546 Tell a cache to completely forget about an entity. RD is honoured. 548 CLR requests have the following OP-DATA structure: 550 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 551 0: | RESERVED | REASON | 552 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 553 2: | | 554 / SPECIFIER / 555 / / 556 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 558 REASON is a numeric code indicating the reason why the requestor is 559 asking that this entity be removed. The codes are as follows: 561 0 some reason not better specified by another code 562 1 the origin server told me that this entity does not exist 564 RESPONSE codes are as follows: 566 0 i had it, it's gone now 567 1 i had it, i'm keeping it, no reason given. 568 2 i didn't have it 570 CLR responses have no OP-DATA. 572 Clearing a URI without specifying response, entity, or cache headers 573 means to clear all entities using that URI. 575 7 - Security Considerations 577 If the optional AUTH element is not used, it is possible for 578 unauthorized third parties to both view and modify a cache using the 579 HTCP protocol. 581 8 - Acknowledgements 583 Mattias Wingstedt of Idonex brought key insights to the development of 584 this protocol. David Hankins helped clarify this document. 586 9 - References 588 [RFC1630] 589 T. Berners-Lee, ``Universal Resource Identifiers in WWW,'', RFC 1630, 590 CERN, June 1994. 592 [RFC2068] 593 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 594 ``Hypertext Transfer Protocol -- HTTP/1.1,'' RFC 2068, UC Irvine, 595 DEC, MIT/LCS, January 1997. 597 [RFC2104] 598 H. Krawczyk, M. Bellare, R. Canetti, ``HMAC: Keyed-Hashing for 599 Message Authentication,'' RFC 2104, IBM and UCSD, February, 1997. 601 [RFC2186] 602 D. Wessels, K. Claffy, ``Internet Cache Protocol (ICP), version 2,'' 603 RFC 2186, National Laboratory for Applied Network Research/UCSD, 604 September 1997. 606 10 - Author's Address 608 Paul Vixie 609 Vayu Communications 610 950 Charter Street 611 Redwood City, CA 94063 612 +1 650 779 7001 613 615 Duane Wessels 616 National Lab for Applied Network Research 617 USCD, 9500 Gilman Drive 618 La Jolla, CA 92093 619 +1 303 497 1822 620