idnits 2.17.1 draft-lovric-icp-ext-01.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 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2186]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 701 has weird spacing: '...hanisms for S...' == Line 702 has weird spacing: '... Format of I...' -- 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.) -- The document date (October 1, 1998) is 9340 days in the past. Is this intentional? 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: 'RFC1341' is mentioned on line 159, but not defined ** Obsolete undefined reference: RFC 1341 (Obsoleted by RFC 1521) == Unused Reference: 'RFC-1341' is defined on line 699, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Downref: Normative reference to an Informational RFC: RFC 2186 Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ivan Lovric 2 ICP Working Group France Telecom 3 October 1, 1998 4 Expires: April 1, 1999 5 draft-lovric-icp-ext-01.txt 7 Internet Cache Protocol Extension 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 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Abstract 31 ICP (see [RFC2186]) is a protocol allowing standardized communication 32 management between caches. 33 This document describes an extension to the ICP protocol whose aim is 34 to reach the following three goals : 36 - locating requested data more efficiently among a cache hierarchy, 37 - reducing network traffic between caches by exchanging compressed 38 data over different protocols, 39 - offering a suitable protocol for the forthcoming techniques of 40 push and intelligent prefetching. 42 Table of contents 44 1. Introduction......................................................2 46 2. Terminology.......................................................3 47 3. New OP codes......................................................4 49 3.1 ICP_OP_SET_INF...................................................4 51 3.2 ICP_OP_SET.......................................................5 53 3.3 ICP_OP_SET_OBJ...................................................6 55 3.4 ICP_OP_SET_TAB_INF...............................................7 57 3.5 ICP_OP_SET_TAB...................................................8 59 3.6 ICP_OP_SET_TAB_OBJ...............................................9 61 3.7 ICP_OP_GET_INF..................................................10 63 3.8 ICP_OP_INF......................................................10 65 4. New ICP Option Flags.............................................11 67 5. Security.........................................................12 69 6. Format of a list of URLs file ...................................12 71 6.1 Format description..............................................12 73 6.2 Example.........................................................13 75 7. Conclusion.......................................................14 77 8. References.......................................................14 79 9. Authors' Address.................................................15 81 1. Introduction 83 The ICP protocol allows communication between a hierarchy of caches by 84 transmitting messages between the different caches making up this 85 hierarchy. 86 First of all, the messages transmitted by a cache to locate a specific 87 object are sent to sibling caches which are placed at the same level 88 in the hierarchy. Then, the caches placed at the upper level are 89 queried if the replies from sibling caches did not succeed. 90 The disadvantage of this communication system between caches resides 91 in the large number of messages sent to sibling and upper level caches 92 in order to find a particular object, but without being sure to find 93 it among the whole hierarchy. This large number of messages generates 94 a supplemental network load which reduces network capabilities. 95 In order to limit the amount of query messages, it should be more 96 convenient for each cache to know all or part of the content of other 97 caches, thus permitting a faster way to locate the requested 98 information. 100 Furthermore, the broadcasting technologies are evolving very fast. 101 Satellite and multicast techniques make possible the emission of a 102 unique information which will reach a lot of different receivers. 103 Also, the recent arrival of artificial intelligence technologies on 104 the net enables new intelligent prefetching solutions to be 105 developped, so that information will be placed near the end users even 106 before their request. 107 The actual version of ICP does not offer a convenient way to push 108 information between caches, and to take advantage of the forthcoming 109 technologies. 110 To be able to push data between caches, it should be useful to 111 remotely command a cache in order to modify its content, and to take 112 advantage of compression techniques, so that the amount of network 113 traffic necessary to push objects could be limited. 115 All these elements work towards the necessity to extend the ICP 116 protocol in order to permit better interactivity between the different 117 caches that cooperate within the hierarchy . For each cache, this 118 interactivity must result firstly in the knowledge of the content of 119 other caches so that requested information could be efficiently 120 located. Secondly, this interactivity must also result in the 121 acceptance of commands from other caches which must be able to 122 remotely update the content of a given cache. In order to optimize 123 data transfer rates and to minimize network traffic, the hierarchical 124 cache system built over ICP must be able to use the most efficient 125 protocol for data transmission over a specific link, and must allow 126 data compression. 127 To reach these goals, new operation codes have been created that reuse 128 the initial structure of ICP messages, thus preserving compatibility 129 with protocol ICP-v2. 131 2. Terminology 133 client cache: 134 In this document, client cache represents the cache which is asked to 135 process an insert or a delete command. 137 Server cache: 138 Server cache represents the cache which asks a client cache to process 139 an insert or a delete command. 141 URL : 142 An Uniform Ressource Locator is used to locate resources, by providing 143 an abstract identification of the resource location. 144 (see [RFC1738]) 146 alias : 147 An alias is the duplication of a particular cached object. 148 A new URL name is given to the alias, and the protocol used for 149 accessing the alias can be different from the original protocol. The 150 alias can be compressed to minimize storage space and network traffic. 152 object : 153 Any kind of text or binary data which can be cached. 155 Ressource : 156 In this document, a ressource is equivalent to an object. 158 MIME content-type : 159 The MIME (Multipurpose Internet Mail Extensions, see [RFC1341]) 160 content-type describes the format of a type of content for an object. 161 In this document, the MIME content-type encoding is only used for 162 compressed objects, so that the format can only fit in the form 163 "application/subtype". 165 3. New Opcodes 167 The following table shows the new ICP opcodes : 169 Value Name 170 ----- ------------------ 171 24 ICP_OP_SET_INF 172 25 ICP_OP_SET 173 26 ICP_OP_SET_OBJ 174 27 ICP_OP_SET_TAB_INF 175 28 ICP_OP_SET_TAB 176 29 ICP_OP_SET_TAB_OBJ 177 30 ICP_OP_GET_INF 178 31 ICP_OP_INF 180 3.1 ICP_OP_SET_INF 182 This message informs the client cache that a cached URL is available 183 on the server cache. The client cache can update its internal tables 184 concerning the server cache content (similar to ICP_OP_ADVERTISE). 186 The information supplied with the message also describes the possible 187 existence of an alias and its compression method. 189 ICP_OP_SET_INF payload format : 191 0 1 2 3 4 192 012345678901234567890123456789012 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 / Null terminated URL / 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 / Null terminated URL for alias / 197 / if flag ICP_FLAG_ALIAS / 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | + 200 / Null terminated MIME / 201 / content-type if flag / 202 / ICP_FLAG_COMPRESSED_ALIAS / 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 If the flag ICP_FLAG_SET_DEL is set , then the server cache no longer 206 holds the URL specfified within the message payload (similar to 207 ICP_OP_UNADVERTISE). 209 If the flag ICP_FLAG_ALIAS is set , then the URL is followed by the 210 aliased URL within the payload. 212 If the flag ICP_FLAG_COMPRESSED_ALIAS is set , then the object pointed 213 to by the aliased URL is compressed. The compression method is 214 described by the MIME content-type following the URL of the alias. 216 3.2 ICP_OP_SET 218 This message is sent to ask the client cache for the delayed loading 219 of a specific URL or for the delayed deletion of this URL on the 220 client cache. 222 ICP_OP_SET payload format : 224 0 1 2 3 4 225 012345678901234567890123456789012 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | delay + 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 / Null terminated URL / 231 / / 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 / Null terminated URL for alias / 235 / if flag ICP_FLAG_ALIAS / 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | + 238 / Null terminated MIME / 239 / content-type if flag / 240 / ICP_FLAG_COMPRESSED_ALIAS / 241 / / 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 The maximum delay before the client cache loads the given URL, is 245 indicated within the message as a 4-octet integer representing the 246 time expressed in milliseconds. The delay counting starts when the 247 client cache receives the message. 248 If a null delay is given, the URL has to be immediately loaded by the 249 client cache. 251 If an alias is given, the client cache must load the alias located at 252 the given URL for the alias. After loading, the alias is eventually 253 decompressed, and must be renamed with the name of the original URL. 255 If flag ICP_FLAG_SET_DEL is set, a delete command of the given URL 256 must be processed within the indicated delay. 258 If the client cache does not allow insert or delete commands to be 259 done, a message ICP_OP_DENIED must be sent with flags 260 ICP_FLAG_DENY_INSERT or ICP_FLAG_DENY_DELETE set. 262 If the client cache does not allow aliases to be processed, a message 263 ICP_OP_DENIED must be sent with flag ICP_FLAG_DENY_ALIAS set. 265 If the client cache does not allow compressed aliases to be processed, 266 a message ICP_OP_DENIED must be sent with flag 267 ICP_FLAG_DENY_COMPRESSION set. 269 If the client cache does not support processing of the aliased URL 270 protocol, or of the compression method, a message ICP_OP_ERR must be 271 sent with flags ICP_FLAG_ERR_PROTOCOL or ICP_FLAG_ERR_COMPRESSED set. 273 3.3 ICP_OP_SET_OBJ 275 This message is identical to ICP_OP_SET except that the object is 276 directly included within the payload. In order to preserve 277 compatibility with the previous version of ICP, the total size of the 278 message must not exceed 16384 octets. 280 ICP_OP_SET_OBJ payload format : 282 0 1 2 3 4 283 012345678901234567890123456789012 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | delay + 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 / Null terminated URL / 289 / / 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | + 292 / Null terminated MIME / 293 / content-type if flag / 294 / ICP_FLAG_COMPRESSED_OBJ / 295 / / 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 / Object / 299 / / 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 If the flag ICP_FLAG_COMPRESSED_OBJ is set , then the object is 303 compressed with the compression method included within the payload, 304 located prior to the object. 306 If the client cache does not allow objects to be included within 307 payload, a message ICP_OP_DENIED must be sent with flag 308 ICP_FLAG_DENY_OBJ set. 310 If the client cache does not allow included objects to be compressed, 311 a message ICP_OP_DENIED must be sent with flag 312 ICP_FLAG_DENY_COMPRESSION set. 314 Remark : 315 Before sending a compressed object, the server cache should verify 316 that the client cache has enabled this functionnality to be processed, 317 and is able to decompress the object, by sending a message ICP_OP_INF. 319 3.4 ICP_OP_SET_TAB_INF 321 This message informs the client cache that a list of cached URLs is 322 available on the server cache. By requesting this list at the given 323 URL, the client cache can update its internal tables concerning the 324 server cache content. 325 An alias of the list, eventually compressed, may exist. 327 The list of URLs is a text formatted object described in 5. Its URL 328 is included within the message payload. 330 ICP_OP_SET_TAB_INF payload format : 332 0 1 2 3 4 333 012345678901234567890123456789012 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | delay + 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Required storage space (ko) + 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Number of URLs| + 340 +-+-+-+-+-+-+-+-+ + 341 | | 342 / Null terminated URL / 343 / / 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 / Null terminated URL for alias / 347 / if flag ICP_FLAG_ALIAS / 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | + 350 / Null terminated MIME / 351 / content-type if flag / 352 / ICP_FLAG_COMPRESSED_ALIAS / 353 / / 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 If the flag ICP_FLAG_SET_DEL is set , then the list contains at least 357 one URL that has been deleted on the server cache. 359 If the list contains at least one URL pointing to an alias, then the 360 flag ICP_FLAG_ALIAS_IN_LIST must be set. 362 If the list itself is not aliased, but contains compressed aliases 363 (flag ICP_FLAG_ALIAS unset, flag ICP_FLAG_ALIAS_IN_LIST set, 364 flag ICP_FLAG_ALIAS_COMPRESSED set), then the compression method for 365 aliases must be included within the payload. 367 If the list is aliased and the alias is compressed (flag 368 ICP_FLAG_ALIAS set and flag ICP_FLAG_COMPRESSED_ALIAS set), then the 369 compression method for eventual compressed aliases within the list 370 must be the same as the one used to compress the alias of the list. 372 The required storage space (unit expressed in kilo-octets) give 373 information to the client cache about the amount of space necessary to 374 store all the objects pointed to by the URLs indicated in the list 375 after decompression of compressed objects. 377 The number of URLs in the list is indicated in a 2-octet field within 378 the payload. 380 3.5 ICP_OP_SET_TAB 382 This message is sent to ask the client cache for the delayed loading 383 of a list of URLs and for the delayed loading of all the URLs within 384 the list. 386 ICP_OP_SET_TAB payload format : 388 0 1 2 3 4 389 012345678901234567890123456789012 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | delay + 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Required storage space (ko) + 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Number of URLs| + 396 +-+-+-+-+-+-+-+-+ + 397 / Null terminated URL / 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 / Null terminated URL for alias / 401 / if flag ICP_FLAG_ALIAS / 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 / Null terminated MIME / 404 / content-type if flag / 405 / ICP_FLAG_COMPRESSED_ALIAS / 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 If the flag ICP_FLAG_SET_DEL is set , then the list contains at least 409 one delete command to process on the client cache. 410 If this flag is not set, and the list nevertheless contains delete 411 commands, those commands must not be processed. 413 If the client cache does not allow aliases whose URL is placed either 414 in payload or in a list file to be processed, a message ICP_OP_DENIED 415 must be sent with flag ICP_FLAG_DENY_ALIAS set. 417 3.6 ICP_OP_SET_TAB_OBJ 419 This message is sent to ask the client cache for the delayed loading 420 of a list of URLs. 422 The list of URLs is included within the message and is formatted as 423 decribed in 5. It may be compressed. 425 ICP_OP_SET_TAB_OBJ payload format : 427 0 1 2 3 4 428 012345678901234567890123456789012 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | delay + 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Required storage space (ko) + 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Number of URLs| + 435 +-+-+-+-+-+-+-+-+ + 436 | + 437 / Null terminated MIME / 438 / content-type if flag / 439 / ICP_FLAG_COMPRESSED_OBJ / 440 / or flag / 441 / ICP_FLAG_COMPRESSED_ALIAS / 442 / / 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | | 445 / List of URLs / 446 / / 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 If the flag ICP_FLAG_COMPRESSED_OBJ is set , then the list is 450 compressed using the compression method included within the payload. 452 If the flag ICP_FLAG_COMPRESSED_ALIAS is set , then the list contains 453 compressed aliases. 455 If the list contains compressed aliases and is itself compressed 456 (flag ICP_FLAG_COMPRESSED_OBJ set and flag ICP_FLAG_COMPRESSED_ALIAS 457 set), then the compression method for aliases must be the same as the 458 one used to compress the list. 460 If the list contains compressed aliases and is itself not compressed 461 (flag ICP_FLAG_COMPRESSED_OBJ unset and flag 462 ICP_FLAG_COMPRESSED_ALIAS set), then the compression method for 463 aliases is indicated within the payload format. 465 3.7 ICP_OP_GET_INF 467 This message is sent to a client cache in order to obtain information 468 about its capabilities and permitted commands. 470 3.8 ICP_OP_INF 472 This OP code can be sent by a client cache in reply to an 473 ICP_OP_GET_INF message, or directly, in order to inform other caches 474 about operations which are supported. 476 The different flags used for information are : 478 - ICP_FLAG_ALLOW_INSERT 479 - ICP_FLAG_ALLOW_DELETE 480 - ICP_FLAG_ALLOW_COMPRESSION 481 - ICP_FLAG_ALLOW_OBJ 482 - ICP_FLAG_ALLOW_ALIAS 484 ICP_OP_INF payload format : 486 0 1 2 3 4 487 012345678901234567890123456789012 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Max available space for insert| 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 / NULL terminated list of / 493 / compression formats / 494 / / 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 / NULL terminated list of / 497 / protocols / 498 / / 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 If the flag ICP_FLAG_ALLOW_INSERT is set , then the maximum available 502 space information (unit expressed in kilo-octets) indicates to the 503 server cache the largest amount of uncompressed object storage space 504 that can be currently inserted in the client cache. 506 If the flag ICP_FLAG_ALLOW_COMPRESSION is set, then a list of the MIME 507 content-types used for data compression that can be processed by the 508 client cache will be included within the message. The different 509 elements of this list are separated by a comma. 511 An example of a list of supported data compression types (null 512 terminated): 513 application/x-gzip,application/x-tar,application/x-zip-compressed 515 If the flag ICP_FLAG_ALLOW_ALIAS is set, then a list of the protocols 516 that can be processed by the client cache will be included within the 517 message. The different elements of this list are separated by a comma. 519 An example of a list of protocols (null terminated): 520 http,ftp,file 522 4. ICP Option Flags 524 0x00000010 ICP_FLAG_COMPRESSED_OBJ 525 This flag indicates that the object joined to the message is 526 compressed. 528 0x00000020 ICP_FLAG_SET_DEL 529 This flag indicates that the message contains at least one delete 530 command to process on the client cache. 532 0x00000040 ICP_FLAG_ALIAS 533 This flag indicates that the message contains at least one alias. 535 0x00000080 ICP_FLAG_COMPRESSED_ALIAS 536 This flag indicates that the message or list of URLs contains 537 compressed aliases. 539 0x00000100 ICP_FLAG_ALIAS_IN_LIST 540 This flag indicates that the list of URLs contains at least one URL 541 pointing to an alias. 543 0x00000200 ICP_FLAG_ERR_PROTOCOL 544 This flag indicates that the client cache does not process the 545 protocol used for an URL or an aliased URL. 547 0x00000400 ICP_FLAG_ERR_COMPRESSED 548 This flag indicates that the client cache does not process the 549 compression method used for a compressed object. 551 0x00001000 ICP_FLAG_DENY_INSERT 552 This flag indicates that the client cache does not allow insert 553 commands from a server cache to be done. 555 0x00002000 ICP_FLAG_DENY_DELETE 556 This flag indicates that the client cache does not allow delete 557 commands from a server cache to be done. 559 0x00004000 ICP_FLAG_DENY_COMPRESSION 560 This flag indicates that the client cache allows neither aliases nor 561 payload included objects to be processed. 563 0x00008000 ICP_FLAG_DENY_OBJ 564 This flag indicates that the client cache does not allow the 565 server cache to include objects within messages ICP_SET_OBJ and 566 ICP_SET_TAB_OBJ. 568 0x00010000 ICP_FLAG_DENY_ALIAS 569 This flag indicates that the client cache does not allow aliases whose 570 URL is placed either in payload or in a list file to be processed. 572 0x04000000 ICP_FLAG_ALLOW_INSERT 573 This flag indicates that the client cache allows insert commands to be 574 processed. 576 0x02000000 ICP_FLAG_ALLOW_DELETE 577 This flag indicates that the client cache allows delete commands to be 578 processed. 580 0x01000000 ICP_FLAG_ALLOW_COMPRESSION 581 This flag indicates that the client cache allows compressed objects to 582 be processed. 584 0x00800000 ICP_FLAG_ALLOW_OBJ 585 This flag indicates that the client cache allows objects to be 586 Included within messages ICP_OP_SET_OBJ and ICP_OP_SET_TAB_OBJ. 588 0x00400000 ICP_FLAG_ALLOW_ALIAS 589 This flag indicates that the client cache allows aliases to be 590 processed. 591 When receiving an aliased URL, the client cache must, first of all 592 decompress the alias it if it was compressed, and then rename it 593 with the original name of the URL. 595 5. Security 597 To provide strong integrity and authentication mechanisms during 598 exchanges between server and client caches, the IP Security 599 Architecture must be used with the IP Authentication Header (see 600 [RFC1825] and [RFC1826]). 602 6. Format of a list of URLs file 604 6.1 Format description 605 In the list file, URLs are stored hierarchically respecting the 606 following tree: 608 - protocol, 609 - host, 610 - port, 611 - path, 612 - file name 614 To accelerate the location of a particular URL within the list, 615 specfic weights have been applied to the different hierarchical 616 levels : 618 - 1 for protocol, 619 - 2 for host 620 - 3 for port, 621 - 4 for path, 622 - 5 for file name 624 Each filename must be preceded by a command code : 626 - N for No operation, is only used to inform the client cache about 627 the content of the server cache 628 - I to process an insert command on the client cache, 629 - D to process a delete command on the client cache, or to inform it 630 that a particular URL has been deleted on the server cache 632 The file name may be followed by an URL which indicates the location 633 of an alias. The alias may be compressed ; if so , the compression 634 method is the same as the one indicated in the message payload. 635 In the list file, the code to describe aliases is : 637 - A for Alias 638 - AC for Alias Compressed 640 Assuming that the http is the default protocol, and port 80 is the 641 default port for http servers, the refering lines in the list file can 642 be omitted. 644 Remark : 645 By this format specification, it is possible to use a protocol of 646 type file:// for aliases. In this case, aliases can be directly 647 accessed from the file system of the client cache. 649 6.2 Example 651 To make the understanding of the format of a list of URLs file easier, 652 the following example explains how the four URLs listed below should 653 be formatted in the list file. A compressed alias of the object 654 pointed to by the URL http://www.url1.org/index.html exists and is 655 located at the URL ftp://ftp.url1.org/index.html.gz . 657 - http://www.url1.org/index.html 658 - http://www.url1.org/logo.gif 659 - http://www.url2.com/dir2/file2.html 660 - http://www.url2.com/dir2/file2.gif 662 The list of URLs file should be : 663 1,http 664 2,www.url1.org 665 3,80 666 4,/ 667 5,I,index.html,AC,ftp://ftp.url1.org/index.html.gz 668 5,I,logo.gif 669 2,www.url2.com 670 3,80 671 4,/dir2/ 672 5,I,file2.html 673 5,I,file2.gif 675 Refering to the fact that http is the default protocol and port 80 is 676 the default port for http servers, an other form for the list file 677 could be : 679 2,www.url1.org 680 4,/ 681 5,I,index.html,AC,ftp://ftp.url1.org/index.html.gz 682 5,I,logo.gif 683 2,www.url2.com 684 4,/dir2/ 685 5,I,file2.html 686 5,I,file2.gif 688 7. Conclusion 690 This draft has described the ICP protocol extensions necessary to 691 answer the current needs of network traffic management, and the next 692 needs of push technologies. 693 It also demonstrates that ICP protocol can be extended because of its 694 evolutional structure. So, new services will probably appear which 695 will rely on the capabilities of this protocol. 697 8. References 699 [RFC-1341] 700 Borenstein, N., and N. Freed, "MIME (Multipurpose 701 Internet Mail Extensions): Mechanisms for Specifying and 702 Describing the Format of Internet Message Bodies", 703 RFC 1341, Bellcore, June, 1992. 705 [RFC1738] 706 Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource 707 Locators (URL)", RFC 1738, CERN, Xerox PARC, University of 708 Minnesota, December 1994. 710 [RFC1825] 711 Atkinson, R., "Security Architecture for the Internet Protocol", 712 RFC 1825, NRL, August 1995. 714 [RFC1826] 715 Atkinson, R., "IP Authentication Header", RFC 1826, NRL, 716 August 1995. 718 [RFC2186] 719 D. Wessels, K. Claffy,``Internet Cache Protocol (ICP), version 2,'' 720 RFC 2186, National Laboratory for Applied Network Research/UCSD, 721 September 1997 723 9. Author's address 725 Ivan Lovric 726 France Telecom 727 Centre National d'Etudes en Telecommunications 728 42, rue Coutures 729 BP 6243 14066 Caen Cedex 730 France 732 Phone: +33 2 31 75 91 25 733 Fax: +33 2 31 73 56 26 734 E-mail: ivan.lovric@cnet.francetelecom.fr