Keith Moore writes:
If we get into specifying filenames, should we also specify ownership?
File type (fixed/variable length, carraige control, record size)?
Permissions? How do we ensure that the filenames are portable to
all of the systems that might want to use RFC XXXX? How much "archive"
support do we want to wire into RFC XXXX?
Apart from the filename, there should be a default for everything
(possibly based on the filename and content-type!), and an extensible way
to override the defaults. Systems that have peculiar needs can put
options in that are ignored by most systems without such needs, but that
help for similar systems. For example, there are unshar programs for
MS-DOS and arc/zoo programs for UNIX that solve the problems of name
translation (although a hint about what a portable file name is would be
fine -- POSIX 1003.1 specifies one).
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.
RFC XXXX defines a convenient way to ship around application-specific
binary data over email. An application that packaged up multiple files in
RFC XXXX body parts would be very useful, but it should be defined
separately.
I expect that manu more people mail each other bunches of source files,
which would greatly benefit from multipart/archive, than arbitrary binary
data (not counting sound and images).
But I agree that in the end RFC-XXXX is already too loaded with features,
and maybe multipart/archive can be worked out as a separate RFC. Any
volunteers to help me write it (I'm totally new in this RFC business).
--Guido van Rossum, CWI, Amsterdam <guido(_at_)cwi(_dot_)nl>
"The life of a Repo Man is always intense"