Below is a quote from DRAFT Mime headers 0.4
by Charles Lindsey <chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>, which
is being developed by the USEFOR IETF group:
6.x.5.3 Message/news obsoleted
The Content-Type "message/news", as previously registered with
IANA, is hereby obsoleted and should be withdrawn. The reason
is that, according to RFC-2045, it is expressly forbidden for
any "message" type to use a transfer-encoding other than
"7bit", "8bit" or "binary", thus preventing a news article
which makes full use of UTF-8 characters in its headers, or
which uses (as it SHOULD) "8bit" as its own transfer-encoding,
from being passed through a 7bit transport medium (recall that
it is not permitted by this document for the transfer-encoding
of a news article to be changed).
Well, I certainly agree with the outcome -- message/news should never have been
registered. The intent was always for message/rfc822 to cover News, and it does
so just fine. Creating additional composite types is a serious business owing
to the need to add support in a large number of contexts. It should never have
been allowed, and would not be today, but back in those days we didn't have an
appropriately tuned type registration mechanism in place.
But the reasons given here are specious. For one thing, the use of UTF-8 in
headers is an orthogonal issue to this one. We've had a strong consensus for
years that this is a place we want to get to eventually, but we have to finish
a bunch of other stuff, most notably DRUMS, first. Only then will we have the
basis on which a design team can write a specification for UTF-8 headers that
actually works.
And as for the CTE issue, it was decided long ago that CTEs cannot be nested.
And this is why the restrictions on message exist, and will apply equally to
any attempt to register any other composite type, regardless of what top-level
type you put it under. And this is why CTEs on inner parts can and will be
changed by software as messages, be they from News or whereever, move from News
to mail or vica versa.
Millions of lines of code have been written in good faith based on this choice.
We don't go against choices we made in the past that have led to widespread
good faith implementations. As such, any document that says I cannot do what
I've previously been specifically told I have to do to messages because they
happened to originate in News, doesn't stand much of a chance of being
standardized.
How does this conclusion influence e-mail standards?
It isn't a conclusion, it is simply a paragraph in an Internet Draft. And one
which will receive strong objection if by some chance it makes it to IETF last
call.
Ned