Re: Line Wrapping Question

Terry Crowley <tcrowley@vermeer.com> Wed, 07 February 1996 22:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22312; 7 Feb 96 17:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22308; 7 Feb 96 17:57 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa15234; 7 Feb 96 17:57 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id RAA21434; Wed, 7 Feb 1996 17:27:12 -0500
Received: from vermeer.vermeer.com (vermeer.vermeer.com [204.252.75.5]) by list.cren.net (8.6.12/8.6.12) with ESMTP id RAA21400 for <ietf-822@list.cren.net>; Wed, 7 Feb 1996 17:26:18 -0500
Received: from localhost (uucp@localhost) by vermeer.vermeer.com (8.6.5/8.6.5) id RAA04535; Wed, 7 Feb 1996 17:25:33 -0500
Received: from thoreau.vermeer.com(198.69.149.76) by vermeer.vermeer.com via smap (V1.3) id sma004528; Wed Feb 7 17:25:10 1996
Message-Id: <BMSMTP82374121626tcrowley@vermeer>
Date: Wed, 7 Feb 1996 17:25:03 -0800
Reply-To: Terry Crowley <tcrowley@vermeer.com>
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Terry Crowley <tcrowley@vermeer.com>
To: Ned Freed <NED@innosoft.com>, "Sukvinder Singh Gill (Exchange)" <sukvg@wspu.microsoft.com>
Cc: "ietf-822@list.cren.net" <ietf-822@list.cren.net>
Subject: Re: Line Wrapping Question
In-Reply-To: <01I0XJWH039A9N3WDF@INNOSOFT.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7Bit
X-Mailer: BeyondMail for Windows/SMTP 2.2
X-BeyondMail-Priority: 1
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN

Ned,

I know I shouldn't jump into this argument, but I can't resist the opportunity.
I have no argument that QP is not a presentation encoding, it's a transfer
encoding.  However, QP is specifically designed to support sending of long
lines.  Most implementors of MIME readers have recognized this and made sure
that they wrap long lines when presenting them to the user (usually at the
window width at presentation time, not to some fixed width).

I agree, text/plain is defined as "unformatted" text.  But wrapping unformatted
text is a very reasonable presentation thing to do (perhaps as a configurable
user option).

I'm sure if text/enriched had seemed like more of an integral part of the MIME
spec, and if there hadn't been confusion introduced by QP's handling of long
lines and text/enriched's handling of long lines, more implementors would have
decided that when deciding to send formatted text, to send QP-encoded
text/enriched rather than "just send QP".  But that's not how it happened.

>From your rather vociferous reply, I take it your mail client or gateway didn't
wrap text/plain by default.  Given that, you've taken the world view that "just
send QP" is a radical misunderstanding of the difference between transfer
encoding and presentation encoding.  But most MIME implementors have found that
sending QP results in decent interoperability of automatically wrapped text and
therefore took that approach.  They knew that any mail client that supported
MIME, supported QP, but couldn't guarantee that it would support text/enriched.
So "just send QP" was a more conservative thing to do.

Yes, you really need a presentation semantics to cleanly handle quoting of
wrapped text.  But that's a distinct issue.

Terry