<< Representation of Filenames in Message/External-body.
<<
<< The inclusion of filenames in the content-type headers has the effect of
<< requiring that all filenames be 7 bit ASCII. The Working Group discussed
<< the likelihood that new operating systems will require a richer character
<< set for filenames and possiblity that when this occurs the current
<< filename mechanism may not be adequate. ...
< "Likelihood"? "Possibility"? "When this occurs"?
<
< The Macintosh OS uses an 8 bit charactrer set for file names and disallows
< only the character colon (":"). I can even have embedded nulls or other
< weirdness in file names on my Macintosh.
<
< NT uses full 16 bit UNICODE for filenames, in case no one has noticed.
UNIX System V release 4 allows all 8 bit characters in its filenames, only
disallowing NUL and /. They've done this for the last 4 years.
Plan 9 (from AT&T research) uses 16-bit unicode everywhere, including
filenames. Yes, even the mail system uses unicode.
I'd say it's better to bite the bullet now and work out how to allow them.
Using the rfc 1342 mechanisms seems appropriate. The only problem that
occurs to me is the fact that many of these filenames don't necessarily have
any particular character set associated with them, so the use of an
"unknown" character set seems called for.
Content-Type: Message/External-body;
filename="=?unknown?Q?/usr/spool/xyz/ne=3d=3cfoo?"
for a filename of /usr/spool/xyz/neXXfoo where the XX are a couple of 8-bit
characters.
Comments? (Is this old news?)
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony