On Fri, Apr 08, 2011 at 01:13:47PM -0700, Junio C Hamano wrote:
> A Tangent.
>
> >> X-Mailer: git-send-email 1.7.4.2.1.gd6f1f
> >> In-Reply-To: <1302102336-8800-1-git-send-email-asedeno@xxxxxxx>
>
> This is not about this particular patch, but the From: address
> git-send-email generates for you does not seem to quote the human readable
> part, even though the name has a "." in it.
>
> Your mails seem to reach the recipients fine, but I saw my reply to you
> bounce, because "To:" or "Cc:" in my reply end up having the "R." part not
> quoted, like this:
>
> (wrong) To: Alejandro R. SedeÃo <asedeno@xxxxxxx>
> (correct) To: "Alejandro R. SedeÃo" <asedeno@xxxxxxx>
Hmm. His case has an extra level of confusion, though, because the
non-ascii characters all need rfc2047 encoding. So two emails I've seen
from him have:
From: =?UTF-8?B?IkFsZWphbmRybyBSLiBTZWRlw7FvIg==?= <asedeno@xxxxxxx>
From: =?UTF-8?q?Alejandro=20R=2E=20Sede=C3=B1o?= <asedeno@xxxxxxx>
where the first is from Icedove (i.e., Thunderbird) and the second is
from git-send-email.
The first one contains double-quotes embedded in the encoded portion.
The second one (send-email) does not.
But I'm not clear on if that is necessary. I thought that rfc2047 could
only encode a "word" in the "phrase" portion in an address header,
meaning the parsing should be unambiguous.
That being said, I think we are not quoting in the non-rfc2047 case,
anyway, and that is a bug. rfc5322 says this (section 4.1, Miscellaneous
obsolete tokens):
Note: The "period" (or "full stop") character (".") in obs-phrase is
not a form that was allowed in earlier versions of this or any other
specification. Period (nor any other character from specials) was not
allowed in phrase because it introduced a parsing difficulty
distinguishing between phrases and portions of an addr-spec (see
section 4.4). It appears here because the period character is
currently used in many messages in the display-name portion of
addresses, especially for initials in names, and therefore must be
interpreted properly.
which recognizes this situation. But being in the obsolete section, I
think it is saying "you still need to interpret these, but don't
generate them". IOW, we should still be generating quotes now.
I think format-patch is totally lacking in this type of quoting. If I
do:
$ git init
$ git config user.name '<bogus> with "quotes"'
$ echo contents >foo && git add . && git commit -m foo
$ git format-patch --stdout --root
...
From: bogus with "quotes <peff@xxxxxxxx>
So some of my magic characters are just stripped, and some of them get
included, making the output bogus (the stripping of <> actually happens
within git, so the commit itself is missing them).
Not that I think a name like that is sane, but probably we should be
double-quoting properly anyway, and then the "." case would just fall
out.
-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