What's ??? ? "file-with-info" (as distinguished from "pem" or something)?
Is that enough for you, Ned?
I suggest a comma-separated list of subtypes if there is an alternative
in the header-set's first body part. Otherwise we will have to register
new pseudo-subtypes for "file-with-info" and other such gadgets, which
I don't like because it brings the lookahead back: "is this a Mac or a
Windows 'file-with-info', or is it someone else's?".
Can your implementation solve this problem at all? I know you may want to
turn into macbinary to keep Mac All-In-One happy. But is there a Windows
version of All-In-One? Do you need to turn it into something else for
that? If so, how do you know which transformation to apply?
I can't comment on All-In-One (never used it). I will say that Windows does
have file header info in some cases. The one that comes to mind is OLE
(Object Linking and Embedding) files which have some header info (class
name, topic name, network machine name, and other stuff) and then the
data itself. If I was sending an OLE object via MIME, I'd want to split
the header info off so that non-Windows user agents can get at the raw data,
yet still be able to rebuild the OLE object in a Windows user agent so it
can be linked into an application on the recipient's machine.
So, header-set or some equivalent is looking very attractive to me.
It's also possible that some or all of the OLE header info could be
translated into the Mac AppleSingle information given a suitably smart
MIME user agent, so having the ability to do alternatives in the first
body part would be a plus.
Cheers,
Rhys.