84/666503f1a2b0c063c4a4d04911a80f1ba306d0

   1 Return-Path: <jrollins@finestructure.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 24F65429E25\r
   6         for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 12:11:12 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.29\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id GDbYlBT62C0T for <notmuch@notmuchmail.org>;\r
  16         Sun, 20 Nov 2011 12:11:09 -0800 (PST)\r
  17 Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
  18         [131.215.239.19])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 7431F431FD0\r
  20         for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 12:11:09 -0800 (PST)\r
  21 Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
  22         by earth-doxen-postvirus (Postfix) with ESMTP id E6CA766E075F;\r
  23         Sun, 20 Nov 2011 12:11:08 -0800 (PST)\r
  24 X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new\r
  25 Received: from finestructure.net (cpe-76-174-136-149.socal.res.rr.com\r
  26         [76.174.136.149]) (Authenticated sender: jrollins)\r
  27         by earth-doxen-submit (Postfix) with ESMTP id EDAE066E0754;\r
  28         Sun, 20 Nov 2011 12:10:55 -0800 (PST)\r
  29 Received: by finestructure.net (Postfix, from userid 1000)\r
  30         id 5DF73BBC; Sun, 20 Nov 2011 12:10:55 -0800 (PST)\r
  31 From: Jameson Graef Rollins <jrollins@finestructure.net>\r
  32 To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
  34         format.\r
  35 In-Reply-To: <87r512pru2.fsf@gmail.com>\r
  36 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  37         <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
  38         <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
  39 User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1\r
  40         (x86_64-pc-linux-gnu)\r
  41 Date: Sun, 20 Nov 2011 12:10:52 -0800\r
  42 Message-ID: <87ipmewo4z.fsf@servo.finestructure.net>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: multipart/signed; boundary="=-=-=";\r
  45         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  46 X-BeenThere: notmuch@notmuchmail.org\r
  47 X-Mailman-Version: 2.1.13\r
  48 Precedence: list\r
  49 List-Id: "Use and development of the notmuch mail system."\r
  50         <notmuch.notmuchmail.org>\r
  51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  54 List-Post: <mailto:notmuch@notmuchmail.org>\r
  55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  58 X-List-Received-Date: Sun, 20 Nov 2011 20:11:12 -0000\r
  59 \r
  60 --=-=-=\r
  61 Content-Transfer-Encoding: quoted-printable\r
  62 \r
  63 On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmai=\r
  64 l.com> wrote:\r
  65 > Yes, at least in most cases.  On the other hand, if you can make notmuch\r
  66 > show raw multipart part (you can, right?), then it seems natural that\r
  67 > notmuch provides enough information to parse it.\r
  68 \r
  69 This is kind of an unresolved issue, actually.  Currently headers are\r
  70 only included in the "raw" format output of an entire message.\r
  71 Otherwise, when raw output is requested of an individual part only the\r
  72 body is output.  For multipart parts, the raw format output includes all\r
  73 body parts concatenated together, still without any headers.\r
  74 \r
  75 This "raw" multipart output clearly doesn't really make much sense and\r
  76 we need to figure that out.  dkg wrote a good breakdown of the issue\r
  77 here:\r
  78 \r
  79 id:"4E09072A.7040906@fifthhorseman.net"\r
  80 \r
  81 However, this only for "raw" output.  It's definitely not the same as\r
  82 the json output.  For json the parts are all parsed by notmuch and\r
  83 placed into separate json elements.  The receiver is not going to do any\r
  84 further parsing since all the mime structure parsing has been done.\r
  85 \r
  86 We need to keep clear the distinction between "parsing" the mime\r
  87 structure, and "encoding" the content of the part.  Confusion seems to\r
  88 be coming from the fact that the Content-Type header includes\r
  89 information needed for both mime parsing and content encoding.  However,\r
  90 I don't think that means that we need to just include everything in the\r
  91 output.  Parameters that have to do with mime parsing should be dropped,\r
  92 since that information has already been used in the mime parsing and\r
  93 can't is no longer useful to the consumer.  It's just noise, and I don't\r
  94 think notmuch should be outputting useless noise.\r
  95 \r
  96 The open question seems to be how we handle the content encoding\r
  97 parameters.  My argument is that those should either be used by notmuch\r
  98 to properly encode the content for the consumer.  If that's not\r
  99 possible, then just those parameters needed by the consumer to decode\r
 100 the content should be output.\r
 101 \r
 102 > > But isn't that actually a large part of the issue?  If this patch fixes\r
 103 > > something that you think notmuch is doing improperly, could there not be\r
 104 > > a test for it?\r
 105 >=20\r
 106 > No.  It just happens to be how I found the problem.  The issue is:\r
 107 > notmuch JSON format mangles Content-Type header value by throwing away\r
 108 > useful information in some cases and adding info that was not there in\r
 109 > others.  Note that I do not mention any single parameter name here.  It\r
 110 > is a general issue, not a "charset" or "boundary" parameter issue.\r
 111 \r
 112 I'm sorry, but I still don't believe it's not possible to test for this\r
 113 issue.  If there's a problem that you're seeing, then you must of\r
 114 identified it somehow, and therefore there must be a way to test for it.\r
 115 \r
 116 jamie.\r
 117 \r
 118 --=-=-=\r
 119 Content-Type: application/pgp-signature\r
 120 \r
 121 -----BEGIN PGP SIGNATURE-----\r
 122 Version: GnuPG v1.4.11 (GNU/Linux)\r
 123 \r
 124 iQIcBAEBCAAGBQJOyV7NAAoJEO00zqvie6q89j8QAIwLpC2PTwk4ceoYJ9e44uSf\r
 125 2yJupIVV3+wpWqMsg7q0mY7ofNg367jFyMwF4iyWrm+cq+14O9tiGYJ0l+HoG9uk\r
 126 rSps+BNWVKCjiAE+MROgAWzF7BIwdbmClWzE9tIP/Scj5gbDGdcwTQYCapXs3U56\r
 127 ENnZP90DBpAkwGyPS12JqWDVhM9jjaRg38XM4OLhgwWc547AYAMjqaE15fe9U3PV\r
 128 gufXtv65ECkqLlPrHwdXNzJYsLaitRZTukAIePYcXl9OFW9HPa39DoDP8azU4jLj\r
 129 7hzPB9Gs4nPRTf5SWGUK4r/5VAszh3awSHuyAs3WQL3eZyyhsJlQaCz5qI16vt+/\r
 130 U8oNqzAfbkaZh9SSg35IlKjdA6jJ/devpdwo3aEUTY37bsBzti+WxuFQpLpgF3NV\r
 131 ZtonJGBaIDYMU67tCqt0t8rhq0IQ/fHjuT4eh6zuHVT4nnGZcCfp9CTb+qgKLOq7\r
 132 Wpa+OMnlldifAN18bMuu2R4SHvCSIjboIQ4ZEUtVTZKknGjfShT76SPywowun1ek\r
 133 FcvOFxrZfXa5cc430sSrugf0NeHPfrXDUdoMB2AoxczNYpiir+ZD4kc71Ez6fgGO\r
 134 yg3pLUt3XHzE6+vXqcoCoUZUbZbPeddxntP+Mo3MnP/+tEuWKGSVbFK/s7AtUzxC\r
 135 28dyJXd23Xx2g9T0JZbx\r
 136 =+r3R\r
 137 -----END PGP SIGNATURE-----\r
 138 --=-=-=--\r