At 08:53 AM 3/10/98 -0800, Ned Freed wrote:
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.
In fact, such systems DID exist back then, mostly notably SRI's NLS system
which I used for doing documentation. However we very much were NOT trying
to support the sending of their "native" construct, a paragraph.
Once again: 733 and 822 used the term "lines of ASCII text". The word
"lines" was not accidental or ambiguous.
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
This goes to the heart of the matter. We are talking about two different
semantic meanings for CRLF. One is as a line-ender and the other is as a
paragraph ender. This is not merely a matter of display, BUT OF SEMANTICS.
Surely that justifies use of a different content subtype, rather than
'merely' an added parameter, especially when the parameter pertains to
display and not semantics?
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;
Already exists. It's text/plain.
d/
________________________________________________________________________
Dave Crocker Brandenburg Consulting +1 408 246 8253
dcrocker(_at_)brandenburg(_dot_)com 675 Spruce Drive (f) +1 408 249
6205
www.brandenburg.com Sunnyvale, CA 94086 USA