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.
As I said to Chris privately yesterday, I agree with this. I think a new
document could be written that extends the definition of text/plain with
an added parameter, and that document would have little trouble moving
along the standards track.
I really don't think there's a problem with defining a new parameter, as
long as the default is defined in such a way that the absence of such a
parameter yields the current text/plain semantics.
I have a non-procedural problem with the parameter approach, myself. I see
this as broadening the definition of text/plain to include material which is
not presently legal. This weakens the definition and makes it harder to deal
effectively with incompliant products. We actually have a pretty good track
record of getting the more popular incompliant products to stop misusing
text/plain. The products of a certain company headquartered in Redmond,
Washington are a case in point. I know for a fact that the specificity of the
definition of text/plain was the overriding factor in getting them to change.
And while having a parameter would have avoided the need for them to change, I
worry about what will happen with a weakened definition of text/plain the next
time we run into some form of incompliancy.
Now, this may sound like I don't think we should be doing text/paragraph, since
after all, if we can get people to switch to doing text/plain properly, why
bother? But the problem isn't that we haven't been able to get things changed
-- we have -- it is instead that we have had to go to a lot of trouble to get
this to happen, and it has been a tough sell because of the lack of available
alternatives. Text/paragraph fixes this, since it is much easier to tell
someone to change a label than it is to tell them to write a lot of new code.
I see some appeal in adding parameters to text/plain, on the assumption
that they may all be ignored by many mail readers. But I also know that
many systems can be customized/extended by subtypes, but not by
parameters. (Metamail, for the record, can work either way.) So I
don't see any truly compelling argument one way or the other.....
The inability to switch on parameters is also a problem, of course. But I see
this as quite different from the problem we have with broken agents that are
unwilling to handle unrecognized subtypes of text as text/plain. In one case we
penalize people for not doing something we never told them we had to do -- we
never said in so many words that parameter-based dispatching was a requirement.
But in the other case we did say quite explicitly what had to be done. Given
the choice between causing problems for conformant inplementations and causing
problems for nonconformant implementations, I think the right choice is
obvious.
Ned