RE: SMTP Use Cases
2004-10-22 20:52:17
Jfc,
Since I cannot understand your objections, despite multiple
serious attempts to do so, my suggestion would be for you to forward
your new-charter-makes-no-sense objections to IESG. If IESG
understands and agrees with your position, they might be able to
explain it in a way that I can comprehend in order to help with fixing
the charter. If not, we would not have to come back to this until the
next charter revision.
Alex.
On Sat, 23 Oct 2004, jfcm wrote:
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.
|
|