Erik M. van der Poel writes:
Why multipart/appledouble? What if Microsoft also comes out with a
two-part structure? Do we call it multipart/ms-double? How about
calling it multipart/double, or simply multipart/mixed?
You have to call it multipart/appledouble to be able to
identify that what comes is not to arbitrary multipart parts,
but a file in a format which have two byte streams.
My impression is that Microsoft in this case should call
a two-part structure multipart/ms-double.
You refer to RFC 1341 for the file name parameter, but perhaps you
actually mean RFC 1342? Is it easy to implement such a parameter for
Mac file names? I got the impression that Mac file names sometimes
just use the 8th bit without saying which "font" it's in. Or do they
sometimes also include font tags? And how does all this fit into RFC
1342's way of doing things?
I refered to 1341 and mean 1341, not 1342, even though your idea
of incorporating teh ideas of 1342 into the filename parameter.
There is no information in the filename itself about what font
is used on the Macintosh. But, there is information in the
finder info structure (together with dates etc) that tell
what "scripting" system is used when writing the filename.
You can then check what font can be used with that scripting system
and get the correct filename. Unfortunately Apple themselves is not
using these opportunities themselves in the Finder (hi Apple, this
is something I really want!).
But, I can't see that this has to do with the MacMIME. It's a
problem MIME has with the "name" parameter which is accepted
in most content types. One should use the sam type of encoding
of the filename in MacMIME as you should do when sending a
file from UNIX which support 8-bit characters in filenames.
This is an issue which is yet unsolved in the MIME spec I think.
Since the Mac world doesn't want to destroy the interoperability that
it has already built up with BinHex, it's very sensible to incorporate
it in your spec. On the other hand, you're recommending Apple Double
so that non-Mac platforms can extract e.g. image/gif body parts.
Would there be any need to extract even more info, such as the
timestamp of the file?
No. We have been thinking about extracting the hexadecimal codes
used on the Macintosh to tag creator and filetype, but I'm convinced
that a program which want to real filename, the real date stamps, the
real creator etc, have to extract those date from the AppleSingle
file or from the AppleDouble header. So, the name parameter should
only be used as a help for the reciever to identify the file until
he/she is able to extract the file and thereby find the real name.
paf