Date: Wed, 12 Feb 92 11:14:58 +0100
From: "Alain FONTAINE (Postmaster - UCL)"
<fontaine(_at_)sri(_dot_)ucl(_dot_)ac(_dot_)be>
Subject: re: A bad journey (an apocryphal war story)
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.
Transport encoding can indeed be done and undone without knowing anything
about the type of transported object. (However, a little knowledge helps
pick the best transport encoding -- quoted-printable is likely to be more
efficient for text files with ascii-like charsets, base64 is likely
to be "safer" for application/octet-stream.)
However, for almost any content-type, there is likely to be some conversion
from "local" format to the canonical format for that content type. Text
files are no exception -- you have to convert from the local newline
convention to CRLF before encoding, and upon receipt, (after decoding
the content-transfer-encoding), you have to convert from CRLFs to the
local newlien convention.
The reason this is confusing is that at present, everything sent over
email is assumed to be text, and the conversion from CRLFs to newlines
is usually done by the receiving SMTP server. So it's easy to forget
that such a conversion is actually taking place.
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.
I agree that the current spec is confusing. I wouldn't call it
broken, but it does seem to need some tweaking to make this clearer.
Keith