ietf-822
[Top] [All Lists]

Re: Content-Disposition Header and multipart/alternative

1993-06-30 06:53:56
Excerpts from mail: 29-Jun-93 Content-Disposition Header .. Rens
Troost(_at_)stimpys(_dot_)imsi (3133)

Nathaniel, you raised a point about the hidden disposition type being
difficult to deal with in linear (metamail-style) parsers. Isn't this
also a problem with multipart/alternative, in which the 'richest' of
the alternatives comes last? You have to scan all the alternatives
before falling back to the first, simple one.

Bang.  You got me.  I wasn't mentioning this because I didn't want to
complicate the discussion, but...

As it turns out, when I was first writing metamail, I had this  funny
feeling that I better code more carefully than usual; just an instinct,
I guess, that lots of people would see this code.  And I was actually
very happy with the way the code looked until one fateful day, about two
years ago, when someone on the list convinced me that the then-specified
order of multipart/alternative should be reversed, yielding the
"best-version-last" semantics we have now.

That change KILLED metamail's structural integrity.  I should have done
a completely rewrite at that point, but didn't have time.  If you look
through the metamail code for "SquirrelFile", you'll get an idea of how
bad it was -- SquirrelFile was added strictly to accomodate the
"best-version-last" semantics of multipart/alternative.  I still cringe
every time I look at it.  If we add the kind of semantics that have been
discussed for 'hidden', I would have to either make it much worse or
rewrite it completely enough to make it much better, and guess which one
I'm more likely to have time for....  

This has to be dealt with, it seems to me, whether you use
multipart/alternative or a hidden disposition.

Yeah, the one advantage is that people have already implemented or are
already implementing multipart/alternative, so "hidden" simply adds
complexity.....

That said, I'd be more than willing to jettison "hidden" in favor of a
reccommendation to use multipart/alternative in this manner. It's a
good clean solution to the problem; good call, Gabe!

Is this agreeable to y'all?

It is certainly extremely agreeable to me!  -- Nathaniel

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