Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104691: Don't reuse previous Message-id when resending.

[Stephen J. Turnbull]

Richard Stallman writes:

 > I cannot follow that concretely.

Maybe you should have asked about that, then.  It's important.

 > However, it is perfectly normal to write multiple responses to a
 > single incoming message.

Sure.  I haven't used RMail in decades, but I seem to recall that
there are several ways to do that if your intent is to reply with
different content each time.  But retrying a failed message isn't one
of them; that's a different use case, and typically in my experience
involves not changing the message body at all.

 > Retrying the first response with a new Message-ID is a special case
 > of that, so it can't be wrong.

In general, however, it is not conforming to the RFC, which specifies
that if the sender considers the content of the message to be the
same, the Message-ID should be the same.  You encountered software
that cannot handle two messages with the same ID, so you want this.
Fully conforming, as long as you only do this for yourself.

That, however, is a very rare use case.  (At least, I've never heard
of it before.)  Most users will expect the semantics that two messages
with different Message-IDs have different content, and that is *why*
the RFC is specified as it is.

If what you mean is that you edit the message so that it has somewhat
different content, then indeed I expect it should in most cases have a
different Message-ID (although that's up to the sender).  However, I
wouldn't consider that a typical retry -- almost all of my retries
simply involve fixing an address typo and resending content as is.  Do
you have a reason for frequently doing something else, I mean one that
would apply to enough users to justify the change in default?

 > I am confident that any programs designed to keep track of threads
 > do something reasonable in this case.

Your confidence has no bearing on correctness, unfortunately.  You're
wrong.  This introduces an ambiguity that can only be handled by
analyzing the content of the message and attempting to guess whether
the sender thinks of this as a new message.  That's a hard problem.

What threading MUAs do in practice is to punt.  They see different
Message-IDs and they split the thread, although none of the
correspondents want that since they all perceive the messages as being
a single message that arrived multiple times (usually at different
places; it's even more annoying if it arrives twice in the same
mailbox with different Message-IDs).

There is no mechanical way to merge threads once split; you have to
persuade all of the participants to abandon one thread and concentrate
on the other, which is pretty chancy at best.  In practice it's common
for latecomers to respond to the "wrong" subthread because it seems to
just have left obvious issues unresolved.

 >      > It isn't wrong.
 > 
 >     Sorry, Richard, that is not yours to decide.
 > 
 > It is not up to you what the GNU Project can decide.

When put that way, no, of course not.  What I meant is, "feel free to
disagree with the rest of the world, and be aware that those you need
to cooperate with to use email will consider your decision *wrong*."

 > In the GNU Project, we do not obey standards -- we consider them, then
 > DTRT.

Yeah, I know.  I'm not suggesting that you change that, just this
default.

 > You can make arguments about what is TRT, but they can only succeed if
 > they do not presume the RFC has authority.

"Authority"?  *This* RFC has been best practice for the largest
electronic community in existence for longer than Emacs has been in
existence.  Call that "authority" if you like, but I prefer to think
of it as "listening to others' experience."  Emacs is only hurting
itself if it defaults to semantics which few users will expect, even
if it's only occasionally noticable.

 >     in general it is the sender's decision, not the implementer's
 > 
 > I agree, and that's how it is.  This variable specifies the way the
 > mail buffer is initialized.  The user has ultimate control.

Control is only useful if the user is informed of the choice they need
to make, and have a convenient way to implement it.  For most users
leaving things as they were does the right thing without them thinking
about it at all, and that's a good thing.  On the other hand, with the
default as you specify it, the consequences are unobvious, and
recovery is impossible once the message is sent, and difficult at best
during the composition stage.

In other words, the default you specified is going to cause naive
users to do themselves inadvertant harm.  You know what you are doing
and why, they don't.  So you should customize that variable for
yourself and let Emacs have a safe default.