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

[Austin Clements <amdragon@MIT.EDU>]

Quoth Dmitry Kurochkin on Nov 19 at  9:26 am:
> On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements <amdragon@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@finestructure.net> wrote:
> > > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin <dmitry.kurochkin@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.

Interesting.  I hadn't realized the content-type specification was so
open-ended.  However, there are many things that *could* be included
in the JSON format but aren't; what's included is primarily driven by
what consumers actually need and it seems like the actual need here is
charset handling.  Maybe the JSON format *shouldn't* evolve this way,
but I think it should either be driven by its needs like it is now, or
we should be taking bigger steps like providing *all* of the headers
(essentially, a JSON-ification of the MIME structure), which would
subsume more specific generalizations like exposing just the full
content-type header.

Regarding charset, specifically, though, the JSON format only includes
part bodies for text/* types and, according to RFC 2045,

  For example, the "charset" parameter is applicable to any subtype of
  "text", ...

Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush,
but I think it's saying essentially the same thing in a lot more
detail.  Given that, I think it does make sense for notmuch to handle
the charset parameter and re-coding.

> > (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.

Yes, I now agree with this, modulo my statements about generality above.

> Regards,
>   Dmitry
> 

-- 
Austin Clements                                      MIT/'06/PhD/CSAIL
amdragon@mit.edu                           http://web.mit.edu/amdragon
       Somewhere in the dream we call reality you will find me,
              searching for the reality we call dreams.