ietf-openproxy
[Top] [All Lists]

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

2003-08-14 08:31:42


Andre,

        I think we narrowed our primary disagreement down to a
manageable size:

        - You envision IRML to be used to describe very basic
          rules, occasionally distributed to OPES processors
          using off-band mechanisms. You want the language
          itself to make it difficult to describe complex
          manipulations. IRML inspiration comes, in part,
          from CPL which targets IP telephony needs.

        - I see the value of Rule Language in supporting
          in-band distribution and dynamic interpretation.
          I want the language to be compact and conveniently
          powerful. I expect arrangements within a given
          OPES system to limit the complexity of actual
          expressions as/if needed. My inspiration comes,
          in part, from trends in ACL (Access Control List)
          specification languages used by HTTP proxies and
          L2-7 switches.

I doubt the above differences can be resolved by a compromise. One
primary direction should be chosen by the working group. Am I the only
person disliking the general direction of irml-03?

Thanks,

Alex.


On Wed, 13 Aug 2003, Andre Beck wrote:


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