From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r104691: Don't reuse previous Message-id when resending. Date: Tue, 28 Jun 2011 05:28:54 +0900 Message-ID: <87r56f10jd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mxh37nfp.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309210569 29327 80.91.229.12 (27 Jun 2011 21:36:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Jun 2011 21:36:09 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 27 23:36:04 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QbJTO-0006gz-VF for ged-emacs-devel@m.gmane.org; Mon, 27 Jun 2011 23:36:03 +0200 Original-Received: from localhost ([::1]:50749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbJTN-0001Hn-GE for ged-emacs-devel@m.gmane.org; Mon, 27 Jun 2011 17:36:01 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbIQS-000130-Ny for emacs-devel@gnu.org; Mon, 27 Jun 2011 16:28:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbIQQ-0000NO-OS for emacs-devel@gnu.org; Mon, 27 Jun 2011 16:28:56 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:42333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbIQQ-0000Mt-3v; Mon, 27 Jun 2011 16:28:54 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id ECE793FA06E2; Tue, 28 Jun 2011 05:28:49 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2FAC61A2628; Tue, 28 Jun 2011 05:28:54 +0900 (JST) In-Reply-To: X-Mailer: VM 8.1.93a under 21.5 (beta31) "ginger" cd1f8c4e81cd XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141091 Archived-At: 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.