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 >> > “not set” and “set to empty string” cases 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. >> >> 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 := "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 > > -- > 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