I am glad that someone (wow, the editor himself 8-)) finally realized that
there is a problem here. The problem (that I have been trying to draw some
attention to for months) is simply that one cannot, at the same time :
- pretend that quoted-printable can transport newlines in a transparent
fashion between unlike systems and
- pretend that quoted-printable can be used to faithfully transport arbitrary
binary objects just like base64, and that either encoding can be selected
at will
*unless* one goes to the extreme complication implied by the proposal I have
made. Please note that I don't feel guilty at all : I just tried to formalize
what other, reputable people explained after I sent my 'bad journey' example
to this list. In the message accompanying the proposal, I did explain how
complicated it will be to do things correctly (but mrc has convinced me that
it is indeed possible), and so how much one can expect to see bad
implementations. (How it is possible : it is true that text must be
converted to CRLF before encoding, but the result of the encoding operation
will be produced in the local newline convention - abracadabra, no problem
for the transport layer, since it gets everything in the same (local)
presentation - and of course, with proper layering, it should never try
to decode anything, and thus never see the 'already in CRLF' texts sitting
inside).
Another, alternative solutions is to cease to pretend that quoted-printable
can encode anything, and make it into something that can only encode text ;
this is of course the end of the quoted-printable = base64 credo (this
equivalence has in fact been deleted when portable record separators were
removed from base64). But I see this is already the conclusion of Nat :
What all this points to, I believe, is that quoted-printable is
fundamentally line-oriented in the same way that unencoded 822
mail is, and we should just be upfront about that fact. It is NOT
an encoding intended to produce identical binary data on the
recipient's end. Quoted-printable data will not even necessarily
have the same number of BYTES on the recipient system as on the
sending system (e.g. if CRLF is converted to newline). This is a
property it shares with text.
The one thing one can *NOT* do is to leave the january text as is (or I'll
send my 'bad journey example' again). /AF