Simple: Today there is no character limitations for the subject
line. Tomorrow there will be (with RFC-XXXX).
Wrong. 8 bit characters are presently illegal on the Subject: line, or any
other header. See RFC822. It may work now, but only because your software does
not enforce existing standards. Software does exist that enforces standards,
and your mail does not interoperate with it.
You have misunderstood Peter here. Today there are no character
limitation for _writing Swedish_ on the Subject line when
communicating with other Swedes, since the Swedish version of
7-bit ISO 646 is used.
The users will naturally want to continue to use our special
characters, as they allways have. But suddently -- as those characters
now will be 8-bit -- we have to stop them from doing that on the
subject line. This is a severe decrease in functionality.
RFC-XXXX changes nothing in this regard. It simply restates what is presently
stated in RFC822, and explicitly specifies the character set that was not
completely specified in RFC822.
RFC-XXXX explicitly specifies that US-ASCII is used in headers,
and therefore, in its present shape, will make it _impossible_
to write the Subject line in Swedish. (Of course RFC-XXXX will
make it easier and safer to write in Swedish in the _message
body_, so the situation is paradoxical.)
There is no deteriotion. You are living in a fantasy world if you think
your present violations of RFC822 and RFC821 are not causing operability
problems. Sorry, it does cause them. We're trying to come up with a
scheme that does not.
Please explain which severe interoperability problems you are
talking about. If I by mistake would send a message written in
Swedish to an international mailing-list it doesn't matter if it
is coded by Swedish ISO 646 or by ISO 8859-1 (according to
RFC-XXXX). People not talking Swedish (or other SCandinavian
languages) can't understand it anyway. Note that your strict
interpretation of RFC821+822 would make it totally unusable in
Sweden and most other non-English speaking countries.
I note in passing that your voice was not raised in the debate about how to
accomplish all of this using mnemonic or whatever. (At least I don't recall
any
input from you -- correct me if I'm wrong.) We could have used your input
then... And consequently I have a little trouble with dealing with your input
now.
No, neither Peter Svanberg nor I have contributed to the
discussion earlier. The reasons for this are in short:
1) We didn't catch up with the discussions on the smtp/822
lists until a few days ago, partly because of the sheer
volume of messages on these lists.
2) The suggestion to leave all proposals about extended headers
out of RFC-XXXX to finish it as soon as possible (and try to
solve all header problems in some future RFC) was made only
four days ago (by Nat Borenstein).
3) Suddenly everyone seemed to agree with this suggestion. In
this new situation we could no longer trust that one of the
proposals for a general solution of the extended header
problem would be adopted. Only then did we start to think
about an interim solution for the unstructered headers
(including Subject), and we think we have found a good one.
If you want to solve these problems, offer up a proposal that addresses
the issues at hand
Our proposal is to finish RFC-XXXX now by adding the following
partial solution for the practically most important header
fields: Introduce two new headers, Text-Header-Field-Type and
Text-Header-Field-Transfer-Encoding, governing the
interpretation of the Subject, Comments and Content-Description
headers in exactly the same way as Content-Type and
Content-Transfer-Encoding govern the interpretation of the
message body. Make the problem of using non-US-ASCII characters
in _structured headers_, especially address phrases, as well as
other header problems the subject of a future RFC.
For my part I'm now finished listening to your
complaints when you have nothing positive to offer.
But we have. Essentially the proposal above was included
already in Peter Svanberg's first message (Date: Thu, 26 Sep 91
23:48:35 +0200).
And frankly, your position
that this ignores a particularly European piece of the problem is offensive --
the folks here in the US have these problems too and want to solve them as
much
as you do.
All characters needed for writing English are already in
US-ASCII. Most other languages need letters that aren't
included in US-ASCII. If the strict interpretation will be
enforced in RFC-XXXX that only US-ASCII can be used in the
Subject header, the result is that Subjects can be written in
English but not in many other languages. That problem will not
be restricted to Europe, but it has a good chance of being
ignored in the US (which this whole discussion seems to prove).
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>