1 Return-Path: <dmitry.kurochkin@gmail.com>
\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 79B1B429E25
\r
6 for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:59 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
\r
13 FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id VeWkirRIWUf8 for <notmuch@notmuchmail.org>;
\r
17 Sun, 20 Nov 2011 10:52:58 -0800 (PST)
\r
18 Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com
\r
19 [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 7DE9F431FD0
\r
22 for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:58 -0800 (PST)
\r
23 Received: by bkaq10 with SMTP id q10so6313665bka.26
\r
24 for <notmuch@notmuchmail.org>; Sun, 20 Nov 2011 10:52:57 -0800 (PST)
\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
26 h=from:to:cc:subject:in-reply-to:references:user-agent:date
\r
27 :message-id:mime-version:content-type;
\r
28 bh=g4rL4fm1mreKKx/KWfKr57WlRgRl/K8tAS0HhEvA5Zc=;
\r
29 b=w9CbxcAR7ZgSL4sHKeXuNWNHKrAzCt0bhg1L2TnWvoldRZUFHyqEEx7jRfhOOsZ4z0
\r
30 +RsdwbmSbMeJby5fF2LA2Yg7n+6TPoCAy9m1HtvLpDZvAI7/V114LJLIG8dE70zq0QuR
\r
31 T3nOnv+A9kY8GGrci1BubgSFlYKZ8Fi4aU9WQ=
\r
32 Received: by 10.204.136.200 with SMTP id s8mr11189521bkt.49.1321815177106;
\r
33 Sun, 20 Nov 2011 10:52:57 -0800 (PST)
\r
34 Received: from localhost ([91.144.186.21])
\r
35 by mx.google.com with ESMTPS id f14sm5463910bkv.3.2011.11.20.10.52.55
\r
36 (version=TLSv1/SSLv3 cipher=OTHER);
\r
37 Sun, 20 Nov 2011 10:52:56 -0800 (PST)
\r
38 From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
\r
39 To: Austin Clements <amdragon@MIT.EDU>
\r
40 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON
\r
42 In-Reply-To: <20111119185818.GR9351@mit.edu>
\r
43 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
\r
44 <87fwhkyisj.fsf@servo.finestructure.net>
\r
45 <87wrawq1dz.fsf@gmail.com> <20111119045957.GQ9351@mit.edu>
\r
46 <87ty60pts9.fsf@gmail.com> <20111119185818.GR9351@mit.edu>
\r
47 User-Agent: Notmuch/0.10~rc1+20~gec94ced (http://notmuchmail.org) Emacs/23.3.1
\r
48 (x86_64-pc-linux-gnu)
\r
49 Date: Sun, 20 Nov 2011 22:52:39 +0400
\r
50 Message-ID: <87lirapqx4.fsf@gmail.com>
\r
52 Content-Type: text/plain; charset=us-ascii
\r
53 Cc: notmuch@notmuchmail.org
\r
54 X-BeenThere: notmuch@notmuchmail.org
\r
55 X-Mailman-Version: 2.1.13
\r
57 List-Id: "Use and development of the notmuch mail system."
\r
58 <notmuch.notmuchmail.org>
\r
59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
60 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
62 List-Post: <mailto:notmuch@notmuchmail.org>
\r
63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
65 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
66 X-List-Received-Date: Sun, 20 Nov 2011 18:52:59 -0000
\r
68 On Sat, 19 Nov 2011 13:58:18 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
\r
69 > Quoth Dmitry Kurochkin on Nov 19 at 9:26 am:
\r
70 > > On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
\r
71 > > > Quoth Dmitry Kurochkin on Nov 19 at 6:42 am:
\r
74 > > > > On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
\r
75 > > > > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
\r
76 > > > > > > Before the change, notmuch used g_mime_content_type_to_string(3)
\r
77 > > > > > > function to output Content-Type header value. Turns out it outputs
\r
78 > > > > > > only "type/subtype" part and ignores all parameters. Also, if there
\r
79 > > > > > > is no Content-Type header, default "text/plain" value is used.
\r
81 > > > > > Hi, Dmitry. Can you explain under what circumstances you would need the
\r
82 > > > > > extra content-type parameters?
\r
84 > > > > Charset is an example of a parameter which you need to render a part
\r
87 > > > Can notmuch convert to a common charset, given that, otherwise, every
\r
88 > > > client is going to have to implement this conversion anyway?
\r
91 > > Notmuch can handle charset (and any other) parameters but only for known
\r
92 > > media types (i.e. text/*). I think it would be useful (especially for
\r
93 > > human-readable output formats). But it is a separate issue.
\r
95 > > Notmuch can not convert other types it does not know how to handle.
\r
96 > > E.g. HTML charset conversion is not as simple as for plain text.
\r
98 > > AFAIK standard defines charset parameter just for few types. So in
\r
99 > > general, charset parameter can have any meaning for some custom media
\r
102 > Interesting. I hadn't realized the content-type specification was so
\r
103 > open-ended. However, there are many things that *could* be included
\r
104 > in the JSON format but aren't; what's included is primarily driven by
\r
105 > what consumers actually need and it seems like the actual need here is
\r
106 > charset handling. Maybe the JSON format *shouldn't* evolve this way,
\r
107 > but I think it should either be driven by its needs like it is now, or
\r
108 > we should be taking bigger steps like providing *all* of the headers
\r
109 > (essentially, a JSON-ification of the MIME structure), which would
\r
110 > subsume more specific generalizations like exposing just the full
\r
111 > content-type header.
\r
114 I think it is a good idea to provide all headers in JSON output. Still
\r
115 I believe this patch is still valid. It is a simple change, which makes
\r
116 the JSON format simpler and we have consumers that need it. Providing
\r
117 all headers would be a bigger change (and I expect it to be much more
\r
118 difficult to get accepted).
\r
120 What I definately do not like, is adding an exception for charset
\r
121 parameter and inventing complex rules for JSON format instead of keeping
\r
124 > Regarding charset, specifically, though, the JSON format only includes
\r
125 > part bodies for text/* types and, according to RFC 2045,
\r
127 > For example, the "charset" parameter is applicable to any subtype of
\r
130 > Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush,
\r
131 > but I think it's saying essentially the same thing in a lot more
\r
132 > detail. Given that, I think it does make sense for notmuch to handle
\r
133 > the charset parameter and re-coding.
\r
136 I think it may be a good idea but it is not trivial to do right. We
\r
137 should not just convert all text parts unconditionally to locale or
\r
140 > > > (And are there other examples of useful things in the content type?)
\r
142 > > What is meant by useful? All parameters do have some use. The fact
\r
143 > > that notmuch does not handle them does not mean they are useless. And
\r
144 > > notmuch can not handle all parameters just because the list of
\r
145 > > parameters is not defined. So there is no choice but to let notmuch
\r
146 > > users see and use these parameters.
\r
148 > Yes, I now agree with this, modulo my statements about generality above.
\r
161 > Austin Clements MIT/'06/PhD/CSAIL
\r
162 > amdragon@mit.edu http://web.mit.edu/amdragon
\r
163 > Somewhere in the dream we call reality you will find me,
\r
164 > searching for the reality we call dreams.
\r
projects / notmuch-archives.git / blob