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: <87r512pru2.fsf@gmail.com>
References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
	<87fwhkyisj.fsf@servo.finestructure.net> <87wrawq1dz.fsf@gmail.com>
	<87d3coxu7s.fsf@servo.finestructure.net> <87r512pru2.fsf@gmail.com>
User-Agent: Notmuch/0.9+81~gd8cf814 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Sun, 20 Nov 2011 12:10:52 -0800
Message-ID: <87ipmewo4z.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 Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmai=
l.com> wrote:
> Yes, at least in most cases.  On the other hand, if you can make notmuch
> show raw multipart part (you can, right?), then it seems natural that
> notmuch provides enough information to parse it.

This is kind of an unresolved issue, actually.  Currently headers are
only included in the "raw" format output of an entire message.
Otherwise, when raw output is requested of an individual part only the
body is output.  For multipart parts, the raw format output includes all
body parts concatenated together, still without any headers.

This "raw" multipart output clearly doesn't really make much sense and
we need to figure that out.  dkg wrote a good breakdown of the issue
here:

id:"4E09072A.7040906@fifthhorseman.net"

However, this only for "raw" output.  It's definitely not the same as
the json output.  For json the parts are all parsed by notmuch and
placed into separate json elements.  The receiver is not going to do any
further parsing since all the mime structure parsing has been done.

We need to keep clear the distinction between "parsing" the mime
structure, and "encoding" the content of the part.  Confusion seems to
be coming from the fact that the Content-Type header includes
information needed for both mime parsing and content encoding.  However,
I don't think that means that we need to just include everything in the
output.  Parameters that have to do with mime parsing should be dropped,
since that information has already been used in the mime parsing and
can't is no longer useful to the consumer.  It's just noise, and I don't
think notmuch should be outputting useless noise.

The open question seems to be how we handle the content encoding
parameters.  My argument is that those should either be used by notmuch
to properly encode the content for the consumer.  If that's not
possible, then just those parameters needed by the consumer to decode
the content should be output.

> > 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?
>=20
> No.  It just happens to be how I found the problem.  The issue is:
> notmuch JSON format mangles Content-Type header value by throwing away
> useful information in some cases and adding info that was not there in
> others.  Note that I do not mention any single parameter name here.  It
> is a general issue, not a "charset" or "boundary" parameter issue.

I'm sorry, but I still don't believe it's not possible to test for this
issue.  If there's a problem that you're seeing, then you must of
identified it somehow, and therefore there must be a way to test for it.

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJOyV7NAAoJEO00zqvie6q89j8QAIwLpC2PTwk4ceoYJ9e44uSf
2yJupIVV3+wpWqMsg7q0mY7ofNg367jFyMwF4iyWrm+cq+14O9tiGYJ0l+HoG9uk
rSps+BNWVKCjiAE+MROgAWzF7BIwdbmClWzE9tIP/Scj5gbDGdcwTQYCapXs3U56
ENnZP90DBpAkwGyPS12JqWDVhM9jjaRg38XM4OLhgwWc547AYAMjqaE15fe9U3PV
gufXtv65ECkqLlPrHwdXNzJYsLaitRZTukAIePYcXl9OFW9HPa39DoDP8azU4jLj
7hzPB9Gs4nPRTf5SWGUK4r/5VAszh3awSHuyAs3WQL3eZyyhsJlQaCz5qI16vt+/
U8oNqzAfbkaZh9SSg35IlKjdA6jJ/devpdwo3aEUTY37bsBzti+WxuFQpLpgF3NV
ZtonJGBaIDYMU67tCqt0t8rhq0IQ/fHjuT4eh6zuHVT4nnGZcCfp9CTb+qgKLOq7
Wpa+OMnlldifAN18bMuu2R4SHvCSIjboIQ4ZEUtVTZKknGjfShT76SPywowun1ek
FcvOFxrZfXa5cc430sSrugf0NeHPfrXDUdoMB2AoxczNYpiir+ZD4kc71Ez6fgGO
yg3pLUt3XHzE6+vXqcoCoUZUbZbPeddxntP+Mo3MnP/+tEuWKGSVbFK/s7AtUzxC
28dyJXd23Xx2g9T0JZbx
=+r3R
-----END PGP SIGNATURE-----
--=-=-=--