On Sun, Apr 19, 2009 at 11:43:41AM -0500, Michael Witten wrote:
> } elsif (/^Subject:\s*(.+)\s*$/i) {
> - $initial_subject = $1;
> - my $subject = $initial_subject;
> - $_ = "Subject: " .
> - ($subject =~ /[^[:ascii:]]/ ?
> - quote_rfc2047($subject) :
> - $subject) .
> - "\n";
> + $initial_subject = $need_8bit_cte ? quote_rfc2047($1) : $1;
> + next;
I don't think this is a good idea. need_8bit_cte is about the _whole_
message, including all headers, and this is just about the subject.
Which means that we end up rfc2047-encoding the subject unnecessarily
quite a bit (since at least in git itself, most of the time the
non-ascii bits are in people's names).
This makes the subject unnecessarily ugly for readers which don't do
rfc2047 decoding. And while I expect that most real MUAs these days
handle the decoding, it also makes life harder for people looking
directly at message, or doing "grep -i ^subject: foo.mbox". Yes, I know
that doesn't even remotely follow the standards (e.g., it won't handle
line-wrapped headers), but I don't see any need to make it worse.
All of that being said, even if we decided that it _is_ OK to quote
even when it wasn't unnecessary, your patch still isn't right.
need_8bit_cte is not "does this message need an 8-bit cte at all?" but
rather "does _we_ need to add an 8-bit cte?". A few lines above the ones
you changed, notice that when we see the message already has a
MIME-Version header, we turn set $need_8bit_cte to 0. But in that case,
we still may need to encode the subject if it has non-ascii characters.
-Peff
--
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