RE: SMTP Use Cases
I know that you do not understand. From the very beginning your vision of
an OPES is the vision of a front-end middlebox with an OCP link to
a remote server. You just explained this: the interest of that middlebox
is that it can easily be adapted to any protocol. This vision is of real
interest to patch protocols and to implement transitions. But it permits
much more if used in a proper architectural way.
Now, you are able to understand that if what you work on is to be used in
an architectural dead-end - whatever the cosmetic in describing it - you
will waste your time and efforts. So the question is of importance to you.
Right now IETF is trying to understand if they are in such an architectural
dead-end or not. This is plainly documented in the IAB RFC 3869 published
a few weeks ago. This is plainly documented in IETF RFCs on IETF situation.
This is plainly documented in the IETF debates initiated by Harald
Alvestrand. This was plainly documented through ICANN early warning problem
two years ago. This was plainly documented in the new economy quick
blundering. This is plainly documented in the WSIS resolutions calling on
Koffi Annan's experts. Always in the same way: a partial list of problems
without ever considering the deliveries, the call for help to people they
do not want (money and Gov), the lack of understanding of what would
trigger a positive response (that deliveries would match real needs).
The IAB documents the internet problems in RFC 3869: the lack of vision, of
motivation and of funding for R&D. It also gives the reasons why: through
what is missing in their document (they do not even allude to
mutilingualism, to user or market demand). The real internet problem is an
host centric architecture which does not respond the real world needs. The
real needs and interest are usage centric. The IAB is clear about it: it
identifies global access to information (host application) as THE internet
service. This is a 1971 need (first commercial ISP bill in Feb. 1971).
There is a very long that network marketers and service developpers know
this is far more complex. Users also want services and full control. But
how IETF will know it without market study? The IETF is producing Ford-T
cars and meets some difficulties about organizing, funding, recruiting. At
the present time it tries to understand how to best organize, get funding,
motivate its members. Sometimes they will consider producing Mustang cars.
This is why there is a drop in R&D and funding, why IETF audience and money
drop, why Stuart Lynn had to call on Govs for ICANN, why IAB now calls on
Govs for R&D, why WSIS calls on Govs for an Internet governance review
(please read RFC on IETF problems). For two centuries the world has used
Gov control/monopolies. The web has made believe that we could use
Internet's free datagram du to the lack of State protected economical
model. This has initially worked because the USG warranted it, but its
interest is not in warranting and funding the world's system (the WSIS has
two problems: world system's governance and funding).
The loss of interest comes from the fact that no one sees big return from
investing in the internet architecture. Only bandwidth value added people
who see some saving while their revenues and margins drop. This is the
reason of the new economy failure. This is the reason why no one will fund
you for developing OCP. This is the reason why the WG loses momentum while
it works on a real key issue. The searchers and investors question is
really simple "what for?".
Some have understood the solution. Many have understood how to look for it
(please reread RFC 2775).
Once again, what is concerned is not OCP, but where and how to use it.
I am not interested in documenting this to IESG. We made the diagnosis
nearly 20 years ago from our real life commercial success. We documented
the architectural reasons of such a success. At the time we were the world
leader (Tymnet) when we were poorly purchased. We quitted and disbanded. I
can tell you exactly how and when our world lost 30 years. And the 1987
evening when we evaluated that there was no interest in wasting time to
document the young IETF because real world and academic life, vision and
budgets are so apart. The interest is that these 20 years permitted to
validate and to deep our vision (through some huge success as M$ which
partly used it, or some evolution such as the drop in bandwidth cost and
ubiquity, but mostly in observing the problems met by OSI and then by the
Internet - and the way they try to patch them, as with OPES). This is lame.
Either you understand it and the opportunity is huge, or you do not want to
accept it and you waste your time and energy.
Now, with the currently coming appliances hardware and FCC/Govs growing
communication attitude, the future internet is at hand. It may not come
from IETF nor from GPL etc. It may come from an US start-up, from a Major's
understanding of the real musical market and economical model, it can come
from an European workshop, it can come from a Chinese manufacturers
consensus, or from an Indian engineers venture. Probably after a major
collapse over a DoS, a DNS failure, a spam growth, a brilliant physing, or
a real life catastrophe as Richard Clarke foresaw it, a big digital
terrorist attack or a Govs fed-up at the ASCII internet US nexus (please
note that I invent nothing. All this is fully documented in RFCs and in USG
documents). All this will lead to competition in solutions, hence to a
balkanization of the Internet (cf. Paul Vixie on the IETF general mailing
list over IPv9 Chinese testing). This is why the only solution IMHO is to
document Govs about the real life threats, imply them in solutions and
demonstrate through real working system solutions.
In that future Internet, a distributed ubiquity of smart stand alone smart
multi services $ 100 nodes over a continuity of various types of bandwidths
by coopeting large concentrated operators (look at FCC policy) at a global
$ 15 cost per month, the protocol will probably progressively switch from
IP to something better (but compatibility will have to be maintained for a
while) managed by a secure and versatile simple inter-user network
operating system. OCP could be a good embryo of such an OS internal protocol.
At 05:52 23/10/2004, Alex Rousskov wrote:
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.
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
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....
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).
-----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...