On Wed, 18 Feb 1998, Steve Dorner wrote:
1. I think that more and more "nonconformant" uses of text/plain will be
discovered, and that we're going to wind up with a plethora of text/
subtypes, each with narrow definitions and little hope of widespread
implementation. text/plain itself will be illegal for practically anything.
It has never been legal to use CRLF for anything other than "line break"
in text/plain. The MIME standard is quite clear on that point. It is
also clear that text/plain is intended to be displayed without formatting
or processing. It has never been legal to generate paragraph-based text
and label it as text/plain (unless all paragraphs are less than 80-cols).
I don't think we can change the definition of text/plain at this point,
since changing it would require a reset of MIME to proposed standard. We
can clarify it and provide alternatives for misuse of the media type.
denominator. For better or worse, I think we'll soon be seeing a much
greater influx of 40 or 30 or even 20 character "terminals" in the near
future as more and more portable devices get on the net. Your "MUST" allow
an option not to wrap is very likely to be ignored by such systems.
This is a very good point. I will take it into account in the next
revision.
I would prefer that the honus for text/plain remain on the receiver; that
the receiving MUA do "something reasonable" with it, without making too
many assumptions. I don't want to get into a situation where it's perfectly
acceptable for a mailer to dump a piece of text/plain on the floor because
the sender didn't put two spaces after every period or whatever.
Any mailer which dropped any text/plain no matter how illegal will get
dropped as well. It's a practical requirement to offer a line-wrap option
for text/plain even though it was never intended to need line-wrapping.
Perhaps it would be better to put such hints in a parameter instead.
Define a "wrap" parameter, with values of "please" and "nothankyou" or
something. This would have the advantage of not running afoul of mailers
that choke on text/anything-they-dont-know-about.
Such mailers violate RFC 2049, so I'm inclined to ignore them. Nor am I
sure there's an option to add a parameter to a standards track media type
without resetting it to proposed.
- Chris