From: Mark Walters <markwalters1009@gmail.com>
To: "W. Trevor King" <wking@tremily.us>, David Bremner <david@tethera.net>
Subject: Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for
	part buttons
In-Reply-To: <20140208165931.GB17142@odin.tremily.us>
References: <877g9chbay.fsf@qmul.ac.uk>
 <cover.1391423201.git.wking@tremily.us>
	<27be295875a7df782a83c9a2c09d06f9d321fe9e.1391423201.git.wking@tremily.us>
	<87vbwwosuw.fsf@qmul.ac.uk>	<20140203203418.GO14197@odin.tremily.us>
	<20140204013246.GQ19935@odin.tremily.us>	<87r47dojbt.fsf@zancas.localnet>
	<20140208165931.GB17142@odin.tremily.us>
User-Agent: Notmuch/0.15.2+484~gfb59956 (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Sun, 09 Feb 2014 10:10:08 +0000
Message-ID: <878utkd2bj.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list


Initially I agreed with Bremner that we should be as faithful as
possible in our json/sexp output. However, looking at other headers like
cc: it seems that this can be present but empty (at least I sent myself
a message with that property), but that notmuch-show omits it.

Looking at the code for that pathway we use
g_mime_message_get_recipients followed by
internet_address_list_to_string and we only output a cc: pair if this is
non-null (which means we had an address)

In light of that I think changing the cli to only output
content-description if non-null seems consistent.

Best wishes

Mark





On Sat, 08 Feb 2014, "W. Trevor King" <wking@tremily.us> wrote:
> On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:
>> "W. Trevor King" <wking@tremily.us> writes:
>> > Rather than patching this in Emacs, maybe we should collapse the
>> > =E2=80=9Cnot set=E2=80=9D and =E2=80=9Cset to empty string=E2=80=9D ca=
ses in notmuch-show.c?  I
>> > can't think of any reasons why someone would want to distinguish
>> > those two cases, and it's easier all around if we standardize the
>> > representation as far upstream as possible.
>>=20
>> Do the RFCs have anything to say about headers with empty content?
>> If not I'd be inclined to leave the CLI output as raw as possible,
>> just because people are always finding new ways to apply tools.
>
> RFC 2183 does not describe Content-Description, it just uses it in
> some examples [1].  In all the examples where Content-Description is
> present, the value is not empty.  RFC 2045 defines
> Content-Description, but it doesn't give all that much information
> [2]:
>
>   The ability to associate some descriptive information with a given
>   body is often desirable.  For example, it may be useful to mark an
>   "image" body as "a picture of the Space Shuttle Endeavor."  Such
>   text may be placed in the Content-Description header field.  This
>   header field is always optional.
>
>     description :=3D "Content-Description" ":" *text
>
>   The description is presumed to be given in the US-ASCII character
>   set, although the mechanism specified in RFC 2047 may be used for
>   non-US-ASCII Content-Description values.
>
> I couldn't find more generic references to the meaning of empty header
> values, but I find it hard to imagine anyone assigning semantic value
> to an explicitly-empty description (vs. no Content-Description at
> all).
>
> Cheers,
> Trevor
>
> [1]: http://tools.ietf.org/html/rfc2183#section-3
> [2]: http://tools.ietf.org/html/rfc2045#section-8
>
> --=20
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy