ietf-822
[Top] [All Lists]

re: A bad journey (an apocryphal war story)

1992-02-12 12:15:35
On Wed, 12 Feb 92 11:14:58 +0100, Alain FONTAINE (Postmaster - UCL) wrote:
Do I understand correctly that the right way to do the transport encoding
depends on the type of the object transmitted ? This is contrary to the
credo I heard before : transport encoding can be done/undone without knowing
anything about the type of the transported object.

No, no, 1000 times no!!!!!

Your problem is that you are assuming that it is *ever* reasonable to transmit
a text document using UNIX-style newlines via e-mail.  It is not, and using a
fancy encoding does not make it reasonable.

The first step you do when submitting a text document to e-mail is that you
convert from your local conventions to Internet conventions.  Only AFTER that
do you do any transport encoding.

The final step you do when receiving a text document from e-mail is that you
convert from Internet conventions to local conventions.  Transport decoding is
done BEFORE this.

Within the Internet e-mail infrastructure, all text is in CR LF format.  There
is no conversion of newlines within the infrastructure.  It doesn't matter if
it is quoted-printable, base64, 7bit, 8bit, or 69bit binary.

The conversion of newlines to/from local conventions is a user agent feature.

There can be no ambiguity because you don't convert newlines on binary, and
you always convert newlines on text.

Anyway, if doing the right thing is possible, but 'hard', most
implementations
will do it wrong (there are enough simple things done wrong to prove this
point). A specification that leads to such a conclusion should be considered
broken in the first place.

It's not that it's hard so much as that certain people insist upon getting a
fundamental concept such as newlines wrong (`all the world is UNIX').  That
doesn't make the specification flawed.  Some people have trouble with
division; does that mean we should throw out arithmetic?

No matter what you do, you will have some question about portable newline
support.  If you don't do newlines right, you'll have trouble properly
interpreting text documents from me in BASE64, because I can assure you that
even text documents in BASE64 have CR LF newlines out of my mailer.  If you
think about it you'll see that that is the only reasonable thing.

Once again, let me emphasize: NEWLINE CONVERSION IS GOVERNED BY THE CONTENT
TYPE AND NOT BY ANY TRANSPORT ENCODING.  YOU *ALWAYS* APPLY NEWLINE CONVERSION
(IF NECESSARY ON YOUR SYSTEM TYPE) TO TEXT DATA AND *NEVER* APPLY NEWLINE
CONVERSION TO ANY OTHER DATA, NO MATTER *WHAT* THE TRANSPORT ENCODING MAY BE.


<Prev in Thread] Current Thread [Next in Thread>