ietf-openproxy
[Top] [All Lists]

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

2003-08-13 19:54:17

Alex Rousskov wrote:

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.

OK, I agree with that statement, though I still have doubts whether or not there is really a need to express rules that are so complex that it would be cumbersome to express them with IRML. Wouldn't most OPES services simply be triggered by matching a pattern against the requested URL? If I look at the classic OPES service examples like virus scanning, request filtering, ad insertion etc. I just don't see a need for rules with multiple, nested rule conditions.

Also, the reason why processing points in IRML are rule attributes and not rule conditions is that this allows rules to be grouped by processing point. That way, only rules relevant to a specific processing point need to be evaluated at any given time.

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.

OK, that sentence should probably go to a separate document about rule authorization. I agree that IRML should neither specify how rules are authorized nor how the authorization is enforced.

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?

That is indeed a good question. IRML certainly isn't designed to be used in application protocol headers. I would agree that an XML-based format would not be suitable for this type of dynamic rules.

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.

Again, I don't think OPES needs to or should support such rule constructs. Thus I think IRML's simplifications and limitations are a feature and not a bug. ;-)

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).

Well, a generic XML editor - if configured with the IRML DTD - can at least assist the author in that it can enforce the syntax and grammar of IRML modules.

-Andre