ietf-openproxy
[Top] [All Lists]

Re: FW: I-D ACTION:draft-beck-opes-psrl-00.txt

2000-12-01 09:59:11
Dave Reynolds wrote:

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.

Well, I think I have to disagree here. The client should always be able
to have the last word on any modifications he would like to make to the
requested page. In fact, the order we suggested in our draft merely
reflects the order of the traditional approach (no service-enabled
caching proxy involved): A content provider inserts ads at the origin
server and the client uses a program like WebWasher on his local machine
to remove the ads. The proxylet approach simply moves these two services
to a single point in the middle, namely the caching proxy, but the order
in which the different parties can modify messages at this point should
be the same as in the traditional approach.

I can also imagine cases where interleaving the rules between different
(cooperating) module owners might be useful but perhaps the complexity rules
this out.

Can you give an example where this would make sense?

[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 are right. For processing points 1 and 2 the rule module order
should be Client/Access Provider/Content Provider and for processing
points 3 and 4 the order should be Content Provider/Access
Provider/Client.

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

I agree. We should not restrict properties to actual protocol headers,
but instead allow both protocol and user-defined headers plus the six
extension headers (as long as there is no conflict). Since proxylets may
also add (or delete) headers to a message (for instance at point 1),
this should also allow for some sort of inter-proxylet communication. 

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?

That's a good idea.

4. Is there a proposed namespace URI for this element set?

Not yet, but there probably will be some time in the future.

-Andre