One of the suggested benefits of header-set is to allow alternative headers
for data without having to repeat the data. If Ned wants a parameter that
tells him what "sort" of header-set it is, and you specify alternative
headers, THEN what?
The parameter gives me the broad outlines of what the collective data
represent.
multipart/header-set; type=???
multipart/alternative
application/applefile
application/windows-info
image/gif
I don't see this as a viable use of this concept. Something like
multipart/header-set; type=appledouble
multipart/alternative
application/applefile
application/altnertive-packaging-of-apple-file-information
image/gif
would be as close as I can come to a use of multipart in the appledouble case.
What's ??? ? "file-with-info" (as distinguished from "pem" or something)?
Is that enough for you, Ned?
Nope. It isn't enough. I require that the multipart type identify what's going
on before I have to process the first part. Nothing less is acceptable to me.
Can your implementation solve this problem at all? I know you may want to
turn into macbinary to keep Mac All-In-One happy.
The ALL-IN-1 example is just an example. It isn't even a very important
example. I have dozens of other gateway components to think about here besides
ALL-IN-1, and frankly appledouble is the least of my worries when it comes to
gateway considerations. The other uses of header-set worry me a heck of a lot
more.
But is there a Windows version of All-In-One?
As a matter of fact there is -- sort of.
Do you need to turn it into something else for that?
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.
If so, how do you know which transformation to apply?
Either I'm told by a configuration file what to do or I have to do all of
them. In either case I want to know what's going in the structure before
I have to commit to any single approach.
Ned