I agree with Greg Vaudreuil's mail on this subject. There is no
compatibility problem with earlier versions of content-type:
message/external-body interpreters, because before there was no way to
express 8-bit filenames at all and so such beasts could not be sent. Once a
mechanism is defined, such names COULD be sent out and it's then a matter of
whether upgraded servers will recognize the new features where nothing could
be done before.
Greg's statement that "names which could be expressed in 7-bit form must be
expressed in 7-bit form" is necessary for this to work, because otherwise
the encodings could break otherwise okay filenames for older servers.
I disagree with one statement that Greg makes saying that "mail servers
don't currently support 8-bit filenames and that those names are only
applicible when using local or distributed filesystem types." It's true that
no such mail servers exist that can be used across normal 7-bit smtp links,
because there's no way they can receive an 8-bit name, but that doesn't
preclude such mail servers from working in 8-bit clean enclaves.
Of particular note, though, an external body reference to a >>local-file<<
NEEDS some form of 8-bit capability to be used on a system that supports
such file names. Such names are irrelevant outside of the system to which
the file is local, so issues of ftp'ability or mail-server'ability are moot.
Currently, you either have to illegally send 8-bits for the filenames
anyways, or forget about it.
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony