But this misses the point of header-set. The point is that you do NOT have
to repeat the image. If I can (please) take the liberty of changing that
"tiff" to "gif", the idea behind header-set is to allow you to express your
Well, this is all news to me. There isn't anything even resembling such a goal
in the header-set draft I have read. This appears to be a recent invention that
has been brought in to justify header-set now that it has failed demonstrate
any other advantages.
If the goal of header-set is to reduce the size of the data we have to transfer
around, then it needs to be reevaluated in that light. There are plenty of
other approaches (compression, external references, etc.) that reduce message
sizes. It is far from clear that header-set is the right solution, or even a
solution, to these problems.
As I see it, header-set has three advantages:
1. It eliminates the need to register a subtype of multipart for each
Let's see. For each header-set header, you have to register a type, right?
Where's the huge overhead involved in registering a subtype of multipart at the
same time? I see no overhead here at all!
I'm sorry, but this is nothing short of a complete red herring.
2. By making the first part alternative, you can associate several
different headers with one set of data, saving the multiple retransmission
of the data.
This quite clearly is not what header-set was designed to do. I am very
troubled to find that the stated goals of all this work seem to be completely
mutable over time. This is not good engineering. Either header-set stands on
the merits set forth in its documentation or that document needs to be
withdrawn and replaced with another document that does state what the goals
are. Once the goals are stated people can discuss them intelligently and
possibly propose useful alternatives.
3. The reader has a hint that the header part of the header-set is not the
essential data. (Though PEM makes me uneasy on this score.)
Every single header-set type currently under discussion makes me *very* uneasy
on this score. Doesn't this sound like a trend to you?
Now, requiring a "type=" parameter on the header-set header largely negates
advantage 1, in my view. Spade a spade, rose by any other name, etc, etc.
Simple question: Why? Let's say that we adopt the simplest possible header-set
mechanism with a parameter, where there's simply a list of the header types in
the outer multipart content-type. Does this present any problems to any
implementation? I cannot see how it does. Does this present any problems for
header registration? I sure don't see any. Does this present any problems in
any other areas? None that I'm aware of.
Forbidding an alternative for the header part and instead using an outer
alternative construct completely negates advantage 2.
Strawman argument here. Nobody ever suggested banning multipart/alternative for
headers. I simply suggested that it might not be appropriate for appledouble.
Advantage 3 is pretty minor and questionable.
I see them all as highly dubious.
So, if we accept Ned's restrictions on header-set, I'm not sure that
header-set does any good; we may as well just use multipart/foo. That
isn't a disaster as far as I'm concerned; I thought header-set was a nifty
idea, but I don't really mind having lots of multipart subtypes, either.
OK by me. I've yet to see anything but lots of pain and absolutely no gain in
all this header-set stuff.