I disagree; multipart/foo is certainly easier for metamail than any of
these proposals, because you can do the top-level switching (decide what
application to run) while processing the enclosing multipart. This is
a big win for metamail, which wants to be able to do everything in one
pipe-like pass through a MIME message. This is not at all possible
with header-set. It is closer to possible with multipart/related,
though it would be better if the actual content-type were visible at the
enclosing level.
I agree most emphatically with Nathaniel here. In fact, I will go further and
state that I find all of these proposals to be contrary to what I see as the
MIME philosophy, anwhere from excruciatingly difficult to completely impossible
to implement, and providing no tangible advantage for any proposed multipart
object I have seen thus far.
The issue here for me is extremely simple. I need to know what sort of
multipart entity I'm dealing with at the point where I encounter it. I don't
want to have to wade through the entire thing looking for some random part and
then have to take that part apart to figure out what I'm supposed to do with
the whole collection. This is totally unacceptable to me.
Let me deal with my points here one by one:
(a) Contrary to the MIME philosophy.
The MIME approach is structurally very similar to a textual document: we
announce one or more somethings and then they appear. This similarity is
quite deliberate. In the case of documents, it make them easier for people
to read. It also makes MIME objects easier for people to figure out, both
manually and in the code they write. The resulting software is both simpler
and easier to maintain.
There is only one exception to this in all of MIME: multipart/alternative
part ordering. This one exception was made as a sop to the installed base,
and the jury is definitely still out on it. It was felt that the benefits
to the installed base outweighed the complexity it induces in user agents.
(Note that this penalty is pretty much limited to user agents and is
not shared by other sorts of MIME-ware. Note also that if we're to cater
to the installed base again we should summarily reject both of these
proposals right now.)
Now let's consider this proposal in the context of a text document, as I
have always done with all other MIME entities. It is like having a section
head that says "I don't know what this is, see subsection twenty to find
out what this stuff means". What would you say about a text document that
contained such a thing?
(b) Difficult/impossible to implement.
A simple real-world example will suffice to illustrate this. Let's suppose
that multipart/appledouble gets implemented as multipart/related. I happen
to have a gateway that needs to convert multipart/appledouble into
MacBinary format. Most other multipart/related parts need to stay in
their original text form.
Keith has already described how multipart/related pretty much has to be
implemented: I now have to write each part into a buffer (my buffering is
done in memory with file fallback since disk files are way too much
overhead). Only once I'm irretrievably committed to disassembly do I know
whether or not I've done the right thing. (The fact that
multipart/header-set always uses the first part for labelling is no help
since I can neither back out my decision to disassemble nor back up my
input stream without a lot of extra structure-breaking code.) If I haven't
done the right thing I now have to reassemble the part. Doing so
effectively doubles the amount of code involved. I call this excruciating,
especially when a single parameter in the right place would make it
unnecessary.
Now, as to flatly impossible. Steve Dorner points out that this whole
thing causes real problems on low-end systems. He's absolutely right, but
that's not my problem. My concern is what this does to high-performance
gateways. The gateway I've been talking about has to be able to handle
average throughputs of 20,000 messages a day. (One message every 4 seconds
or thereabouts average, but it isn't evenly distributed throughout the
day.) Most sites running serious gateways simply don't have the resources
to blow on doubling message processing overhead.
Of course not every message is going to be multipart/related. In fact,
very few will be to begin with. But high-performance gateways like these
always operate just below the knee of a curve. Up the overhead and you may
receive more messages than you can send. This messages than it can send.
The resulting backlogs can push you past the knee into nonlinear
performance. (This is usually, but not always, filesystem-related.) The
backlogs can then grow exponentially. (You know you're headed for trouble
if you're building up a backlog during the day that only clears at night.
When you're "flirting with the knee" like this you need to start watching
very closely, because if it ever wraps around into the next day your system
may well melt down completely.) To the extent that multipart/related
throws a considerable degree of unpredictability into the overall process,
it is a Very Bad Thing indeed.
There is no way I can provide these gateways with a useful means to deal
with the present multipart/related proposal. The constraints are just too
tight.
(c) No tangible benefit.
This is simple. There isn't a single multipart proposal I'm aware of that
employs any of the sophisticated stuff multipart/related has to offer.
(Maybe the SGML one does, but I haven't read that one yet. The two major
proposals I see being affected are multipart/appledouble and
multipart/pem.) It is also far from clear that the mechanisms
provided by multipart/related are going to be the right fit to future
multipart objects that *do* contain references. The issues of how this
integrates into the equivalent X.400 mechanism (yes Virginia, there is
one in X.400 -- I'll leave the exercise of finding it to the reader) hasn't
been dealt with either.
Nor does multipart/header-set offer any advantage over simply defining
multipart/whatever. I'm sorry, but the added semantics of "these things
are related somehow" don't impress either me or the gateways I write. I
don't know how to deal with such nebulous semantics meaningfully. I have
to have specific information. And existing software is going to treat either
one of these as multipart/mixed anyhow, as the MIME specification mandates!
Actually, the more I think about it, the more I realize that "start"
doesn't buy me much. What I really want in the outer level is the
content-type of the "main" inner piece, but I realize it would be a poor
idea to include this information twice (because of the opportunity for
inconsistency).
I disagree that this implies duplication of information. There's nothing that
says that the "subtype" of multipart object either can or should be in 1-1
correspondence with the type information of the header part. As a matter of
fact, both multipart/pem and multipart/appledouble already violate this rule.
The former allows application/pem-header to appear outside of a multipart
structure and the latter uses application/applefile for both standalone
AppleSingle and as the identifing part of application/appledouble.
I take the fact that the first two multipart objects with related parts we've
dealt with both violate the supposed 1-1 relationship as a sure sign of things
to come. I suspect it won't be long before someone comes up with a single
multipart/related structure that admits multiple identifying header part types.
Geez, if we're going to have a generic thing like multipart/related, it
should at least be able to specify this sort of behavior. How about a
parameter, something like
multipart/related; displaypiecesifmainunrecognized={yes,no}
This simply adds insult to injury. Now I have a parameter on the outer
container whose meaning cannot be determined until I look inside the object.
This just further illustrates how lopsided these things are.
Folks, both of the present proposals in their present form are bad news. I
think they should both be dumped in favor of multipart/whatever. And if we must
have them, then for heaven's sake let's put the information about what type of
grouped object we're dealing with where it belongs, if not in the subtype then
at least in a parameter. Failure to do so is a complete showstopper for me.
Ned