Subject: BEANIE BABY LOVERS!!
From: [email-masked]
To: [email-masked]
Date: Mon, 30 Mar 1998 19:21:07 -0600 (CST)

BEANIE BABY LOVERS!!

Be a part of the largest and most exciting Beanie Baby club around!
Organized by Les & Sue Fox, authors of The New York Times Bestseller,
The Beanie Baby Handbook!

Go to http://www.beaniefanclub.com

From: [email-masked]
Date: Mon, 30 Mar 1998 02:42:22 +0200 (CEST)
To: [email-masked]
Subject: BEANIE BABY LOVERS!!
Reply-To: [email-masked]
Comments: Authenticated Sender is <[email-masked]>
Sender: [email-masked]

BEANIE BABY LOVERS!!

Be a part of the largest and most exciting Beanie Baby club around!
Organized by Les & Sue Fox, authors of The New York Times Bestseller,
The Beanie Baby Handbook!

Go to http://www.beaniefanclub.com

Date: Mon, 23 Mar 1998 16:06:07 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Fri, 20 Mar 1998, Jacob Palme wrote:
> At 19.08 +0100 98-03-19, Chris Newman wrote:
> > I'm starting to think "wrap=yes/no" is a misleading name for the
> > parameter.  Perhaps "format=fixed-lines/paragraphs" would be better.
> > Anyone have a better suggestion?   (and please don't suggest
> > "blurdybloop=yes/no" :-).
> 
> I do not think the recipient mailer is very interested in knowing
> whether the sender has wrapped paragraphs or not. The receipient
> mailer is interested in what kind of processing it should perform,
> such as:

The recipient is also interested in what programs can interpret the data.
For example, on my Macintosh I'd use SimpleText as the preferred
application creator code for "format=paragraphs" and I'd use CodeWarrior
as the preferred application creator code for "format=fixed-lines".  The
types of processing and default views these programs are capable of is
very different and goes well beyond the distinction between whether or not
the diplay can be wrapped.

> - Wrap long lines on the user display
> - Use a smaller font, or a proportional font, so that long lines fit
>   on one line
> - Insert a horizontal scroll bar in the viewing window

These are all currently legal behaviors for text plain, although the wrap
and proportional-font options will incorrectly display some text/plain
data.

> - Automatically convert CRLF to space and double CRLF to new paragraph

That will never be an option for text/plain -- use text/enriched if
you want those semantics.

> So the recipient mailer needs information if it should wrap or not,
> not information about whether the sender has wrapped or not!

The recipient can decide what to do on its own if it knows what media type
it's receiving.

> "wrap=no" might also indicate that a non-proportional font is suitable,
> since the text may contain tables or ascii art. And "wrap=yes" might
> indicate that a proportional font is suitable.

And this is a great example of why "wrap=yes/no" is a misleading label.

		- Chris

Date: Fri, 20 Mar 1998 12:05:17 -0800
To: Jacob Palme <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

At 04:51 PM 3/20/98 +0100, Jacob Palme wrote:
>I do not think the recipient mailer is very interested in knowing
>whether the sender has wrapped paragraphs or not. The receipient
>mailer is interested in what kind of processing it should perform,

In fact I think you've highlighted the nature of the current dilemma quite
nicely.  Some people are focusing on formatting directives and others are
focusing on information representation.  The latter pertains to semantics
of the underlying data and the former pertains to the presentation of that
data.  Both are valid issues, but it's important to keep them separate.

The trigger to the discussion, namely formalization of the "paragraph"
construct, is semantics.  Terms like "wrap" are presentation.

d/
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Date: Fri, 20 Mar 1998 16:51:50 +0100
To: Chris Newman <[email-masked]>, Pete Resnick <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

At 19.08 +0100 98-03-19, Chris Newman wrote:
> I'm starting to think "wrap=yes/no" is a misleading name for the
> parameter.  Perhaps "format=fixed-lines/paragraphs" would be better.
> Anyone have a better suggestion?   (and please don't suggest
> "blurdybloop=yes/no" :-).

I do not think the recipient mailer is very interested in knowing
whether the sender has wrapped paragraphs or not. The receipient
mailer is interested in what kind of processing it should perform,
such as:

- Wrap long lines on the user display
- Use a smaller font, or a proportional font, so that long lines fit
  on one line
- Insert a horizontal scroll bar in the viewing window
- Automatically convert CRLF to space and double CRLF to new paragraph

So the recipient mailer needs information if it should wrap or not,
not information about whether the sender has wrapped or not!

"wrap=no" might also indicate that a non-proportional font is suitable,
since the text may contain tables or ascii art. And "wrap=yes" might
indicate that a proportional font is suitable.

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Thu, 19 Mar 1998 19:46:31 -0800 (PST)
From: Laurence Lundblade <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Pete Resnick <[email-masked]>, [email-masked]
Subject: RE: text/paragraph or wrap=yes/no 
Sender: [email-masked]

On 19 Mar 1998, Chris Newman wrote:
>
> I'm starting to think "wrap=yes/no" is a misleading name for the
> parameter.  Perhaps "format=fixed-lines/paragraphs" would be better.
> Anyone have a better suggestion?   (and please don't suggest
> "blurdybloop=yes/no" :-).
> 
> At this point, I'll go ahead and update the draft to use a content-type
> parameter ("format=" for now).
> 

This sounds great, but shouldn't it be:

  format=fixed-lines/paragraphs/blurdybloops

I'm a bit worried about what people will do given the option to name 
their text anything they want, so we probably ought to try (again) for a 
defaulting rule for unrecognized formats. :-)

LL

Date: Thu, 19 Mar 1998 10:08:22 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Fri, 13 Mar 1998, Pete Resnick wrote:
> I don't understand how this differs in kind from a wrap=yes parameter to
> text/plain. Why is that acceptable and this not?

Because Content-Disposition includes display/storage advice while
Content-Type is used to distinguish semanticly different media types.  The
meaning of CRLF is semantically different between paragraph-based and
line-based plain text, so the distinction has to be made on the
Content-Type line.  I don't see a problem calling these either two
different subtypes of "text" or two different variants of "text/plain,"
but I do see a problem calling them the exact same media type with
different display advice. 

For another fun example, suppose you're mapping from text/plain to a
Unicode text file using the LINE SEPARATOR and PARAGRAPH SEPARATOR
codepoints -- then the mappings for line-based and paragraph-based text
are different.  (Please don't start a long diversion on this example --
it's a separate problem).

I'm starting to think "wrap=yes/no" is a misleading name for the
parameter.  Perhaps "format=fixed-lines/paragraphs" would be better.
Anyone have a better suggestion?   (and please don't suggest
"blurdybloop=yes/no" :-).

At this point, I'll go ahead and update the draft to use a content-type
parameter ("format=" for now).

BTW, as far as the spec is concerned, "format=fixed-lines" and no format
parameter are semanticly identical.  If an MUA wants to handle those two
cases differently, that's fine.

		- Chris

Date: Thu, 19 Mar 1998 07:30:30 -0800
From: Laurence Lundblade <[email-masked]>
To: [email-masked]
Reply-to: [email-masked]
Subject: This is text/plain wrap=yes - how does it look?
Sender: [email-masked]

Perhaps this test is unnecessary since we occasionally deal with long lines on a daily basis already, but it still seems like a good idea to check this just to be sure.  If you send responses directly to me I'll summarize for this list.  This message is entirely one long line except for a couple of carriage returns and my initials at the end. I wonder what other things we're going to run into? I suspect some buffer overflow bugs for MUAs and MTAs that can't really handle 1000 characters. We'll also probably run into more anti-quoted-printable sentiment since QP is likely to be used more often. Probably the transfer encoding section of text/plain wrap=yes should say that CTE should be avoided unless required by line length or character set. MUAs are also going to have to learn to permanently wrap when the ">" quote a message in a reply.

LL

Date: Thu, 19 Mar 1998 07:11:47 -0800 (PST)
From: Laurence Lundblade <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Steve Dorner <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: RE: text/paragraph or wrap=yes/no 
Sender: [email-masked]

On 13 Mar 1998, Ned Freed wrote:

> There's nothing vague about it. The problem is that there needs to be an added
> requirement to require the ability to generate text/plain wrap=no and you and
> others at Qualcomm appear to object to that.

Or I/we were following a few paths to see where they lead. I don't object 
to the requirement.

Perhaps it is useful to consider that the text we deal falls basically 
into three categories:

1) Haiku/ascii art/tabular - Text that was composed explicity on a
line-by-line basis. The user put the line breaks in where they wanted them.
This is clearly text/plain now and text/plain wrap=no in the future. 

2) Courtesy wrapped - Text that was composed in an environment which flows
text across lines as the user composes it and then hard-wrapped by the
sending agent as a courtesy to the receiving agent and to comply to the
standard.  This text is typically wrapped at slightly less than 80 columns.
This is probably the most common form of text in use today. 

3) Flowable - Text that was composed in an environment which flows text 
across lines and is sent that way. This would be text/plain wrap=yes.

LL

From: "Bart Schaefer" <[email-masked]>
Date: Tue, 17 Mar 1998 10:42:52 -0800
Comments: In reply to Jacob Palme <[email-masked]> "Some notes about the wrap=yes/no or Text/Paragraph issue" (Mar 17, 10:53am)
To: IETF mailing list on MIME and e-mail  <[email-masked]>
Subject: Re: Some notes about the wrap=yes/no or Text/Paragraph issue
Sender: [email-masked]

On Mar 17, 10:53am, Jacob Palme wrote:
} Subject: Some notes about the wrap=yes/no or Text/Paragraph issue
}
} Should a sender who has wrapped a message indicate wrap=no or wrap=yes?
} ----------------------------------------------------------------------
} 
} It is important to specify whether "wrap=no" means that the sender has
} already wrapped the message into < 80-character lines, or whether it
} is advice to the receiving mailer on whether to wrap or use horizontal
} scrolling for long lines.  [...]
} 
} Thus, even if the sending mailer has already wrapped the message, it
} should still have "wrap=yes" (or be sent as "text/paragraph").

I think this illustrates that we're not faced with a yes-or-no question.
You're trying to make a distinction between "fill" and "nofill" which is
not appropriate for the (so far discussed) meaning of the parameter.  If
that's an important distinction to make, then probably there should be
additional values.

However, that's drifting even farther down the path of markup languages.

} "wrap=no" should only be used for messages which contain ascii art
} and tables.

Most messages that contain tables etc. will contain "ordinary" text as
well.

} Suppose a message only contains very short paragraphs, with no
} paragraph longer than 70 characters. For example, a message which
} only contains the word "Yes!" or only contains the phrase "Hear,
} hear!". How should such a message be handled?

Exactly as if the text weren't short.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

Date: Tue, 17 Mar 1998 10:53:28 +0100
To: IETF mailing list on MIME and e-mail  <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Some notes about the wrap=yes/no or Text/Paragraph issue
Sender: [email-masked]

Should a sender who has wrapped a message indicate wrap=no or wrap=yes?
----------------------------------------------------------------------

It is important to specify whether "wrap=no" means that the sender has
already wrapped the message into < 80-character lines, or whether it
is advice to the receiving mailer on whether to wrap or use horizontal
scrolling for long lines. For example, even if the sending mailer has
wrapped the lines into < 80-character lines, a receiving mailer with
a very small screen might want to rewrap them to a lower width.

Thus, even if the sending mailer has already wrapped the message, it
should still have "wrap=yes" (or be sent as "text/paragraph").
"wrap=no" should only be used for messages which contain ascii art
and tables.

Meaning of omission of the wrap parameter
-----------------------------------------

One difference between the wrap=yes/no and text/paragraph solution is
that the wrap=yes/no allows three variants:

- wrap=yes
- wrap=no
- no wrap parameter specified (which might be interpreted as "this comes
  from an old mail client developed before the wrap parameter was specified",
  or alternatively as "don't know" or "don't care")

Labelling of messages which only has very short paragraphs
----------------------------------------------------------

Suppose a message only contains very short paragraphs, with no
paragraph longer than 70 characters. For example, a message which
only contains the word "Yes!" or only contains the phrase "Hear,
hear!". How should such a message be handled?

(a) Always wrap=no
(b) Either wrap=no or wrap=yes are equally valid
(c) wrap=yes if the very short text should be wrapped in clients with
    very narrow windows, wrap=no if the very short text should not be
    wrapped for such clients.
(d) No wrap parameter should be given at all

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Date: Mon, 16 Mar 1998 15:54:52 -0800
From: Dan Wing <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: draft-ietf-drums-smtpupd-06.txt: TURN
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------5CEE13E423E5D391A5E933E1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Some sortof braincell malfunction caused me to send this to the
incorrect mailing list, so I'm resending it to DRUMS.  Sorry if you've
seen this twice.

-Dan Wing
--------------5CEE13E423E5D391A5E933E1
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Date: Mon, 16 Mar 1998 15:33:01 -0800
From: Dan Wing <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: draft-ietf-drums-smtpupd-06.txt
Sender: [email-masked]

draft-ietf-drums-smtpupd-06.txt, Appendix I reads:

% (1) TURN
%  
% This command, described in RFC 821, raises important security issues
% (described in RFC 1123).  Its use is deprecated; SMTP systems SHOULD
% NOT use it unless the server can authenticate the client.

I couldn't find the reference to TURN in RFC1123.

-Dan Wing

--------------5CEE13E423E5D391A5E933E1--

Date: Mon, 16 Mar 1998 15:33:01 -0800
From: Dan Wing <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: draft-ietf-drums-smtpupd-06.txt
Sender: [email-masked]

draft-ietf-drums-smtpupd-06.txt, Appendix I reads:

% (1) TURN
%  
% This command, described in RFC 821, raises important security issues
% (described in RFC 1123).  Its use is deprecated; SMTP systems SHOULD
% NOT use it unless the server can authenticate the client.

I couldn't find the reference to TURN in RFC1123.

-Dan Wing

Date: Mon, 16 Mar 1998 09:20:14 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

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
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Date: Mon, 16 Mar 1998 00:33:53 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: overdefining text/plain?
To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> The right way to send "hairy" rtf would be something like application/rtf
> (assuming it existed).  Goodness only knows what "hairy" means, of course.

Agreed. And I've yet to see any RTF didn't at least have quite a bit of stubble
on it...

				Ned

Date: Mon, 16 Mar 1998 00:06:59 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > This has the advantage of indicating the wrapping or non-wrapping desires
> > > of the sender, but doesn't dork with the definition of text/plain.

I don't believe this claimed advantage is real. The dorking, so to speak, is
there regardless of where you put the wrap information.

> > I find this option unacceptable.  "Plain text with CRLF representing line
> > breaks" and "plain text with CRLF representing paragraph breaks"  are
> > semanticly different media types.  The operation of line wrapping
> > demonstrates this because it often damages the former and never damages
> > the latter.  In addition, the former works fine with ascii art and tables
> > while the latter may not work.

> I don't understand how this differs in kind from a wrap=yes parameter to
> text/plain. Why is that acceptable and this not?

I agree; while this argument about media types may be a valid one against the
use of any sort of parameter I don't think it argues against particular
placement of it.

However, I do think wrap is more of a media type _characteristic_ than it is a
disposition recommendation. As such, I think it makes more sense to make it a
content-type parameter.

> Remember, line breaks are
> perfectly acceptable (according to 2046) to be inserted for display
> purposes whereever the receiver finds them useful, though for text/plain it
> claims that you shouldn't need to do that (obviously PDA's being the
> canonical example). How to handle display of media types is not discussed
> in 2046, nor should it be (e.g., text in Braille or speech, images in color
> or on paper, etc.). That's why Content-Disposition seems like an OK place
> to deal with this; it describes the intended handling of the content of
> this MIME body part. Like inline gives a hint of how to display it, so does
> wrap.

I think another, more telling practical point is that support for
preservation, transport, and switching based on content-type parameters
is more likely to be found than corresponding support for content-disposition.

In summary, I think a content-type parameter is the appropriate choice for
wrap=.

				Ned

Date: Sun, 15 Mar 1998 23:46:53 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: Bart Schaefer <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

> } Right now, the MIME documents make no claim about what the number of
> } columns that you are required to keep your short lines too; the only thing
> } it says is that you're supposed to send them short enough such that "It
> } should not be necessary to add any line breaks to display "text/plain"
> } correctly" (2046). My claim all along (with Laurence, Steve, and others I
> } believe) is that this turns out to be an impossible requirement to meet
> } because senders can't tell how short to make the lines from this dictum.

> What that rule should be getting across (and apparently isn't) is that
> a line break should -mean- the same thing to both the sender and the
> recipient of any bodypart that is labeled text/plain.

Quite correct, and your point about people not picking up on this is well
taken. If there's something that needs to change in MIME it is this. However,
I've tried numerous times in this discussion to get this point across with
no success whatsoever. I hope your restatement here helps clarify matters.

> What it means for recipient UA text/plain handling is:

> * Don't add more line breaks unless there's no other way to show all
>   the text (or unless asked to add them by some configuration option).
>   Especially never display one line break as two; that is, a line break
>   does NOT mean a paragraph break.

> * Don't remove any line breaks.

> (A corollary is that a sender who deliberately uses long lines, e.g. for
> a table, can assume that recipients won't break up his long lines unless
> they have no other choice.  A secondary problem with sending paragraph
> text labeled text/plain is that recipient UAs get modified to compensate
> by doing word-break folding on long lines, which then destroys display of
> text that was intended to have lines left unfolded.)

> The only requirement that senders have to meet is that, if they use the
> label text/plain for a bodypart, then the recipient's UA can produce a
> minimally sensible display of that part by following those two rules.

> Note that this means that a sender -cannot- assume that a recipient will
> fold long lines at word breaks.  In fact, given that (2046):

>     Plain text may allow the stacking of several characters in the
>     same position in the text.  Plain text in scripts like Arabic
>     and Hebrew may also include facilities that allow the arbitrary
>     mixing of text segments with opposite writing directions.

> A sender can't even assume that a recipient knows what a word break -is-.

> How much folding a UA that allows user input in paragraph format needs
> to add in order to use the text/plain label, is a judgement call.  BCP
> indicates folding somewhere between 70 and 80 columns, but that's only a
> guideline.  The one thing that should be clear is that -not- folding at
> all means that -no- recipient UA can display that text sensibly by using
> only those two line-break rules.

And perhaps more to the point, the solution to this problem is _not_ to declare
that text/plain with lines longer than 80 characters is broken. This is
perfectly valid usage that we cannot break. 

> The idea is to minimize the number of extra line breaks that recipients
> may be forced to insert for display; the impossible task is to eliminate
> them entirely, but that's not what senders are being asked to do.

Nicely put.

				Ned

From: [email-masked]
To: [email-masked]
Date: 15 Mar 1998 21:00:28 +0100
Sender: [email-masked]

g.dk, [email-masked], [email-masked]
From: <[email-masked]>
Subject: The Online Gamblers Network
Reply-To: [email-masked]
X-PMFLAGS: 10322341.10
X-UIDL: 10293287_192832.222
Comments: Authenticated Sender is <[email-masked]>
Message-Id: <51835936_33826252>
content-length: 1332

The Online Gamblers Network (gamblersnetwork.com) has located an exciting
new
Web site that offers FREE online gaming for fun, entertainment, and profit!

At Caribbean Treasure Casino's new internet site, guests are invited to
play
Poker, Blackjack, Baccarat, Slot Machines, Craps, and Roulette for pure fun
and
entertainment.  This is a very well thought out site and offers intuitive
interfaces to all games.  It is not overly-graphic, so that it loads
quickly,
and registration is a snap.  We were at the Blackjack table in less than 3
minutes after locating the 
home page.  Once the game has started, it is incredibly fast - probably due
to
the Java applet that handles most of the client side user interface.  All
in
all, this site was a pleasure to visit - very impressive for a free site.

In addition, a promotional Grand Opening Tournament with $4,000.00 in prize
money has just started.  The tournament is also free.  At the start of the
contest, each guest's account gets 5000 credits.  Guests may play any of
the
games, and at the end of the contest period, the top three accounts with
the
most credits will share in the prize money.

Visit the Caribbean Treasure Site at

        http://www.ctc-contest.com

This is a five-star site!
Site Reviews Editor
The Online Gamblers Network

From: [email-masked]
Date: Sun, 15 Mar 1998 21:49:40 +0200
To: [email-masked]
Subject: Offroad 151 drives anywhere - even underwater!
Reply-To: [email-masked]
Comments: Authenticated Sender is <[email-masked]>
Sender: [email-masked]

Adventure and 4x4 fun is yours with the unique Encore 151.
Military's top vehicle before the Hummer.
Ideal for hunting, ranchers and offroad driving.
Visit http://EncoreVehicles.com for photo & details!

--
-/-/-/-/-/-/-/-/-/-/-/-/-
Dewey Davis-Thompson, Publisher/Promoter
DailyRevolution.com - Daily News in Tampa, Moscow and Virgin Islands
Davis-Thompson.Com - a multimedia marketing agency

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 14 Mar 1998 14:05:04 -0800
Comments: In reply to Pete Resnick <[email-masked]> "Re: text/paragraph or wrap=yes/no" (Mar 13,  5:58pm)
To: Pete Resnick <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

On Mar 13,  5:58pm, Pete Resnick wrote:
} Subject: Re: text/paragraph or wrap=yes/no
}
} Right now, the MIME documents make no claim about what the number of
} columns that you are required to keep your short lines too; the only thing
} it says is that you're supposed to send them short enough such that "It
} should not be necessary to add any line breaks to display "text/plain"
} correctly" (2046). My claim all along (with Laurence, Steve, and others I
} believe) is that this turns out to be an impossible requirement to meet
} because senders can't tell how short to make the lines from this dictum.

What that rule should be getting across (and apparently isn't) is that
a line break should -mean- the same thing to both the sender and the
recipient of any bodypart that is labeled text/plain.

What it means for recipient UA text/plain handling is:

* Don't add more line breaks unless there's no other way to show all
  the text (or unless asked to add them by some configuration option).
  Especially never display one line break as two; that is, a line break
  does NOT mean a paragraph break.

* Don't remove any line breaks.

(A corollary is that a sender who deliberately uses long lines, e.g. for
a table, can assume that recipients won't break up his long lines unless
they have no other choice.  A secondary problem with sending paragraph
text labeled text/plain is that recipient UAs get modified to compensate
by doing word-break folding on long lines, which then destroys display of
text that was intended to have lines left unfolded.)

The only requirement that senders have to meet is that, if they use the
label text/plain for a bodypart, then the recipient's UA can produce a
minimally sensible display of that part by following those two rules.

Note that this means that a sender -cannot- assume that a recipient will
fold long lines at word breaks.  In fact, given that (2046):

    Plain text may allow the stacking of several characters in the
    same position in the text.  Plain text in scripts like Arabic
    and Hebrew may also include facilities that allow the arbitrary
    mixing of text segments with opposite writing directions.

A sender can't even assume that a recipient knows what a word break -is-.

How much folding a UA that allows user input in paragraph format needs
to add in order to use the text/plain label, is a judgement call.  BCP
indicates folding somewhere between 70 and 80 columns, but that's only a
guideline.  The one thing that should be clear is that -not- folding at
all means that -no- recipient UA can display that text sensibly by using
only those two line-break rules.

The idea is to minimize the number of extra line breaks that recipients
may be forced to insert for display; the impossible task is to eliminate
them entirely, but that's not what senders are being asked to do.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Fri, 13 Mar 1998 17:58:58 -0600
To: Ned Freed <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: Ned Freed <[email-masked]>, Laurence Lundblade <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On 3/13/98 at 4:57 PM -0600, Ned Freed wrote:

>It was my understanding that you objected to the requirement that agents
>generating wrap=yes also be able to generate wrap=no, or at least questioned
>the need for it. If that's not the case then we are basically in agreement
>and can proceed with the wrap parameter and a requirement that it be possible
>to generate wrap=no material.

I did question the need for the requirement, but I didn't object to it per
se. Here's my reasoning, though you can all skip down to the bottom of the
message if you just want the conclusion:

Right now, the MIME documents make no claim about what the number of
columns that you are required to keep your short lines too; the only thing
it says is that you're supposed to send them short enough such that "It
should not be necessary to add any line breaks to display "text/plain"
correctly" (2046). My claim all along (with Laurence, Steve, and others I
believe) is that this turns out to be an impossible requirement to meet
because senders can't tell how short to make the lines from this dictum. At
best, you can follow the rule, "Lots of people won't have trouble if you
keep them below 80 columns, but some will". For some class of clients, it's
going to be necessary to add line breaks in order for many text/plain
messages to "display correctly". Arbitrarily putting a dividing line at
clients who have 80 column displays and don't do any further wrapping is
fine, but let's be sure we understand that this is what's going on. And
this failure of 2046 is going to be present whether we do text/paragraph or
a wrap parameter.

If there is consensus that 2046 really meant "short lines, meaning less
than 80 columns", then this means we have to add a requirement to the wrap
parameter document saying "You MUST still be able to generate short lines,
meaning less than 80 columns, and wrap=no". That's fine. But understand
that text/paragraph is going to have to make the same clarification: "2046
says that you still have to generate text/plain and that means you still
have to be able to generate short lines, and that has always meant less
than 80 columns." If text/paragraph doesn't need to make that clarification
to 2046, then there's no need for the requirement statement in the wrap
document; either 2046 needs clarification on what it allows in text/plain
or it doesn't.

All that said, I think you have heard now from at least Steve and I that we
have no objection to the wrap=no requirement if consensus is that this
clarification of 2046 is necessary; we have all the support to do that in
Eudora now and we don't think it's any big burden on other implementations.
You have heard objections to text/paragraph due to its serious
interoperability problems. So I think we can proceed with the wrap
parameter as you stated and abandon text/paragraph.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Fri, 13 Mar 1998 15:04:46 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: [email-masked]
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

> Until of course some bozo wants to mix long-line paragraphs with
> ascii art, because *his* MUA 'looks right when he does it".... ;)

Yep, it is a problem for sure.

> I sense a slippery slope here.  Perhaps pushing text/html capable
> MUA is the REAL right answer here?

I used to believe this was the case, although I might have argued for
text/enriched or text/simpletext at various points in time. But we have ample
evidence that this just doesn't fly. We've spent vast amounts of time trying to
come up with solutions in this space, we've documented them, many of
us have written code to support them, and none of them have worked out.

I guess another way to put it is that this may well be the right answer, but
there doesn't appear to be a way to get there from here.

And yes, I agree about the slippery slope, which is why the requirements in
these proposals need to be fairly draconian.

				Ned

Date: Fri, 13 Mar 1998 14:57:23 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: Pete Resnick <[email-masked]>
Cc: Ned Freed <[email-masked]>, Laurence Lundblade <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> On 3/13/98 at 10:59 AM -0600, Ned Freed wrote:

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

> Are you saying that a compliant display is only one that chops off lines
> that are greater than it's maximum screen real estate if it is less than 80
> columns? I thought you denied that some time ago.

I don't recall saying any such thing. A display that chops off lines is
compliant as far as I can tell. Suboptimal, perhaps, but compliant. If I said
otherwise I was mistaken.

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

> Unless I misunderstand what you are saying, I don't object to wrap=yes nor
> the requirement that senders must be able to generate short lines. What do
> you think I'm objecting to?

It was my understanding that you objected to the requirement that agents
generating wrap=yes also be able to generate wrap=no, or at least questioned
the need for it. If that's not the case then we are basically in agreement
and can proceed with the wrap parameter and a requirement that it be possible
to generate wrap=no material.

				Ned

Date: Fri, 13 Mar 1998 14:52:16 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
To: Steve Dorner <[email-masked]>
Cc: Dave Crocker <[email-masked]>, [email-masked]
Sender: [email-masked]

> The interoperability problem is in the near term better solved by a
> parameter, not text/paragraph.  The only problems I've heard with the
> parameter are fairly vague procedural misgivings, and a wish that nobody
> would send paragraph text.  I understand the former, but I think it's
> outweighed by the practical disadvantage of text/paragraph, at least for
> now.  As for the latter, I just don't agree.

There's nothing vague about it. The problem is that there needs to be an added
requirement to require the ability to generate text/plain wrap=no and you and
others at Qualcomm appear to object to that.

I have said before and I'll say it again: I have no problem with adding
a parameter as long as this requirement is present. You appear to be
the one with a problem, so the ball is in your court: Either convince
the rest of us that this parameter is unnecessary, or accept that it needs
to be there. Either way and it looks like we can move forward, and if not
we cannot.

				Ned

To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: text/paragraph or wrap=yes/no 
From: [email-masked]
Date: Fri, 13 Mar 1998 17:17:52 -0500
Sender: [email-masked]

--==_Exmh_550241756P
Content-Type: text/plain; charset=us-ascii

On Fri, 13 Mar 1998 11:58:48 PST, Dave Crocker said:
> Text/plain is assumed to be (fully) formatted by the sender, hence the term
> "lines".  
> It is assumed that one line from the sender will be displayed as one line.
> While it is legal for a receiver to play formatting games with the text, we
> have all seen how difficult (or impossible) this can often is to make pretty.
> 
> Text/paragraph says that the sender is using CRLF very differently from
> text/plain and expects the receiver to perform whatever wrapping procedures
> are necessary for smooth presentation.  

Until of course some bozo wants to mix long-line paragraphs with
ascii art, because *his* MUA 'looks right when he does it".... ;)

I sense a slippery slope here.  Perhaps pushing text/html capable
MUA is the REAL right answer here?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_550241756P
Content-Type: application/pgp-signature

--==_Exmh_550241756P--

Date: Fri, 13 Mar 1998 15:42:51 -0600
To: Dave Crocker <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

At 1:58 PM -0600 3/13/98, Dave Crocker wrote:
>Further, messing with text/plain by adding a parameter scares me a bit.
>Text/plain is so fundamental to MIME's deployment that I believe we should
>not mess with it

I agree with you that it shouldn't have been messed with.  But Ned already
messed with it in 2046 by adding the "displayable without wrapping"
requirement.  Call it a clarification, say it was what you really intended
all along, fine.  It still remains that formally compliant implementations
became formally non-compliant when he did that.  I'm no longer asking for
this to be rolled back, I'm just pointing out that text/plain has already
been messed with.

>even if the argument in favor of a text/plain parameter
>were strong, which it isn't.

A large part of the user community would be significantly inconvenienced by
text/paragraph.  I suspect least as large a part as are currently being
bothered by paragraph text in text/plain (go look at the list of mailers
failing to display text/* easily, and count their users).

I understand the desire to punish these non-compliant implementations.
Unfortunately, the old saw "this is going to hurt me more than it hurts
you" comes into play.  They're too big for me to punish.

So I will not at this point in time generate text/paragraph.  However, I
will continue to send unwrapped text when users instruct me to.  I would be
happy to label this with a parameter in either content-type or
content-disposition or anywhere else you please (how about message-id?
Received?  :-)).  But I will not send it as text/paragraph until there is
better compliance with the text/* rule (at which point I have no objection
to it at all).

The interoperability problem is in the near term better solved by a
parameter, not text/paragraph.  The only problems I've heard with the
parameter are fairly vague procedural misgivings, and a wish that nobody
would send paragraph text.  I understand the former, but I think it's
outweighed by the practical disadvantage of text/paragraph, at least for
now.  As for the latter, I just don't agree.

Date: Fri, 13 Mar 1998 14:11:20 -0600
To: Ned Freed <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: Laurence Lundblade <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

On 3/13/98 at 10:59 AM -0600, Ned Freed wrote:

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

Are you saying that a compliant display is only one that chops off lines
that are greater than it's maximum screen real estate if it is less than 80
columns? I thought you denied that some time ago.

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

Unless I misunderstand what you are saying, I don't object to wrap=yes nor
the requirement that senders must be able to generate short lines. What do
you think I'm objecting to?

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Fri, 13 Mar 1998 14:07:57 -0600
To: Ned Freed <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

I repeat:

We do not object to the requirement that sending text/plain with "short
lines" be the default.

If you think we have objections to that requirement, you have misunderstood us.

Period.

Date: Fri, 13 Mar 1998 11:58:48 -0800
To: Chris Newman <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: Pete Resnick <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:41 PM 3/12/98 -0800, Chris Newman wrote:
>  "Plain text with CRLF representing line
>breaks" and "plain text with CRLF representing paragraph breaks"  are
>semanticly different media types.  

This is a simple, straightforward and I believe accurate description of the
two text "models" that are under discussion.  

Text/plain is assumed to be (fully) formatted by the sender, hence the term
"lines".  
It is assumed that one line from the sender will be displayed as one line.
While it is legal for a receiver to play formatting games with the text, we
have all seen how difficult (or impossible) this can often is to make pretty.

Text/paragraph says that the sender is using CRLF very differently from
text/plain and expects the receiver to perform whatever wrapping procedures
are necessary for smooth presentation.  

It is the semantic distinction which makes the separate content-type
appropriate.  

Further, messing with text/plain by adding a parameter scares me a bit.
Text/plain is so fundamental to MIME's deployment that I believe we should
not mess with it, even if the argument in favor of a text/plain parameter
were strong, which it isn't.

d/

p.s.  The refined text that Laurence suggests looks helpful, too.
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Date: Fri, 13 Mar 1998 11:52:01 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: Steve Dorner <[email-masked]>
Cc: Ned Freed <[email-masked]>, Laurence Lundblade <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> At 10:59 AM -0600 3/13/98, Ned Freed wrote:
> >(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.)

> N O N S E N S E.  We don't object to it. Our software has, and has  A L W A
> Y S  had, an option to send wrapped text/plain that would warm the cockles
> of your little vt100-loving heart.  And it is turned on B Y   D E F A U L
> T.  So knock off the slams.

Knock off seeing slams that are not there, either implicitly or explicitly. I
never said your software was incapable of generating text/plain. I know full
well that it is.

What I said, and all I said, is that I expected Qualcomm people to object to
this requirement. And my expectations on this matter have been met quite
handily: You have objected, Pete has objected, and Lawrence has objected. If
need be I will cite chapter and verse from mail messages I've received from
each one of you to prove this point.

> > 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

> The "no line breaks necessary" wasn't written in any standard until 2046,
> and people writing software to the older spec were doing so in perfectly
> good faith, too.

So what? The fact remains that the requirement is there and in a draft
standard, one that has been out for quite some time. As I have told you several
times now, you need to deal with this fact. You cannot change it at this point.

				Ned

Date: Fri, 13 Mar 1998 13:46:52 -0600
To: Chris Newman <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

>>  * Due to (C) compatibility problem, an additional "MUST be able to
>>    generate text/plain 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).

Your text says basically "it might be significant to change software to
generate short lines".  But since you claim this is already a requirement,
no new burden is added.

So this is not a con for a wrap parameter; it's just life.

Date: Fri, 13 Mar 1998 13:38:21 -0600
To: Ned Freed <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: Laurence Lundblade <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

At 10:59 AM -0600 3/13/98, Ned Freed wrote:
>(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.)

N O N S E N S E.  We don't object to it. Our software has, and has  A L W A
Y S  had, an option to send wrapped text/plain that would warm the cockles
of your little vt100-loving heart.  And it is turned on B Y   D E F A U L
T.  So knock off the slams.

>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

The "no line breaks necessary" wasn't written in any standard until 2046,
and people writing software to the older spec were doing so in perfectly
good faith, too.

Date: Fri, 13 Mar 1998 12:59:34 -0600
To: Chris Newman <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

On 3/12/98 at 11:41 PM -0600, Chris Newman wrote:

>On Thu, 12 Mar 1998, Pete Resnick wrote:
>> 3) Create a new Content-Disposition for "display-wrap".
>>
>> This has the advantage of indicating the wrapping or non-wrapping desires
>> of the sender, but doesn't dork with the definition of text/plain.
>
>I find this option unacceptable.  "Plain text with CRLF representing line
>breaks" and "plain text with CRLF representing paragraph breaks"  are
>semanticly different media types.  The operation of line wrapping
>demonstrates this because it often damages the former and never damages
>the latter.  In addition, the former works fine with ascii art and tables
>while the latter may not work.

I don't understand how this differs in kind from a wrap=yes parameter to
text/plain. Why is that acceptable and this not? Remember, line breaks are
perfectly acceptable (according to 2046) to be inserted for display
purposes whereever the receiver finds them useful, though for text/plain it
claims that you shouldn't need to do that (obviously PDA's being the
canonical example). How to handle display of media types is not discussed
in 2046, nor should it be (e.g., text in Braille or speech, images in color
or on paper, etc.). That's why Content-Disposition seems like an OK place
to deal with this; it describes the intended handling of the content of
this MIME body part. Like inline gives a hint of how to display it, so does
wrap.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Fri, 13 Mar 1998 08:59:49 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: Laurence Lundblade <[email-masked]>
Cc: Chris Newman <[email-masked]>, [email-masked]
Sender: [email-masked]

> > 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

Date: Thu, 12 Mar 1998 23:02:26 -0800 (PST)
From: Laurence Lundblade <[email-masked]>
To: Chris Newman <[email-masked]>
cc: [email-masked]
Subject: Re: text/paragraph or wrap=yes/no 
Sender: [email-masked]

On 12 Mar 1998, Chris Newman wrote:

> Date: 12 Mar 1998 12:46:37 0800
> From: Chris Newman <[email-masked]>
> To: [email-masked]
> 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

Date: Thu, 12 Mar 1998 21:41:13 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 12 Mar 1998, Pete Resnick wrote:
> 3) Create a new Content-Disposition for "display-wrap".
> 
> This has the advantage of indicating the wrapping or non-wrapping desires
> of the sender, but doesn't dork with the definition of text/plain.

I find this option unacceptable.  "Plain text with CRLF representing line
breaks" and "plain text with CRLF representing paragraph breaks"  are
semanticly different media types.  The operation of line wrapping
demonstrates this because it often damages the former and never damages
the latter.  In addition, the former works fine with ascii art and tables
while the latter may not work.

		- Chris

Date: Thu, 12 Mar 1998 21:05:15 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Thu, 12 Mar 1998, Steve Dorner wrote:
> Why add this requirement to wrap=yes but not to text/paragraph?  Seems like
> it makes every bit as much sense to say:
> 
>  * Due to (C) compatibility problem, an additional "MUST be able to
>    generate text/plain 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).

Because text/paragraph is backwards compatible for all compliant MIME
agents -- it's a new media type which meets all the requirements of a MIME
text media type.  The only new compatibility issue is that text/paragraph
is not compatible with pre-MIME agents, but there is already a requirement
in RFC 2049 specifically to address that issue -- namely a MIME MUA must
be able to generate text/plain.  Thus text/paragraph needs no new
backwards compatibility rules (although it wouldn't hurt to reiterate the
rule from RFC 2049 and explain its purpose).

The problem with adding a parameter to text/plain is that you are making
an incompatible amendement to the MIME spec which can break compliant MIME
agents (unlike text/paragraph).  Thus from a procedure point of view, the
new compatibility rules are required.

As I said, I consider either change an improvement to the status quo, so
I'll go along with either.

		- Chris

Date: Thu, 12 Mar 1998 20:10:45 -0600
To: "Larry Osterman (Exchange)" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: text/paragraph or wrap=yes/no
Cc: "'Chris Newman'" <[email-masked]>, [email-masked]
Sender: [email-masked]

On 3/12/98 at 4:37 PM -0600, Larry Osterman (Exchange) wrote:

>My personal problem with #2 is that it breaks open text/plain, even if only
>a little bit (sort-of like being a little bit pregnant?).

I don't know what you mean by "breaks open". The fact is that people are
now sending stuff that they intend to be wrapped by the recipient as
text/plain. All that adding the parameter does is to indicate "yes, I
really want it wrapped". It doesn't break anything.

However, even if you do think there is a concern here, that's why I did
mention a third possible alternative:

3) Create a new Content-Disposition for "display-wrap".

This has the advantage of indicating the wrapping or non-wrapping desires
of the sender, but doesn't dork with the definition of text/plain.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Thu, 12 Mar 1998 17:04:59 -0800 (PST)
From: John Mani <[email-masked]>
Reply-To: John Mani <[email-masked]>
Subject: MIME torture test
To: [email-masked]
Sender: [email-masked]

Anyone know where I can get the mime-torture test mailbox from ? Its a mailbox
containing a single message that has multiple, deeply nested bodyparts.

thanx
-john

Date: Thu, 12 Mar 1998 17:15:24 -0600
To: Chris Newman <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: text/paragraph or wrap=yes/no
Cc: [email-masked]
Sender: [email-masked]

At 2:46 PM -0600 3/12/98, Chris Newman wrote:
>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).

Why add this requirement to wrap=yes but not to text/paragraph?  Seems like
it makes every bit as much sense to say:

 * Due to (C) compatibility problem, an additional "MUST be able to
   generate text/plain 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).

From: "Larry Osterman (Exchange)" <[email-masked]>
To: "'Chris Newman'" <[email-masked]>, [email-masked]
Subject: RE: text/paragraph or wrap=yes/no
Date: Thu, 12 Mar 1998 14:37:28 -0800
Sender: [email-masked]

My personal problem with #2 is that it breaks open text/plain, even if only
a little bit (sort-of like being a little bit pregnant?).

And I'm not sure that it is possible to word the MUST/SHOULD exception in
such a way as to allow generation of long lines (which is currently
conforming behavior) but prohibiting the generation of long lines that look
like paragraphs - that would be a tricky bit of wordsmithing.

-----Original Message-----
From: Chris Newman [mailto:[email-masked]]
Sent: Thursday, March 12, 1998 12:47 PM
To: [email-masked]
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.

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

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:

(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 think either (1) or (2) is a significant improvement to the status quo,
so I'll go along with either.

		- Chris

Date: Thu, 12 Mar 1998 12:46:37 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: text/paragraph or wrap=yes/no
To: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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.

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

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:

(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 think either (1) or (2) is a significant improvement to the status quo,
so I'll go along with either.

		- Chris

Date: Wed, 11 Mar 1998 17:47:47 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: RE: overdefining text/plain?
Sender: [email-masked]

At 4:41 PM -0600 3/11/98, Dan Kohn wrote:
>If you want to send RTF that is not meant for interpreted display (in
>order to get the new-line cononicalization and charset definition), why
>not use text/rtf with "Content-Disposition: attachment"?

a) Content-disposition is advisory only; mailers are free to ignore it.

b) Part of the definition of the text type is that it be useful to display
to humans without interpretation.  The fact that the user has to take an
extra step to display it doesn't make this any more true than it was when
the display was immediately inline.

The right way to send "hairy" rtf would be something like application/rtf
(assuming it existed).  Goodness only knows what "hairy" means, of course.

From: Dan Kohn <[email-masked]>
To: Steve Dorner <[email-masked]>, [email-masked]
Subject: RE: overdefining text/plain?
Date: Wed, 11 Mar 1998 14:41:57 -0800
Sender: [email-masked]

If you want to send RTF that is not meant for interpreted display (in
order to get the new-line cononicalization and charset definition), why
not use text/rtf with "Content-Disposition: attachment"?

		- dan

> -----Original Message-----
> From:	Steve Dorner 
> Sent:	Wednesday, March 11, 1998 1:17 PM
> To:	[email-masked]
> Subject:	Re: overdefining text/plain?
> 
> >Ned, perhaps you could comment on whether you feel text/rtf and
> >text/vnd.in3d.3dml are (1) actual valid registered subtypes of "text"
> 
> Well, I'm not Ned, but I have an opinion.
> 
> Is it possible to write rtf that can be read by ordinary humans
> without
> harm?  Then text/rtf is ok.  It does NOT follow that all rtf should go
> as
> text/rtf; "hairy" rtf should probably go as application/rtf or
> something.
> I doubt there's a chance in hell of that happening, though.
> 
> I believe one problem is that there is no clear way to get character
> sets
> and newline canonicalization for types other than text/*.  So people
> tend
> to try to put things under text in order to get these semantics.  I've
> argued in the past for specific parameters for text-y things, and been
> told
> that was wrong.  Instead, people are supposed to note in their
> registrations of non-text types if they want any text-y semantics.  I
> think
> this is not widely understood.  Whether my parameter would be
> convenient
> enough for people to specify that they wouldn't try to "cheat" by
> using
> text/* is debatable, of course.
> 
> Anyway, I think it was probably an error to register those types under
> text.  Doesn't mean we should throw out the rule, just means we should
> unregister the types (which I believe is procedurally difficult,
> but...).
> 
> >The actual semantics in
> >use, however, seems to be that any data which is represented in a
> >textual format, regardless of whether that representation was meant
> for
> >humans or machines, is a subtype of "text".
> 
> There are also textual representations registered under other
> top-level
> types (eg, application/mac-binhex40).  So some people got it right.
> Maybe
> it can be fixed.  Or maybe it's as useless as the number after
> Mime-Version...

Date: Wed, 11 Mar 1998 15:16:48 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

>Ned, perhaps you could comment on whether you feel text/rtf and
>text/vnd.in3d.3dml are (1) actual valid registered subtypes of "text"

Well, I'm not Ned, but I have an opinion.

Is it possible to write rtf that can be read by ordinary humans without
harm?  Then text/rtf is ok.  It does NOT follow that all rtf should go as
text/rtf; "hairy" rtf should probably go as application/rtf or something.
I doubt there's a chance in hell of that happening, though.

I believe one problem is that there is no clear way to get character sets
and newline canonicalization for types other than text/*.  So people tend
to try to put things under text in order to get these semantics.  I've
argued in the past for specific parameters for text-y things, and been told
that was wrong.  Instead, people are supposed to note in their
registrations of non-text types if they want any text-y semantics.  I think
this is not widely understood.  Whether my parameter would be convenient
enough for people to specify that they wouldn't try to "cheat" by using
text/* is debatable, of course.

Anyway, I think it was probably an error to register those types under
text.  Doesn't mean we should throw out the rule, just means we should
unregister the types (which I believe is procedurally difficult, but...).

>The actual semantics in
>use, however, seems to be that any data which is represented in a
>textual format, regardless of whether that representation was meant for
>humans or machines, is a subtype of "text".

There are also textual representations registered under other top-level
types (eg, application/mac-binhex40).  So some people got it right. Maybe
it can be fixed.  Or maybe it's as useless as the number after
Mime-Version...

Date: Wed, 11 Mar 1998 12:19:45 PST
From: Bill Janssen <[email-masked]>
To: Bill Janssen <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
CC: Bill Janssen <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

Excerpts from direct: 10-Mar-98 Re: overdefining text/plain? Ned
[email-masked] (965*)

> And as I said before, I disagree with this assessment. I also think you have
> not come even close to demonstrating that this is a good change to make.

Well, maybe I'm suggesting the wrong change.

Ned, perhaps you could comment on whether you feel text/rtf and
text/vnd.in3d.3dml are (1) actual valid registered subtypes of "text"
(maybe they're not and I'm just confused by their presence in
http://www.isi.edu/in-notes/iana/assignments/media-types/text/), and (2)
ignoring for the moment what the RFC specifies, whether it is good
user-interface design to display values of these types as "text/plain",
charset "US-ASCII".  In my opinion, the answers are "yes", and "no",
which in my mind points to a deficiency in the system somewhere.

The problem seems to be in the semantics of "text".  My (fallible)
understanding of the desired semantics is that all subtypes of text are
more-or-less directly presentable to the user; that is, they are all
more or less plain-text, and additional markup or other information that
can't be interpreted by the MUA can either be understood by the user as
text, or is not a significant enough part of the information so that if
discarded, the message will be misunderstood.  The actual semantics in
use, however, seems to be that any data which is represented in a
textual format, regardless of whether that representation was meant for
humans or machines, is a subtype of "text".

Bill

Date: Wed, 11 Mar 1998 11:09:32 -0600
To: Ned Freed <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: overdefining text/plain?
Cc: Ned Freed <[email-masked]>, Steve Dorner <[email-masked]>, [email-masked]
Sender: [email-masked]

It seems to me we're pretty close to agreement here with two minor
exceptions, and those seem to simply be a lack of understanding on my part.

On 3/11/98 at 10:19 AM -0600, Ned Freed wrote:

>> The only thing that these documents say is that
>> text/plain should be able to be displayed "uninterpreted", presumably
>> differentiating it from text/enriched and the like in that you don't have
>> to interpret the characters inside text/plain as meaning something other
>> than "character". So, text/plain is defining an interpretation semantics,
>> but not a display semantics per se.
>
>Read the documents again. This is not all they say.

Well, I have read them many times, but I went back and read them again.
Searching for all occurences of the word "text" in 2049, I find no section
refering to text/plain which discuss display semantics.

2046 is a little more interesting. The sections in question are the top of
4.1, 4.1.1, and 4.1.3. In none of these can I find display semantics for
text/plain other than 'Plain text is intended to be displayed "as-is", that
is, no interpretation of embedded formatting commands, font attribute
specifications, processing instructions, interpretation directives, or
content markup should be necessary for proper display.' But that simply
says that text/plain does *not* need further interpretation of its content
for display. It certainly doesn't say how it ought to be displayed, e.g.,
whether to render it in braille or in some color on a CRT or where to put
line breaks. It's simply silent on the issue.

Is there something I'm missing?

>What worries me about the parameter approach is that its too easy...

Why is this a problem?

>...and the restraints a document
>specifying it will require are likely not to be acceptable to the people who
>want to send around paragraph text.

Such as? I don't see what constraints will be objected to.

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Wed, 11 Mar 1998 10:58:43 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

At 10:19 AM -0600 3/11/98, Ned Freed wrote:
>specifying it will require are likely not to be acceptable to the people who
>want to send around paragraph text.

Why?  If I am willing that my text be wrapped to the recipient's
convenience, I add the parameter.  If I think I know best where line breaks
should occur, I don't.  In the latter case, I take my lumps when some
systems display the text strangely; but given that it's no skin off my nose
to add the parameter, so what?

Doesn't seem bad to me at all.

Date: Wed, 11 Mar 1998 10:45:41 -0600
To: <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: Summary (This is text/paragraph - how does it look?)
Sender: [email-masked]

At 9:33 AM -0600 3/11/98, Michael A Quinlan wrote:
>Ned Freed seems to be claiming that, of the programs listed below, only
>Netscape works correctly (because the others wrapped the lines).
>
>Is this correct?

No.  The standard says "it should not be necessary" to wrap the text.  It
does not say that wrapping the text is forbidden.  So according to 2046
you're *allowed* to wrap text you receive, but not to *send* text that some
(unspecified) device must wrap to display.

Date: Wed, 11 Mar 1998 10:49:08 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: RE: overdefining text/plain?
Sender: [email-masked]

At 1:08 AM -0600 3/11/98, Ned Freed wrote:
>> P.S.  I am probably missing someting obvious, but I don't see "interpret
>> unrecognized subtypes of text/ as text/plain"
>
>Well, for one thing, it's implicit in the first conformance requirement for
>text when the charset is US-ASCII:
>
>  -- Recognize and display "text" mail with the charset "US-ASCII."
>
>This doesn't say anything about the subtype being "plain".

And I hope you don't amend it to say so.  The semantics you've given
text/plain are that no interpretation and wrapping should be "necessary".
I think people will be likely to read that as "no interpretation and
wrapping is 'permitted'," and do stupid things like add huge scroll bars if
they see (eg) text/paragraph.

I really like the nonspecific "display" in that context.

Date: Wed, 11 Mar 1998 08:40:58 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Summary (This is text/paragraph - how does it look?)
To: Michael A Quinlan <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Ned Freed seems to be claiming that, of the programs listed below, only
> Netscape works correctly (because the others wrapped the lines).

> Is this correct?

Completely incorrect. It is perfectly acceptable for a _display_ agent to wrap
lines of text/plain to fit a display. What's unacceptable is for such an agent
to actively modify and thereby damage the message, which is what happens all
too often in practice.

				Ned

Date: Wed, 11 Mar 1998 08:38:43 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Michael A Quinlan <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > Well, for one thing, it's implicit in the first conformance requirement for
> > text when the charset is US-ASCII:
> >
> >  -- Recognize and display "text" mail with the charset "US-ASCII."
> >
> >This doesn't say anything about the subtype being "plain".
> >
> >But then there's an explicit conformance requirement covering this case:
> >
> >  -- For unrecognized subtypes in a known charset, show or offer to show
> >  the user the "raw" version of the data after conversion of the content
> from
> >  canonical form to local form.

> How does converting the text/paragraph entity to an attachment violate
> either of these constraints?

It doesn't. But that's not the issue at hand -- the issue was whether or not
agents are allowed to not have any display option for such material at all.
They aren't. If they also want to have an option to treat it as an attachment
that's fine, and if they want to make treat as attachment the default that's
fine. But it cannot be the only option.

				Ned

Date: Wed, 11 Mar 1998 08:19:07 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Pete Resnick <[email-masked]>
Cc: Ned Freed <[email-masked]>, Steve Dorner <[email-masked]>, [email-masked]
Sender: [email-masked]

> > I am. I run into them on a daily basis in the customer support work I do.

> The document <draft-newman-mime-textpara-00.txt> says this as well, but
> like you without explanation. What are the compatibility problems here?
> That some MUAs use a horizontal scrollbar when long lines occur? That some
> MUAs are unable to display long lines? What exactly is the problem?

I believe I've described this several times already, but anyway...

The main problem I see is a second order one. People send around mail with long
lines intending for the lines to be treated as paragraphs. This works quite
poorly on a large number of existing mail clients. So people proceed to "fix"
these clients by adding facilities to perform line wrapping.

But they don't do it right. Instead of adding this as a display-time option
they add it as a facility that actually reformats messages. Sometimes this is
because they're incompetent, but more often than not it is because they don't
have access to the display machinery and must instead do this processing at
some other point in the message handling process.

Regardless, the end result is that these facilities end up getting applied to
messages that contain structured material -- tables, ASCII art, configuration
files, you name it. And the result is useless trash.

This is a widespread problem. We see it cropping up in a wide variety of
widely used products.

This malaise also has a funny way of hitting very highly placed people in
companies. I don't know why exactly -- perhaps its because these people
tend to send around more tabular information or something, or perhaps its
simply because the complaints of regular users are simply ignored by
technical staff. But the end result is that we have it thrown in our
face on a regular basis with quite a bit of force.

We also suffer from this ourselves, since we often send around configuration
files and the like through email as part of tech support. However, while it is
easy to get someone technical to resend a text file as a binary attachment,
this approach is a nonstarter when you're talking about a corporate VP.

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

> I'm not totally sure I know what the above opposition refers to, so let me
> weed this one out:

> Are you opposed to a parameter to text/plain that means "I intend for these
> long lines to be displayed wrapped"? Are you opposed to perhaps a
> Content-Disposition that says "inline; wrapped"?

Neither of these have anything to do with the solution the quoted paragraph
above proposes. And so I'm not opposed to either of them, at least not
totally. (I do think they're both nonstarters but for other reasons.)

My opposition was and is to the idea of creating a new text/tty type to capture
the semantics text/plain is supposed to have. I am opposed to this because it
violates a fundamental IETF rule -- we don't declare existing, standardized
practice to be invalid.

> There is nothing I can find in 2046 or 2049 which entails that text/plain
> SHOULD NOT or MUST NOT be wrapped for display; in fact, that requirement
> would be silly on devices which can fit substantially less than 72 columns
> of text on the screen.

Of course there is no such requirement. However, there is a requirement that
that text/plain should be constructed so that this is not necessary.

> The only thing that these documents say is that
> text/plain should be able to be displayed "uninterpreted", presumably
> differentiating it from text/enriched and the like in that you don't have
> to interpret the characters inside text/plain as meaning something other
> than "character". So, text/plain is defining an interpretation semantics,
> but not a display semantics per se.

Read the documents again. This is not all they say.

> It seems to me that the only problem with the "long line as paragraph"
> people is that they are *assuming* a display semantics of "wrap these lines
> to display width" which is unreasonable to assume; text/plain does not
> provide any display semantics for long lines one way or the other. Adding a
> parameter to text/plain indicating display semantics seems much more
> coherent than creating a new Content-Type which normally implies a new
> *interpretation* semantics.

This is only the first order problem; by itself it worries not appreciably more
than, say, the adoption and use of quoted-printable as an alternative to 8bit
SMTP. (Which is to say I don't ignore it, but I don't let it get me into a huge
snit either.)

I take issue, however, with the second order problems we _know_ this usage
causes. These cannot be fixed by simply upgrading display agents. Once
carefully formatted plain text is wrecked it is wrecked, and no amount of
automatic processing will fix it.

My primary goal in wanting to add some means of labelling paragraph text is so
that these sorts of effects can be contained. And any sort of labelling will
solve this problem -- some may bring up the old "some agents can't switch on
the basis of parameters but can on subtype so let's use subtype" line of
reasoning, but even that doesn't worry me all that much. What worries me about
the parameter approach is that its too easy and the restraints a document
specifying it will require are likely not to be acceptable to the people who
want to send around paragraph text.

				Ned

Reply-To: "Michael A Quinlan" <[email-masked]>
From: "Michael A Quinlan" <[email-masked]>
To: <[email-masked]>
Subject: Re: Summary (This is text/paragraph - how does it look?) 
Date: Wed, 11 Mar 1998 08:33:05 -0700
Sender: [email-masked]

Ned Freed seems to be claiming that, of the programs listed below, only
Netscape works correctly (because the others wrapped the lines).

Is this correct?

-----Original Message-----
From: Laurence Lundblade <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 10, 1998 10:02 PM
Subject: Summary (This is text/paragraph - how does it look?)

>Eudora          - Yes
>Pine            - Yes
>Notes           - Yes
>AOL             - Yes
>Outlook 98      - Yes
>Andrew          - conflicting reports: yes and attachment
>Netscape        - big horizontal scroll bar
>ZMail           - attachment
>WhoWhere        - attachment
>Simeon          - attachment
>Outlook Express - attachment
>
>LL
>

Reply-To: "Michael A Quinlan" <[email-masked]>
From: "Michael A Quinlan" <[email-masked]>
To: <[email-masked]>
Subject: Re: overdefining text/plain?
Date: Wed, 11 Mar 1998 08:29:37 -0700
Sender: [email-masked]

Outlook and Outlook Express are two different programs. FYI.

-----Original Message-----
From: Dan Kohn <[email-masked]>
To: Ned Freed <[email-masked]>; Bill Janssen
<[email-masked]>
Cc: [email-masked] <[email-masked]>; Chris Newman
<[email-masked]>; Paul Hoffman <[email-masked]>
Date: Tuesday, March 10, 1998 10:02 PM
Subject: RE: overdefining text/plain?

>1) Outlook working with Exchange Server 5.0 (which converts the MIME
>type to proprietary gunk in the MTA), correctly displayed text/paragraph
>as text/plain.  Thus, Outlook's error with direct Internet access (for
>which it decodes MIME itself) appears to be an inconsistency rather than
>a direct design decision by Microsoft to go against the standard.

Reply-To: "Michael A Quinlan" <[email-masked]>
From: "Michael A Quinlan" <[email-masked]>
To: <[email-masked]>
Subject: Re: overdefining text/plain?
Date: Wed, 11 Mar 1998 08:21:15 -0700
Sender: [email-masked]

From: Ned Freed <[email-masked]>
To: Dan Kohn <[email-masked]>
Cc: Ned Freed <[email-masked]>; Bill Janssen
<[email-masked]>; [email-masked] <[email-masked]>; Chris Newman
<[email-masked]>; Paul Hoffman <[email-masked]>
Date: Wednesday, March 11, 1998 12:25 AM
Subject: RE: overdefining text/plain?

>Well, for one thing, it's implicit in the first conformance requirement for
>text when the charset is US-ASCII:
>
>  -- Recognize and display "text" mail with the charset "US-ASCII."
>
>This doesn't say anything about the subtype being "plain".
>
>But then there's an explicit conformance requirement covering this case:
>
>  -- For unrecognized subtypes in a known charset, show or offer to show
>  the user the "raw" version of the data after conversion of the content
from
>  canonical form to local form.

How does converting the text/paragraph entity to an attachment violate
either of these constraints?

Date: Wed, 11 Mar 1998 09:15:42 -0600
To: Ned Freed <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: overdefining text/plain?
Cc: Steve Dorner <[email-masked]>, [email-masked]
Sender: [email-masked]

Ned, I'd like clarification on two points.

On 3/10/98 at 10:53 AM -0600, Ned Freed wrote:

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

The document <draft-newman-mime-textpara-00.txt> says this as well, but
like you without explanation. What are the compatibility problems here?
That some MUAs use a horizontal scrollbar when long lines occur? That some
MUAs are unable to display long lines? What exactly is the problem?

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

I'm not totally sure I know what the above opposition refers to, so let me
weed this one out:

Are you opposed to a parameter to text/plain that means "I intend for these
long lines to be displayed wrapped"? Are you opposed to perhaps a
Content-Disposition that says "inline; wrapped"?

There is nothing I can find in 2046 or 2049 which entails that text/plain
SHOULD NOT or MUST NOT be wrapped for display; in fact, that requirement
would be silly on devices which can fit substantially less than 72 columns
of text on the screen. The only thing that these documents say is that
text/plain should be able to be displayed "uninterpreted", presumably
differentiating it from text/enriched and the like in that you don't have
to interpret the characters inside text/plain as meaning something other
than "character". So, text/plain is defining an interpretation semantics,
but not a display semantics per se.

It seems to me that the only problem with the "long line as paragraph"
people is that they are *assuming* a display semantics of "wrap these lines
to display width" which is unreasonable to assume; text/plain does not
provide any display semantics for long lines one way or the other. Adding a
parameter to text/plain indicating display semantics seems much more
coherent than creating a new Content-Type which normally implies a new
*interpretation* semantics.

Any problems with this?

pr
--
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

Date: Wed, 11 Mar 1998 08:58:59 GMT
From: ruth moulton <[email-masked]>
To: [email-masked]
Subject: Re: This is text/paragraph - how does it look?
Cc: [email-masked]
Disposition-notification-to: [email-masked]
Sender: [email-masked]

XEmacs's ( version 19.15) VM tool displayed it ok too - it wraps long lines and
shows where they have been wrapped with a <return> symbol 

Ruth

-- 
================================================
Ruth Moulton            [email-masked]
Consultant              

65 Tetherdown, 
London N.10 1NH, UK     Tel:+44 181 883 5823

-- 

To: Keith Moore <[email-masked]>
cc: Paul Hoffman / IMC <[email-masked]>, Chris Newman <[email-masked]>, [email-masked]
Subject: Re: overdefining text/plain? 
Organisation: SURFnet ExpertiseCentrum bv
Address: Radboudburcht, P.O. Box 19115, 3501 DC Utrecht, NL
Phone: +31 302 305 305
Telefax: +31 302 305 329
Date: Wed, 11 Mar 1998 10:05:14 +0100
From: Erik Huizer <[email-masked]>
Sender: [email-masked]

We did that (at least most of it) long ago. Read 1844. The test-results 
are still coming in and still available on the URL mentioned in 1844.

Erik

==> From: Keith Moore

> Why doesn't somebody set up a web page of MIME test cases,
> similar to the web page of content-types?
> 
> You type in your email address, and select from a list of test cases.
> For each test case you select, the web server sends you two email
> messages - one which is the test case itself, and another which
> describes what the results should look like.  (or you put the results
> description on a web page).
> 
> People should be able to submit test cases to the server; others could
> comment on whether those cases were bogus or not.  This part could be
> implemented as a moderated mailing list with a web-accessible threaded
> archive -- the convention being that each test case has a new subject.
> 
> Seems a lot cheaper than a bake-off.
> 
> Keith
> 
> 
> 

To: Paul Hoffman / IMC <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: overdefining text/plain? 
Organisation: SURFnet ExpertiseCentrum bv
Address: Radboudburcht, P.O. Box 19115, 3501 DC Utrecht, NL
Phone: +31 302 305 305
Telefax: +31 302 305 329
Date: Wed, 11 Mar 1998 09:43:22 +0100
From: Erik Huizer <[email-masked]>
Sender: [email-masked]

==> From: Paul Hoffman / IMC

> If others on this list think the test is a good idea, I can go ahead with
> it and with a list for people to list tests. BTW, don't forget to look at
> RFC 1844.

Yeah that one badly needs updating. I am afraid I won't have time for 
that for another few months at least. Maybe over summer.

Erik

Date: Tue, 10 Mar 1998 23:08:39 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: overdefining text/plain?
To: Dan Kohn <[email-masked]>
Cc: Ned Freed <[email-masked]>, Bill Janssen <[email-masked]>, [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

> 1) Outlook working with Exchange Server 5.0 (which converts the MIME
> type to proprietary gunk in the MTA), correctly displayed text/paragraph
> as text/plain.  Thus, Outlook's error with direct Internet access (for
> which it decodes MIME itself) appears to be an inconsistency rather than
> a direct design decision by Microsoft to go against the standard.

Interesting -- that's the exact opposite of what I would have predicted. Just
goes to show the essential foolishness of trying to predict the behavior of
other people's code...

> 2) Let's not lose sight of the natural split inherent in text/* vs.
> application/*.  The text/directory effort, for instance, was debating
> last year the crux of the issue, which is whether uniterpreted
> information should be displayed to the user or made available to save
> (e.g., octet-stream).  We can argue over any specific subtype, like
> text/html, but the dichotomy clearly makes sense and is an integral
> feature of MIME.  Conformance to this dichotomy is essential to
> continued growth of MIME , as shown in this situation.

Hear hear!

> 3) I would like to heartily second Paul's idea for a MIME conformance
> program.  I think the MIME conformance statement in RFC 2049 is an
> important direction in Internet standards.  What is now needed is for an
> independent and trusted third-party to start conformance testing.

Complete agreement here as well.

> P.S.  I am probably missing someting obvious, but I don't see "interpret
> unrecognized subtypes of text/ as text/plain" in the 10 conformance
> requirements of RFC 2049.  This would seem worthwhile to add as MIME
> moves to Standard.  When is that, BTW?

Well, for one thing, it's implicit in the first conformance requirement for
text when the charset is US-ASCII:

  -- Recognize and display "text" mail with the charset "US-ASCII."

This doesn't say anything about the subtype being "plain".

But then there's an explicit conformance requirement covering this case:

  -- For unrecognized subtypes in a known charset, show or offer to show
  the user the "raw" version of the data after conversion of the content from
  canonical form to local form.

Note that you are allowed to make display conditional on user acceptance.

				Ned

Date: Tue, 10 Mar 1998 22:54:54 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: text/paragraph summary
To: Laurence Lundblade <[email-masked]>
Cc: Rick Troth <[email-masked]>, [email-masked]
Sender: [email-masked]

> What we're really talking about here is a text format that works well in
> text controls, widgets, and gadgets on modern OS's.  In these controls a
> line break means "display the next character at the left margin (right for
> semetic languages)."  It also means "wrap the text between line break to
> fit the display window".  I think we must be explicit about these
> characteristics for the definition of text/paragraph.  I don't find the
> term "paragraph" very concise.

That's fine. I have no problem with refining the specification of
text/paragraph, provided it doesn't turn into text/enriched. As I said before,
we know this dog doesn't hunt.

> The text/paragraph draft says it can be converted to text/plain by
> wrapping at 72 columns.  Seems you at least have to same "for example, by
> wrapping at 72 columns" as 72 columns or any number of columns is not
> specified by text/plain.  Otherwise the draft is also adding definition to
> text/plain.

I agree. Actually I think this should be removed. The notion that mechanical
conversion to text/plain is acceptable begs the question of why we're
even bothering with text/paragraph.

> So I'm going to stick my neck out here a bit and suggest that the two
> characteristics of text/paragraph I'm suggesting above are not clearly in
> violation of the text/plain definition. At least I can't see it at the
> moment. The meaning of text/plain I get is that "line break means display
> next character at the left(right) margin" and "this is the only thing a
> line break can be used for."  Further it seems ambiguous about wrapping as
> there is no clear discussion of wrappin.  Also it refers "no special
> software required" and "as-is" as how you display the text/plain. These
> seem very ambiguous and seem to imply things display & editing devices.
> Even for the 822 days this seems ambiguous. Is it a VT100 in wrap mode or
> not in wrap mode?

Well, it seems clear enough to me:

   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

> So if we're really going to do this right, how about another draft that
> disambiguates text/plain and says lines must be shorter than 72
> characters?  That will provide a double motivation for moving to
> text/paragraph faster, no?

Sigh. This is NOT the problem and this is ABSOLUTELY NOT a solution to
anything.

Long lines in text/plain are Good Things. I and many other use them all the
time. But when I use them I intend for them to be just what they are: Long
lines. Not paragraphs that random message processing agents should see fit
to turn into garbage.

Yes, this is display oriented rather than content oriented. Yes, this implies
that the sender has to have some notion of the recipients capabilities and
intentions. Yes, this doesn't blend well with the brave new PDA world. But we
have this tiny little concept in the IETF: We try not bust existing,
standardized usage, which this is, like it or not.

				Ned

Date: Tue, 10 Mar 1998 22:38:45 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Bill Janssen <[email-masked]>
Cc: Bill Janssen <[email-masked]>, Ned Freed <[email-masked]>, [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

> Excerpts from direct: 10-Mar-98 Re: overdefining text/plain? Ned
> [email-masked] (3167*)

> > What I do think we have is evidence of something we've known from the start,
> > which is "developers often implement things incorrectly and once implemented,
> > things tend not to get fixed, even when users complain".

> Sure, a well-known problem.  My point is that the RFC is broken, and
> that a conforming MUA would not be a good one, from a CHI perspective.

And as I said before, I disagree with this assessment. I also think you have
not come even close to demonstrating that this is a good change to make. (Even
assuming I could make it at this point, which I don't believe I could.)

> Fine.  I'd still adjust the RFC to eliminate the requirement to display
> things simply because someone has registered them as a text subtype.

That's your opinion. Mine is that this is a terrible idea, and not something
within my purview as editor anyhow.

				Ned

Date: Tue, 10 Mar 1998 13:43:05 -0800 (PST)
From: Laurence Lundblade <[email-masked]>
To: Rick Troth <[email-masked]>
cc: [email-masked]
Subject: Re: text/paragraph summary 
Sender: [email-masked]

On 20 Feb 1998, Rick Troth wrote:
> 
> 	Aren't we bumping up against the  content -vs- display  problem? 
> If so,  are we trying to do what has been wrongly done with HTML?   That is, 
> to use a tool designed for content to acomodate presentation?   Let's not. 

Yes, I think so. I'm having a little trouble with meaning of the terms
"line break" and "paragraph".  To me "paragraph" implies semantic mark up
(your "content") not display mark up. 

What we're really talking about here is a text format that works well in
text controls, widgets, and gadgets on modern OS's.  In these controls a
line break means "display the next character at the left margin (right for
semetic languages)."  It also means "wrap the text between line break to
fit the display window".  I think we must be explicit about these
characteristics for the definition of text/paragraph.  I don't find the
term "paragraph" very concise. 

The text/paragraph draft says it can be converted to text/plain by
wrapping at 72 columns.  Seems you at least have to same "for example, by
wrapping at 72 columns" as 72 columns or any number of columns is not
specified by text/plain.  Otherwise the draft is also adding definition to
text/plain. 

So I'm going to stick my neck out here a bit and suggest that the two
characteristics of text/paragraph I'm suggesting above are not clearly in
violation of the text/plain definition. At least I can't see it at the
moment. The meaning of text/plain I get is that "line break means display
next character at the left(right) margin" and "this is the only thing a
line break can be used for."  Further it seems ambiguous about wrapping as
there is no clear discussion of wrappin.  Also it refers "no special
software required" and "as-is" as how you display the text/plain. These
seem very ambiguous and seem to imply things display & editing devices.
Even for the 822 days this seems ambiguous. Is it a VT100 in wrap mode or
not in wrap mode? 

So if we're really going to do this right, how about another draft that
disambiguates text/plain and says lines must be shorter than 72
characters?  That will provide a double motivation for moving to
text/paragraph faster, no? 

LL

Date: Tue, 10 Mar 1998 12:23:27 -0800 (PST)
From: Laurence Lundblade <[email-masked]>
To: [email-masked]
Subject: Summary (This is text/paragraph - how does it look?) 
Sender: [email-masked]

Eudora          - Yes
Pine            - Yes
Notes           - Yes
AOL             - Yes
Outlook 98      - Yes
Andrew          - conflicting reports: yes and attachment
Netscape        - big horizontal scroll bar
ZMail           - attachment
WhoWhere        - attachment
Simeon          - attachment
Outlook Express - attachment

LL

From: Dan Kohn <[email-masked]>
To: Ned Freed <[email-masked]>, Bill Janssen <[email-masked]>
Cc: [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: RE: overdefining text/plain?
Date: Tue, 10 Mar 1998 20:32:49 -0800
Sender: [email-masked]

1) Outlook working with Exchange Server 5.0 (which converts the MIME
type to proprietary gunk in the MTA), correctly displayed text/paragraph
as text/plain.  Thus, Outlook's error with direct Internet access (for
which it decodes MIME itself) appears to be an inconsistency rather than
a direct design decision by Microsoft to go against the standard.

2) Let's not lose sight of the natural split inherent in text/* vs.
application/*.  The text/directory effort, for instance, was debating
last year the crux of the issue, which is whether uniterpreted
information should be displayed to the user or made available to save
(e.g., octet-stream).  We can argue over any specific subtype, like
text/html, but the dichotomy clearly makes sense and is an integral
feature of MIME.  Conformance to this dichotomy is essential to
continued growth of MIME , as shown in this situation.

3) I would like to heartily second Paul's idea for a MIME conformance
program.  I think the MIME conformance statement in RFC 2049 is an
important direction in Internet standards.  What is now needed is for an
independent and trusted third-party to start conformance testing.

		- dan

P.S.  I am probably missing someting obvious, but I don't see "interpret
unrecognized subtypes of text/ as text/plain" in the 10 conformance
requirements of RFC 2049.  This would seem worthwhile to add as MIME
moves to Standard.  When is that, BTW?

> -----Original Message-----
> From:	Ned Freed 
> Sent:	Tuesday, March 10, 1998 3:09 PM
> To:	Bill Janssen
> Cc:	[email-masked]; Chris Newman; Paul Hoffman
> Subject:	Re: overdefining text/plain?
> 
> > > The rule which
> > > requires MIME MUAs to treat unrecognized subtypes of text as
> "text/plain"
> > > is documented in both RFC 2046 and RFC 2049.  The fact that three
> MIME
> > > MUAs failed one of the most basic MIME requirements is
> unacceptable.
> 
> > Isn't the problem here really that (1) customer demand trumps
> standards,
> > and (2) as Laurence pointed out, some folks are registering (and
> using!)
> > invalid subtypes of "text", like "text/html", "text/sgml", and
> > "text/rtf"?  MUA vendors don't want to put gibberish up on their
> > customer's screens, and there are registered subtypes of "text"
> which
> > look like gibberish to normal users when presented directly, so the
> only
> > sensible MUA rule for commercial vendors is to censor anything they
> > don't know to be correctly presentable.
> 
> Perhaps, but the data from this survey doesn't support this
> conclusion.
> Specifically, we have three MUAs that have problems, but only one of
> them
> (Outlook) is a relatively recent design. At least one of the other two
> (ZMailer) was designed quite some time ago, considerably before such
> problems
> were readily evident. I also suspect that even with Outlook the issue
> is less
> one of "mustn't throw up unintelligible stuff" than it is one of "how
> we map an
> open-ended set of types into our internal typing system that's based
> on file
> extensions".
> 
> There is also considerable evidence that when shoe is on the other
> foot, so to
> speak, and it is noncompliance with MIME that leads to bad displays
> full of
> garbage, this fact hasn't stopped MUAs from breaking the rules. For
> example, if
> you look at proper handling of the charset parameter, you'll find that
> many
> agents don't bother to check it even though MIME says you're supposed
> to. And
> similarly, if you look at compliance in the area of message/rfc822
> handling,
> you'll find that a fair number of agents didn't bother to do it until
> we raised
> the bar a bit. And failure to comply here often leads to screens full
> of
> base64.
> 
> What I do think we have is evidence of something we've known from the
> start,
> which is "developers often implement things incorrectly and once
> implemented,
> things tend not to get fixed, even when users complain". Scarcely a
> major
> insight, to be sure, but about the only one I think can be had from
> the data.
> 
> I also believe that text/html is actually legal and registered. The
> others
> aren't, but they are also fairly rare.
> 
> > I remember raising this point during the original MIME discussions
> (when
> > some folks were proposing text/postscript :-).  The fact is, by
> allowing
> > arbitrary registration, we remove the ability to say anything in
> general
> > about the so-called top-level media types, because people are always
> > going to misuse them.  I'd suggest just facing that fact, and
> removing
> > any RFC requirements that are supposed to apply to all instances of
> any
> > top-level type.
> 
> Actually, we do not allow arbitrary registrations and never have. The
> number of
> things that have been registered until text/ is actually quite small.
> And while
> you may argue that text/html was a mistake, it isn't like it wasn't
> discussed
> at considerable length. We have only ourselves to blame if it is a
> botch.
> 
> 				Ned

To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: overdefining text/plain? 
From: [email-masked]
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<[email-masked]>"
Date: Tue, 10 Mar 1998 22:26:21 -0500
Sender: [email-masked]

On Tue, 10 Mar 1998 21:03:48 EST, Keith Moore said:
> Why doesn't somebody set up a web page of MIME test cases,
> similar to the web page of content-types?

I'll be more than happy to do this if somebody is willing to help supply....

I'll look at cooking up basic test cases for the more tirvial things in RFC2049
when I get in ot the office tomorrow...

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

Date: Tue, 10 Mar 1998 18:41:58 PST
From: Bill Janssen <[email-masked]>
To: Bill Janssen <[email-masked]>, Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
CC: [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

Excerpts from direct: 10-Mar-98 Re: overdefining text/plain? Ned
[email-masked] (3167*)

> What I do think we have is evidence of something we've known from the start,
> which is "developers often implement things incorrectly and once implemented,
> things tend not to get fixed, even when users complain".

Sure, a well-known problem.  My point is that the RFC is broken, and
that a conforming MUA would not be a good one, from a CHI perspective.

> I also believe that text/html is actually legal and registered. The others
> aren't, but they are also fairly rare.

Hmmm.  They're (text/rtf and text/sgml) both in the IANA registry at
http://www.isi.edu/in-notes/iana/assignments/media-types/text/, along
with things like vnd.abc (a language for exchanging ``human-readable
notation for musical scores''), but I've been mistaken about media types
before.  Is there some other stamp of validation that's required?

> We have only ourselves to blame if it is a botch.

Fine.  I'd still adjust the RFC to eliminate the requirement to display
things simply because someone has registered them as a text subtype.

Bill

From: Keith Moore <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
cc: Chris Newman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: overdefining text/plain? 
Date: Tue, 10 Mar 1998 21:03:48 -0500
Sender: [email-masked]

Why doesn't somebody set up a web page of MIME test cases,
similar to the web page of content-types?

You type in your email address, and select from a list of test cases.
For each test case you select, the web server sends you two email
messages - one which is the test case itself, and another which
describes what the results should look like.  (or you put the results
description on a web page).

People should be able to submit test cases to the server; others could
comment on whether those cases were bogus or not.  This part could be
implemented as a moderated mailing list with a web-accessible threaded
archive -- the convention being that each test case has a new subject.

Seems a lot cheaper than a bake-off.

Keith

Date: Tue, 10 Mar 1998 16:29:47 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Chris Newman <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

> On Tue, 10 Mar 1998, Paul Hoffman / IMC wrote:
> > Where I do have a problem is deciding what rules to test, and what are
> > "correct" results. The ietf-822 list doesn't seem like the best place to
> > discuss this, so I propose setting up another mailing list to specify what
> > should be tested and what the acceptable/unacceptable results should be.
> >
> > If others on this list think the test is a good idea, I can go ahead with
> > it and with a list for people to list tests. BTW, don't forget to look at
> > RFC 1844.

> The non-controversial set is the conformance rules in RFC 2049 which are
> already draft standard.  Anything else (including RFC 1844) might be nice,
> but I think it would be better to start with a simpler set just to see how
> it works.

Concur.

> I also believe this is the right list to discuss it, since this list
> is the same list where MIME was developed (albeit at its former
> location).

Also concur.

				Ned

Date: Tue, 10 Mar 1998 16:01:55 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: overdefining text/plain?
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Tue, 10 Mar 1998, Paul Hoffman / IMC wrote:
> Where I do have a problem is deciding what rules to test, and what are
> "correct" results. The ietf-822 list doesn't seem like the best place to
> discuss this, so I propose setting up another mailing list to specify what
> should be tested and what the acceptable/unacceptable results should be.
> 
> If others on this list think the test is a good idea, I can go ahead with
> it and with a list for people to list tests. BTW, don't forget to look at
> RFC 1844.

The non-controversial set is the conformance rules in RFC 2049 which are
already draft standard.  Anything else (including RFC 1844) might be nice,
but I think it would be better to start with a simpler set just to see how
it works.

I also believe this is the right list to discuss it, since this list
is the same list where MIME was developed (albeit at its former
location).

		- Chris

Date: Tue, 10 Mar 1998 15:08:34 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Bill Janssen <[email-masked]>
Cc: [email-masked], Chris Newman <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

> > The rule which
> > requires MIME MUAs to treat unrecognized subtypes of text as "text/plain"
> > is documented in both RFC 2046 and RFC 2049.  The fact that three MIME
> > MUAs failed one of the most basic MIME requirements is unacceptable.

> Isn't the problem here really that (1) customer demand trumps standards,
> and (2) as Laurence pointed out, some folks are registering (and using!)
> invalid subtypes of "text", like "text/html", "text/sgml", and
> "text/rtf"?  MUA vendors don't want to put gibberish up on their
> customer's screens, and there are registered subtypes of "text" which
> look like gibberish to normal users when presented directly, so the only
> sensible MUA rule for commercial vendors is to censor anything they
> don't know to be correctly presentable.

Perhaps, but the data from this survey doesn't support this conclusion.
Specifically, we have three MUAs that have problems, but only one of them
(Outlook) is a relatively recent design. At least one of the other two
(ZMailer) was designed quite some time ago, considerably before such problems
were readily evident. I also suspect that even with Outlook the issue is less
one of "mustn't throw up unintelligible stuff" than it is one of "how we map an
open-ended set of types into our internal typing system that's based on file
extensions".

There is also considerable evidence that when shoe is on the other foot, so to
speak, and it is noncompliance with MIME that leads to bad displays full of
garbage, this fact hasn't stopped MUAs from breaking the rules. For example, if
you look at proper handling of the charset parameter, you'll find that many
agents don't bother to check it even though MIME says you're supposed to. And
similarly, if you look at compliance in the area of message/rfc822 handling,
you'll find that a fair number of agents didn't bother to do it until we raised
the bar a bit. And failure to comply here often leads to screens full of
base64.

What I do think we have is evidence of something we've known from the start,
which is "developers often implement things incorrectly and once implemented,
things tend not to get fixed, even when users complain". Scarcely a major
insight, to be sure, but about the only one I think can be had from the data.

I also believe that text/html is actually legal and registered. The others
aren't, but they are also fairly rare.

> I remember raising this point during the original MIME discussions (when
> some folks were proposing text/postscript :-).  The fact is, by allowing
> arbitrary registration, we remove the ability to say anything in general
> about the so-called top-level media types, because people are always
> going to misuse them.  I'd suggest just facing that fact, and removing
> any RFC requirements that are supposed to apply to all instances of any
> top-level type.

Actually, we do not allow arbitrary registrations and never have. The number of
things that have been registered until text/ is actually quite small. And while
you may argue that text/html was a mistake, it isn't like it wasn't discussed
at considerable length. We have only ourselves to blame if it is a botch.

				Ned

To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: overdefining text/plain? 
From: [email-masked]
Date: Tue, 10 Mar 1998 16:28:33 -0500
Sender: [email-masked]

--==_Exmh_1136740576P
Content-Type: text/plain; charset=us-ascii

On Tue, 10 Mar 1998 11:50:46 PST, you said:
> Where I do have a problem is deciding what rules to test, and what are
> "correct" results. The ietf-822 list doesn't seem like the best place to
> discuss this, so I propose setting up another mailing list to specify what

Paul:

How about this:

1) The IETF-822 list develops a MIME analog of RFC1912 (Common DNS
configuration errors).

2) IMC then does testing of various MUA/MTA to see if any given
software has a common error?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_1136740576P
Content-Type: application/pgp-signature

--==_Exmh_1136740576P--

Date: Tue, 10 Mar 1998 12:19:09 PST
From: Bill Janssen <[email-masked]>
To: [email-masked], Chris Newman <[email-masked]>
Subject: Re: overdefining text/plain?
CC: Paul Hoffman <[email-masked]>
Sender: [email-masked]

Excerpts from ext.ietf-822: 10-Mar-98 Re: overdefining text/plain? Chris
[email-masked] (848*)

> The rule which
> requires MIME MUAs to treat unrecognized subtypes of text as "text/plain"
> is documented in both RFC 2046 and RFC 2049.  The fact that three MIME
> MUAs failed one of the most basic MIME requirements is unacceptable.

Isn't the problem here really that (1) customer demand trumps standards,
and (2) as Laurence pointed out, some folks are registering (and using!)
invalid subtypes of "text", like "text/html", "text/sgml", and
"text/rtf"?  MUA vendors don't want to put gibberish up on their
customer's screens, and there are registered subtypes of "text" which
look like gibberish to normal users when presented directly, so the only
sensible MUA rule for commercial vendors is to censor anything they
don't know to be correctly presentable.

I remember raising this point during the original MIME discussions (when
some folks were proposing text/postscript :-).  The fact is, by allowing
arbitrary registration, we remove the ability to say anything in general
about the so-called top-level media types, because people are always
going to misuse them.  I'd suggest just facing that fact, and removing
any RFC requirements that are supposed to apply to all instances of any
top-level type.

Bill

Date: Tue, 10 Mar 1998 11:50:46 -0800
To: Chris Newman <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

>I'd like to see the IMC gather as many MIME MUAs as possible (regardless
>of IMC membership), test them against the MIME conformance rules in RFC
>2049 and generate an industry MIME report card listing percentage of
>conformance to each rule (without naming names).

This sounds reasonable, if not difficult. I can easily test MUAs under
MS-DOS, Win 3.1, Win 95, MacOS, and some free Intel-based Unixes, but don't
have other capabilities easily at hand. Since we're not naming names, I
don't think this is a problem.

>Vendors who failed
>conformance rules would be notified privately.

No problem there

Where I do have a problem is deciding what rules to test, and what are
"correct" results. The ietf-822 list doesn't seem like the best place to
discuss this, so I propose setting up another mailing list to specify what
should be tested and what the acceptable/unacceptable results should be.

If others on this list think the test is a good idea, I can go ahead with
it and with a list for people to list tests. BTW, don't forget to look at
RFC 1844.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 10 Mar 1998 11:20:50 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: overdefining text/plain?
To: [email-masked]
Cc: Paul Hoffman <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

The results of the text/paragraph test were abysmal.  The rule which
requires MIME MUAs to treat unrecognized subtypes of text as "text/plain"
is documented in both RFC 2046 and RFC 2049.  The fact that three MIME
MUAs failed one of the most basic MIME requirements is unacceptable.

I'd like to see the IMC gather as many MIME MUAs as possible (regardless
of IMC membership), test them against the MIME conformance rules in RFC
2049 and generate an industry MIME report card listing percentage of
conformance to each rule (without naming names).  Vendors who failed
conformance rules would be notified privately.  I would consider this an
excellent use of IMC dues money.  This might cause some of the problems to
get fixed and would certainly be helpful when considering the impact of
certain MIME extension or media type proposals.

		- Chris

Date: Tue, 10 Mar 1998 08:53:11 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: overdefining text/plain?
To: Steve Dorner <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

Date: Tue, 10 Mar 1998 10:07:48 -0600
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: overdefining text/plain?
Sender: [email-masked]

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:

     3.1.  GENERAL DESCRIPTION

          A message consists of header fields and, optionally, a body.
     The  body  is simply a sequence of lines containing ASCII charac-
     ters.  It is separated from the headers by a null line  (i.e.,  a
     line with nothing preceding the CRLF).

This says nothing about line length at all.  The only mention in 822 I can
find of lengths is:

     3.4.8.  FOLDING LONG HEADER FIELDS

        ...For readability, the
        field-body  portion of long header fields may be "folded" onto
        multiple lines of the actual field.  "Long" is commonly inter-
        preted  to  mean greater than 65 or 72 characters.  The former
        length serves as a limit, when the message is to be viewed  on
        most  simple terminals which use simple display software; how-
        ever, the limit is not imposed by this standard.

        Note:  Some display software often can selectively fold lines,
               to  suit  the display terminal.  In such cases, sender-
               provided  folding  can  interfere  with   the   display
               software.

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.

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.

So:

- Long lines in 822 were permissible, even lines that needed to be wrapped
for display.
- 2046 claims that text/plain is the same as 822.
- 2046 also claims that text/plain must be viewable without wrapping, which
seems to me to conflict with the previous two statements.
- There will be significant compatibility problems if people start sending
text/paragraph.
- I'm not aware of significant compatibility problems with text/plain &
long lines.

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.

Date: Tue, 10 Mar 1998 03:29:37 -0500 (EST)
From: John C Klensin <[email-masked]>
Subject: Re: This is text/paragraph - how does it look?
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

Simeon identifies it as a "no message, one attachment" 
structure.  The obvious way to open the attachment it to 
map it only plain text.  That, by default, brings it up in 
a viewer that requires left-to-right scrolling to read the 
text (i.e., no "wrap" option readily available).  I can 
bring it up in other viewers instead, but while most of 
their wrapping algorithms would have handled this message 
ok, they would have wrapped everything together had you not 
inserted the blank line between your two paragraphs (I 
haven't rechecked your definition, but several of the word 
processing systems that might be used to produce this stuff 
certainly don't require that).

Summary: pretty stinky.  Actually slightly worse than 
pretending it is text/plain (as long as the lines stay under
1K).

   john

From: [email-masked]
To: Laurence Lundblade <[email-masked]>
cc: [email-masked]
Date: Mon, 9 Mar 1998 18:34:25 -0500
Subject: Re: This is text/paragraph - how does it look?
Sender: [email-masked]

Works just fine with Notes/Domino v4.6.  I suspect it would be handled
likewise with earlier versions.

Date: Mon, 9 Mar 1998 11:13:06 -0500 (EST)
From: Todd Vierling <[email-masked]>
To: Laurence Lundblade <[email-masked]>
cc: [email-masked]
Subject: Re: This is text/paragraph - how does it look?
Sender: [email-masked]

On Sun, 8 Mar 1998, Laurence Lundblade wrote:

: In particular I'm worried about text/* defaulting rules. It used to be
: that text/* was good to display (modulo char set of course). But, I
: suspect text/html has changed all that.  I know early versions of Pine
: assumes text/* is good in multipart/alternative and now display the html
: instead of the plain text. If recent MUA releases (that don't display
: HTML) consider text/* hostile because of HTML, they won't display
: text/paragraph. 

Here's your Pine response.  Pine 3.96 defaults to showing it inline (though
text/html is treated as an attachment that my .mailcap has a rule for:
"lynx -dump -force_html %s").  Of course, it doesn't wrap quotes like the
above by default, but fortunately the Pine wrap function (^J) works properly
on a quotation.

And what was that about Outlook Express not parsing it properly?  Might even
convince me to support text/paragraph as a standard just to break M$'s
already broken mailer even more.  ;)  (Does it _still_ respond to e-mail
using the Sender: field?)

-- 
-- Todd Vierling (Personal [email-masked]; Bus. [email-masked])

Date: Mon, 9 Mar 1998 09:27:24 -0600
To: Laurence Lundblade <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: This is text/paragraph - how does it look?
Cc: [email-masked]
Sender: [email-masked]

Showed up fine here; Mac Eudora 4.0.  Would have been fine in older
versions, too.

Reply-To: "Michael A Quinlan" <[email-masked]>
From: "Michael A Quinlan" <[email-masked]>
To: <[email-masked]>
Subject: Re: This is text/paragraph - how does it look?
Date: Mon, 9 Mar 1998 06:41:49 -0700
Sender: [email-masked]

Microsoft Outlook Express showed an empty message body with an attachment.

FYI,
--
Michael Quinlan
[email-masked]
http://www.primenet.com/~mikeq

From: "Bart Schaefer" <[email-masked]>
Date: Mon, 9 Mar 1998 01:34:22 -0800
Comments: In reply to Laurence Lundblade <[email-masked]> "This is text/paragraph - how does it look?" (Mar  8,  7:50pm)
To: [email-masked], Laurence Lundblade <[email-masked]>
Subject: Re: This is text/paragraph - how does it look?
Sender: [email-masked]

(To: [email-masked] ?)

On Mar 8,  7:50pm, Laurence Lundblade wrote:
} Subject: This is text/paragraph - how does it look?
}
} Seems to me the real test of text/paragraph is whether or not MUAs will
} handle it correctly or at least reasonably. I certainly wouldn't want to
} generate if not. So I thought I'd post some and see what happens...

Z-Mail showed me its unknown-type icon and didn't display the text; but I
typed "attach -inline text/paragraph" in the Command: field and now I can
display and respond to text/paragraph exactly as if it were text/plain with
very long lines.  (I used the "Fill" operation in the composer to make the
paragraph above look pretty.)

However, I'm not sure what it'd do with text/paragraph that had been base64
encoded, or that was in some charset other than us-ascii or iso-8859-1.  (I
tried repackaging your message in quoted-printable and that worked OK.)

Of course, most Z-Mail users probably don't know that it's that easy to
produce the desired effect; and the last Z-Mail release was last July, so
maybe that's not a "recent MUA release" ... but, here's your data point.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Date: Sun, 8 Mar 1998 19:50:24 -0800
From: Laurence Lundblade <[email-masked]>
To: [email-masked]
Subject: This is text/paragraph - how does it look?
Sender: [email-masked]

Seems to me the real test of text/paragraph is whether or not MUAs will handle it correctly or at least reasonably. I certainly wouldn't want to generate if not.  So I thought I'd post some and see what happens... 

In particular I'm worried about text/* defaulting rules. It used to be that text/* was good to display (modulo char set of course). But, I suspect text/html has changed all that.  I know early versions of Pine assumes text/* is good in multipart/alternative and now display the html instead of the plain text. If recent MUA releases (that don't display HTML) consider text/* hostile because of HTML, they won't display text/paragraph.

LL