--- /dev/null
+Return-Path: <dmitry.kurochkin@gmail.com>\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 79B1B429E25\r
+ for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:59 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.799\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ FREEMAIL_FROM=0.001, 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 VeWkirRIWUf8 for <notmuch@notmuchmail.org>;\r
+ Sun, 20 Nov 2011 10:52:58 -0800 (PST)\r
+Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
+ [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 7DE9F431FD0\r
+ for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:58 -0800 (PST)\r
+Received: by bkaq10 with SMTP id q10so6313665bka.26\r
+ for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:57 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+ h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
+ :message-id:mime-version:content-type;\r
+ bh=g4rL4fm1mreKKx/KWfKr57WlRgRl/K8tAS0HhEvA5Zc=;\r
+ b=w9CbxcAR7ZgSL4sHKeXuNWNHKrAzCt0bhg1L2TnWvoldRZUFHyqEEx7jRfhOOsZ4z0\r
+ +RsdwbmSbMeJby5fF2LA2Yg7n+6TPoCAy9m1HtvLpDZvAI7/V114LJLIG8dE70zq0QuR\r
+ T3nOnv+A9kY8GGrci1BubgSFlYKZ8Fi4aU9WQ=\r
+Received: by 10.204.136.200 with SMTP id s8mr11189521bkt.49.1321815177106;\r
+ Sun, 20 Nov 2011 10:52:57 -0800 (PST)\r
+Received: from localhost ([91.144.186.21])\r
+ by mx.google.com with ESMTPS id f14sm5463910bkv.3.2011.11.20.10.52.55\r
+ (version=TLSv1/SSLv3 cipher=OTHER);\r
+ Sun, 20 Nov 2011 10:52:56 -0800 (PST)\r
+From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
+ format.\r
+In-Reply-To: <20111119185818.GR9351@mit.edu>\r
+References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
+ <87fwhkyisj.fsf@servo.finestructure.net>\r
+ <87wrawq1dz.fsf@gmail.com> <20111119045957.GQ9351@mit.edu>\r
+ <87ty60pts9.fsf@gmail.com> <20111119185818.GR9351@mit.edu>\r
+User-Agent: Notmuch/0.10~rc1+20~gec94ced (http://notmuchmail.org) Emacs/23.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sun, 20 Nov 2011 22:52:39 +0400\r
+Message-ID: <87lirapqx4.fsf@gmail.com>\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: Sun, 20 Nov 2011 18:52:59 -0000\r
+\r
+On Sat, 19 Nov 2011 13:58:18 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> Quoth Dmitry Kurochkin on Nov 19 at 9:26 am:\r
+> > On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> > > Quoth Dmitry Kurochkin on Nov 19 at 6:42 am:\r
+> > > > Hi Jamie.\r
+> > > > \r
+> > > > On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
+> > > > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
+> > > > > > Before the change, notmuch used g_mime_content_type_to_string(3)\r
+> > > > > > function to output Content-Type header value. Turns out it outputs\r
+> > > > > > only "type/subtype" part and ignores all parameters. Also, if there\r
+> > > > > > is no Content-Type header, default "text/plain" value is used.\r
+> > > > > \r
+> > > > > Hi, Dmitry. Can you explain under what circumstances you would need the\r
+> > > > > extra content-type parameters?\r
+> > > > \r
+> > > > Charset is an example of a parameter which you need to render a part\r
+> > > > correctly.\r
+> > > \r
+> > > Can notmuch convert to a common charset, given that, otherwise, every\r
+> > > client is going to have to implement this conversion anyway?\r
+> > > \r
+> > \r
+> > Notmuch can handle charset (and any other) parameters but only for known\r
+> > media types (i.e. text/*). I think it would be useful (especially for\r
+> > human-readable output formats). But it is a separate issue.\r
+> > \r
+> > Notmuch can not convert other types it does not know how to handle.\r
+> > E.g. HTML charset conversion is not as simple as for plain text.\r
+> > \r
+> > AFAIK standard defines charset parameter just for few types. So in\r
+> > general, charset parameter can have any meaning for some custom media\r
+> > type.\r
+> \r
+> Interesting. I hadn't realized the content-type specification was so\r
+> open-ended. However, there are many things that *could* be included\r
+> in the JSON format but aren't; what's included is primarily driven by\r
+> what consumers actually need and it seems like the actual need here is\r
+> charset handling. Maybe the JSON format *shouldn't* evolve this way,\r
+> but I think it should either be driven by its needs like it is now, or\r
+> we should be taking bigger steps like providing *all* of the headers\r
+> (essentially, a JSON-ification of the MIME structure), which would\r
+> subsume more specific generalizations like exposing just the full\r
+> content-type header.\r
+> \r
+\r
+I think it is a good idea to provide all headers in JSON output. Still\r
+I believe this patch is still valid. It is a simple change, which makes\r
+the JSON format simpler and we have consumers that need it. Providing\r
+all headers would be a bigger change (and I expect it to be much more\r
+difficult to get accepted).\r
+\r
+What I definately do not like, is adding an exception for charset\r
+parameter and inventing complex rules for JSON format instead of keeping\r
+it simple.\r
+\r
+> Regarding charset, specifically, though, the JSON format only includes\r
+> part bodies for text/* types and, according to RFC 2045,\r
+> \r
+> For example, the "charset" parameter is applicable to any subtype of\r
+> "text", ...\r
+> \r
+> Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush,\r
+> but I think it's saying essentially the same thing in a lot more\r
+> detail. Given that, I think it does make sense for notmuch to handle\r
+> the charset parameter and re-coding.\r
+> \r
+\r
+I think it may be a good idea but it is not trivial to do right. We\r
+should not just convert all text parts unconditionally to locale or\r
+UTF-8.\r
+\r
+> > > (And are there other examples of useful things in the content type?)\r
+> > \r
+> > What is meant by useful? All parameters do have some use. The fact\r
+> > that notmuch does not handle them does not mean they are useless. And\r
+> > notmuch can not handle all parameters just because the list of\r
+> > parameters is not defined. So there is no choice but to let notmuch\r
+> > users see and use these parameters.\r
+> \r
+> Yes, I now agree with this, modulo my statements about generality above.\r
+> \r
+\r
+Thanks.\r
+\r
+Regards,\r
+ Dmitry\r
+\r
+> > Regards,\r
+> > Dmitry\r
+> > \r
+> \r
+> -- \r
+> Austin Clements MIT/'06/PhD/CSAIL\r
+> amdragon@mit.edu http://web.mit.edu/amdragon\r
+> Somewhere in the dream we call reality you will find me,\r
+> searching for the reality we call dreams.\r
projects / notmuch-archives.git / commitdiff