Dave,
1. What is the motivation for the ordering rules in section 4? It
seems to me that there may be different business arrangements which
lead to different choices of which rule module owner takes
precedence. For example, ad insertion on behalf of access providers,
ad insertion on behalf of content providers and ad removal on
behalf of clients all conflict and the resolution depends on local
context like funding models, not on a globally fixed order.
I basically agree with you that the order might depend on business
arrangements - we also discussed this a lot when writing the draft.
Imagine, for example, that a content provider defines a rule module to
insert ads into its pages and that a client defines a rule module to
remove all ads from all pages. One might argue, now, that the execution
order of the rules depends on the business arrangements (basically, who
pays more - the content provider or the client :). However, even if the
ad insertion for the content provider is executed last and, therefore,
ads are inserted despite the client rule, the client could still remove
the ads on its local machine by using a local tool. In this case,
there's no motivation for the client to use the edge service provided by
its service provider. Basically, the client always has "the last word",
because it could run all the services also on its local machine, without
giving the content provider any chance to have impact. Similar for
content provider/service provider relationship. This, in some sense, was
the motivation for the ordering we outlined in section 4 - following the
"natural" message flow. Certainly an issue to discuss...
I can also imagine cases where interleaving the rules between
different (cooperating) module owners might be useful but perhaps
the complexity rules this out.
Interleaving rules might be used for optimization, but our feeling is
that the benefits we could get out of it would not justify the added
complexity.
[BTW there may be a trivial typo here, I suspect the request points
are mis-numbered in either para2 or para4 of this section.].
You're right, the error is in para4. We'll fix that in the next version.
Thanks!
2. A possible extension to the property naming rules (section 3.5.2)
would be to allow inter-proxylet communication by allowing one
proxylet to add property annotations to the message which can
trigger later proxylets. For example, I may have a proxylet which
checks the P3P policy of the site to generate an
"acceptable-privacy-policy" annotation which in turn might
trigger later proxylets. This could be achieved by lifting the
restriction that property names be limited to actual protocol
headers (plus the six extension properties).
Agreed. We probably should relax the restriction and should allow
additional property names. This can probably be included without major
changes to the draft.
3. For the property value matching would it be appropriate to add an
additional attribute to the "property" element to control
case-sensitivity of the matching?
Hm, I'd rather prefer to stay case-insensitive per default. Just for
simplicity.
4. Is there a proposed namespace URI for this element set?
No, not yet, but his should probably be done later.
-Markus