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>rule-management(_at_)comcast(_dot_)com</contact>
<id>www.comcast.com</id>
</author>
<author type="self">
<name>Andre Beck</name>
<contact>abeck(_at_)home(_dot_)com</contact>
<id>abeck(_at_)home(_dot_)com</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>abeck(_at_)lucent(_dot_)com</contact>
<id>abeck(_at_)lucent(_dot_)com</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, hofmann}(_at_)bell-labs(_dot_)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.
<!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>rule-info(_at_)lucent(_dot_)com</contact>
<id>www.lucent.com</id>
</author>
<ruleset>
<authorized-by class="data-provider" type="individual">
<name>Lucent Technologies</name>
<contact>rule-info(_at_)lucent(_dot_)com</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>abeck(_at_)home(_dot_)com</contact>
<id>138.43.43.55</id>
</author>
<ruleset>
<authorized-by class="data-consumer" type="individual">
<name>Lucent Technologies</name>
<contact>abeck(_at_)home(_dot_)com</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>rule-info(_at_)comcast(_dot_)com</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>vs-subscribers(_at_)comcast(_dot_)com</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>rule-info(_at_)cnn(_dot_)com</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]