On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.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? > > 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.