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

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 10:13:39 -0600 (MDT)

On Fri, 25 Jul 2003, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > I will try to show that XML presents virtually no advantages
> > compared to a domain specific language and introduces significant
> > hurdles.
>
> I assume "domain specific language" implies a "custom/new/specific"
> language?

Yes (assuming there is not one available already). Please note that
proposed IRML is also a new domain specific language.

> If so, allow me to raise flag in that we should use existing
> approaches (e.g. XML or others) as long as they don't have serious
> disadvantages, rather than inventing everything ourselves.

It looks like I may have introduced a terminology/classification
problem. Rules Language can use XML or, say, UTF-8 to represent its
tokens. Both XML and UTF-8 are "existing approaches".

The main problem with XML is that in addition to providing lexical
tokens for the Rules Language, XML demands certain hierarchical
relationship and order between language statements. IMO, that
relationship and order are note appropriate for a good Rules Language
because they do not exist in the original Rules Manipulation domain.

In other words, it is not a question of reusing an existing encoding.
It is a question of using the right existing encoding.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 10:30:19 -0600 (MDT)

I am confused by the "property" element.

   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" elements.

My interpretation of the above is that the "property" element is
defined as "rule condition" that may contain other rule conditions and
rule actions. In other words, property element is the rule itself:

	if "condition" then do "action"

This should be clarified. Either "property" is a condition or it is an
action. If it is a condition (logical expression), then why is it
called "property"? If it is both condition and action, then why it is
not called a "rule"?

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 11:11:19 -0600 (MDT)

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.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 13 Aug 2003 15:34:58 -0400

> proposed IRML is also a new domain specific language.

Yup, but the usage of XML, for example, allows to very easily and very 
quickly implement an IRML parser using exisitng XML parsers - you 
almost get it for free.

Sure, if there are other (or even more approriate) existing 
schemas/languages/etc., we need to discuss their suitability and 
decide on the most approriate one. All I'm saying is let's have a look 
at what's out there rather than always wanting to design our own new 
stuff from scratch... which I believe to understand you agree with.

> It is a question of using the right existing encoding.

Correct. Using XML was partially inspired by CPL (Call Processing 
Language), which is used for similar problems in the SIP area. We 
should learn from their experience - both positive and negative.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 14:13:34 -0600 (MDT)

> quickly implement an IRML parser using exisitng XML parsers - you

I believe this is a common misconception about XML. XML does not make
parsing much easier than any BNF-defined syntax. Just like there are
existing parsers for XML, there are existing parser-generators for
arbitrary BNFs (YACC, Spirit, etc.). Practical usefulness of either
for production interpreters and compilers is about the same.

> decide on the most approriate one. All I'm saying is let's have a
> look at what's out there rather than always wanting to design our
> own new stuff from scratch... which I believe to understand you
> agree with.

Absolutely. XML parsers exist. BNF parser-generators exist. IRML
defines an XML DTD. It could use a BNF instead. Both approaches would
reuse existing facilities to a similar degree.

> should learn from their experience - both positive and negative.

Interesting. I need to look CPL up. My comments are based, in part, on
experience with ACLs (Access Control Lists) languages and other
configuration issues for HTTP intermediaries and L2-7 switches.

Thanks,

Alex.

---

From: Andre Beck <[email-masked]>
Date: Wed, 13 Aug 2003 22:54:11 -0400

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

>    contain rule sets which have been authorized by either endpoint

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.

> Does everybody agree that support of such dynamic and/or embedded

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.

> irml-03 (due to its simplifications/limitations) allows. See examples

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

> format. IMO, no, they cannot (and so this argument should not be

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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 14 Aug 2003 09:31:35 -0600 (MDT)

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.

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 19 Aug 2003 13:30:32 -0400

Alex Rousskov wrote:

> [...]

Folks, please post if you've an opinion on this matter, since we 
really need to decide what to do with the rules language, whether to 
adopt the IRML draft and keep working on it as WG draft, or whether 
someone is willing to commit writing an alternative approach.

-Markus

---

From: Andre Beck <[email-masked]>
Date: Tue, 19 Aug 2003 17:39:43 -0400

Alex,

> 	  manipulations.

It was not an explicit design goal to make it difficult to describe 
complex manipulations, but rather this resulted from the fact that we 
didn't see a requirement/need to support complex manipulations and in 
particular didn't want to allow advanced flow control constructs such as 
loops etc.

> IRML inspiration comes, in part,

Correct. It's true that CPL targets IP telephony, but the requirements 
on CPL are surprisingly similar to those of OPES systems which is we 
decided to partly model IRML after CPL. For example, CPL is (signaling) 
protocol agnostic, is limited in power so that it can run safely in 
Internet (telephony) servers, defines rule conditions that match 
patterns against protocol header values etc.

-Andre