Subject: Re: best name for followups?
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Date: 30 Jun 1997 23:48:22 -0000

It's important to understand that the author sets followups. Let me
emphasize once again that reply-to munging is harmful; the question is
how to fix the message duplication _without_ reply-to munging.

In light of this understanding, let's review Keith's complaints:

> + The author of the subject message isn't always on the mailing list,
> in which case he misses the replies/followups.

No, he doesn't miss anything, because he puts his own address into the
followup field along with the list address.

Of course, he doesn't have to bother with a followup field in this case,
since the default followup targets will work properly.

If he _is_ on the list, he should supply a followup field without his
address. His MUA can do this automatically if it knows that he's on the
list; some MUAs already support the necessary database.

> + A single message can be posted to multiple mailing lists, in which
> case followups should arguably go to all lists.

So the user puts all the lists into the followup field.

MUAs configured as above will do the right thing automatically.

> When replies
> from my list postings go to [email-masked], I can respond more
> quickly.

So leave your address in the followup field. You have control.

(Btw, why is ietf-822 so slow? It doesn't look good for a mailing list
to take half an hour to distribute a message---especially when it's a
mailing list for mail implementors!)

> And a followup-to like header is certainly not "the" only available
> solution.  For instance, UAs could suppress duplicate messages.

Suppressing duplicates is fine, if you can afford to do it securely, but
it solves only half the problem.

After a long sequence of followups---let's say a sequence of 500
messages from different contributors---there are, with current defaults,
501 recipient addresses in the header. Software breaks. Humans can no
longer read the header. Each new message takes ten times as much archive
space as it should. Every contributor is at risk of being a permanent
recipient of a neverending discussion; there is no escape.

Of course, people don't let the header grow so much. They trim it down
to just the list address. But this introduces some of the same problems
as reply-to munging; for example, it destroys cross-posted discussions.

With a followup field, the solution is trivial: the MUA copies the
message's followup field into subsequent followups by default.

> Even if you only have reply, sometimes you want to reply to author
> only, sometimes to author and all recipients, sometimes to author and
> particular recipients, etc.

So what? Are you going to argue that we shouldn't have Reply-To since
people sometimes want followups instead?

> Add a followup-to
> (wide-reply-to, group-reply-to whatever) field to the mix and it just
> makes things more confusing.

Explanation, please. Who exactly would be confused?

Users will have a button for replies, just as they do now.

Users will have a button for followups, just as they do now.

They can control replies with Reply-To, just as they do now.

They can control followups with the new field. This is much simpler than
the current situation.

> What we haven't had is
> agreement that such proposals, if adopted, would do more good than
> harm.

Explanation, please. How exactly would a followup field hurt anyone?

> We've already had proposals for a name.

I know. I don't think ``Wide-Reply-To'' will work. As you can easily
verify, ``wide reply'' is meaningless for a typical user. (``Does that
have something to do with the window size?'') Even when the MUA has a
``wide reply'' feature, most users have no clue what it does.

``Group reply'' is somewhat better (and apparently more common in MUAs),
but still not immediately clear to most users.

Any other suggestions?

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: best name for followups? 
Date: Mon, 30 Jun 1997 16:58:36 -0400
Sender: [email-masked]

> ``Every time you do a "Group-reply" some poor shmoes are receiving
> duplicate e-mails.''
> 
> This is one user's description of what happens when you follow up to
> 
>    From: Member <[email-masked]>
>    To: List <[email-masked]>
> 
> It's used as a justification---in fact, the only justification---for
> reply-to munging, i.e., adding Reply-To: [email-masked].
>
[...]
>
> This problem is well known. The solution---having a header field that
> says where to send followups---has been proposed many times. But MUAs
> don't seem to support any such field. Why not?

Partially because there's not a consensus that this is a good idea.

Even if you only have reply, sometimes you want to reply to author
only, sometimes to author and all recipients, sometimes to author and
particular recipients, etc.  Sometimes you want to use the reply-to
field; other times you want to override that field.  Add a followup-to
(wide-reply-to, group-reply-to whatever) field to the mix and it just
makes things more confusing.  (e.g. Sometimes you really do want to
reply to the From/to/cc addresses instead of the addresses in either
the followup-to or reply-to fields.  etc.)

Followup-to would also not solve many of the problems that currently
exist with list reply-to munging:

+ The author of the subject message isn't always on the mailing list,
in which case he misses the replies/followups.

+ A single message can be posted to multiple mailing lists, in which
case followups should arguably go to all lists.  (Yes, this is
annoying for those on several of those lists, but cross-list
discussions are often useful.)

+ The author may post from a different address than his list
subscription.  I post from [email-masked] but get inbound list mail
at [email-masked]; and inbound list mail gets read at a
lower priority than mail sent to my primary mailbox.  When replies
from my list postings go to [email-masked], I can respond more
quickly.

And a followup-to like header is certainly not "the" only available
solution.  For instance, UAs could suppress duplicate messages.  This
doesn't require any changes to the protocols, or to the list servers,
and has immediate benefit for anyone whose UA implements it.  

(Though there are security risks with trusting message-ids alone for
this...you have to actually compare the messages to see if they're
similar enough to call them duplicates.  But message-ids should be a
good way to identify *candidates* for duplicate suppression.)

> Perhaps it would help to have a good name. ``Followup-To'' is taken by
> news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are
> incomprehensible to novice users. ``Followups'' might work, but it's
> probably too close to ``Followup-To''.

We've already had proposals for a name.  What we haven't had is
agreement that such proposals, if adopted, would do more good than
harm.

Keith

Date: 30 Jun 1997 05:12:47 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: best name for followups?
Sender: [email-masked]

``Every time you do a "Group-reply" some poor shmoes are receiving
duplicate e-mails.''

This is one user's description of what happens when you follow up to

   From: Member <[email-masked]>
   To: List <[email-masked]>

It's used as a justification---in fact, the only justification---for
reply-to munging, i.e., adding Reply-To: [email-masked].

As http://www.unicom.com/FAQ/reply-to-harmful.html explains in detail,
reply-to munging is harmful. But the user's criticism is still valid.
Followups produce duplicates.

You might suggest leaving From out of the followup address list. But
that's even worse: if the sender isn't in the To line he won't get a
copy of the followup.

This problem is well known. The solution---having a header field that
says where to send followups---has been proposed many times. But MUAs
don't seem to support any such field. Why not?

Perhaps it would help to have a good name. ``Followup-To'' is taken by
news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are
incomprehensible to novice users. ``Followups'' might work, but it's
probably too close to ``Followup-To''.

Any ideas? How many MUA implementors do we have here, anyway?

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

From: Keith Moore <[email-masked]>
To: Chris Newman <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Accept-Language: proposal 
Date: Mon, 16 Jun 1997 14:21:03 -0400
Sender: [email-masked]

> On Fri, 13 Jun 1997, Keith Moore wrote:
> > I don't think the UTF-8 requirement is reasonable.  
> > It seems like this would impose a huge implementation burden for most UAs.
> > With this requirement in place, most people can't use it or benefit
> > from it.  Without this requirement, many users could just add a header
> > field to outgoing mail specifying the languages and charsets that the
> > user can deal with, without needing UTF-8 support. 
> 
> I disagree with this point.  UTF-8 is not particularly hard to support --

It would require a huge effort to take every tool that I use to
process mail, and extend them all to use UTF-8.  This remains true
even if I only care about supporting the 8859/1 subset.

(in my case, we're talking MH, exmh, metamail, xterm, procmail,
/bin/mail, and numerous scripts)

> We need to start "hooking" UTF-8 to proposals like this so that we can
> transition away from the current mess of character sets we have.  

I strongly disagree.  I want to encouage a transition to UTF-8, but
not by "hooking" it to what would otherwise be a very simple and
useful extension, and not in such a way that it would have a severe
adverse impact on the installed base.

We haven't yet recovered from the 822-to-MIME transition.  The vast
majority of mailers out there can't yet deal with it adequately.
(They may have some support for it, but in general it seems to be
lousy.)  To raise the bar further at this point would not encourage
adoption of UTF-8, it would just degrade interoperability.  Some tools
would ignore the UTF-8 requirement and generate accept-language
anyway; other tools would use this as an excuse to send UTF-8 to those
in the first set and thus annoy the user.  Many tools would implement
UTF-8 poorly (just as they have implemented MIME poorly) and this
would be an additional source of user complaints.

Neither is it reasonable for every UA that sends messages, to assume
that the reply will be read (or processed) by a UA with the same
capabilities.  It might be reasonable to assume that it will be read
by the same *user*, but it's quite unreasonable to assume that the
message will be read by the same *tool*, or even on the same host.

Keith

From: "Jeff Stephenson (Exchange)" <[email-masked]>
To: "'John Gardiner Myers'" <[email-masked]>, [email-masked]
Subject: RE: Accept-Language: proposal
Date: Mon, 16 Jun 1997 08:42:37 -0700
Sender: [email-masked]

It seems to me that it would be better to have the UA provide a
localized human-readable explanation of the error based on the enhanced
error codes, for two reasons:

1)  This proposal, to be useful, requires that MTAs be able to generate
DSNs in a large number of languages.  In practice, I suspect that you'd
find maybe 5 or 6 major languages being supported, with the result that
in many cases DSNs would still end up being generated in English.
2)  The user agent, almost by definition, is going to be localized for
any particular user; it can use the enhanced error codes to generate an
appropriate message.  Further the UA is in a position to tell the user
what, if anything, they can do about the problem using that particular
UA.

I also share Keith's concern about the layering issue: this
functionality should be an SMTP extension rather than an 822 header.
But unless I'm missing something, I don't think it should be either -
enhanced error codes should be all that's required.

-- jeff

> -----Original Message-----
> From:	John Gardiner Myers [SMTP:[email-masked]]
> Sent:	Friday, June 13, 1997 12:09 PM
> To:	[email-masked]
> Subject:	Accept-Language: proposal
> 
> I have a need to localize the human-readable text inside of DSN's and
> other automated responses to 822-format messages.  Here is a proposal
> I
> would like to float here, prior to issuing an internet-draft.
> 
<...snip...> 

> Disadvantages:
> 
> Does not necessarily work correctly if the message goes through list
> expansion.  The language preferences of the list maintainer can be
> different than those of the original sender, so if the list expander
> does not know to strip or replace the Accept-Language header, the list
> maintainer could get DSN's in a language and charset they don't
> understand.
> 
> So, what do people think?

Date: Sun, 15 Jun 1997 19:15:10 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Accept-Language: proposal
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I have a need to localize the human-readable text inside of DSN's and
> other automated responses to 822-format messages.  Here is a proposal I
> would like to float here, prior to issuing an internet-draft.

> Rough definition:

> Define an "Accept-Language" header with the following syntax.

> accept-language = "Accept-Language" ":" 1#Language-tag
> 			; Language-tag as defined in RFC 1766

> This header discloses the language preference(s) of the sender.
> Languages listed earlier in the list are preferred.

I agree with Larry that use of Accept-Language: in this fashion, which doesn't
correspond to the HTTP semantics, is a showstopper. The IETF has both critiqued
and modified HTTP usage where that usage conflicts with MIME, and I think the
IETF was correct in doing this. But it is only fair that when the shoe is on
the other foot, and we're defining stuff for MIME-based but non-HTTP-based
protocols like Internet mail, that we pay attention to HTTP usage and not do
things that conflict with it.

There are two ways to solve this problem. One is to use the same field
name and keep the semantics the same. The other is to define a new field
with limited semantics.

I see problems with both approaches. The first seems excessive for the
stated application. And the second only solves this one problem without
providing a basis for other sorts of capability discovery (e.g. discovery
of support for things other than langauge, support for different capabilities
for different sorts of messages like notifications, receipts, replies, or
new mail).

Capability discovery in email should either be done right or not done at all.
A point solution specifically for this one limited application is a good
idea if and only if we decide right her and now that this is the only
sort of capability discovery we ever intend to do. And since I do not believe
that this is the only sort we want I don't think this is a good idea.

> The existence of this header also indicates that the sender is capable
> of handling text encoded in the utf-8 charset [RFC 2044], when properly
> MIME labeled.

I agree with Larry about this as well -- the issue of language and character
set are largely orthogonal, and as such should not be coupled in this bizzarre
way. I have no problem with a mechanismm that lets you say you want responses
to be in UTF-8 per se; however, such a mechanism should be part of a more
general capability discovery system and not coupled to language like it 
was an afterthought as this proposal does.

> Does not necessarily work correctly if the message goes through list
> expansion.  The language preferences of the list maintainer can be
> different than those of the original sender, so if the list expander
> does not know to strip or replace the Accept-Language header, the list
> maintainer could get DSN's in a language and charset they don't
> understand.

This is exactly why such a mechanism has to be done right -- there's
clearly a distinction between what the list moderator wants in notifications
and what a message originator wants in a reply. And don't think for a
minute that should you define a field like this that it won't end up being
used to control other sorts of automated and even manual replies -- it will.

				Ned

Date: Sat, 14 Jun 1997 23:33:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Accept-Language: proposal
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Fri, 13 Jun 1997, Keith Moore wrote:
> I don't think the UTF-8 requirement is reasonable.  
> It seems like this would impose a huge implementation burden for most UAs.
> With this requirement in place, most people can't use it or benefit
> from it.  Without this requirement, many users could just add a header
> field to outgoing mail specifying the languages and charsets that the
> user can deal with, without needing UTF-8 support. 

I disagree with this point.  UTF-8 is not particularly hard to support --
it's certainly much easier to support than a large table of multiple
charsets for each language and all the cross-conversions (which often use
Unicode as an intermediate).

We need to start "hooking" UTF-8 to proposals like this so that we can
transition away from the current mess of character sets we have.  In
addition, an "accept-language" header which requires UTF-8 is a far
simpler architecture than a combination of "accept-language" and
"accept-charset".  Given the IAB charset workshop guidelines I think it
would be a mistake to let "accept-charset" leak out of HTTP.

Date: Fri, 13 Jun 1997 17:45:47 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Accept-Language: proposal
Sender: [email-masked]

Let me try to say this differently:

Headers should be compatible between HTTP and mail: that is,
a single message header should have the same meaning, no 
matter which protocol is being used.

Accept-Language already has a meaning in HTTP. If you want
to use it in mail, you should only use it with the same meaning.
Do not attach new meanings to the same header. If you really
need a different meaning, then use a different header name.

> I disagree that the reasons for accept-charset in HTTP apply equally to
> mail.
> 
> 1) In mail, the lack of interactivity significantly raises the
> importance of using a canonical format over the importance of having the
> sender avoid the cost of converting from local form to canonical form.
> 
> 2) Time has passed on since accept-charset was designed.  The report of
> the IAB Character Set Workshop strongly recommends transitioning to
> ISO-10646 based charsets, such as UTF-8 and/or UTF-7.

I don't see what these have to do with it; you might as well just
assume you can always send UTF-8, then. Whether or not "Accept-Language"
is present in the message doesn't have much to do with it.

In fact, "Accept-Language" is a misnomer; it should probably have been
called "Prefer-Language".

If you want to have a header that means "You can reply with UTF-8",
why not make it "Mime-Version: 1.1" or something; the appearance of
accept-language is not by itself an indication of anything other than
language preference.

Larry

From: Keith Moore <[email-masked]>
To: John Gardiner Myers <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Accept-Language: proposal 
Date: Fri, 13 Jun 1997 19:21:17 -0400
Sender: [email-masked]

If it's not going to have the syntax used in HTTP, I'd rather
have it called by some other name.  

I don't think the UTF-8 requirement is reasonable.  
It seems like this would impose a huge implementation burden for most UAs.
With this requirement in place, most people can't use it or benefit
from it.  Without this requirement, many users could just add a header
field to outgoing mail specifying the languages and charsets that the
user can deal with, without needing UTF-8 support. 

Also, the chosen I18N approach to DSNs was to define precise
error codes and include enough information so that the error
could be presented in the user's language by the user agent.
As far as I can tell, the error codes are usually adequate for this
purpose, in that they can describe most conditions with sufficient
precision.  So I have to wonder if this is really needed for DSNs.

And while I could see something like this header being used for
email-based document requests, for it to affect DSNs would require 
that MTAs look at the header of the subject message.   This
is a layering violation.

Keith

Date: Fri, 13 Jun 1997 15:21:03 -0700
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Re: Accept-Language: proposal
Sender: [email-masked]

Larry Masinter wrote: 
> Please no.

Do you mean "no, please define accept-charset as well" or "no, please
call this header something other than accept-charset"?  I strongly
disagree with the former, I could be convinced of the latter.

> In HTTP, accept-language and accept-charset are orthogonal,
> and the reasons for making them so in HTTP apply equally to mail.

I disagree that the reasons for accept-charset in HTTP apply equally to
mail.

1) In mail, the lack of interactivity significantly raises the
importance of using a canonical format over the importance of having the
sender avoid the cost of converting from local form to canonical form.

2) Time has passed on since accept-charset was designed.  The report of
the IAB Character Set Workshop strongly recommends transitioning to
ISO-10646 based charsets, such as UTF-8 and/or UTF-7.

[email-masked] wrote:
> This AIX 4.2 box I'm typing on has *some* UFT-8 support.  However,
> my MUA does not support it, nor do I have fonts to cover the entire UTF-8
> space.

Your MUA also doesn't support the accept-language header.  In order for
it to support the accept-language header, it would have to be extended
to understand the UTF-8 charset.

It is not necessary that your MUA be able to display the entire UTF-8
codepoint space.  It is only necessary for your MUA to be able to
display that subset of the space that is necessary to display text in
the languages that are advertised.  If text in your languages all fit
into iso-8859-1, for example, your MUA only has to be able to convert
from UTF-8 to iso-8859-1 when displaying text.

> Also, remember that UTF-8 is only an *encoding* scheme.  It is *not* an
> internationalization or localization scheme.  As such, things like currency
> formats, date/time preferences, and sorting/collating issues are totally
> not addressed.  If the person requests Cyrillic, what's the format of the
> date?

These issues are addressed by the language tags in the accept-language
header.  The person does not request Cyrillic, they request a specific
language that happens to use Cyrillic characters.

> Why are you implying UTF-8 support? What does this buy you?

Simplicity.  It removes the need for senders and recipients to negotiate
and convert amongst a large number of different charsets.  It removes
the possibility of having a successful negotiation of a common language
be stymied by a failure to negotiate a common charset capable of
representing the necessary characters.

> How about an alternative of "Return English if you can't supply in one of
> the requested languages"?  This would eliminate a UTF-8 requirement, and
> be more backward-compatible as well..

This alternative would not remove the UTF-8 requirement.  Once a sender
has determined which language to use, it has the problem of figuring out
which charset is both capable of expressing text in that language and
which will be understood by the recipient.  Without either a separate
charset negotiation or charset support being communicated by the
accept-language header itself, only us-ascii is known to be supported by
the recipient.

To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Subject: Re: Accept-Language: proposal 
From: [email-masked]
Date: Fri, 13 Jun 1997 16:19:15 -0400
Sender: [email-masked]

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

On Fri, 13 Jun 1997 12:08:38 PDT, you said:
> The existence of this header also indicates that the sender is capable
> of handling text encoded in the utf-8 charset [RFC 2044], when properly
> MIME labeled.

Umm.. yeah, but.. this may not do what you hope.

This AIX 4.2 box I'm typing on has *some* UFT-8 support.  However,
my MUA does not support it, nor do I have fonts to cover the entire UTF-8
space.

Also, remember that UTF-8 is only an *encoding* scheme.  It is *not* an
internationalization or localization scheme.  As such, things like currency
formats, date/time preferences, and sorting/collating issues are totally
not addressed.  If the person requests Cyrillic, what's the format of the
date?

Why are you implying UTF-8 support? What does this buy you?

> Since this header is presumably only going to be generated by "new"
> UA's, it is not unreasonable to require these "new" UA's to support
> UTF-8.  The alternative of also negotiating acceptable charset is worse.

How about an alternative of "Return English if you can't supply in one of
the requested languages"?  This would eliminate a UTF-8 requirement, and
be more backward-compatible as well..
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

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

--==_Exmh_2109757544P--

Date: Fri, 13 Jun 1997 12:58:20 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: John Gardiner Myers <[email-masked]>
CC: [email-masked]
Subject: Re: Accept-Language: proposal
Sender: [email-masked]

> The existence of this header also indicates that the sender is capable
> of handling text encoded in the utf-8 charset [RFC 2044], when properly
> MIME labeled.
> 

Please no.

> The syntax of this header is deliberately a subset of that in HTTP.

Please don't use something with the same syntax but different
semantics. In HTTP, accept-language and accept-charset are orthogonal,
and the reasons for making them so in HTTP apply equally to mail.

Larry
-- 
http://www.parc.xerox.com/masinter

Date: Fri, 13 Jun 1997 12:08:38 -0700
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Accept-Language: proposal
Sender: [email-masked]

I have a need to localize the human-readable text inside of DSN's and
other automated responses to 822-format messages.  Here is a proposal I
would like to float here, prior to issuing an internet-draft.

Rough definition:

Define an "Accept-Language" header with the following syntax.

accept-language = "Accept-Language" ":" 1#Language-tag
			; Language-tag as defined in RFC 1766

This header discloses the language preference(s) of the sender. 
Languages listed earlier in the list are preferred.

The existence of this header also indicates that the sender is capable
of handling text encoded in the utf-8 charset [RFC 2044], when properly
MIME labeled.

Comments:

The syntax of this header is deliberately a subset of that in HTTP.

Since this header is presumably only going to be generated by "new"
UA's, it is not unreasonable to require these "new" UA's to support
UTF-8.  The alternative of also negotiating acceptable charset is worse.

Disadvantages:

Does not necessarily work correctly if the message goes through list
expansion.  The language preferences of the list maintainer can be
different than those of the original sender, so if the list expander
does not know to strip or replace the Accept-Language header, the list
maintainer could get DSN's in a language and charset they don't
understand.

So, what do people think?