If someone from the meeting can better articulate the reasons this
proposal was rejected, please jump in. I personally support the idea,
Greg, I think you got it exactly right. However, until other issues
are worked out, I contend this is a non-problem. Long tirade follows...
... so long as 7 bit filenames would be subject to a new
restriction that prevent the use of quoted-printable.
This restriction basically cannot be imposed. FTP is designed to
permit the use of the file naming conventions of any operating system
(see RFC1123, 126.96.36.199, which I'll come back to), and there is no
technical reason why we couldn't encounter systems out there for which
=3d=3cfoo are not perfectly canonical file name strings in their
explicit ASCII representation terms.
The rule would probably be tolerable if MIME external bodies were
just addressing MIME-specific repositories, but there will be many cases
in which they will address general FTP repositories on the relevant
hosts. While we could say "look, we've got 30+ years of experience with
operating systems and file systems, things are becoming more homogeneous
over time, and we haven't seen one of these yet, so maybe we can make a
good guess", that still turns into a heuristic in a place where we don't
There is, however, a more important issue. If I had an operating
system that was 8bit-native (file names and file contents) and,
especially if I had one that was 16-bit native, I'd be taking a very
hard look at FTP. The Type we usually use is called "ASCII", with
the same semantics we have been over and over with "US-ASCII" in MIME,
plus (explicitly) the NVT restrictions. 16 bit characters can't be
transmitted as "TYPE A" without encoding or some other sort of violence
to the notion that FTP clients and servers are expected to translate
between ASCII-on-the-wire and local forms. The best approximation for
16 bit characters (they are certainly something one doesn't want to
handle as "image" in a heterogeneous network presumably would be "TYPE L
16", but local type values other than 8 are not widely supported these
days and TYPE L really isn't a text type anyway. Note that
transmitting 16-bit characters as "Type I" leaves them vunerable to the
NUXI problem, which is not a nice thing to do to characters.
And then there is the matter of the ASCII/NVT restriction on the control
connection: no matter how you represent the file name in the MIME file,
it is not clear how you *transmit* a file name that contains 16-bit
characters (or even 8-bit ones-- see RFC1123, section 188.8.131.52, where the
usual/dreaded "ASCII" and "7bit" language appears).
The result of all of this is that, if I'm implementing FTP in a 16 (or
8) bit environment, I need to either go off and start organizing FTP
extensions or I need to define a presentation format for my file names
that presents them in 7-bit form. Maybe I *expect* to have
"=?unknown?Q?/usr/spool/xyz/ne=3d=3cfoo?" transmitted to me for local
decoding. Maybe this is where I really do want to use MNEM (please,
let's not start a discussion about that option). Maybe something else.
None of this solves the problem of how to transmit the data characters.
But the FTP client associated with the MIME reader better know,
unambiguously and for certain, whether it is expected to decode a
"filename" string or just transmit it.
I propose the following principles. They are convenient for two reasons:
(i) they don't require any heuristics or protocol-breaking modifications
to MIME and (ii) other ideas that have been proposed are inconsistent
with a narrow reading of RFC 959 and the supplemental material in 1123.
Putting stuff in MIME for FTP access to files that works only over
broken FTP clients and servers does not strike me as a good idea.
Rule 1: If Message/External-body is used with access-type=FTP or
ANON-FTP, the file name is expected to consist of ASCII characters and
is expected to be transmitted, exactly as it appears, from an FTP client
to an FTP server, presumably as part of a RETR command. The
interpretation of that name (as has always been the case with FTP) is up
to the server. In particular, it can be a presentation format that is
different from the format used within the remote file system or it can
embed UDLs or UDI for interpretation by that server. Who cares? The
person or machine producing the MIME file merely needs to know what the
repository wants to see and then put it in the right place.
Rule 2: For any cases in which Rule 1 is unreasonable (e.g., translation
of characters to 8 or 16 bit form has to be done in the MIME reader or
FTP client), a different access method is needed. Can't be done over
RFC 959 FTP, since the characters can't go over the control connection.
And I think it would be a real good idea for people to think through
what happens to the data stream before trying to define that access
type--it may be the harder problem.
Important conclusion: Other than possibly clarifying the principle that
the "Name" string is intended for uninterpreted transmission to the FTP
server, the MIME doc is not broken and does not need fixing.