``ctext'' would be OK, except that comments (where ctext is used) may be
used in MTA-generated Received: headers. (An MTA that I wrote years ago
puts comments in its Received: lines.) Does this mean that all MTAs
must check whether comments are to be encoded before printing comments
in the Received: header, and encode the comment text as required?
One of us is confused here. As far as I know, the only interaction an
MTA has with Received headers is to add them--it shouldn't need to
parse, print,... them at all. And, since the ASCII subset of mnemonic
is ASCII, there would not seem to be a need for a flag-day conversion.
That said, I'd rather make a header-by-header rule, with designation of
mnemonic-able fields specifically by location and function, not as an
artifact of the notation of RFC-822, which was certainly not written
with this problem in mind.
I'm quite opposed to any version of
this that requires changing all the MTAs everywhere.
If that were really required, it would be equivalent to the "declare
broken" scenarios. And, as soon as one is willing to do that, lots of
this becomes easier. But completely unacceptable.
I'm still rather
opposed to a version of this that edits the RFC-822 rules in ways that
will be open to mis-interpretation, or that will be so complex as to
encourage lazy implementation.
Concur. I think these are real concerns with any "non-ASCII in the
headers" system.
--john