[Top] [All Lists]

RE: yet another way to indicate related MIME body parts

1993-10-26 01:04:05
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

    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

(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

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.


<Prev in Thread] Current Thread [Next in Thread>