Re: 8-bit transmission in NNTP

Ned Freed <NED@innosoft.com> Wed, 14 September 1994 00:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10307; 13 Sep 94 20:44 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10302; 13 Sep 94 20:44 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa24337; 13 Sep 94 20:44 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08348; Tue, 13 Sep 94 20:18:15 EDT
Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08335; Tue, 13 Sep 94 20:16:31 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HH2JBJP5Z49N3X3L@INNOSOFT.COM>; Tue, 13 Sep 1994 17:10:39 -0800 (PST)
Date: Tue, 13 Sep 1994 16:50:19 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@innosoft.com>
Subject: Re: 8-bit transmission in NNTP
In-Reply-To: Your message dated "Mon, 12 Sep 1994 21:58:38 -0400" <9409122158.ZM2528@stargate>
To: Mark.R.Horton@att.com
Cc: Keith Moore <moore@cs.utk.edu>, keld@dkuug.dk, John Gardiner Myers <jgm+@cmu.edu>, IETF Mail Extensions WG <ietf-822@dimacs.rutgers.edu>, IETF SMTP Extensions WG <ietf-smtp@dimacs.rutgers.edu>
Message-Id: <01HH2KP7Z4XW9N3X3L@INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> It is not totally clear to me that doing Base64 encoding on binary
> attachments is the right long term thing to do.  I've seen criticism
> of MIME (as compared to X.400) in that MIME requires such an encoding.

Such criticism of MIME is entirely unjustified, since MIME does not require any
encoding per se.

MIME is a transport neutral protocol. If you have a binary transport you can
use MIME and not have to encode anything. If you have an 8bit-capable transport
you will have to encode binary objects. If you have a 7bit-capable transport
you have to encoding anything that isn't 7bit text.

The use of SMTP for MIME transport is what imposes the encoding requirement,
not MIME itself. Moreover, a means of negotiating 8bit transport over SMTP is
already defined, and work is underway in the MAILEXT Working Group to define
binary transport. Once this in place the need to encode binary in MIME goes
away.

Given this trend towards 8bit and possibly binary SMTP transport in the future,
your statements that encoding may not be the right thing to do in the long term
follows directly as a corollary. However, at the present time the ability to
operate over the current infrastructure is well worth the cost of encoding, in
my opinion.

> X.400 has its own ASN.1 encoding, but that does not involve translating
> every byte of a (potentially large) binary attachment.

In practice the encoding requirements of binary MIME are substantially simpler
than those of ASN.1 encoding. This is especially true on the receiving end.

> Are there any comparisons of performance of X.400 and SMTP/text
> and SMTP/MIME/Base64 on similar hardware?

Sure. I have done full implementations of both MIME and X.400, using hand-coded
parsers in both cases for maximum performance. On the transmit side 7bit MIME
costs more because of the need to encode every octet. On the receive side,
however, the difficulties of handling all the flexibility in ASN.1 offset most
if not all of the gains X.400 gets from its lighter encoding. (And this is with
all the tricks in place like comparing tags values as a whole instead of
breaking them down into subfields, use of proper language constructs to get
optimized code, direct comparison of encoded OIDs, and so on. Without these
tricks ASN.1 processing overhead can increase by a factor of 5 or more.)

Complexity is another matter, however, and to my mind it is usually more
important. On the transmit side MIME is trivial. No other word suffices to
describe it -- the construction of 7bit MIME messages is so easy its  almost
embarassing. And receiving and handling 7bit MIME is harder, but still pretty
simple. 

X.400, on the other hand, is substantially more complex, especially on the
receiving side. I'd say a factor of 4 increase in complexity at a minimum,
although I only needed about 2 times as many lines of code.

				Ned