In a discussion in ietf-smtp I wrote:
My preference for headers would be to adopt
mneumonic as the text-type of free-text parts of headers [even though this
might not be 100% backward compatible the problems are few and manageable].
I've always felt uneasy about the name "mnemonic" and now I can see why.
It's too damned hard to spell. Anyway I've changed my mind about there being
any compatibility problem.
The solution is this.
1. If there is no Content-type header (i.e. an old-style message) then the
implied text type of free-text parts of headers is USASCII, as now.
2. If there is a Content-type header in the message then the implied text
type of free-text parts of headers is MNEMONIC.
3. If any agent decides to explicitly add the implied "Content-type: usascii"
header to a message that previously had no Content-type header then it must
change all the free-text parts of headers by changing & to && and fixing any
resulting line-length problem.
4. Because the message may wander back into realms where Content-type is not
understood, the rules for determining what can go in free-text parts of headers
without being quoted are the rfc-822 rules. E.g. &"a is three characters for
the purposes of this determination not a single a-diaresis.