[PATCH] Output unmodified Content-Type header value for JSON format.

[Dmitry Kurochkin]

On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements <amdragon at MIT.EDU> wrote:
> Quoth Dmitry Kurochkin on Nov 19 at  6:42 am:
> > Hi Jamie.
> > 
> > On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin at gmail.com> wrote:
> > > > Before the change, notmuch used g_mime_content_type_to_string(3)
> > > > function to output Content-Type header value.  Turns out it outputs
> > > > only "type/subtype" part and ignores all parameters.  Also, if there
> > > > is no Content-Type header, default "text/plain" value is used.
> > > 
> > > Hi, Dmitry.  Can you explain under what circumstances you would need the
> > > extra content-type parameters?
> > 
> > Charset is an example of a parameter which you need to render a part
> > correctly.
> 
> Can notmuch convert to a common charset, given that, otherwise, every
> client is going to have to implement this conversion anyway?
> 

Notmuch can handle charset (and any other) parameters but only for known
media types (i.e. text/*).  I think it would be useful (especially for
human-readable output formats).  But it is a separate issue.

Notmuch can not convert other types it does not know how to handle.
E.g. HTML charset conversion is not as simple as for plain text.

AFAIK standard defines charset parameter just for few types.  So in
general, charset parameter can have any meaning for some custom media
type.

> (And are there other examples of useful things in the content type?)

What is meant by useful?  All parameters do have some use.  The fact
that notmuch does not handle them does not mean they are useless.  And
notmuch can not handle all parameters just because the list of
parameters is not defined.  So there is no choice but to let notmuch
users see and use these parameters.

Regards,
  Dmitry