At 12:24 PM -0600 2/18/98, Chris Newman wrote:
It has never been legal to generate paragraph-based text
and label it as text/plain (unless all paragraphs are less than 80-cols).
There is nowhere a mention of an 80 column restriction for text/plain, and
if there were it would be meaningless anyway, because of narrow devices.
A no-wrap restriction is not workable for the basic text type and I think
it should be given up. The "bad" example in your RFC is cute, but it's a
lot more legible than:
A no-wrap restriction is not workable for the basic
it should be given up. The example in your RFC is r
lot more legible than:
which is what a no-wrap rule is asking for.
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.
One of those mailers used to be AOL. Ignoring AOL is impractical. Now, it
may be that AOL has fixed their problem, but I'm not in general comfortable
with the risk. If I start generating text/paragraph and some large user
base botches it, users complain to me, and are relatively unimpressed when
I quote RFC's to them. (I'm currently having this problem with 8bitmime
and MSN...)
Nor am I
sure there's an option to add a parameter to a standards track media type
without resetting it to proposed.
Argument from ietf process doesn't tickly my ivories. Now, if we all
believe that all the major players are up to snuff in this regard, and we
think they'll all continue to be, fine. It scares ME, but maybe I'm just
chicken.