I find the response to Laurence's text/paragraph test to be what I
expected; significant compatibility problems still exist, in mailers it
would scare me to ignore.
RFC 2046:
4.1.1. Representation of Line Breaks
...
Similarly, whether or not line breaks should be added during display
operations is also a function of the media type. It should not be
necessary to add any line breaks to display "text/plain" correctly
...
4.1.3. Plain Subtype
...The
default media type of "text/plain; charset=us-ascii" for Internet
mail describes existing Internet practice. That is, it is the type
of body defined by RFC 822.
So, does 822 impose a no-folding-necessary rule? The only item I can find
in 822 that mentions the body is:
I'm afraid I find this line of reasoning to be entirely specious and without
merit.
The basic problem with trying to find language in RFC 822 about this is that
the present situation -- that of people putting lots of text on a single line
and expecting agents to be able to fold it for display -- didn't exist at the
time the document was written. As such, it simply did not occur to the document
authors to deal with this situation.
As the time MIME was written it was our task to assess the intent of RFC 822 in
this regard. And we reached a clear consensus on this point, one that is
reflected in the present MIME documents. (It was not reflected all that clearly
in earlier versions of MIME, I regret to say, but that's an editorial gaffe
rather than a failure of the WG to reach closure on this point.)
Note that this does not impose a length restriction, and in the note gives
tacit approval to letting the sender do the wrapping. Yes, this is in the
headers, not the body; I find it hard to believe that matters; the point
is, RFC 822 is clearly providing for long lines and recipient wrapping
rather than declaring long lines to be illegal.
Allowing for long lines and requiring that display agents be able to wrap on
display are completely different things. My basic problem with the way long
lines are used currently isn't that display them is an issue. It isn't. My
problem is that the intent of allowing long lines is to _allow_ _long_ _lines_.
Text/plain was defined with this purpose in mind. But now we're abusing the
mechanism. The result is that agents now find it necessary to wrap plain text
material in arbitrary ways and not just for purposes of display. This is
inevitable given that in many cases display processing cannot be changed and so
steps must be taken to alter the message before it reaches that point. And the
result is an interoperability problem, one that is not fixed by relaxing the
restrictions on text/plain.
So I think that 2046.4.1.1 and 2046.4.1.3 are in conflict with one another.
text/plain can't be both required to be viewable without added line breaks
and a description of RFC 822 mail, since RFC 822 had no such restriction.
I completely disagree. The first section limits the responsibilities of display
agents and imposes responsibilities on senders. The second simply says that
text/plain is intended to capture the semantics of RFC 822 text.
Even if I grant your conclusion that RFC 822 endorses the use of folding for
display (which I do not), it is _always_ permissible for a subsequent standard
to refine and restrict a previous definition. Always.
In fact it is even permissible for a revision of a standard to impose
additional restrictions that the previous version did not. And this can even be
done without a reset to proposed -- it is basically the only sort of change
that is permitted.
As such, as a procedural matter I find your assertion of a conflict to be
unfounded.
So:
- Long lines in 822 were permissible, even lines that needed to be wrapped
for display.
No. There is a difference between not giving something consideration and
permitting it.
- 2046 claims that text/plain is the same as 822.
No. Text/plain is derived from RFC 822 text; it is not the same thing. This is
obviously the case; consider "charset".
- 2046 also claims that text/plain must be viewable without wrapping, which
seems to me to conflict with the previous two statements.
No again. 2046 doesn't "claim" anything; it defines things.
- There will be significant compatibility problems if people start sending
text/paragraph.
There are already significant compatibility problems. Text/paragraph fixes some
of them. It may cause others, which means its a judgement call as to whether or
not it is a good idea. My current assessment is that the costs far outweight
the benefits.
- I'm not aware of significant compatibility problems with text/plain &
long lines.
I am. I run into them on a daily basis in the customer support work I do.
It seems to me that if there is a desire to have a type that should be
prewrapped and not need to be rewrapped, that should be the new type;
text/tty or something. I would be equally happy with a "wrap" parameter to
text/plain. However, I don't see much point in generating text/paragraph,
since it will be handled poorly by some major MUA's.
As you might well imagine, I am completely opposed to this.
Steve, you need to face facts here. The current MIME standard imposes certain
restrictions on text/plain. This is a done deal that you need to accept and
move on. Now, while I could quite possibly further restrict text/plain in a
subsequent revision of the document, I am not permitted to remove the
restrictions that are there without at a minimum undergoing a reset to proposed
and probably reforming the WG. This is not going to happen; the IESG would
likely have me strung up if I were foolish enough to try.
Now, it would be possible to do a follow-on document that changes the MIME
definitions. However, my assessment of the current climate surrounding this
issue is that such a document would never be approved.
As such, you can talk all you want about conflicts and removing restrictions
and so on, but it isn't going to accomplish anything. I could not change this
in MIME even if I wanted to (which I don't), and I don't believe follow-on work
to change it has any chance of acceptance. So the question you should be
looking at is, "Given that text/plain is defined this way and I cannot change
it, what should be done to fix the problems that have arisen with incompliant
usage of this type?". And the ways I see to fix it are to:
(1) Fix the agents that do this. This is what is happening, like it or not.
Community pressure _is_ forcing resolution of this problem. The problem
with this, of course, is that a genuinely useful facility may well be
lost in the process.
(2) Switch to using text/enriched or text/html. We tried; this dog doesn't
seem to hunt.
(3) Parameterize text/plain in a separate document. My assessment is that such
a course of action would only be acceptable if in addition to the
parameterization extremely strong language was added about the use of
long lines in text/plain with wrap=no being absolutely and completely wrong
and forbidden. I doubt this would then be acceptable to existing text/plain
abusers.
(4) Define text/paragraph. This will undoubtedly cause interoperability
problems with incompliant MIME agents, but I'd rather break incomplaint
ones that complaint ones.
Ned