In message <2E8AD45E@MSMAIL.INDY.TCE.COM>, Fisher Mark writes:>>2. Define "Content-Type: multipart/file; name=X" where X is the suggested >filename for that part. Agents (mail user agents, WWW browsers, etc.) are >free to rename the file as they deem fit or to reject filenames if they >violate filesystem access permissions (like "Content-Type: multipart/file; >name=/etc/passwd");>>3. Allow the "Content-Type:" header to occur when a "Packet:" occurs;

This is mixing methaphors. For one thing, you can't call it
multipart/* without using the multipart syntax, including
boundaries. And you can't stick any content-transfer-encoding except
7bit inside multipart/*. The MIME spec frowns on complex encodings
(e.g. base64 wrapped up in base64).

Did you see my proposal for aggregate/mixed etc? This allows
the features you're after.

>4. Force a blank line:> printf("%c%c", CR, LF);>between these headers and the packet contents; and

Blech. Parsing of packets is supposed to be quick and dirty.
Don't muck it up with header/body parsing.

>The resulting data would look like this for two files, each with one line of >text terminated by a CR-LF pair:>> Content-Transfer-Encoding: packet> Content-Type: multipart/file; name="capital.txt"> Packet: 28>> ABCDEFGHIJKLMNOPQRSTUVWXYZ> Content-Transfer-Encoding: packet> Content-Type: multipart/file; name="lower.txt"> Packet: 28

Your Packet: header is exactly the Content-Length: header in sheep's
clothing! You're back to the old problem of having to know how big the
body is before you write the headers of the body part.