From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH] Output unmodified Content-Type header value for JSON
	format.
In-Reply-To: <87wrawq1dz.fsf@gmail.com>
References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
	<87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>
User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Sat, 19 Nov 2011 02:49:43 -0800
Message-ID: <87d3coxu7s.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Sat, 19 Nov 2011 06:42:00 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmai=
l.com> wrote:
> The parameters are there for a reason.  They are part of the
> content-type and are needed to handle the body properly.  If you say
> that the parameters are not needed by notmuch users, that implies that
> they are handled by notmuch.  Which is just not possible.

Hey, Dimitry.  At least some of the parameters in the content-type are
actually related to the mime structure itself.  A good example is:

boundary=3D\"=3D-=3D-=3D\"

This parameter is there to tell the MIME parser how to parse the content
that follows.  It is meant for the first level parser and no more.  Once
the MIME has been separated into it's constituent parts, there's no need
for any further clients to know anything about boundary string.

I would argue that notmuch is acting as the first level parser.  As far
as I can tell, most of the rest of the parameters I've seen should only
be useful to the those first-level parsers.

As Austin mentioned, is it not possible for notmuch itself to act on the
parameter to give a properly formatted output to its clients?

> The fact that this change happens to fix an issue with HTML charsets for
> me is just a side effect.

But isn't that actually a large part of the issue?  If this patch fixes
something that you think notmuch is doing improperly, could there not be
a test for it?

However, based on your patches and as far as I can tell, this change
adds more than a boundary parameter to only crypto parts
(application/signed and application/encrypted).  However, I don't think
any of the crypto functionality needs any of the extra information
provided in the extended output.  If there was a test for the
functionality you think is missing, it would help bolster the case for
the additional output.

> > >   "content": [{"id": 2,
> > > - "content-type": "text/plain",
> > >   "content": "This is a test signed message.\n"},
> >=20
> > Without figuring out what's going on, I notice that some of the tests
> > have been modified to remove the content-type fields on a bunch of
> > parts.  I think that is probably not right.
> >=20
>=20
> I tried to explain this in the preable.  These parts do not have
> Content-Type in the original message.  So I think it is wrong for
> notmuch JSON format to add it.

Ah, ok, I think I understand this point.  I think this is actually a
separate issue than the one the rest of the patch set is for, though.
One part of the patch is that content-type parameters are also about,
and another part is that parts without content-type shouldn't be
assigned one automatically.  I personally think those should be separate
patches.

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOx4nHAAoJEO00zqvie6q827gP/RiinHLKC4FO445/yq3eMgyC
3v/JN14rjgw5NZ+EnG2VxRDT5LaYV8yiBKIRJH09O3Ewo1pomVu3E6V6lVOS7FnD
EjUODYl3Ss6uGbHkH2a6ww2NowGBNOWT1/bBktQTeakAbLqDy6k/dJciXIeajmUS
JJolaOonTKlzqJi6LcqX6k9L1A2jEbWyp2uqC9nnaq4tokvhxohiep8Ju/mu+ixj
y79IS/sUxY7u3/h1mJNCEPuZ8gBss3fZOaycJ2x9Cwt3DAcuovVBXva2KAgKNzw0
KbTA/NGhAlCoGeK8ceYLhb0cRcsTC0wbroWCr4L/mjOVuBZvjZ6Zlu7cSrwDfZY0
pKnoOlLgQdk6r93CXBwu3i4LEi7J4xW60K1qZUsPa6heK7r1Fimg3iibn3RITLCl
FDUQrldjVOViNMmsVudKu/z2PSvXq6gPlWqyuaQ6YV4B5JdnvAmkEsZIqOqjG2fF
N4PJT1yr6NJcBV6D2vkWfF3IKMHokk+u2ERGPZwqhFV/5XKEiNvvUqswavCG+LY/
qzIUTX+xjNEMYY4adqPcym9ETSwJvxiv137vV4vUVhpLUliDsW6LNh7DHbcaekRq
BZikGxsma1WnGwfFCenuqyqG/G085Tfv1bgF/rVQfLQpTktAPG4LVorCsBKZDygh
JWzM8d3AdOpaoQntsXcq
=RdDy
-----END PGP SIGNATURE-----
--=-=-=--