Have you considered to have a special section of RFC-XXXX
specifying the "general" parameters (or attributes) that are
applicable to more than one content-type with the same semantics
and therefore should have the same parameter name for these
types and not be overloaded for other types?
There is one clear example of such a parameter, Charset
(mandatory for Text and optional for other types). I
would also suggest that the following parameters could be
treated as general parameters as well:
-- File-Name (optional for all types). Was called "Name" for
type Binary in the October draft, and "Filename" for
Application/External-Reference. The recipient may be
interested in storing not only these but also Text
and Image body (parts) in external files and the sender may
be able to suggest a good file name.
-- Original-File-Date (optional for all types): This
information, provided by the sender, may be very useful if
you get different versions of the "same" file or has got
it from several different sources.
-- File-Type (optional for Text and Application): This did
exist in the October draft under the name "Type" as a
parameter for Binary. The kind of information I think could
be given here is a short label corresponding to the "type" of
a file that in old-fashioned operating systems like TOPS-10
and MSDOS used to be indicated by the three characters after
the point in the file name, e.g. Fortran source program, help
information file, initialization file, .LZH archive file.
-- Language (optional for Text and Audio): Indicates one or
more natural languages used in a text or audio message, by
means of ISO-standardized language identifiers. Keld
Simonsen has told me that something like this has been
discussed and rejected earlier. If the issue is not closed,
I can provide some arguments for this being useful
information to provide in program-parsable form in some
cases.