Ned, I'm having trouble understanding the difference in how your
implementation would treat multipart/header-set vs. multipart/foo,
and why the latter is significantly less complex than the former.
In one case, you would see:
------
content-type: multipart/header-set; boundary=xyzzy
--xyzzy
content-type: application/foo
...
------
... and in the second case, you would see:
------
content-type: multipart/foo; boundary=xyzzy
--xyzzy
content-type: application/foo
...
------
Right?
Is the problem just that the MIME parser is already trying to process the
inner body part without knowing what it's going to have to do with the rest
of the multipart body? (maybe a concrete example would help)
In a metamail-like environment, it appears that multipart/foo puts a big
burden on the programs that must interpret such body parts, because they have
to be able to parse multipart MIME messages. A generalized multipart/related
type lets the mail reader deal with parsing the message structure (as long as
all of the components of a message are non-composite MIME types), and just
pass the primitive parts to sub-programs. (of course, they can still process
them internally if they wish for reasons of efficiency).
What I think I hear you saying is that this imposes too much of a burden in
your environment, where you have to translate the message into some other
form on-the-fly. (do I grok?)
If that's the case, maybe the idea of having a "type" parameter for the
generalized multipart/related bodypart isn't such a bad idea, since it lets
both the metamail-style program, and the on-the-fly translator function
efficiently. (If the type parameter doesn't match the content-type,
gee...the message must be garbled!)
Keith