ietf-822
[Top] [All Lists]

Re: MTAs and Content-Transfer-Encoding conversions

1993-08-19 16:21:01
I think that the reason for the objections to quoted-printable is that it
tries to do too much.

Specifically, q-p tries to deal with the data munging problem as well as the
8-bit problem.

A correct q-p implementation will indeed deal with the data munging problem,
although you have to do extra things such as apply quoting to any line that
begins with ``From '' to work around the cretinism in Unix mbox format.
However, here are you are starting to see where q-p goes overboard.

Some editors by their nature leave trailing whitespace at the end of lines.
That comes out in q-p as lots of =20 sequences, none of which are of any
interest to either the sender or the recipient.

I am starting to think that what we need to do is define a new transfer
encoding that seeks only to get 8-bit characters through while keeping the
data readable, but does not attempt to deal with octet preservation the way
q-p does.

My proposal is for something like this:

        Content-Transfer-Encoding 8IN7

        The 8IN7 transfer encoding provides a way of indicating 8-bit
        characters in a 7-bit stream in a readable fashion.  It does
        not attempt to preserve the precise octets of the original
        stream; for this see the QUOTED-PRINTABLE and BASE64 encodings.

        Two characters in 8IN7 encoding are special.  The backslash (\)
        character quotes the next character, which may be either another
        backslash (\) or a tilde (~); no other character is valid.  The
        \\ sequence results in a single backslash, and the \~ sequence
        results in a single tilde in the destination stream.

        The tilde (~) character applies the high order (0x80) bit to the
        next character.  For example, the sequence ~A (0x7e 0x41)
        results in a capital accented A (0xc1).