ietf-822
[Top] [All Lists]

overdefining text/plain?

1998-02-18 10:44:17
I'm not convinced that the semantics of text/plain should be so precise as
to indicate "no wrapping permitted" (yes, I agree that Chris's
text/paragraph draft doesn't go that far).  Or that it's even wise to
suggest that MUA's MUST offer certain options when dealing with it.

I think this for two reasons:

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.

2. For many years almost all client systems have been getting MORE capable,
and the "old standard" of an 80-column terminal has been the least common
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.

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.

I've no objection to also defining text/paragraph, for an explicit hint
that wrapping is desired.  And no objection either to text/70s, as an
explicit hint that wrapping is unwelcome.

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.