From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id A4A5D429E26 for ; Sat, 19 Nov 2011 10:55:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAbuzJRy3eys for ; Sat, 19 Nov 2011 10:55:51 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by olra.theworths.org (Postfix) with ESMTP id 79F35429E21 for ; Sat, 19 Nov 2011 10:55:51 -0800 (PST) X-AuditID: 12074423-b7f266d0000008b8-ee-4ec7fbb61b95 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.A8.02232.6BBF7CE4; Sat, 19 Nov 2011 13:55:50 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAJItni5016446; Sat, 19 Nov 2011 13:55:50 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAJItlbZ010619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 19 Nov 2011 13:55:48 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RRq7G-0008T9-E1; Sat, 19 Nov 2011 13:58:18 -0500 Date: Sat, 19 Nov 2011 13:58:18 -0500 From: Austin Clements To: Dmitry Kurochkin Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON format. Message-ID: <20111119185818.GR9351@mit.edu> References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com> <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com> <20111119045957.GQ9351@mit.edu> <87ty60pts9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ty60pts9.fsf@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IRYrdT0d32+7ifQd99bourW/vZLfbs87K4 fnMmswOzx93TXB47Z91l93i26hZzAHMUl01Kak5mWWqRvl0CV8bF65oFh6Urtu6cyNzAuE60 i5GTQ0LARGLSpC/sELaYxIV769m6GLk4hAT2MUrMOfUFytnAKHHhyg12COckk8Sn9/OgnCWM Ekt3XWTpYuTgYBFQlehbKgMyik1AQ2Lb/uWMILaIgKHErYuvmEFsZoEIiSkzPjKB2MICwRIv l7WD2bwC2hJLm1qhtl1klDhw+i0jREJQ4uTMJywQzVoSN/69ZALZxSwgLbH8HwdImFNAXWLV 8XVgJaICKhJTTm5jm8AoNAtJ9ywk3bMQuhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPL zSzRS00p3cQIDnMX5R2Mfw4qHWIU4GBU4uEtnHHMT4g1say4MvcQoyQHk5Io74qfx/2E+JLy UyozEosz4otKc1KLDzFKcDArifBeWAeU401JrKxKLcqHSUlzsCiJ88rsdPATEkhPLEnNTk0t SC2CycpwcChJ8D77BtQoWJSanlqRlplTgpBm4uAEGc4DNNz1N8jw4oLE3OLMdIj8KUZFKXFe HZCEAEgiozQPrheWhl4xigO9Isx7GWQFDzCFwXW/AhrMBDQ4d88RkMEliQgpqQbGiWpvNnjx c932fH0/6WwLg072m14uS8bodw8cdA+avPJzfJf9TuAqg8qhyXvO/+vtnLFAuUtQxffa/cB1 3t5Wb0S5e7KuLL8kLFv+RmaTrk3jDkUDyc0Hgi/MLlLoijRjnbPWUeiVy5pqb1W5H9frTDP6 Pz7fGbtxihr3Odtbj07XHDnIU79NiaU4I9FQi7moOBEAiubs+h4DAAA= Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 18:55:52 -0000 Quoth Dmitry Kurochkin on Nov 19 at 9:26 am: > On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements wrote: > > Quoth Dmitry Kurochkin on Nov 19 at 6:42 am: > > > Hi Jamie. > > > > > > On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins wrote: > > > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin wrote: > > > > > Before the change, notmuch used g_mime_content_type_to_string(3) > > > > > function to output Content-Type header value. Turns out it outputs > > > > > only "type/subtype" part and ignores all parameters. Also, if there > > > > > is no Content-Type header, default "text/plain" value is used. > > > > > > > > Hi, Dmitry. Can you explain under what circumstances you would need the > > > > extra content-type parameters? > > > > > > Charset is an example of a parameter which you need to render a part > > > correctly. > > > > Can notmuch convert to a common charset, given that, otherwise, every > > client is going to have to implement this conversion anyway? > > > > Notmuch can handle charset (and any other) parameters but only for known > media types (i.e. text/*). I think it would be useful (especially for > human-readable output formats). But it is a separate issue. > > Notmuch can not convert other types it does not know how to handle. > E.g. HTML charset conversion is not as simple as for plain text. > > AFAIK standard defines charset parameter just for few types. So in > general, charset parameter can have any meaning for some custom media > type. Interesting. I hadn't realized the content-type specification was so open-ended. However, there are many things that *could* be included in the JSON format but aren't; what's included is primarily driven by what consumers actually need and it seems like the actual need here is charset handling. Maybe the JSON format *shouldn't* evolve this way, but I think it should either be driven by its needs like it is now, or we should be taking bigger steps like providing *all* of the headers (essentially, a JSON-ification of the MIME structure), which would subsume more specific generalizations like exposing just the full content-type header. Regarding charset, specifically, though, the JSON format only includes part bodies for text/* types and, according to RFC 2045, For example, the "charset" parameter is applicable to any subtype of "text", ... Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush, but I think it's saying essentially the same thing in a lot more detail. Given that, I think it does make sense for notmuch to handle the charset parameter and re-coding. > > (And are there other examples of useful things in the content type?) > > What is meant by useful? All parameters do have some use. The fact > that notmuch does not handle them does not mean they are useless. And > notmuch can not handle all parameters just because the list of > parameters is not defined. So there is no choice but to let notmuch > users see and use these parameters. Yes, I now agree with this, modulo my statements about generality above. > Regards, > Dmitry > -- Austin Clements MIT/'06/PhD/CSAIL amdragon@mit.edu http://web.mit.edu/amdragon Somewhere in the dream we call reality you will find me, searching for the reality we call dreams.