Re: [PATCH] Output unmodified Content-Type header value for JSON format.

diff --git a/4a/2d616e54ca4b941cdee29833b7619f00a6d2b7 b/4a/2d616e54ca4b941cdee29833b7619f00a6d2b7
new file mode 100644 (file)
index 0000000..fc8abfa
--- /dev/null
+++ b/4a/2d616e54ca4b941cdee29833b7619f00a6d2b7
@@ -0,0 +1,88 @@
+Return-Path: <pieter@praet.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id DD3E6429E29\r
+       for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:12 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id MwMqP0RCSw+o for <notmuch@notmuchmail.org>;\r
+       Thu, 12 Jan 2012 09:09:12 -0800 (PST)\r
+Received: from mail-we0-f181.google.com (mail-we0-f181.google.com\r
+       [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 4CD4E429E26\r
+       for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:12 -0800 (PST)\r
+Received: by werm12 with SMTP id m12so1793052wer.26\r
+       for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:11 -0800 (PST)\r
+Received: by 10.216.136.94 with SMTP id v72mr1924105wei.43.1326388151110;\r
+       Thu, 12 Jan 2012 09:09:11 -0800 (PST)\r
+Received: from localhost ([109.131.126.209])\r
+       by mx.google.com with ESMTPS id ga4sm6470978wbb.4.2012.01.12.09.09.09\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Thu, 12 Jan 2012 09:09:10 -0800 (PST)\r
+From: Pieter Praet <pieter@praet.org>\r
+To: Austin Clements <amdragon@MIT.EDU>,\r
+       Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
+       format.\r
+In-Reply-To: <20111123034021.GL9351@mit.edu>\r
+References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
+       <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
+       <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
+       <87ipmewo4z.fsf@servo.finestructure.net>\r
+       <20111123034021.GL9351@mit.edu>\r
+User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+Date: Thu, 12 Jan 2012 18:07:31 +0100\r
+Message-ID: <87ipkglui4.fsf@praet.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 12 Jan 2012 17:09:13 -0000\r
+\r
+On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:\r
+> > The open question seems to be how we handle the content encoding\r
+> > parameters.  My argument is that those should either be used by notmuch\r
+> > to properly encode the content for the consumer.  If that's not\r
+> > possible, then just those parameters needed by the consumer to decode\r
+> > the content should be output.\r
+> \r
+> If notmuch is going to include part content in the JSON output (which\r
+> perhaps it shouldn't, as per recent IRC discussions), then it must\r
+> handle content encodings because JSON must be Unicode and therefore\r
+> the content strings in the JSON must be Unicode.\r
+\r
+Having missed the IRC discussions: what is the rationale for not\r
+including (specific types of?) part content in the JSON output ?\r
+Eg. how about inline attached text/x-patch ?\r
+\r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
+\r
+\r
+Peace\r
+\r
+-- \r
+Pieter\r