4a/2d616e54ca4b941cdee29833b7619f00a6d2b7

   1 Return-Path: <pieter@praet.org>\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 DD3E6429E29\r
   6         for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09: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: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 MwMqP0RCSw+o for <notmuch@notmuchmail.org>;\r
  16         Thu, 12 Jan 2012 09:09:12 -0800 (PST)\r
  17 Received: from mail-we0-f181.google.com (mail-we0-f181.google.com\r
  18         [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 4CD4E429E26\r
  21         for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:12 -0800 (PST)\r
  22 Received: by werm12 with SMTP id m12so1793052wer.26\r
  23         for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:11 -0800 (PST)\r
  24 Received: by 10.216.136.94 with SMTP id v72mr1924105wei.43.1326388151110;\r
  25         Thu, 12 Jan 2012 09:09:11 -0800 (PST)\r
  26 Received: from localhost ([109.131.126.209])\r
  27         by mx.google.com with ESMTPS id ga4sm6470978wbb.4.2012.01.12.09.09.09\r
  28         (version=TLSv1/SSLv3 cipher=OTHER);\r
  29         Thu, 12 Jan 2012 09:09:10 -0800 (PST)\r
  30 From: Pieter Praet <pieter@praet.org>\r
  31 To: Austin Clements <amdragon@MIT.EDU>,\r
  32         Jameson Graef Rollins <jrollins@finestructure.net>\r
  33 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
  34         format.\r
  35 In-Reply-To: <20111123034021.GL9351@mit.edu>\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         <87ipmewo4z.fsf@servo.finestructure.net>\r
  40         <20111123034021.GL9351@mit.edu>\r
  41 User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1\r
  42         (x86_64-unknown-linux-gnu)\r
  43 Date: Thu, 12 Jan 2012 18:07:31 +0100\r
  44 Message-ID: <87ipkglui4.fsf@praet.org>\r
  45 MIME-Version: 1.0\r
  46 Content-Type: text/plain; charset=us-ascii\r
  47 Cc: notmuch@notmuchmail.org\r
  48 X-BeenThere: notmuch@notmuchmail.org\r
  49 X-Mailman-Version: 2.1.13\r
  50 Precedence: list\r
  51 List-Id: "Use and development of the notmuch mail system."\r
  52         <notmuch.notmuchmail.org>\r
  53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  56 List-Post: <mailto:notmuch@notmuchmail.org>\r
  57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  60 X-List-Received-Date: Thu, 12 Jan 2012 17:09:13 -0000\r
  61 \r
  62 On Tue, 22 Nov 2011 22:40:21 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  63 > Quoth Jameson Graef Rollins on Nov 20 at 12:10 pm:\r
  64 > > The open question seems to be how we handle the content encoding\r
  65 > > parameters.  My argument is that those should either be used by notmuch\r
  66 > > to properly encode the content for the consumer.  If that's not\r
  67 > > possible, then just those parameters needed by the consumer to decode\r
  68 > > the content should be output.\r
  69 > \r
  70 > If notmuch is going to include part content in the JSON output (which\r
  71 > perhaps it shouldn't, as per recent IRC discussions), then it must\r
  72 > handle content encodings because JSON must be Unicode and therefore\r
  73 > the content strings in the JSON must be Unicode.\r
  74 \r
  75 Having missed the IRC discussions: what is the rationale for not\r
  76 including (specific types of?) part content in the JSON output ?\r
  77 Eg. how about inline attached text/x-patch ?\r
  78 \r
  79 > _______________________________________________\r
  80 > notmuch mailing list\r
  81 > notmuch@notmuchmail.org\r
  82 > http://notmuchmail.org/mailman/listinfo/notmuch\r
  83 \r
  84 \r
  85 Peace\r
  86 \r
  87 -- \r
  88 Pieter\r