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