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.
...
Right?
Yes.
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)
Well, I gave a concrete example in my original message.
There are several ways to deal with a MIME multipart structure. One is to open
up a new context in the message being created (if nested structures are
supported) and fit the parts into this new structure. Another is to leave the
entire multipart alone and encapsulate it inside of a labelled MIME object. A
third way to deal with it is to process the collection of parts in some way to
produce an appropriate aggregate in the target environment. (Obviously, there
are a large number of subcases under this one.) I already see separate
instances of multipart/header-set that will correspond to each of these
processing options.
My goal here is very very simple. I want to know which one of these I need to
do when I first encounter the multipart structure. In order to do this I need
to know what sort of header-set I am dealing with. If I don't know which one I
have to assume the worst when I get to the multipart boundary. I have to
preserve all the content- headers for the outer part. I should probably
preserve the preamble as well. If the first part is itself a multipart I must
recurse, looking through the resulting alternate headers to see which one makes
the most sense for me. And I still cannot have committed to any sort of
processing at this point.
I certainly can implement all this. I can buffer up and reread all this stuff,
in most cases preserving information I will never need. But why should I? What
is gained by omitting essential labelling information from the place where it
makes the most sense to have it?
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.
I disagree. multipart/foo is either recognized, in which case it is handled by
an appropriate handler that knows what to do, or it isn't, in which case it is
treated as multipart/mixed. In either case the decision is easily made based on
the existing mailcap facility. The appropriate handler can easily do whatever
it needs to do to the inner parts.
Using a header-set parameter to convey the subsubtype of header-set is only
marginally less convenient, since it requires some modification to the mailcap
format (or a separate file, perhaps). But the hand-off to the proper processor
can be done before any of the parts are read.
But multipart/header-set with no additional information requires that the first
part be read, possibly recursing to handle nested parts, possibly resolving
external references, before the proper handling program can even be determined.
And let's suppose that after we have the subsubtype information we decide to
use our regular handler for multipart/parallel or multipart/mixed. But we
cannot do that since the first part has already been shuttled off to some
separate location. So now let's crank through the code and add another squirrel
file (maybe we'll call this one a rabbit file, for variety) to handle this
special case. Yuck!
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).
Right.
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?)
You do.
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!)
As I've said previously, I'm far from sure that this is duplicate information.
Our extant header-set headers can and do function outside of header-set
objects. It is only a matter of time before we come up either some kind of
multipart object that admits two different headers or a header that services
two different subtypes of multipart. (The more I think about this last point
the more I think we'll be crying into our beverages later if we do this wrong.)
Ned