The more correct answer here is to allow RFC2047 header-encoding to be used
in the 'dstring' field. This way, other encoding systems besides UTF8
can be used if desired.
Close but not quite. The main problem with using pure RFC2047 parameter values
is that equals signs are involved, and the quoting that results gets really
messy.
Another problem is that we really don't want to allow more than one character
set in a single value.
So what we ended up with is a mechanism that reuses only parts of RFC2047.
This works, and in fact works well.
Unfortunately, it's past 4AM local time and I can't remember why we didn't
allow the 2047-style encoding in the first place. Somebody else here
remember why we did that?
Because we could never reach agreement on how, given a filename from a local
system, to accurately map it into and out of a legal filename parameter value.
Think about message/external-body, an FTP server that does localization based
on client origin, and the name= parameter in this case, and you'll see what I'm
talking about.
It was only by avoiding this issue entirely that we were able to come up
with an acceptable approach. Pity we didn't realize this five years ago,
but there you are...
Ned