Subject: Re: gzip/deflate compression/encoding
From: Frank Ellermann <[email-masked]>
To: [email-masked]
Date: Fri, 01 Jul 2005 05:47:05 +0200
List-Id: <ietf-822.imc.org>

Charles Lindsey wrote:
 
> Are the usual audio, image, etc. formats truly 8bit clean
> (i.e. are they guaranteed not to contain NUL or naked CR or
> LF)?

Of course not, this thread is about introducing yenc as CTE,
in pseudo-REXX (untested, ignoring trailing SP or HT issues):

   CRLF = x2c( 0D0A )
   BAD  = CRLF || x2c( 0 ) || '='
   OUT  = ''
   LIM  = 500 /* REXX idiosyncrasy on my side ;-) */
   
   do while INPUT \== '' /* strict comparison */
      parse var INPUT TOP 2 INPUT
      TOP = d2c( c2d( TOP ) + 64 ) // 256 )
      
      if sign( pos( TOP, BAD )) then OUT = OUT || '='
      OUT = OUT || TOP
       
      if LIM <= length( OUT ) then do
         call charout /* stdout */, OUT || CRLF
         OUT = ''
      end
   end  

> If not, then you are back to the 37+% expansion of base64.

The worst case is slightly more than 50% if the entire input
is d2c(192), d2c(202), d2c(205), or d2c(253).  And for runs
of d2c(201) or d2c(224) for the trailing SP / HT issue.

Ignoring the latter using Bruce's formula; 260/256 * 502/500
or less than 102%.  Sometimes it's 503/501, but we don't need
it more precisely while ignoring the trailing HT / SP stuff.

                        Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: gzip/deflate compression/encoding
Date: Thu, 30 Jun 2005 21:26:35 -0400
Sender: [email-masked]

On Thu June 30 2005 20:33, Laird Breyer wrote:

> I generally agree with you that double compression is useless, where
> we differ is where the single compression step should be applied.  You
> propose that it should occur in the MIME format, while I still believe
> it should be a transparent service at a level much closer to the OS.

Although it's a perhaps subtle distinction, my position is that an
end-to-end solution is preferable to multiple hop-by-hop partial
solutions, and that MIME is the most appropriate mechanism for
supporting a general end-to-end solution.

> Since XML data seems to be the main beneficiary mentioned thus far of
> the CTE (37% base64 overhead aside), let me ask what the proponents
> aim to achieve in this instance?  

I'm not particularly a compression proponent and I'm certainly not
an XML proponent.  The gains would be the usual ones for compression;
shorter transmission time, etc.  For email, it probably doesn't
matter much, but for highly interactive protocols (HTTP, IM, etc.)
it may be a significant factor.  As a non-proponent of XML, I'd
personally say pick a more efficient representation, but that's
just me.
 
> Other media types such as audio/video/images are already compressed so
> won't benefit substantially from a CTE.

A few points:
1. some specific image (etc.) formats can benefit from compression
2. CTE for binary-to-8bit (unrelated to compression) can reduce the
   37% expansion to ~2%

> If space is such a serious concern, I ask: why shouldn't XML applications
> simply read and write XML directly in compressed form when needed
> (you already gave the example of OpenOffice) ?

While OpenOffice uses XML to represent documents, it's not amenable
to use OpenOffice to edit arbitrary XML.  For example, you might think
that a document processor that uses XML might be useful for editing
XML versions of Internet-Drafts.  Not without a major effort.  So while
compression may be useful for OpenOffice file formats, it doesn't
necessarily follow that the same compression is necessarily useful for
all XML applications.

> There would be no need for MIME readers and writers to be adapted at
> all, and the physical benefits would be comparable.

RFC 1925:
   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection.

Moving the problem to all applications and/or their respective protocols
doesn't solve the problem, it just shifts the burden.
 
> Now if the arguments against this are that this requirement would
> complicate XML applications needlessly, obscure data against the
> purpose of XML, and could be handled at a lower system level such that
> other programs can also benefit, then this also summarizes my current
> position on MIME/email (as opposed to MIME alone - but substantial
> changes to MIME cannot be ignored by email).

Trying to shift the problem to media specifically for text would obscure
the text.  Probably not a problem for application/*+xml, though it seems
wasteful (to this non-XML proponent anyway) to have to repeat the solution
N times over in N formats rather than once in MIME.

Date: Fri, 1 Jul 2005 10:33:52 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

I think this thread is getting bogged down in technical points without
a clear overview. Rather than respond to each good point you've
raised, I'd like to try another line which broadly summarizes my view
and is perhaps more useful to the list.

I generally agree with you that double compression is useless, where
we differ is where the single compression step should be applied.  You
propose that it should occur in the MIME format, while I still believe
it should be a transparent service at a level much closer to the OS.

Since XML data seems to be the main beneficiary mentioned thus far of
the CTE (37% base64 overhead aside), let me ask what the proponents
aim to achieve in this instance?  

Other media types such as audio/video/images are already compressed so
won't benefit substantially from a CTE. Is the idea of CTE compression
simply a way to pass the burden of XML compression onto another
system level?

XML is by design a textual format. An explicit goal of this format
is the ability for humans and other programs to easily read and
modify it. The internet message format has similar goals, although
MIME more generally may not.

If space is such a serious concern, I ask: why shouldn't XML applications
simply read and write XML directly in compressed form when needed
(you already gave the example of OpenOffice) ?
There would be no need for MIME readers and writers to be adapted at
all, and the physical benefits would be comparable.

Now if the arguments against this are that this requirement would
complicate XML applications needlessly, obscure data against the
purpose of XML, and could be handled at a lower system level such that
other programs can also benefit, then this also summarizes my current
position on MIME/email (as opposed to MIME alone - but substantial
changes to MIME cannot be ignored by email).

-- 
Laird Breyer.

From: [email-masked]
Cc: [email-masked]
To: Charles Lindsey <[email-masked]>
Date: Thu, 30 Jun 2005 12:28:12 -0700 (PDT)
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

> In <[email-masked]> Frank Ellermann <[email-masked]> writes:

> >Bruce Lilly wrote:

> >> Conclusions:
> >> 1. binary-to-8bit encoding w/o gzip compression is fine for audio,
> >>    image, and video media which already has media-specific compression
> >>    (for 8bit transport, avoiding the 37+% expansion of base64)

> >Yes

> Question:

> Are the usual audio, image, etc. formats truly 8bit clean (i.e. are they
> guaranteed not to contain NUL or naked CR or LF)?

Of course they aren't.

> If not, then you are
> back to the 37+% expansion of base64.

Doesn't follow. A binary-to-8bit encoding has enough characters available that
the overhead can be limited to at most 1-2%.

> For that matter, is a gzipped file 8bit clean?

It isn't and doesn't have to be.

				Ned

From: [email-masked]
Cc: [email-masked]
To: Charles Lindsey <[email-masked]>
Date: Thu, 30 Jun 2005 11:40:25 -0700 (PDT)
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

> In <20050629070218.GA30094@ender> Laird Breyer <[email-masked]> writes:

> >If it really has to be tried out, wouldn't a few content types
> >make more sense to test the waters? A CTE which replaces them can
> >always be defined some years later, and in the meantime it doesn't
> >force all standards compliant software to implement a decompressor.

> How about:

> Content-Type: application/compressed; protocol=gzip;
>               uncompressed-type="image/jpeg" (; and all parameters of the
>               uncompressed type allowed here)

> Content-Type: application/compressed; protocol=gzip;
>               uncompressed-type="text/html"; charset=iso-8859-1

Repeating for the Nth time: Media types are supposed to be used to identify
types of media, not general compression schemes or other stuff. Section 2.2.1
of RFC 2048 is very clear about this, and this requirement remains unchanged in
section 4.1 of draft-freed-media-type-reg-04.txt. As such, any attempt to
register such a media type will be immediately rejected.

If you want to play around with general compression schemes and MIME in a
standards-compliant way, nothing prevents you from using x-gzip or whatever
as a CTE.

				Ned

To: [email-masked]
Xref: clerew local.mime:4820
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Date: Thu, 30 Jun 2005 12:02:15 GMT
Lines: 26
Sender: [email-masked]

In <20050629070218.GA30094@ender> Laird Breyer <[email-masked]> writes:

>If it really has to be tried out, wouldn't a few content types
>make more sense to test the waters? A CTE which replaces them can
>always be defined some years later, and in the meantime it doesn't
>force all standards compliant software to implement a decompressor.

How about:

Content-Type: application/compressed; protocol=gzip;
              uncompressed-type="image/jpeg" (; and all parameters of the
              uncompressed type allowed here)

Content-Type: application/compressed; protocol=gzip;
              uncompressed-type="text/html"; charset=iso-8859-1

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

To: [email-masked]
Xref: clerew local.mime:4819
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Date: Thu, 30 Jun 2005 11:56:42 GMT
Lines: 29
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>Bruce Lilly wrote:

>> Conclusions:
>> 1. binary-to-8bit encoding w/o gzip compression is fine for audio,
>>    image, and video media which already has media-specific compression
>>    (for 8bit transport, avoiding the 37+% expansion of base64)

>Yes

Question:

Are the usual audio, image, etc. formats truly 8bit clean (i.e. are they
guaranteed not to contain NUL or naked CR or LF)? If not, then you are
back to the 37+% expansion of base64.

For that matter, is a gzipped file 8bit clean?

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

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: gzip/deflate compression/encoding
Date: Wed, 29 Jun 2005 09:10:45 -0400
Sender: [email-masked]

On Wed June 29 2005 03:02, Laird Breyer wrote:
> 
> On Jun 29 2005, Bruce Lilly wrote:
> 
> > MIME transfer encoding is typically used end-to-end.  It doesn't
> > matter where the bottleneck is, doesn't require any special software
> > support at intermediate sites.
> 
> Yes, this is the crucial point. You've identified one problem at intermediate
> nodes of the network, namely the SMTP size limit which depends on the
> installed MTA software. 

and administrative policy (and possibly, depending on implementation,
factors such as available storage capacity).

> With CTE: No software change at intermediate nodes is required. 
>  Major change at all client leaf nodes is required just to continue
> using email, because the CTE makes the compressed content opaque.

Not "all", only those wishing to use the particular transfer encoding.
A sender who uses base64 alone and recipients of such content need not
be concerned with other encodings.

> Without CTE, but TLS: changes at intermediate nodes and leaf nodes 
> bring definite benefits, but no change is required of all clients at once.

Base TLS benefits are orthogonal to the issue; optional compression over
TLS doesn't address a crucial problem (the SMTP size limit), and involves
multiple CPU-intensive compress/decompress cycles.
 
> And finally: if the user sends precompressed documents as 8bit attachments 
> from his MUA, no changes at all are required today. This is the purest
> end-to-end scenario.

Not quite.  Any such scheme requires some sort of cooperation at at least
the end points (sender and receiver need to agree on the method, packaging,
etc.).  Some schemes require implicit cooperation of intermediate nodes
(not adding empty lines, not folding long lines, not adding/removing
whitespace at the end of lines, not mangling lines that happen to begin
with "From ", etc.  If MIME is used, then there is some hypothetical and
probably private-use encoding or media type or both, which sender and
recipient need to agree upon.  If not MIME, then sender and recipient also
need to agree on all of the equivalent framework that MIME provides
(checksums, language indication, parameters, fitting into the Internet
Message Format, and so on).

> Indeed, compression is always an option whether or not a CTE is available.
> Just because the sender pushes an uncompressed message over the wire doesn't
> mean that the receiver must accept the uncompressed stream into a holding
> buffer the same size as the message, it can be compressed as it is received. 

Perhaps, but the SMTP SIZE indication is based on message DATA size as
transferred at the application protocol level, not on some hypothetical
compression.
 
> If you're going to give the SMTP receiver an option to rewrite the
> message encoding with a CTE, then on-the-fly compression in RAM or on
> disk is also an option which compares favourably.

I'm not quite sure what you're getting at...  Hypothetically an MTA
could apply a CTE to meet transport requirements, but there is no
requirement for a particular implementation method.
 
> Sorry, I was aware of that, I meant a second CTE compression on top
> of the video stream.

That would be ineffective, as discussed in a previous message.  N.B.
that applies to compression over TLS and filesystem compression.

> Regarding text compression, big savings are possible 
> but normally text isn't the bulkiest part of a large email, so compression is 
> not crucial.

Apparently from comments in this thread there is some desire to compress
repetitive text-like stuff ("all that XML").

> > No, the information is all there (both formats can be opened in OpenOffice
> > and contain the same spreadsheet data).
> 
> Except for VB macros and whatever else Microsoft decided to put in
> their files. I've been told that Excel is Turing complete...

OpenOffice includes the macros, but comments them out in the .sxc format,
since OpenOffice doesn't interpret the same macro language.

> I really don't know, it seems easy to define these CTEs, but once they exist
> everyone is stuck with them and there's no backwards compatibility.

Backward compatibility is indeed a concern, and is why proliferation of
transfer encodings is undesirable.  Backward compatibility is going to
take a hit no matter what, so it's a matter of considering the pros and
cons and trying to design a solution that inflicts minimum harm both
now and for the foreseeable future.  If a MIME-version increment is
warranted, then it would be prudent to minimize the chance that future
extensions would need yet another increment.
 
> If it really has to be tried out, wouldn't a few content types
> make more sense to test the waters?

There is a strong tradition against registration of media types which
are really transfer encodings.  The biggest problem would be under the
text media type, where some built-in compression would almost certainly
conflict with the characteristics that text types are supposed to have
(e.g. "software must not be required in order to get the general idea
of the content".  (And I would probably be among the first to complain.)

> A CTE which replaces them can 
> always be defined some years later, and in the meantime it doesn't
> force all standards compliant software to implement a decompressor.

In which ways would delaying a backwards incompatibility introduction
be a good thing?  The MIME RFCs are currently at Draft status.
Introduction  of new encodings now might force a reset to Proposed.
How would advancement to full Standard soon, followed by a later reset
to Proposed be advantageous?

Date: Wed, 29 Jun 2005 17:15:00 +1000
From: Laird Breyer <[email-masked]>
To: [email-masked]
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Jun 28 2005, Harald Tveit Alvestrand wrote:
> 
> I'd very much like to see the deflate-8bit and deflate-base64 C-T-Es 
> formally defined.

Does it have to be a content encoding, or would a small number of
media types serve the same purpose, ie to try the scheme out?

> 
> If someone identifies a niche for which they can be introduced sensibly, 
> they will be able to deploy them, rather than inventing Yet Another 
> Compression Scheme. If nobody starts using them seriously, well.... we've 
> lost some time, and an RFC number or two. Big deal. We've done that any 
> number of times, for any number of things (remember the MODEL top level 
> type? Who's hurt by having it around?)

I think I can guarantee that, whether it's useful or not, it will be used
by spammers to hide their junk. That means mail software will have to handle 
it just on the off chance it's legitimate, and pretty soon all
mail software will implement it, whether it has a useful place or not. 

Now if it's a media type rather than a transfer encoding, it can be safely
ignored if it doesn't find a use.

-- 
Laird Breyer.

Date: Wed, 29 Jun 2005 17:02:18 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Jun 29 2005, Bruce Lilly wrote:

> MIME transfer encoding is typically used end-to-end.  It doesn't
> matter where the bottleneck is, doesn't require any special software
> support at intermediate sites.

Yes, this is the crucial point. You've identified one problem at intermediate
nodes of the network, namely the SMTP size limit which depends on the
installed MTA software. 

With CTE: No software change at intermediate nodes is required. 
 Major change at all client leaf nodes is required just to continue
using email, because the CTE makes the compressed content opaque.

Without CTE, but TLS: changes at intermediate nodes and leaf nodes 
bring definite benefits, but no change is required of all clients at once.

And finally: if the user sends precompressed documents as 8bit attachments 
from his MUA, no changes at all are required today. This is the purest
end-to-end scenario.

>  
> > > See RFC 1123 section 5.3.8.
> > 
> > Seems a little outdated ;-) 
> 
> Limits still exist. Now there's an extension so that the client can
> specify the size before sending.  If the SMTP receiver can't handle
> the message size, the options are compress, fragment, or bounce.  A
> bounce is a failure, fragmentation has several issues, and that
> leaves compression.

Indeed, compression is always an option whether or not a CTE is available.
Just because the sender pushes an uncompressed message over the wire doesn't
mean that the receiver must accept the uncompressed stream into a holding
buffer the same size as the message, it can be compressed as it is received. 

If you're going to give the SMTP receiver an option to rewrite the
message encoding with a CTE, then on-the-fly compression in RAM or on
disk is also an option which compares favourably.

> 
> > Even if you're transferring say an MPEG video stream,
> > there are key frames which allow small random corruptions to be ignored.
> > But compress the video, and you can throw it away if there's a corruption. 
> 
> MPEG *IS* compressed!  Loss of a P, B, or I frame will be a (temporary)

Sorry, I was aware of that, I meant a second CTE compression on top
of the video stream. Regarding text compression, big savings are possible
but normally text isn't the bulkiest part of a large email, so compression is 
not crucial.

> Conclusions:
> 1. binary-to-8bit encoding w/o gzip compression is fine for audio,
>    image, and video media which already has media-specific compression
>    (for 8bit transport, avoiding the 37+% expansion of base64)

I agree with Frank Ellermann, this option isn't broken and has the advantage
of simplicity.

> 
> No, the information is all there (both formats can be opened in OpenOffice
> and contain the same spreadsheet data).

Except for VB macros and whatever else Microsoft decided to put in
their files. I've been told that Excel is Turing complete...

> > Of course, all these transparent ways must be implemented and deployed
> > just the same, but what is the serious long term benefit in making MIME
> > carry CTEs? Every MIME aware application will have to be adapted to
> > read those new encodings.
> 
> See Harald's message.

I really don't know, it seems easy to define these CTEs, but once they exist
everyone is stuck with them and there's no backwards compatibility.

If it really has to be tried out, wouldn't a few content types
make more sense to test the waters? A CTE which replaces them can
always be defined some years later, and in the meantime it doesn't
force all standards compliant software to implement a decompressor.

-- 
Laird Breyer.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: gzip/deflate compression/encoding
Date:  Wed, 29 Jun 2005 06:41:02 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Bruce Lilly wrote:

> Conclusions:
> 1. binary-to-8bit encoding w/o gzip compression is fine for audio,
>    image, and video media which already has media-specific compression
>    (for 8bit transport, avoiding the 37+% expansion of base64)

Yes

> 2. gzip compression seems to be suitable for only a limited set of media
>    types, therefore:
[...]
     or
     e. let's see what happens after testing the water with 1.

Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: gzip/deflate compression/encoding
Date: Wed, 29 Jun 2005 00:16:13 -0400
Sender: [email-masked]

On Tue June 28 2005 21:03, Laird Breyer wrote:
> 
> On Jun 28 2005, Bruce Lilly wrote:

> > 1. the bottleneck might be elsewhere, known to the originator, but
> >    unknown to the network operator
> > 2. That still implies 3749 support at the operator's side
> > 3. it assumes that the end user knows enough to/can/will install
> >    TLS support including the 3749 extension
> 
> These are pretty standard objections, which apply to software updates,
> whether for TLS support or MIME/CTE. They don't serve as a strong
> differentiator in favour of either approach.

MIME transfer encoding is typically used end-to-end.  It doesn't
matter where the bottleneck is, doesn't require any special software
support at intermediate sites.
 
> > See RFC 1123 section 5.3.8.
> 
> Seems a little outdated ;-) 

Limits still exist. Now there's an extension so that the client can
specify the size before sending.  If the SMTP receiver can't handle
the message size, the options are compress, fragment, or bounce.  A
bounce is a failure, fragmentation has several issues, and that
leaves compression.

> Even if you're transferring say an MPEG video stream,
> there are key frames which allow small random corruptions to be ignored.
> But compress the video, and you can throw it away if there's a corruption. 

MPEG *IS* compressed!  Loss of a P, B, or I frame will be a (temporary)
problem. There are techniques which can be used to detect and correct
some errors (at the cost of additional overhead), and there are other
video-specific techniques which can be used to conceal detected but
uncorrectable errors.  A general compression scheme, whether in a
MIME CTE or in TLS, is not a particularly good choice for compression
of audio, video, or image data; these media types have specific
compression methods tailored to the media characteristics.  For example,
a particular JPEG image I have is 4088362 octets; gzip yields
4083504 octets, which is negligible additional compression [*].  Now one
might be able to achieve some compression of particular subtypes of
some of these media types (e.g. a bitmap PCM image format), but the
resulting size will typically be no smaller than what could be achieved
with a lossless variant of media-specific compression (JPEG in the
case of image media).  General-purpose compression may however be useful
for text, text-like content (scripting languages, etc.) and some
application data.

Conclusions:
1. binary-to-8bit encoding w/o gzip compression is fine for audio,
   image, and video media which already has media-specific compression
   (for 8bit transport, avoiding the 37+% expansion of base64)
2. gzip compression seems to be suitable for only a limited set of media
   types, therefore:
   a. plan on something that is amenable to multiple compression schemes,
      each alone (binary output) and coupled with encodings to 8bit and
      7bit.
   or
   b. choose a compression framework that is adaptable, pluggable, or
      configurable with parameters for different media characteristics
   or
   c. define suitable text, model, and application media subtypes with
      built-in compression, analaogous to compression already available
      in audio, image, and video media, obviating the need for compression
      in CTE
   or
   d. take the up-front pain of adding a handful of new CTEs now (with
      and w/o compression) and live with the one compression method
which pretty much leads back to my earlier observations about proliferation
of encoding tags vs. some means of specifying compression orthogonally to
encoding per se.  To which I would add that given the end-to-end nature
of MIME CTE, even a brute-force adaptive scheme (try N different compression
methods, pick the best and tag the data for decompression) is reasonable
(it would be unreasonable to do that on a hop-by-hop transport-level basis).
 
> > > For example, there's the scenario of sending a message containing
> > > a huge binary attachment.
> > 
> > For example a spreadsheet in application/vnd.ms-excel format. An order
> > of magnitude size reduction is typically possible via compression. I
> > have just such a spreadsheet; it is 428544 octets in native form and
> > 69674 octets in OpenOffice.org (compressed) .sxc format.
> 
> That's a bad example. The Excel format is a binary serialized object format
> unlike the XML OpenOffice.org format, so you've done a lossy conversion.

No, the information is all there (both formats can be opened in OpenOffice
and contain the same spreadsheet data).

> Compress the original spreadsheet, since that's what the CTE would do.

Whatever. 167572 octets. So compare:

428544 -> base64 -> 586429
428544 -> gzip-8bit -> 171266 (assuming about 2% increase for escapes and
1000/998 for CRLF line endings)

That's about a 3.4:1 size ratio between base64 and gzip-8bit.  Quite a
size difference, though (unsurprisingly) not as much of a difference as
using an optimized representation that works with compression (sxc format).

> For example, compressed filesystems solve this same storage space
> issue more efficiently at the system level,

It's not a storage space issue, it's an end-to-end issue.

> The bandwidth issue can be addressed transparently with TLS/SSL, or
> Apache/mod_gzip, etc. for any number of current applications.

TLS isn't end-to-end, and that does raise storage (and CPU) issues.
Moreover, it doesn't address some of the application-level issues (see
below).
 
> Of course, all these transparent ways must be implemented and deployed
> just the same, but what is the serious long term benefit in making MIME
> carry CTEs? Every MIME aware application will have to be adapted to
> read those new encodings.

See Harald's message.

Look at the costs associated with your alternative for a 3-hop
message transfer using TLS and filesystem compression:
1. compress in TLS from source on first hop, decompress at receiver
2. compress again in filesystem for local storage, decompress on read
3. compress in TLS from 1st to second hop, decompress at receiver
4. compress yet again in filesystem for local storage, decompress on read
5. compress again in TLS for 3rd hop, decompress at receiver
and that still doesn't address SMTP size limits, since those apply
between TLS decompression and filesystem compression.  That's a lot of
repetitive compression and decompression, a lot of software at several
sites that needs to be updated, and it still doesn't address an important
issue.  Nor is it adaptive to the needs of different media types.

Compared to an end-to-end solution where the issues are addressed
and only the endpoints need be concerned with compression and decompression.

-----
* similar for video: a 5394004 octet MPEG file is "compressed" by gzip
  to 5260869 octets.  MP3 audio is left as an exercise for the reader.
  Incidentally, if one tries to compress that sxc spreadsheet with gzip,
  one goes from 69674 octets to 68051 octets.

Date: Wed, 29 Jun 2005 11:03:51 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Jun 28 2005, Bruce Lilly wrote:
> On Mon June 27 2005 21:00, Laird Breyer wrote:
> > 
> > On Jun 27 2005, Bruce Lilly wrote:
> 
> > That's correct, but surely it's the way it should be: if some network
> > admin wants to allow faster transfers to his users, then he'll set up
> > the software.
> 
> 1. the bottleneck might be elsewhere, known to the originator, but
>    unknown to the network operator
> 2. That still implies 3749 support at the operator's side
> 3. it assumes that the end user knows enough to/can/will install
>    TLS support including the 3749 extension

These are pretty standard objections, which apply to software updates,
whether for TLS support or MIME/CTE. They don't serve as a strong
differentiator in favour of either approach.

>  
> > > Such compression cannot work around e.g. SMTP message size limits as
> > > the message would be stored in uncompressed form.
> > 
> > Which SMTP size limits are those?
> 
> See RFC 1123 section 5.3.8.

Seems a little outdated ;-) 

> 
> > I'm not convinced that it is the job of the message format to make 
> > storage easier or smaller.
> 
> We're talking about MIME, not the Message Format.  MIME does a number
> of things to work around transport issues.  A side-effect of some of those
> (notably the two non-identity encodings) is a substantial increase in
> message size.  Additional encodings that do not substantially increase
> message size would be welcome.  If they can decrease message size, so
> much the better.
> 

I accept that, but we are on the 822 list. It's still important to identify
whether and how changes to MIME can affect email.

(snip accepted points)

> > > There are two distinct issues at work:
> > > 1. encoding binary data to fit into 8bit (as opposed to 7bit) transport
> > >    can be done in a more space-efficient manner than is possible with
> > >    binary-to-7bit encoding
> > > 2. compression for size reduction of stored/transmitted content
> > 
> > I'd like to understand these points better. What kind of space saving
> > scenario do you have in mind?
> 
> For binary data, base64 encoding uses a 3:4 encoding with insertion of
> a CRLF pair after at most every 76 octets of output.  That's an expansion
> factor of 4 / 3 * 78 / 76 or 26:19 or about a 37% (minimum) increase in
> size.  For binary data, quoted-printable typically expands data by a much
> greater factor; quoted-printable should probably be viewed as an ISO-8859
> text 8bit-to-7bit encoding.

Yes, I understand that, I'm just asking for scenarios to get an idea of
whether the cost and complexity of introducing CTEs is outweighed by
substantial benefits.

A mere 37% space saving doesn't seem worth it to me if it comes
at the cost of human readability and brittleness (change 1 byte in a
compressed stream and you can generally throw the whole thing away -
not so with text). 

Even if you're transferring say an MPEG video stream,
there are key frames which allow small random corruptions to be ignored.
But compress the video, and you can throw it away if there's a corruption. 

>  
> > For example, there's the scenario of sending a message containing
> > a huge binary attachment.
> 
> For example a spreadsheet in application/vnd.ms-excel format. An order
> of magnitude size reduction is typically possible via compression. I
> have just such a spreadsheet; it is 428544 octets in native form and
> 69674 octets in OpenOffice.org (compressed) .sxc format.

That's a bad example. The Excel format is a binary serialized object format
unlike the XML OpenOffice.org format, so you've done a lossy conversion.
Compress the original spreadsheet, since that's what the CTE would do.

> 
> > Arguably in that case, the sender is misusing 
> > email as a file transfer facility, and should only send instructions on
> > how to retrieve the file separately.
> 
> You are assuming that:
> 1. the sender has a way to store the file such that it can be retrieved
>    by others w/o corruption
> 2. that bandwidth from the sender to the hypothetical storage place
>    isn't an issue
> 3. that size isn't an issue at the hypothetical storage place 
> 4. that all recipients are able to retrieve files by the same hypothetical
>    method
> 5. that bandwidth at each recipient's side is not an issue
> 6. that such an arrangement is agreeable to the sender and all recipients

Look, my main objection is that there are ways to deal with some of
these issues in transparent ways.

For example, compressed filesystems solve this same storage space
issue more efficiently at the system level, and without the need to
introduce CTE handling logic in applications. Files can't be
substantially compressed twice, so having both a CTE and a compressed
filesystem wouldn't substantially increase capacity.

The bandwidth issue can be addressed transparently with TLS/SSL, or
Apache/mod_gzip, etc. for any number of current applications.

Of course, all these transparent ways must be implemented and deployed
just the same, but what is the serious long term benefit in making MIME
carry CTEs? Every MIME aware application will have to be adapted to
read those new encodings.

-- 
Laird Breyer.

Date: Tue, 28 Jun 2005 22:43:55 +0200
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

I'd very much like to see the deflate-8bit and deflate-base64 C-T-Es 
formally defined.

If someone identifies a niche for which they can be introduced sensibly, 
they will be able to deploy them, rather than inventing Yet Another 
Compression Scheme. If nobody starts using them seriously, well.... we've 
lost some time, and an RFC number or two. Big deal. We've done that any 
number of times, for any number of things (remember the MODEL top level 
type? Who's hurt by having it around?)

(The time of the authors/reviewers/IESG is the expensive part, 
unfortunately :-()

                         Harald

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: gzip/deflate compression/encoding
Date: Tue, 28 Jun 2005 07:02:13 -0400
Sender: [email-masked]

On Mon June 27 2005 21:00, Laird Breyer wrote:
> 
> On Jun 27 2005, Bruce Lilly wrote:

> That's correct, but surely it's the way it should be: if some network
> admin wants to allow faster transfers to his users, then he'll set up
> the software.

1. the bottleneck might be elsewhere, known to the originator, but
   unknown to the network operator
2. That still implies 3749 support at the operator's side
3. it assumes that the end user knows enough to/can/will install
   TLS support including the 3749 extension
 
> > Such compression cannot work around e.g. SMTP message size limits as
> > the message would be stored in uncompressed form.
> 
> Which SMTP size limits are those?

See RFC 1123 section 5.3.8.

> I'm not convinced that it is the job of the message format to make 
> storage easier or smaller.

We're talking about MIME, not the Message Format.  MIME does a number
of things to work around transport issues.  A side-effect of some of those
(notably the two non-identity encodings) is a substantial increase in
message size.  Additional encodings that do not substantially increase
message size would be welcome.  If they can decrease message size, so
much the better.

> In fact, the best compression can only be achieved 
> by the final destination system, because it can combine the characteristics
> of all received messages in optimal ways. 

You are assuming that the sole criterion is storage size on the ultimate
destination system, which is not a criterion at all in the current
discussion.

> > Indicating the fact of compression and the method by...? (w/o obscuring
> > the nature of the media type that is compressed)
> 
> What's wrong with an application/gzip (or similar) attachment and a 
> Content-Description field which tells the user what's inside?

It obscures the nature of the media type that is compressed.  From that
there is no machine-readable way to determine whether it's text, image,
audio, video, or model data.  It's claimed to be application data.  If
the data is in fact a composite media type (message or multipart) your
scheme won't work at all (within the MIME framework) (of course, a
transfer encoding can't be applied overall either, but can be applied to
individual parts of the composite entity).

The Content-Description field is not machine-readable; it is a
human-readable unstructured field.  Suppose the content is being sent
to a mailing list which is expanded to a hundred recipients, each of which
speaks a different language from the others.  What would you put in a
Content-Description field such that it wouldn't be larger than any other
message component and wouldn't imply some sort of favoritism?
 
> > There are two distinct issues at work:
> > 1. encoding binary data to fit into 8bit (as opposed to 7bit) transport
> >    can be done in a more space-efficient manner than is possible with
> >    binary-to-7bit encoding
> > 2. compression for size reduction of stored/transmitted content
> 
> I'd like to understand these points better. What kind of space saving
> scenario do you have in mind?

For binary data, base64 encoding uses a 3:4 encoding with insertion of
a CRLF pair after at most every 76 octets of output.  That's an expansion
factor of 4 / 3 * 78 / 76 or 26:19 or about a 37% (minimum) increase in
size.  For binary data, quoted-printable typically expands data by a much
greater factor; quoted-printable should probably be viewed as an ISO-8859
text 8bit-to-7bit encoding.
 
> For example, there's the scenario of sending a message containing
> a huge binary attachment.

For example a spreadsheet in application/vnd.ms-excel format. An order
of magnitude size reduction is typically possible via compression. I
have just such a spreadsheet; it is 428544 octets in native form and
69674 octets in OpenOffice.org (compressed) .sxc format.

> Arguably in that case, the sender is misusing 
> email as a file transfer facility, and should only send instructions on
> how to retrieve the file separately.

You are assuming that:
1. the sender has a way to store the file such that it can be retrieved
   by others w/o corruption
2. that bandwidth from the sender to the hypothetical storage place
   isn't an issue
3. that size isn't an issue at the hypothetical storage place 
4. that all recipients are able to retrieve files by the same hypothetical
   method
5. that bandwidth at each recipient's side is not an issue
6. that such an arrangement is agreeable to the sender and all recipients
 
> Another scenario is the case of an SMTP agent being overwhelmed by
> large message numbers such as spam.

Not a criterion.

Date: Tue, 28 Jun 2005 12:07:17 +1000
From: Laird Breyer <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: Ned Freed <[email-masked]>, Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>
Sender: [email-masked]

On Jun 27 2005, Ned Freed wrote:
> 
> Of course this leaves open exactly what compression/encoding pairs
> need to be defined for use as CTEs. As you say, there are potentially
> five of them, but I only see three that are genuinely useful:
> 
>    binary-8bit
>    deflate-8bit
>    deflate-base64
>    deflate-binary
> 
> Of these I see little value in the last, but the others all make good sense.

There's another potential problem with CTEs that occurred to me,
namely inherent brittleness. The text based formats are largely robust
to localized corruptions such as line splitting etc., and were
obviously designed with that intent. However, small corruptions can
irrecoverably destroy compressed data streams. 

So I would be hesitant to recommend CTE usage for textual data on
principle, even if it is 8bit internationalized. As a long term
storage medium, it is much more important that the RFC 2822 format
allows graceful degradation rather than a 2x-5x typical size reduction.

-- 
Laird Breyer.

Date: Tue, 28 Jun 2005 11:00:00 +1000
From: Laird Breyer <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: ietf-822 <[email-masked]>
Sender: [email-masked]

On Jun 27 2005, Bruce Lilly wrote:
> On Sun June 26 2005 23:51, Laird Breyer wrote:
> 
> > Since support for compression is already built into the TLS protocol
> > by RFC 3749, the benefit in lower bandwidth requirements and faster
> > transfer can be achieved today as long as both the server and client use
> > this feature.
> 
> That's a big "if".  Obviously, that's only hop-by-hop, and it doesn't
> apply it TLS isn't available, or with TLS implementations that do not
> support the RFC 3749 extension.

That's correct, but surely it's the way it should be: if some network
admin wants to allow faster transfers to his users, then he'll set up
the software.  Given the general fuss about authentication and
security of email services, TLS is already likely to be used or on the
list of things to be used.

> 
> Such compression cannot work around e.g. SMTP message size limits as
> the message would be stored in uncompressed form.

Which SMTP size limits are those? I had a quick check on my copy
of RFC 2821 (page 55) and I don't see any hard limits on the total 
message size. There's the SIZE extension and there are standards for
splitting a message into pieces.

I'm not convinced that it is the job of the message format to make 
storage easier or smaller. In fact, the best compression can only be achieved
by the final destination system, because it can combine the characteristics
of all received messages in optimal ways. 

> 
> > On the other hand, the message sender is already free to compress his
> > attachments any way desired,
> 
> Indicating the fact of compression and the method by...? (w/o obscuring
> the nature of the media type that is compressed)

What's wrong with an application/gzip (or similar) attachment and a 
Content-Description field which tells the user what's inside?

> 
> There are two distinct issues at work:
> 1. encoding binary data to fit into 8bit (as opposed to 7bit) transport
>    can be done in a more space-efficient manner than is possible with
>    binary-to-7bit encoding
> 2. compression for size reduction of stored/transmitted content

I'd like to understand these points better. What kind of space saving
scenario do you have in mind?

For example, there's the scenario of sending a message containing
a huge binary attachment. Arguably in that case, the sender is misusing
email as a file transfer facility, and should only send instructions on
how to retrieve the file separately.

Another scenario is the case of an SMTP agent being overwhelmed by
large message numbers such as spam. In that case, a compressed 
attachment format would make a difference, but it relies on the sending
parties actually using the compressed transfer encoding as intended.

-- 
Laird Breyer.

From: [email-masked]
Cc: [email-masked], Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
To: Bill Janssen <[email-masked]>
Date: Mon, 27 Jun 2005 17:44:56 -0700 (PDT)
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

> > However, I'm still not seeing the sort of community interest that's really
> > needed to get this off the ground. (In fact I'm see pretty much the opposite.)

> Perhaps not in the mail community, but MIME media-types are used in
> many other Web-centric applications, some of which would like to
> compress all that XML that's in one part of a multipart body.  A CTE
> like "deflate-8bit" would be great for that.

Point taken and thanks for the input.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: gzip/deflate compression/encoding
Date: Mon, 27 Jun 2005 14:17:57 -0400
Sender: [email-masked]

On Mon June 27 2005 10:58, [email-masked] wrote:

> (1) Put some sort of "escape" label in the CTE field saying that
>     content-compression needs to be looked at.
> (2) Bump the MIME-Version value to 2.0.

Changing C-T-E semantics itself would probably warrant changing the
version.

I'm not convinced that 2.0 is the next step (as opposed to 1.1 for
example).

> is fundamental: An existing, standards-compliant client seees this and thinks
> all it has to do is undo the base64 encoding and a bunch of text will pop out.
> But when it actually does this aa pile of binary goo appears instead. The
> resulting mess won't make users very happy even if clients handle it well, and
> the odds are good they won't.

True.
 
> Now, many folks believe bumping the MIME version is not possible. I'm
> personally not convinced of that, but I do think it would be hugely difficult.
> Bumping it just to get a compression field added strikes me as way too
> much trouble for way too little gain, so (2), while technically possible,
> is a practical nonstarter IMO.

Another change-C-T-E method (again, probably warranting a version change)
would be to change the syntax to permit a list of keywords, so e.g. one
could have
 Content-Transfer-Encoding: 7bit
 Content-Transfer-Encoding: deflate
 Content-Transfer-Encoding: deflate, base64
etc.
 
> Embedding compression information in the CTE is, OTOH, entirely doable. And
> not only was this understood back when MIME was first standardized, the
> reason we didn't define content-compression or something similar is exactly
> because this possibility existed and there was no real need for
> content-compression.
> 
> Of course this leaves open exactly what compression/encoding pairs
> need to be defined for use as CTEs. As you say, there are potentially
> five of them, but I only see three that are genuinely useful:
> 
>    binary-8bit
>    deflate-8bit
>    deflate-base64
>    deflate-binary
> 
> Of these I see little value in the last, but the others all make good sense.

Compression alone may be useful for transmitting large, sparse binary
files efficiently (e.g. files containing long runs of NUL octets).  Of
course, that requires binary transport (e.g. ftp via message/external-body
or SMTP BINARYMIME).
 
> However, I'm still not seeing the sort of community interest that's really
> needed to get this off the ground. (In fact I'm see pretty much the opposite.)

There are disadvantages to all of the approaches.  For adding encodings,
the primary disadvantage is:
o add 3 encodings per compression scheme (suppose somebody comes up with
  a scheme better than deflate)

The alternative ideas address that issue.  Push here, something else
pops out there.

A binary-to-8bit encoding scheme would work with SMTP 8BITMIME where
available even if BINARYMIME is not supported, and with other protocols
(IMAP, NNTP) which support 8bit but not binary content transfer.  That
may have some use independent of the compression issue, so maybe that
could be standardized now, deferring the compression issue until there
is interest in it.

Date: Mon, 27 Jun 2005 18:06:27 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

Bruce Lilly writes:
> On Sun June 26 2005 23:51, Laird Breyer wrote:
>>  Since support for compression is already built into the TLS protocol 
>>  by RFC 3749, the benefit in lower bandwidth requirements and faster 
>>  transfer can be achieved today as long as both the server and 
>>  client use this feature.
>
> That's a big "if". Obviously, that's only hop-by-hop, and it doesn't 
> apply it TLS isn't available, or with TLS implementations that do not 
> support the RFC 3749 extension.

On the other hand, using 3749 doesn't have compatibility problems with 
today's installed firewalls and other software, and if either peer 
doesn't support 3749, the connection gracefully degrades. Nothing 
breaks with "unknown c-t-e" errors.

Advantages and disadvantages.

Arnt

From: [email-masked]
Cc: ietf-822 <[email-masked]>, [email-masked]
To: Bruce Lilly <[email-masked]>
Date: Mon, 27 Jun 2005 07:58:45 -0700 (PDT)
Subject: Re: gzip/deflate compression/encoding
Sender: [email-masked]

> o A Content-Compression field, field body consists of a registered keyword.

I'm afraid this is a total and complete nonstarter unless you either:

(1) Put some sort of "escape" label in the CTE field saying that
    content-compression needs to be looked at.
(2) Bump the MIME-Version value to 2.0.

The problem with doing something like:

   MIME-Version: 1.0
   content-type: text/plain
   content-transfer-encoding: base64
   content-compression: deflate

is fundamental: An existing, standards-compliant client seees this and thinks
all it has to do is undo the base64 encoding and a bunch of text will pop out.
But when it actually does this aa pile of binary goo appears instead. The
resulting mess won't make users very happy even if clients handle it well, and
the odds are good they won't.

Now, many folks believe bumping the MIME version is not possible. I'm
personally not convinced of that, but I do think it would be hugely difficult.
Bumping it just to get a compression field added strikes me as way too
much trouble for way too little gain, so (2), while technically possible,
is a practical nonstarter IMO.

And the problem with doing something like

   MIME-Version: 1.0
   content-type: foo/bar
   content-transfer-encoding: see-other-fields
   content-compression: deflate
   content-other-encoding-field: base64

is that it creates a whole lot of bother for no good reason.

Embedding compression information in the CTE is, OTOH, entirely doable. And
not only was this understood back when MIME was first standardized, the
reason we didn't define content-compression or something similar is exactly
because this possibility existed and there was no real need for
content-compression.

Of course this leaves open exactly what compression/encoding pairs
need to be defined for use as CTEs. As you say, there are potentially
five of them, but I only see three that are genuinely useful:

   binary-8bit
   deflate-8bit
   deflate-base64
   deflate-binary

Of these I see little value in the last, but the others all make good sense.

However, I'm still not seeing the sort of community interest that's really
needed to get this off the ground. (In fact I'm see pretty much the opposite.)

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: gzip/deflate compression/encoding
Date: Mon, 27 Jun 2005 10:34:05 -0400
Sender: [email-masked]

On Sun June 26 2005 23:51, Laird Breyer wrote:

> Since support for compression is already built into the TLS protocol
> by RFC 3749, the benefit in lower bandwidth requirements and faster
> transfer can be achieved today as long as both the server and client use
> this feature.

That's a big "if".  Obviously, that's only hop-by-hop, and it doesn't
apply it TLS isn't available, or with TLS implementations that do not
support the RFC 3749 extension.

Such compression cannot work around e.g. SMTP message size limits as
the message would be stored in uncompressed form.

> On the other hand, the message sender is already free to compress his
> attachments any way desired,

Indicating the fact of compression and the method by...? (w/o obscuring
the nature of the media type that is compressed)

There are two distinct issues at work:
1. encoding binary data to fit into 8bit (as opposed to 7bit) transport
   can be done in a more space-efficient manner than is possible with
   binary-to-7bit encoding
2. compression for size reduction of stored/transmitted content

> and introducing a compressed transfer encoding 
> will seriously complicate MIME decoders.

It will add standard encodings, of course, and MIME decoders claiming
conformance to the encoding specification(s) would presumably have to
support them.  If the combination of compression and encoding is handled
by a Content-Transfer-Encoding tag alone, the possibly desirable
combinations might include:
1. binary compression alone
2. binary-to-8bit encoding alone
3. combination of binary compression followed by binary-to-8bit encoding
4. combination of binary compression followed by binary-to-7bit encoding
   (presumably base64)
That would expand the current 5 tags (quoted-printable, base64, 7bit, 8bit,
binary) to as many as 9 tags.

As an alternative, if a separate MIME extension field and associated 
mechanism were developed for compression, the only encoding that is missing
from the current lineup is binary-to-8bit.

A rough outline of how that might work:
o A Content-Compression field, field body consists of a registered keyword.
o Possibly provision for private-use unregistered (x-) tags.
o Initially defined keyword could be "gzip".
o An IANA registry for compression keywords and an associated registration
  procedure.
o possibly a provision for field parameters, including provision for a
  filename parameter for use in the event that a compression method is
  unrecognized or where an implementation may wish to use an intermediate
  file between decoding and decompression
o When compressing and encoding, compression is applied to media first,
  then encoding is applied to the compressed (binary) data.
o When decompressing and decoding, decoding is performed first, yielding
  binary data which is uncompressed to yield the base media.
o Obviously, if only compression or encoding/decoding applies, there is no
  need to worry about the order of processing.
o if an encoding tag is unrecognized by a receiving implementation, no
  processing takes place (ideally with a notification to the user)
o Security considerations related to the compression method

Clearly, implementations claiming conformance with such a specification
would need to support compression and decompression (library code exists
for that purpose).  With compression indicated orthogonally to encoding,
a single compression method and a single new encoding, coupled with the
existing encodings, would suffice to cover all four combinations listed
above.

If a receiving implementation supports encoding but not compression, there
are two cases:
A. the encoding (e.g. base64) is recognized and the content is decoded.
   That leaves binary data which can be saved to a file and manually
   decompressed.
B. the encoding is not recognized. Same situation applies as for a set of
   new encoding tags which are unrecognized.  Manual decoding and
   decompression can be used.

Date: Mon, 27 Jun 2005 13:51:13 +1000
From: Laird Breyer <[email-masked]>
To: [email-masked]
Subject: Re: gzip/deflate compression/encoding
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

This conversation seems to have started off the ietf-822 list, but
I assume it refers to draft-freed-newenc-00.txt or similar?
Otherwise, please advise if the following is off topic.

I don't see the benefit of complicating the mail message format with
compression methods. 

Since support for compression is already built into the TLS protocol
by RFC 3749, the benefit in lower bandwidth requirements and faster
transfer can be achieved today as long as both the server and client use
this feature.

On the other hand, the message sender is already free to compress his
attachments any way desired, and introducing a compressed transfer encoding
will seriously complicate MIME decoders.

Am I missing something in this discussion?

Laird Breyer.   

Date: Sun, 26 Jun 2005 23:56:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: gzip/deflate compression/encoding
Cc: Dan Kohn <[email-masked]>, Bruce Lilly <[email-masked]>, Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

IMNSHO, a protocol extension will succeed only if implementing it brings 
value to the user. If implementing e.g the SMTP MUMBLE extension 
doesn't benefit either the implementor or the user, and does benefit 
someone else greatly, then that extension isn't going to be implemented 
very much.

I may be wrong, of course. But let's suppose I'm right. In that case:

1. Mobile MUAs get considerable benefit from compressing messages as 
they go from/to the server, so an SMTP/POP/IMAP extension to provide 
compression for all messages or all attachments ought to be fairly 
widely implemented by authors of such MUAs (and likely seldom by 
others).

2. Even mobile MUAs don't get much benefit from c-t-e: deflate, since 
that works only when both the message sender and all receivers support 
it, which'll be fairly seldom. Authors of clients who assume ethernet 
to the server almost never get any benefit.

Arnt

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: Ned Freed <[email-masked]>
Subject: gzip/deflate compression/encoding
Date: Sat, 25 Jun 2005 09:59:00 -0400
Cc: [email-masked], [email-masked], Dan Kohn <[email-masked]>
Sender: [email-masked]

On Fri June 24 2005 17:36, Ned Freed wrote:

> FWIW, I would be happy to revive the draft if there is any interest.
> The last time I tried this the silence was fairly deafening, however.

It probably makes sense, though as noted last time, there may be some
benefit to decoupling compression and encoding binary->8-bit:
o some binary content, e.g. http://users.erols.com/blilly/mparse/tm35
  body content, won't compress well and may in fact be expanded by gzip
  "compression".
o combining compression and encoding can yield benefits even for 8-bit
  content encoded to a 7-bit transport. E.g. given a 1 MB 8-bit text
  source, compression will typically yield approx. 500 kB binary
  compressed data.  Base64 encoding will expand that by about 26:19
  (4/3 * 78/76) yielding about 684 kB which is obviously smaller than
  what encoding alone would yield.
o similarly, binary content could be compressed and encoded for 7bit
  transport, yielding a size reduction compared to encoding alone.
o Continuing along the same lines, large 7-bit content could be
  compressed and encoded for 7-bit transport to yield an overall size
  reduction, e.g. if one part of the transport path is known to be a
  low-bandwidth or size-constrained bottleneck (typically 1 MB -> 684 kB
  as detailed above).
o compression could be used even where binary transport is available
  (though it's a stretch to call that an "encoding") without the need
  to hide the nature of the original media type by wrapping the compressed
  data in a label identifying the data as "application/x-gzip" or
  "application/octet-stream".

I found out yesterday that 8BITMIME works much more widely than expected,
so this probably should be handled separately from the USEFOR WG (which
is already behind schedule with its work items).  Accordingly, I've
copied the ietf-822 list and set Reply-To to point there.

> I should also mention that Dan and I saw no problem, and indeed some benefit,
> from combining the two drafts.

If you think I can be of assistance, feel free to contact me off-list(s).

Date: Fri, 10 Jun 2005 14:03:58 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

>     Whatever you do, I don't want replies
>     sent to the From address, because that is a role account read by
>     several people, but this brain-dead Gatesware won't let me change it."
[...]
> And yes, Gatesware is indeed brain-dead, but notoriously resistant to
> being fixed :-( .

If MS can't implement From correctly, what makes you think they can
implement a new header field correctly?

To: [email-masked]
Xref: clerew local.mime:4799
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Fri, 10 Jun 2005 15:05:04 GMT
Lines: 46
Sender: [email-masked]

In <[email-masked]> Alan Barrett <[email-masked]> writes:

>On Thu, 09 Jun 2005, Charles Lindsey wrote:
>> We need:
>> 1. A header to be set by the list maintainer.
>> 2. A header to be set by the user, to control where replies to list go
>> (and in particular whether he gets a private copy or not).
>> 3. A header to be set by the user to control where personal (non-list)
>> replies go.
>> 
>> And rules to determins which takes priority if they conflict.
>> 
>> I think it is clear that Reply-To is the proper header for #3.

>No, it's not at all clear that "Reply-To:" is the proper header for #3.
>#3 should be separated into cases where "From:" is the proper header,
>and cases where it is not.  "Reply-To:" is currently used for both #2
>and #3 (and is sometimes even used for the subset of case #3 where
>"From:" would have been more appropriate).

Reply-To does not provide the needed flexibility.

You want to say

    "Please reply to the list, and I don't want a personal copy in that
    case. OTOH, if you want to discuss this with me privately off-list,
    then please reply to XXXXXX. Whatever you do, I don't want replies
    sent to the From address, because that is a role account read by
    several people, but this brain-dead Gatesware won't let me change it."

You can't specify all that in Reply-To. Ergo you need (at least) one more
header.

And yes, Gatesware is indeed brain-dead, but notoriously resistant to
being fixed :-( .

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Understanding response protocols
Date:  Fri, 10 Jun 2005 02:40:42 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:
 
> The last thing we need are more headers and more rules to
> make the situation more complex for the recipient who is
> trying to compose a reply.

+1

As far as I'm concerned I'm happy with what my UA does behind
a mail2news gateway.  If that's also the case with your UA all
you need is a "news emulation mode" maybe based on the List-ID
+ a configurable list adress.
                              Bye, Frank

Date: Thu, 9 Jun 2005 22:25:24 +0200
From: Alan Barrett <[email-masked]>
To: [email-masked]
Subject: Re: Understanding response protocols
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, 09 Jun 2005, Charles Lindsey wrote:
> We need:
> 1. A header to be set by the list maintainer.
> 2. A header to be set by the user, to control where replies to list go
> (and in particular whether he gets a private copy or not).
> 3. A header to be set by the user to control where personal (non-list)
> replies go.
> 
> And rules to determins which takes priority if they conflict.
> 
> I think it is clear that Reply-To is the proper header for #3.

No, it's not at all clear that "Reply-To:" is the proper header for #3.
#3 should be separated into cases where "From:" is the proper header,
and cases where it is not.  "Reply-To:" is currently used for both #2
and #3 (and is sometimes even used for the subset of case #3 where
"From:" would have been more appropriate).

--apb (Alan Barrett)

Date: Thu, 9 Jun 2005 14:24:35 -0400
From: Keith Moore <[email-masked]>
To: ietf-822 <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> > Some MUAs (e.g. Apple's Mail.app) are even worse in that
> > they require you to copy and paste one address at a time.  Often you
> > end up having to resize and/or move the compose and mail reader windows
> > so that you can have the relevant portions of each on the screen at the
> > same time.
> > 
> > Frankly, this sucks dead pigs through a straw.
> 
> If it hurts, don't do it:
> o Pick a better UA
> o Roll your own
> o Complain to the vendor

One or more of those would solve the problem for me.  I'm trying to 
address the larger problem that email is made dysfunctional for everyone
because of lousy reply behavior.

> >> We need [...] A header to be set by the list maintainer.
> > Yes, but only after we get MUAs to improve their UIs.
> 
> Blocked by too much cruft in the message header, leading to UA developers
> who understandably by default hide most header fields. 

There are better ways to display the information in many of those header fields 
than to display the fields themselves, and many MUAs already do that.  Reply-To 
is just one example of a field that isn't effectively presented at present.

> There are other UI issues.  For example, how far down the legal
> "look-and-feel" rathole would you like to go?

I don't think we can specify look-and-feel.  I do think that we can encourage
better MUA behavior, probably through an Informational document.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 9 Jun 2005 14:10:31 -0400
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

On Thu June 9 2005 12:38, Keith Moore wrote:

> Some MUAs (e.g. Apple's Mail.app) are even worse in that
> they require you to copy and paste one address at a time.  Often you
> end up having to resize and/or move the compose and mail reader windows
> so that you can have the relevant portions of each on the screen at the
> same time.
> 
> Frankly, this sucks dead pigs through a straw.

If it hurts, don't do it:
o Pick a better UA
o Roll your own
o Complain to the vendor

>> We need [...] A header to be set by the list maintainer.
> Yes, but only after we get MUAs to improve their UIs.

Blocked by too much cruft in the message header, leading to UA developers
who understandably by default hide most header fields.  Note that the
proposed change will make that underlying problem worse, not better.
[I'm working on a solution to that and some related problems, but it
will be awhile before there's a set of drafts to poke holes in, and as
with anything that involves "change the UAs", it will be a slow
evolutionary process]

There are other UI issues.  For example, how far down the legal
"look-and-feel" rathole would you like to go?

Date: Thu, 9 Jun 2005 12:38:46 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >- Even when people hit the right button, (i.e. "reply to author" or
> >  "reply all") the behavior of an MUA in the presence of reply-to or
> >  other header fields is often surprising to the user, because these
> >  fields are either difficult to notice or not displayed at all.
> 
> In every mail agent I have used, the compose window starts out showing
> editable fields for To: and Cc:. So if you don't like what it offers
> initially, you just change it. 

And if you want to change between any one of
{ reply-to-author, reply-to-all, reply-to-list, reply-to-reply-to }
and another, you have to click on the original message window, copy the
addresses from a header field (which may or may not be visible), click
on the compose window, paste those addresses into the appropriate box,
and repeat for each header field from which you need to grab
addresses.  Some MUAs (e.g. Apple's Mail.app) are even worse in that
they require you to copy and paste one address at a time.  Often you
end up having to resize and/or move the compose and mail reader windows
so that you can have the relevant portions of each on the screen at the
same time.

Frankly, this sucks dead pigs through a straw.

But it's not just that editing those fields is cumbersome.  Present MUAs
don't make it adequately clear when the default behavior of a reply command
is altered by reply-to or some other header in the subject message.

> >Just in case it isn't clear, I have no objection to defining a new header field
> >which is set by lists (and only by lists), and which says in effect, "if you 
> >want to reply to the list, use this address."  However, without substantial
> >changes to the UIs of MUAs, such a field won't be terribly useful, and may
> >even be harmful if it produces less consistent behavior than at present.
> 
> We need:
> 1. A header to be set by the list maintainer.

Yes, but only after we get MUAs to improve their UIs.

> 2. A header to be set by the user, to control where replies to list go
> (and in particular whether he gets a private copy or not).

HELL NO.

> 3. A header to be set by the user to control where personal (non-list)
> replies go.

HELL NO.
 
> And rules to determins which takes priority if they conflict.

HELL NO.

The last thing we need are more headers and more rules to make the 
situation more complex for the recipient who is trying to compose a reply.
 
> >Note that such a field is NOT the same as Mail-Followup-To, which was 
> >intended to be set by message originators.  Trying to equate the two 
> >doesn't lend credibility to your arguments.
> 
> I believe the current intention for MFT is to cover both #1 and #2. That
> certainly is my reading of Jacob Palme's draft.

That would make MFT even worse than Dan's original suggestion.

Keith

To: [email-masked]
Xref: clerew local.mime:4793
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 9 Jun 2005 15:12:55 GMT
Lines: 53
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>- Even when people hit the right button, (i.e. "reply to author" or
>  "reply all") the behavior of an MUA in the presence of reply-to or
>  other header fields is often surprising to the user, because these
>  fields are either difficult to notice or not displayed at all.

In every mail agent I have used, the compose window starts out showing
editable fields for To: and Cc:. So if you don't like what it offers
initially, you just change it. I grant you that any agent that fails to
provide that is severely broken, but what agents are that bad?

[And, to confuse the issue, I discovered yesterday that Outlook provides
such a field entitled "From", but what you type in there actually turns
into the Reply-To header of the sent message, and the From header contains
what should have been in the Sender. Doh!]

>Just in case it isn't clear, I have no objection to defining a new header field
>which is set by lists (and only by lists), and which says in effect, "if you 
>want to reply to the list, use this address."  However, without substantial
>changes to the UIs of MUAs, such a field won't be terribly useful, and may
>even be harmful if it produces less consistent behavior than at present.

We need:
1. A header to be set by the list maintainer.
2. A header to be set by the user, to control where replies to list go
(and in particular whether he gets a private copy or not).
3. A header to be set by the user to control where personal (non-list)
replies go.

And rules to determins which takes priority if they conflict.

I think it is clear that Reply-To is the proper header for #3. Whether
you actually need separate headers for #1 and #2 is a topic for dicussion.

>Note that such a field is NOT the same as Mail-Followup-To, which was 
>intended to be set by message originators.  Trying to equate the two 
>doesn't lend credibility to your arguments.

I believe the current intention for MFT is to cover both #1 and #2. That
certainly is my reading of Jacob Palme's draft.

-- 
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: Wed, 8 Jun 2005 21:53:02 +0100 (BST)
From: Philip Hazel <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

I fully intended to stay out of this, because it is a well-known 
rathole, but ...

On Wed, 8 Jun 2005, Keith Moore wrote:

> - People often end up wanting to change the recipient list of a reply 
>   after they have started composing the text of a message, indicating that the 
>   "push the right reply button before you compose" model is broken.

I rarely want to change the recipient list, so I might dispute your 
"often". But when I do, my MUA allows me to. I don't think anyone 
disagrees with the notion that whatever button the user pushes, the MUA 
should construct some recipient list, and then let the user modify it if
he/she wishes.

> - It's not as if 95% of repliers want to do the same thing in every case.

In my case, at least 99.9% of the time, I hit "R" and "Y" in Pine to
"reply to all" when replying, either to personal or mailing list 
messages. Probably about 0.9% of the time I then modify the list of
recipients. The other 0.1% is when there is a message of such import
that I decide in advance that I want to do something unusual.

>   Small mistakes in communications can have large consequences.

That is certainly true.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

Date: Wed, 8 Jun 2005 14:32:26 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Understanding response protocols
Sender: [email-masked]

> >You are correct that Reply-To is not the solution to this problem,  
> >but the fact that Reply-To is better reserved for use by authors is  
> >NOT "exactly why" Reply-To is not the solution to the problem.  The  
> >reason that Reply-To is not the solution to the problem is that the  
> >decision about where a reply goes needs to be made by the person  
> >composing the reply, and NO set of header fields, no matter how you  
> >define them, can make this decision for that person.
> 
> But nobody has ever suggested that the person composing the reply should
> not have the final say.

Actually, that's not true either.  But I don't think this view is widely held,
and to name names would be to invite digression into a pointless discussion 
about who said what and what he meant by that.  Let's not go there.

> But if you want to provide hoops and popups to ask the user
> 
>    "The original sender wants you to send your reply to X, but you should
>    should be aware that you have a God given right to to send it somewhere
>    else, and you are advised to consider your options carefully before
>    just hitting 'send'."
> 
> then the 95% of people who are happy to just hit 'send' will be mightily
> pissed off.

Well, duh.   If you _try_ to make an annoying UI, of course it's going to
piss people off.  It's certainly possible to botch this UI so that it's annoying 
to the user, but it's not at all difficult to do well.  Which is why I provided
(if you cared to read it) an example of how it could be done _without_ hoops
or popups and without excessive or condescending dialogue. 

> Currently, we have the Reply-To header, and the usual behaviour of MUAs is
> to reply to that address when you hit 'send'.

Which - without a clear indication to the user that the result will be surprising,
and without an easy way for the user to override that behavior - is thoroughly
broken.

> All that is suggested is that there should be some further header(s) with
> the same property, namely MUAs will reply to that address when you hit
> 'reply-to-list'.

Which is even more broken (i.e. more complex, harder to use correctly)
than the current behavior.

(well, actually it's not "all that is suggested" - it may be all _you_ are 
suggesting at the moment but the number of harebrained ideas for fixing
reply is rather large.)

> Both Reply-To and MFT/whatever are headers provided by the original sender
> and/or the mailing list manager with the intent of influencing where
> replies should be sent. The first is existing practice and the second is a
> proposed future practice.

But experience indicates that existing practice is broken, so it's reasonable
to assume that further extensions along those lines will also be broken.

Also, there's a difference of opinion about whether MFT should be used
by lists.  Not surprisingly, the same kind of brokenness that's been
been observed with the use of Reply-To by lists seems to occur when MFT
is used by lists.

> But in both cases, it is reasonable to suppose that 95% of repliers will
> just hit the proper key and accept the default behaviour.

Your characterization is overly simplistic and contradicted by experience.

- When faced with multiple reply buttons, people often fail to use the right 
  one even when they are aware of it.  Since 9X% of the time people
  hit one button, they tend to hit that button without thinking even for the
  cases when it's not appropriate.

- People often end up wanting to change the recipient list of a reply 
  after they have started composing the text of a message, indicating that the 
  "push the right reply button before you compose" model is broken.

- Even when people hit the right button, (i.e. "reply to author" or
  "reply all") the behavior of an MUA in the presence of reply-to or
  other header fields is often surprising to the user, because these
  fields are either difficult to notice or not displayed at all.

- Often this surprising behavior isn't noticed until after the message is 
  sent, when it's too late to change it.

- It's not as if 95% of repliers want to do the same thing in every case.
  You need to look at a spectrum of repliers and what they want to do
  with a spectrum of mail messages.  It also should not be assumed that
  the remaining 5% of cases (or however many cases) are insigifnicant.
  Small mistakes in communications can have large consequences.

> If you are complaining that you do not like such behaviour for MFT, then
> logically wou must admit that you do not like it for Reply-To either. In
> that case, your quarrel is with implementors of existing MUAs, and if you
> want to start a campaign to have chem change their user interfaces, then
> go ahead.

I have two goals:

1. to change the behavior of existing MUAs
2. to discourage further brain-damage in MUA and header field design

They're not mutually exclusive, and they're related.

> But no way is your argument a valid objection to having another header, in
> addition to Reply-To, whose behaviour is broadly similar to Reply-To.

Just in case it isn't clear, I have no objection to defining a new header field
which is set by lists (and only by lists), and which says in effect, "if you 
want to reply to the list, use this address."  However, without substantial
changes to the UIs of MUAs, such a field won't be terribly useful, and may
even be harmful if it produces less consistent behavior than at present.

Note that such a field is NOT the same as Mail-Followup-To, which was 
intended to be set by message originators.  Trying to equate the two 
doesn't lend credibility to your arguments.

Keith

To: [email-masked]
Xref: clerew local.mime:4789
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Wed, 8 Jun 2005 11:20:12 GMT
Lines: 59
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>> Which is exactly why Reply-To is NOT the solution to this problem.

>You are correct that Reply-To is not the solution to this problem,  
>but the fact that Reply-To is better reserved for use by authors is  
>NOT "exactly why" Reply-To is not the solution to the problem.  The  
>reason that Reply-To is not the solution to the problem is that the  
>decision about where a reply goes needs to be made by the person  
>composing the reply, and NO set of header fields, no matter how you  
>define them, can make this decision for that person.

But nobody has ever suggested that the person composing the reply should
not have the final say.

But if you want to provide hoops and popups to ask the user

   "The original sender wants you to send your reply to X, but you should
   should be aware that you have a God given right to to send it somewhere
   else, and you are advised to consider your options carefully before
   just hitting 'send'."

then the 95% of people who are happy to just hit 'send' will be mightily
pissed off.

Currently, we have the Reply-To header, and the usual behaviour of MUAs is
to reply to that address when you hit 'send'.

All that is suggested is that there should be some further header(s) with
the same property, namely MUAs will reply to that address when you hit
'reply-to-list'.

Both Reply-To and MFT/whatever are headers provided by the original sender
and/or the mailing list manager with the intent of influencing where
replies should be sent. The first is existing practice and the second is a
proposed future practice.

But in both cases, it is reasonable to suppose that 95% of repliers will
just hit the proper key and accept the default behaviour.

If you are complaining that you do not like such behaviour for MFT, then
logically wou must admit that you do not like it for Reply-To either. In
that case, your quarrel is with implementors of existing MUAs, and if you
want to start a campaign to have chem change their user interfaces, then
go ahead.

But no way is your argument a valid objection to having another header, in
addition to Reply-To, whose behaviour is broadly similar to Reply-To.

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

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Wed, 8 Jun 2005 09:30:48 -0400
Cc: Ian Bell <[email-masked]>
Sender: [email-masked]

On Wed June 8 2005 04:08, Ian Bell wrote:

> ... but because of those clients' broken behaviour with respect to 
> text/unknown, the vendor would have been unable to make use of 
> text/paragraph to fix their problem without breaking their installed 
> base.

I think you mean "fixing their installed base" -- it was broken.

Date: Wed, 8 Jun 2005 09:08:33 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

This is a PGP signed message sent according to RFC3156 [PGP/MIME]

--=_Turnpike_EfvhKkG2dqpCRIqL=
Content-Type: text/plain;charset=us-ascii;format=flowed
Content-Transfer-Encoding: quoted-printable

In message <[email-masked]>, Bruce Lilly=20
<[email-masked]> writes
>On Tue June 7 2005 03:37, Ian Bell wrote:

text/paragraph was (briefly) proposed as a very simple way for programs=20
that currently send paragraphs as single lines in text/plain to be fixed=20
so that they can continue to send long lines but without breaking any=20
RFC.

However, most text/plain messages containing paragraphs sent as single=20
lines that I receive seem to be sent from Outlook and Outlook Express...

>> At the time that 2646 was written, Outlook and Outlook Express both
>> treated "text/unknown" as attachments (they may or may not still do
>> that).

>it is generally
>more appropriate to urge the vendor to fix the problem

... but because of those clients' broken behaviour with respect to=20
text/unknown, the vendor would have been unable to make use of=20
text/paragraph to fix their problem without breaking their installed=20
base.

Thus text/paragraph could not achieve its aim - at least as far as=20
Outlook/OE were concerned.

--=20
Ian Bell                                                 T U R N P I K E

--=_Turnpike_EfvhKkG2dqpCRIqL=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc

--=_Turnpike_EfvhKkG2dqpCRIqL=--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Folding of long lines in message bodies
Date:  Wed, 08 Jun 2005 01:55:48 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Bruce Lilly wrote:

>> There is no way of telling (because full headers are not
>> available) whether that messange was sent with
>> format=flowed, or not.

> The full message archive is available in text form, and you
> can (if you doubt my word) download it and verify that the
> part is labeled:
>   Content-Type: text/plain; charset=us-ascii; format=flowed

Grab last 1200 headers of the list on GMaNe, find the relevant
subject, note news: URL for the Message-ID, then replace the
part news://news by http://mid, use a browser to find the URI
where it's archived at GMaNe, add /raw at the end resulting in
<http://article.gmane.org/gmane.ietf.smime/5227/raw>

Not exactly the fastest way, but for you and Charles I dare not
propose to use obscure software like a newsreader and the URL
<news://news.gmane.org/[email-masked]>

                        Bye, Frank

From: "Hector Santos" <[email-masked]>
To: "ietf-822" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 16:51:54 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: "ietf-822" <[email-masked]>
Sent: Tuesday, June 07, 2005 11:49 AM
Subject: Re: Understanding response protocols

> > Oh boy!  There goes your modus operandi again!  Here we go again with
the 2
> > year old "Brucy" degrading every conversation ANYWAY or ANYWHERE when he
> > don't get his way!  Brucy,  are you capable of having an form of
> > non-confrontable conversion?  Nah, that is impossible!
>
> You are overreacting.  There was a polite request to fix a problem at
> your side.

Your request to remove you from the server's TWIT BLOCK filter list is
denied!  Unless, you can show a RFC that says "all mail from BRUCE" must be
accepted, your block will stay.

> > Clearly, you have no credentials in mail software designs.  Absolutely
no
> > brain for the matter. You are a paper pusher, doc pusher, technie
end-user.
> > No more, no less and when you can't hack it, you resort to put downs and
> > ad-nausem facts that are clearly not even in question.
>
> Your remarks, in addition to being untrue, are inappropriate.

Oh silly. Of course its true.

Look,  this forum is your heaven.  It is as Howard says, "Your reason for
living."  I can see that and like a child with candy, I will not take that
away from you.   But just to let you remind you, that your BS can be sensed
from as far as Miami! The above statement stands.

Ciao

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 10:39:35 -0400
Sender: [email-masked]

--Apple-Mail-2-279940661
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

>> Author (or author's UA per author's configuration) sets Reply-To:  
>> good.
>> List expander sets Reply-To: very bad.  RFC 2822 says "When the
>> "Reply-To:" field is present, it indicates the mailbox(es) to  
>> which the
>> author of the message suggests that replies be sent".  N.B. "author",
>> not anybody or anything else.
>
> Which is exactly why Reply-To is NOT the solution to this problem.

You are correct that Reply-To is not the solution to this problem,  
but the fact that Reply-To is better reserved for use by authors is  
NOT "exactly why" Reply-To is not the solution to the problem.  The  
reason that Reply-To is not the solution to the problem is that the  
decision about where a reply goes needs to be made by the person  
composing the reply, and NO set of header fields, no matter how you  
define them, can make this decision for that person.

> What is needed is some field that can be set by the Mailing-List  
> expander
> according to the default policy of the particular mailing list.  
> Yes, there
> need to be rules as to which takes priority when the poster and the
> expander have different ideas as to what they want, and there need  
> to be
> rules as to how the ultimate recipient can override the lot of them  
> if he
> wants to. But those are just details.

No, those aren't "just details"  - they are the most important aspect  
of getting it right.  In particular, the notion of "rules" and  
"priorities" that dictate where a reply goes is broken.  No proposal  
for solving this problem is going to succeed until it puts the person  
composing the reply in the loop.

> The usual case (95% of the time) is that both posters and  
> recipients will
> be happy to accept what the standard list policy decides.

While that may be true, it should not be inferred that the other 5%  
of the cases are unimportant, or that it's appropriate to treat the  
95% case as a default.

(95% of the time if you fall asleep at the wheel of your car, you  
will wake up before anything bad happens.  It's the other 5% that  
will eventually kill you if you make a habit of driving while asleep.)

The other thing to realize is that the 95% case (which I take to be  
an estimate of the percentage of time that a rule-based reply command  
will do what the replier wants to do anyway) isn't uniformly spread  
across mail users.  Some mail users don't participate in mailing  
lists and rarely send mail to more than one or two recipients.   
Chances are good that those users will never see a problem with Reply- 
To as it is currently implemented.  Again, the mistake is in assuming  
that what's good for that set of users is good for everybody.  They  
may even be the largest set of users, but they're not representative  
of the user population.

> They do NOT want to have to make different choices when posting on  
> account of different vagaries of different lists. They do NOT want  
> to be faced with loads of choices when replying. All they want  
> (both of them) is to press one button and have the "Right Thing"  
> happen.

It's certainly true that users don't want unnecessarily cumbersome  
user interfaces.  It's also true that at least some users want their  
computers to read their minds.  And it's also true that users don't  
like having replies go to the wrong place.

But it should not be assumed that giving people more choices about  
how to reply will make their user interfaces unnecessarily  
cumbersome.   It's not as if the only way to solve this problem is to  
put lots of different "reply" buttons on the reader window.  Actually  
as far as I can tell you want this selection to be part of the window  
associated with composing the reply, because the reply author wants  
to be able to change his mind while composing the reply about where  
the message should go, and he should be able to do this without  
having to cut and paste the subject and text of the reply that he is  
drafting.  So you might end up having only one "reply" button in the  
reader window, and a compose window that looks like:

[ Replying to: <x> author  <x> recipients < > reply-to < > list < >  
reset ]

To: [email-masked], _____________
Cc: [email-masked], [email-masked], _____________
Subject: foo bar

The reply author could click the boxes at the top of the window, and  
the addresses in the header of the message being composed would  
change to reflect the reply author's selections.  This would make the  
selection easy and unobtrusive.

The selection box at the top of the reply compose window could also  
change color to subtly indicate changes in the default selection due  
to the presence of a Reply-To or similar field.  Or the UA could  
alert the recipient to the presence of Reply-To fields by putting a  
message at the top of the compose window for the reply.  e.g.:

+----------------------------------------------------------------------- 
-----+
| ! The message you are replying to contains a suggested Reply-To  
address.   |
| You may override this suggestion by using the buttons below.   
[options]    |
+----------------------------------------------------------------------- 
-----+
[ Replying to: < > author  < > recipients <x> reply-to < > list < >  
reset ]

To: [email-masked], _____________
Cc: [email-masked], [email-masked], _____________
Subject: foo bar

and the [options] button could expand the pane to allow the user to  
customize the alerts on a per-sender basis, so that the user wouldn't  
have to see the warning every time he received a mail from a  
particular person who had a reply-to field in his message.  e.g.:

+----------------------------------------------------------------------- 
-----+
| ! The message you are replying to contains a suggested Reply-To  
address.   |
| You may override this suggestion by using the buttons  
below.               |
|                                                                        
      |
| < > always accept Reply-To from this author without warning  
me             |
| < > always ignore Reply-To from this  
author                                |
| <x> alert me when this author suggests Reply-To  
(default)                  |
|                                                                        
      |
| Regardless of which you select, you will always have the option  
of         |
| overriding the suggestion of a Reply-To  
field.                             |
+----------------------------------------------------------------------- 
-----+
[ Replying to: <x> author  <x> recipients < > reply-to < > list < >  
reset ]

To: [email-masked], _____________
Cc: [email-masked], [email-masked], _____________
Subject: foo bar

A similar mechanism could be used to handle a List-Reply-To or  
similar field.

The point of this example is not to specify what the user interface  
should look like.  The point is to demonstrate that far better user  
interfaces than what we're currently seeing are possible.  We need to  
design header fields that encourage and make it feasible for better  
user interfaces to exist and evolve, rather than designing fields  
that encourage dysfunctional user interfaces.

> And the present situation is that there is NO WAY that those 95% of  
> people can do that.

I think it's incorrect to assume that anywhere near 95% of the people  
prefer a solution that sometimes does the wrong thing without telling  
them.   A rule-based system might do the right thing for 95% of  
messages, but not for 95% of users.

Keith

--Apple-Mail-2-279940661
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE =
type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV>Author (or author's UA per =
author's configuration) sets Reply-To: good.</DIV><DIV>List expander =
sets Reply-To: very bad.=A0 RFC 2822 says "When =
the</DIV><DIV>"Reply-To:" field is present, it indicates the mailbox(es) =
to which the</DIV><DIV>author of the message suggests that replies be =
sent".=A0 N.B. "author",</DIV><DIV>not anybody or anything =
else.</DIV></BLOCKQUOTE><DIV><BR></DIV><DIV>Which is exactly why =
Reply-To is NOT the solution to this problem.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>You are correct that Reply-To is =
not the solution to this problem, but the fact that Reply-To is better =
reserved for use by authors is NOT "exactly why" Reply-To is not the =
solution to the problem.=A0 The reason that Reply-To is not the solution =
to the problem is that the decision about where a reply goes needs to be =
made by the person composing the reply, and NO set of header fields, no =
matter how you define them, can make this decision for that =
person.</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><DIV>What is needed is =
some field that can be set by the Mailing-List =
expander</DIV><DIV>according to the default policy of the particular =
mailing list. Yes, there</DIV><DIV>need to be rules as to which takes =
priority when the poster and the</DIV><DIV>expander have different ideas =
as to what they want, and there need to be</DIV><DIV>rules as to how the =
ultimate recipient can override the lot of them if he</DIV><DIV>wants =
to. But those are just details.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>No, those aren't "just details"=A0=
 - they are the most important aspect of getting it right.=A0 In =
particular, the notion of "rules" and "priorities" that dictate where a =
reply goes is broken.=A0 No proposal for solving this problem is going =
to succeed until it puts the person composing the reply in the =
loop.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE =
type=3D"cite"><DIV>The usual case (95% of the time) is that both posters =
and recipients will</DIV><DIV>be happy to accept what the standard list =
policy decides. <BR></DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>While that may be true, it =
should not be inferred that the other 5% of the cases are unimportant, =
or that it's appropriate to treat the 95% case as a =
default.=A0=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(95% of the time if you =
fall asleep at the wheel of your car, you will wake up before anything =
bad happens.=A0 It's the other 5% that will eventually kill you if you =
make a habit of driving while asleep.)</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>The other thing to realize is =
that the 95% case (which I take to be an estimate of the percentage of =
time that a rule-based reply command will do what the replier wants to =
do anyway) isn't uniformly spread across mail users.=A0 Some mail users =
don't participate in mailing lists and rarely send mail to more than one =
or two recipients.=A0 Chances are good that those users will never see a =
problem with Reply-To as it is currently implemented.=A0 Again, the =
mistake is in assuming that what's good for that set of users is good =
for everybody.=A0 They may even be the largest set of users, but they're =
not representative of the user population.</DIV><DIV><BR><BLOCKQUOTE =
type=3D"cite"><DIV>They do NOT want=A0to have to make different choices =
when posting on account of different=A0vagaries of different lists. They =
do NOT want to be faced with loads of=A0choices when replying. All they =
want (both of them) is to press one button=A0and have the "Right Thing" =
happen.</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV>It's certainly true that users =
don't want unnecessarily cumbersome user interfaces.=A0=A0It's also true =
that at least some users want their computers to read their minds. =A0And =
it's also true that users don't like having replies go to the wrong =
place.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>But it =
should not be assumed that giving people more choices about how to reply =
will make their user interfaces unnecessarily cumbersome.=A0 =A0It's not =
as if the only way to solve this problem is to put lots of different =
"reply" buttons on the reader window.=A0 Actually as far as I can tell =
you want this selection to be part of the window associated with =
composing the reply, because the reply author wants to be able to change =
his mind while composing the reply about where the message should go, =
and he should be able to do this without having to cut and paste the =
subject and text of the reply that he is drafting.=A0 So you might end =
up having only one "reply" button in the reader window, and a compose =
window that looks like:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">[ Replying to: &lt;x&gt; =
author=A0 &lt;x&gt; recipients <FONT class=3D"Apple-style-span" =
color=3D"#808080">&lt; &gt; reply-to &lt; &gt; list</FONT> &lt; &gt; =
reset ]</FONT></DIV><DIV><FONT class=3D"Apple-style-span" face=3D"Courier =
New"><BR class=3D"khtml-block-placeholder"></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">To: <A =
href=3D"mailto:[email-masked]">[email-masked]</A>, =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Cc: <A =
href=3D"mailto:[email-masked]">[email-masked]</A>, <A =
href=3D"mailto:[email-masked]">[email-masked]</A>, =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Subject: foo bar</FONT></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The reply author could =
click the boxes at the top of the window, and the addresses in the =
header of the message being composed would change to reflect the reply =
author's selections.=A0=A0This would make the selection easy and =
unobtrusive.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The selection box at the =
top of the reply compose window could also change color to subtly =
indicate changes in the default selection due to the presence of a =
Reply-To or similar field.=A0 Or the UA could alert the recipient to the =
presence of Reply-To fields by putting a message at the top of the =
compose window for the reply.=A0 e.g.:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" =
color=3D"#FF0000">+-------------------------------------------------------=
---------------------+</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" color=3D"#FF0000">| ! The message you are =
replying to contains a suggested Reply-To address.=A0=A0 =
|</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" face=3D"Courier=
 New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">| You may =
override this suggestion by using the buttons below.=A0 [options] =A0 =
=A0|</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New"><FONT class=3D"Apple-style-span" =
color=3D"#FF0000">+-------------------------------------------------------=
---------------------+</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">[ Replying to: &lt; &gt; =
author=A0 &lt; &gt; recipients &lt;x&gt; reply-to <FONT =
class=3D"Apple-style-span" color=3D"#808080">&lt; &gt; list</FONT> &lt; =
&gt; reset ]</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New"><BR =
class=3D"khtml-block-placeholder"></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">To: <A =
href=3D"mailto:[email-masked]">[email-masked]</A>, =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Cc: <FONT class=3D"Apple-style-span" =
color=3D"#818181"><A href=3D"mailto:[email-masked]">[email-masked]</A>, <A =
href=3D"mailto:[email-masked]">[email-masked]</A>,</FONT> =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Subject: foo bar</FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><BR =
class=3D"khtml-block-placeholder"></FONT></DIV><DIV>and the [options] =
button could expand the pane to allow the user to customize the alerts =
on a per-sender basis, so that the user wouldn't have to see the warning =
every time he received a mail from a particular person who had a =
reply-to field in his message.=A0 e.g.:</DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><BR =
class=3D"khtml-block-placeholder"></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" =
color=3D"#FF0000">+-------------------------------------------------------=
---------------------+</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" color=3D"#FF0000">| ! The message you are =
replying to contains a suggested Reply-To address.=A0=A0 =
|</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" face=3D"Courier=
 New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">| You may =
override this suggestion by using the buttons below.=A0 =A0 =A0 =A0 =A0 =
=A0 =A0=A0 |</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">|=A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 |</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">| =
&lt; &gt; always accept Reply-To from this author without warning me=A0 =
=A0 =A0 =A0 =A0 =A0=A0 |</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" color=3D"#FF0000">| &lt; &gt; always ignore =
Reply-To from this author=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 |</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span"=
 face=3D"Courier New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">|=
 &lt;x&gt; alert me when this author suggests Reply-To (default)=A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 |</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" color=3D"#FF0000">|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
|</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" face=3D"Courier=
 New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">| Regardless of =
which you select, you will always have the option of=A0 =A0 =A0 =A0=A0 =
|</FONT></FONT></DIV><DIV><FONT class=3D"Apple-style-span" face=3D"Courier=
 New"><FONT class=3D"Apple-style-span" color=3D"#FF0000">| overriding =
the suggestion of a Reply-To field.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0=A0 |</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New"><FONT =
class=3D"Apple-style-span" =
color=3D"#FF0000">+-------------------------------------------------------=
---------------------+</FONT></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">[ Replying to: &lt;x&gt; =
author=A0 &lt;x&gt; recipients &lt; &gt; reply-to &lt; &gt; list &lt; =
&gt; reset ]</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New"><BR =
class=3D"khtml-block-placeholder"></FONT></DIV><DIV><FONT =
class=3D"Apple-style-span" face=3D"Courier New">To: <A =
href=3D"mailto:[email-masked]">[email-masked]</A>, =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Cc: <FONT class=3D"Apple-style-span" =
color=3D"#808080"><A href=3D"mailto:[email-masked]">[email-masked]</A>, <A =
href=3D"mailto:[email-masked]">[email-masked]</A>,</FONT> =
_____________</FONT></DIV><DIV><FONT class=3D"Apple-style-span" =
face=3D"Courier New">Subject: foo bar</FONT></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>A similar mechanism could =
be used to handle a List-Reply-To or similar field.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>The point of this example =
is not to specify what the user interface should look like.=A0 The =
point=A0is to demonstrate that far better user interfaces than what =
we're currently seeing are possible.=A0 We need to design header fields =
that encourage and make it feasible for better user interfaces to exist =
and evolve, rather than designing fields that encourage dysfunctional =
user interfaces.</DIV><DIV><BR><BLOCKQUOTE type=3D"cite"><DIV>And the =
present situation is that there is NO WAY that those 95% of people=A0can =
do that.</DIV></BLOCKQUOTE><BR></DIV><DIV>I think it's incorrect to =
assume that anywhere near 95% of the people prefer a solution that =
sometimes does the wrong thing without telling them. =A0 A rule-based =
system might do the right thing for 95% of messages, but not for 95% of =
users.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Keith</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV></BODY></HTML>=

--Apple-Mail-2-279940661--

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Tue, 7 Jun 2005 14:41:01 -0400
Cc: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

On Tue June 7 2005 06:44, Charles Lindsey wrote:
> 
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> >And yet it does.  See
> >http://www.imc.org/ietf-smime/mail-archive/msg01961.html
> >for example.
> 
> There is no way of telling (because full headers are not available)
> whether that messange was sent with format=flowed, or not.

The full message archive is available in text form, and you
can (if you doubt my word) download it and verify that the
part is labeled:
  Content-Type: text/plain; charset=us-ascii; format=flowed

From: [email-masked]
Cc: [email-masked]
To: Charles Lindsey <[email-masked]>
Date: Tue, 07 Jun 2005 11:13:37 -0700 (PDT)
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> >On Mon May 30 2005 14:30, Charles Lindsey wrote:
> >> And if implemented correctly, it should not result
> >> in extremely long lines

> >And yet it does.  See
> >http://www.imc.org/ietf-smime/mail-archive/msg01961.html
> >for example.

> There is no way of telling (because full headers are not available)
> whether that messange was sent with format=flowed, or not.

Exactly. My own experience has been that I receive text messages with absurdly
long lines without fail every day. But if any of them have format=flowed set I
haven't noticed it (and a quick inspection of my mailbox didn't turn up any).

The long lines problem started long before format=flowed became available and
persists despite its availability. Our mistake wasn't in defining
format=flowed, but in not attempting to use it's definition as a means to try
and stop this particular form of bad behavior.

				Ned

From: [email-masked]
Cc: [email-masked]
To: Ian Bell <[email-masked]>
Date: Tue, 07 Jun 2005 11:12:16 -0700 (PDT)
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

> (that proposal was text/paragraph)

Sigh. Forgot about that one. Make that four failures, not three.

				Ned

From: [email-masked]
Cc: ietf-822 <[email-masked]>, Ned Freed <[email-masked]>
To: Bruce Lilly <[email-masked]>
Date: Tue, 07 Jun 2005 11:00:27 -0700 (PDT)
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

> On Mon June 6 2005 21:32, Ned Freed wrote:

> > You appear to have missed section 4.2, which says:
> [...]
> > Far from giving text generators carte blanche to generate long lines in hopes
> > they'll be wrapped by the receiver, RFC 3676 reiterates and even strengthens
> > the recommendation (it cannot be a requirement since there are cases where long
> > lines are unavoidable) that text/plain material use short lines.

> My complaints with 3676 and its predecessor are that it force-fits content
> markup (pages 6 through 11 of 3676) onto a format that explicitly is not
> allowed content markup ("plain"; RFC 2046 sect. 4.1.3 "no interpretation
> of embedded formatting commands, [...] or content markup should be
> necessary for proper display"),

Note the "should be necessary". I see no prohibition here.

> is based on silly assertions, e.g.
> sect. 3.3 "programs treat unknown subtypes of TEXT as an attachment" vs.
> RFC 2045 sect. 4.1.4 "Unrecognized subtypes of 'text' should be treated
> as subtype 'plain'" (modulo unrecognized charset issues),

Unfortunately this is far from silly. Quite a few programs suffer from this
defect. Attempts to get them to change have been made and AFAIK have been
totally unsuccessful.

> interoperability-busting rules, e.g. sect. 4 "any content-transfer-encoding
> used is irrelevant to the processing of flowed text"

This statement should be true of text/plain regardless of whether or not RFC
3676. Unfortunately there are known cases of programs conflating CTE usage with
formatting. This statement is an attempt to make it clear this is unacceptable.

> vs. RFC 2045 sect. 5
> "MIME implementations must ignore any parameters whose names they do not
> recognize" ("format" was not a parameter defined for text/plain when that
> media type was defined, so it is reasonable for implementations to not
> recognize it (i.e. ignore it) and treat transfer encoding as originally
> specified), etc.

There is no vs or conflict to be found here. If you believe otherwise it sure
sounds like you're misinterpreting what RFC 3676. The irrelevance of the CTE
does NOT mean the CTE hshould not be processed in the usual way. Rather, it 
means that the actual CTE used should not be used as a basis for how the text
gets displayed.

> > What RFC 3676 does is enhance the ability to display plain text on displays of
> > varying sizes. And none of these benefits would accrue if a different media
> > type had been used.

> Given the bogosity of the "treat [...] as an attachment" claim, and the
> reality that MIME conforming implementations treat unrecognized text
> subtypes as text/plain, precisely why couldn't this markup format have
> been handled as another subtype (e.g. text/flowed)?

Been there, tried that. Not once, not twice, but three times: text/richtext,
text/enriched, and text/simpletext. None of them were in any way succesful.
format=flowed, OTOH, has been somewhat succesful. Not as much as I'd like, and
I blame that mostly on format=flowed setting its sights a bit too low. There
should have been explicit text attempting to convert the horrible use of long
lines with the expectation that they will be wrapped for display by the
recipient.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Tue, 7 Jun 2005 12:18:13 -0400
Cc: Ian Bell <[email-masked]>
Sender: [email-masked]

On Tue June 7 2005 03:37, Ian Bell wrote:

> At the time that 2646 was written, Outlook and Outlook Express both
> treated "text/unknown" as attachments (they may or may not still do
> that).

Given the fact that such behavior is not MIME-conformant, there is
no reason to believe that introduction of a previously-unspecified
parameter with interoperability issues would be an overall improvement.
Or in more general terms, given some broken software, it is generally
more appropriate to urge the vendor to fix the problem than to cause
additional breakage, especially where that breakage impacts previously
conformant software. 

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Unhelpful behavior of many MUAs...
Date: Tue, 7 Jun 2005 12:05:56 -0400
Cc: Paul Jakma <[email-masked]>
Sender: [email-masked]

On Tue June 7 2005 10:27, Paul Jakma wrote:

> 1. Unhelpful behaviour of many MUAs in presence of Reply-To

> Would it be an idea to start by solving 1 first? Eg via a BCP or some 
> other document?

You could try.  I suspect an intended status of BCP would run into
difficulties, including:
o IETF usually doesn't attempt to regulate implementation issues
  which do not have serious interoperability issues.  It would be
  at best difficult to word things carefully to fit within what is
  usually considered suitable for BCP.
o good luck achieving consensus, particularly if you are right that
  *many* MUAs are currently doing something unsuitable

On the other hand, an Informational document describing the facts
and their consequences, but stopping short of recommending implementation
design changes should go through the process without more than the
usual trouble.

You're of course welcome to write an Internet-Draft that makes
implementation recommendations, but that's much more likely to get
caught on one or more ratholes.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 11:49:02 -0400
Sender: [email-masked]

On Tue June 7 2005 01:13, Hector Santos wrote:

> > 550 Return Path not verifiable. (in reply to RCPT TO command)
> >
> > Please fix your buggy server.
> 
> Oh boy!  There goes your modus operandi again!  Here we go again with the 2
> year old "Brucy" degrading every conversation ANYWAY or ANYWHERE when he
> don't get his way!  Brucy,  are you capable of having an form of
> non-confrontable conversion?  Nah, that is impossible!

You are overreacting.  There was a polite request to fix a problem at
your side.
 
> I did this the last time we had this Reply-To-List/Reply-To debate to prove
> the point that I don't what you to REPLY directly to me but to the LIST
> instead.

Then use the Reply-To field which is provided for that purpose.  It is
common courtesy to copy an author on a response unless that author has
clearly indicated otherwise.  The Reply-To field is defined precisely
to provide such an indication.

> Pretty much for the same reason you now finally saw the light and 
> are forcing a natural reply to the list by defining Reply-To: to the list
> instead of the AUTHOR - YOU!

I've been using Reply-To consistently for years.  It involves no
"forcing" of any kind.
 
> > 1. mailing lists have been around since well before RFC 724 (1977).
> 
> And what kind of environment did we have in 1997?
> 
> ONLINE systems?  Since when where you able to set a Reply-To in MUA in 1977?

Trivial to do at that time, since most UAs simply provided a template
and opened the user's preferred editor.

[much rambling and ad-hominem remarks elided]
> >   Note
> >    that RFC 724 also defines the semantics of the Reply-To field as an
> >    author-supplied suggestion for responses and specifically mentions
> >   "text-message teleconferencing", i.e. mailing lists.
> 
> Right, and to clearly point out what it says:
> 
> |           More interesting
> |           is a case such as text-message teleconferencing in which an
> |           automatic distribution facility  is  provided  and  a  user
> |           submitting  an  "entry" for distribution only needs to send
> |           their message to the mailbox(es) indicated in  the  "Reply-
> |           to:" field.
> 
> Which suggest that in a group environment, the natural reply is to go to the
> suggested reply-to field.

No, it says that the author can suggest that replies be directed to a
list mailbox, and/or to other mailboxes.  There is nothing anywhere
about a "natural reply".
 
[more rambling elided]
> Clearly, you have no credentials in mail software designs.  Absolutely no
> brain for the matter. You are a paper pusher, doc pusher, technie end-user.
> No more, no less and when you can't hack it, you resort to put downs and
> ad-nausem facts that are clearly not even in question.

Your remarks, in addition to being untrue, are inappropriate. Please
read RFC 3934, to which you have been previously referred.

Date: Tue, 7 Jun 2005 15:27:22 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: *Reply-to* considered harmful (was Re: Understanding response protocols)
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 6 Jun 2005, Keith Moore wrote:

> Rather, the whole assumption that the author of a message should be 
> able to change the behavior of a recipient's user agent is very 
> much in doubt.

Amen (I have come to realise).

> The only way to make Reply work better is to improve the user 
> interfaces of mail user agents so that recipients of messages are 
> more easily able to explicitly choose where their replies go.  To 
> the next new fields can help this process, they can only do so by 
> providing more information to a recipient to inform that choice.

How about looking at this as two seperate problems:

1. Unhelpful behaviour of many MUAs in presence of Reply-To

2. Desires by sending users for finer-grained means to specify
    preferences for replies

Would it be an idea to start by solving 1 first? Eg via a BCP or some 
other document?

That would help clear-up the scope of 2 also. (Eg, currently the 
desire for 2 is often because of 1 - that's why I initially 
approached this list).

> Keith

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A complex system that works is invariably found to have evolved from a
simple system that works.

To: [email-masked]
Xref: clerew local.mime:4767
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 10:41:45 GMT
Lines: 37
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>Author (or author's UA per author's configuration) sets Reply-To: good.
>List expander sets Reply-To: very bad.  RFC 2822 says "When the
>"Reply-To:" field is present, it indicates the mailbox(es) to which the
>author of the message suggests that replies be sent".  N.B. "author",
>not anybody or anything else.

Which is exactly why Reply-To is NOT the solution to this problem.

What is needed is some field that can be set by the Mailing-List expander
according to the default policy of the particular mailing list. Yes, there
need to be rules as to which takes priority when the poster and the
expander have different ideas as to what they want, and there need to be
rules as to how the ultimate recipient can override the lot of them if he
wants to. But those are just details.

The usual case (95% of the time) is that both posters and recipients will
be happy to accept what the standard list policy decides. They do NOT want
to have to make different choices when posting on account of different
vagaries of different lists. They do NOT want to be faced with loads of
choices when replying. All they want (both of them) is to press one button
and have the "Right Thing" happen.

And the present situation is that there is NO WAY that those 95% of people
can do that.

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

To: [email-masked]
Xref: clerew local.mime:4768
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Tue, 7 Jun 2005 10:44:54 GMT
Lines: 33
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

>On Mon May 30 2005 14:30, Charles Lindsey wrote:
>> And if implemented correctly, it should not result
>> in extremely long lines

>And yet it does.  See
>http://www.imc.org/ietf-smime/mail-archive/msg01961.html
>for example.

There is no way of telling (because full headers are not available)
whether that messange was sent with format=flowed, or not.

>The distinguishing characteristic of such messages (absent
>from Jacob's original in this thread) is that an entire
>paragraph of text is contained in a single message line as
>described in section 3.1 of RFC 3676.

But if it _was_ sent with format=flowed, then the agent which sent it has
breached a SHOULD in RFC 3676 by not splitting after 78 characters,
Breaching that SHOULD is not the end of the world, but it makes that agent
thoroughly broken IMO.

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

From: "Hector Santos" <[email-masked]>
To: "ietf-822" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 06:35:40 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Alan Barrett" <[email-masked]>
To: "ietf-822" <[email-masked]>
Sent: Tuesday, June 07, 2005 4:44 AM
Subject: Re: Understanding response protocols

> On Mon, 06 Jun 2005, Hector Santos wrote:
> > old :
> >
> > char *ReplyToSender()
> > {
> >   char *to_address = reply_to_address;
> >   if (to_address empty) to_address = from_address;
> >   return to_address;
> > }
>
> A function that does the above should be labeled "Reply" or "Reply to
> author's suggested reply address", or something similar.  A function
> labeled "Reply to sender" should reply to the "Sender:" address, or to
> the "From:" address if there is no "Sender:" address.
>

Ahh, I see the confusion.  In no way was I implying that it was a reply to
the "Sender:" address concept simply because it is not part of the MUA
methodology (MUAs do not reply to a Sender: address).  I was making the
relationship to the typical CUI, ergonomics options available, atleast as I
see it for my current MUA (OE), when I right click your message the popup
menu shows:

    Reply To Sender
    Reply To All

etc.

But I see your point. Technically, we have in our system called OOMS Object
Oriented Message System, a C/C++ virtual class object system. a virtual
method as follows:

// virtual
char *CMesageObject::GetDefaultReplyAddress()
{
    return NULL;
}

which is virtual abstract class for the many different mail formats and
networks we support.  So the virtual override for this abstract when using a
RFC 822/2822 would be something like so:

// virtual
char *CRFC2822MesageObject::GetDefaultReplyAddress()
{
   char *to_address = headers["Reply-To"];
   return to_address?to_address:headers["From"]
}

If there existed a new "List-Reply-To:" concept,  we would use (explore) a
simple update:

// virtual
char *CRFC2822MesageObject::GetDefaultReplyAddress()
{
   char *to_address = headers["List-Reply-To"];
   if (!to_address) to_address = headers["Reply-To"];
   return to_address?to_address:headers["From"]
}

But the odds are good we would use a Pull Down concept like we have in one
of our MUAs (Platinum Xpress - and online GUI Sysop Editor) where would show
all the potential reply addresses in a pull down list which the most
expected address for the action to be the default, in order words, the pull
down would appear in the following order, as made available:

    List-Reply-To:
    Reply-To:
    From:

This would be a for a normal "Reply" concept.

We currently do not do this in our web mail client for a reply. It picks the
default and allows the user to change it but that depends on the conference
type:

    Email          - open field
    Mailing List  - a fixed reply address is set by the sysop

And this is what I wanted to illustrate.  When using an Offline concept, the
backend system can not control the fields, and I am not suggested that it
does. Yet, it maybe the future for the more advanced MUA more aware or 1 to
1 EMAIL vs. 1 to MANY (List, News) concepts. That all depends on the desires
of the MUA author.  There is certainly no reason why the MUA can't enforce
it, but the offline nature also means it needs to be flexible and provide
all the possible options.

If I replied to your message via web mail,  it will go to the defined list
address simply because the conference is setup that way.  I have no control
as a user in this case via web mail.

With my offline RFC, well,  I want to reply back to the list.  Not to you.
The problem?  It all depends on who's message I am reading on the list.  For
your message, I have to click Reply to All to get the list address and
manually delete your address from the multiple addresses it grabbed.   For
Bruce's message, a simply reply will do it.  If I wasn't paying attention,
duplicate mail goes out.   Most people will prefer a consistent behavior
regarding of which list they are using.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 7 Jun 2005 10:55:12 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Keith Moore <[email-masked]>
cc: ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Confusing UAs considered harmful (was *Reply-to* considered harmful)
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 6 Jun 2005, Keith Moore wrote:

> However, most MUA implementations still treat Reply-to more as an 
> "indication" of where responses are to be sent than as a 
> "suggestion"

Aye. Quite annoying.

> Entirely agree.  And if we're going to have a new field for 
> suggesting where replies go, it needs to be designed in such a way 
> that it makes a useful suggestion for the recipient, rather than in 
> such a way that recipient UAs are expected to process it 
> automatically without human input.

I think the correct thing is for the header to contain information 
specific and pertinent to the person who inserted or added to it. 
Something about /their/ preference, and avoid assuming things about 
respondents by trying to suggest things to them.

> Keith

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You know it's Monday when you wake up and it's Tuesday.
 		-- Garfield

Date: Tue, 7 Jun 2005 10:52:11 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
cc: Charles Lindsey <[email-masked]>
Subject: Re: Understanding response protocols
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 6 Jun 2005, Bruce Lilly wrote:

> Several UAs implement a "Reply to List" function without such a 
> header field; evidently there is no such "need".

And more than of them will consider the MFT when forming such a 
reply-to-list response.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who fights and runs away lives to fight another day.

Date: Tue, 7 Jun 2005 10:44:47 +0200
From: Alan Barrett <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Sender: [email-masked]

On Mon, 06 Jun 2005, Hector Santos wrote:
> old :
> 
> char *ReplyToSender()
> {
>   char *to_address = reply_to_address;
>   if (to_address empty) to_address = from_address;
>   return to_address;
> }

A function that does the above should be labeled "Reply" or "Reply to
author's suggested reply address", or something similar.  A function
labeled "Reply to sender" should reply to the "Sender:" address, or to
the "From:" address if there is no "Sender:" address.

--apb (Alan Barrett)

Date: Tue, 7 Jun 2005 08:37:58 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

In message <[email-masked]>, Bruce Lilly 
<[email-masked]> writes

>My complaints with 3676 and its predecessor are that it
[]
>is based on silly assertions, e.g.
>sect. 3.3 "programs treat unknown subtypes of TEXT as an attachment" vs.

Full quote

    A proposal to define a new media type to explicitly represent the
    paragraph form

(that proposal was text/paragraph)

    suffered from a lack of interoperability with currently deployed
    software. Some programs treat unknown subtypes of TEXT as an
    attachment.

At the time that 2646 was written, Outlook and Outlook Express both 
treated "text/unknown" as attachments (they may or may not still do 
that).

>Given the bogosity of the "treat [...] as an attachment" claim,

I see no "bogosity". text/paragraph foundered on the (broken) treatment 
of text/unknown by some very common clients.

(Perhaps "Some programs treated unknown..." would have been slightly 
better though.)

> precisely why couldn't this markup format have been handled as another 
>subtype (e.g. text/flowed)?

see above

- -- 
Ian Bell                                                 T U R N P I K E

From: "Hector Santos" <[email-masked]>
To: "ietf-822" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Tue, 7 Jun 2005 01:13:50 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: "ietf-822" <[email-masked]>
Sent: Monday, June 06, 2005 11:26 PM
Subject: Re: Understanding response protocols

> 550 Return Path not verifiable. (in reply to RCPT TO command)
>
> Please fix your buggy server.

Oh boy!  There goes your modus operandi again!  Here we go again with the 2
year old "Brucy" degrading every conversation ANYWAY or ANYWHERE when he
don't get his way!  Brucy,  are you capable of having an form of
non-confrontable conversion?  Nah, that is impossible!

Bruce, for the 3rd time,  you were twitted on our system.  You can't send to
our system using EOLS.COM domain. The same with your side-kick.  We use a
delay verification system hence why it checking is done at RCPT TO until it
is known you are sending to a local destination address.   Elusive or not.
Everyone gets the same response depending on the TMS  <tm> (Transaction
Management and Security) plug-in.   The local server side logs provides the
reason for the rejected transaction.

I did this the last time we had this Reply-To-List/Reply-To debate to prove
the point that I don't what you to REPLY directly to me but to the LIST
instead.   Pretty much for the same reason you now finally saw the light and
are forcing a natural reply to the list by defining Reply-To: to the list
instead of the AUTHOR - YOU!

> 1. mailing lists have been around since well before RFC 724 (1977).

And what kind of environment did we have in 1997?

ONLINE systems?  Since when where you able to set a Reply-To in MUA in 1977?
Did you have an MUA on your VT100? Your WISE terminal,  your Tekronik Raster
graphics terminal?

And if you were able to do it with your Pet PC computer,  using a tape based
offline MUA written in ADA, FORTRAN or god-forbid APL,   the server-side
list mail/server still has control over how the make the more common system
can easily respond using the standard BACK to the list REPLY BUTTON address.

Look, no system or network had a concept that converged or merged ONLINE and
OFFLINE considerations as a single concept where you have:

    FROM:
    DATE:
    TO:
    SUBJECT:
    REPLY-TO:
    CC:

Nearly all systems had only 3 options:

    REPLY TO SENDER  - REPLY-TO: | FROM:
    REPLY TO ALL :  REPLY-TO |  TO | CC
    FORWARD:  blank

and this was either for online or offline systems. Only more advance systems
had concepts where they might augment with

    REPLY TO ORIGINAL AUTHOR
    REPLY TO ORIGINAL RECEIPT

and MORE important as part of the security for a online system, the USER had
absolutely NO control over it would reply to in the conference system.  The
system handle it.

This began to change with OFFLINE, store and forward systems.  However, the
better mail server still did security integrity checks with uploaded offline
mail to make sure the offline behavior was consistent with the online
behavior.  If the mail server did not check the integrity of the uploaded
message, than it was a POOR server and had a hole into the mail system.
Never mind the fact that mail delivery and reliability was at stake.

Bruce, you are out of your league here. I can spin you a thousand times with
the design issues that are involved here.

>   Note
>    that RFC 724 also defines the semantics of the Reply-To field as an
>    author-supplied suggestion for responses and specifically mentions
>   "text-message teleconferencing", i.e. mailing lists.

Right, and to clearly point out what it says:

|           More interesting
|           is a case such as text-message teleconferencing in which an
|           automatic distribution facility  is  provided  and  a  user
|           submitting  an  "entry" for distribution only needs to send
|           their message to the mailbox(es) indicated in  the  "Reply-
|           to:" field.

Which suggest that in a group environment, the natural reply is to go to the
suggested reply-to field.

However, once again, it was designed around online systems and it is the
online system that ulitimates defines the distribution.   The END USER has
ABSOLUTELY
no control over online system mail policies.

What you are suggesting, as I said in another forum, that a OFFLINE MUA has
more control over how mail is transported over a system.  Sorry, it doesn't
buddy.   An offline system will not define how a mail server policy will
behave.

What you suggesting that a USER has control over his FROM field in a online
system. He typically doesn't.

And again, we are taking about the ergonomics of the natural reply process
which I am getting sick and tired of explaining to you over and over again.

Ironically,  you just did it yourself. You purposely set the reply-to:
address to the IETF-2822 mailing list address because you know it for
yourself that is how the natural behavior for ALL MUAs to behind.  It was
your way to make sure the maximum set of users will reply to the right
address when responding to your mail without extra confusing field editing
or using a "Reply to All" concept to get the list address.

If you did not do this, then a NATURAL REPLY will go back the to FROM:
address which is NOT what the user wanted in 99.99% of the cases.  His
intentions is to reply to the list, not to you.  That is why you set up your
MUA folder to force the Reply-TO: to the list address.

>  2. "alias" and "mailing list" are different. See RFC 2821 section 3.5.1.

> > char *ReplyToSender()
> >{
> >   char *to_address = reply_to_address;
> >   if (to_address empty) to_address = from_address;

> No and no.  Reply-To != Sender.  From != Sender.

Clearly, you have no credentials in mail software designs.  Absolutely no
brain for the matter. You are a paper pusher, doc pusher, technie end-user.
No more, no less and when you can't hack it, you resort to put downs and
ad-nausem facts that are clearly not even in question.  Hey, don't get me
wrong. We typically people like you to dot all the i's and cross the t's.

But you really don't have no right to be involve in this design discussion.
It is beyond you at this point.  When a draft is written, that you can join
the conversation again.

How about those adam apples?

People,  write your proposal to identify a LIST ADDRESS and present it to
all the MUA, LIST SERVER authors.  We know better than Bruce whether its
needed or not.

Rest assured it will be considered very strongely if only for the key reason
that we do want to make sure we retain the Reply-To: address in a LIST
expanded system.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 23:26:38 -0400
Sender: [email-masked]

On Mon June 6 2005 21:52, Hector Santos wrote:
> Cc: "Hector Santos" <[email-masked]>

<[email-masked]>: host mail.winserver.com[208.247.131.9] said:
    550 Return Path not verifiable. (in reply to RCPT TO command)

Please fix your buggy server.

> > Author (or author's UA per author's configuration) sets Reply-To: good.
> > List expander sets Reply-To: very bad.  RFC 2822 says "When the
> > "Reply-To:" field is present, it indicates the mailbox(es) to which the
> > author of the message suggests that replies be sent".  N.B. "author",
> > not anybody or anything else.
> 
> Well, life is about flux and change.
[...]
> I'm not telling you nothing. but with a list system, this isn't a 1 to 1
> communications anymore.   The "list" concept works on the basis the list
> address is an "alias user" mailbox which has reached it's final destination.
[...]

1. mailing lists have been around since well before RFC 724 (1977).  Note
   that RFC 724 also defines the semantics of the Reply-To field as an
   author-supplied suggestion for responses and specifically mentions
   "text-message teleconferencing", i.e. mailing lists.
2. "alias" and "mailing list" are different. See RFC 2821 section 3.5.1.

> char *ReplyToSender()
> {
>   char *to_address = reply_to_address;
>   if (to_address empty) to_address = from_address;

No and no.  Reply-To != Sender.  From != Sender.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Mon, 6 Jun 2005 23:06:58 -0400
Cc: Ned Freed <[email-masked]>
Sender: [email-masked]

On Mon June 6 2005 21:32, Ned Freed wrote:

> You appear to have missed section 4.2, which says:
[...]
> Far from giving text generators carte blanche to generate long lines in hopes
> they'll be wrapped by the receiver, RFC 3676 reiterates and even strengthens
> the recommendation (it cannot be a requirement since there are cases where long
> lines are unavoidable) that text/plain material use short lines.

My complaints with 3676 and its predecessor are that it force-fits content
markup (pages 6 through 11 of 3676) onto a format that explicitly is not
allowed content markup ("plain"; RFC 2046 sect. 4.1.3 "no interpretation
of embedded formatting commands, [...] or content markup should be
necessary for proper display"), is based on silly assertions, e.g.
sect. 3.3 "programs treat unknown subtypes of TEXT as an attachment" vs.
RFC 2045 sect. 4.1.4 "Unrecognized subtypes of 'text' should be treated
as subtype 'plain'" (modulo unrecognized charset issues),
interoperability-busting rules, e.g. sect. 4 "any content-transfer-encoding
used is irrelevant to the processing of flowed text" vs. RFC 2045 sect. 5
"MIME implementations must ignore any parameters whose names they do not
recognize" ("format" was not a parameter defined for text/plain when that
media type was defined, so it is reasonable for implementations to not
recognize it (i.e. ignore it) and treat transfer encoding as originally
specified), etc.

> What RFC 3676 does is enhance the ability to display plain text on displays of
> varying sizes. And none of these benefits would accrue if a different media
> type had been used.

Given the bogosity of the "treat [...] as an attachment" claim, and the
reality that MIME conforming implementations treat unrecognized text
subtypes as text/plain, precisely why couldn't this markup format have
been handled as another subtype (e.g. text/flowed)?

From: "Hector Santos" <[email-masked]>
To: "ietf-822" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 21:52:40 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: "ietf-822" <[email-masked]>
Cc: "Hector Santos" <[email-masked]>
Sent: Monday, June 06, 2005 8:42 PM
Subject: Re: Understanding response protocols

> Kmail, Evolution, Pine.

Ok, I would have to note these down for exploration .

> ... Usually specific folder settings.

Ok, thats the only way I can see it work reliablity - using an offline
configuration concept because it certainly isn't an automated integrated
mail concept.

> > That has not been the case of recent messages with yours.   A Reply to
> > Sender does how  I shown above because of your own Reply-To: address
going
> > to the list address.

> Author (or author's UA per author's configuration) sets Reply-To: good.
> List expander sets Reply-To: very bad.  RFC 2822 says "When the
> "Reply-To:" field is present, it indicates the mailbox(es) to which the
> author of the message suggests that replies be sent".  N.B. "author",
> not anybody or anything else.

Well, life is about flux and change.

I can see and agree with your input. Always have.  But there is a small
difference here that I believe "maybe" you don't to consider or want to turn
a blind side to.  Maybe you do.

I'm not telling you nothing. but with a list system, this isn't a 1 to 1
communications anymore.   The "list" concept works on the basis the list
address is an "alias user" mailbox which has reached it's final destination.
At which point where the list server needs to expand, the concept of "Mail
Integrity" isn't as "strong" as it was a 1 to 1 concept.  I am not saying
there is no guidelines any more here, but from a "mail movement" standpoint,
there is precedence from defined the Reply-To field at the list server.

That is the part of the realistic, practical, decades old "equation" that is
missing from the RFC 2822 definition you continue to cite.

I understand your standpoint - the MUA should define all this.  But that
isn't realistic for a Conference Mail/Groupware concept like a mailing list
and far more often than not, it creates more issues compared to forcing the
Reply-To: to the list address REGARDLESS of whole set it.   You set it for a
reason.  You are able to do so with your MUA. I am guessing it is your MUA
folder settings.  But it could of been the list-server and done for the same
reasons you are trying to achieve offline.

What is missing from all this are new integrated mail design standard where
"Conference-Based" considerations are taken into account in a 1 to 1 email
transport structure.

In any case, I would interested in seeing a proposal for a new list address
field that MUAs can begin to use specifically for a "Reply-To-List" concept
which is nothing more than:

old :

char *ReplyToSender()
{
  char *to_address = reply_to_address;
  if (to_address empty) to_address = from_address;
  return to_address;
}

new addition:

char *ReplyToList()
{
  char *to_address = list_to_address;
  if (to_address empty) to_address = ReplyToSender();
  return to_address;
}

We have 7 MUA device systems to support.

Console Text (Online)
Silver Xpress (offline)
Platinum Xpress (online)
Wildcat Navigator (online)
Web Mail (online)
Offline Mail Doors (offline)
RFC based Mail Reader (offline)

I would most definitely consider a proposal that helps the "user
expectations" of replying back to the list.

The difference in your thinking process is more within the MUA.  I need to
take everything into account, including those more current and legacy MUAs
as well that doesn't have a Conference Mail concept for the EMAIL side of
the MUA.

Finally, I have to listen to customers who say forcing a Reply-To: is far
more better than dealing with the redundant mail being sent all parties
unbeknownst to the casual user when it sees a "reply" button and only has
one kind of thinking - "that must be how I reply."

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: [email-masked]
Cc: ietf-822 <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
To: Bruce Lilly <[email-masked]>
Date: Mon, 06 Jun 2005 18:32:19 -0700 (PDT)
Subject: Re: Folding of long lines in message bodies
Sender: [email-masked]

> On Mon June 6 2005 16:53, Arnt Gulbrandsen wrote:
> > Bruce Lilly writes:
> > > The distinguishing characteristic of such messages (absent from
> > > Jacob's original in this thread) is that an entire paragraph of text
> > > is contained in a single message line as described in section 3.1 of
> > > RFC 3676.
> >
> > Agreed. So in other words, nothing about this problem is related to
> > RFC3676. ISTR that Netscape Navigator 2.0 did the same thing with
> > text/plain.

> "this problem" == extremely long lines == RFC 3676 section 3.1 "use
> CRLF to represent paragraph breaks [...] Text which meets this
> description is defined by this memo as "flowed" [...] software products
> erroneously label this format as Text/Plain, resulting in much user
> discomfort"

> Unfortunately, 3676 and its predecessor label the format as text/plain.

You appear to have missed section 4.2, which says:

  When generating Format=Flowed text, lines SHOULD be 78 characters or shorter,
  including any trailing white space and also including any space added as part
  of stuffing (see Section 4.4). As suggested values, any paragraph longer than
  78 characters in total length could be wrapped using lines of 72 or fewer
  characters. While the specific line length used is a matter of aesthetics and
  preference, longer lines are more likely to require rewrapping and to encounter
  difficulties with older mailers. (It has been suggested that 66 character lines
  are the most readable.)

Far from giving text generators carte blanche to generate long lines in hopes
they'll be wrapped by the receiver, RFC 3676 reiterates and even strengthens
the recommendation (it cannot be a requirement since there are cases where long
lines are unavoidable) that text/plain material use short lines.

What RFC 3676 does is enhance the ability to display plain text on displays of
varying sizes. And none of these benefits would accrue if a different media
type had been used.

I have not observed obuse of RFC 3676 formats in practice - almost all material
I received with format=flowed displays fine in an 80 column display. But sadly,
there are still plenty of botched clients (including some new ones) that
generate long lines in classic text/plain. RFC 3676 really wasn't aimed at
solving this problem, but in retrospect I wish it had tried...

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Mon, 6 Jun 2005 20:48:23 -0400
Cc: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On Mon June 6 2005 16:53, Arnt Gulbrandsen wrote:
> Bruce Lilly writes:
> > The distinguishing characteristic of such messages (absent from 
> > Jacob's original in this thread) is that an entire paragraph of text 
> > is contained in a single message line as described in section 3.1 of 
> > RFC 3676.
> 
> Agreed. So in other words, nothing about this problem is related to 
> RFC3676. ISTR that Netscape Navigator 2.0 did the same thing with 
> text/plain.

"this problem" == extremely long lines == RFC 3676 section 3.1 "use
CRLF to represent paragraph breaks [...] Text which meets this
description is defined by this memo as "flowed" [...] software products
erroneously label this format as Text/Plain, resulting in much user
discomfort"

Unfortunately, 3676 and its predecessor label the format as text/plain.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 20:42:51 -0400
Cc: "Hector Santos" <[email-masked]>
Sender: [email-masked]

On Mon June 6 2005 19:04, Hector Santos wrote:

> Do you know of specific UA that do specifically support "Reply To List"
> Common User Interface option?  If so what do they tag on?

Kmail, Evolution, Pine.  Usually specific folder settings.

> I know OE is not using the List-ID for a "Reply To Sender" or a "Reply to
> All"   It would be nice to have a third "Reply To List" option where it
> might use the "List-ID" if available.

List-ID does not contain a mailbox; it cannot be used to send to a
mailing list. 

> But as you say, you don't need it if the List Server or middle-ware or
> special UA has a special way of setting the "Reply-to:" field.

I didn't say that.
 
> Now, this is the $6 million question.   Not to long ago, you were clearly
> dead set against a system using the Reply-To:  as a way to force the List
> Address within a normal MUA expected "Reply to Sender" concept.
> 
> That has not been the case of recent messages with yours.   A Reply to
> Sender does how  I shown above because of your own Reply-To: address going
> to the list address.

Author (or author's UA per author's configuration) sets Reply-To: good.
List expander sets Reply-To: very bad.  RFC 2822 says "When the
"Reply-To:" field is present, it indicates the mailbox(es) to which the
author of the message suggests that replies be sent".  N.B. "author",
not anybody or anything else.

From: "Hector Santos" <[email-masked]>
To: "ietf-822" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 19:04:41 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: "ietf-822" <[email-masked]>
Cc: "Charles Lindsey" <[email-masked]>
Sent: Monday, June 06, 2005 2:40 PM
Subject: Re: Understanding response protocols

> > Therefore, it is evident that some further Reply-to-like header (MFT,
MCT
> > or something new) is needed for use with the "Reply-to-List" command
>
> Several UAs implement a "Reply to List" function without such a header
> field; evidently there is no such "need".

Do you know of specific UA that do specifically support "Reply To List"
Common User Interface option?  If so what do they tag on?

Using Outlook Express, it has two reply options:  Replying to your message,
the destination addresses are set as follows:

Action:  Reply to Sender
            To:  [email-masked]

Action:  Reply to Sender
            To:  [email-masked];  [email-masked]
            cc: "Charles Lindsey" [email-masked]

The pertinent headers on your original message are:

    From: Bruce Lilly <[email-masked]>
    Reply-To: ietf-822 <[email-masked]>
    To: ietf-822 <[email-masked]>
    Cc: "Charles Lindsey" <[email-masked]>
    Sender: [email-masked]
    Precedence: bulk
    List-ID: <ietf-822.imc.org>

I know OE is not using the List-ID for a "Reply To Sender" or a "Reply to
All"   It would be nice to have a third "Reply To List" option where it
might use the "List-ID" if available.

But as you say, you don't need it if the List Server or middle-ware or
special UA has a special way of setting the "Reply-to:" field.

Absense of the Reply-To: field, the OE behavior is:

Action:  Reply to Sender
            To:  [email-masked]

Action:  Reply to Sender
            To:  [email-masked];  [email-masked]
            cc: "Charles Lindsey" [email-masked]

OE is following standard behavior and also expectations of the mail servers
as well..

Now, this is the $6 million question.   Not to long ago, you were clearly
dead set against a system using the Reply-To:  as a way to force the List
Address within a normal MUA expected "Reply to Sender" concept.

That has not been the case of recent messages with yours.   A Reply to
Sender does how  I shown above because of your own Reply-To: address going
to the list address.

This is clearly the best ergonomic behavior for 99.9% of user expectations
who have no clear view of a "EMAIL" system being used for a
Conference-Messaging Based groupware concept.

Until you have a specific "Reply-To-List" concept,  doing what you have in
your messages today, is in my opinion, the best behavior.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 6 Jun 2005 22:53:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Folding of long lines in message bodies
Cc: Bruce Lilly <[email-masked]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Bruce Lilly writes:
> The distinguishing characteristic of such messages (absent from 
> Jacob's original in this thread) is that an entire paragraph of text 
> is contained in a single message line as described in section 3.1 of 
> RFC 3676.

Agreed. So in other words, nothing about this problem is related to 
RFC3676. ISTR that Netscape Navigator 2.0 did the same thing with 
text/plain.

Arnt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: *Reply-to* considered harmful
Date:  Mon, 06 Jun 2005 22:35:43 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

Keith Moore wrote:

> The only way to make Reply work better is to improve the user
> interfaces of mail user agents so that recipients of messages
> are more easily able to explicitly choose where their replies
> go.

I'm quite happy with my UA:  Re:News goes to the list - I read
all serious lists behind a mail2news gateway (GMaNe) - Re:Mail
goes to the Reply-To (or to the From without a Reply-To), and
for exactly one person in the world preferring another mode of
netiquette (in other words you) I use Re:Both.

Works like a charm, unless I screw up and hit the wrong button.
Mailing lists trying to be "smart" about Reply-To are a pain,
it's user territory.
                     Bye, Frank

Date: Mon, 6 Jun 2005 16:05:59 -0400
From: Keith Moore <[email-masked]>
To: ietf-822 <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Confusing UAs considered harmful (was *Reply-to* considered harmful)
Sender: [email-masked]

> On Mon June 6 2005 14:58, Keith Moore wrote:
> 
> > Rather, the whole assumption that the author of a message should be able to
> > change the behavior of a recipient's user agent is very much in doubt.
> 
> That's emphatically NOT the assumption behind the Reply-To field semantics.
> "suggestion" != "change the behavior"

It was the assumption in RFC 822, according to both my reading of that
document and my understanding of statements made by the editor of that
document. 2822 (correctly IMHO) changes the semantics to "suggestion".  

However, most MUA implementations still treat Reply-to more as an
"indication" of where responses are to be sent than as a "suggestion" -
in the sense that they use Reply-To to change the default behavior of a
Reply command, they don't make it clear to the recipient that the
default behavior is being changed, and they don't allow recipients to
easily choose other behaviors.

> > The only way to make Reply work better is to improve the user interfaces
> > of mail user agents so that recipients of messages are more easily able to 
> > explicitly choose where their replies go.
> 
> Agreed.  Maybe UAs, when instructed to respond, should start with "Where
> do you want your message to go today?" :-)
> 
> > To the [extent?] new fields can help 
> > this process, they can only do so by providing more information to a recipient
> > to inform that choice.
> 
> Maybe.  Sometimes too much information can make matters worse.  Ultimately
> a respondent needs to give some thought to the matter, and neither a UA
> nor a new header field is a substitute for thought.

Entirely agree.   And if we're going to have a new field for suggesting where
replies go, it needs to be designed in such a way that it makes a useful
suggestion for the recipient, rather than in such a way that recipient UAs 
are expected to process it automatically without human input.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Confusing UAs considered harmful (was *Reply-to* considered harmful)
Date: Mon, 6 Jun 2005 15:48:44 -0400
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

On Mon June 6 2005 14:58, Keith Moore wrote:

> Rather, the whole assumption that the author of a message should be able to
> change the behavior of a recipient's user agent is very much in doubt.

That's emphatically NOT the assumption behind the Reply-To field semantics.
"suggestion" != "change the behavior"

It appears to be the assumption behind "Mail-Followup-To", but then that's
not an official message header field and is implemented differently by
the few UAs that pay any attention to it.

Some UAs may in fact change behavior; blame the UAs and/or their authors
if you wish, don't blame the field.  Maybe blame RFC 724/822 authors for
the "If there is" sentences (absent from RFCs 733/2822).

[more complaints about particular types of UAs elided]

> The only way to make Reply work better is to improve the user interfaces
> of mail user agents so that recipients of messages are more easily able to 
> explicitly choose where their replies go.

Agreed.  Maybe UAs, when instructed to respond, should start with "Where
do you want your message to go today?" :-)

> To the [extent?] new fields can help 
> this process, they can only do so by providing more information to a recipient
> to inform that choice.

Maybe.  Sometimes too much information can make matters worse.  Ultimately
a respondent needs to give some thought to the matter, and neither a UA
nor a new header field is a substitute for thought.

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Folding of long lines in message bodies
Date: Mon, 6 Jun 2005 15:21:04 -0400
Cc: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

On Mon May 30 2005 14:30, Charles Lindsey wrote:
> And if implemented correctly, it should not result
> in extremely long lines

And yet it does.  See
http://www.imc.org/ietf-smime/mail-archive/msg01961.html
for example.

The distinguishing characteristic of such messages (absent
from Jacob's original in this thread) is that an entire
paragraph of text is contained in a single message line as
described in section 3.1 of RFC 3676.

Date: Mon, 6 Jun 2005 14:58:37 -0400
From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: *Reply-to* considered harmful (was Re: Understanding response protocols)
Sender: [email-masked]

> No! Reply-To is what you should use if you want to send a personal reply
> to the author of, the original message (which indeed you sometimes need to
> do if, for example, your reply is too complex/personal/whatever for
> sending to thje complete list).

That is completely incorrect.

"From" contains the author (or authors) of the original message.  If you 
want your reply to go to the author(s) of the original message, you need 
to send your message to the addresses in the From field.  As at least
one example in RFC 822 makes clear, it is not reasonable to assume that
sending to addresses in the Reply-To field will reach the author(s) of 
the original message.

> Therefore, it is evident that some further Reply-to-like header (MFT, MCT
> or something new) is needed for use with the "Reply-to-List" command (or
> Reply-to-All if Reply-to-list is not provided).

No, it doesn't follow - both because your premise is incorrect, and because
the absence of a field specifically intended for group replies is not an indicator
that some additional field is needed.  

Rather, the whole assumption that the author of a message should be able to
change the behavior of a recipient's user agent is very much in doubt.  Even
in the case of a single recipient message the behavior of Reply in the presence
of a Reply-To field is too often surprising for the responder.   It only becomes 
more surprising in the presence of additional recipients, reply to author /
reply to all choices, mailing lists, and/or multiple fields indicating how to reply -
_no matter how those new fields are defined_.

The only way to make Reply work better is to improve the user interfaces
of mail user agents so that recipients of messages are more easily able to 
explicitly choose where their replies go.   To the next new fields can help
this process, they can only do so by providing more information to a recipient
to inform that choice.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 14:40:24 -0400
Cc: "Charles Lindsey" <[email-masked]>
Sender: [email-masked]

On Mon June 6 2005 09:43, Charles Lindsey wrote:
> 
> In <[email-masked]> Paul Jakma <[email-masked]> writes:

> >To be honest, I'd rather see some kind of 'best-practice for 
> >Reply-To' document than MFT. Reply-To, in an ideal world, should work 
> >just as well. The only reason for MFT, it seems, is just to avoid 
> >bogus behaviour in MTAs wrt Reply-To.
> 
> No! Reply-To is what you should use if you want to send a personal reply
> to the author of, the original message (which indeed you sometimes need to
> do if, for example, your reply is too complex/personal/whatever for
> sending to thje complete list).

No, the semantics of the Reply-To field is NOT "personal reply", it is
"where the author(s) suggested".  Nor is the semantics "the author"; that
would be the From field.  A response to the author(s) intentionally
disregarding the authors' suggestion would go to the mailboxes in the
original message From field, and that is precisely what several UAs
which provide separate "Reply to Author" functions do. 

> Therefore, it is evident that some further Reply-to-like header (MFT, MCT
> or something new) is needed for use with the "Reply-to-List" command

Several UAs implement a "Reply to List" function without such a header
field; evidently there is no such "need".

To: [email-masked]
Xref: clerew local.mime:4754
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Mon, 6 Jun 2005 13:43:19 GMT
Lines: 70
Sender: [email-masked]

In <[email-masked]> Paul Jakma <[email-masked]> writes:

>On Thu, 2 Jun 2005, Charles Lindsey wrote:

>> It would be better if there were a couple of keywords so you could say
>>
>>    Mail-Followup-To: poster,list
>>
>> and configure that for all lists you subscribe to.

>To be honest, I'd rather see some kind of 'best-practice for 
>Reply-To' document than MFT. Reply-To, in an ideal world, should work 
>just as well. The only reason for MFT, it seems, is just to avoid 
>bogus behaviour in MTAs wrt Reply-To.

No! Reply-To is what you should use if you want to send a personal reply
to the author of, the original message (which indeed you sometimes need to
do if, for example, your reply is too complex/personal/whatever for
sending to thje complete list).

Therefore, it is evident that some further Reply-to-like header (MFT, MCT
or something new) is needed for use with the "Reply-to-List" command (or
Reply-to-All if Reply-to-list is not provided).

Such a header should be flexible enough to include/not-include the
original poster (or his nominee) in the reply, and to include/not-include
various sub-lists/super-lists/parallel-lists/no-list-at-all in the reply.

>> Actually, that is all beginning to look quite like the 
>> Mail-Copies-To header sometimes used in News.

>Right.

>But it doesn't offer much extra though. (except that it avoids 
>current bad Reply-To behaviour in some MUAs). If we were to have a 
>new header like that i'd want it:

>1. transitive (must be kept in replies)

>2. additive (so people could add their own/further mailboxes to it,
>    if they wanted)

>3. Get rid of that ambigious 'never' thing it allows

The main problem is that it currently allows only one option to be
specified:  poster, nobody (aka never) and some mailbox-list.

"poster" means poster+list/newsgroup.
"nobody" means list/newsgroup only.
mailbox-list means addresses-listed+list/newsgroup.

If you want reply not to go to the list/newsgroup at all, then you have to
use Followup-to: poster (which then uses the Reply-To address).

So that isn't quite what we want.

So the question is whether it is easier to add the functionality we want
to MFT or to MCT, or whether to start over.

-- 
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, 3 Jun 2005 14:36:07 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, 2 Jun 2005, Charles Lindsey wrote:

> Well, as MFT is currently implemented, either it gets filled in by 
> the mailing list administrator (according to whatever the "list 
> policy" is), or by the original poster - something like
>
>    Mail-Followup-To: [email-masked],[email-masked]
>
> For a man who wants personal as well as list replies. But to 
> provide that funtionality conveniently requires the poster's MUA to 
> be configured with a list of known mailing lists, and how the MFT 
> is to be formed for each.
>
> It would be better if there were a couple of keywords so you could say
>
>    Mail-Followup-To: poster,list
>
> and configure that for all lists you subscribe to.

To be honest, I'd rather see some kind of 'best-practice for 
Reply-To' document than MFT. Reply-To, in an ideal world, should work 
just as well. The only reason for MFT, it seems, is just to avoid 
bogus behaviour in MTAs wrt Reply-To.

I dont seem to having much success in my last mail asking whether 
it'd be an idea to draft such a BCP document though. :(

Which is a shame, cause until that is done we'll either continue 
having this discussion every now and then, or we'll see more and more 
MUAs implementing ad-hoc solutions (odd 'list reply' buttons and MFT 
headers). Anyway. :(

> That presumes the MUA generating replies can figure out what 
> 'poster' means (easy - use the Reply-To/From address) and what 
> 'list' means (not so easy if there is no List-Post field).

Indeed.

That's probably not a good idea. Again more scope for confusion.

> Actually, that is all beginning to look quite like the 
> Mail-Copies-To header sometimes used in News.

Right.

But it doesn't offer much extra though. (except that it avoids 
current bad Reply-To behaviour in some MUAs). If we were to have a 
new header like that i'd want it:

1. transitive (must be kept in replies)

2. additive (so people could add their own/further mailboxes to it,
    if they wanted)

3. Get rid of that ambigious 'never' thing it allows

Then it would be a useful addition to the Reply-To header I think.

But that's me.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
He who renders warfare fatal to all engaged in it will be the greatest
benefactor the world has yet known.
 		-- Sir Richard Burton

To: [email-masked]
Xref: clerew local.mime:4752
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Understanding response protocols
Date: Thu, 2 Jun 2005 09:46:57 GMT
Lines: 44
Sender: [email-masked]

In <[email-masked]> Paul Jakma <[email-masked]> writes:

>But that's very configuration intensive. (Just as for the Reply-To 
>solution). "I like to be copied on wide-replies" tends to be a global 
>preference, it shouldn't need per-list configuration - just something 
>you set once in your MUA and leave be (maybe on very rare occassions 
>editing the header when composing an email, when it doesnt suit).

>I'd still love a Foo-Copy-Me type header, much easier and clearer. 
>But seems I wont get it. :(

Well, as MFT is currently implemented, either it gets filled in by the
mailing list administrator (according to whatever the "list policy" is),
or by the original poster - something like

    Mail-Followup-To: [email-masked],[email-masked]

For a man who wants personal as well as list replies. But to provide that
funtionality conveniently requires the poster's MUA to be configured with
a list of known mailing lists, and how the MFT is to be formed for each.

It would be better if there were a couple of keywords so you could say

    Mail-Followup-To: poster,list

and configure that for all lists you subscribe to.

That presumes the MUA generating replies can figure out what 'poster'
means (easy - use the Reply-To/From address) and what 'list' means (not so
easy if there is no List-Post field).

Actually, that is all beginning to look quite like the Mail-Copies-To
header sometimes used in News.

-- 
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: Wed, 1 Jun 2005 09:08:22 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Understanding response protocols
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, 30 May 2005, Charles Lindsey wrote:

> Does it really allow you to set the Reply-To field according to the 
> "role"?

Yes it does.

With the caveat that at present it doesn't allow multi-mailbox 
Reply-To's to be set. I intend to nag on the Pine list to try get 
that fixed.

> Certainly, the intention wrt Mail-Followup-To was that 
> users could set something like those "roles", but in a manner that 
> generated a MFT field depedong on the "role".

Sure, I could do that.

But that's very configuration intensive. (Just as for the Reply-To 
solution). "I like to be copied on wide-replies" tends to be a global 
preference, it shouldn't need per-list configuration - just something 
you set once in your MUA and leave be (maybe on very rare occassions 
editing the header when composing an email, when it doesnt suit).

I'd still love a Foo-Copy-Me type header, much easier and clearer. 
But seems I wont get it. :(

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Contemptuous lights flashed flashed across the computer's console.
-- Hitchhiker's Guide to the Galaxy

Date: Wed, 1 Jun 2005 09:03:52 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, 31 May 2005, Charles Lindsey wrote:

> Which is why there needs to be a standard to declare exactly what 
> it is supposed to do and not to do.

Yes, but just conceptually it's quite a broad concept.

Given the current state of things wrt Reply-To and MUA behaviour i 
think "Do no harm" should be a major factor. Adding scope for further 
ambiguity and/or diverging MUA behaviour is worse than present 
situation.

> Sure. But a proper MFT standard would state clearly who the reply 
> was to go to (subject to user override) in all the possible 
> combinations of List-Post fields, MFT fields, Reply-To fields, etc 
> that could arise.

Given previous discussion, it seems unlikely it could ever become a 
standard header though.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The poetry of heroism appeals irresitably to those who don't go to a war,
and even more so to those whom the war is making enormously wealthy."
 		-- Celine

Date: Wed, 1 Jun 2005 08:59:49 +0100 (IST)
From: Paul Jakma <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: mail-followup-to / mail-copies-to
Mail-Copies-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, 29 May 2005, Paul Jakma wrote:

> A major part of /my/ problem with using Reply-To for directing 
> list-replies is that many MUAs will then direct replies (be it 
> 'reply' or 'reply-all') to the mailbox(es) in the Reply-To field 
> automatically *without* involving their user in this decision, with 
> great risk that user doesn't even notice the redirection (and hence 
> commits an indiscretion by sending a private reply to multiple 
> addresses, not just the original author).
>
> If that annoying behaviour were discouraged via an official 
> document I could then whine at the implementors of such MUAs,

So is there any interest in this as a possible way forward?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Ow, my face is on fire!"

 	--Ralph Wiggum
 	  Bart of Darkness (Episode 1F22)