On Fri, Apr 15, 2011 at 12:29 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Apr 15, 2011 at 12:21:24AM +0200, Erik Faye-Lund wrote: > >> >> True. But since the fix is as simple as it is, perhaps it's worth it >> >> just for the clean conscience? >> > >> > Fair enough. Patch to follow. >> > >> >> Thinking about it a bit more, I'm getting a bit more unsure: >> - The 78-limit is about user-interfaces, not protocol robustness. > > True. In theory we should also be limiting to avoid the 998-character > hard protocol limit, but that is getting ridiculously unlikely. I think that's over in my definition of "insanity land", yeah :) >> - Since send-email unwraps the line and does not re-wrap it, even if >> we have a name like this it's likely that the work gets undone right >> away. > > Not everybody uses send-email. So you are also helping MUAs which > consume the output of format-patch. Good point. > That being said, I doubt that this will make a difference to anybody. > The real reason that we put wrapping into add_rfc2047 was for subjects, > which _do_ get long. Absolutely. >> - So that means that send-email should probably also be fixed. But now >> I'm wondering if we've crossed the point where this will just lead to >> less obvious code for very little gain. > > It is ugly code. > > I'm just as happy if we drop it. OK, then I'll try to forget about this issue for now. Sorry for troubling you. >> > Because it means we have to _parse_ those >> > headers and understand which part is a name and which is an address. >> >> That part is surprisingly easy: If it contains a '<', then it's on the form >> "Foo Bar Baz <foo@xxxxxxx>". If not, it's "foo@xxxxxxx" (assuming it's >> UTF-8 encoded rfc5322 mailbox'es we assume, which would make the most >> sense to me) > > What about: > > "Foo \"The Bar\" Baz" <foo@xxxxxxxxxxx> > > or > > Foo "The Bar" Baz <foo@xxxxxxxxxxx> > > or > > Foo (The Bar) Baz <foo@xxxxxxxxxxx> > > I.e., are we taking rfc822-style addresses, or are we taking something > that looks vaguely like an email address, and just treating everything > left of "<" as literal? I was just thinking of interpreting everything left of '<' literally and encode it (if needed). Currently, we interpret the entire string literally, encoding the name would an improvement. -- 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