Hi, MArk and Andre,
just a comment of my own. see them in line.
Regards,
cwng
* Section 3.5.1 - processing points - this seems unneccesarily
restrictive; 1|2|3|4 is based on a request/response pattern, and
even then it's very possible that more processing points will be
desireable.
Instead, why not, after identifying the protocol by a URI, identify
the protocol-scoped message as a URI as well? Then, you can
identify message-specific processing points with (drum roll) a URI.
For example;
<rule protocol="http://ietf-opes.org/protocol/rfc/2616";
message="http://ietf-opes.org/protocol/rfc/2616/Request";
processing-point="http://ietf-opes.org/protocol/rfc/2616/Request/Client";
What is the point of repeating the "http://ietf-opes.org/protocol/rfc/2616";
on all 3 attributes? Is there a use-case scenario where the rule acts on a
HTTP protocol, but the processing point is not operating on HTTP?
This doesn't really help to make the rules more compact and readable
:-), but I can see some benefit in it. Other opinions?
Having processing points named 1, 2, 3, 4 doesn't make a rule readable,
either :)
But specifying the URL to an RFC is a bit of an overkill, IMHO.
Might I suggest changing it to something like
<rule protocol="HTTP" processing-point="Client-Request">
This gives room for furture expansion if need be.
re: matches; regex is awfully expensive (and encourages people to
cut corners in parsing). Could some room for extensibility be left
here, so that other means of matching can be specified? I suppose
that regex could be the default, and other means of matching could
be specified by an attribute (there needs to be room for
expressions here anyway; it would be good to be able to do
"response.headers.age < 30", for example).
This has been proposed before. The issue here really is how much
complexity we can afford to add to a OPES rule language. It's basically
a tradeoff between the performance impact on the in-path OPES
intermediary and the goal to minimize the number of unnecessary
callouts/invocations of OPES services.
The HTTP headers are almost all text, so the use of regex matching is
justified. If there is any properties that are numeric in nature, then
arithmetic comparison might be more suitable. May I point to the I-Draft
"http://www.ietf.org/internet-drafts/draft-ng-opes-irmlqos-01.txt"; on QoS
sub-system, where arithmetic comparison is used since the qos parameters are
numeric in nature.