--- /dev/null
+Return-Path: <amdragon@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id EE515429E32\r
+ for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
+ RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id HzpNuan7pkXo for <notmuch@notmuchmail.org>;\r
+ Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
+Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com\r
+ [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 2CBB4429E25\r
+ for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
+Received: by qyk9 with SMTP id 9so3408401qyk.5\r
+ for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:30 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+ h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
+ :x-google-sender-auth:message-id:subject:from:to:content-type\r
+ :content-transfer-encoding;\r
+ bh=zBgAsI/iyHZdzMTiCbXmbJmxkff6w1U3pxQQntndgUc=;\r
+ b=nilv8Jx3eT2ssG9CxEwgek0uychm4fP4BwxZoKTRnhAvKUIFKaCJxUQiXvhgLHjdAU\r
+ 5hLrUC0AcA3wKc0dmi3adE1XmfbhOEkKTZPZ1enaXQUEoP8re/1LtLVwt/YFL5xjMrIC\r
+ HpYK7jHyq+nFTWNXogukxSr116VfKx3se5HXA=\r
+DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
+ h=mime-version:sender:in-reply-to:references:date\r
+ :x-google-sender-auth:message-id:subject:from:to:content-type\r
+ :content-transfer-encoding;\r
+ b=LvE4s/MmkBOj6gWDCed3onxcQ1kNVi34expTF/W4DhQ8mkYAI5mx0nlTvspwEMQdwl\r
+ K7K7DovuFJrq06rN8GK+XO3/WNuKTJvRGLS/wZZAK9duqjFQxJbKF3IPgZS/kpKrTthe\r
+ 3ZsCod+avv5tkXx6aEZbbjAxMJwChmH9usR+A=\r
+MIME-Version: 1.0\r
+Received: by 10.229.2.157 with SMTP id 29mr5269708qcj.62.1309227150232; Mon,\r
+ 27 Jun 2011 19:12:30 -0700 (PDT)\r
+Sender: amdragon@gmail.com\r
+Received: by 10.229.32.197 with HTTP; Mon, 27 Jun 2011 19:12:30 -0700 (PDT)\r
+In-Reply-To: <4E09072A.7040906@fifthhorseman.net>\r
+References: <1307032735-27427-1-git-send-email-jrollins@finestructure.net>\r
+ <1307120466-4980-1-git-send-email-jrollins@finestructure.net>\r
+ <87wrgccedd.fsf@yoom.home.cworth.org>\r
+ <87mxh319un.fsf@servo.factory.finestructure.net>\r
+ <BANLkTik8v7uZDcO4wV1Ve1Lymd03Z-WWdw@mail.gmail.com>\r
+ <878vsn0x1i.fsf@servo.factory.finestructure.net>\r
+ <20110627220741.GA4120@mit.edu>\r
+ <4E09072A.7040906@fifthhorseman.net>\r
+Date: Mon, 27 Jun 2011 22:12:30 -0400\r
+X-Google-Sender-Auth: dwt19CTcg1NN7LbihamhpN5LcMg\r
+Message-ID:\r
+ <CAH-f9WtuGs29c41NRgdWXmVwfhLXhT+yaR6pE_soUrBTC5q6Tw@mail.gmail.com>\r
+Subject: Re: interaction between --format=raw and multipart handling [was: Re:\r
+ Do not attept to output part raw if part is not GMimePart.]\r
+From: Austin Clements <amdragon@mit.edu>\r
+To: notmuch <notmuch@notmuchmail.org>\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 28 Jun 2011 02:12:32 -0000\r
+\r
+On Mon, Jun 27, 2011 at 6:41 PM, Daniel Kahn Gillmor\r
+<dkg@fifthhorseman.net> wrote:\r
+> On 06/27/2011 06:07 PM, Austin Clements wrote:\r
+>> Oh, right, of course. =C2=A0show_message_part will walk into the parts, =\r
+so\r
+>> format_part_content_raw will still be called on the leafs of a\r
+>> requested multipart. =C2=A0Though, this approach results in each leaf be=\r
+ing\r
+>> transfer decoded and printed individually, so if you ask for a\r
+>> multipart, you won't get the "raw" contents of the multipart (unless\r
+>> it's part 0), so much as you get the concatenated "raw" contents of\r
+>> each part in the multipart.\r
+>\r
+>\r
+> let's take two labeled examples:\r
+>\r
+> A=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 58292 bytes\r
+> B =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 56553 bytes\r
+> C =E2=94=82=E2=94=9C=E2=95=B4text/plain 1278 bytes\r
+> D =E2=94=82=E2=94=9C=E2=95=B4text/plain attachment [grub-install.out] 541=\r
+09 bytes\r
+> E =E2=94=82=E2=94=94=E2=95=B4text/x-diff attachment [597538.patch] 496 by=\r
+tes\r
+> F =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
+900 bytes\r
+>\r
+>\r
+> X=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 3863 bytes\r
+> Y =E2=94=9C=E2=95=B4text/plain 1857 bytes\r
+> Z =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
+900 bytes\r
+>\r
+> (i know, you won't use "A" or "Z" as part IDs once we have hierarchical\r
+> part numbers, but consider them placeholders).\r
+>\r
+> if parts F or Z are ever going to be useful (e.g. to some external\r
+> process that wants to validate the signature by hand), then the tool\r
+> needs to provide some way of producing parts B and Y in a pristine form\r
+> (that is, including MIME headers and without interpreting/applying any\r
+> transfer encodings).\r
+>\r
+> Perhaps this means there are two flavors of "raw" that we should be\r
+> distinguishing, something like:\r
+>\r
+> =C2=A00) "source" -- the equivalent to viewing the source of the message,\r
+> with headers and without attempting to reverse transfer-encodings, etc.\r
+>\r
+> =C2=A01) "rare" -- (not entirely raw, but still bloody, ha ha) strip head=\r
+ers,\r
+> reverse transfer encodings, etc.\r
+>\r
+> I think our current implementation of --format=3Draw emits "source" when\r
+> applied to the entire message, but "rare" when applied to one of the part=\r
+s.\r
+\r
+Yes.\r
+\r
+> I'm suggesting that it might be useful to be able to get "source" of a\r
+> part. =C2=A0(and perhaps it might also be useful to get the whole message\r
+> "rare" sometimes?)\r
+>\r
+> My first instinct was: if it's multipart, provide "source", if it's\r
+> single-part, provide "rare". =C2=A0But that fails for the XYZ case above =\r
+--\r
+> we'd need Y (which is single-part) to be provided as "source" if we were\r
+> ever to be able to make use of Z on its own, so i don't think it'll be\r
+> that simple.\r
+>\r
+> OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf\r
+> parts.\r
+>\r
+>> That if you ask for a multipart, you should effectively get a slice\r
+>> out of the original message bytes (since multipart/* parts can't have\r
+>> non-identity transfer encodings). =C2=A0Are you also saying that should\r
+>> extend to transfer encoded leaf parts, too?\r
+>\r
+> hmm. =C2=A0is it true that multipart/* parts can't have non-identity tran=\r
+sfer\r
+> encodings? =C2=A0that would simplify some things, but i don't have a\r
+> reference handy that says it's the case.\r
+\r
+RFC 2045, section 6.4: "If an entity is of type "multipart" the\r
+Content-Transfer-Encoding is not permitted to have any value other\r
+than "7bit", "8bit" or "binary"." (And, for completeness, section\r
+6.2: "The Content-Transfer-Encoding values "7bit", "8bit", and\r
+"binary" all mean that the identity (i.e. NO) encoding transformation\r
+has been performed.")\r
+\r
+> At any rate, i'm not sure it affects the need for being able to emit\r
+> both "rare" and "source" forms of at least the leaf (non-multipart) parts=\r
+.\r
+>\r
+> i hope this is all at least somewhat clarifying and not just adding to\r
+> the confusion,\r
+\r
+Thanks. That's actually very informative and solidifies some of\r
+what's been slowly coagulating in my mind.\r
+\r
+I was also thinking about the two output variants you describe\r
+(though, being less clever, I was thinking "raw" and "decoded"). The\r
+fact that multipart/* parts can only have identity encodings makes me\r
+wonder if the two could be merged by thinking of the decoded content\r
+of a leaf part as a child/body to the original, encoded part. On the\r
+other hand, that doesn't make sense for other formats, so perhaps\r
+that's not a fruitful approach.\r
projects / notmuch-archives.git / commitdiff