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: Rmail-mbox branch Date: Mon, 08 Sep 2008 13:57:40 +0900 Message-ID: <878wu3fd4r.fsf@xemacs.org> References: <87zlprvod0.fsf@stupidchicken.com> <4868CF84.1040005@pajato.com> <48A90589.4020804@pajato.com> <48A91146.60200@pajato.com> <48A968A3.8050806@pajato.com> <48BA1DAE.2030005@pajato.com> <874p51xblf.fsf@cyd.mit.edu> <84od39q9mv.fsf@boris.laptop> <84abesum0g.fsf@boris.laptop> <841w03v389.fsf@boris.laptop> <84wshvtgoz.fsf@boris.laptop> <87od363q1i.fsf@uwakimon.sk.tsukuba.ac.jp> <87iqtd4ubu.fsf@uwakimon.sk.tsukuba.ac.jp> <877i9s4pf5.fsf@uwakimon.sk.tsukuba.ac.jp> <87hc8vf97n.fsf@xemacs.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1220849596 22762 80.91.229.12 (8 Sep 2008 04:53:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2008 04:53:16 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@IRO.UMontreal.CA, evilborisnet@netscape.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 08 06:54:08 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KcYlK-0007Cn-UZ for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 06:54:07 +0200 Original-Received: from localhost ([127.0.0.1]:41999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcYkK-0005nd-QT for ged-emacs-devel@m.gmane.org; Mon, 08 Sep 2008 00:53:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcYkA-0005m1-8H for emacs-devel@gnu.org; Mon, 08 Sep 2008 00:52:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcYk7-0005kG-Ua for emacs-devel@gnu.org; Mon, 08 Sep 2008 00:52:52 -0400 Original-Received: from [199.232.76.173] (port=56412 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcYk7-0005kA-Mz for emacs-devel@gnu.org; Mon, 08 Sep 2008 00:52:51 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:40420) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcYk0-0005n5-UX; Mon, 08 Sep 2008 00:52:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 883A58003; Mon, 8 Sep 2008 13:52:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 81A971A431D; Mon, 8 Sep 2008 13:57:40 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 78738a40e31e XEmacs Lucid (x86_64-unknown-linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103667 Archived-At: Richard M. Stallman writes: > > It's the same difference as between text/plain and any of > > the other media types mentioned: you will cannot preserve > > all the information in a text/html part while saving it > > in mbox format. > > > > Why not? > > I have no clue what you could have in mind that you would ask > that question. > > I simply do not see why that claim would be true. > I thought you might provide an argument to support it. Let me try again, this time bluntly. I cannot determine from your disyllabic question, nor from the tenfold increased reiteration above, what claim you think I'm making. Specifically, I don't know whether a. you are unaware of the context of your question from my point of view and think I'm making a much broader claim than I intend, or b. you are nearly completely ignorant of the relevant aspects of how email works and don't understand the claim, which is obviously true to those who work with MIME email, or perhaps c. both, or even d. something else. Now, addressing confusion (a), paraphrased to compress thread context, I understand the question as "can we achieve interoperability with other MUAs, yet avoid (MIME-)decoding a message every time we present it?" The answer is "only if you're willing to destroy information" for all MIME types except 'text/plain; charset=us-ascii'. Addressing lack of knowledge (b), the multimedia functionality common to Internet MUAs expects to be handed messages in a complex form defined by RFCs 2821, 2822, 2045-2049, 2231, and several others of subsidiary interest. The first two RFCs establish the requirement that mail shall be transmitted as plain ASCII text.[1] The rest provide various conventions for how to serialize quite arbitrary objects, from non-ASCII text to video clips to binary blobs, as plain ASCII text. They are the *only* conventions commonly adopted by MUA authors as defining non-ASCII-text email.[2] Therefore, it simply is not possible to save Emacs's presentation of HTML in *any form other than an HTML MIME body* that can be *expected* to be operated on usefully by other MUAs. Except if that form strips out the HTML-specific formatting information, links, multimedia, etc., and turns it into plain ASCII text, which all MUAs must be able to handle. Thus, to preserve all information it needs to be left as an HTML MIME body in the mbox file, and therefore it will need to be decoded every time it is presented. It should be clear that the same rationale applies to any emailed object which is not MIME 'text/plain; charset=us-ascii'.[3] I hope that makes it clear that the constraints are on Rmail/mbox are that you can get the first two but not the third of these desiderata: 1) interoperability with other MUAs (including a future Rmail with real MIME capability); 2) preservation of all information in each message in the folder; and 3) saving the decoded form of each message in the folder in lieu of the MIME-encoded message. I advocate abandoning the last, as it's not a perceptible efficiency gain in the context of Rmail. Stefan and Paul have both acknowledged that the runtime cost of decoding is negligible. It's also safe and easy to provide a per-message cache in the form of RFC 2822 extension fields in the message header, with the only constraint being to respect the ASCII-only restriction of RFC 2822 for header fields. Footnotes: [1] Indeed there are non-ASCII-text "content transfer encodings", but they are not considered as reliable, and in my experience they are not as reliable as the ASCII-based ones. In general, a private agreement between mail agents is required for use of the non-ASCII-based ones, as conformance is not universal. [2] With the likely exception of uuencoded file attachments, which I believe even Microsoft Outlook still recognizes. [3] For practical purposes we can assume that message bodies which are 'text/plain; charset=XYZ' for XYZ=iso-8859-1, XYZ=iso-8859-15, and XYZ=utf-8 will generally "just work", too. But it's easy to imagine situations where a MIME-conforming MUA might render such incorrectly without a MIME Content-Type header to guide it, such as a Latin-2- using locale.