From: Philip Oakley <philipoakley@iee.org>
Date: Sun, 07 Dec 2014 15:34:00 GMT
Subject: Re: [PATCH v2 2/2] send-email: handle adjacent RFC 2047-encoded words properly
Message-ID: <316EF32F3157400882911A84EA0CFC61@PhilipOakley>
In-Reply-To: <op.xqh5hrafnngjn5@freezie>

From: "Роман Донченко" <dpb@corrigendum.ru>
> 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