Re: Line Wrapping Question

[Ned Freed <[e-mail]>]

> A couple points:

> 1.  Yes, QP is simply an encoding mechanism.
> 2.  Yes, it shouldn't be used as a presentation mechanism (e.g assuming long
> lines wrap).

> But, THIS WAS NOT CLEAR.  It really wasn't.  Trust me.

I disagree. I think it is quite clear. The specification of text/plain says
right at the beginning:

  text -- textual information.  The subtype "plain" in particular indicates plain
  (unformatted) text.  No special software is required to get the full meaning of
  the text, aside from support for the indicated character set.

And later on it says:

  NOTE: The proper interpretation of line breaks when a body is displayed depends
  on the media type. In particular, while it is appropriate to treat a line break
  as a transition to a new line when displaying a text/plain body, this treatment
  is actually incorrect for other subtypes of text like text/enriched [RFC-1563].

In other words, line breaks in text/plain are to be treated as line breaks, and
the text is unformatted and is to be treated as such.

About the only thing missing from this description is an explicit declaration
that it should not be necessary to reformat text/plain by adding line breaks to
display it properly. I will add some wording to that effect to the next
iteration of these documents, not because I think it is necessary but because
it will be an improvement.

> The whole discussion of QP in the MIME spec discusses "hard" and "soft"
> carriage returns, and the examples show lines that are wrapped by QP, being
> rewrapped when decoded (partially an unfortunate consequence of the ASCII only
> presentation medium).  The discussion doesn't center on long lined data that
> needs to get through wrapping transports/gateways.  It talks about hard and
> soft CR's, a word-processing notion.

Sure it does. But you are ignoring the context in which this discussion occurs.
This discussion doesn't appear in the section on media types. It appears in the
section on transport encodings. The discussion of hard and soft line breaks
appears in the discussion of the sort of output the encoding produces, not in
any disussion of the input to the encoding process.

Furthermore, the preceeding sections explain what the purpose of transport
encodings is, and the stated purpose does not include control of presentation
to the user in any case other than that of quoted-printable being somewhat
kind to non-MIME-capable agents.

> Ned, step back for a moment and recognize that your world view is not everyone
> elses.  For example, you talk about "wrapping blindly".  But if I'm presenting
> the text in a windowed screen, I can "wrap blindly" and allow the user to
> resize the window if they don't like the way it wrapped at that size.  You're
> writing gateways, so you're forced to make a hard and fast decision that isn't
> revokable.  In your case, wrapping would be wrapping blindly.  In my case it's
> not.

Of course my world view isn't universal. It would be silly to assume so.
However, the point you seem to be consistently missing is that my position is
not based on my own biases as to how things should work. I have never made any
statements as to how I think things should work. As it happens my personal view
as to how it should have been done differs in substantial ways from the views I
have presented in this discussion, and you have no business making assumptions
about my personal view in any case. I quite frankly don't know why you insist
this being a personal issue for me -- you started by trying to make it out to
be somehow related to the limitations of my user agent, and now you're making
it out to be personal bias. It is neither.

My intent is to state how the *standards* *say* things *are* *required* to work
and that software agents exist that operate on the assumption that the
standards are to be obeyed in this regard.

You claim the standards are not clear in this regard. I claim they are, and
that the only reading that could arrive at any other conclusion is one that
totally ignores the context of the some statements and ignores any number of
other statements completely.

It is flat-out impossible to write useful standards documents without assuming
some amount of information is provided by context. Nor can we add text to every
section of the document under the assumption that other sections will not be
read. Were we to do so the document would literally explode in size and the
result would be unusable.

Your philosophy, on the other hand,  seems to be the same as the one that now
appears to govern the installation of traffic lights and signs on the roads in
this country: When someone screws up and there's an accident, it must be
because things weren't marked clearly, so the solution to the problem is to
install some additional lights and signs to make things even clearer. Every
misinterpretation requires clarification. Gone is the very real possibility
that some individual or individuals simply messed up.

I claim that this is what happened. Microsoft messed up. They are not immune.
Nobody is. Maybe some other people did so too, but if so I haven't seen or
heard about it. (I have seen Mac gateways get this wrong as well, but once I
talked with the gateway providers it became clear that they knew full well what
they were doing was wrong.)

I refuse to accept as given that any time someone misreads something it is
necessarily the material that they read that is in the wrong. The burden of
proof in order to get me to change something is a lot more than this.

> But this is history.  The bottom line is, there are still MIME capable
> mailers/gateways that do things in incompatible ways because of confusion in
> reading/interpreting/using the MIME spec.  The programmers that are reading
> that spec are not stupid.  It just wasn't clear.

And once again I disagree. The specification is clear on this point. I will
take steps to make it even more clear, but I maintain that it is clear enough
already. I have cited the places where it discusses this aspect of text/plain.
To say that line wrapping should be done on text/plain requires that you simply
ignore what the specification does in fact already say.

The most you have been able to do is say that the talk about soft and hard line
breaks in the section on quoted-printable encoding is confusing. My response is
that this is confusing only if you don't take the context in which the
discusssion appears into account. And this is something I am not able to
fix -- if you take something out of context you're in the wrong, period.

> Here's a clear statement:

> 1. For maximum interoperability of text composed by the user in an
> automatically wrapping text editor, send text/plain with short, hard-wrapped
> lines.  Wrap at something less that 80 characters (72 or 76 are good choices)
> to allow for quoting on reply.  If possible, send as 7-bit.  If your data
> contains 8-bit characters, you'll probably have to provide a user option about
> whether they want to encode as QP in this case or "just send 8-bit".

This is not a statement that is appropriate to put in MIME. MIME has no
business saying what constitutes maximum interoperability of text. The closest
MIME comes to this is it's discussion of transport limitations and what should
be done to assure maximum interoperability across transports. This is entirely
within MIME's province as it is a specification of an on-wire format.

In fact you seem to be missing the entire point with the prose you have
proposed. It is perfectly permissible to have long lines in text/plain material
-- if you want long lines to appear at the other end that's exactly what you
you should be putting in there! The problem is that this is NOT the effect that
Microsoft wanted: They wanted those lines to be wrapped. Their error consisted
of assuming that quoted-printable encoding would in some way accomplish this
goal. It won't.

> 2. If you want to send automatically wrapped text, use text/enriched, encoded
> using QP.

> If you're a vendor of MIME-capable software, support for text/enriched is a
> must.

Such a normative reference to another standard that's behind MIME on the
standards track is entirely out of order and cannot appear.

I'll think about adding a note about not using QP as a means to control the
display of material on MIME readers. I object to it on principle and think
it's unnecessary, but I'll think about it adding it.

				Ned