da/e2b3b5dd96d8b07814d1d7dd69d0e830216b1a

   1 Return-Path: <tomi.ollila@nixu.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 BB4B6429E4E\r
   6         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:18:36 -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\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         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 BlzCo79UXJyW for <notmuch@notmuchmail.org>;\r
  16         Mon, 16 Jan 2012 05:18:36 -0800 (PST)\r
  17 Received: from mail-gw3.nixu.fi (mail-gw3.nixu.fi [193.209.237.7])\r
  18         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id CD2D2429E4A\r
  21         for <notmuch@notmuchmail.org>; Mon, 16 Jan 2012 05:18:35 -0800 (PST)\r
  22 Received: from pps.filterd (mail-gw3 [127.0.0.1])\r
  23         by mail-gw3.nixu.fi (8.14.4/8.14.4) with SMTP id q0GDHrvV018941;\r
  24         Mon, 16 Jan 2012 15:18:31 +0200\r
  25 Received: from taco2.nixu.fi (taco2.nixu.fi [194.197.118.31])\r
  26         by mail-gw3.nixu.fi with ESMTP id 114cs15q3r-1\r
  27         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  28         Mon, 16 Jan 2012 15:18:30 +0200\r
  29 Received: from taco2.nixu.fi (taco2.nixu.fi [194.197.118.31])\r
  30         by taco2.nixu.fi (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id\r
  31         q0GDIUo8003383; Mon, 16 Jan 2012 15:18:30 +0200\r
  32 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  33 To: David Edmondson <dme@dme.org>, Austin Clements <amdragon@MIT.EDU>,\r
  34         Pieter Praet <pieter@praet.org>\r
  35 Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON\r
  36         format.\r
  37 In-Reply-To: <cunlip858xs.fsf@hotblack-desiato.hh.sledj.net>\r
  38 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  39         <87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>\r
  40         <87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>\r
  41         <87ipmewo4z.fsf@servo.finestructure.net>\r
  42         <20111123034021.GL9351@mit.edu> <87ipkglui4.fsf@praet.org>\r
  43         <20120112172840.GC18625@mit.edu> <87ehv2proa.fsf@praet.org>\r
  44         <cun1ur16v3r.fsf@hotblack-desiato.hh.sledj.net>\r
  45         <87boq4q23z.fsf@awakening.csail.mit.edu>\r
  46         <cunlip858xs.fsf@hotblack-desiato.hh.sledj.net>\r
  47 User-Agent: Notmuch/0.11+64~g42e8f66 (http://notmuchmail.org) Emacs/23.3.1\r
  48         (i686-pc-linux-gnu)\r
  49 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  50         $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  51         !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  52 Date: Mon, 16 Jan 2012 15:18:30 +0200\r
  53 Message-ID: <yf6vcobwztl.fsf@taco2.nixu.fi>\r
  54 MIME-Version: 1.0\r
  55 Content-Type: text/plain; charset=us-ascii\r
  56 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,\r
  57  1.0.211,       0.0.0000        definitions=2012-01-16_01:2012-01-16, 2012-01-16,\r
  58         1970-01-01 signatures=0\r
  59 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0\r
  60         ipscore=0 suspectscore=0\r
  61         phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0\r
  62         reason=mlx\r
  63         scancount=1 engine=6.0.2-1012030000 definitions=main-1201160097\r
  64 Cc: notmuch@notmuchmail.org\r
  65 X-BeenThere: notmuch@notmuchmail.org\r
  66 X-Mailman-Version: 2.1.13\r
  67 Precedence: list\r
  68 List-Id: "Use and development of the notmuch mail system."\r
  69         <notmuch.notmuchmail.org>\r
  70 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  72 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  73 List-Post: <mailto:notmuch@notmuchmail.org>\r
  74 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  75 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  77 X-List-Received-Date: Mon, 16 Jan 2012 13:18:36 -0000\r
  78 \r
  79 On Mon, 16 Jan 2012 08:49:03 +0000, David Edmondson <dme@dme.org> wrote:\r
  80 > On Sun, 15 Jan 2012 12:58:40 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
  81 > \r
  82 > This, I suspect, brings us back to what may have been Dmitry's original\r
  83 > concern. If we codify the current behaviour then we're actually\r
  84 > _forcing_ clients to use inline content if it's present, because\r
  85 > otherwise they have no way to discover the charset/encoding used for the\r
  86 > raw part.\r
  87 > \r
  88 > That seems as though it could be a problem for some clients.\r
  89 > \r
  90 > > OTOH, I don't understand the encoding story for HTML, since the encoding\r
  91 > > can come from either a header or from the body of the HTML.  Does this\r
  92 > > make it strictly necessary for the client to handle the encoding?\r
  93 \r
  94 Either from a header or from the body of the *HTTP*. Html meta tag is part\r
  95 of the header of the HTML document, body of the HTTP message.\r
  96 \r
  97 > If it can be specified by the content of a part rather than the part\r
  98 > headers, then I think that the client will have to be prepared to handle\r
  99 > it.\r
 100 > \r
 101 > Even if not, it might still be more effective to choose that approach -\r
 102 > it would remove the need to add arbitrary encoding support to the CLI\r
 103 > application.\r
 104 \r
 105 In case of w3m interface if charset is not told it defaults\r
 106 to iso-8859-1 as both input and output encoding.\r
 107 \r
 108 That is no problem in w3m -- it just doesn't do any conversion.\r
 109 \r
 110 But emacs thinks that it gets input in iso-8859-1 format and will\r
 111 attempt to convert that to whatever charset the window user has\r
 112 is using. \r
 113 \r
 114 If input was utf8 but emacs thinks input was latin1 then we get\r
 115 this infamous 'double-utf8'ied output (a subset of wtf-8 charset ;)\r
 116 (in case window charset is utf8)\r
 117 \r
 118 In case of w3m the content feed to w3m could be pre-encoded to utf-8\r
 119 and w3m interface is told that charset is utf-8 -- w3m will now\r
 120 called using utf-8 as input and output encoding -- and at the end\r
 121 emacs does conversion from utf-8 to the window encoding (if needed).\r
 122 \r
 123 As mentioned in IRC: 2012-01-10 11:46 (UTC)  xxxXX  indeed, the headers\r
 124         should take precedence to meta tag, as defined in HTML4\r
 125 \r
 126 So, complying clients takes the precedence from command line options\r
 127 (which, in case of command line clients makes perfect sense).\r
 128 \r
 129 Tomi\r