The move to an 8-bit character set is very good for us -- we don't
have to have double meanings for some code elements in the 7-bit code
anymore. (Today "{" is sometimes a left brace, sometimes a lowercase
"a" with dots above.)
So, how do you then explain to the users that as a *consequence* of
this good improvement, they will have to live with the deterioration
that they can't write decent letters anymore? I can't.
At the risk of starting another firestorm, one solution to this for
users in Sweden (or elsewhere with similar problems, e.g., JIS 2022
isn't ASCII either) might be to implement and disseminate an 8bit
transport plan with negotiation (or, for that matter, a 7bit transport
plan with negotiation). Such a negotiated model might very well take a
more relaxed attitude toward non-ASCII characters in headers than is
feasible with the 821/XXXX combination, since the negotiation itself
would force the use of gateways that would presumably be able to do
something acceptable.
In a way, that suggestion is for a return to the enclave model, although
with a different tone. Within Sweden (? Nordunet? Western Europe?)
you use a negotiation extension to SMTP and transport, e.g., ISO8859-1
either "native" and over an 8bit connection or encoded in some
appropriate way (presumably mnemonic) over a 7bit connection. You use
the GL subset of that character set in mailbox fields in headers and
other information to which RFC-XXXX, RFC-822, or the DNS assign strict
syntax, but use the full set as needed in Subjects, address phrases, and
comments. While I would prefer to avoid it for convenience in
interoperability, substituting "646 NLV Sweden" for "8859-1" does not
change this picture significantly. When a host is encountered that won't
accept the negotiation, you convert in some plausible way.
What is important about this is that we have always, of necessity, been
willing to accept types of behavior from gateways that we would never
want to approve for normal internet operation. I don't like "real-" for
RFC-XXXX, and I loathe bit-stripping as a solution to anything, but I
wouldn't be terribly upset (or surprised) to see something emerge from a
gateway that looked like:
Subject: garble{}|
X-Gateway-Warning: Subject field was in ISO_8859-1 and was
bit-stripped
X-Original-Subject-Mnemonic-Conversion: ....
Personally, I find two things interesting about this. The first is that
it is the transport-level negotiation that makes the orderly transition
possible. Whether the transport itself is 7 or 8 bits is mostly
irrelevant. And the second is that no amount of standards-writing can
prohibit the gateway behavior I've posited without making existing
conforming implementations broken: if we think of these things as
gateways, they have the authority to do this, and 822 explicitly permits
locally-defined X- headers of this nature.
Please, if there is to be further discussion on this, let's do it on the
other list, not start a rash of cross-postings.
john