While sharing some of your free-floating fear that careless email
software zealots will latch onto Nathaniel's note as the justification
for implementing assorted Bad Things, I think that we must have the
opportunity to consider the kinds of issues that Nathaniel is
raising and I think the current version of his note raises its
points rather well.
He gives no specs, so a software type will have trouble claiming that
it is any sort of standard. He cites related work-in-progress. he
gives some alternatives. All of this sounds pretty reasonable, to me.
The RFC publishing mechanism will give these thoughts a broader base
of exposure than simple online discussion.
Concerning the question of content translations, I'm increasingly
believing that we need to model such things differently than has been
done in the past. We keep calling such things "MTA" functions. I
believe, instead, that they are UA functions. In particular, they
are UA functions for the recipient. (If they were for the sender, then
the sender/originator would have encoded the objects in the alternative
form. This is part of the reason that having the sender prohibit
translation has always seems a bit strange, to me.)
Gateway's pose a different problem, since they move the message between
two, fundamentally different email environments. But Application gateways
always violate the architectural rules, so we shouldn't let that
distract us, too much.
Within a homogeneous email service, the need to translate only arises
when the recipient is unable to process a particular data type. Hence,
it is knowledge of the recipient that should/does dictate when and
whether email software transforms the content. The fact that such
software is running on a different processor than is used by the
interactive recipient does not make it any less an agent of that