On Sat, 29 Feb 92 16:39:24 +0900 you said:
There is at least one piece of text in MIME that might be worth taking
a closer look at to see if any changes are necessary (as far as the
quoted-printable newline issue is concerned):
The Content-Transfer-Encoding field is designed to specify
an invertible mapping between the "native" representation of
a type of data and a representation that can be readily
exchanged using 7 bit mail transport protocols, such as
those defined by RFC 821 (SMTP).
My understanding is that it has been an important decision that all
encodings should have the same capabilities, so that anyone can be selected
(for example by a gateway) without any knowledge of the type of the stuff to
be encoded. I started this thread because I did find that the current spec
is not in line with the stated principle. Fortunately, I (and the list) got a
couple of very enlightening messages from Mark Crispin, that convinced me that
it is indeed possible to have both encodings lossless and working correctly
for all types. They showed me that there was a problem in quoted-printable
(having this encoding using some knowledge about the local line separation
system directly), but also that texts encoded in base64 without enough care
could be damaged.
My proposal, as I said earlier, is just an attempt at putting into the spec
what I had learned. Maybe some pictures will help. Here is the flow following
the current spec :
Binary objects Text (local newline)
| |
| ---------------------------------------------------
| | | |
|-------------------------------------- | |
| | | | |
v v v v |
------------------------- ------------------------------ |
| Base64 encoder | | Quoted-printable encoder | |
| No special treatment | | Special treatment for the | |
| for the bytes used | | bytes used locally for | |
| locally for newline | | newline | |
------------------------- ------------------------------ |
| | |
|-------------------------------------- |
...........|........................................ |
. | Encoding (text), using local newline . |
. | convention as the MTA expects . |
. | . |
. |---------------------------------------------------------
. v .
. ------------------------ .
.| MTA |------------------------------------(Network)
. ------------------------ Text with CRLF newlines
. .
. What is done here is not really specified, .
. anything giving the same result on the line .
. is acceptable. .
....................................................
Both text and binary objects are subject to a different treatment depending
on the encoding selected ! And when text is encoded in base64, nothing
clearly warns implementers that it is not allowed to simply encode the
bytes locally representing line breaks (and why should this not happen,
since the encoder does not know the type of object to be encoded).
Here is the flow specified by the 'proposal' :
Binary objects Text (local newline)
| |
| |-------------
| | |
| -------------------- |
| | Local newline to | |
| | CRLF conversion | |
| -------------------- |
| | |
| Text (CRLF newline) | |
| | |
| --------------------------------------| |
| | | |
|-------------------------------------- | |
| | | | |
v v v v |
------------------------- ------------------------------ |
| Base64 encoder | | Quoted-printable encoder | |
| No special treatment | | No special treatment | |
| for the bytes used | | for the bytes used | |
| locally for newline | | locally for newline | |
------------------------- ------------------------------ |
| | |
|-------------------------------------- |
| |
| Encoding (text), using local newline |
| convention as the MTA expects |
| |
|---------------------------------------------------------
v
------------------------
| MTA |------------------------------------(Network)
------------------------ Text with CRLF newlines
Now, both texts and binary objects get the same treatment by either encoder.
And texts are always encoded in CRLF form, so they can be recovered without
doubt on any machine. Indeed, everything is now orthogonal, as it should be.
/AF