Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Dec 7, 2014, 15:34 UTC
- Message-ID
- <316EF32F3157400882911A84EA0CFC61@PhilipOakley>
- In-Reply-To
- <op.xqh5hrafnngjn5@freezie>
From: "Роман Донченко" <dpb@corrigendum.ru>
Show 37 quoted lines
> Jeff King <peff@peff.net> писал в своём письме Sun, 07 Dec 2014 > 12:18:59 +0300: > >> On Sat, Dec 06, 2014 at 10:36:23PM +0300, Роман Донченко wrote: >> >>> The RFC says that they are to be concatenated after decoding (i.e. >>> the >>> intervening whitespace is ignored). >> >> Thanks. Both patches look good to me, and I'd be happy to have them >> applied as-is. I wrote a few comments below, but in all cases I think >> I >> convinced myself that what you wrote is best. > > I had the same concerns myself, and eventually convinced myself of the > same. :-) > >> One final note on this bit of code: if there are multiple encoded >> words, >> we grab the $charset from the final encoded word, and never report >> the >> earlier charsets. Technically they do not all have to be the same >> (rfc2047 even has an example where they are not). I think we can >> dismiss >> this, though, as: >> >> 1. It was like this before your patches (we might have seen >> multiple >> non-adjacent encoded words; you're just handling adjacent ones), >> and nobody has complained. >> >> 2. Using two separate encodings in the same header is sufficiently >> ridiculous that I can live with us not handling it properly. > > Yeah, that bugs me as well. But I think handling multiple encodings > would require substantial reworking of the code, so I chickened out > (with the same excuses :-)).
Would that be worth a terse comment in the documentation change part of the patch? "Multiple (RFC2047) encodings are not supported.", or would that be bike shed noise.
Philip