OK, we already have a tiny MIME builder in libcurl: this is limited to
form-data construction
 
Although not a "1st level protocol" (just above TCP), I think MIME is a
very important protocol: it is used in HTTP input: form-data, but also
some more complex forms like SOAP input; in HTTP output (SOAP results)
and SMTP input (Yes, I know: we do not have SMTP yet !!!).
 
That's why I'm attempting to write a MIME handler. If you agree, my goal
is to include it in libcurl. This inclusion offers the following
benefits compared to a separate package:
 
_ MIME-related code can use libcurl internal procedures and structures
_ It can offer additional support to the above mentionned protocols
within libcurl
_ As a superset, it can be used as a substitution to the current formadd
code

These considerations lead me to write the MIME handler in the "libcurl
style": please find my proposal in attachment.
This is a work in progress and far from being finished: I would be
interested in your opinion about it before continuing this way.

After applying the patch against CVS, you will find new man files:
docs/libcurl/curl_mime_* and curl_cid_*.

You will also find a lib/test.c program that I link with the library to
test the MIME code (this is not intended to stay in this directory !).
You can play with, to evaluate the MIME code.

The new procedures allow to build a MIME structure (multipart tree), to
generate MIME text from the structure and to parse MIME input into a
tree structure. Each tree node in the structure is handled as a single
entity, can have its data in memory, in a file or consumed/generated by
a callback procedure. There is no limit on the multipart nesting level.
Content-transfer-encoding can be processed "on-the-fly". There is also
some support for mid/cid URI referencing.

Things that are not yet implemented:
_ content-transfer-encoding in parser (this is OK in generation).
_ True integration in libcurl, like formadd substitution, new "easy"
option(s) for input parsing and output generation, declaration in
curl.h, etc.

Caveats:
_ cannot have a nul byte in a name, because curl_slist does not support
nuls embedded in strings...

I know it adds a lot of entry points, definitions, etc. but it is the
cleanest way I've thought to implement it.

Please tell me your impressions, remarks, questions, gripes, etc. Thanks
in advance for your interest.
Patrick