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.
but in most cases this is inherent in the nature of the feature, and
has nothing whatsoever to do with the message format. if you could
add the feature at all, you could do so without changing the message
format and without the disruption that would cause.
which issues are the ones that warrant an overhaul of the message
format?
The collective lot of them.
I didn't name a single feature that would require any change to the
message format, and I haven't seen any other suggestions for features
that need a change to the message format. so I ask again, which
user-visible features need this kind of change?
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.
no we don't.
On the other hand, what is it that is not feasible about a new message and
transfer service?
1. getting users to buy into it when it is disruptive and it doesn't
provide them with any immediate benefit.
2. getting past second-system effect from the large number of people who
will see it as an opportunity to fix things (many of which aren't broken)
and to introduce new problems in the process.
Keith