similarly, I recommend against implementing automatic rfc 2047
decoding for parameters in general - partly because there's a small
chance that you'll misinterpret a parameter that way, partly because
it conflicts with standard usage, and partly because 2047 is a poor
mechanism for this purpose (which is why the standard doesn't use it).
I think the small chance that he really meant 'file it in a file with the
name "=?koi8-r?B?Q8/XxdQuZG9j?="' is a resonable risk to take.
However, I would like to know why 2047 is thought to be a "poor mechanism"
for this purpose (i.e. why was it not standardized that way - it seems to
work in a wide variety of situations).
partially because 2047 only tries to solve the problem for human-readable
text - and specifically not for text that needs to be compared with
anything other text by a computer. so it doesn't specify anything about
normalization or canonicalization or any of those other issues that
(for instance) the IDN folks have had to worry about. also, had this been
intended as a general encoding mechanism for paramters, there would have
been a strong incentive to specify a particular character encoding scheme.
but since 2047 was for human-readable text only, it seemed acceptable
to allow any charset to be used.
partially because 2047 imposes strict limitations on the lengths of
encoded-words, doesn't allow them to appear in quoted strings, and
contains characters which aren't legal in MIME parameters.
partially because there are a few things out there that unilaterally
translate all 2047 encodings in a message from one charset to another,
or that decode all 2047 encodings - and 2047 was explicitly designed to
permit the former. but while it might be reasonable to translate
human-readable text if you know the recipient can read the translated
version, it's not reasonable to translate parameters that aren't
intended for humans.
Keith