Let review the starting points:
1. the demand is by/for the users => not by the RFCs.
2. the solution is to be network technology independent => anyone coming
with a "tier&tier" solution for e-mail, SMS/MMS, VoIP, peer2peer, no-Spam,
Web etc. will ruin any effort to devise anything smart but dedicated..
3. The current architectures (SMPT and X.400) failed => let start
understanding why and what are the alternatives.
The root of the e-mail concept is Louis Pouzin, Glenda Schroeder and Pat
Crismans PSN 49, end 1964. It was developped into the mail program by Tom
Van Vleck and Noël Morris. Louis was a key contributor to TCP/IP, etc.
Louis keeps thinking by postal comparison. This permits him to reach good,
simple, stable solutions in other architectural aspects (DNS, IDNA,
Governance, etc.) This helps people to quickly understand him (he really
influenced the recent WSIS). The whole e-mail system is built on that image.
We often oppose because I think this image does not work in our real
e-world. which is far more complex and subject to pollution than the
regular mail/world.
Question: at the PSN 49 root level of the problem, was it an alternative to
the postal model? Could we study it?
All of us (Tom Van Vleck, the first one) used another model and we all know
it works the same or better. This is signaling.
I am a seaman. When a General sends a Courier on a horse, and Admiral sends
a "Captains repair on board" signal. History is made of Couriers failures,
deaths, etc. no sea battle was ever lost because of a spaming Captain's barge.
IMHO the problem is that SMTP is too complex and spans too many layers.
KISS (keep the Internet sure and secure). To do that we are to think to a
"wider" (hence dumber) rather than to a "smarter" solution. One layer at a
time.
I am ready to bet a lot on the following:
1. this mailing list will only succeed if proposing an accepted rock solid
downgraded SMTP with dumb bridges with other technologies - including
current SMTP.
2. if it permits to plug an unlimited set of value added services to
support interapplication (extended) services
3. as such it will impact on TCP/IP itself because the is the (possibly
saturated) largest current TCP/IP user application.
jfc