X.400 is defined using ASN.1, Internet Mail using ABNF

ASN.1 is two things:
  1. A data definition syntax which defines such things as "an integer goes here; this structure contains two strings and an integer, in any order"
  2. A set of encoding syntaxes for transferring ASN.1-defined data over the wire. The oldest, and the only one that is currently used in X.400, is Basic Encoding Rules - BER.
In the following, "ASN.1" is used as a shorthand for "ASN.1 + BER".

To quote some of the debaters over this issue: David Gibson:

But most important of all:
[X.400 is] Defined using an object oriented, recursive language designed for telecommunications - ASN.1.
Builtin support for multiple high performance transfer syntaxes.

Marshall Rose:

combining ASN.1 and high-performance is oxymornonic.

ASN.1 is probably the greatest failure of the OSI effort, it led hundreds of engineers, including myself, to devise data structures that were far too complicated for their own good.

David Gibson:
All the object oriented extensions (true object orientation - not OBJECT-TYPE Macros) of '94 ASN.1 make it a very powerful modelling language. Generating a high performance transfer syntax is a problem for the compiler author - the application designer is focused on other issues.
Carl M. Ellison <cme@tis.com>:
ASN.1 might be an interesting exercise for people who believe LISP is the only real language or who really like to play with abstract syntax or who like to write specs while ignoring implementations (ie., write standards). It's *really* easy to write structure declarations in ASN.1 -- as long as you don't try to implement from them.

However, as one who wants computer programs to be written efficiently and legibly (with small, easy to handle names, allowing complete statements to be expressed in a small space) and to have these programs communicate between machines with different byte ordering -- and almost nothing else -- I find ASN.1 is the *wrong* tool.

Throwing some reality out with the bathwater, when reading the above, consider:

Handling ASN.1

There are other issues with ASN.1 versus a text oriented protocol, such as: On the other hand, one problem with text-based headers is that they're meant to be human readable. Naive humans tend to assume that "if it looks right, it must be gramatically correct" and so generate messages with errors.
The most common case is
  From: John Q. Public <jqp@somewhere.com>
This is illegal according to RFC 822; a dot in a freeform name must be quoted, because a dot is a "special character". But it has become so common that most useful mail software accepts such headers, even though they are not standards-conformant.
(Thanks to Keith Moore <moore@cs.utk.edu> for this example)

But still, this error is a bit easier to spot than the encoding error in the hexdump 01 02 08 00 (an empty bitstring value should be encoded in one octet with zero unused bits in the last byte, not two octets with eight unused bits in the last byte. This, too, comes from real life....).

Last modified: Fri Nov 3 10:15:41 1995