On Wed, 19 Feb 2003, The Purple Streak, Hilarie Orman wrote:
If you are going to allow the callout processor to have that much
control, then it should be a fully general engine and be able to
select the transport protocol, port numbers, application protocol,
etc.
Yes, the scope of the allowed callout server modifications is not
obvious:
- Limit to application message content/payload only?
but modifying content often requires modifying headers!
but content is sometimes passed in the headers!
but e-mail applications require modifying destination
addresses!
- Limit to application message (headers+payload) only?
but examples demonstrate that it is often possible
to modify the destination address and even the
protocol by modifying the message headers and
tricking OPES processor into modifying connection-level
properties; if tricks are possible we should make
them explicit!
- Limit to any changes within the same application protocol?
but I want to convert FTP to HTTP!
- Limit nothing?
but can we address privacy/security concerns if there are
no limits to what OPES can do?
Heck, it should be able to open the connections itself.
I do not think we can technically prevent/prohibit that.
Ideally, our goal should be NOT to prohibit all "bad" actions we can
think of, but design the protocol that makes privacy/security
violations detectable and traceable. We cannot control real-world
implementations; they will violate our MUSTs if our MUSTs are too
restrictive (HTTP is a good example). What we might be able to do is
to enable data consumers and data producers to optionally detect and
attribute violations of their preferences.
For example: the client does not care whether a callout server opened
a connection to doubleckick.com while processing an HTTP transaction.
The client only cares that doubleckick.com does not insert an X-rated
ad into the response.
I'd presented this concept at one of the pre-WG meetings, as an
additional work item that might go onto a charter someday, but there
was no interest. It's still a fine idea, but not for this WG.
It seems within current WG scope though. Content adaptation may
include "redirecting" content to a better "adapter".
The very focused approach of in-the-flow content adaptation that we
have now is a good one, and it reflects current practice and
engineering principles that are known to work very efficiently.
True. That is why I originally asked whether there is consensus on
this issue. If others are convinced by your arguments, I will adjust
the protocol draft accordingly.
... The OPES rules can be used to change the source and destination,
and the OPES box is the most efficient place to accomplish that
function.
That's a very good point! However, I am not sure the current drafts
allow what you want. draft-ietf-opes-architecture-04.txt says "OPES
rules: these specify when and how to execute OPES services." This
does not seem to include any modifications.
draft-beck-opes-irml-02.txt does not seem to have any rules that can
modify anything. The rules in that draft are only for invoking an
appropriate OPES service.
So, it looks like there is a second, related question to be asked. Do
we want OPES rules to be able to modify something? For example, should
OPES rules be able to modify destination of an application message?
If we allow modification-by-rules but not by callout servers, how can
an OPES system implement the following modifications?
- if HTTP request contains an XSS (cross-site script),
encode XSS to be HTML-safe, and change the destination
URL to example.com/explain/XSS.
- if incoming e-mail contains a virus, delete the
virus and redirect the e-mail to staging(_at_)area(_dot_)com;
send a notification to the recipient
As you can see, the above examples make destination modification
dependent on content filtering/modification done by the callout
server. Can/should OPES support the above?
Thank you,
Alex.