ietf-822
[Top] [All Lists]

Re: text/paragraph or wrap=yes/no

1998-03-13 10:58:08
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.

Nothing this strong was ever implied. What was there previously is what the
MIME standard says: That text/plain material must be formatted with no-wrap
display in mind. (Note that the use of the word "should" in RFC 2046 predates
the precise definitions of our compliance terminology. And there's also a
bigger problem in that MIME has never done enough in the area of collecting and
dealing with what it means to be a conformant sender. I've been complaining
about this aspect of MIME for several years now but have received basically no
support for trying to deal with the issue. Perhaps the present imbrogio will
provice me with some support the next time I bring this matter up.)

In many cases this means formatting to fit 80 column screens. But it is also
perfectly legal, and quite common, for someone to format something for 132
column display because they know that's what's at the other end. Or for 132
column printing with no expectation that display on a narrow terminal is
worthwhile.

Yes, this implies sender knowledge of recipient capabilities. Yes, this relies
on senders to "do the right thing" and not create messes. Yes, this is the sort
of assumption that made sense when the Internet was small (and indeed never
found its way into an RFC until the third revision of MIME) and makes less
sense now. And yes, there is a sort of an implicit "default that usually works
and should be used unless you know better" in all this that's somewhere around
80 columns (a bit less to be safe, actually). But it is only a default, not
a concrete requirement.

You keep trying to turn this into an explicit 80 column requirement. That isn't
there and isn't intended to be there. The most there is some sort of "should
unless you know better", which isn't a hard requirement and should never be
one.

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.

The problem is that this is neither necessary nor sufficient to deal with
text/plain as it is used today. It isn't necessary because of the existing
sender requirements. And it isn't sufficient because it fails to deal with
real-world usage.

Suppose I send you text/plain with a carefully formatted 132 colum table that's
also quite long and complex. No matter how you slice it you're not going to be
able to view this sensibly on a display that only has 80 columns. You can slide
and you can wrap to your heart's content but you're not going to get it to work
on an 80 column screen, much less a PDA.

Trying to impose requirements of the general form "recipients must be able to
make sense of this media type no matter what" are never a good idea -- this is
just one example of many. Other than security requuirements we try to stay out
of the business of making rules of this sort.

The real point is that as a sender I should not be firing this off to you
unless I know good and well that you can handle it. (Just as I should not be
sending you text/html or Microsoft Word.) If I don't know your capabilities I
should restrict myself to using a small number of columns. And the world seems
to have settled on some number slightly below 80 as something you can assume
support for.

And yes, I am well aware of the problem this poses for PDAs. We have similar
issues now with the "must be able to generate text/plain requirement's impact
on voice messaging systems. And with FAX on/off-ramps. But we don't try fix
this by breaking the installed base and saying that everyone must support audio
or image data of certain types. We fix this by devising new media types (or by
parameterizing old ones) with these devices in mind and, if necessary, by
creating new classes of service which lift whatever requirements no longer make
sense in their case.

Now, you can argue that PDAs are a different class of service and thus deserve
exemption from, say, the requirement that text/plain wrap=no be generatable.
But this is a separate discussion from the one we're having now. (I will say,
however, that I'm a long way from being convinced that PDAs do in fact
constitute a separate service class. And even if they do, I doubt very, very
much that generation of text/plain is the first requirement we should be
looking at modifying. In fact I doubt its in the top 10.)

So, I'm not sure text/plain wrap=yes has a significant compatibility
problem, at least not for display.

It doesn't as long as existing text/plain requirements aren't dropped.

(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).

FWIW, I don't think including the 80-colum number is appropriate. What needs to
be there is a requirement that wrap=no be generatable and probably some mention
that in the absense of information to the contrary a column width of less than
80 should be assumed.

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.

I disagree with your assessment that this is the nature of compliant
diplays. As such, I disagree that this requirement can be dropped.

(This, BTW, is what I meant when I said wrap=yes is "too easy" in and of
itself. I knew this that this requirement would need to be added and I knew
the folks at Qualcomm would object to 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?

Yes it would.

How about the last 40 characters of an 80 character line?

It would be standards compliant but not in compliance with implicit assumptions
peopel have made for many years. And this is why we need to do something about
this situation.

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? 

Um, well, no, we cannot, because in order to impose such a requirement we need
a label for such material and adding any sort of label would be a new feature
that would reset MIME to proposed. This one's a procedural no-brainer, I'm
afraid.

And while we could add an additional requirement without the label and not
reset MIME to proposed (additional restrictions and requirements are OK in this
regard), the result is known to cause interoperability problems and violates
the consensus reached during the MIME WGs operation in regards to how the
installed based should be handled. As such, it is my assessment as document
editor that this is also a nonstarter on procedural grounds.

Now, what we can do is write a new document that moves along the standards
track separately that imposes such a requirement along with a label. And this
is, more or less, just what we're trying to do.

I'm
suggesting that we don't require composition of both forms because the
current practice for compliant software already displays both.

Sorry. This dog doesn't hunt for me.

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.

Exactly. These are good faith implementations that comply with the standard
as it is written. We don't violate the trust people have placed in us in
such cases, even when not doing so is more painful to those doing new
implementation work.

                                        Ned