On Sun, Jun 13, 2010 at 6:15 AM, Michael Witten <mfwitten@xxxxxxxxx> wrote: > On Sat, Jun 12, 2010 at 05:11, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: >> AFAICT the original message did not declare an encoding: >> >> Subject: [PATCH v2 0/2] bash completion: Support "divergence from upstream" warnings in __git_ps1 >> Date: Sat, 12 Jun 2010 12:02:14 +0200 >> Message-ID: <cover.1276336602.git.trast@xxxxxxxxxxxxxxx> >> X-Mailer: git-send-email 1.7.1.561.g94582 >> In-Reply-To: <20100612000002.GA30196@neumann> >> References: <20100612000002.GA30196@neumann> >> MIME-Version: 1.0 >> Content-Type: text/plain >> Return-Path: trast@xxxxxxxxxxxxxxx >> ... >> Is this a new vger policy, or am I hitting a send-email bug? > > Let's assume the headers themselves are already properly encoded. > > According to: > > http://www.faqs.org/rfcs/rfc2045.html > > we have: > > The proper Content-Transfer-Encoding > label must always be used. > > and: > > An encoding type of 7BIT requires that > the body is already in a 7bit mail-ready > representation. This is the default value > -- that is, "Content-Transfer-Encoding: 7BIT" > is assumed if the Content-Transfer-Encoding > header field is not present. > > Moreover, according to: > > http://www.faqs.org/rfcs/rfc2046.html > > we have: > > 4.1.2 Charset Parameter > ... > The default character set, which must be > assumed in the absence of a charset parameter, > is US-ASCII. > > So, your email is indeed incorrect in 2 ways if the body contains > UTF-8 encoded data. > > From what I've skimmed, the mail user agent (MUA)---such as > send-email---could send your unmodified message body by producing > these headers: > > MIME-Version: 1.0 > Content-type: text/plain; charset=utf-8 > Content-transfer-encoding: 8bit > > but only 7bit transfer encodings are guaranteed to make it intact to > the destination; consequently, it would probably be a good idea for > the MUA to transform your message into some 7bit encoding, preferably > a human-readable one such as the 'quoted-printable' encoding; after > such a transformation, the headers could be: > > MIME-Version: 1.0 > Content-type: text/plain; charset=utf-8 > Content-transfer-encoding: quoted-printable > QP-encoding is sometimes destructive, and as such not recommended for patches - in fact, Documentation/SubmittingPatches forbid it. For the cover-letter the destruction might not be an issue (IIRC it's some line-feeds that might be added because QP can a line longer than the maximum line-length), but special casing the encoding for cover-letters doesn't strike me as The Right Thing To Do(tm). I think the only real alternative to 8-bit encoding is Base64, and it sacrifices human-readability. Dunno how bad that is, though. -- Erik "kusma" Faye-Lund -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html