🚀 go-pugleaf

In article <C0LnHt.C9J@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>files via "binary" mode ftp transfer.  I would not consider it
>desirable to have an ftp that looked inside the bits it was moving
>around (personal opinion).

No, this is not appropriate for the File Transfer Protocol; however, it
may well be appropriate for a file transfer client.  I already have a
shell script around FTP that does "uncompress" and "tar -xf" if the name
ends in .tar or .Z; luckily, this is possible because people conventionally
use these filenames (the FTP does not provide any useful information).
An FTP client could similarly recognise MIME files, but nobody is going
to use filenames like

   myfile.MIME-Content-Type:application/foobar

so the information will have to be conveyed by some eyecatcher in the file.
Perhaps a filename  myfile.MIME  would indicate that the first few lines
of the file (until a blank line) were in fact "headers".

But even this is not enough - one has to say whether .MIME files are text
or binary.  If an EBCDIC machine FTPs a .MIME file in binary mode, it must
assume the headers are in ASCII.  And if an EBCDIC machine provides a .MIME
file for anonymous FTP, it must use ASCII for the headers even if the data
is readable (EBCDIC) text.  Alternatively, you could say that .MIME files
are readable text using BASE64 etc. if necessary.  Or have .MIMEB and .MIMET
files.  Why not put MIMEB and MIMET into FTP, along with ASCII, BINARY and
EBCDIC?

Similarly, one could argue about how to annotate files that are sent to
a print server (via LPR, not SMTP).  Why shouldn't print servers be MIME-
capable?  Some already automatically detect the difference between text
and PostScript based on the file starting '%!PS-Adobe'. How are they
supposed to detect MIME?