ietf-822
[Top] [All Lists]

Re: text/paragraph or wrap=yes/no

1998-03-13 04:46:15


On 12 Mar 1998, Chris Newman wrote:

Date: 12 Mar 1998 12:46:37 0800
From: Chris Newman <Chris(_dot_)Newman(_at_)innosoft(_dot_)com>
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.

I would describe this as "text in which segments between line breaks
should be reflowed to fit horizontally on the user's screen for display or
editing". 


(C) An agent which assumes text/plain will display correctly on an
80-column terminal with no wrapping of any sort is standards compliant.

I would describe this as "text in which segments between line breaks are
intended to be display and edited each in one horizontal line. The display
or editor should make all attempts possible to show the text segments
without any wrapping or reflowing (e.g., a horizontal scroll bar). If
however it is not possible to display text in this fashion due to device
limitations, the text may be wrapped." 

So it seems Netscape did with the sample text/paragraph what is prefered
for text/plain and Eudora, AOL, ... did OK. 

Further, text/plain (as it stands today) should in most cases be displayed
in a fixed pitch font. That is, given two 300 character lines, the most
correct display would have characters in position 299 of each line
vertically aligned. 

How does this match what others think text/plain is? 


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:

Certainly the principles are correct, but you're implying producing 80
column text is compliance and I'm not sure what the basis of that is. If
that was implied all along that's OK, but I think we should now be 
explicit about it.

Since we've never clearly said what specific line length is compliant, I
would think any compliant displaying software MUST be able to deal with
arbitrarily long lines either by horizontal scrolling, or by wrapping. 
So, I'm not sure text/plain wrap=yes has a significant compatibility
problem, at least not for display. 



(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 don't see the compatibility problem because it seems to me any compliant
display must deal with arbitrary length because we've never specified a
length -- unless we decide that 80 columns was implied all along or such. 
That's OK, but lets be up front about it. 

Or asking in another way: would a user agent that refused to display in 
any manner the last 52 characters of a 132 character line be compliant? 
How about the last 40 characters of an 80 character line? 


Seems we can consider compatibility and compliance in three cases:
  - displaying what you get
  - composing what you send
  - editing something you got, for example forwarding

We clearly have to require any MIME agent to display both forms of text,
(to be wrapped, and long lines) but do we require them to compose it?  I'm
suggesting that we don't require composition of both forms because the
current practice for compliant software already displays both. 

The one counter argument is that MUAs most faithfully displaying
text/plain today, like Netscape, will suffer the most if we allow MUAs to 
compose only text/plain wrap=yes.

My preference is still the wrap parameter at this point, though I'm
interested to see what comes next in the discussion. I fear my neck is out
a little further. 

LL