On Thursday, March 7, 2002, at 07:24 PM, Ng Chan Wah wrote:
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?
Attributes other than protocol can be defined as relative to the
protocol URI.
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.
How do you manage that name space? Will an IANA registry be set up? URIs
give you segmentation, extensibility and manageability for free.
The HTTP headers are almost all text, so the use of regex matching is
justified.
That doesn't follow; XML is also textual, but XPath, a format-specific
expression language, is more well-suited than regex because it
understands the structure of XML. It's possible to write a regex that
gives equivalent functionality, but it puts all of the burden of doing
so on the person writing the rule. IMO, this is dangerous.
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.
Interesting; thanks for the reference.