idnits 2.17.1 draft-beck-opes-irml-03.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: ---------------------------------------------------------------------------- No issues found here. 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. 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 (June 24, 2003) is 7612 days in the past. Is this intentional? -- 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 97 looks like a reference -- Missing reference section? '3' on line 126 looks like a reference -- Missing reference section? '4' on line 126 looks like a reference -- Missing reference section? '5' on line 170 looks like a reference -- Missing reference section? '6' on line 359 looks like a reference -- Missing reference section? '7' on line 1001 looks like a reference -- Missing reference section? '8' on line 449 looks like a reference -- Missing reference section? '9' on line 477 looks like a reference -- Missing reference section? '10' on line 603 looks like a reference -- Missing reference section? '11' on line 610 looks like a reference -- Missing reference section? '12' on line 776 looks like a reference -- Missing reference section? '13' on line 869 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Beck 2 M. Hofmann 3 Expires: December 23, 2003 Lucent Technologies 4 Document: draft-beck-opes-irml-03.txt 5 June 24, 2003 6 Category: Informational 8 IRML: A Rule Specification Language for Intermediary Services 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with 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 23 reference 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 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The Intermediary Rule Markup Language (IRML) is an XML-based 33 language that can be used to specify rules for the execution of OPES 34 services. 36 OPES services are a new class of applications running on network 37 intermediaries, such as caches, proxies, gateways, etc. or dedicated 38 (callout) servers. They are invoked through intermediaries acting on 39 behalf of application endpoints. IRML is designed to serve as a 40 simple and efficient, but yet powerful language to express the 41 service execution policies of application endpoints. IRML rules are 42 typically processed by intermediaries that trigger the execution of 43 OPES services according to these rules and policies. 45 Table of Contents 47 1 Terminology....................................................3 48 2 Introduction...................................................3 49 3 IRML Syntax and Grammar........................................4 50 3.1 High-level Structure of IRML Documents.......................4 51 3.2 IRML Rule Modules............................................5 52 3.2.1 The "rulemodule" Element....................................5 53 3.3 IRML Rule Authors............................................5 54 3.3.1 The "author" Element........................................5 55 3.3.2 The "name" Element..........................................6 56 3.3.3 The "contact" Element.......................................6 57 3.3.4 The "id" Element............................................6 58 3.3.5 IRML Rule Author Examples...................................6 59 3.4 IRML Rule Sets...............................................6 60 3.4.1 The "ruleset" Element.......................................6 61 3.4.2 The "authorized-by" Element.................................6 62 3.4.3 The "protocol" Element......................................7 63 3.5 IRML Rules...................................................7 64 3.5.1 The "rule" Element..........................................7 65 3.6 IRML Rule Conditions.........................................9 66 3.6.1 The "property" Element......................................9 67 3.6.2 Unconditional Rules........................................11 68 3.7 IRML Rule Actions...........................................11 69 3.7.1 The "execute" Element......................................11 70 3.7.2 The "service" Element......................................11 71 3.7.3 The "uri" Element..........................................12 72 3.7.4 The "any" Element..........................................13 73 3.7.5 The "parameter" Element....................................13 74 3.7.6 The "value" Element........................................14 75 3.7.7 The "variable" Element.....................................14 76 3.8 IRML Rule Set Example.......................................14 77 4 IRML Rule Processing..........................................15 78 4.1 Conflict Resolution for Endpoints...........................15 79 4.2 Order of Service Execution..................................15 80 5 IAB Considerations............................................16 81 6 Security Considerations.......................................18 82 7 Acknowledgements..............................................18 83 8 References....................................................18 84 Authors' Addresses................................................19 85 Appendix A - IRML DTD.............................................19 86 Appendix B - IRML Extensions for HTTP.............................20 87 Appendix C - IRML Sub-Systems.....................................21 88 Appendix D - Rule Module Examples.................................21 89 Appendix E - IRML Change Log......................................24 90 Full Copyright Statement..........................................25 92 1 Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [2]. 98 DATA TRANSACTION 100 A message exchange between a data consumer and a data provider, 101 typically consisting of a data request and a data response message. 103 DATA PATH 105 The path that data requests and responses take through the network. 106 Typically, data requests and responses flow between a data consumer 107 and a data provider. 109 DATA PATH PROTOCOL 111 The application-layer protocol used between the two endpoints of a 112 data transaction, e.g. HTTP or RTSP. 114 Other terminology used in this document is consistent with that 115 defined and used in [3]. 117 2 Introduction 119 This document defines the Intermediary Rule Markup Language (IRML) 120 in an attempt to create a standard representation of OPES service 121 execution policies. It is designed to be simple, efficient, and easy 122 to understand but yet powerful enough to cover complex scenarios 123 with a large number of rules and rule conditions. 125 IRML can be used in particular, but not exclusively, in the context 126 of the OPES framework as proposed in [3] and [4]. Since OPES 127 services may only be executed on behalf of data providers or data 128 consumers - the two endpoints of a data transaction - IRML-specified 129 rules must reflect the intents of either of the two endpoints. A 130 data provider like CNN, for example, may wish to specify the 131 conditions under which CNN web pages may be adapted to fit the 132 screen for users with small wireless devices. The customers of an 133 ISP, on the other hand, may wish to specify the conditions for the 134 execution of a privacy service that removes certain information from 135 user requests before they are sent to an origin server (e.g. the 136 "referer" header in HTTP requests). 138 In its basic form, IRML is not tied to any particular data path 139 protocol or deployment environment. However, IRML allows for 140 extensions that can be used to better accommodate the specifics of 141 data path protocols or different deployment environments. 143 It is anticipated that IRML rules will either be authored directly 144 by data providers or data consumers or indirectly through an 145 authorized delegate such as an ISP. 147 IRML-specified rules are meant to be processed by a rule processor 148 on an intermediary device (e.g. a caching proxy, an access router, a 149 wireless gateway, or a switch) located in the path between data 150 providers and consumers. IRML rules are matched by evaluating rule 151 conditions against the properties of incoming and outgoing messages 152 and possibly also system and environment variables. 154 IRML is designed to be easily created and edited by graphical 155 tools. It is based on XML [5], so many publicly available parsers 156 and editing tools can be used in this process. The structure of the 157 language maps closely to its behavior, so that an editor can easily 158 understand IRML rule modules, even ones written by hand. The 159 language is also designed so that an IRML-enabled intermediary or 160 admin server can easily confirm the validity of IRML rule modules. 162 Although this document does not define a secure and reliable 163 mechanism for transferring IRML rule files to intermediary devices 164 (or other OPES entities), it is expected that existing protocols 165 (e.g. HTTPS) can be used for this purpose. 167 3 IRML Syntax and Grammar 169 IRML is an application of XML. Thus, its syntax is governed by the 170 rules of the XML syntax as defined in [5], and its grammar is 171 specified by a DTD, or Document Type Definition. The IRML DTD can be 172 found in Appendix A. 174 An IRML rule module that appears as a top-level XML document is 175 identified with the formal public identifier "-//IETF//DTD RFCxxxx 176 IRML 1.0//EN". 178 An IRML rule module embedded as a fragment within another XML 179 document is identified with the XML namespace identifier 180 "http://www.rfc-editor.org/rfc/rfcxxxx.txt". 182 3.1 High-level Structure of IRML Documents 184 Valid and well-formed IRML documents consist of one or more rule 185 modules. Each rule module has a section that describes the rule 186 module author. IRML rule modules can be authored directly by data 187 providers or consumers but also indirectly through authorized 188 delegates. The IRML rule author section is followed by one or more 189 IRML rule sets and information about the party that authorized each 190 set of rules. 192 The rules contained in a rule set each consist of a number of IRML 193 rule conditions and a number of consequent IRML rule actions that 194 are to be performed if the rule conditions become true. Through IRML 195 rule actions, endpoints can request the execution of services. 197 The conditions within a rule refer to message properties in the 198 request or response message of a given data transaction. They are 199 met if the property value matches the pattern(s) specified in the 200 rule condition(s). Rule conditions may also refer to system or 201 service-manipulated environment variables. 203 3.2 IRML Rule Modules 205 IRML rule modules represent the service execution policies of data 206 providers and data consumers. The service execution policy of a 207 specific data provider or consumer MAY be expressed through more 208 than one IRML rule module. 210 3.2.1 The "rulemodule" Element 212 The "rulemodule" element is the root element for all IRML rule 213 modules and MAY/MUST contain the following elements (see also IRML 214 DTD in Appendix A). 216 3.3 IRML Rule Authors 218 IRML rule modules can be authored by data providers, data consumers, 219 or authorized delegates who author rule modules on behalf of data 220 providers or consumers. 222 3.3.1 The "author" Element 224 The "author" element specifies the author of a rule module. Each 225 rule module MUST have exactly one author. 227 Attributes of "author" 229 Name Values Default 230 ---------------------------------------------------- 231 type delegate|self self 233 The "type" attribute assigns a rule module author to one of the two 234 possible types of rule module authors. An attribute value of 235 "delegate" indicates that the rule module author acts as a delegate 236 for one or more endpoints. An attribute value of "self" indicates 237 that a rule module is authored directly by a data provider or 238 consumer. 240 The rule module author is described further by a "name", "id", and 241 optionally a "contact" element which are described in the following 242 sections. 244 3.3.2 The "name" Element 246 The "name" element MUST contain a descriptive name for the rule 247 module author. The name does not have to be unique among rule module 248 authors. 250 3.3.3 The "contact" Element 252 The "contact" element is an optional element that, if used, MUST 253 contain a valid email address at which the rule author can be 254 contacted. 256 3.3.4 The "id" Element 258 The "id" element MUST contain a globally unique identifier for the 259 rule module author, for example a URI or an email address. 261 3.3.5 IRML Rule Author Examples 263 264 Comcast 265 rule-management@comcast.com 266 www.comcast.com 267 269 270 Andre Beck 271 abeck@home.com 272 abeck@home.com 273 275 3.4 IRML Rule Sets 277 IRML rule sets represent a collection of rules that apply to and 278 have been authorized by the same data provider or data consumer. 280 3.4.1 The "ruleset" Element 282 The "ruleset" element MUST contain one or more "rule" elements. Rule 283 modules authored directly by a data provider or consumer MUST 284 contain exactly one "ruleset" element. Rule modules authored 285 indirectly through an authorized delegate on the other hand MAY 286 contain more than one set of rules where each rule set MUST be 287 authorized by a different data provider/consumer. 289 3.4.2 The "authorized-by" Element 291 The "authorized-by" element specifies the authorizing data 292 transaction endpoint for a set of rules. This MUST be either a data 293 provider or a data consumer. In self-authored rule modules, the 294 authorizing endpoint MUST be identical with the rule module author. 296 Name Values Default 297 ----------------------------------------------------- 298 class data-provider|data-consumer 299 type individual|group 301 The "class" attribute specifies whether the authorizing endpoint is 302 a data provider or data consumer. 304 The "type" attribute specifies whether the corresponding rule set 305 applies to and has been authorized by an individual data 306 provider/consumer or a group of data providers/consumers. An 307 attribute value of "group" means that the rules in the corresponding 308 rule set apply to all members of the specified group. A value of 309 "group" MAY only be used if the rule module author is a delegate and 310 primarily serves as a means of simplifying cases where a large 311 number of data providers/consumers have identical rules. This can be 312 the case, for example, if an ISP manages rules on behalf of its 313 customers or in an enterprise environment. 315 The "authorized-by" element MUST contain a "name" and "id" element 316 as described in 3.3.2 and 3.3.4 and MAY contain a "contact" element 317 as described in 3.3.3 to further identify the authorizing endpoint. 319 If the authorizing endpoint is of the type "individual", then these 320 elements MUST contain the endpoint's name, globally unique id (such 321 as a URI or email address), and optionally a contact email address. 323 If the authorizing endpoint is of the type "group", then the "name" 324 and "id" elements MUST contain a descriptive name and a globally 325 unique identifier for the corresponding group of data 326 providers/consumers and the "contact" element SHOULD contain an 327 email address at which the delegate managing the group can be 328 contacted. 330 3.4.3 The "protocol" Element 332 The "protocol" element specifies the applicable data path protocol 333 for a set of rules. It MUST contain the protocol acronym of the 334 applicable data path protocol. For example, rule sets applying to 335 HTTP messages MUST specify "HTTP" in the "protocol" element. Each 336 rule set MUST apply to exactly one data path protocol. 338 3.5 IRML Rules 340 IRML rules make up the actual service execution policies of data 341 providers and consumers. They are composed of rule conditions and 342 rule actions. 344 3.5.1 The "rule" Element 345 The "rule" element typically contains one or more "property" 346 elements which represent rule conditions in IRML. In the case of 347 unconditional rules, "rule" elements MAY also contain elements 348 representing rule actions ("execute" elements). 350 Attributes of "rule" 352 Name Values 353 ---------------------------- 354 processing-point 1|2|3|4 356 The "processing-point" attribute specifies at which of the four 357 points in figure 1 a rule MUST be processed by the rule engine on 358 the intermediary device. The four common processing points of an 359 OPES intermediary are further defined in [6]. Implementation 360 architectures for other intermediary devices might define different 361 or additional processing points. 363 Figure 1 shows the typical HTTP data flow between a client, an IRML- 364 enabled intermediary (in this case a caching proxy), and an origin 365 server. The four processing points (1-4) represent locations in the 366 round trip message flow where rules can be processed and service 367 applications can be executed. A virus scanning service for instance 368 could be executed at point 3 in figure 1 in order to scan web 369 objects for viruses before they are stored in the cache. A URI-based 370 request filtering service on the other hand could be executed at 371 point 1 and a language translation service could be executed at 372 point 4. Note that in a caching proxy the message flow may skip 373 points 2 and 3 after point 1 if the requested object can be served 374 from cache. 376 +--------+ +-----------+ +--------+ 377 | |<------|4 3|<------| | 378 | Client | | Caching | | Origin | 379 | | | Proxy | | Server | 380 | |------>|1 2|------>| | 381 +--------+ +-----------+ +--------+ 383 Figure 1: Rule Processing/Service Execution Points 385 Depending on the service type, rules may be processed and services 386 may be executed at any of the four points outlined in figure 1. 387 However, the local policy of an intermediary MAY prevent endpoints 388 from executing service applications at certain processing points. 389 For example, data consumers may not be allowed to execute service 390 applications at processing point 3 because a modified response 391 message may subsequently be cached and served to other data 392 consumers as well. 394 3.6 IRML Rule Conditions 396 IRML rule conditions specify a pattern and a message, system, or 397 service property. Rule conditions are evaluated by matching the 398 specified pattern against the value of the specified message, 399 system, or service property at the time of the evaluation. 401 3.6.1 The "property" Element 403 The "property" element represents a rule condition and MAY contain 404 one or more other "property" elements and/or one or more elements 405 representing rule actions, i.e. "execute" elements. Nested 406 "property" elements represent a hierarchical "AND" relationship. 407 This means that an inner "property" condition can only be true if 408 the outer "property" condition is true and so forth. 410 Attributes of "property" 412 Name Values Default 413 ----------------------------------------------------------- 414 name CDATA 415 context (req-msg|res-msg|system|service) 416 matches CDATA 417 not-matches CDATA 418 case-sensitive (yes|no) "no" 419 sub-system CDATA "standard" 421 The "name" attribute specifies the name of the property that is to 422 be matched. 424 The "context" attribute specifies the property type further. A 425 property context value of "req-msg" or "res-msg" indicates that the 426 corresponding "property" element refers to a request or a response 427 message property, i.e. a protocol-specific request or response 428 header. For HTTP messages, for example, the list of protocol- 429 specific header names is defined in [7]. IRML, however, is not 430 limited to the message properties defined in protocol 431 specifications. User-defined message properties (e.g. user-defined 432 protocol headers) MAY also be used. 434 Note that rule conditions at processing points 1 and 2 can typically 435 only reference request message properties, whereas rule conditions 436 at processing points 3 and 4 can reference request and response 437 message properties. 439 If the "context" attribute is specified as "system", then the 440 property name refers to system variables that are set by the 441 intermediary. 443 IRML defines the following general system property variables which 444 MUST be supported by all IRML-compliant intermediaries: 446 Property Name Value 447 -------------------------------------------------------------- 448 "system-date" a timestamp using the Internet date-time 449 format as defined in [8] 450 "client-ip" the IP address of the data consumer in 451 the common dotted-decimal format 453 In addition to these general system properties, IRML also defines 454 data path protocol-specific system properties. 456 Currently, IRML only defines protocol-specific system properties for 457 HTTP which can be found in Appendix B. 459 If the property "context" attribute is specified as "service", then 460 the property name refers to service-specific environment variables 461 that can be set and modified by service applications. These can be 462 used by service applications to maintain state information beyond a 463 particular session. If these service variables are referenced in 464 IRML rule conditions, then service applications can dynamically 465 adapt the conditions that lead to specific rule actions without 466 altering the actual rule. 468 Service-specific variables can also be used for the communication 469 between different services, e.g. if one service applications sets a 470 state variable that is subsequently read by another service 471 application. 473 The "matches" attribute specifies the pattern against which the 474 property value MUST be matched by the rule engine on the 475 intermediary device. The "matches" pattern MUST be a regular 476 expression compliant with the extended regular expression syntax as 477 defined in [9]. 479 A "property" rule condition is considered true if the pattern 480 provided in the "matches" attribute matches the message, system, or 481 service attribute value referred to by the "property" element 482 through its "name" and "type" attribute values. 484 The "not-matches" attribute MAY be used instead of the "matches" 485 attribute to express "property" rule conditions that are considered 486 true if the provided pattern does NOT match the referenced attribute 487 value. 489 The "case-sensitive" attribute specifies whether the matching of the 490 pattern specified in the "matches" or "not-matches" attributes must 491 be performed case sensitive or not. The default value for this 492 attribute is "no" meaning that pattern matching is case insensitive 493 unless otherwise specified. The matching of property names, 494 regardless of their type, is always case insensitive. 496 The "sub-system" attribute can be used with a "context" attribute 497 value of "system" to specify rules for services that require the 498 evaluation of non-standard system properties which may not be 499 supported by all intermediaries. For example, limited 500 client bandwidth adaptation and streaming media adaptation services 501 may require service execution rules that reference quality of 502 service properties, such as the allocated bandwidth or the packet 503 loss rate. 505 The default sub-system for IRML "property" elements is "standard" 506 which means that only those system properties MAY be referenced that 507 are defined in this document. If the "sub-sytem" attribute is used 508 to specify the name of a sub-sytem other than "standard", then it is 509 up to the referenced sub-sytem to define the supported system 510 properties and how "property" rule conditions are to be matched. 512 Appendix C lists all currently known IRML sub-sytem specifications. 513 Rule modules that use an IRML sub-system other than the "standard" 514 sub-system MAY only be distributed to intermediaries that 515 specifically offer support for the specified sub-system. An IRML 516 rule processor that encounters a "property" rule condition with an 517 unknown sub-system MUST consider the rule condition as false. 519 3.6.2 Unconditional Rules 521 If a "rule" element contains an element representing a rule action 522 outside of any "property" elements, then the specified rule action 523 MUST be performed for all data path protocol messages that originate 524 from or are intended for the authorizing endpoint and pass through 525 the specified processing point. Services with logging functionality, 526 for example, may have to be triggered for all user requests that 527 pass through the intermediary device. 529 3.7 IRML Rule Actions 531 Through IRML rule actions, endpoints can request the execution of 532 services. This type of rule action is expressed through the 533 following IRML elements. 535 3.7.1 The "execute" Element 537 The "execute" element is a rule action element that can be used to 538 express the intent of the authorizing endpoint to execute a specific 539 service application if the surrounding "property" rule conditions 540 are true. The service that the rule author wants to be executed is 541 further specified by the contained "service" element(s). 543 3.7.2 The "service" Element 545 Rule action elements apply to a service application which is further 546 specified by the "service" element. The "service" element contains 547 either a "uri" to identify a specific service application or an 548 "any" element if a rule action applies to any service application. 549 It MAY also contain any number of "parameter" elements. 551 Attributes of "service" 553 Name Values Default 554 ----------------------------------------------------------- 555 name CDATA 556 failure (abort|ignore|try-alternate) "abort" 557 type (primary|alternate) "primary" 559 The "name" attribute contains a descriptive name of the service 560 application, e.g. "Norton Virus Scanning". 562 The "failure" attribute specifies how the intermediary MUST react to 563 a service execution failure of the specified service application. 565 An attribute value of "abort" (which is also the default value) 566 indicates that the intermediary MUST abort the current data 567 transaction and inform the data consumer and possibly also the data 568 provider of the service execution failure. 570 An attribute value of "ignore" indicates that the intermediary MUST 571 ignore the service execution failure and continue the rule 572 processing as though it never attempted to execute the specified 573 service. 575 An attribute value of "try-alternate" indicates that the 576 intermediary MUST attempt to execute an alternate service 577 application instead of the failed service application. If multiple 578 alternate services are given, then the intermediary MUST attempt to 579 execute them in the order they are specified. 581 The "type" attribute specifies whether the "service" element 582 specifies a primary or an alternate service application. Alternate 583 service applications MUST only be executed if the execution of the 584 primary service application fails. A rule action element MAY only 585 contain one "service" element of the type "primary", but MAY contain 586 multiple "service" elements of the type "alternate". If a "service" 587 element has a "failure" attribute value of "try-alternate", then it 588 MUST be followed directly by at least one "service" element of the 589 type "alternate". 591 3.7.3 The "uri" Element 593 The "uri" element identifies the service application of the 594 corresponding "service" element. The "uri" element does not, 595 however, specify a specific instance of a service application, e.g. 596 a specific installation on a specific server. Instead, the IRML- 597 enabled intermediary can map the identified service application to a 598 specific instance at run-time in order to accommodate for system or 599 network conditions, e.g. the current system load on a particular 600 remote callout server. 602 The "uri" element MUST contain an absolute URI that follows the URI 603 syntax as defined in [10] and uniquely identifies a service 604 application including its version. Each "uri" element MAY contain 605 one service identifier. 607 The service identifier, to serve its intended purpose, MUST have the 608 characteristics of global uniqueness and persistence. It is not a 609 goal that it conveys information about how to retrieve or locate a 610 service. Because Uniform Resource Names [11] have been designed with 611 these goals in mind, URNs SHOULD be used as service identifiers. 612 However, other URIs can be managed in such a way as to achieve the 613 same goals. 615 3.7.4 The "any" Element 617 The "any element is an empty element that can be used instead of the 618 "uri" element to express that the surrounding rule action applies to 619 any service application. For example, a rule author may wish to 620 express that under certain rule conditions no service application 621 should be executed. The "any" element MAY not be used in combination 622 with the "execute" element. 624 3.7.5 The "parameter" Element 626 The "parameter" element is an optional element that can be used in 627 combination with "execute" rule actions to specify one or more 628 parameters that MUST be passed to the service application as it is 629 being executed. It MAY contain either a "variable" or a "value" 630 element which represent two different types of parameters. They are 631 described in the following two sections. 633 Attributes of "parameter" 635 Name Values Default 636 ----------------------------------------------------------- 637 name CDATA 638 type (static|dynamic) 640 The "name" attribute specifies the name of the parameter as it is 641 passed to the service application. 643 The "type" attribute specifies whether the parameter value is static 644 or dynamic. Static "parameter" elements MUST contain a "value" 645 element and dynamic "parameter" elements MUST contain a "variable" 646 element. 648 3.7.6 The "value" Element 650 The "value" element contains a static character value which MUST be 651 passed to the service application along with the name of the 652 surrounding "parameter" element. 654 3.7.7 The "variable" Element 656 The "variable" element specifies a message, system, or service 657 property whose current value MUST be passed to the service 658 application along with the name of the surrounding "parameter" 659 element. 661 Attributes of "variable" 663 Name Values Default 664 ------------------------------------------------------------- 665 name CDATA 666 context (req-msg|res-msg|system|service) 667 sub-system CDATA "standard" 669 The "name", "context", and "sub-system" attributes have the same 670 semantics as the ones in the "property" element (section 3.6.1). 672 3.8 IRML Rule Set Example 674 675 676 A. Beck 677 abeck@lucent.com 678 abeck@lucent.com 679 680 HTTP 681 682 683 684 685 opes://log.com/requestlog-v1.0 686 687 688 689 690 691 692 693 694 696 697 700 701 702 703 opes://altavista.com/babelfish 704 705 706 707 708 709 711 More complete and complex rule module examples can be found in 712 Appendix D. 714 4 IRML Rule Processing 716 For each data transaction the rule processor on the intermediary 717 located in the path between data consumers and data providers MUST 718 process only those IRML rule sets that are relevant to the current 719 transaction, i.e. all IRML rule modules that apply to the data path 720 protocol of the transaction (as specified by the "protocol" element) 721 and contain rule sets which have been authorized by either endpoint 722 of the transaction. Within each rule set only those rules MUST be 723 evaluated that apply to the current rule processing point. 725 The rule processor MUST also take into account that message and 726 service property values may be modified by the execution of service 727 applications. It MAY therefore be necessary for the rule processor 728 to re-evaluate rule conditions after the execution of a service 729 application. However, no service application MAY be executed more 730 than once as a result of the re-evaluation of rule conditions. 732 4.1 Conflict Resolution for Endpoints 734 When processing rules, the rule processor MUST evaluate all rule 735 conditions of relevant rules in order to determine the intents of 736 both endpoints. Potential conflicts between the intentions of the 737 two endpoints MUST then be resolved according to the local policy of 738 the intermediary. 740 4.2 Order of Service Execution 742 The order in which service applications on the intermediary device 743 are executed may influence the final result of a data transaction. 744 For example, a content analyzer/filtering service executed against 745 the result of a web page translation service may produce a different 746 result than a reverse execution order. 748 Within sets of rules authorized by the same endpoint, it is 749 reasonable that the authorizing endpoint should be able to determine 750 the service execution order. Within any "ruleset" element, services 751 MUST therefore be executed in the order they are specified in the 752 "rule", "property", and "execute" elements. 754 It is generally not possible, however, to automatically determine a 755 correct order if both endpoints request the execution of different 756 services at the same processing point. In these cases, the 757 intermediary MUST determine the service execution order. 759 In many cases, it may make sense to base this decision on the 760 request/response message flow of a data transaction, i.e. for 761 incoming requests at processing points 1 and 2, the order of service 762 execution would be: 764 1. Data consumer authorized rule actions 765 2. Data provider authorized rule actions 767 For outgoing responses at points 3 and 4, the service execution 768 order would be reverse: 770 1. Data provider authorized rule actions 771 2. Data consumer authorized rule actions 773 5 IAB Considerations 775 This section quotes the IAB's architectural and policy 776 considerations for the OPES framework [12] and describes how these 777 are addressed by this document or why they are not relevant to IRML: 779 (1) "One-party consent: An OPES framework standardized in the IETF 780 must require that the use of any OPES service be explicitly 781 authorized by one of the application-layer end-hosts (that is, 782 either the content provider or the client)." 784 As described in section 3.4.2 and throughout the document, this 785 document REQUIRES that each set of rules in IRML rule modules be 786 authorized by one of the endpoints of a data transaction. 788 (2) "IP-layer communications: For an OPES framework standardized in 789 the IETF, the OPES intermediary must be explicitly addressed at the 790 IP layer by the end user" 792 This document does not specify or impact the addressing of OPES 793 intermediaries by the end user. 795 (3) "Notification: The overall OPES framework needs to assist 796 content providers in detecting and responding to client-centric 797 actions by OPES intermediaries that are deemed inappropriate by the 798 content provider." 799 Both data providers and data consumers can use IRML to express their 800 service execution policies. The processing of IRML rules from both 801 endpoints will therefore help reveal conflicts between the service 802 execution policies of both endpoints. However, it is beyond the 803 scope of IRML to define a method of facilitating the detection of 804 inappropriate service application behavior. Conflict resolution and 805 notification of data providers/consumers is not defined by IRML and 806 is done according to local policy. 808 (4) "Notification: The overall OPES framework should assist end 809 users in detecting the behavior of OPES intermediaries, potentially 810 allowing them to identify imperfect or compromised intermediaries." 812 It is beyond the scope of IRML to define a method of assisting data 813 consumers and providers in detecting imperfect or compromised OPES 814 intermediaries. However, IRML allows both endpoints to specify the 815 behavior of the intermediary in the case of service execution 816 failures (see section 3.7.4). The default behavior is to abort the 817 data transaction and notify the application endpoint. 819 (5) "Non-blocking: If there exists a "non-OPES" version of content 820 available from the content provider, the OPES architecture must not 821 prevent users from retrieving this "non-OPES" version from the 822 content provider." 824 IRML does not prevent data consumers from receiving a "non-OPES" 825 version of content if the data provider offers a "non-OPES" version 826 of its content. For example, data providers could offer a "non-OPES" 827 version under a different URI and make sure that their IRML rules do 828 not trigger any OPES services for the "non-OPES" URI. 830 (6) "URI resolution: OPES documentation must be clear in describing 831 these services as being applied to the result of URI resolution, not 832 as URI resolution itself." 834 This document does not define or describe OPES services. 836 (7) "Reference validity: All proposed services must define their 837 impact on inter- and intra-document reference validity." 839 This document does not define or describe any specific OPES 840 services. 842 (8) "Any services that cannot be achieved while respecting the above 843 two considerations may be reviewed as potential requirements for 844 Internet application addressing architecture extensions, but must 845 not be undertaken as ad hoc fixes." 847 This document does not define or describe any specific OPES 848 services. 850 (9) "Privacy: The overall OPES framework must provide for mechanisms 851 for end users to determine the privacy policies of OPES 852 intermediaries." 854 This part of the OPES framework is not defined by this document. 856 6 Security Considerations 858 Since data providers and data consumers can author IRML rule 859 modules, it will be necessary to securely and reliably transfer rule 860 modules from data providers/consumers to intermediary devices (or to 861 other OPES entities in the same domain and from these entities to 862 intermediary devices). 864 Because IRML rule modules can control the execution of services, the 865 receiving intermediary must be able to authenticate the rule module 866 author and verify the integrity of the received rule module. 868 IRML therefore REQUIRES that all IRML rule modules be signed by the 869 rule module author using XML signatures as defined in [13]. 871 Also, to protect the privacy of data providers and data consumers, 872 application-layer or network-layer encryption SHOULD be applied to 873 connections that are used for the transfer of IRML rule modules. 875 As IRML-enabled intermediaries could potentially be the target of 876 security attacks, intermediaries SHOULD be able to reject submitted 877 IRML rule modules if accepting them would compromise their ability 878 to function properly. Intermediaries SHOULD also be able to reject 879 IRML rule modules that are incompatible with their own policies. 881 7 Acknowledgements 883 The authors would like to thank all active participants in the OPES 884 mailing list for their thought-provoking discussion, and many of the 885 ideas and suggestions that have been incorporated into this 886 document. 888 8 References 890 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 891 9, RFC 2026, October 1996 892 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 893 Levels", Request for Comments 2119, Harvard University, March 894 1997 895 3 Barbir, A., et al., "An Architecture For Open Pluggable Edge 896 Services (OPES)", Work in Progress Internet Draft: draft-ietf- 897 opes-architecture-04.txt, December 2002. 899 4 Barbir, A., et al., "OPES Use Cases and Deployment Scenarios", 900 Work in Progress Internet Draft: draft-ietf-opes-scenarios- 901 01.txt, August 2002 902 5 Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second 903 Edition), http://www.w3.org/TR/2000/REC-xml-20001006, October 904 2000 905 6 Barbir, A., et al., "Policy, Authorization and Enforcement 906 Requirements", Work in Progress, Internet Draft draft-ietf-opes- 907 authorization-02.txt, February 2002 908 7 Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", 909 Request for Comments 2616, June 1999 910 8 Klyne, G., et al., "Date and Time on the Internet: Timestamps", 911 Work in Progress, Internet Draft "draft-ietf-impp-datetime- 912 05.txt", November 2001 913 9 ISO/IEC DIS 9945-2:1992, Information technology - Portable 914 Operating System Interface (POSIX) - Part 2: Shell and Utilities 915 (IEEE Std 1003.2-1992); X/Open CAE Specification, Commands and 916 Utilities, Issue 4, 1992 917 10 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 918 Identifiers (URI): Generic Syntax and Semantics", Request for 919 Comments 2396, August 1998 920 11 Moats, R., "URN Syntax", Request for Comments 2141, May 1997 921 12 Floyd, S. et al., "IAB Architectural and Policy Considerations 922 for OPES", RFC 3238, January 2002 923 13 Bartel, M. et al., "XML-Signature Syntax and Processing", W3C 924 Recommendation, February 2002 926 Authors' Addresses 928 Andre Beck 929 Markus Hofmann 930 Bell Labs Research 931 Lucent Technologies 932 101 Crawfords Corner Rd. 933 Holmdel, NJ 07733 934 Phone: (732) 332-5983 935 Email: {abeck, hofmann}@bell-labs.com 937 Appendix A - IRML DTD 939 The DTD in this section describes the XML syntax of IRML. Every rule 940 module submitted to an IRML-enabled intermediary or admin server 941 MUST comply with this DTD. Note that compliance with this DTD is not 942 a sufficient condition for correctness of an IRML rule module, as 943 some of the conditions described in this document are not 944 expressible in the DTD syntax. 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 964 965 967 969 971 972 974 975 976 977 978 979 980 982 983 985 Appendix B - IRML Extensions for HTTP 987 For HTTP messages, IRML defines the following system variables: 989 Property Name Value 990 -------------------------------------------------------------- 991 "request-line" the first line of an HTTP request 992 "request-method" the HTTP request method, e.g. GET or POST 993 "request-path" the rel_path of the request URI as defined 994 in [7] 995 "request-version" the HTTP version number as it appears in the 996 first HTTP request line, e.g. HTTP/1.1 997 "request-host" the host name/IP address of the origin server 998 as it appears in the first HTTP request line 999 or HTTP "Host" request header 1001 "request-uri" the absolute request URI as defined in [7] 1002 "response-line" the first line of an HTTP response 1003 "response-code" the HTTP response code as it appears in the 1004 first HTTP response line, e.g. 200 1006 All intermediaries that accept IRML rule modules with a protocol 1007 value of "HTTP" MUST support the above listed HTTP-specific system 1008 variables. 1010 Appendix C - IRML Sub-Systems 1012 The following is a list of currently known IRML sub-systems: 1014 Sub-System Name Description Specification 1015 ---------------------------------------------------------------- 1017 Appendix D - Rule Module Examples 1019 Data provider Rule Module Example 1021 1022 1023 1024 Lucent Technologies 1025 rule-info@lucent.com 1026 www.lucent.com 1027 1028 1029 1030 Lucent Technologies 1031 rule-info@lucent.com 1032 www.lucent.com 1033 1034 HTTP 1035 1036 1037 1039 1040 1041 1042 1043 opes://local.net/insert-local-content 1044 1045 1046 1047 1048 1049 1051 1052 1053 1054 1055 1056 ... 1057 1059 Data consumer Rule Module Example 1061 1062 1063 1064 Andre Beck 1065 abeck@home.com 1066 138.43.43.55 1067 1068 1069 1070 Lucent Technologies 1071 abeck@home.com 1072 www.lucent.com 1073 1074 HTTP 1075 1076 1078 1079 1080 opes://privacy.net/priv-serv 1081 1082 remove-referer 1083 1084 1085 1086 1087 1088 1089 1090 ... 1091 1093 Delegate Rule Module Example 1095 1096 1097 1098 Comcast ISP 1099 rule-info@comcast.com 1100 www.comcast.com 1101 1102 1103 1104 1105 Virus Scanning Subscribers 1106 vs-subscribers@comcast.com 1107 www.comcast.com/irml-groups/vs-subscribers 1108 1109 HTTP 1110 1111 1112 1114 1115 1117 opes://mcaffee.com/mscan 1118 1119 1121 opes://norton.com/nscan 1122 1123 1124 1125 1126 1127 1128 1129 1130 CNN 1131 rule-info@cnn.com 1132 www.cnn.com 1133 1134 HTTP 1135 1136 1143 opes://mcaffee.com/mscan 1144 1145 1146 1147 1148 1149 1150 1151 ... 1152 1154 Appendix E - IRML Change Log 1156 Changes from draft-beck-opes-irml-02.txt 1158 - aligned terminology with OPES WG documents 1159 - removed references to Web services 1160 - removed "may-execute" and "do-not-execute" elements 1161 - updated references section 1163 Changes from draft-beck-opes-irml-01.txt 1165 - replaced the element with three different rule action 1166 elements: (to request the execution of a service), 1167 (to disallow the execution of services), and 1168 (to permit the execution of services) 1169 - introduced "delegate" as rule module author and separation 1170 between rule module author and authorizing endpoint 1171 - introduced IRML rule sets as a collection of rules authorized by 1172 the same endpoint 1173 - introduced separation between service identification through URI 1174 and service execution parameters 1175 - added recommendation to use URNs as service identifiers 1176 - introduced support for dynamic parameters (i.e. the ability to 1177 pass run-time message, system, and service property values to 1178 service applications) 1179 - introduced "failure" attribute to allow endpoints to control the 1180 intermediary behavior in the case of service execution failures 1181 - introduced the concept of executing alternate services in the case 1182 of service execution failures 1183 - rewrote introduction 1184 - added "Rule Pocessing" section 1185 - added "IAB Considerations" section to address the recent IAB draft 1186 with considerations for OPES 1187 - changed mandated order of service execution 1188 - rewrote security considerations and introduced the requirement to 1189 use XML signatures in all rule modules 1190 - fixed syntax of comments in examples, clarified the meaning of the 1191 "request-path" system property and the regular expression syntax 1192 to be used in rule condition patterns 1193 (as suggested by M. Cinquini) 1194 - added more HTTP-specific system properties to simplify the rule 1195 matching for HTTP messages (as suggested by Lily Yang) 1196 - introduced "not-matches" attribute in property element 1197 (as suggested by M. Cinquini) 1198 - renamed "type" attribute in "property" elements to "context" 1199 - added "context" attribute values "req-msg" and "res-msg" to better 1200 differentiate between request message and response message 1201 properties (as suggested by R. Rahman) 1202 - introduced IRML sub-system attribute in "property" elements and 1203 appendix with list of known sub-systems (as suggested by C.W. Ng) 1204 - moved pre-defined HTTP-specific system properties to HTTP-specific 1205 appendix 1207 - added IRML document identifiers for XML 1208 - rewrote all rule module examples to match the new IRML DTD 1209 - added this change log 1211 Changes from draft-beck-opes-irml-00.txt 1213 - updated references to include the models and policy requirements 1214 drafts 1215 - removed terminology section and referenced the taxonomy in the 1216 models draft instead 1217 - revised use of terminology to be conform with models draft 1218 terminology 1219 - removed access provider from list of rule authors (as suggested by 1220 new OPES charter) 1221 - late binding in field through OPES URI (as suggested by 1222 Lee Rafalow and others) 1223 - added "request-host" variable (as suggested by Francis Zane) 1224 - added type attribute to property element to accomodate three 1225 different types of properties: message, system, and service 1226 - added "client-ip" system variable to support services that depend 1227 on the client IP, e.g. URL rewriting in a CDN scenario 1228 - added support for arbitrary service state variables which also 1229 allows rule matching against members of dynamic groups (as 1230 suggested by Lee Rafalow and others) 1231 - new date format in system property (as suggested by 1232 Ian Cooper) 1233 - removed DEFAULT keyword in IRML DTD (as suggested by Ting) 1235 Full Copyright Statement 1237 Copyright (C) The Internet Society (2000). All Rights Reserved. 1239 This document and translations of it may be copied and furnished to 1240 others, and derivative works that comment on or otherwise explain it 1241 or assist in its implementation may be prepared, copied, published 1242 and distributed, in whole or in part, without restriction of any 1243 kind, provided that the above copyright notice and this paragraph 1244 are included on all such copies and derivative works. However, this 1245 document itself may not be modified in any way, such as by removing 1246 the copyright notice or references to the Internet Society or other 1247 Internet organizations, except as needed for the purpose of 1248 developing Internet standards in which case the procedures for 1249 copyrights defined in the Internet Standards process must be 1250 followed, or as required to translate it into languages other than 1251 English. 1253 The limited permissions granted above are perpetual and will not be 1254 revoked by the Internet Society or its successors or assigns. 1256 This document and the information contained herein is provided on an 1257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.