Subject: Re: Message-ID practical maximum size
From: Charles Lindsey <[email-masked]>
To: [email-masked]
Date: Fri, 29 Aug 2003 12:42:41 +0100 (BST)
List-Id: <ietf-822.imc.org>

On Thu, 28 Aug 2003 18:27:36 -0700
	Russ Allbery <[email-masked]> said...

> I'm sorry, you're right.  I was insufficiently precise.  The current,
> completely out-dated and inadequate-for-implementation NNTP standard, RFC
> 977, limits the message ID to around 500 octets indirectly by limits on
> the length of command arguments.  (It doesn't address the point directly.)
> 
> The upcoming standards track replacement, which is very close to last call
> and which is a much better basis for implementation, states:
> 
>    o  A message-id MUST begin with "<" and end with ">", and MUST NOT
>       contain the latter except at the end.
> 
>    o  A message-id MUST be between 3 and 250 octets in length.
> 
>    o  A message-id MUST NOT contain octets other than printable US-ASCII
>       characters.

The not-quite-so-upcoming standards track replacement for RFC 1036
(draft-ietf-usefor-article-11/txt) also imposes the same length
restriction (and some slightly tighter restrictions on the rest of the
syntax).

There was recent discussion on both lists, and it was agreed that some
limit was needed for technical reasons, that 250 was about the right
size and was also built into several existing servers, and therefore was
as good a number as any.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Fri, 29 Aug 2003 09:21:56 +0200
From: "Rolf E. Sonneveld" <[email-masked]>
Subject: RE: Message-ID practical maximum size
To: "'Dave Crocker'" <[email-masked]>, [email-masked]
Reply-to: [email-masked]
Organization: Sonnection B.V.
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_AfzLkU4BvHbJC5KYQ4SKOw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi, Dave,

in the past, I have seen problems with the length of Message-IDs for
messages, which were gatewayed from the Internet to an X.400 network.
After some investigation it turned out that X.400 seems to have a limit
of only 64 characters (if memory serves). Messages with longer
Message-ID's were rejected and undeliverable. As the at-sign cannot be
part of an X.400 message-id without encoding (I believe) there is no
such thing as a left-id in X.400. But you may want to read the MIXER
document in more detail to be sure.

The question remains whether you want to this  (X.400 presence in the
world) into account ;-)

Regards,
Rolf E. Sonneveld
Sonnection B.V.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dave Crocker
> Sent: vrijdag 29 augustus 2003 7:09
> To: [email-masked]
> Subject: Re: Message-ID practical maximum size
> 
> 
> Folks,
> 
> DC> What do folks suggest for the largest maximum size of the
left-hand
> DC> field of a message-id (id-left)?
> 
> 
> Thanks for the various responses.  Most have explored the standards
> documented limits pretty well.
> 
> Are there any further comments about known, limits in existing
> implementations
> 
> 
> d/
> --
>  Dave Crocker <mailto:[email-masked]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

--Boundary_(ID_AfzLkU4BvHbJC5KYQ4SKOw)
Content-type: text/x-vcard; name="Rolf Sonneveld.vcf"
Content-transfer-encoding: QUOTED-PRINTABLE
Content-disposition: attachment; filename="Rolf Sonneveld.vcf"

BEGIN:VCARD=0D=0AVERSION:2.1=0D=0AN:Sonneveld;Rolf=0D=0AFN:Rolf Sonne=
veld=0D=0AORG:Kluwer Academic Publishers (NL);Operations=0D=0ATITLE:C=
onsultant E-mail and Directory services=0D=0ATEL;WORK;VOICE:6823=0D=
=0ATEL;CELL;VOICE:+31 6 543 70205=0D=0AADR;WORK:;05E26b;Van Godewijck=
straat 30;Dordrecht;Zuid Holland;3311 GX;The Netherlands=0D=0ALABEL;W=
ORK;ENCODING=3DQUOTED-PRINTABLE:05E26b=3D0D=3D0AVan Godewijckstraat 3=
0=3D0D=3D0ADordrecht, Zuid Holland 3311 GX=3D0D=3D=0D=0A=3D0AThe Neth=
erlands=0D=0AEMAIL;PREF;INTERNET:[email-masked]=0D=0AREV:2003=
0709T080305Z=0D=0AEND:VCARD=0D=0A=

--Boundary_(ID_AfzLkU4BvHbJC5KYQ4SKOw)--

Date: Thu, 28 Aug 2003 22:08:55 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Message-ID practical maximum size
Sender: [email-masked]

Folks,

DC> What do folks suggest for the largest maximum size of the left-hand
DC> field of a message-id (id-left)?

Thanks for the various responses.  Most have explored the standards
documented limits pretty well.

Are there any further comments about known, limits in existing
implementations

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Thu, 28 Aug 2003 22:04:16 -0600 (MDT)
From: Lyndon Nerenberg <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Message-ID practical maximum size
Organization: The Frobozz Magic Homing Pigeon Company
Sender: [email-masked]

> My math is:
>
>     998          one unfolded line
>   -  12          "Message-ID: "
>   -   3          "<" and "@" and ">"
>   - 255          maximum domain name length (actually 254 but...)
>  --------
>   = 728 octets   safest maximum left-hand size

The space at the end of "Message-ID: " is optional, so make it 729 pctets.

--lyndon

Date: Thu, 28 Aug 2003 22:25:08 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: [email-masked]
Subject: Re: Message-ID practical maximum size
Sender: [email-masked]

on 8/28/2003 9:03 PM Dave Crocker wrote:

> BL> Note also that the maximum length of the domain part is 64 octets
> per
> 
> yes, constraints on the right-hand side are pretty well established. 
> that's why i only asked about the left-hand side.

The right-hand part of a message-id is *operationally* independent from
the envelope limits, since the message-id can refer to a host that doesn't
accept mail (and therefore doesn't need to use the addressing limits for
the domain name). So, the maximum size of the right-hand of the message-id
is the maximum size of a domain name, not the addressing limits.

My math is:

    998          one unfolded line
  -  12          "Message-ID: "
  -   3          "<" and "@" and ">"
  - 255          maximum domain name length (actually 254 but...)
 --------
  = 728 octets   safest maximum left-hand size

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Thu, 28 Aug 2003 19:03:49 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Bruce Lilly <[email-masked]>
CC: [email-masked]
Subject: Re: Message-ID practical maximum size
Sender: [email-masked]

Bruce,

>> What do folks suggest for the largest maximum size of the left-hand
>> field of a message-id (id-left)?

BL> As RFC 2821/2822 are relatively recent and are proposed standards
BL> (vs. 821/822 which are full standards), for maximum interoperability
BL> I'd stick with the appropriate limit from 821/822 and related standards.
BL> There, a msg-id has angle bracketed local-part@domain syntax and the
BL> maximum length of the local-part is 64 octets (RFC 821 section 4.5.3).

An interesting data point.  I understand you viewing one left-hand-sade
as being the same as any other. However RFC821 has nothing to do with the
Message-ID field.

BL> Note also that the maximum length of the domain part is 64 octets per

yes, constraints on the right-hand side are pretty well established.
that's why i only asked about the left-hand side.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

To: [email-masked]
Subject: Re: Message-ID practical maximum size
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 28 Aug 2003 18:27:36 -0700
Sender: [email-masked]

Bruce Lilly <[email-masked]> writes:
> Russ Allbery wrote:

>> The NNTP standards impose a maximum length of 250 characters for the
>> complete message ID when used in a Usenet article, so that may be a
>> reasonable upper guideline if there are no other more pressing
>> considerations, just for convenience of gatewaying.

> IIRC, the NNTP limit is approx. 500 octets; the 250 limit for Usenet
> articles is imposed by the 'dbz' implementation used in some Usenet
> spooling software.

I'm sorry, you're right.  I was insufficiently precise.  The current,
completely out-dated and inadequate-for-implementation NNTP standard, RFC
977, limits the message ID to around 500 octets indirectly by limits on
the length of command arguments.  (It doesn't address the point directly.)

The upcoming standards track replacement, which is very close to last call
and which is a much better basis for implementation, states:

   o  A message-id MUST begin with "<" and end with ">", and MUST NOT
      contain the latter except at the end.

   o  A message-id MUST be between 3 and 250 octets in length.

   o  A message-id MUST NOT contain octets other than printable US-ASCII
      characters.

but it is not yet a standard.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 24 Aug 2003 19:24:22 -0600
From: Lyndon Nerenberg <[email-masked]>
To: Richard Clayton <[email-masked]>, [email-masked], [email-masked]
Subject: Re: HELO command syntax
Sender: [email-masked]

On Sunday, August 24, 2003 6:07 PM +0100 Richard Clayton 
<[email-masked]> wrote:

> In 4.1.1.1 it says (this is new material which was not in 821):
>
>    In situations in which the
>    SMTP client system does not have a meaningful domain name (e.g., when
>    its address is dynamically allocated and no reverse mapping record is
>    available), the client SHOULD send an address literal (see section
>    4.1.3), optionally followed by information that will help to identify
>    the client system.
>
> However reading the syntax carefully, I can see no specification for the
> optional information. The ABNF specifies just a domain or an address
> literal :-(

ISTR that there was discussion at one time about allowing optional 
free-form text after <Domain>, but this idea was shot down. I think the 
text you're referring to might be there due to an editing error. If you 
look at the top paragraph on page 30 of RFC 2821, the second sentence has 
a stray " y " at its head, leading me to believe we might have a simple 
snarf-and-barf error here.

John, can you comment on this?

--lyndon

Date: Sun, 24 Aug 2003 13:21:15 -0500
From: "Eric A. Hall" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Message-ID practical maximum size
Sender: [email-masked]

on 8/24/2003 12:28 PM Dave Crocker wrote:

> Didn't see any length recommendations for Message-ID, in RFC2821.
> 
> What do folks suggest for the largest maximum size of the left-hand
> field of a message-id (id-left)?

Son-of-1036 defines a maximum message identifier length of 250 characters
for the entire ID, including the domain element and angled-brackets.

RFC 2822 prohibits folding in the message identifier header field, so the
maximum length of the header field value is 986 characters (998 characters
minus 12 characters for the Message-ID header field name and the
separating Colon and Space characters).

Subtract the minimum and maximum domain lengths from 986 to produce the
minimum and maximum theoretical length of the left-hand side.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
Subject: Re: Message-ID practical maximum size
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 24 Aug 2003 10:49:01 -0700
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:

> Didn't see any length recommendations for Message-ID, in RFC2821.

> What do folks suggest for the largest maximum size of the left-hand
> field of a message-id (id-left)?

The NNTP standards impose a maximum length of 250 characters for the
complete message ID when used in a Usenet article, so that may be a
reasonable upper guideline if there are no other more pressing
considerations, just for convenience of gatewaying.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 24 Aug 2003 10:28:32 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Message-ID practical maximum size
Sender: [email-masked]

Didn't see any length recommendations for Message-ID, in RFC2821.

What do folks suggest for the largest maximum size of the left-hand
field of a message-id (id-left)?

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Sun, 24 Aug 2003 18:07:21 +0100
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: HELO command syntax
Sender: [email-masked]

I have been reading RFC2821.

In 4.1.1.1 it says (this is new material which was not in 821):

   In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see section
   4.1.3), optionally followed by information that will help to identify
   the client system.

However reading the syntax carefully, I can see no specification for the
optional information. The ABNF specifies just a domain or an address
literal :-(

I suspect this means that sending such optional information would be
unwise ? and also that this last clause "optionally followed..." should
be removed as the standards process proceeds ??

- -- 
richard                     richard.clayton  @  h i g h w a y m a n . com

"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Date: Tue, 19 Aug 2003 13:59:02 +0200
Sender: [email-masked]

Claus Färber writes:
> You must encode the trailing spaces when using quoted-printable. Not 
> doing so would be a violation of the quoted-printable protocol (and 
> the spaces would be removed by the decoder, damaging the RFC 2646 
> format).

Yes. But if the training spaces are the only reason to use q-p, 2646 
says you should not use q-p.

If you're using q-p for some other reason, you should of course encode 
those spaces.

--Arnt

Date: 18 Aug 2003 17:31:00 +0200
From: [email-masked] (=?ISO-8859-1?Q?Claus_F=E4rber?=)
To: [email-masked]
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Sender: [email-masked]

Pete Resnick <[email-masked]> schrieb/wrote:
> strictly 7-bit transport such as unextended SMTP)." If the messages
> you looked at had non US-ASCII characters in them, they needed the
> quoted-printable. The important thing is that you don't encode the
> trailing spaces.

You must encode the trailing spaces when using quoted-printable. Not  
doing so would be a violation of the quoted-printable protocol (and the  
spaces would be removed by the decoder, damaging the RFC 2646 format).

Claus
-- 
http://www.faerber.muc.de/ -- http://www.bayern-gewinnt.de/

Date: Mon, 18 Aug 2003 13:21:25 -0500
To: Keith Moore <[email-masked]>, Marc Mutz <[email-masked]>, Nathaniel Borenstein <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: [email-masked], [email-masked]
Sender: [email-masked]

A bunch of responses in one message:

On 8/15/03 at 1:49 PM -0400, Keith Moore wrote:

>>OK, then let's do a small thought experiment: Why would you need 
>>long lines in English (of course, that are not otherwise addressed 
>>by  format=flowed)?
>
>wide tables or "ASCII art", lots of columns of data, data files that 
>are in character format but not really intended for human 
>consumption.

And which of those would you ever send in a format=flowed message? 
(Remember, the original issue I was answering was why you should 
never send QP with Japanese in format=flowed.)

On 8/15/03 at 8:40 PM +0200, Marc Mutz wrote:

>As I see it (and Pete has just reinforced my view on this by sharing 
>it), format=flowed's main feature is to define paragraphs (in 
>unquoted, but more importantly also in quoted text) and an algorithm 
>for preserving that information on replies.

Not quite. The main features of format=flowed are:

1. To give *plain text* clients the ability to re-wrap paragraphs 
(especially in quoted text) for display. (Of course, this is most 
important for clients with smaller screens.)

2. To give clients the ability to reformat reply messages so that 
quoted sections (even if they are excerpted from the middle of a 
line) are reasonably wrapped and displayed upon receipt.

There are two important things to note about these features: They are 
about *display* and they are about *plain text*. Whatever gets to the 
other side has to be easily and reasonably displayed by any plain 
text reader. The least common denominator you are shooting for is 
that someone who ignores that "format=flowed" parameter will do OK. 
The best you want is that someone who honors the parameter will be 
able to do fancier things. Reliable semantic transmission is not the 
primary goal. If you really want to preserve the semantics of 
paragraph and quoting reliably, you should be using HTML or XML or 
some other markup.

>However, that requires trailing whitespace to be preserved, since 
>line-coupling to paragraphs is lost if TWS is. In my experience, 
>"preserve TWS" evaluates to "apply QP". Now, that is not suggested 
>(not to say forbidden) for readability reasons with legacy 
>(non-QP-aware) MUAs.

If your primary purpose was to preserve semantics, preserving TWS 
would be required. Since that's not the primary purpose, it is not 
necessary, and more importantly not desirable.

>IMO, priority should be on preserving the information for "modern" 
>MUAs, not on enhancing readability for legacy MUAs[1].

That's why you have HTML.

On 8/16/03 at 4:45 PM -0400, Nathaniel Borenstein wrote:

>On Friday, August 15, 2003, at 12:03  PM, Pete Resnick wrote:
>
>>When you put it back together, what you get is a single long line 
>>that (for example) should be displayed with a horizontal scrollbar. 
>>It is a representation of a single line, not a wrapped paragraph.
>
>The latter sentence is true, but I have a quibble with your use of 
>the word "should" in the previous sentence.  The fact that the data 
>object being displayed is properly understood as a single long line 
>of text does not mandate the choice of one display mechanism over 
>another.  In this case, I would contend that inserting soft line 
>breaks and avoiding a horizontal scrollbar is more often than not 
>the more user-friendly thing to do.
>
>If you had said "might" instead of "should" I would have kept my 
>mouth shut.  -- Nathaniel

On one hand, you're correct: The reality of the world is that clients 
do dumb things, including marking things as quoted-printable long 
lines even though they really don't intend to convey that this line 
really *should* be displayed as a single line with a horizontal 
scroll bar. On the other hand, a client with a 30 column display 
which chooses to display:

      Stupid              Smart
      Pete Resnick        Nathaniel =
      Borenstein

as:

      Stupid              Smart
      Pete Resnick
      Nathaniel Borenstein

instead of using a scrollbar and showing:

      Stupid              Smart
      Pete Resnick        Nathaniel Borenstein

is doing their user a disservice. If we are strictly talking about 
preserving semantics, you *should* use the horizontal scrollbar. If 
we are accounting for what sending clients incorrectly transmit in 
the semantics, you are of course correct that we might want to do 
something different.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Ken Hirsch <[email-masked]>
To: IETF-822 <[email-masked]>
Date: Mon, 18 Aug 2003 13:15:58 -0400
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Sender: [email-masked]

Nathaniel Borenstein wrote:
>Pete Resnick wrote:
>> When you put it back together, what you get is a single long line 
>> that (for example) should be displayed with a horizontal scrollbar. 
>> It is a representation of a single line, not a wrapped paragraph. 
>
>The latter sentence is true, but I have a quibble with your use of the 
>word "should" in the previous sentence.  The fact that the data object 
>being displayed is properly understood as a single long line of text 
>does not mandate the choice of one display mechanism over another.  In 
>this case, I would contend that inserting soft line breaks and avoiding 
>a horizontal scrollbar is more often than not the more user-friendly 
>thing to do.
>
>If you had said "might" instead of "should" I would have kept my mouth 
>shut.  -- Nathaniel

I almost said the same thing, but since the point about quoted messages 
is valid, I resisted.

Still, experimenting today with 4 PC-based MUAs and 3 web-based MUAs, all of them wrapped a paragraph that was sent with quoted-printable soft line breaks.

Date: Sat, 16 Aug 2003 16:45:04 -0400
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: "Ken Hirsch" <[email-masked]>, <[email-masked]>
To: Pete Resnick <[email-masked]>
From: Nathaniel Borenstein <[email-masked]>
Sender: [email-masked]

On Friday, August 15, 2003, at 12:03  PM, Pete Resnick wrote:

> When you put it back together, what you get is a single long line that 
> (for example) should be displayed with a horizontal scrollbar. It is a 
> representation of a single line, not a wrapped paragraph.

The latter sentence is true, but I have a quibble with your use of the 
word "should" in the previous sentence.  The fact that the data object 
being displayed is properly understood as a single long line of text 
does not mandate the choice of one display mechanism over another.  In 
this case, I would contend that inserting soft line breaks and avoiding 
a horizontal scrollbar is more often than not the more user-friendly 
thing to do.

If you had said "might" instead of "should" I would have kept my mouth 
shut.  -- Nathaniel

From: Arnt Gulbrandsen <[email-masked]>
To: "Lyndon Nerenberg {VE6BBM}" <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: [email-masked], Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Date: Mon, 18 Aug 2003 10:37:01 +0200
Sender: [email-masked]

Long lines in English occur fairly commonly when the reader's screen is 
unusually narrow.

On the screen i use right now, hardly anything is too long. One my PDA, 
any source code pasted in qualifies as long. In my world, source code 
occurs all the time.

--Arnt

Date: Sun, 17 Aug 2003 23:44:32 -0600
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
To: Pete Resnick <[email-masked]>
From: Lyndon Nerenberg {VE6BBM} <[email-masked]>
Sender: [email-masked]

On Friday, August 15, 2003, at 11:28  AM, Pete Resnick wrote:

 > OK, then let's do a small thought experiment: Why would you need long 
 > lines in English

Because that's the way the author intended the text to be displayed.

Silly, perhaps, but it happens. We've had authors who eschew 
capitalization and punctuation. Why can't they ignore the right margin?

Beware of setting policy.

--lyndon

From: Arnt Gulbrandsen <[email-masked]>
To: Marc Mutz <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: [email-masked]
Date: Sun, 17 Aug 2003 14:34:25 +0200
Sender: [email-masked]

Marc Mutz writes:
> IMO, priority should be on preserving the information for "modern" 
> MUAs, not on enhancing readability for legacy MUAs[1].

The issue arises only when a broken MTA is used and the message is 
harmed. When that happens, which of the following is more likely?

a) the end user is using the latest version of kmail
b) the end user is using a MUA selected by whoever bought the broken MTA

I place my money on b.

(I would also argue that guarding against text corruption isn't the role 
of f=f, it's the role of multipart/signed.)

--Arnt

Date: Fri, 15 Aug 2003 20:40:37 +0200
From: Marc Mutz <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
To: [email-masked]
Organization: KDE
Sender: [email-masked]

--Boundary-02=_lkSP/TWjbo+8UAz
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=2E..this reminds me of an issue I wanted to raise while reading rfc/
draft...

On Friday 15 August 2003 17:17, Ken Hirsch wrote:
> I just searched the net for instances of Format=3DFlowed; Delsp=3DYes and
> found quite a few (all from Apple Mail). Almost all ofr the messages
> were CTE: quoted-printable.
>
> This rather misses the whole point of the format, doesn't it?
> =A0RFC2646 says you SHOULD NOT use quoted-printable.

I don't understand this SHOULD NOT. Well, I understand why it's there=20
(it's explained in the document), but I immediately thought: "What=20
the...". Let me explain:

As I see it (and Pete has just reinforced my view on this by sharing=20
it), format=3Dflowed's main feature is to define paragraphs (in unquoted,=20
but more importantly also in quoted text) and an algorithm for=20
preserving that information on replies.

However, that requires trailing whitespace to be preserved, since line-
coupling to paragraphs is lost if TWS is. In my experience, "preserve=20
TWS" evaluates to "apply QP". Now, that is not suggested (not to say=20
forbidden) for readability reasons with legacy (non-QP-aware) MUAs.

IMO, priority should be on preserving the information for "modern" MUAs,=20
not on enhancing readability for legacy MUAs[1].

Marc

[1] legacy here meaning pre-MIME, not pre-format=3Dflowed.

=2D-=20
I am Bush of USA. You will be pacified. Resistance is futile.

--Boundary-02=_lkSP/TWjbo+8UAz
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_lkSP/TWjbo+8UAz--

Date: Fri, 15 Aug 2003 13:49:50 -0400
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Sender: [email-masked]

> OK, then let's do a small thought experiment: Why would you need long 
> lines in English (of course, that are not otherwise addressed by 
> format=flowed)?

wide tables or "ASCII art", lots of columns of data, data files
that are in character format but not really intended for human
consumption.

Keith

Date: Fri, 15 Aug 2003 12:28:50 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 8/15/03 at 1:26 PM -0400, Keith Moore wrote:

>>Why would you need long lines in 2022-JP?
>
>since I don't speak or read Japanese, I don't pretend to know.

OK, then let's do a small thought experiment: Why would you need long 
lines in English (of course, that are not otherwise addressed by 
format=flowed)?
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 15 Aug 2003 13:26:39 -0400
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Sender: [email-masked]

> Why would you need long lines in 2022-JP?

since I don't speak or read Japanese, I don't pretend to know.
but neither do I assume that those who do speak it don't ever
need to transmit long lines.

Date: Fri, 15 Aug 2003 12:25:13 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 8/15/03 at 1:20 PM -0400, Keith Moore wrote:

>>ISO-2022-JP, for example, has no need for quoted-printable. Of 
>>course, a MIME MUA has to handle quoted-printable, but CJK can be 
>>sent without QP.
>
>it doesn't need QP to allow sending through 7bit channels. QP could 
>still be useful to allow long lines to be transmitted through 
>channels that impose a maximum line length.

Why would you need long lines in 2022-JP? Do you send a great deal of 
programming code with Japanese comments at the ends of lines? Do you 
send lots of long-line ASCII art, only using Kanji characters? The 
only reason to use QP is to send long lines that you don't want soft 
paragraph wrapped by format=flowed. Please identify some real use for 
QP when you're using 2022.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Fri, 15 Aug 2003 13:20:59 -0400
From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Sender: [email-masked]

> ISO-2022-JP, for example, has no need for quoted-printable. Of 
> course, a MIME MUA has to handle quoted-printable, but CJK can be 
> sent without QP.

it doesn't need QP to allow sending through 7bit channels.
QP could still be useful to allow long lines to be transmitted
through channels that impose a maximum line length.

Keith

Date: Fri, 15 Aug 2003 11:03:41 -0500
To: "Ken Hirsch" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Format=flowed delsp=Yes and quoted-printable
Cc: <[email-masked]>
Sender: [email-masked]

On 8/15/03 at 11:17 AM -0400, Ken Hirsch wrote:

>This rather misses the whole point of the format, doesn't it? 
>RFC2646 says you SHOULD NOT use quoted-printable.

2646 says that you should not use quoted-printable "unless absolutely 
necessary (for example, non-US-ASCII (8-bit) characters over a 
strictly 7-bit transport such as unextended SMTP)." If the messages 
you looked at had non US-ASCII characters in them, they needed the 
quoted-printable. The important thing is that you don't encode the 
trailing spaces.

>Besides which, quoted-printable already has a mechanism for soft line breaks.

NO! Quoted-printable does *NOT* have a mechanism for soft line breaks 
in the sense of paragraph wrapping the way that format=flowed does. 
Quoted-printable has a mechanism for breaking up a long line of 
characters over multiple lines for transmission purposes. When you 
put it back together, what you get is a single long line that (for 
example) should be displayed with a horizontal scrollbar. It is a 
representation of a single line, not a wrapped paragraph.

>As Arnt Gulbrandsen pointed out last year, don't MUAs for CJK 
>already need to handle quoted-printable, multiple charsets, etc.?

ISO-2022-JP, for example, has no need for quoted-printable. Of 
course, a MIME MUA has to handle quoted-printable, but CJK can be 
sent without QP.

>Does Format=flowed really add anything?

Yes. It adds paragraph wrapping, and more importantly quoted 
paragraph wrapping, while preserving backward compatibility. It is 
the quoted paragraph wrapping (i.e., putting ">" before each line in 
a quoted section.) that is the biggest feature.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: "Ken Hirsch" <[email-masked]>
To: <[email-masked]>
Subject: Format=flowed delsp=Yes and quoted-printable
Date: Fri, 15 Aug 2003 11:17:55 -0400
Sender: [email-masked]

I just searched the net for instances of Format=Flowed; Delsp=Yes and found
quite a few (all from Apple Mail). Almost all ofr the messages were CTE:
quoted-printable.

This rather misses the whole point of the format, doesn't it?  RFC2646 says
you SHOULD NOT use quoted-printable.

Besides which, quoted-printable already has a mechanism for soft line
breaks.

As Arnt Gulbrandsen pointed out last year, don't MUAs for CJK already need
to handle quoted-printable, multiple charsets, etc.?  Does Format=flowed
really add anything?

For what it's worth, I did find a few Japanese messages with CTE: 7-bit

http://www.egroups.co.jp/message/minnademac/3563?source=1
http://alpha.c.oka-pu.ac.jp/~yokota/gakkai/etc/npdpa02

Date: Tue, 12 Aug 2003 11:22:59 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-moore-auto-email-response-02.txt
Sender: [email-masked]

Please read and review this to see whether you agree with it.

Assuming no objections, I would like to ask the Apps ADs to
Last Call this for Proposed soon.

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-moore-auto-email-response-02.txt,.ps
Date: Thu, 07 Aug 2003 09:55:55 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Recommendations for Automatic Responses to Electronic 
                          Mail
	Author(s)	: K. Moore
	Filename	: draft-moore-auto-email-response-02.txt,.ps
	Pages		: 18
	Date		: 2003-8-7
	
This memo makes recommendations for software that automatically responds
to incoming electronic mail messages, including 'out of the office' or
'vacation' response generators, mail filtering software, email-based
information services, and other automatic responders.  The purpose of
these recommendations is to discourage undesirable behavior which is
caused or aggravated by such software, to encourage uniform behavior
(where appropriate) among automatic mail responders, and to clear up
some sources of confusion among implementors of automatic email
responders.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-moore-auto-email-response-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-moore-auto-email-response-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-moore-auto-email-response-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-moore-auto-email-response-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-moore-auto-email-response-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--