Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters

[Ralph Corderoy]

Hi Ken,

> I don't think you're understanding the problem.  There are no invalid
> octets here; the issue is whether or not we perform an automatic
> decode.

But now Lyndon's brought it up,

    Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
    Content-Disposition: attachment; filename*=UTF-8''%41%00%42

`mhstore -auto' creates `./A'.  Perhaps the RFCs rule out %00?  But then
again, we're talking about crap that doesn't follow the RFCs.  If it's
%41%2F%42 then `A/B' is created if A exists, so that seems OK.

BTW, file(1) might be happy with inode/x-empty, and nmh stores an empty
file, but I wonder if other systems complain they don't know what to do?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy