Internet Draft A. Beck M. Hofmann Expires: December 23, 2003 Lucent Technologies Document: draft-beck-opes-irml-03.txt June 24, 2003 Category: Informational IRML: A Rule Specification Language for Intermediary Services Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Intermediary Rule Markup Language (IRML) is an XML-based language that can be used to specify rules for the execution of OPES services. OPES services are a new class of applications running on network intermediaries, such as caches, proxies, gateways, etc. or dedicated (callout) servers. They are invoked through intermediaries acting on behalf of application endpoints. IRML is designed to serve as a simple and efficient, but yet powerful language to express the service execution policies of application endpoints. IRML rules are typically processed by intermediaries that trigger the execution of OPES services according to these rules and policies. Beck, Hofmann Expires December 2003 [Page 1] Internet Draft IRML June 2003 Table of Contents 1 Terminology....................................................3 2 Introduction...................................................3 3 IRML Syntax and Grammar........................................4 3.1 High-level Structure of IRML Documents.......................4 3.2 IRML Rule Modules............................................5 3.2.1 The "rulemodule" Element....................................5 3.3 IRML Rule Authors............................................5 3.3.1 The "author" Element........................................5 3.3.2 The "name" Element..........................................6 3.3.3 The "contact" Element.......................................6 3.3.4 The "id" Element............................................6 3.3.5 IRML Rule Author Examples...................................6 3.4 IRML Rule Sets...............................................6 3.4.1 The "ruleset" Element.......................................6 3.4.2 The "authorized-by" Element.................................6 3.4.3 The "protocol" Element......................................7 3.5 IRML Rules...................................................7 3.5.1 The "rule" Element..........................................7 3.6 IRML Rule Conditions.........................................9 3.6.1 The "property" Element......................................9 3.6.2 Unconditional Rules........................................11 3.7 IRML Rule Actions...........................................11 3.7.1 The "execute" Element......................................11 3.7.2 The "service" Element......................................11 3.7.3 The "uri" Element..........................................12 3.7.4 The "any" Element..........................................13 3.7.5 The "parameter" Element....................................13 3.7.6 The "value" Element........................................14 3.7.7 The "variable" Element.....................................14 3.8 IRML Rule Set Example.......................................14 4 IRML Rule Processing..........................................15 4.1 Conflict Resolution for Endpoints...........................15 4.2 Order of Service Execution..................................15 5 IAB Considerations............................................16 6 Security Considerations.......................................18 7 Acknowledgements..............................................18 8 References....................................................18 Authors' Addresses................................................19 Appendix A - IRML DTD.............................................19 Appendix B - IRML Extensions for HTTP.............................20 Appendix C - IRML Sub-Systems.....................................21 Appendix D - Rule Module Examples.................................21 Appendix E - IRML Change Log......................................24 Beck, Hofmann Expires December 2003 [Page 2] Internet Draft IRML June 2003 Full Copyright Statement..........................................25 1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. DATA TRANSACTION A message exchange between a data consumer and a data provider, typically consisting of a data request and a data response message. DATA PATH The path that data requests and responses take through the network. Typically, data requests and responses flow between a data consumer and a data provider. DATA PATH PROTOCOL The application-layer protocol used between the two endpoints of a data transaction, e.g. HTTP or RTSP. Other terminology used in this document is consistent with that defined and used in [3]. 2 Introduction This document defines the Intermediary Rule Markup Language (IRML) in an attempt to create a standard representation of OPES service execution policies. It is designed to be simple, efficient, and easy to understand but yet powerful enough to cover complex scenarios with a large number of rules and rule conditions. IRML can be used in particular, but not exclusively, in the context of the OPES framework as proposed in [3] and [4]. Since OPES services may only be executed on behalf of data providers or data consumers - the two endpoints of a data transaction - IRML-specified rules must reflect the intents of either of the two endpoints. A data provider like CNN, for example, may wish to specify the conditions under which CNN web pages may be adapted to fit the screen for users with small wireless devices. The customers of an ISP, on the other hand, may wish to specify the conditions for the execution of a privacy service that removes certain information from user requests before they are sent to an origin server (e.g. the "referer" header in HTTP requests). In its basic form, IRML is not tied to any particular data path protocol or deployment environment. However, IRML allows for Beck, Hofmann Expires December 2003 [Page 3] Internet Draft IRML June 2003 extensions that can be used to better accommodate the specifics of data path protocols or different deployment environments. It is anticipated that IRML rules will either be authored directly by data providers or data consumers or indirectly through an authorized delegate such as an ISP. IRML-specified rules are meant to be processed by a rule processor on an intermediary device (e.g. a caching proxy, an access router, a wireless gateway, or a switch) located in the path between data providers and consumers. IRML rules are matched by evaluating rule conditions against the properties of incoming and outgoing messages and possibly also system and environment variables. IRML is designed to be easily created and edited by graphical tools. It is based on XML [5], so many publicly available parsers and editing tools can be used in this process. The structure of the language maps closely to its behavior, so that an editor can easily understand IRML rule modules, even ones written by hand. The language is also designed so that an IRML-enabled intermediary or admin server can easily confirm the validity of IRML rule modules. Although this document does not define a secure and reliable mechanism for transferring IRML rule files to intermediary devices (or other OPES entities), it is expected that existing protocols (e.g. HTTPS) can be used for this purpose. 3 IRML Syntax and Grammar IRML is an application of XML. Thus, its syntax is governed by the rules of the XML syntax as defined in [5], and its grammar is specified by a DTD, or Document Type Definition. The IRML DTD can be found in Appendix A. An IRML rule module that appears as a top-level XML document is identified with the formal public identifier "-//IETF//DTD RFCxxxx IRML 1.0//EN". An IRML rule module embedded as a fragment within another XML document is identified with the XML namespace identifier "http://www.rfc-editor.org/rfc/rfcxxxx.txt". 3.1 High-level Structure of IRML Documents Valid and well-formed IRML documents consist of one or more rule modules. Each rule module has a section that describes the rule module author. IRML rule modules can be authored directly by data providers or consumers but also indirectly through authorized delegates. The IRML rule author section is followed by one or more IRML rule sets and information about the party that authorized each set of rules. Beck, Hofmann Expires December 2003 [Page 4] Internet Draft IRML June 2003 The rules contained in a rule set each consist of a number of IRML rule conditions and a number of consequent IRML rule actions that are to be performed if the rule conditions become true. Through IRML rule actions, endpoints can request the execution of services. The conditions within a rule refer to message properties in the request or response message of a given data transaction. They are met if the property value matches the pattern(s) specified in the rule condition(s). Rule conditions may also refer to system or service-manipulated environment variables. 3.2 IRML Rule Modules IRML rule modules represent the service execution policies of data providers and data consumers. The service execution policy of a specific data provider or consumer MAY be expressed through more than one IRML rule module. 3.2.1 The "rulemodule" Element The "rulemodule" element is the root element for all IRML rule modules and MAY/MUST contain the following elements (see also IRML DTD in Appendix A). 3.3 IRML Rule Authors IRML rule modules can be authored by data providers, data consumers, or authorized delegates who author rule modules on behalf of data providers or consumers. 3.3.1 The "author" Element The "author" element specifies the author of a rule module. Each rule module MUST have exactly one author. Attributes of "author" Name Values Default ---------------------------------------------------- type delegate|self self The "type" attribute assigns a rule module author to one of the two possible types of rule module authors. An attribute value of "delegate" indicates that the rule module author acts as a delegate for one or more endpoints. An attribute value of "self" indicates that a rule module is authored directly by a data provider or consumer. The rule module author is described further by a "name", "id", and optionally a "contact" element which are described in the following sections. Beck, Hofmann Expires December 2003 [Page 5] Internet Draft IRML June 2003 3.3.2 The "name" Element The "name" element MUST contain a descriptive name for the rule module author. The name does not have to be unique among rule module authors. 3.3.3 The "contact" Element The "contact" element is an optional element that, if used, MUST contain a valid email address at which the rule author can be contacted. 3.3.4 The "id" Element The "id" element MUST contain a globally unique identifier for the rule module author, for example a URI or an email address. 3.3.5 IRML Rule Author Examples Comcast rule-management@comcast.com www.comcast.com Andre Beck abeck@home.com abeck@home.com 3.4 IRML Rule Sets IRML rule sets represent a collection of rules that apply to and have been authorized by the same data provider or data consumer. 3.4.1 The "ruleset" Element The "ruleset" element MUST contain one or more "rule" elements. Rule modules authored directly by a data provider or consumer MUST contain exactly one "ruleset" element. Rule modules authored indirectly through an authorized delegate on the other hand MAY contain more than one set of rules where each rule set MUST be authorized by a different data provider/consumer. 3.4.2 The "authorized-by" Element The "authorized-by" element specifies the authorizing data transaction endpoint for a set of rules. This MUST be either a data provider or a data consumer. In self-authored rule modules, the authorizing endpoint MUST be identical with the rule module author. Beck, Hofmann Expires December 2003 [Page 6] Internet Draft IRML June 2003 Name Values Default ----------------------------------------------------- class data-provider|data-consumer type individual|group The "class" attribute specifies whether the authorizing endpoint is a data provider or data consumer. The "type" attribute specifies whether the corresponding rule set applies to and has been authorized by an individual data provider/consumer or a group of data providers/consumers. An attribute value of "group" means that the rules in the corresponding rule set apply to all members of the specified group. A value of "group" MAY only be used if the rule module author is a delegate and primarily serves as a means of simplifying cases where a large number of data providers/consumers have identical rules. This can be the case, for example, if an ISP manages rules on behalf of its customers or in an enterprise environment. The "authorized-by" element MUST contain a "name" and "id" element as described in 3.3.2 and 3.3.4 and MAY contain a "contact" element as described in 3.3.3 to further identify the authorizing endpoint. If the authorizing endpoint is of the type "individual", then these elements MUST contain the endpoint's name, globally unique id (such as a URI or email address), and optionally a contact email address. If the authorizing endpoint is of the type "group", then the "name" and "id" elements MUST contain a descriptive name and a globally unique identifier for the corresponding group of data providers/consumers and the "contact" element SHOULD contain an email address at which the delegate managing the group can be contacted. 3.4.3 The "protocol" Element The "protocol" element specifies the applicable data path protocol for a set of rules. It MUST contain the protocol acronym of the applicable data path protocol. For example, rule sets applying to HTTP messages MUST specify "HTTP" in the "protocol" element. Each rule set MUST apply to exactly one data path protocol. 3.5 IRML Rules IRML rules make up the actual service execution policies of data providers and consumers. They are composed of rule conditions and rule actions. 3.5.1 The "rule" Element Beck, Hofmann Expires December 2003 [Page 7] Internet Draft IRML June 2003 The "rule" element typically contains one or more "property" elements which represent rule conditions in IRML. In the case of unconditional rules, "rule" elements MAY also contain elements representing rule actions ("execute" elements). Attributes of "rule" Name Values ---------------------------- processing-point 1|2|3|4 The "processing-point" attribute specifies at which of the four points in figure 1 a rule MUST be processed by the rule engine on the intermediary device. The four common processing points of an OPES intermediary are further defined in [6]. Implementation architectures for other intermediary devices might define different or additional processing points. Figure 1 shows the typical HTTP data flow between a client, an IRML- enabled intermediary (in this case a caching proxy), and an origin server. The four processing points (1-4) represent locations in the round trip message flow where rules can be processed and service applications can be executed. A virus scanning service for instance could be executed at point 3 in figure 1 in order to scan web objects for viruses before they are stored in the cache. A URI-based request filtering service on the other hand could be executed at point 1 and a language translation service could be executed at point 4. Note that in a caching proxy the message flow may skip points 2 and 3 after point 1 if the requested object can be served from cache. +--------+ +-----------+ +--------+ | |<------|4 3|<------| | | Client | | Caching | | Origin | | | | Proxy | | Server | | |------>|1 2|------>| | +--------+ +-----------+ +--------+ Figure 1: Rule Processing/Service Execution Points Depending on the service type, rules may be processed and services may be executed at any of the four points outlined in figure 1. However, the local policy of an intermediary MAY prevent endpoints from executing service applications at certain processing points. For example, data consumers may not be allowed to execute service applications at processing point 3 because a modified response message may subsequently be cached and served to other data consumers as well. Beck, Hofmann Expires December 2003 [Page 8] Internet Draft IRML June 2003 3.6 IRML Rule Conditions IRML rule conditions specify a pattern and a message, system, or service property. Rule conditions are evaluated by matching the specified pattern against the value of the specified message, system, or service property at the time of the evaluation. 3.6.1 The "property" Element The "property" element represents a rule condition and MAY contain one or more other "property" elements and/or one or more elements representing rule actions, i.e. "execute" elements. Nested "property" elements represent a hierarchical "AND" relationship. This means that an inner "property" condition can only be true if the outer "property" condition is true and so forth. Attributes of "property" Name Values Default ----------------------------------------------------------- name CDATA context (req-msg|res-msg|system|service) matches CDATA not-matches CDATA case-sensitive (yes|no) "no" sub-system CDATA "standard" The "name" attribute specifies the name of the property that is to be matched. The "context" attribute specifies the property type further. A property context value of "req-msg" or "res-msg" indicates that the corresponding "property" element refers to a request or a response message property, i.e. a protocol-specific request or response header. For HTTP messages, for example, the list of protocol- specific header names is defined in [7]. IRML, however, is not limited to the message properties defined in protocol specifications. User-defined message properties (e.g. user-defined protocol headers) MAY also be used. Note that rule conditions at processing points 1 and 2 can typically only reference request message properties, whereas rule conditions at processing points 3 and 4 can reference request and response message properties. If the "context" attribute is specified as "system", then the property name refers to system variables that are set by the intermediary. IRML defines the following general system property variables which MUST be supported by all IRML-compliant intermediaries: Beck, Hofmann Expires December 2003 [Page 9] Internet Draft IRML June 2003 Property Name Value -------------------------------------------------------------- "system-date" a timestamp using the Internet date-time format as defined in [8] "client-ip" the IP address of the data consumer in the common dotted-decimal format In addition to these general system properties, IRML also defines data path protocol-specific system properties. Currently, IRML only defines protocol-specific system properties for HTTP which can be found in Appendix B. If the property "context" attribute is specified as "service", then the property name refers to service-specific environment variables that can be set and modified by service applications. These can be used by service applications to maintain state information beyond a particular session. If these service variables are referenced in IRML rule conditions, then service applications can dynamically adapt the conditions that lead to specific rule actions without altering the actual rule. Service-specific variables can also be used for the communication between different services, e.g. if one service applications sets a state variable that is subsequently read by another service application. The "matches" attribute specifies the pattern against which the property value MUST be matched by the rule engine on the intermediary device. The "matches" pattern MUST be a regular expression compliant with the extended regular expression syntax as defined in [9]. A "property" rule condition is considered true if the pattern provided in the "matches" attribute matches the message, system, or service attribute value referred to by the "property" element through its "name" and "type" attribute values. The "not-matches" attribute MAY be used instead of the "matches" attribute to express "property" rule conditions that are considered true if the provided pattern does NOT match the referenced attribute value. The "case-sensitive" attribute specifies whether the matching of the pattern specified in the "matches" or "not-matches" attributes must be performed case sensitive or not. The default value for this attribute is "no" meaning that pattern matching is case insensitive unless otherwise specified. The matching of property names, regardless of their type, is always case insensitive. The "sub-system" attribute can be used with a "context" attribute value of "system" to specify rules for services that require the Beck, Hofmann Expires December 2003 [Page 10] Internet Draft IRML June 2003 evaluation of non-standard system properties which may not be supported by all intermediaries. For example, limited client bandwidth adaptation and streaming media adaptation services may require service execution rules that reference quality of service properties, such as the allocated bandwidth or the packet loss rate. The default sub-system for IRML "property" elements is "standard" which means that only those system properties MAY be referenced that are defined in this document. If the "sub-sytem" attribute is used to specify the name of a sub-sytem other than "standard", then it is up to the referenced sub-sytem to define the supported system properties and how "property" rule conditions are to be matched. Appendix C lists all currently known IRML sub-sytem specifications. Rule modules that use an IRML sub-system other than the "standard" sub-system MAY only be distributed to intermediaries that specifically offer support for the specified sub-system. An IRML rule processor that encounters a "property" rule condition with an unknown sub-system MUST consider the rule condition as false. 3.6.2 Unconditional Rules If a "rule" element contains an element representing a rule action outside of any "property" elements, then the specified rule action MUST be performed for all data path protocol messages that originate from or are intended for the authorizing endpoint and pass through the specified processing point. Services with logging functionality, for example, may have to be triggered for all user requests that pass through the intermediary device. 3.7 IRML Rule Actions Through IRML rule actions, endpoints can request the execution of services. This type of rule action is expressed through the following IRML elements. 3.7.1 The "execute" Element The "execute" element is a rule action element that can be used to express the intent of the authorizing endpoint to execute a specific service application if the surrounding "property" rule conditions are true. The service that the rule author wants to be executed is further specified by the contained "service" element(s). 3.7.2 The "service" Element Rule action elements apply to a service application which is further specified by the "service" element. The "service" element contains either a "uri" to identify a specific service application or an Beck, Hofmann Expires December 2003 [Page 11] Internet Draft IRML June 2003 "any" element if a rule action applies to any service application. It MAY also contain any number of "parameter" elements. Attributes of "service" Name Values Default ----------------------------------------------------------- name CDATA failure (abort|ignore|try-alternate) "abort" type (primary|alternate) "primary" The "name" attribute contains a descriptive name of the service application, e.g. "Norton Virus Scanning". The "failure" attribute specifies how the intermediary MUST react to a service execution failure of the specified service application. An attribute value of "abort" (which is also the default value) indicates that the intermediary MUST abort the current data transaction and inform the data consumer and possibly also the data provider of the service execution failure. An attribute value of "ignore" indicates that the intermediary MUST ignore the service execution failure and continue the rule processing as though it never attempted to execute the specified service. An attribute value of "try-alternate" indicates that the intermediary MUST attempt to execute an alternate service application instead of the failed service application. If multiple alternate services are given, then the intermediary MUST attempt to execute them in the order they are specified. The "type" attribute specifies whether the "service" element specifies a primary or an alternate service application. Alternate service applications MUST only be executed if the execution of the primary service application fails. A rule action element MAY only contain one "service" element of the type "primary", but MAY contain multiple "service" elements of the type "alternate". If a "service" element has a "failure" attribute value of "try-alternate", then it MUST be followed directly by at least one "service" element of the type "alternate". 3.7.3 The "uri" Element The "uri" element identifies the service application of the corresponding "service" element. The "uri" element does not, however, specify a specific instance of a service application, e.g. a specific installation on a specific server. Instead, the IRML- enabled intermediary can map the identified service application to a specific instance at run-time in order to accommodate for system or Beck, Hofmann Expires December 2003 [Page 12] Internet Draft IRML June 2003 network conditions, e.g. the current system load on a particular remote callout server. The "uri" element MUST contain an absolute URI that follows the URI syntax as defined in [10] and uniquely identifies a service application including its version. Each "uri" element MAY contain one service identifier. The service identifier, to serve its intended purpose, MUST have the characteristics of global uniqueness and persistence. It is not a goal that it conveys information about how to retrieve or locate a service. Because Uniform Resource Names [11] have been designed with these goals in mind, URNs SHOULD be used as service identifiers. However, other URIs can be managed in such a way as to achieve the same goals. 3.7.4 The "any" Element The "any element is an empty element that can be used instead of the "uri" element to express that the surrounding rule action applies to any service application. For example, a rule author may wish to express that under certain rule conditions no service application should be executed. The "any" element MAY not be used in combination with the "execute" element. 3.7.5 The "parameter" Element The "parameter" element is an optional element that can be used in combination with "execute" rule actions to specify one or more parameters that MUST be passed to the service application as it is being executed. It MAY contain either a "variable" or a "value" element which represent two different types of parameters. They are described in the following two sections. Attributes of "parameter" Name Values Default ----------------------------------------------------------- name CDATA type (static|dynamic) The "name" attribute specifies the name of the parameter as it is passed to the service application. The "type" attribute specifies whether the parameter value is static or dynamic. Static "parameter" elements MUST contain a "value" element and dynamic "parameter" elements MUST contain a "variable" element. Beck, Hofmann Expires December 2003 [Page 13] Internet Draft IRML June 2003 3.7.6 The "value" Element The "value" element contains a static character value which MUST be passed to the service application along with the name of the surrounding "parameter" element. 3.7.7 The "variable" Element The "variable" element specifies a message, system, or service property whose current value MUST be passed to the service application along with the name of the surrounding "parameter" element. Attributes of "variable" Name Values Default ------------------------------------------------------------- name CDATA context (req-msg|res-msg|system|service) sub-system CDATA "standard" The "name", "context", and "sub-system" attributes have the same semantics as the ones in the "property" element (section 3.6.1). 3.8 IRML Rule Set Example A. Beck abeck@lucent.com abeck@lucent.com HTTP opes://log.com/requestlog-v1.0 Beck, Hofmann Expires December 2003 [Page 14] Internet Draft IRML June 2003 opes://altavista.com/babelfish More complete and complex rule module examples can be found in Appendix D. 4 IRML Rule Processing For each data transaction the rule processor on the intermediary located in the path between data consumers and data providers MUST process only those IRML rule sets that are relevant to the current transaction, i.e. all IRML rule modules that apply to the data path protocol of the transaction (as specified by the "protocol" element) and contain rule sets which have been authorized by either endpoint of the transaction. Within each rule set only those rules MUST be evaluated that apply to the current rule processing point. The rule processor MUST also take into account that message and service property values may be modified by the execution of service applications. It MAY therefore be necessary for the rule processor to re-evaluate rule conditions after the execution of a service application. However, no service application MAY be executed more than once as a result of the re-evaluation of rule conditions. 4.1 Conflict Resolution for Endpoints When processing rules, the rule processor MUST evaluate all rule conditions of relevant rules in order to determine the intents of both endpoints. Potential conflicts between the intentions of the two endpoints MUST then be resolved according to the local policy of the intermediary. 4.2 Order of Service Execution The order in which service applications on the intermediary device are executed may influence the final result of a data transaction. For example, a content analyzer/filtering service executed against the result of a web page translation service may produce a different result than a reverse execution order. Within sets of rules authorized by the same endpoint, it is reasonable that the authorizing endpoint should be able to determine the service execution order. Within any "ruleset" element, services Beck, Hofmann Expires December 2003 [Page 15] Internet Draft IRML June 2003 MUST therefore be executed in the order they are specified in the "rule", "property", and "execute" elements. It is generally not possible, however, to automatically determine a correct order if both endpoints request the execution of different services at the same processing point. In these cases, the intermediary MUST determine the service execution order. In many cases, it may make sense to base this decision on the request/response message flow of a data transaction, i.e. for incoming requests at processing points 1 and 2, the order of service execution would be: 1. Data consumer authorized rule actions 2. Data provider authorized rule actions For outgoing responses at points 3 and 4, the service execution order would be reverse: 1. Data provider authorized rule actions 2. Data consumer authorized rule actions 5 IAB Considerations This section quotes the IAB's architectural and policy considerations for the OPES framework [12] and describes how these are addressed by this document or why they are not relevant to IRML: (1) "One-party consent: An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)." As described in section 3.4.2 and throughout the document, this document REQUIRES that each set of rules in IRML rule modules be authorized by one of the endpoints of a data transaction. (2) "IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" This document does not specify or impact the addressing of OPES intermediaries by the end user. (3) "Notification: The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider." Beck, Hofmann Expires December 2003 [Page 16] Internet Draft IRML June 2003 Both data providers and data consumers can use IRML to express their service execution policies. The processing of IRML rules from both endpoints will therefore help reveal conflicts between the service execution policies of both endpoints. However, it is beyond the scope of IRML to define a method of facilitating the detection of inappropriate service application behavior. Conflict resolution and notification of data providers/consumers is not defined by IRML and is done according to local policy. (4) "Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries." It is beyond the scope of IRML to define a method of assisting data consumers and providers in detecting imperfect or compromised OPES intermediaries. However, IRML allows both endpoints to specify the behavior of the intermediary in the case of service execution failures (see section 3.7.4). The default behavior is to abort the data transaction and notify the application endpoint. (5) "Non-blocking: If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider." IRML does not prevent data consumers from receiving a "non-OPES" version of content if the data provider offers a "non-OPES" version of its content. For example, data providers could offer a "non-OPES" version under a different URI and make sure that their IRML rules do not trigger any OPES services for the "non-OPES" URI. (6) "URI resolution: OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself." This document does not define or describe OPES services. (7) "Reference validity: All proposed services must define their impact on inter- and intra-document reference validity." This document does not define or describe any specific OPES services. (8) "Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes." This document does not define or describe any specific OPES services. Beck, Hofmann Expires December 2003 [Page 17] Internet Draft IRML June 2003 (9) "Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries." This part of the OPES framework is not defined by this document. 6 Security Considerations Since data providers and data consumers can author IRML rule modules, it will be necessary to securely and reliably transfer rule modules from data providers/consumers to intermediary devices (or to other OPES entities in the same domain and from these entities to intermediary devices). Because IRML rule modules can control the execution of services, the receiving intermediary must be able to authenticate the rule module author and verify the integrity of the received rule module. IRML therefore REQUIRES that all IRML rule modules be signed by the rule module author using XML signatures as defined in [13]. Also, to protect the privacy of data providers and data consumers, application-layer or network-layer encryption SHOULD be applied to connections that are used for the transfer of IRML rule modules. As IRML-enabled intermediaries could potentially be the target of security attacks, intermediaries SHOULD be able to reject submitted IRML rule modules if accepting them would compromise their ability to function properly. Intermediaries SHOULD also be able to reject IRML rule modules that are incompatible with their own policies. 7 Acknowledgements The authors would like to thank all active participants in the OPES mailing list for their thought-provoking discussion, and many of the ideas and suggestions that have been incorporated into this document. 8 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments 2119, Harvard University, March 1997 3 Barbir, A., et al., "An Architecture For Open Pluggable Edge Services (OPES)", Work in Progress Internet Draft: draft-ietf- opes-architecture-04.txt, December 2002. Beck, Hofmann Expires December 2003 [Page 18] Internet Draft IRML June 2003 4 Barbir, A., et al., "OPES Use Cases and Deployment Scenarios", Work in Progress Internet Draft: draft-ietf-opes-scenarios- 01.txt, August 2002 5 Bray, T., et al., Extensible Markup Language (XML) 1.0 (Second Edition), http://www.w3.org/TR/2000/REC-xml-20001006, October 2000 6 Barbir, A., et al., "Policy, Authorization and Enforcement Requirements", Work in Progress, Internet Draft draft-ietf-opes- authorization-02.txt, February 2002 7 Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", Request for Comments 2616, June 1999 8 Klyne, G., et al., "Date and Time on the Internet: Timestamps", Work in Progress, Internet Draft "draft-ietf-impp-datetime- 05.txt", November 2001 9 ISO/IEC DIS 9945-2:1992, Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (IEEE Std 1003.2-1992); X/Open CAE Specification, Commands and Utilities, Issue 4, 1992 10 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", Request for Comments 2396, August 1998 11 Moats, R., "URN Syntax", Request for Comments 2141, May 1997 12 Floyd, S. et al., "IAB Architectural and Policy Considerations for OPES", RFC 3238, January 2002 13 Bartel, M. et al., "XML-Signature Syntax and Processing", W3C Recommendation, February 2002 Authors' Addresses Andre Beck Markus Hofmann Bell Labs Research Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 Phone: (732) 332-5983 Email: {abeck, hofmann}@bell-labs.com Appendix A - IRML DTD The DTD in this section describes the XML syntax of IRML. Every rule module submitted to an IRML-enabled intermediary or admin server MUST comply with this DTD. Note that compliance with this DTD is not a sufficient condition for correctness of an IRML rule module, as some of the conditions described in this document are not expressible in the DTD syntax. Beck, Hofmann Expires December 2003 [Page 19] Internet Draft IRML June 2003 Appendix B - IRML Extensions for HTTP For HTTP messages, IRML defines the following system variables: Property Name Value -------------------------------------------------------------- "request-line" the first line of an HTTP request "request-method" the HTTP request method, e.g. GET or POST "request-path" the rel_path of the request URI as defined in [7] "request-version" the HTTP version number as it appears in the first HTTP request line, e.g. HTTP/1.1 "request-host" the host name/IP address of the origin server as it appears in the first HTTP request line or HTTP "Host" request header Beck, Hofmann Expires December 2003 [Page 20] Internet Draft IRML June 2003 "request-uri" the absolute request URI as defined in [7] "response-line" the first line of an HTTP response "response-code" the HTTP response code as it appears in the first HTTP response line, e.g. 200 All intermediaries that accept IRML rule modules with a protocol value of "HTTP" MUST support the above listed HTTP-specific system variables. Appendix C - IRML Sub-Systems The following is a list of currently known IRML sub-systems: Sub-System Name Description Specification ---------------------------------------------------------------- Appendix D - Rule Module Examples Data provider Rule Module Example Lucent Technologies rule-info@lucent.com www.lucent.com Lucent Technologies rule-info@lucent.com www.lucent.com HTTP opes://local.net/insert-local-content Beck, Hofmann Expires December 2003 [Page 21] Internet Draft IRML June 2003 ... Data consumer Rule Module Example Andre Beck abeck@home.com 138.43.43.55 Lucent Technologies abeck@home.com www.lucent.com HTTP opes://privacy.net/priv-serv remove-referer ... Delegate Rule Module Example Comcast ISP rule-info@comcast.com www.comcast.com Beck, Hofmann Expires December 2003 [Page 22] Internet Draft IRML June 2003 Virus Scanning Subscribers vs-subscribers@comcast.com www.comcast.com/irml-groups/vs-subscribers HTTP opes://mcaffee.com/mscan opes://norton.com/nscan CNN rule-info@cnn.com www.cnn.com HTTP opes://mcaffee.com/mscan ... Beck, Hofmann Expires December 2003 [Page 23] Internet Draft IRML June 2003 Appendix E - IRML Change Log Changes from draft-beck-opes-irml-02.txt - aligned terminology with OPES WG documents - removed references to Web services - removed "may-execute" and "do-not-execute" elements - updated references section Changes from draft-beck-opes-irml-01.txt - replaced the element with three different rule action elements: (to request the execution of a service), (to disallow the execution of services), and (to permit the execution of services) - introduced "delegate" as rule module author and separation between rule module author and authorizing endpoint - introduced IRML rule sets as a collection of rules authorized by the same endpoint - introduced separation between service identification through URI and service execution parameters - added recommendation to use URNs as service identifiers - introduced support for dynamic parameters (i.e. the ability to pass run-time message, system, and service property values to service applications) - introduced "failure" attribute to allow endpoints to control the intermediary behavior in the case of service execution failures - introduced the concept of executing alternate services in the case of service execution failures - rewrote introduction - added "Rule Pocessing" section - added "IAB Considerations" section to address the recent IAB draft with considerations for OPES - changed mandated order of service execution - rewrote security considerations and introduced the requirement to use XML signatures in all rule modules - fixed syntax of comments in examples, clarified the meaning of the "request-path" system property and the regular expression syntax to be used in rule condition patterns (as suggested by M. Cinquini) - added more HTTP-specific system properties to simplify the rule matching for HTTP messages (as suggested by Lily Yang) - introduced "not-matches" attribute in property element (as suggested by M. Cinquini) - renamed "type" attribute in "property" elements to "context" - added "context" attribute values "req-msg" and "res-msg" to better differentiate between request message and response message properties (as suggested by R. Rahman) - introduced IRML sub-system attribute in "property" elements and appendix with list of known sub-systems (as suggested by C.W. Ng) - moved pre-defined HTTP-specific system properties to HTTP-specific appendix Beck, Hofmann Expires December 2003 [Page 24] Internet Draft IRML June 2003 - added IRML document identifiers for XML - rewrote all rule module examples to match the new IRML DTD - added this change log Changes from draft-beck-opes-irml-00.txt - updated references to include the models and policy requirements drafts - removed terminology section and referenced the taxonomy in the models draft instead - revised use of terminology to be conform with models draft terminology - removed access provider from list of rule authors (as suggested by new OPES charter) - late binding in field through OPES URI (as suggested by Lee Rafalow and others) - added "request-host" variable (as suggested by Francis Zane) - added type attribute to property element to accomodate three different types of properties: message, system, and service - added "client-ip" system variable to support services that depend on the client IP, e.g. URL rewriting in a CDN scenario - added support for arbitrary service state variables which also allows rule matching against members of dynamic groups (as suggested by Lee Rafalow and others) - new date format in system property (as suggested by Ian Cooper) - removed DEFAULT keyword in IRML DTD (as suggested by Ting) Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Beck, Hofmann Expires December 2003 [Page 25] Internet Draft IRML June 2003 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Beck, Hofmann Expires December 2003 [Page 26]