file transfer in particular

        My own view on the whole matter of header sets and 
object|part attributes is tainted.   I have this tool, 
and a protocol to support it,  which sometimes falls back 
upon mail,  in which case "mail" must be MIME.   This tool is 
Internet SENDFILE and is described in RFC 1440. 
 
        Something completely vague in the RFC though central to 
the idea is that a  "meta file"  accompany the file being sent. 
This metafile is nothing more or less than a set of attributes 
describing the file and suggesting what exactly the recipient 
might want to do with it.   Now  "on the wire"  (over TCP) 
the metafile is embedded in the commands sent from client 
to server.   But what do you do when you fall back to mail? 
 
        For now,  when  'sendfile'  can't connect directly via IP, 
it punts to mail (MIME) using  Application/octet-stream.   The 
attributes listed in the metafile are overloaded on the  Content-
Type  header line.   It would be better (perhaps) if the metafile 
were sent as a separate part of  Content-Type: Application/sift. 
 
        I've been using  Application/octet-stream  because it was 
already defined.   I had hoped that one of these other schemes 
we've been discussing might do what I'm looking for,  but I 
don't see it.   So I'm tempted to pursue getting  Application/sift 
(or maybe Application/sendfile or Application/uft)  registered. 
 
        Thoughts? 
 
        Here's what it would look like: 
 
                ... other header lines ... 
                Content-Type: Application/sift; 
                                boundary=SIFTBOUNDARY 
                ... other header lines ... 
 
                --SIFTBOUNDARY 
                Content-Transfer-Encoding: ASCII 
 
                type=a 
                name=some.example.file 
                date=1993.11.01 01:30:00 
                --SIFTBOUNDARY 
                Content-Transfer-Encoding: ASCII 
 
                This then is the body (data) of the file. 
                In this particular case, 
                the file is  "Type A"  (plain text) 
                and happens to be sent as plain text. 
                Generally I prefer Base 64 for the body, 
                and plain text for the metafile, 
                which speaks all the more for registering 
                this mechanism as its own type so that it 
                would be known and users wouldn't get a 
                mixture of encoding AND get an "unknown" MIME object. 
                --SIFTBOUNDARY-- 
 
        The metafile looks (intentionally) like UNIX environment 
strings.   In the "on the wire" mode,  the equals sign is replaced 
with a blank space.   Maybe the MIME-ified flavour should look the same. 
 
        So ... the question is,  should I continue overloading 
Content-Type: Application/octet-stream; type=A; name=whatever, etc, 
or should  there be this two-part thing via multipart? 
 
-- 
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems