My personal problem with #2 is that it breaks open text/plain, even if only
a little bit (sort-of like being a little bit pregnant?).
And I'm not sure that it is possible to word the MUST/SHOULD exception in
such a way as to allow generation of long lines (which is currently
conforming behavior) but prohibiting the generation of long lines that look
like paragraphs - that would be a tricky bit of wordsmithing.
-----Original Message-----
From: Chris Newman [mailto:Chris(_dot_)Newman(_at_)innosoft(_dot_)com]
Sent: Thursday, March 12, 1998 12:47 PM
To: ietf-822(_at_)imc(_dot_)org
Subject: text/paragraph or wrap=yes/no
The problem we are trying to solve is the conflict between the following
facts:
(A) Inserting line breaks into text/plain may damage the data, and thus
needs to be avoided. In particular, it destroys ascii-art as well as
long lines with "hard" rather than "soft" line breaks.
(B) People generate paragraph-based text which is intended to have line
breaks inserted.
(C) An agent which assumes text/plain will display correctly on an
80-column terminal with no wrapping of any sort is standards compliant.
IETF tradition dictates that we don't break compliant software and we
don't damage data. Applying these facts to the two proposals results
in the following:
(1) Create new text/paragraph media type.
Pros:
* Only change is software class (B) has to use a new label
* Has no impact on (C) since it is a separate media type
Cons:
* Results in inability to display text on some non-conformant products
(2) Add a "wrap=yes/no" parameter to text/plain
Pros:
* All UIs will display text in one way or another
Cons:
* Due to (C) compatibility problem, an additional "MUST be able to
generate `wrap=no' 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).
I think either (1) or (2) is a significant improvement to the status quo,
so I'll go along with either.
- Chris