On Thu, 12 Mar 1998, Steve Dorner wrote:
Why add this requirement to wrap=yes but not to text/paragraph? Seems like
it makes every bit as much sense to say:
* Due to (C) compatibility problem, an additional "MUST be able to
generate text/plain text suitable for 80-column display, and SHOULD do
so by default" rule has to be added. This may be a significant change
to software in class (B).
Because text/paragraph is backwards compatible for all compliant MIME
agents -- it's a new media type which meets all the requirements of a MIME
text media type. The only new compatibility issue is that text/paragraph
is not compatible with pre-MIME agents, but there is already a requirement
in RFC 2049 specifically to address that issue -- namely a MIME MUA must
be able to generate text/plain. Thus text/paragraph needs no new
backwards compatibility rules (although it wouldn't hurt to reiterate the
rule from RFC 2049 and explain its purpose).
The problem with adding a parameter to text/plain is that you are making
an incompatible amendement to the MIME spec which can break compliant MIME
agents (unlike text/paragraph). Thus from a procedure point of view, the
new compatibility rules are required.
As I said, I consider either change an improvement to the status quo, so
I'll go along with either.
- Chris