The above paragraph could be made clearer by indicating that "text"
must be converted to the Internet CRLF format before applying the
quoted-printable encoding, and that other, non-text objects should not
be converted to CRLF format before q-p'ing.
That's not enough : the same apply when text is submitted to base64, and
the changes I proposed also included comments at the right places to cover
this case. And then, one must remove any reference to the local newline
convention in the definition of q-p since, by definition, it now never sees
anything in that format (the other part of my changes - needed because the
current spec, which I helped to write, is wrong, in part as a result of
my own bad understanding of the matter when I wrote it).
to CRLF
It much easier to tell that text must be converted first, and then to define
a q-p (modified) and a base64 (the current one) that don't know anything about
the local convention, than trying to define both a q-p and a base64 that do
everything in one operation, because one has then to write everything with
clauses like 'if text is encoded', 'when a binary object is encoded'.
Now, if I remember well, nobody objected when these changes were first posted.
Only when the editor, who had accepted the principle, tried to put them in
the text, was he worried about one aspect of the question, and only this
aspect, namely the fact that it was not clear for him what would happen
when the encoding would be handed to some MTA's that are designed to accept
text in local newline format. This is indeed an implementation issue, and
my drawings were made to clarify one possible way to do the MUA/MTA transfer
(but any other way is fine as long as the result is the same).
In the same logic, one may of course
implement programs that do the conversion of text to CRLF (and the non-conver-
sion of binary object) at the same time as the actual encoding in base64
or q-p. But the specification is best made in term of independent, modular
transformations.
/AF