Re: Mime types and attached files

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <m3vet8o9ms.fsf@quimbies.gnus.org>
>>>>>	Lars Magne Ingebrigtsen wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> However, I must evaluate the form[1]
>>
>> (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)
>>
>> when sending files with Japanese names in business.  That's very
>> annoying, though I never want to make it the default (so, I
>> restore it into `rfc2231-encode-string' after sending a mail).

> Well -- why not make it the default?  We know that a large number of
> mail readers out there don't support RFC2231, and we know that most
> mail readers support RFC2047 parameter decoding.  (Are there any that
> don't?  I mean, that don't support RFC2047 parameter encoding, but do
> support RFC2231?)

The reasons I wouldn't like to make it the default are:

The RFC2047-like encoding has not been documented as a standard
as far as I know.  I don't know how it has been decided
reasonably and democratically.  The specification doesn't seem
to have been unified in mailers that use it.  For instance, I
heard that some mailer works with a parameter in which a long
encoded file name is folded but others don't.  Because of this,
I designed `rfc2047-encode-parameter' so as not to fold an
encoded file name no matter how it is long.  Therefore, it
potentially violates the rule that maximum length of lines is
restricted by some RFCs.

> So to make life easier for everybody I propose making
> `rfc2047-encode-parameter' the default.

I swim with the tide. ;-)  I wish it weren't an obstruction to
Thunderbird's lofty ambition, though.