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.
Isn't it MUCH simpler to just extend the Type and Encoding
mechanism that is already there in RFC-XXXX for message bodies
to the text-only header fields Subject, Comments, and
Content-Description? (This can be done by two new headers,
Text-Header-Field-Type and Text-Header-Field-Transfer-Encoding,
as Peter Svanberg proposed already in his first message to this
list.) A further advantage is that this allows e.g. Swedes in
Sweden to communicate with other Swedes working e.g. in the US
in Swedish with no artificial restrictions.
The need for national characters in address phrases is not as
urgent as in the case of the Subject header and can wait for a
future general solution to the header extension problem.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>