Me:
I'd like to wire just enough support for archives into RFC-XXXX so that I
can be almost sure that if I send 100 files in 7 subdirectories as one
(nested) multipart/archive message, the recipient (using an RFC-XXXX
compatible UA) needn't issue 100 save commands or type in 100 file names,
nor escape from the UA to create the subdirectories -- otherwise it'd be
friendlier to use shar, which presumes UNIX and doesn't have transport
encodings.
Nathaniel:
I think this is already there, using the binary type, although it is a
UA decision whether or not there's a way for the user to avoid saying
"yes" 100 times. (In my current implementation, with your example, the
only problem is that the user has to say "yes" 100 times.)
The user has to say yes 100 times because there is no hint in the RFC
that this type of usage is common enough to support in the UA. This
is what type multipart/archive tries to prevent.
And what convention do you use to invent a file name? And to invent a
subdirectory name, if a part is a nested multipart archive? Also,
your use of content-type binary defeats the guessing of file options
such as blocking factor or CR/LF translation based upon content-type.
--Guido van Rossum, CWI, Amsterdam <guido(_at_)cwi(_dot_)nl>
"That was never five minutes just now!"
"I'm afraid it was."
----- End Included Message -----