00/be70ec0182189fa700ac97c4282a6f8217ad89

   1 Return-Path: <m.walters@qmul.ac.uk>\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 20585431FBD\r
   6         for <notmuch@notmuchmail.org>; Sun,  9 Feb 2014 02:10:25 -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: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] 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 g3d0B3jIDnUN for <notmuch@notmuchmail.org>;\r
  17         Sun,  9 Feb 2014 02:10:17 -0800 (PST)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 0C894431FBC\r
  22         for <notmuch@notmuchmail.org>; Sun,  9 Feb 2014 02:10:17 -0800 (PST)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1WCRKz-0001ZW-JG; Sun, 09 Feb 2014 10:10:10 +0000\r
  27 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
  28         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
  29         (envelope-from <m.walters@qmul.ac.uk>)\r
  30         id 1WCRKz-0006sv-6w; Sun, 09 Feb 2014 10:10:09 +0000\r
  31 From: Mark Walters <markwalters1009@gmail.com>\r
  32 To: "W. Trevor King" <wking@tremily.us>, David Bremner <david@tethera.net>\r
  33 Subject: Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for\r
  34         part buttons\r
  35 In-Reply-To: <20140208165931.GB17142@odin.tremily.us>\r
  36 References: <877g9chbay.fsf@qmul.ac.uk>\r
  37  <cover.1391423201.git.wking@tremily.us>\r
  38         <27be295875a7df782a83c9a2c09d06f9d321fe9e.1391423201.git.wking@tremily.us>\r
  39         <87vbwwosuw.fsf@qmul.ac.uk>     <20140203203418.GO14197@odin.tremily.us>\r
  40         <20140204013246.GQ19935@odin.tremily.us>        <87r47dojbt.fsf@zancas.localnet>\r
  41         <20140208165931.GB17142@odin.tremily.us>\r
  42 User-Agent: Notmuch/0.15.2+484~gfb59956 (http://notmuchmail.org) Emacs/23.4.1\r
  43         (x86_64-pc-linux-gnu)\r
  44 Date: Sun, 09 Feb 2014 10:10:08 +0000\r
  45 Message-ID: <878utkd2bj.fsf@qmul.ac.uk>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=utf-8\r
  48 Content-Transfer-Encoding: quoted-printable\r
  49 X-Sender-Host-Address: 93.97.24.31\r
  50 X-QM-Geographic: According to ripencc,\r
  51         this message was delivered by a machine in Britain (UK) (GB).\r
  52 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  53 X-QM-Body-MD5: 8a1577782296a5f47bc4a84eb2b8c988 (of first 20000 bytes)\r
  54 X-SpamAssassin-Score: 0.0\r
  55 X-SpamAssassin-SpamBar: /\r
  56 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  57         determine if it is\r
  58         spam. We require at least 5.0 points to mark a message as spam.\r
  59         This message scored 0.0 points. Summary of the scoring: \r
  60         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  61         provider *      (markwalters1009[at]gmail.com)\r
  62         *  0.0 AWL AWL: From: address is in the auto white-list\r
  63 X-QM-Scan-Virus: ClamAV says the message is clean\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: Sun, 09 Feb 2014 10:10:25 -0000\r
  78 \r
  79 \r
  80 Initially I agreed with Bremner that we should be as faithful as\r
  81 possible in our json/sexp output. However, looking at other headers like\r
  82 cc: it seems that this can be present but empty (at least I sent myself\r
  83 a message with that property), but that notmuch-show omits it.\r
  84 \r
  85 Looking at the code for that pathway we use\r
  86 g_mime_message_get_recipients followed by\r
  87 internet_address_list_to_string and we only output a cc: pair if this is\r
  88 non-null (which means we had an address)\r
  89 \r
  90 In light of that I think changing the cli to only output\r
  91 content-description if non-null seems consistent.\r
  92 \r
  93 Best wishes\r
  94 \r
  95 Mark\r
  96 \r
  97 \r
  98 \r
  99 \r
 100 \r
 101 On Sat, 08 Feb 2014, "W. Trevor King" <wking@tremily.us> wrote:\r
 102 > On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:\r
 103 >> "W. Trevor King" <wking@tremily.us> writes:\r
 104 >> > Rather than patching this in Emacs, maybe we should collapse the\r
 105 >> > =E2=80=9Cnot set=E2=80=9D and =E2=80=9Cset to empty string=E2=80=9D ca=\r
 106 ses in notmuch-show.c?  I\r
 107 >> > can't think of any reasons why someone would want to distinguish\r
 108 >> > those two cases, and it's easier all around if we standardize the\r
 109 >> > representation as far upstream as possible.\r
 110 >>=20\r
 111 >> Do the RFCs have anything to say about headers with empty content?\r
 112 >> If not I'd be inclined to leave the CLI output as raw as possible,\r
 113 >> just because people are always finding new ways to apply tools.\r
 114 >\r
 115 > RFC 2183 does not describe Content-Description, it just uses it in\r
 116 > some examples [1].  In all the examples where Content-Description is\r
 117 > present, the value is not empty.  RFC 2045 defines\r
 118 > Content-Description, but it doesn't give all that much information\r
 119 > [2]:\r
 120 >\r
 121 >   The ability to associate some descriptive information with a given\r
 122 >   body is often desirable.  For example, it may be useful to mark an\r
 123 >   "image" body as "a picture of the Space Shuttle Endeavor."  Such\r
 124 >   text may be placed in the Content-Description header field.  This\r
 125 >   header field is always optional.\r
 126 >\r
 127 >     description :=3D "Content-Description" ":" *text\r
 128 >\r
 129 >   The description is presumed to be given in the US-ASCII character\r
 130 >   set, although the mechanism specified in RFC 2047 may be used for\r
 131 >   non-US-ASCII Content-Description values.\r
 132 >\r
 133 > I couldn't find more generic references to the meaning of empty header\r
 134 > values, but I find it hard to imagine anyone assigning semantic value\r
 135 > to an explicitly-empty description (vs. no Content-Description at\r
 136 > all).\r
 137 >\r
 138 > Cheers,\r
 139 > Trevor\r
 140 >\r
 141 > [1]: http://tools.ietf.org/html/rfc2183#section-3\r
 142 > [2]: http://tools.ietf.org/html/rfc2045#section-8\r
 143 >\r
 144 > --=20\r
 145 > This email may be signed or encrypted with GnuPG (http://www.gnupg.org).\r
 146 > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\r