6b/e5760eceff3d1255654fb0642f0dc19efe9e29

   1 Return-Path: <amdragon@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id EE515429E32\r
   6         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id HzpNuan7pkXo for <notmuch@notmuchmail.org>;\r
  17         Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
  18 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com\r
  19         [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 2CBB4429E25\r
  22         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:31 -0700 (PDT)\r
  23 Received: by qyk9 with SMTP id 9so3408401qyk.5\r
  24         for <notmuch@notmuchmail.org>; Mon, 27 Jun 2011 19:12:30 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:content-type\r
  28         :content-transfer-encoding;\r
  29         bh=zBgAsI/iyHZdzMTiCbXmbJmxkff6w1U3pxQQntndgUc=;\r
  30         b=nilv8Jx3eT2ssG9CxEwgek0uychm4fP4BwxZoKTRnhAvKUIFKaCJxUQiXvhgLHjdAU\r
  31         5hLrUC0AcA3wKc0dmi3adE1XmfbhOEkKTZPZ1enaXQUEoP8re/1LtLVwt/YFL5xjMrIC\r
  32         HpYK7jHyq+nFTWNXogukxSr116VfKx3se5HXA=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  34         h=mime-version:sender:in-reply-to:references:date\r
  35         :x-google-sender-auth:message-id:subject:from:to:content-type\r
  36         :content-transfer-encoding;\r
  37         b=LvE4s/MmkBOj6gWDCed3onxcQ1kNVi34expTF/W4DhQ8mkYAI5mx0nlTvspwEMQdwl\r
  38         K7K7DovuFJrq06rN8GK+XO3/WNuKTJvRGLS/wZZAK9duqjFQxJbKF3IPgZS/kpKrTthe\r
  39         3ZsCod+avv5tkXx6aEZbbjAxMJwChmH9usR+A=\r
  40 MIME-Version: 1.0\r
  41 Received: by 10.229.2.157 with SMTP id 29mr5269708qcj.62.1309227150232; Mon,\r
  42         27 Jun 2011 19:12:30 -0700 (PDT)\r
  43 Sender: amdragon@gmail.com\r
  44 Received: by 10.229.32.197 with HTTP; Mon, 27 Jun 2011 19:12:30 -0700 (PDT)\r
  45 In-Reply-To: <4E09072A.7040906@fifthhorseman.net>\r
  46 References: <1307032735-27427-1-git-send-email-jrollins@finestructure.net>\r
  47         <1307120466-4980-1-git-send-email-jrollins@finestructure.net>\r
  48         <87wrgccedd.fsf@yoom.home.cworth.org>\r
  49         <87mxh319un.fsf@servo.factory.finestructure.net>\r
  50         <BANLkTik8v7uZDcO4wV1Ve1Lymd03Z-WWdw@mail.gmail.com>\r
  51         <878vsn0x1i.fsf@servo.factory.finestructure.net>\r
  52         <20110627220741.GA4120@mit.edu>\r
  53         <4E09072A.7040906@fifthhorseman.net>\r
  54 Date: Mon, 27 Jun 2011 22:12:30 -0400\r
  55 X-Google-Sender-Auth: dwt19CTcg1NN7LbihamhpN5LcMg\r
  56 Message-ID:\r
  57  <CAH-f9WtuGs29c41NRgdWXmVwfhLXhT+yaR6pE_soUrBTC5q6Tw@mail.gmail.com>\r
  58 Subject: Re: interaction between --format=raw and multipart handling [was: Re:\r
  59         Do not attept to output part raw if part is not GMimePart.]\r
  60 From: Austin Clements <amdragon@mit.edu>\r
  61 To: notmuch <notmuch@notmuchmail.org>\r
  62 Content-Type: text/plain; charset=UTF-8\r
  63 Content-Transfer-Encoding: quoted-printable\r
  64 X-BeenThere: notmuch@notmuchmail.org\r
  65 X-Mailman-Version: 2.1.13\r
  66 Precedence: list\r
  67 List-Id: "Use and development of the notmuch mail system."\r
  68         <notmuch.notmuchmail.org>\r
  69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  72 List-Post: <mailto:notmuch@notmuchmail.org>\r
  73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  76 X-List-Received-Date: Tue, 28 Jun 2011 02:12:32 -0000\r
  77 \r
  78 On Mon, Jun 27, 2011 at 6:41 PM, Daniel Kahn Gillmor\r
  79 <dkg@fifthhorseman.net> wrote:\r
  80 > On 06/27/2011 06:07 PM, Austin Clements wrote:\r
  81 >> Oh, right, of course. =C2=A0show_message_part will walk into the parts, =\r
  82 so\r
  83 >> format_part_content_raw will still be called on the leafs of a\r
  84 >> requested multipart. =C2=A0Though, this approach results in each leaf be=\r
  85 ing\r
  86 >> transfer decoded and printed individually, so if you ask for a\r
  87 >> multipart, you won't get the "raw" contents of the multipart (unless\r
  88 >> it's part 0), so much as you get the concatenated "raw" contents of\r
  89 >> each part in the multipart.\r
  90 >\r
  91 >\r
  92 > let's take two labeled examples:\r
  93 >\r
  94 > A=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 58292 bytes\r
  95 > B =E2=94=9C=E2=94=AC=E2=95=B4multipart/mixed 56553 bytes\r
  96 > C =E2=94=82=E2=94=9C=E2=95=B4text/plain 1278 bytes\r
  97 > D =E2=94=82=E2=94=9C=E2=95=B4text/plain attachment [grub-install.out] 541=\r
  98 09 bytes\r
  99 > E =E2=94=82=E2=94=94=E2=95=B4text/x-diff attachment [597538.patch] 496 by=\r
 100 tes\r
 101 > F =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
 102 900 bytes\r
 103 >\r
 104 >\r
 105 > X=E2=94=94=E2=94=AC=E2=95=B4multipart/signed 3863 bytes\r
 106 > Y =E2=94=9C=E2=95=B4text/plain 1857 bytes\r
 107 > Z =E2=94=94=E2=95=B4application/pgp-signature attachment [signature.asc] =\r
 108 900 bytes\r
 109 >\r
 110 > (i know, you won't use "A" or "Z" as part IDs once we have hierarchical\r
 111 > part numbers, but consider them placeholders).\r
 112 >\r
 113 > if parts F or Z are ever going to be useful (e.g. to some external\r
 114 > process that wants to validate the signature by hand), then the tool\r
 115 > needs to provide some way of producing parts B and Y in a pristine form\r
 116 > (that is, including MIME headers and without interpreting/applying any\r
 117 > transfer encodings).\r
 118 >\r
 119 > Perhaps this means there are two flavors of "raw" that we should be\r
 120 > distinguishing, something like:\r
 121 >\r
 122 > =C2=A00) "source" -- the equivalent to viewing the source of the message,\r
 123 > with headers and without attempting to reverse transfer-encodings, etc.\r
 124 >\r
 125 > =C2=A01) "rare" -- (not entirely raw, but still bloody, ha ha) strip head=\r
 126 ers,\r
 127 > reverse transfer encodings, etc.\r
 128 >\r
 129 > I think our current implementation of --format=3Draw emits "source" when\r
 130 > applied to the entire message, but "rare" when applied to one of the part=\r
 131 s.\r
 132 \r
 133 Yes.\r
 134 \r
 135 > I'm suggesting that it might be useful to be able to get "source" of a\r
 136 > part. =C2=A0(and perhaps it might also be useful to get the whole message\r
 137 > "rare" sometimes?)\r
 138 >\r
 139 > My first instinct was: if it's multipart, provide "source", if it's\r
 140 > single-part, provide "rare". =C2=A0But that fails for the XYZ case above =\r
 141 --\r
 142 > we'd need Y (which is single-part) to be provided as "source" if we were\r
 143 > ever to be able to make use of Z on its own, so i don't think it'll be\r
 144 > that simple.\r
 145 >\r
 146 > OTOH, i'm not sure that "rare" is particularly meaningful for non-leaf\r
 147 > parts.\r
 148 >\r
 149 >> That if you ask for a multipart, you should effectively get a slice\r
 150 >> out of the original message bytes (since multipart/* parts can't have\r
 151 >> non-identity transfer encodings). =C2=A0Are you also saying that should\r
 152 >> extend to transfer encoded leaf parts, too?\r
 153 >\r
 154 > hmm. =C2=A0is it true that multipart/* parts can't have non-identity tran=\r
 155 sfer\r
 156 > encodings? =C2=A0that would simplify some things, but i don't have a\r
 157 > reference handy that says it's the case.\r
 158 \r
 159 RFC 2045, section 6.4: "If an entity is of type "multipart" the\r
 160 Content-Transfer-Encoding is not permitted to have any value other\r
 161 than "7bit", "8bit" or "binary"."  (And, for completeness, section\r
 162 6.2: "The Content-Transfer-Encoding values "7bit", "8bit", and\r
 163 "binary" all mean that the identity (i.e. NO) encoding transformation\r
 164 has been  performed.")\r
 165 \r
 166 > At any rate, i'm not sure it affects the need for being able to emit\r
 167 > both "rare" and "source" forms of at least the leaf (non-multipart) parts=\r
 168 .\r
 169 >\r
 170 > i hope this is all at least somewhat clarifying and not just adding to\r
 171 > the confusion,\r
 172 \r
 173 Thanks.  That's actually very informative and solidifies some of\r
 174 what's been slowly coagulating in my mind.\r
 175 \r
 176 I was also thinking about the two output variants you describe\r
 177 (though, being less clever, I was thinking "raw" and "decoded").  The\r
 178 fact that multipart/* parts can only have identity encodings makes me\r
 179 wonder if the two could be merged by thinking of the decoded content\r
 180 of a leaf part as a child/body to the original, encoded part.  On the\r
 181 other hand, that doesn't make sense for other formats, so perhaps\r
 182 that's not a fruitful approach.\r