46/22ca14e4860c4571ab2998b53184ec6d144c2f

   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 D7E9D429E25\r
   6         for <notmuch@notmuchmail.org>; Sat, 19 Nov 2011 02:49:53 -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 Qrlres4jXNGf for <notmuch@notmuchmail.org>;\r
  16         Sat, 19 Nov 2011 02:49:53 -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 F3200431FD0\r
  20         for <notmuch@notmuchmail.org>; Sat, 19 Nov 2011 02:49:52 -0800 (PST)\r
  21 Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
  22         by fire-doxen-postvirus (Postfix) with ESMTP id 80B05328023;\r
  23         Sat, 19 Nov 2011 02:49:50 -0800 (PST)\r
  24 X-Spam-Scanned: at Caltech-IMSS on fire-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 fire-doxen-submit (Postfix) with ESMTP id 95C432E50BD3;\r
  28         Sat, 19 Nov 2011 02:49:47 -0800 (PST)\r
  29 Received: by finestructure.net (Postfix, from userid 1000)\r
  30         id 1669EACC; Sat, 19 Nov 2011 02:49:47 -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: <87wrawq1dz.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 User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1\r
  39         (x86_64-pc-linux-gnu)\r
  40 Date: Sat, 19 Nov 2011 02:49:43 -0800\r
  41 Message-ID: <87d3coxu7s.fsf@servo.finestructure.net>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: multipart/signed; boundary="=-=-=";\r
  44         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 List-Id: "Use and development of the notmuch mail system."\r
  49         <notmuch.notmuchmail.org>\r
  50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  53 List-Post: <mailto:notmuch@notmuchmail.org>\r
  54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  57 X-List-Received-Date: Sat, 19 Nov 2011 10:49:54 -0000\r
  58 \r
  59 --=-=-=\r
  60 Content-Transfer-Encoding: quoted-printable\r
  61 \r
  62 On Sat, 19 Nov 2011 06:42:00 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmai=\r
  63 l.com> wrote:\r
  64 > The parameters are there for a reason.  They are part of the\r
  65 > content-type and are needed to handle the body properly.  If you say\r
  66 > that the parameters are not needed by notmuch users, that implies that\r
  67 > they are handled by notmuch.  Which is just not possible.\r
  68 \r
  69 Hey, Dimitry.  At least some of the parameters in the content-type are\r
  70 actually related to the mime structure itself.  A good example is:\r
  71 \r
  72 boundary=3D\"=3D-=3D-=3D\"\r
  73 \r
  74 This parameter is there to tell the MIME parser how to parse the content\r
  75 that follows.  It is meant for the first level parser and no more.  Once\r
  76 the MIME has been separated into it's constituent parts, there's no need\r
  77 for any further clients to know anything about boundary string.\r
  78 \r
  79 I would argue that notmuch is acting as the first level parser.  As far\r
  80 as I can tell, most of the rest of the parameters I've seen should only\r
  81 be useful to the those first-level parsers.\r
  82 \r
  83 As Austin mentioned, is it not possible for notmuch itself to act on the\r
  84 parameter to give a properly formatted output to its clients?\r
  85 \r
  86 > The fact that this change happens to fix an issue with HTML charsets for\r
  87 > me is just a side effect.\r
  88 \r
  89 But isn't that actually a large part of the issue?  If this patch fixes\r
  90 something that you think notmuch is doing improperly, could there not be\r
  91 a test for it?\r
  92 \r
  93 However, based on your patches and as far as I can tell, this change\r
  94 adds more than a boundary parameter to only crypto parts\r
  95 (application/signed and application/encrypted).  However, I don't think\r
  96 any of the crypto functionality needs any of the extra information\r
  97 provided in the extended output.  If there was a test for the\r
  98 functionality you think is missing, it would help bolster the case for\r
  99 the additional output.\r
 100 \r
 101 > > >   "content": [{"id": 2,\r
 102 > > > - "content-type": "text/plain",\r
 103 > > >   "content": "This is a test signed message.\n"},\r
 104 > >=20\r
 105 > > Without figuring out what's going on, I notice that some of the tests\r
 106 > > have been modified to remove the content-type fields on a bunch of\r
 107 > > parts.  I think that is probably not right.\r
 108 > >=20\r
 109 >=20\r
 110 > I tried to explain this in the preable.  These parts do not have\r
 111 > Content-Type in the original message.  So I think it is wrong for\r
 112 > notmuch JSON format to add it.\r
 113 \r
 114 Ah, ok, I think I understand this point.  I think this is actually a\r
 115 separate issue than the one the rest of the patch set is for, though.\r
 116 One part of the patch is that content-type parameters are also about,\r
 117 and another part is that parts without content-type shouldn't be\r
 118 assigned one automatically.  I personally think those should be separate\r
 119 patches.\r
 120 \r
 121 jamie.\r
 122 \r
 123 --=-=-=\r
 124 Content-Type: application/pgp-signature\r
 125 \r
 126 -----BEGIN PGP SIGNATURE-----\r
 127 Version: GnuPG v1.4.11 (GNU/Linux)\r
 128 \r
 129 iQIcBAEBCAAGBQJOx4nHAAoJEO00zqvie6q827gP/RiinHLKC4FO445/yq3eMgyC\r
 130 3v/JN14rjgw5NZ+EnG2VxRDT5LaYV8yiBKIRJH09O3Ewo1pomVu3E6V6lVOS7FnD\r
 131 EjUODYl3Ss6uGbHkH2a6ww2NowGBNOWT1/bBktQTeakAbLqDy6k/dJciXIeajmUS\r
 132 JJolaOonTKlzqJi6LcqX6k9L1A2jEbWyp2uqC9nnaq4tokvhxohiep8Ju/mu+ixj\r
 133 y79IS/sUxY7u3/h1mJNCEPuZ8gBss3fZOaycJ2x9Cwt3DAcuovVBXva2KAgKNzw0\r
 134 KbTA/NGhAlCoGeK8ceYLhb0cRcsTC0wbroWCr4L/mjOVuBZvjZ6Zlu7cSrwDfZY0\r
 135 pKnoOlLgQdk6r93CXBwu3i4LEi7J4xW60K1qZUsPa6heK7r1Fimg3iibn3RITLCl\r
 136 FDUQrldjVOViNMmsVudKu/z2PSvXq6gPlWqyuaQ6YV4B5JdnvAmkEsZIqOqjG2fF\r
 137 N4PJT1yr6NJcBV6D2vkWfF3IKMHokk+u2ERGPZwqhFV/5XKEiNvvUqswavCG+LY/\r
 138 qzIUTX+xjNEMYY4adqPcym9ETSwJvxiv137vV4vUVhpLUliDsW6LNh7DHbcaekRq\r
 139 BZikGxsma1WnGwfFCenuqyqG/G085Tfv1bgF/rVQfLQpTktAPG4LVorCsBKZDygh\r
 140 JWzM8d3AdOpaoQntsXcq\r
 141 =RdDy\r
 142 -----END PGP SIGNATURE-----\r
 143 --=-=-=--\r