Backwards compatible

New Message Reply About this list Date view Thread view Subject view Author view

From: Erland Sommarskog (sommar-usefor@algonet.se)
Date: Sat Aug 10 2002 - 16:29:29 CDT


=?ISO-8859-1?Q?Claus_F=E4rber?= (list-ietf-wg-apps-usefor@faerber.muc.de) writes:
> Erland Sommarskog <sommar-usefor@algonet.se> schrieb/wrote:
> > Fully backwards-compatible? Only if your name reall is
> > =?ISO-8859-1?Q?Claus_F=E4rber?=?
>
> 1. Has your MUA crashed?
> 2. Has your MTA (or any intermediate MTA) corrputed, bounced or dropped the message?
> 3. Has my mail be routed to the wrong recipient?
>
> With raw UTF-8, 1 and 2 might have happened; if it was used for email
> addresses (very similar to Newsgroup names, BTW), probably 3 might have
> happened, too.
>
> Backwards compatible does not mean that leagacy user agents are able to
> display newsgroup names correctly (they can't with UTF-8 either).
> Backwards compatible does mean that they can:
> . access the newsgroup,
> . create new postings, and
> . create followups
> without crashing or creating corrupted messages.

A lie does not become more true because it is repeated all over again.

Some people like to thrown mud on Microsoft for dishonest marketing.
It happens to be the case that my area of speciality is MS SQL Server.
The SQL Server developers usually bend over backwards to maintain
compability between different versions of SQL Server, adding SET
options, compabtility levels and other means. Nevertheless, there
are situations where they consciously break existing software, for
whatever reason (usually a good one!) Of course, in a RDBMS engine
with a cost-based optimizer, it is about inevitable to break some
existing code which with the a optimizer gets a query plan which
results in an execution time which is unacceptable.

But: Microsoft never tries to claim that everything is backwards
compatible.

That is indifference to the RFC2047 maniacs that touts RFC2047 as
fully backwards compatible with existing software. It doesn't
matter how many times you repeat that marketing drivel of a lie:
it will never become true.

Before RFC2047, reading mail with 8-bit characters with mailx never
was a problems. Most of the time the mail got through untouched.
Sometimes the high bit was stripped, and sometimes the sender had
use CP850 or some MAC charset. But that was easier to read than the
encodings introduced by RFC2047.

Your blathering about crashing software shows that you have not under-
stood what mail and news is good for: mail and news are good for
communication between humans. Encodings like QP or RCC2047 that
makes the message more difficult to read, hampers that communications.
Encodings like Base-64 or Punycode which completely hides the
message destroys communication.

That is just as much breaking existing software as crashing programs.

When MIME was introduced as a way to handle 8-bit characters, one
had to the choice of breaking some transport software, or break about
every client, and one chose the latter. I'm not all convinced that it
was a wise decision; Had they decided to break transport, our usage
of UTF-8 would be completely uncontroversial today. But they important
part is: they decided to break something.

No matter how many times you repeat the lie that it was backwards
compatible.

--
Erland Sommarskog, Stockholm, sommar@algonet.se


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.