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.

No notation existed in 1984 to indicate that "this set or sequence may have elements you don't know about". (The 1992 ASN.1 introduced the "..." notation for this purpose).
The use of ASN.1 compilers generally promoted an "intolerant" view of ASN.1 descriptions, where all extra elements were "parse errors".
Certain features, like MTA-level security, required a guarantee that the message would not be forwarded if the feature was not understood.
When multiple organizations may define extensions, the idea of numbering all elements from 1 using context tags doesn't seem like a brilliant piece of engineering.

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:

The P1 "criticality" mechanism: All new features in the P1 envelope were added using a single structure, containing an integer or object identifier (OIDs only allowed by ISO spec, not ITU spec; the ITU doesn't like free extensibility), and a bitmap indicating what conditions should lead to discarding the message if you don't understand the extension.
The P2 "extension" mechanism: All new features in the P2 header were made up of an integer/OID (same comment) and the value. Rejecting the message because of these is not an option in P2, so there is no criticality; the rules simply say that it is legal to ignore any unknown extension.
The "Extended Body Part" (BP15): A new body part was invented, which contained TWO object identifiers, one identifying the format of any "parameters" and one identifying the format of the "body" itself, using the ASN.1 EXTERNAL construct.

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

SOVwZXIgZHUga29tbWVyIHNuYXJ0Cg==

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.

Harald.T.Alvestrand@uninett.no

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