It was my understanding (correct me if I'm wrong) that the requirement
for CRLF processing in text/* media types came from the fact that
recipients might be called upon to process MIME objects with
unrecognized text/* media types and/or unrecognized charset values,
and that by default, most recipients, even if they do not translate
charset values in any other way, might do end-of-line processing of
the recieved data before saving it to disk; thus, any charset that
does not have standard CRLF end-of-line convention might be subject to
mangling.
In the context of real time connection between sender and recipient
and the ability of the recipient to indicate the allowable media types
and charset values (such as found in HTTP), this is not an issue.
Thus, in the HTTP context, it is usually deemed reasonable to allow
text/* media types to be sent with the assumption that the end-of-line
might be signified by CR, LF, CRLF, or even a charset-specific end of
line convention, with the recipient required to accept all three end
of line mechanisms at least, and to only request other charset
encodings if the recipient understands that encoding.
I personally believe this is a HTTP issue and not an HTML issue.
However, you might note the wording of section 4.2.2 of RFC1866.TXT: