Subject: draft-beck-opes-irml-03.txt

From: Andre Beck <[email-masked]>
Date: Tue, 24 Jun 2003 18:04:13 -0400

Hi,

We revived and re-submitted the attached IRML draft in an attempt to 
trigger some discussion on how to specify service execution rules in OPES.

Comments welcome!

-Andre

   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  
    
   <author type="delegate">  
     <name>Comcast</name>  
     <contact>[email-masked]</contact> 
     <id>www.comcast.com</id>  
   </author>  
    
   <author type="self">  
     <name>Andre Beck</name>  
     <contact>[email-masked]</contact> 
     <id>[email-masked]</id>  
   </author>  
    
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 
 
   <ruleset> 
     <authorized-by class="data-consumer" type="individual"> 
       <name>A. Beck</name> 
       <contact>[email-masked]</contact> 
       <id>[email-masked]</contact> 
     </authorized-by> 
     <protocol>HTTP</protocol> 
     <rule processing-point=1> 
       <!-- Log ALL my requests --> 
       <execute> 
         <service name="Request Log"> 
           <uri>opes://log.com/requestlog-v1.0</uri> 
           <parameter name="timestamp" type="dynamic"> 
             <variable name="system-time" context="system"/> 
           </parameter> 
         </service> 
       </execute>     
     </rule> 
     <rule processing-point=4> 
       <!-- Is the requested web resource a HTML document? -->  
       <property name="Content-Type" context="res-msg" 
                                                   matches="text/html">  
         <!-- Is the user's preferred language supported? -->  
         <property name="Accept-Languages" context="req-msg" 
                                             matches="^de|^fr|^it|^es">  

   Beck, Hofmann        Expires December 2003               [Page 14] 
   Internet Draft                IRML                        June 2003 
    
           <!-- Invoke translation service Babelfish -->  
           <execute> 
             <service name="BabelFish Translation">  
               <uri>opes://altavista.com/babelfish</uri>  
             </service> 
           </execute> 
         </property>  
       </property>  
     </rule>  
   </ruleset> 
    
   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, [email-masked]  
    
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. 
    
   <!ELEMENT rulemodule    (author, ruleset+)>  
   <!ELEMENT author        (name, contact?, id)>  
   <!ELEMENT ruleset       (authorized-by, protocol, rule+)>  

   Beck, Hofmann        Expires December 2003               [Page 19] 
   Internet Draft                IRML                        June 2003 
    
   <!ELEMENT authorized-by (name, contact?, id)>  
   <!ELEMENT name          (#PCDATA)>  
   <!ELEMENT contact       (#PCDATA)>  
   <!ELEMENT id            (#PCDATA)>  
   <!ELEMENT protocol      (#PCDATA)>  
   <!ELEMENT rule          (property|execute)+>  
   <!ELEMENT property      (property|execute)+>  
   <!ELEMENT execute       (service+)>  
   <!ELEMENT service       (any|uri, parameter*)>  
   <!ELEMENT uri           (#PCDATA)>  
   <!ELEMENT any           EMPTY>  
   <!ELEMENT parameter     (value|variable)>  
   <!ELEMENT value         (#PCDATA)>  
   <!ELEMENT variable      (#PCDATA)>  
    
   <!ATTLIST author        type        (delegate|self)          "self">  
   <!ATTLIST authorized-by class       (data-provider|data-consumer) 
                                                             #REQUIRED>  
   <!ATTLIST authorized-by type        (individual|group) "individual">  
    
   <!ATTLIST rule          processing-point  (1|2|3|4)       #REQUIRED>  
    
   <!ATTLIST property      name        CDATA                 #REQUIRED>  
   <!ATTLIST property      context     (req-msg|res-msg|system|service) 
                                                             #REQUIRED>  
   <!ATTLIST property      sub-system  CDATA                "standard">   
   <!ATTLIST property      matches     CDATA                 #REQUIRED>  
   <!ATTLIST property      not-matches CDATA                 #REQUIRED>  
   <!ATTLIST property      case-sensitive    (yes|no)             "no">  
   <!ATTLIST service       name        CDATA                  #IMPLIED>  
   <!ATTLIST service       type        (primary|alternate)   "primary">  
   <!ATTLIST service       failure     (abort|ignore|try-alternate) 
                                                               "abort">  
   <!ATTLIST parameter     name        CDATA                 #REQUIRED> 
   <!ATTLIST parameter     type        (static|dynamic)      #REQUIRED> 

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  
     
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="self">  
       <name>Lucent Technologies</name>  
       <contact>[email-masked]</contact> 
       <id>www.lucent.com</id>  
     </author>  
     <ruleset> 
       <authorized-by class="data-provider" type="individual"> 
         <name>Lucent Technologies</name>  
         <contact>[email-masked]</contact> 
         <id>www.lucent.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="4">  
         <!-- Is the requested web document our home page? -->  
         <property name="request-path" context="system" 
                 matches="^/$|^/index.html$" case-sensitive="yes">  
           <!-- Does the user send us a specific cookie? -->  
           <property name="Cookie" matches="sew=23">  
             <execute> 
               <service name="Localized Content" failure="ignore">  
                 <uri>opes://local.net/insert-local-content</uri>  
                 <parameter name="clientip" type="dynamic"> 
                   <variable name="client-ip" context="system"/> 
                 </parameter> 
               </service> 
             </execute> 
           </property>  

   Beck, Hofmann        Expires December 2003               [Page 21] 
   Internet Draft                IRML                        June 2003 
    
         </property>  
       </rule>  
     </ruleset> 
   </rulemodule>  
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 
    
   Data consumer Rule Module Example  
        
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="self">  
       <name>Andre Beck</name>  
       <contact>[email-masked]</contact> 
       <id>138.43.43.55</id>  
     </author>  
     <ruleset> 
       <authorized-by class="data-consumer" type="individual"> 
         <name>Lucent Technologies</name>  
         <contact>[email-masked]</contact> 
         <id>www.lucent.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="1">  
         <!-- Execute a privacy service that removes the HTTP "Referer" 
              header from all my requests -->  
         <execute> 
           <service name="Privacy Service" failure="ignore">  
             <uri>opes://privacy.net/priv-serv</uri>  
             <parameter name="action" type="static"> 
               <value>remove-referer</value> 
             </parameter> 
           </service> 
         <execute> 
       </rule>  
     </ruleset> 
   </rulemodule>  
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 
    
   Delegate Rule Module Example 
    
   <?xml version="1.0"?>  
   <rulemodule xmlns="http://www.rfc-editor.org/rfc/rfcxxxx.txt">  
     <author type="delegate">  
       <name>Comcast ISP</name>  
       <contact>[email-masked]</contact> 
       <id>www.comcast.com</id>  
     </author>  
     <ruleset> 

   Beck, Hofmann        Expires December 2003               [Page 22] 
   Internet Draft                IRML                        June 2003 
    
       <!-- This set of rules applies to a group of ISP customers -->  
       <authorized-by class="data-consumer" type="group"> 
         <name>Virus Scanning Subscribers</name>  
         <contact>[email-masked]</contact> 
         <id>www.comcast.com/irml-groups/vs-subscribers</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point="4">  
         <!-- Can the requested web object contain a virus? -->  
         <property name="Content-Type" context="res-hdr"  
                                                 matches="application/">  
           <execute> 
             <service name="McAfee Virus Scanning Service" 
                                 type="primary" failure="try-alternate"> 
               <uri>opes://mcaffee.com/mscan</uri>  
             </service>  
             <service name="Norton Virus Scanning Service"               
                                                       type="alternate"> 
               <uri>opes://norton.com/nscan</uri>  
             </service>  
           </execute> 
         </property> 
       </rule>  
     </ruleset> 
     <ruleset> 
       <!-- This set of rules applies to a specific data provider --> 
       <authorized-by class="data-provider" type="individual"> 
         <name>CNN</name>  
         <contact>[email-masked]</contact> 
         <id>www.cnn.com</id>  
       </authorized-by>  
       <protocol>HTTP</protocol>  
       <rule processing-point=4> 
         <property name="request-uri" context="system"  
                                   matches="http://www.cnn.com/file.exe> 
           <!-- CNN wants to allow only the McAffee virus scanning 
                service on this file because there are known issues with  
                Norton's Virus scanning service and particular files.--> 
           <execute> 
             <service name="McAffee Virus Scanning Service"> 
               <uri>opes://mcaffee.com/mscan</uri>  
             </service> 
           </execute>  
         </property> 
       </rule>   
     </ruleset> 
   </rulemodule> 
   <signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
     ... 
   </signature> 

   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 <action> element with three different rule action 
     elements: <execute> (to request the execution of a service),  
     <do-not-execute> (to disallow the execution of services), and 
     <may-execute> (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 <action> 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-date> 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]

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 24 Jun 2003 22:15:01 -0400

Folks,

> trigger some discussion on how to specify service execution rules in OPES.

While we're making good progress with the protocol, we're behind with 
the rules language. We really need to get going here.

As Andre indicates, re-submission of the individual draft is intended 
to trigger some discussions. Please check it out and provide comments 
on the list - either to the draft itself or to the area in general.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 27 Jun 2003 11:21:08 -0600 (MDT)

On Tue, 24 Jun 2003, Markus Hofmann wrote:

> > We revived and re-submitted the attached IRML draft in an attempt
> > to trigger some discussion on how to specify service execution
> > rules in OPES.
>
> While we're making good progress with the protocol, we're behind
> with the rules language. We really need to get going here.
>
> As Andre indicates, re-submission of the individual draft is
> intended to trigger some discussions. Please check it out and
> provide comments on the list - either to the draft itself or to the
> area in general.

I may have few friends left after this message, but I hope that these
comments would do at least some good as well.

My first reaction to the draft is negative. I hope that I missed
something important and that my opinion can be reversed by the
discussion. Below are first high-level comments; no reason to go into
line-by-line specifics if I am wrong about the overall draft
structure/direction.

0) IRLM draft provides insufficient set of general mechanisms for rule
   specification yet also documents many HTTP-specific extensions or
   bindings. This must be fixed. The draft should either define core
   mechanisms and strive to be application agnostic or be
   HTTP-specific. In either case, major additions and changes would be
   required: more general mechanisms are needed and more/different
   HTTP-specific bindings are required. In other words, I am not just
   talking about splitting the draft in two.

1) IRLM is closely tied to a very narrow interpretation of the OPES
   architecture. The language should focus on a more general (yet
   well-scoped) task of expressing a message adaptation rule:

	if "condition" then do "action";

   The "condition" expression should be powerful enough to express a
   mixture of processing points, processor state, application message
   properties, and extensions. The draft artificially segregates, for
   example, processing points, from message properties, severely
   limiting expression power.

   [Side note: Fortunately for us, the "action" part is rather
    simple -- execute service(s)]

2) IRML attempts to enforce rules authorship. IMO, the Rule
   Specification language must focus on specifying the rules, not
   trying to specify or enforce who has the right to submit or execute
   them. For example, imagine C or Java languages with constructs to
   specify/enforce software copyright. I believe that rights
   specification and enforcement requires different mechanisms from
   rules specification. Moreover, both mechanisms lack key features in
   the current draft.

3) I doubt that efficient rule processing would be possible with IRML.
   The language provides no mechanisms to reuse groups of rules (e.g.,
   procedures or functions) or to reuse computation results (i.e.,
   variables). Without such mechanisms, a realistic IRML program will
   be slow. It will also be huge and difficult to manage.

4) I question the choice of XML syntax. Rule specification is much
   closer to a program than it is to a static tree of configuration
   options. I believe that the history of languages used to express
   application routing, load balancing, and filtering decisions at
   intermediaries proves my point: while the industry has started with
   simple maps and tables, the application-level requirements forced
   implementors to support much more flexible rule programming. The
   choice of XML as IRLM syntax makes it very awkward to express
   anything that goes beyond a simple rule. IMO, XML must not be used
   as a programming language syntax.

   XML justification in the draft is "many publicly available parsers
   and editing tools can be used". This is a very weak argument
   because (a) getting XML tree parsed is only a minor step towards
   interpreting IRML and (b) there are more XML-unaware editing tools
   than XML-aware editing tools. The authors claim that "The structure
   of the language maps closely to its behavior" which I believe is
   true only for the authorship part of the language and only
   partially true for the actual rule specification language.
   Moreover, the behavior that XML maps to is the wrong one! See items
   (1) and (3) above. The last argument (ease of IRML validation) is
   also weak because (a) any applicable language syntax would
   relatively easy to validate and (b) syntax validation does little
   good since most errors are of semantic nature, unrelated to DTD
   validity.

If my observations above I correct, I would be surprised to see IRML
supported in practice. It can offer major users a lot less than custom
solutions (future or existing). Again, I would like to be proven wrong
because there is clearly a lot of effort put into the draft, and I am
late with my comments.

HTH,

Alex.

---

From: Andre Beck <[email-masked]>
Date: Mon, 30 Jun 2003 14:56:47 -0400

> comments would do at least some good as well.

Don't worry, Alex. We appreciate any and all (constructive) comments...

>    talking about splitting the draft in two.

I absolutely agree that the goal should be to have a protocol-agnostic
rule matching core and protocol-specific extensions. Earlier versions of
IRML were HTTP-specific and since then we have tried to separate the
HTTP-specific parts from the generic parts, but, as you pointed out,
more work needs to be done to complete this process.

>    limiting expression power.

The "property" element can already refer to application message
properties (i.e. protocol header values), environment/system variables,
and sub-system properties. I don't consider the processing point a rule
condition. Rather, I believe it's a rule attribute as it specifies when
a rule is to be processed. As such, I don't see how the current IRML
design limits expression power. Can you think of a specific example that
shows where IRML lacks expression power?

>    rules specification. Moreover, both mechanisms lack key features in

I am not sure IRML attempts to enforce rule authorship/authorization. It
does allow rule authors to specify rule authorship/authorization, but
how this is enforced is up to the OPES processor or whatever OPES
element receives IRML rules. Generally, I agree with your statement, 
though.

>    be slow. It will also be huge and difficult to manage.

Well, we never envisioned that an OPES processor would actually process
IRML rule files on the fly as it receives user requests/responses.
Instead, we figured that there would be a separate offline process that
receives IRML rule files from external sources, validates them and
subsequently translates them into some internal, proprietary format
optimized for efficient rule processing.

>    as a programming language syntax.

I don't think it's realistic to expect that OPES processors would be
able to process whatever you can express with a full-fledged programming
language just to determine which requests/responses need further OPES
processing. This would probably impose an unacceptable performance
penalty on those transactions that don't need further processing. Also,
I doubt that a service provider would let external rule authors specify
complex rule logic that could use up any amount of processing power,
e.g. through loops etc. For these reasons we decided to keep IRML rules
very simple and XML seems to be a very suitable format to do just that.

>    interpreting IRML and

True, but would this second step by any easier if we used a different
format?

> (b) there are more XML-unaware editing tools
>    than XML-aware editing tools.

True, but then again non-XML formats would have the same problem, right?

Thanks,
Andre