Keith Moore wrote:
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.
This particular discussion is in relation to envelope and protocol
extensions, which has nothing to do with the *current* message format. The
point of this particular discussion is that a message format which
provided envelope data as a separate blob would allow the envelope
extensions to survive blackhole hops.
DSNs with NOTIFY=SUCCESS are an obvious example. The only thing I care
about is that delivery succeeds, meaning that this is a negotation between
the originator and the delivery server. The submission server and any
relays in between are completely irrelevant, yet due to the current
envelope-exchange design, they dictate the success of that feature.
You are correct in that this feature and others which need to survive
blackhole hops do not require a new message format by themselves. After
all, these are envelope extensions, which do not *currently* use the
message format directly.
However, another critical aspect of what I am talking about is that the
transer headers be separated from the message headers and moved into the
envelope blob. That *does* require a new message format. Not only is the
separation of transfer and message headers needed for basic features (such
as header encryption) but the recombination of transfer headers with
envelope data is also necessary for other basic features (transfer header
survivability). So no, I don't think you can add new features without also
modifying the message format.
which user-visible features need this kind of change?
We need a new message format if we want to allow UTF-8 directly in the
message headers. You will probably argue that a UI facade will work just
as well for this, but you will be wrong.
We need a new message format if we want to be able to encrypt the full
message (message headers and body, rather than just the body), since the
commingling of transfer and message headers prevents that now.
It would also be really nice if we could simply the header rules as part
of this effort. The multitude of header rules currently defined are
obtuse, wildly varied, and prone to significant misinterpretation. I did a
survey recently of clients that support "Group Names: user1, user2;" and
only 2 out of 10 clients properly handled them. Your own client didn't
even generate valid References headers until I pointed it out. This
doesn't even take into consideration the multitude of codecs and encoding
forms that people have to deploy. [2]822 is popping at the seams from the
20 lbs of crap getting jammed into this 10 lb sack.
Plenty of others. Flowing and quoting in body parts would be nice, and
would be easier with a new message format.
As single items, none of those warrant a new message format. Collectively
(especially with other benefits that become viable with a new format, as
with the envelope modifications above), they do warrant it.
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.
If the features were desirable and it simplified implementation, people
would use it. It wouldn't happen overnight, we can agree on that.
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.
You will also note that Brooks provides advice on avoiding it.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/