Message-ID: <4E09072A.7040906@fifthhorseman.net>
Date: Mon, 27 Jun 2011 18:41:46 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.17) Gecko/20110516 Icedove/3.1.10
MIME-Version: 1.0
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: interaction between --format=raw and multipart handling [was: Re:
	Do not attept to output part raw if part is not GMimePart.]
References: <1307032735-27427-1-git-send-email-jrollins@finestructure.net>
	<1307120466-4980-1-git-send-email-jrollins@finestructure.net>
	<87wrgccedd.fsf@yoom.home.cworth.org>
	<87mxh319un.fsf@servo.factory.finestructure.net>
	<BANLkTik8v7uZDcO4wV1Ve1Lymd03Z-WWdw@mail.gmail.com>
	<878vsn0x1i.fsf@servo.factory.finestructure.net>
	<20110627220741.GA4120@mit.edu>
In-Reply-To: <20110627220741.GA4120@mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enig016CC7533040F7A4A5342619"
Precedence: list
Reply-To: notmuch <notmuch@notmuchmail.org>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig016CC7533040F7A4A5342619
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 06/27/2011 06:07 PM, Austin Clements wrote:
> Oh, right, of course.  show_message_part will walk into the parts, so
> format_part_content_raw will still be called on the leafs of a
> requested multipart.  Though, this approach results in each leaf being
> transfer decoded and printed individually, so if you ask for a
> multipart, you won't get the "raw" contents of the multipart (unless
> it's part 0), so much as you get the concatenated "raw" contents of
> each part in the multipart.


let's take two labeled examples:

A=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 58292 bytes
B =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 56553 bytes
C =E2=94=82=E2=94=9C=E2=95=B4text/plain 1278 bytes
D =E2=94=82=E2=94=9C=E2=95=B4text/plain attachment [grub-install.out] 541=
09 bytes
E =E2=94=82=E2=94=94=E2=95=B4text/x-diff attachment [597538.patch] 496 by=
tes
F =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =
900 bytes


X=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 3863 bytes
Y =E2=94=9C=E2=95=B4text/plain 1857 bytes
Z =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =
900 bytes

(i know, you won't use "A" or "Z" as part IDs once we have hierarchical
part numbers, but consider them placeholders).

if parts F or Z are ever going to be useful (e.g. to some external
process that wants to validate the signature by hand), then the tool
needs to provide some way of producing parts B and Y in a pristine form
(that is, including MIME headers and without interpreting/applying any
transfer encodings).

Perhaps this means there are two flavors of "raw" that we should be
distinguishing, something like:

 0) "source" -- the equivalent to viewing the source of the message,
with headers and without attempting to reverse transfer-encodings, etc.

 1) "rare" -- (not entirely raw, but still bloody, ha ha) strip headers,
reverse transfer encodings, etc.

I think our current implementation of --format=3Draw emits "source" when
applied to the entire message, but "rare" when applied to one of the part=
s.

I'm suggesting that it might be useful to be able to get "source" of a
part.  (and perhaps it might also be useful to get the whole message
"rare" sometimes?)

My first instinct was: if it's multipart, provide "source", if it's
single-part, provide "rare".  But that fails for the XYZ case above --
we'd need Y (which is single-part) to be provided as "source" if we were
ever to be able to make use of Z on its own, so i don't think it'll be
that simple.

OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf
parts.

> Daniel, is this the problem that you're getting at with "opacity"?

the origin of the term "opaque" used in this context can be found in the
definition of multipart/signed:

 https://tools.ietf.org/html/rfc1847#section-2.1

> That if you ask for a multipart, you should effectively get a slice
> out of the original message bytes (since multipart/* parts can't have
> non-identity transfer encodings).  Are you also saying that should
> extend to transfer encoded leaf parts, too?

hmm.  is it true that multipart/* parts can't have non-identity transfer
encodings?  that would simplify some things, but i don't have a
reference handy that says it's the case.

At any rate, i'm not sure it affects the need for being able to emit
both "rare" and "source" forms of at least the leaf (non-multipart) parts=
=2E

i hope this is all at least somewhat clarifying and not just adding to
the confusion,

	--dkg


--------------enig016CC7533040F7A4A5342619
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQJ8BAEBCgBmBQJOCQcqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD
Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpgVoQAIg+UCSpzFilQc2QLNUfDRmK
WGqVYHaeNvWl6muvCzW+1oX3TM3kq1MaVrEkIgtLY3b1BPIdZ/0szKCRSvJcUzlW
qCqfFwNYs3iwu8tIbS9hB7YnKf30Xq8zt0ACuNFzk67KHPu8eaVV7Eu4AeH++xoN
PrO2cIc4ACiKBRrre2P1fJZRb9c+BftlU9lsWeqp1hVJD2udidf4rVM7AJ/QbjJH
FvH2aWhE0fa1Suy9twcWhgV2ZhVIx1iTck271aTRJw/4ItVSOIpW0vaaM0bTjcn4
SO1v16DBOu6S0rVtiOgxrztBYoT0EDL8Bn5fXq542vQRgKZoKnO2LDy1Dg1ffMLY
WE2CiHKhw9YzETrmlUR4+Kzct+XRQwuPAAzYgtmj0sSgwIZSfN94evBcYol1YcDZ
MaW0UyFNrwciJ1lZwm/njnLRdXYDYpDzxiFX5Eou62EdZxYDQPwM3oVTb6xZPlQV
WK04w8MjpWYh0wf92+wO71+B36XYB43amxhxP9xldX1Itn301PK2YOiwWg+09LT2
wS0KmdHMu32elWIvrp8xafhpkUgoMyr/idBglFmh723e7YTrIy8B1/O24lIfBuzi
/bdWMVHJU2QTT8q6J7vyiudinnIJo/secQA9tLvnajwu0eaRRQ8IYjVIefx+MvJF
o3A2YF+2b50sYJ+cKhbK
=bVBl
-----END PGP SIGNATURE-----

--------------enig016CC7533040F7A4A5342619--