I'm inclined to favor the Content-Disposition header over either a new
content-type parameter or a new {multipart,message}/attachments
content-type, especially if the new header is also used to provide filename
information.
I don't see how the NAME parameter to message/external-body causes a
problem. NAME is the name used to retrieve the file, not the name used to
store the file (presumably in the recipient's private directory).
There *is* a problem with the NAME parameter to application/octet-stream.
Perhaps RFC1341bis could simply discourage the use of this parameter, in
favor of a parameter of the new content-disposition header (even if that
header is defined elsewhere).
Keith