From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 24F65429E25 for ; Sun, 20 Nov 2011 12:11:12 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDbYlBT62C0T for ; Sun, 20 Nov 2011 12:11:09 -0800 (PST) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by olra.theworths.org (Postfix) with ESMTP id 7431F431FD0 for ; Sun, 20 Nov 2011 12:11:09 -0800 (PST) Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1]) by earth-doxen-postvirus (Postfix) with ESMTP id E6CA766E075F; Sun, 20 Nov 2011 12:11:08 -0800 (PST) X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new Received: from finestructure.net (cpe-76-174-136-149.socal.res.rr.com [76.174.136.149]) (Authenticated sender: jrollins) by earth-doxen-submit (Postfix) with ESMTP id EDAE066E0754; Sun, 20 Nov 2011 12:10:55 -0800 (PST) Received: by finestructure.net (Postfix, from userid 1000) id 5DF73BBC; Sun, 20 Nov 2011 12:10:55 -0800 (PST) From: Jameson Graef Rollins To: Dmitry Kurochkin , notmuch@notmuchmail.org Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON format. In-Reply-To: <87r512pru2.fsf@gmail.com> References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com> <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com> <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com> User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Sun, 20 Nov 2011 12:10:52 -0800 Message-ID: <87ipmewo4z.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 20:11:12 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin wrote: > Yes, at least in most cases. On the other hand, if you can make notmuch > show raw multipart part (you can, right?), then it seems natural that > notmuch provides enough information to parse it. This is kind of an unresolved issue, actually. Currently headers are only included in the "raw" format output of an entire message. Otherwise, when raw output is requested of an individual part only the body is output. For multipart parts, the raw format output includes all body parts concatenated together, still without any headers. This "raw" multipart output clearly doesn't really make much sense and we need to figure that out. dkg wrote a good breakdown of the issue here: id:"4E09072A.7040906@fifthhorseman.net" However, this only for "raw" output. It's definitely not the same as the json output. For json the parts are all parsed by notmuch and placed into separate json elements. The receiver is not going to do any further parsing since all the mime structure parsing has been done. We need to keep clear the distinction between "parsing" the mime structure, and "encoding" the content of the part. Confusion seems to be coming from the fact that the Content-Type header includes information needed for both mime parsing and content encoding. However, I don't think that means that we need to just include everything in the output. Parameters that have to do with mime parsing should be dropped, since that information has already been used in the mime parsing and can't is no longer useful to the consumer. It's just noise, and I don't think notmuch should be outputting useless noise. The open question seems to be how we handle the content encoding parameters. My argument is that those should either be used by notmuch to properly encode the content for the consumer. If that's not possible, then just those parameters needed by the consumer to decode the content should be output. > > But isn't that actually a large part of the issue? If this patch fixes > > something that you think notmuch is doing improperly, could there not be > > a test for it? >=20 > No. It just happens to be how I found the problem. The issue is: > notmuch JSON format mangles Content-Type header value by throwing away > useful information in some cases and adding info that was not there in > others. Note that I do not mention any single parameter name here. It > is a general issue, not a "charset" or "boundary" parameter issue. I'm sorry, but I still don't believe it's not possible to test for this issue. If there's a problem that you're seeing, then you must of identified it somehow, and therefore there must be a way to test for it. jamie. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOyV7NAAoJEO00zqvie6q89j8QAIwLpC2PTwk4ceoYJ9e44uSf 2yJupIVV3+wpWqMsg7q0mY7ofNg367jFyMwF4iyWrm+cq+14O9tiGYJ0l+HoG9uk rSps+BNWVKCjiAE+MROgAWzF7BIwdbmClWzE9tIP/Scj5gbDGdcwTQYCapXs3U56 ENnZP90DBpAkwGyPS12JqWDVhM9jjaRg38XM4OLhgwWc547AYAMjqaE15fe9U3PV gufXtv65ECkqLlPrHwdXNzJYsLaitRZTukAIePYcXl9OFW9HPa39DoDP8azU4jLj 7hzPB9Gs4nPRTf5SWGUK4r/5VAszh3awSHuyAs3WQL3eZyyhsJlQaCz5qI16vt+/ U8oNqzAfbkaZh9SSg35IlKjdA6jJ/devpdwo3aEUTY37bsBzti+WxuFQpLpgF3NV ZtonJGBaIDYMU67tCqt0t8rhq0IQ/fHjuT4eh6zuHVT4nnGZcCfp9CTb+qgKLOq7 Wpa+OMnlldifAN18bMuu2R4SHvCSIjboIQ4ZEUtVTZKknGjfShT76SPywowun1ek FcvOFxrZfXa5cc430sSrugf0NeHPfrXDUdoMB2AoxczNYpiir+ZD4kc71Ez6fgGO yg3pLUt3XHzE6+vXqcoCoUZUbZbPeddxntP+Mo3MnP/+tEuWKGSVbFK/s7AtUzxC 28dyJXd23Xx2g9T0JZbx =+r3R -----END PGP SIGNATURE----- --=-=-=--