ietf-openproxy
[Top] [All Lists]

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

2003-08-13 10:11:23


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.