ietf-openproxy
[Top] [All Lists]

RE: SMTP Use Cases

2004-10-22 18:58:30

I think we will never get Alex understand the problem. What he sees is an action on a message. Not the scope of that action. It is true that whatever the protocol a message (in one or several datagrams) is massaged like in any middlebox. The difference is thatit is not massage at the middlebox but at a distant server. The important action is the massaging (filtering, protocol to the server, update). Martin in the SMTP case see the things the same way.

I see the same thing, but in an architectural way. Either the idea is to stop having too many middleboxes and to keep the network intelligence at the edge, so the architectural end to end and dumb network/smart hosts can be protected. This is the IAB idea and we have to be very tought on the OPES definition as an "edge" service. Or we do not mind IAB, we address the need and we extend RFC 3234 with networked middleboxes (I recall that middleboxes can be virtual, so the filter of an OPES is a midlebox).

1. if we talk about OPES. there may be knowledge of the OPES action by the ends, but no dialog with both. In the case of an a-synchornous service multicast such as SMTP the only end to be informed is the nearest end. Also, by no means OPES can be on an MTA, only on UAs because the MTA by nature is not at the edge of the network. OPES can only be on the edge traffic. Not on the stored nor on inner network traffic.

2. if we talk of remote server supported middleboxes, we are totally free to do what we want. But these are no more OPES but ONES. This means Open Network Extended Services. We are then introducing intelligence within the network, what I _fully_ support, but which is far, far more complex to document. May I remind you RFC 2775: there is no objection to change everything in the network vision (and I DO think this necessary and urgent if we want to address the IAB concerns on Internet future) but this is another issue and I doubt this WG has the right people to engage a total rebuild of the Internet.

I can only repeat that the proposed examples are fine as services, not as OPES they are not. Also, that the new charter does not make any technical sense to me. Because OPES are at users plug and the work you want them to provide is at the power plant.

Or we decide that the architecture is end-to-mailserver + mailserver-to-end. The mail server is then an edge. But who is in control? Not the receiving end but the ISP mailserver manager. And we fall back in the situation described by Markus....
jfc


At 01:49 23/10/2004, Hilarie Orman wrote:



HTTP never had a store-and-forward protocol architecture, so all
the proxy stuff got tacked on.  SMTP dealt with it from the beginning
and already addressed the problems of MITM, tracing, etc.  It is,
in fact, the strawman reference model for much of our OPES discussion.

There's an odd recursive aspect to applying OPES to SMTP, and I think
it is important to clarify why SMTP will benefit from OPES, sort of
like asking why one's grandparents should buy their clothes at
Banana Republic (whatever).

Hilarie


-----Snippet of Original Message-----
From: Alex Rousskov
Sent: Friday, October 22, 2004 11:13 AM
Subject: Re: SMTP Use Cases

I may be repeating myself, but I still do not know how store-and-forward
SMTP is different from whatever-you-want-to-call-it HTTP in the context of
adapting content. Thus, for me, SMTP adaptation can be within OPES scope
if HTTP adaptation is. Using your example above, exactly the same argument
can be made for HTTP: why not forward the messages to an HTTP proxy where
the "service enhancements" can be applied...

Alex.


<Prev in Thread] Current Thread [Next in Thread>