On Mon, 30 Jun 2003, Andre Beck wrote:
Alex Rousskov wrote:
1) IRLM is closely tied to a very narrow interpretation of the
OPES architecture. The language should focus on a more general
(yet well-scoped) task of expressing a message adaptation rule:
if "condition" then do "action";
The "condition" expression should be powerful enough to express
a mixture of processing points, processor state, application
message properties, and extensions. The draft artificially
segregates, for example, processing points, from message
properties, severely limiting expression power.
I don't consider the processing point a rule condition. Rather, I
believe it's a rule attribute as it specifies when a rule is to be
processed. As such, I don't see how the current IRML design limits
expression power. Can you think of a specific example that shows
where IRML lacks expression power?
condition1 :=
processing_point == 2 or
processing_point == 5
condition2 :=
message_headers contain "Connection" or
message_headers contain "Proxy-Connection"
rule :=
if condition1 and condition2 then do_something;
Is there a good way to express the above logic using irml-03? BTW, the
above example also illustrates (without details) how a UTF-8-based
rule language could express the desired logic.
Note that the use of processing_point is not really essential
(moreover, documenting specific processing points is not appropriate
for an application-agnostic rule language). Similar examples can be
made with other attributes. For example,
...
conditionA :=
condition1 and condition0;
conditionB :=
condition2 and not condition0
rule :=
if conditionA or conditionB then do_something;
While I was not technically accurate what I used the term "expression
power", I hope the above examples illustrate that proposed irml-03 does
not let us express the above logic in a
good/convenient/suitable/efficient "enough" form.
2) IRML attempts to enforce rules authorship. IMO, the Rule
Specification language must focus on specifying the rules, not
trying to specify or enforce who has the right to submit or execute
them. For example, imagine C or Java languages with constructs to
specify/enforce software copyright. I believe that rights
specification and enforcement requires different mechanisms from
rules specification. Moreover, both mechanisms lack key features in
the current draft.
I am not sure IRML attempts to enforce rule authorship/authorization. It
does allow rule authors to specify rule authorship/authorization, but
how this is enforced is up to the OPES processor or whatever OPES
element receives IRML rules.
The specs seem to enforce authorization (Section 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 ...
contain rule sets which have been authorized by either endpoint
of the transaction.
Generally, I agree with your statement, though.
3) I doubt that efficient rule processing would be possible with IRML.
The language provides no mechanisms to reuse groups of rules (e.g.,
procedures or functions) or to reuse computation results (i.e.,
variables). Without such mechanisms, a realistic IRML program will
be slow. It will also be huge and difficult to manage.
Well, we never envisioned that an OPES processor would actually
process IRML rule files on the fly as it receives user
requests/responses. Instead, we figured that there would be a
separate offline process that receives IRML rule files from external
sources, validates them and subsequently translates them into some
internal, proprietary format optimized for efficient rule
processing.
Sorry if I missed this very important assumption in the spec. It seems
to me that this assumption limits irml-03 applicability to
intermediaries with which content providers have a long-lasting and
mostly static relationship. IMO, the primary value of Rules Language
(from IETF point of view) would be to allow dynamic rule
interpretation and inclusion of rules with application message
metadata.
For example, if we are talking about HTTP adaptation, the content
provider should be able to say something like this using HTTP
response headers:
OPES-Rule: if condition1 do apply_service1;
Does everybody agree that support of such dynamic and/or embedded
rules is out of scope?
4) I question the choice of XML syntax. Rule specification is much
closer to a program than it is to a static tree of configuration
options. I believe that the history of languages used to express
application routing, load balancing, and filtering decisions at
intermediaries proves my point: while the industry has started with
simple maps and tables, the application-level requirements forced
implementors to support much more flexible rule programming. The
choice of XML as IRLM syntax makes it very awkward to express
anything that goes beyond a simple rule. IMO, XML must not be used
as a programming language syntax.
I don't think it's realistic to expect that OPES processors would be
able to process whatever you can express with a full-fledged programming
language just to determine which requests/responses need further OPES
processing.
Neither do I. There is a lot of room between irml-03 and a
"full-fledged programming language".
This would probably impose an unacceptable performance penalty on
those transactions that don't need further processing. Also, I doubt
that a service provider would let external rule authors specify
complex rule logic that could use up any amount of processing power,
e.g. through loops etc. For these reasons we decided to keep IRML
rules very simple and XML seems to be a very suitable format to do
just that.
Clearly, there is a trade-off between what the rules can do and how
much processing is needed to interpret them. IMO, there are many
useful enough cases that can be processed more efficiently than
irml-03 (due to its simplifications/limitations) allows. See examples
above.
XML justification in the draft is "many publicly available parsers
and editing tools can be used". This is a very weak argument
because (a) getting XML tree parsed is only a minor step towards
interpreting IRML and
True, but would this second step by any easier if we used a different
format?
Maybe not. That is exactly why this argument should not be used. All
reasonable language formats would require at most the
pre-interpretation expenses of irml-03.
(b) there are more XML-unaware editing tools
than XML-aware editing tools.
True, but then again non-XML formats would have the same problem, right?
Hard to say. There are more ASCII-aware editing tools than there are
XML-aware editing tools. It is a question of whether generic editing
tools can assist rules writing enough to justify a particular encoding
format. IMO, no, they cannot (and so this argument should not be
used).
Thanks,
Alex.