At 4:09 PM 10/27/93 -0700, Ned Freed wrote:
Yes indeed. That's why a packaging more along the lines of
multipart/alternative
multipart/header-set; type=appledouble
application/applefile
image/gif
image/tiff
would be what I'd expect in this case.
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
example like:
multipart/header-set; type=appledouble
application/applefile
image/gif
The image is transmitted only once.
Or, to return to my original example, we have:
mp/h-s; t=applefile,windows-info multipart/alternative
mp/alternative mp/appledouble
application/applefile vs application/applefile
application/windows-info image/gif
image/gif mp/windowsdouble
application/windows-info
image/gif
As I see it, header-set has three advantages:
1. It eliminates the need to register a subtype of multipart for each
multipart thing.
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.
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.)
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.
Forbidding an alternative for the header part and instead using an outer
alternative construct completely negates advantage 2.
Advantage 3 is pretty minor and questionable.
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.
--
Steve Dorner, Qualcomm Inc.
Sometimes it's easier to let your cockatoo eat your shoes
than to hear him scream.