We just submitted the attached IRML draft update. The most significant
change in this version is that endpoints can now not only request the
execution of services, but may also disallow or permit (but not request)
the execution of specific services. This changes the functionality of
IRML quite a bit, so we'd appreciate comments and feedback on these as
well as other changes in this version which are listed below:
Changes from draft-beck-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
- added IRML document identifiers for XML
- rewrote all rule module examples to match the new IRML DTD
- added a change log
Internet Draft A. Beck
M. Hofmann
Expires: May 22, 2002 Lucent Technologies
Document: draft-beck-opes-irml-02.txt
November 21, 2001
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 Web
services in general and OPES content services in particular.
Web services are a new class of applications running on networked
computers in a distributed environment. These services are invoked
either directly by application endpoints or through intermediaries
acting on behalf of application endpoints. Such intermediaries can
appear in the form of caches, proxies, gateways, switches, etc. and
are also referred to as Service Dispatchers, Application Brokers,
Service Brokers, etc. 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
Web services according to these rules and policies.
Beck, Hofmann Expires May 2002 [Page 1]
Internet Draft IRML November 2001
Table of Contents
1 Terminology....................................................3
2 Introduction...................................................3
3 IRML Syntax and Grammar........................................4
3.1 High-level Structure of IRML Documents.......................5
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.......................................7
3.4.2 The "authorized-by" Element.................................7
3.4.3 The "protocol" Element......................................8
3.5 IRML Rules...................................................8
3.5.1 The "rule" Element..........................................8
3.6 IRML Rule Conditions.........................................9
3.6.1 The "property" Element......................................9
3.6.2 Unconditional Rules........................................11
3.7 IRML Rule Actions...........................................12
3.7.1 The "execute" Element......................................12
3.7.2 The "do-not-execute" Element...............................12
3.7.3 The "may-execute" Element..................................12
3.7.4 The "service" Element......................................12
3.7.5 The "uri" Element..........................................13
3.7.6 The "any" Element..........................................14
3.7.7 The "parameter" Element....................................14
3.7.8 The "value" Element........................................15
3.7.9 The "variable" Element.....................................15
3.8 IRML Rule Set Example.......................................15
4 IRML Rule Processing..........................................16
4.1 Conflict Resolution for Endpoints...........................16
4.2 Order of Service Execution..................................17
5 IAB Considerations............................................17
6 Security Considerations.......................................19
7 Acknowledgements..............................................20
8 References....................................................20
Authors' Addresses...............................................20
Appendix A - IRML DTD............................................21
Appendix B - IRML Extensions for HTTP............................22
Appendix C - IRML Sub-Systems....................................22
Beck, Hofmann Expires May 2002 [Page 2]
Internet Draft IRML November 2001
Appendix D - Rule Module Examples................................22
Appendix E - IRML Change Log.....................................25
Full Copyright Statement.........................................27
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].
CONTENT TRANSACTION
A message exchange between a content consumer and a content owner,
typically consisting of a content request and a content response
message.
CONTENT PATH
The path that content requests and responses take through the
network. Typically, content requests and responses flow between a
client (content consumer) and an origin server (content owner).
CONTENT PATH PROTOCOL
The application-layer protocol used between the two endpoints of a
content 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 Web 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 complicated rule conditions.
IRML can be used in particular, but not exclusively, in the context
of the OPES content services framework as proposed in [3] and [4].
Since OPES services may only be executed on behalf of content owners
or content consumers - the two endpoints of a content transaction -
IRML-specified rules must reflect the intents of either of the two
endpoints. A content owner 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).
Beck, Hofmann Expires May 2002 [Page 3]
Internet Draft IRML November 2001
In its basic form, IRML is not tied to any particular content path
protocol or deployment environment. However, IRML allows for
extensions that can be used to better accommodate the specifics of
content path protocols or different deployment environments.
It is anticipated that IRML rules will either be authored directly
by content owners or content 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 content
owners 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.
Whether or not a service application is executed primarily depends
on the specified rule actions in all matching rules. It is important
to note, however, that rules may be provided by both endpoints of a
content transaction which may lead to rule conflicts, e.g. if a
content consumer wishes to execute a service that the content owner
explicitly disallowed on his content. The resolution of such rule
conflicts and the final decision whether or not to execute a service
remains with the intermediary device processing the rules.
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 at
the time they are delivered to it.
Although this document does not define a secure and reliable
mechanism for transferring IRML rule files to intermediary devices
or admin servers, 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".
Beck, Hofmann Expires May 2002 [Page 4]
Internet Draft IRML November 2001
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 content
owners 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.
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,
disallow the execution of services, or permit the execution of
services.
The conditions within a rule refer to message properties in the
request or response message of a given content 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
content owners and content consumers. The service execution policy
of a specific content owner 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 content owners, content
consumers, or authorized delegates who author rule modules on behalf
of content owners 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.
Beck, Hofmann Expires May 2002 [Page 5]
Internet Draft IRML November 2001
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 content owner 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.
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>Markus Hofmann</name>
<contact>mhof(_at_)home(_dot_)com</contact>
<id>mhof(_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 content owner or content consumer.
Beck, Hofmann Expires May 2002 [Page 6]
Internet Draft IRML November 2001
3.4.1 The "ruleset" Element
The "ruleset" element MUST contain one or more "rule" elements. Rule
modules authored directly by a content owner 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 content owner/consumer.
3.4.2 The "authorized-by" Element
The "authorized-by" element specifies the authorizing content
transaction endpoint for a set of rules. This MUST be either a
content owner or a content consumer. In self-authored rule modules,
the authorizing endpoint MUST be identical with the rule module
author.
Name Values Default
-----------------------------------------------------
class content-owner|content-consumer
type individual|group
The "class" attribute specifies whether the authorizing endpoint is
a content owner or content consumer.
The "type" attribute specifies whether the corresponding rule set
applies to and has been authorized by an individual content
owner/consumer or a group of content owners/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
content owners/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 content
owners/consumers and the "contact" element SHOULD contain an email
address at which the delegate managing the group can be contacted.
Beck, Hofmann Expires May 2002 [Page 7]
Internet Draft IRML November 2001
3.4.3 The "protocol" Element
The "protocol" element specifies the applicable content path
protocol for a set of rules. It MUST contain the protocol acronym of
the applicable content 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 content path
protocol.
3.5 IRML Rules
IRML rules make up the actual service execution policies of content
owners and consumers. They are composed of rule conditions and rule
actions.
3.5.1 The "rule" Element
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 (such as "execute", "do-not-execute", or
"may-execute").
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.
Beck, Hofmann Expires May 2002 [Page 8]
Internet Draft IRML November 2001
+--------+ +-----------+ +--------+
| |<------|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, content 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 content
consumers as well.
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", "do-not-execute", or
"may-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
Beck, Hofmann Expires May 2002 [Page 9]
Internet Draft IRML November 2001
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:
Property Name Value
--------------------------------------------------------------
"system-date" a timestamp using the Internet date-time
format as defined in [8]
"client-ip" the IP address of the content consumer in
the common dotted-decimal format
In addition to these general system properties, IRML also defines
content 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].
Beck, Hofmann Expires May 2002 [Page 10]
Internet Draft IRML November 2001
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
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 [10].
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 content 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.
Beck, Hofmann Expires May 2002 [Page 11]
Internet Draft IRML November 2001
3.7 IRML Rule Actions
Through IRML rule actions, endpoints can request the execution of
services, disallow the execution of services, or permit the
execution of services. These three types of rule actions are
represented by the following three 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 "do-not-execute" Element
The "do-not-execute" element is a rule action element that can be
used to express the intent of the authorizing endpoint to prevent
the execution of a service application if the surrounding "property"
rule conditions are true. The service(s) that the rule author does
not want to be executed is further specified by the contained
"service" element(s).
3.7.3 The "may-execute" Element
The "may-execute" element is a rule action element that can be used
to express the permission of the authorizing endpoint to execute the
service that is specified by the contained "service" element(s) if
a) the surrounding "property" rule conditions are true and
b) the other endpoint of a given content transaction requests the
execution of the specified service
This implies that under the specified conditions the rule author
wishes to prevent the execution of any service that is not specified
by this or any other applicable "may-execute" elements.
For example, the "may-execute" element may be used by a content
owner in order to allow the execution of a specific set of trusted
OPES services on its content, but disallow all other services.
By default and unless otherwise specified, an endpoint gives
permission to the other endpoint of a given content transaction to
execute any service under any condition. The final decision on
whether to execute a service application, however, also depends on
the local policy of the intermediary.
3.7.4 The "service" Element
Rule action elements apply to a service application which is further
specified by the "service" element. The "service" element contains
Beck, Hofmann Expires May 2002 [Page 12]
Internet Draft IRML November 2001
either a "uri" to identify a specific service application or an
"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 content
transaction and inform the content consumer and possibly also the
content owner 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.5 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
Beck, Hofmann Expires May 2002 [Page 13]
Internet Draft IRML November 2001
specific instance at run-time in order to accommodate for system or
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 [11] 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 [12] 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.6 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.7 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 May 2002 [Page 14]
Internet Draft IRML November 2001
3.7.8 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.9 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="content-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 May 2002 [Page 15]
Internet Draft IRML November 2001
<!-- 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 content transaction the rule processor on the intermediary
located in the path between content consumers and content owners
MUST process only those IRML rule sets that are relevant to the
current transaction, i.e. all IRML rule modules that apply to the
content 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.
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. Conflicts within the rule set of one endpoint MUST
be resolved according to the rules in section 4.1.
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
While conflicts between the two endpoints of a content transaction
have to be resolved according to the local policy of the
intermediary, the following rule MUST be applied to the resolution
of conflicts created by rules authorized by the same endpoint:
Restricting IRML rule actions, as expressed by the elements "do-not-
execute" and "may-execute", always override any conflicting service
execution intents as expressed by the element "execute". In other
words, if the same endpoint wishes to execute a service and at the
Beck, Hofmann Expires May 2002 [Page 16]
Internet Draft IRML November 2001
same time disallows the execution of this service, then the service
MUST NOT be executed.
4.2 Order of Service Execution
The order in which service applications on the intermediary device
are executed may change the final result of a content 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
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 content transaction, i.e. for
incoming requests at processing points 1 and 2, the order of service
execution would be:
1. Content consumer authorized rule actions
2. Content owner authorized rule actions
For outgoing responses at points 3 and 4, the service execution
order would be reverse:
1. Content owner authorized rule actions
2. Content consumer authorized rule actions
5 IAB Considerations
This section quotes the IAB's architectural and policy
considerations for the OPES framework [13] 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 content transaction.
Beck, Hofmann Expires May 2002 [Page 17]
Internet Draft IRML November 2001
(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."
Both content owners and content 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 content owners/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
content consumers and owners 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
content 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 content consumers from receiving a "non-OPES"
version of content if the content owner offers a "non-OPES" version
of its content. For example, content owners 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.
Beck, Hofmann Expires May 2002 [Page 18]
Internet Draft IRML November 2001
(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.
(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 IRML rule modules can be authored by content owners and
content consumers, it will be necessary to securely and reliably
transfer rule modules from content owners/consumers to intermediary
devices (or to admin servers in the same domain and from admin
servers to intermediary devices).
Because IRML rule modules can control the execution of services, the
receiving intermediary or admin server 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 [14].
Also, to protect the privacy of content owners and content
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.
Beck, Hofmann Expires May 2002 [Page 19]
Internet Draft IRML November 2001
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 Tomlinson, G., et al., "A Model for Open Pluggable Edge
Services," Work in Progress Internet Draft: draft-tomlinson-opes-
model-01.txt, November 2001.
4 McHenry, S., et al., "OPES Use Cases and Deployment Scenarios",
Work in Progress Internet Draft: draft-mchenry-opes-deployment-
scenarios-00.txt, July 2001
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 Rafalow, L., et al., "Policy Requirements for Edge Services",
Work in Progress, Internet Draft draft-rafalow-opes-policy-
requirements-00.txt, July 2001
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 Ng, C. W. et al., "Quality of Service Extension to IRML",
Internet Draft "draft-ng-opes-irmlqos-00.txt", July 2001
11 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", Request for
Comments 2396, August 1998
12 Moats, R., "URN Syntax", Request for Comments 2141, May 1997
13 Floyd, S. et al., "IAB Architectural and Policy Considerations
for OPES", Internet Draft "draft-iab-opes-01.txt", October 2001
14 Bartel, M. et al., "XML-Signature Syntax and Processing", W3C
Proposed Recommendation, August 2001
Authors' Addresses
Andre Beck
Markus Hofmann
Bell Labs Research
Beck, Hofmann Expires May 2002 [Page 20]
Internet Draft IRML November 2001
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+)>
<!ELEMENT authorized-by (name, contact?, id)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT contact (#PCDATA)>
<!ELEMENT id (#PCDATA)>
<!ELEMENT protocol (#PCDATA)>
<!ELEMENT rule (property|execute|do-not-execute|
may-execute)+>
<!ELEMENT property (property|execute|do-not-execute|
may-execute)+>
<!ELEMENT execute (service+)>
<!ELEMENT do-not-execute(service+)>
<!ELEMENT may-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 (content-owner|content-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>
Beck, Hofmann Expires May 2002 [Page 21]
Internet Draft IRML November 2001
<!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
"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
----------------------------------------------------------------
QoS QoS-specific system properties [10]
Appendix D - Rule Module Examples
Content Owner 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>
Beck, Hofmann Expires May 2002 [Page 22]
Internet Draft IRML November 2001
<ruleset>
<authorized-by class="content-owner" 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>
</property>
</rule>
<rule processing-point="4">
<!-- We don't want the user to run a specific language
translation service on any_of our pages -->
<do-not-execute>
<service name="Babelfish Translation">
<uri>opes://babelfish.com/translation</uri>
</service>
</do-not-execute>
</rule>
</ruleset>
</rulemodule>
<signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
...
</signature>
Content 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="content-consumer" type="individual">
<name>Lucent Technologies</name>
<contact>abeck(_at_)home(_dot_)com</contact>
Beck, Hofmann Expires May 2002 [Page 23]
Internet Draft IRML November 2001
<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>
<!-- This set of rules applies to a group of ISP customers -->
<authorized-by class="content-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>
Beck, Hofmann Expires May 2002 [Page 24]
Internet Draft IRML November 2001
</property>
</rule>
</ruleset>
<ruleset>
<!-- This set of rules applies to a specific content owner -->
<authorized-by class="content-owner" 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.-->
<may-execute>
<service name="McAffee Virus Scanning Service">
<uri>opes://mcaffee.com/mscan</uri>
</service>
</may-execute>
</property>
</rule>
</ruleset>
</rulemodule>
<signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
...
</signature>
Appendix E - IRML Change Log
Changes from draft-beck-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
Beck, Hofmann Expires May 2002 [Page 25]
Internet Draft IRML November 2001
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
- 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-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)
Beck, Hofmann Expires May 2002 [Page 26]
Internet Draft IRML November 2001
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
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 May 2002 [Page 27]