This has the advantage of indicating the wrapping or non-wrapping desires
of the sender, but doesn't dork with the definition of text/plain.
I don't believe this claimed advantage is real. The dorking, so to speak, is
there regardless of where you put the wrap information.
I find this option unacceptable. "Plain text with CRLF representing line
breaks" and "plain text with CRLF representing paragraph breaks" are
semanticly different media types. The operation of line wrapping
demonstrates this because it often damages the former and never damages
the latter. In addition, the former works fine with ascii art and tables
while the latter may not work.
I don't understand how this differs in kind from a wrap=yes parameter to
text/plain. Why is that acceptable and this not?
I agree; while this argument about media types may be a valid one against the
use of any sort of parameter I don't think it argues against particular
placement of it.
However, I do think wrap is more of a media type _characteristic_ than it is a
disposition recommendation. As such, I think it makes more sense to make it a
content-type parameter.
Remember, line breaks are
perfectly acceptable (according to 2046) to be inserted for display
purposes whereever the receiver finds them useful, though for text/plain it
claims that you shouldn't need to do that (obviously PDA's being the
canonical example). How to handle display of media types is not discussed
in 2046, nor should it be (e.g., text in Braille or speech, images in color
or on paper, etc.). That's why Content-Disposition seems like an OK place
to deal with this; it describes the intended handling of the content of
this MIME body part. Like inline gives a hint of how to display it, so does
wrap.
I think another, more telling practical point is that support for
preservation, transport, and switching based on content-type parameters
is more likely to be found than corresponding support for content-disposition.
In summary, I think a content-type parameter is the appropriate choice for
wrap=.
Ned