Keith Moore wrote:
the use of an envelope container would certainly "fix" the
problem that we have now with feature blackholes.
Surely you consider these blackholes as "real problems"?
no, I don't - because most of the (mail) transport level features I
can think of are inherently per-hop and require per-hop negotiation.
"most" is certainly the right word. If you are arguing that some services
need to be rejected if they are not understood, then that is certainly a
valid design point to consider. But as it stands, no new features can be
deployed between willing participants without upgrading all of the systems
in between those end-points, and this has to be performed for every new
extension.
which issues are the ones that warrant an overhaul of the message
format?
The collective lot of them.
Moreover, they are actually feasible as part of an overhaul.
it's not clear that the overhaul is feasible.
We already know that many of the desirable features are absolutely not
feasible in the current model, at least not without significant hammering.
On the other hand, what is it that is not feasible about a new message and
transfer service? Backwards compatibility with legacy systems and
mailboxes is a migratory issue, and that is absolutely feasible.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/