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└┬╴multipart/signed 58292 bytes B ├┬╴multipart/mixed 56553 bytes C │├╴text/plain 1278 bytes D │├╴text/plain attachment [grub-install.out] 54109 bytes E │└╴text/x-diff attachment [597538.patch] 496 bytes F └╴application/pgp-signature attachment [signature.asc] 900 bytes X└┬╴multipart/signed 3863 bytes Y ├╴text/plain 1857 bytes Z └╴application/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=raw emits "source" when applied to the entire message, but "rare" when applied to one of the parts. 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. i hope this is all at least somewhat clarifying and not just adding to the confusion, --dkg
Description: OpenPGP digital signature
_______________________________________________ notmuch mailing list firstname.lastname@example.org http://notmuchmail.org/mailman/listinfo/notmuch