Layers are tools for design, as well as analysis. Collapsing layers
requires very, very careful attention to the implications.
When you are dealling with a twenty year old protocol you are likely
to find that the reason it is failing is that the original layering
design was inappropriate for current uses.
In this case, one of the implications is to kill reall
store-and-forward and real mobility, as has been described quite a few
time.
This has been disproved repeatedly. There is no functionality loss
whatsoever. A tiny, insigificant proportion of users will have
to bring their mail configurations into line with the overwhelming
standard practice.
This group is chartered to make a proposal. It is not chartered to
consider whether the proposal is or is not a good idea.
In the world of Internet protocols, options are often very expensive,
adding quite a bit of implementation and operations complexity,
increasing the likelihood of bugs, and often adding small practical
value, unless used primarily as a means of evolution, rather than
long-term variation.
Options that affect interoperability are a bad idea. That is not
what is being discussed here.
One of the real secrets to Internet protocol success has been the
definition of tight, useful protocols with common, core facilities
that do not require options. If you want to see an example of the
alternative, take a look at the OSI protocols.
The real secret of the internet was it got lucky. If the Web had not
come along when it did and email had remained the killer app for another
few years the US federal government would have deployed OSI regardless
of technical merit.
The fact that a particular set of ideas was sufficient in 1992 does
not mean that it continues to be sufficient in 2004. The patterns of
Internet usage and the trust relationships are far more complex. If
there was absolutely nothing wrong with the original design as you
appear to be insisting then there would be no spam and no need for
this group.
On the average, artificial intelligence algorithms do not
work well at
the core of a high volume networking service like email.
Alas, that's
the technical base that would be required to implement the sort of
description-based service you (and others) are suggesting.
As I said, this approach does not work for high-volume, transfer
protocols.
This is false, AI scoring techniques have been at the heart of
the card payments industry transaction systems for decades.
If you have an alternative proposal, make it to ASRG. If you have
no alternative proposal your comments are not relevant. We are
all aware of the points you keep raising, we just do not agree
with them.
If as you claim the corectness of the original design is proved by
its sucess, then the fact that spam outnumbers legitimate email 3 to 1
means that by your own argument change is essential.
Phill