idnits 2.17.1 draft-beck-opes-psrl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 4) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (November 17, 2000) is 8553 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 255 looks like a reference -- Missing reference section? '3' on line 102 looks like a reference -- Missing reference section? '4' on line 74 looks like a reference -- Missing reference section? '5' on line 350 looks like a reference -- Missing reference section? '6' on line 361 looks like a reference -- Missing reference section? '7' on line 347 looks like a reference -- Missing reference section? '8' on line 364 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Beck 3 M. Hofmann 4 Expires: May 2001 Lucent Technologies 5 Document: draft-beck-opes-psrl-00.txt November 17, 2000 6 Category: Informational 8 PSRL: A Rule Specification Language for Proxy Services 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Proxy services are a new class of applications running on caching 34 proxies or dedicated application servers, preferably at the network 35 edge. They are described in [2] and [3]. Execution of proxy services 36 is triggered by certain conditions. These conditions are service 37 specific and have to be provided by the party on behalf of which the 38 affected service modules are executed. 40 The Proxy Service Rule Specification Language (PSRL) is an XML-based 41 language that can be used to describe service specific execution 42 rules. It allows a service provider to tell a proxy caching provider 43 when and how the services should be executed. 45 Table of Contents 47 1 Terminology....................................................2 48 2 Problem Description and Goals..................................3 49 3 PSRL Syntax and Grammar........................................4 50 3.1 The "rulemodule" Element.....................................4 51 3.2 The "owner" Element..........................................4 52 3.2.1 Attributes of "owner".......................................4 53 3.2.2 The "name" Element..........................................4 54 3.2.3 The "id" Element............................................5 55 3.3 The "protocol" Element.......................................5 56 3.4 Examples of the "owner", "name", "id", "protocol" Elements...5 57 3.5 The "rule" Element...........................................6 58 3.5.1 Attributes of "rule"........................................6 59 3.5.2 The "property" Element......................................7 60 3.5.3 The "action" Element........................................8 61 3.5.4 Examples of the "rule", "property" and "action" elements....8 62 4 Order of Service Execution.....................................9 63 5 Security Considerations........................................9 64 6 References....................................................10 65 7 Author's Addresses............................................10 66 A Appendix - PSRL DTD...........................................11 67 B Appendix - Rule Module Examples...............................11 69 1 Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [4]. 75 rule module 77 A rule module contains a set of rules and information about the rule 78 module owner. 80 rule 82 Rules contain conditions and actions that are to be executed if the 83 conditions are met. 85 action 87 The execution of a local/remote service module or a proxy library 88 function. Message properties MAY be modified as the result of the 89 execution. 91 service module 93 Service modules are executable code modules that can be executed in 94 a local service execution environment on the caching proxy or a 95 remote service execution environment on a dedicated application 96 server. They may run on behalf of content providers, access 97 providers, and clients. 99 2 Problem Description and Goals 101 The three parties that may wish to run value-added proxy services 102 (as described in [2] and [3]) are the same parties that are involved 103 in a typical Web transaction: 105 1. Client 106 2. Access provider (e.g. an ISP) 107 3. Content provider 109 Each party must be able to express the conditions under which they 110 wish to run a service. A content provider, for instance, might want 111 to adapt its pages for users with small wireless devices. Providers 112 of free Internet services might want to insert advertisements into 113 all HTML pages served to their clients. Web users may wish to have 114 certain Web pages translated into a different language. 116 These examples demonstrate the need for rules that tell the caching 117 proxy when to run what service. These rules must be provided to the 118 caching proxy by the three parties on behalf of which services may 119 be executed. A rule engine on the caching proxy evaluates rules that 120 apply to incoming requests/outgoing responses in order to determine 121 what service modules need be executed when and in what order. 123 As the caching proxy processing the rules is not necessarily 124 maintained by the party that authors the rules, a standard 125 specification language is required. 127 This document defines the Proxy Services Rule Specification Language 128 (PSRL) in an attempt to create a standard rule format that will be 129 supported by vendors of service enabled caching proxies and by third 130 parties offering proxy service applications. 132 The Proxy Services Rule Specification Language defined in this 133 document also serves as a standard representation of rules for proxy 134 services. This facilitates the exchange and discussion of these kind 135 of rules between and within groups of rule authors. 137 It is beyond the scope of this document to define a secure and 138 reliable mechanism for transferring rule files to caching proxies. 139 Likewise, this document does not describe the specifics of how to 140 (efficiently) process rules on the caching proxy. 142 3 PSRL Syntax and Grammar 144 PSRL is an application of XML. Thus, its syntax is governed by the 145 rules of the XML syntax as defined in [5], and its grammar is 146 specified by a DTD, or Document Type Definition. The PSRL DTD can be 147 found in Appendix A. 149 Valid and well-formed PSRL documents consist of one or more rule 150 modules. Each rule module contains a set of rules and information 151 about the rule module provider. Rule modules are provided by a 152 content provider, an access provider, or by a client (although 153 usually indirectly through an access provider). The rules contained 154 in rule modules each consist of a number of conditions and a number 155 of consequent actions that must be executed if the conditions are 156 met. The conditions within a rule refer to message properties in the 157 request or response of a given Web transaction. They are met if the 158 property value matches the pattern specified in the condition. 160 3.1 The "rulemodule" Element 162 The "rulemodule" element is the root element for all rule modules 163 and MAY/MUST contain the following elements (see also PSRL DTD in 164 Appendix A). 166 3.2 The "owner" Element 168 The "owner" element specifies the owner of the rule module. Each 169 rule module can have exactly one owner. 171 3.2.1 Attributes of "owner" 173 Name Values 174 ---------------------------------------------------- 175 class content provider|access provider|client 177 The "class" attribute assigns a rule module owner to one of the 178 three types of rule module providers: content providers, access 179 providers, and clients. 181 3.2.2 The "name" Element 183 The "name" element contains a descriptive name for the rule module 184 owner. This could be the company name for content and access 185 providers and a customer login for clients. The name does not have 186 to be unique among rule module owners. 188 3.2.3 The "id" Element 190 The "id" element contains an identifier for the rule module owner. 191 The identifier MUST be unique within a class of rule module 192 providers. The "id" element determines whether a particular Web 193 transaction is relevant to a rule module and thus, whether the 194 contained rules have to be processed for this particular Web 195 request/response. For example, a rule module provided by a content 196 provider should only be processed for Web request referring to Web 197 resources owned by the same content provider. 199 Therefore, if the rule module owner is a content provider, the "id" 200 element MUST contain the domain name(s) of the content provider. If 201 a content provider owns more than one domain and the relevant rule 202 module pertains to more than one of them, the "id" element MAY even 203 contain more than one domain name separated by the "|" character 204 (see "owner" example). The specified domain name(s) MAY also contain 205 a port number. If no port number is specified, then the default port 206 for the specified protocol is assumed, e.g. 80 for HTTP. 208 If the rule module owner is an access provider, then the "id" 209 element is of less importance, since a particular caching proxy is 210 usually associated with only one specific access provider. 212 If the rule module owner is a client, then a unique client 213 identifier, e.g. a customer id, MUST be chosen in order to associate 214 client rule modules with client requests. If the client's access 215 provider does not assign dynamic IP numbers to its customers, the 216 "id" element can also contain the IP number of the module owner. 217 Otherwise, the dynamic IP addresses of incoming client requests MUST 218 be mapped to the unique client "id" element value in order to 219 determine whether a specific rule module must be processed. 221 3.3 The "protocol" Element 223 The "protocol" element contains the name of the protocol acronym the 224 rule module pertains to. For now, only "http" is supported. In a 225 future version of this document other protocols will be supported as 226 well. 228 3.4 Examples of the "owner", "name", "id", "protocol" Elements 230 231 Yahoo Inc. 232 www.yahoo.com|dir.yahoo.com:8000 233 234 http 236 237 abeck 238 205.167.45.1 239 240 http 242 3.5 The "rule" Element 244 The "rule element" contains one or more "property" elements. 246 3.5.1 Attributes of "rule" 248 Name Values 249 ---------------------------- 250 processing-point 1|2|3|4 252 The "processing-point" attribute specifies at which of the four 253 points in figure 1 a rule must be processed by the rule engine on 254 the caching proxy. The four "processing-points" are derived from the 255 Extensible Proxy Services Framework as described in [2]. Other 256 implementation architectures might define additional "processing- 257 points", which can be specified with PSRL by allowing additional 258 values for the "processing-point" attribute. 260 Figure 1 shows the typical HTTP data flow between a client, a 261 caching proxy, and an origin server. The four processing points (1- 262 4) represent locations in the round trip message flow where rules 263 can be processed and service modules can be executed. Note that the 264 message flow may skip points 3 and 4 after point 1 if the requested 265 object can be served from cache. 267 +--------+ +-----------+ +--------+ 268 | |<------|4 3|<------| | 269 | Client | | Caching | | Origin | 270 | | | Proxy | | Server | 271 | |------>|1 2|------>| | 272 +--------+ +-----------+ +--------+ 274 Figure 1: Rule Processing/Service Execution Points 276 Point 1: Client Request 277 A HTTP request from a client has been received. A possible 278 cache lookup has not yet occurred. 280 Point 2: Proxy Request 281 The requested Web object cannot be served from the cache and 282 the origin server is about to be contacted for the HTTP 283 resource. 285 Point 3: Origin Server Response 286 The HTTP response from the origin server has been received. It 287 has not yet been stored in the cache. 289 Point 4: Proxy Response 290 The HTTP response from the cache or the origin server is about 291 to be sent back to the client. 293 Depending on the service type, rules may be processed and services 294 may be executed at any of the four points outlined in figure 1. A 295 virus scanning service for instance should be executed at point 3 in 296 figure 1 in order to scan all Web objects for viruses before they 297 can be stored in the cache. A URL-based request filtering service on 298 the other hand should be executed at point 1 and an ad insertion 299 service will probably be executed at point 4. 301 We can imagine that in the future there will be a need to have more 302 processing points (at a finer granularity) than the ones mentioned 303 above. This will be reflected in a future version of this document. 305 3.5.2 The "property" Element 307 The "property" element contains one or more other "property" 308 elements and one or more "action" elements. "property" elements are 309 conditions, that, if met, will lead to the execution of the service 310 modules specified in the contained "action" elements. Nested 311 "property" elements represent a hierarchical "AND" relationship. 312 This means that an inner "property" condition can only be true, if 313 the outer "property" condition is true and so forth. 315 Attributes of "property" 317 Name Values 318 ---------------------------- 319 name CDATA 320 matches CDATA 322 The "name" attribute specifies the name of the message property that 323 is to be matched. This can be either a request or a response message 324 property. The protocol specified in the "protocol" element 325 determines what are legal property names. If the message property is 326 an HTTP request or response header, the list of legal header names 327 can be taken from [6]. 329 For HTTP messages, the following property names are defined in 330 addition to the list of legal HTTP headers in [6]: 332 Property Name Refers to 333 -------------------------------------------------------------- 334 "request-line" the first line of a HTTP request 335 "response-line" the first line of a HTTP response 336 "request-path" the relative path of the request URI 337 "request-body" the body of a HTTP request (POST) 338 "response-body" the body of a HTTP response 339 "user-id" a value to identify a user, assigned by 340 the access provider and unique for all 341 customers of the same access provider 343 The matches "matches" attribute specifies the pattern against which 344 the property value MUST be compared by the rule engine on the 345 caching proxy. The "matches" pattern MUST be a regular expression 346 compliant with the basic or extended regular expression syntax as 347 defined in [7]. 349 If needed, the double-quote character (") MUST be represented in any 350 attribute value as """ or (as specified in [5]). 352 3.5.3 The "action" Element 354 The "action" element contains the name of the service module that is 355 to be executed on the caching proxy or a dedicated application 356 server. Instead of a service name the "action" element MAY also 357 contain the name of a built-in proxy library function. 359 Any arguments MAY be passed as part of the service module name, 360 using the standard "?"-encoding of attribute-value pairs used in 361 HTTP [6]. If the service module resides on a dedicated application 362 server and ICAP [8] will be used as the transport protocol, the 363 "action" element MAY contain an ICAP-URI as defined in the current 364 version of the ICAP specification [8]. 366 Only one service/function/ICAP-URI MAY be specified per "action" 367 element. A "property" element, however, MAY contain several "action" 368 elements. 370 3.5.4 Examples of the "rule", "property" and "action" elements 372 373 374 375 376 377 378 icap://trans.net/translate?mode=respmod 379 380 381 383 384 385 386 387 icap://mcaffee.com/viruscheck?mode=respmod 388 389 391 4 Order of Service Execution 393 The order in which service modules on the caching proxy are executed 394 may change the final result of a Web transaction. For example, an ad 395 insertion service executed against the result of a Web page 396 translation service may produce a different result than a reverse 397 execution order. 399 Up to three rule modules may have to be processed by a caching proxy 400 per Web transaction. The order in which these rule modules are 401 processed MUST reflect the order in which the message flow reaches 402 the rule module owners. This means that for incoming requests at 403 points 2 and 3 in figure 1, the order MUST be: 405 1. Client rule module 406 2. Access provider rule module 407 3. Content provider rule module 409 For outgoing responses at points 3 and 4, the order MUST be: 411 1. Content provider rule module 412 2. Access provider rule module 413 3. Client rule module 415 Within a single rule module, the caching proxy MUST process and 416 execute all rules and actions IN THE ORDER THEY ARE SPECIFIED in the 417 rule module (both within "property" and "rule" elements). If the 418 rule processor determines that an action must be executed, it MUST 419 do so BEFORE continuing the rule matching process, since service 420 modules MAY modify message property values. This may influence the 421 result of subsequent pattern matches. 423 The authors of rule modules should therefore pay special attention 424 to the order of the "action" elements in their rule modules, as this 425 may have an effect on the final result. 427 5 Security Considerations 429 Although beyond the scope of this document, it is clearly necessary 430 to define a secure mechanism for transferring rule modules to 431 caching proxies. This will include authenticating and authorizing 432 rule module owners and caching proxies. The integrity of rule 433 modules must be guaranteed through the use of strong encryption as 434 they are transferred over the Internet. 436 Also, a security context must be established on the caching proxy 437 for each rule module to ensure that rule modules may not execute 438 service modules or call proxy library functions without without 439 being authorized to do so. Service modules running on the caching 440 proxy also must be restrained from consuming too many resources on 441 the caching proxy. 443 6 References 445 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 446 9, RFC 2026, October 1996 448 2 Tomlinson, G., et al., "Extensible Proxy Services Framework", 449 http://www.ietf.org/internet-drafts/draft-tomlinson-epsfw-00.txt, 450 July 2000 452 3 Hofmann, M., Beck, A., "Example Services for Network Edge 453 Proxies", Workshop on Extensible Proxy Services Framework, San 454 Jose, CA, USA, September 13, 2000. Available at 455 http://www.cs.utah.edu/~horman/opencache/draft-hofmann-isfnep- 456 00.txt 458 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 459 Levels", Request for Comments 2119, Harvard University, March 460 1997 462 5 Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second 463 Edition), http://www.w3.org/TR/2000/REC-xml-20001006, 464 October 2000 466 6 Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", 467 Request for Comments 2616, June 1999 469 7 ISO/IEC DIS 9945-2:1992, Information technology - Portable 470 Operating System Interface (POSIX) - Part 2: Shell and Utilities 471 (IEEE Std 1003.2-1992); X/Open CAE Specification, Commands and 472 Utilities, Issue 4, 1992 474 8 Elson, J., et al., "ICAP, the Internet Content Adaptation 475 Protocol", http://www.i-cap.org/icap_v1-25.txt, January 2000 477 7 Author's Addresses 479 Andre Beck 480 Markus Hofmann 481 Bell Laboratories 482 Lucent Technologies 483 101 Crawfords Corner Rd. 484 Holmdel, New Jersey 07733 485 Phone: (732) 332-5983 486 Email: {abeck, hofmann}@bell-labs.com 488 A Appendix - PSRL DTD 490 491 492 493 494 495 496 497 498 500 501 502 504 B Appendix - Rule Module Examples 506 Content Provider Rule Module Example for Advertisement Insertion 507 Service 509 510 511 512 Lucent Technologies 513 www.lucent.com 514 515 http 516 517 518 519 520 521 icap://adserver.net/insertad?mode=respmod 522 523 524 525 527 Access Provider Rule Module Example for Advertisement Insertion 528 Service for Free Internet Service 530 531 532 533 Comcast Free Internet Service 534 comcast 535 536 http 537 538 539 542 icap://adserver.com/insert_ad?mode=respmod 543 544 545 546 548 Client Rule Module Example for Language Translation and Virus 549 Scanning Service 551 552 553 554 Markus Hofmann 555 23242 556 557 http 558 559 560 561 icap://mcaffee.com/virus_scan?mode=respmod 562 563 564 565 566 567 Document language is probably not 569 German -> Page needs to be translated --> 570 571 icap://icap.net/translate?mode=respmod 572 573 574 575 577 Content Provider Rule Module Example for Content Adaptation Service 578 for Wireless Web Access Devices 580 581 582 583 Yahoo Inc. 584 www.yahoo.com 585 586 http 587 588 589 590 591 592 icap://wapgateway.nl/transcode?mode=respmod 593 594 595 596 598 Full Copyright Statement 600 Copyright (C) The Internet Society (2000). All Rights Reserved. 602 This document and translations of it may be copied and furnished to 603 others, and derivative works that comment on or otherwise explain it 604 or assist in its implementation may be prepared, copied, published 605 and distributed, in whole or in part, without restriction of any 606 kind, provided that the above copyright notice and this paragraph 607 are included on all such copies and derivative works. However, this 608 document itself may not be modified in any way, such as by removing 609 the copyright notice or references to the Internet Society or other 610 Internet organizations, except as needed for the purpose of 611 developing Internet standards in which case the procedures for 612 copyrights defined in the Internet Standards process must be 613 followed, or as required to translate it into languages other than 614 English. 616 The limited permissions granted above are perpetual and will not be 617 revoked by the Internet Society or its successors or assigns. 619 This document and the information contained herein is provided on an 620 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 621 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 622 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 623 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 624 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 626 Acknowledgement 628 Funding for the RFC editor function is currently provided by the 629 Internet Society.