X.400 (88) breaks X.400 (84); MIME doesn't break old mail

Why X.400(88) breaks X.400(84)

When X.400/84 was written, the writers probably thought that they could add fields to the protocol at will later.

This didn't come true, for several reasons, some of which are more obvious than others.

Because of all these problems, X.400(88) wasn't simply an addition of new elements to X.400(84). Instead, X.400(88) invented several new mechanisms: In addition, a new "bag" was added to the side of the O/R name addressing structure, and filled with some components like Teletex-string format address components and directory names.

To add insult to injury, the ISO/ITU comittee declined to give any advice on how to handle interworking between the "old" systems using X.400/84 and the "new" systems. This has been rectified in the appendixes of some newer recommendations, but is still limited approximately to saying that you can tunnel X.400/88 messages through an X.400/84 infrastructure using the content type P22; there is still no real advice on interworking between an X.400/88 UA and an X.400/84 UA. This probably reflected the view that "most people" would convert rapidly to the new formats; this didn't happen; even today, I believe that more X.400 E-mail is carried using X.400/84 compatible formats than is carried using the X.400/88 extension.

An IETF document, RFC 1328, specifies one way to do downgrading; extensions to this for handling stuff in a MIME-compliant way were defined in RFC 1496 (HARPOON). I don't know if there exists any large body of deployment for this stuff.

MIME and RFC-822 mail

MIME did not change the transport mechanism for Internet E-mail.
It did introduce a means of tagging messages with their transport requirements (the "8bit" and "binary" content-transfer-encodings), but didn't even require the 7-bit-only definition of SMTP to change.

This means that a MIME message can be delivered to any RFC-822 compliant user agent; the text-like property of Internet mail means that it can be viewed to some degree when it gets there, and stored in a file without information loss.

This interoperability comes at a price, however; the encoding mechanism for MIME mail is rather ugly compared to other approaches like "just send 8bit and let the recipient beware": A message like this, using some ISO 8859-1 characters:

Subject: Håreks damebesøk

Håper du kommer snart
would be turned into something like this:
Subject: =?iso-8859-1?Q?H=E5reks_damebes=F8k?=
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

H=E5per du kommer snart
This notation is also possible, but rarely used with messages that contain "mostly ASCII-like" text; it is more sensible to use with binary file transfer and non-ASCII alphabets like Cyrillic or Kanji:
Subject: =?iso-8859-1?B?SOVyZWtzIGRhbWViZXP4awo=?=
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: base64

Anyway, even the first notation is ugly enough that several people in the ISO 8859-1 community (Western Europe, mostly) denigrate it as "quoted-unreadable" and go on sending 8-bit SMTP messages.

Extensions have been defined to negotiate an 8-bit transfer channel over SMTP, but these have not seen wide deployment; the hampering issue is the question of what to do when you have an 8-bit message and a 7-bit channel; downgrading MIME into 7bit using quoted-printable is possible, but not completely straightforward; downgrading a non-MIME message to 7bit is an exercise in guesswork.

Still, the MIME extensions have been proven to work in practice for large and growing communities.

Last modified: Sat Sep 2 08:11:52 1995