To deal only with the matter of "header" position and reference --
ignoring various other features under discussion -- I'd like to
ask the list for some feedback on the following point of
distinction:
I'm afraid I see this as an attempt to finesse away the important issues.
You're trying to first make a header position choice and then show how this
lessens the burden and hence is marginally more acceptable. I see all these
issues as tightly intertwined. They cannot be dealt with separately.
Is it acceptable to require that the 'header' body part be at
the beginning
No. The only acceptable compromise as far as I'm concerned is to label the
object for what it is in the multipart header itself. I would much prefer to
simply use multipart/whatever, since I have yet to find any advantage to
multipart/header-set, but I can live with "multipart/header-set;
subtype=whatever" or "multpart/related; subtype=whatever".
or is there particular benefit in letting it be
anywhere in the multipart set?
The multipart/alternative positioning choice springs to mind as one
possibility. On the other hand, these objects are now so complex I think that
worrying about their appearance on non-MIME systems is no longer an issue.
Other than this, I see some benefit to having the header first in terms of
implementation. (It helps when writing multipart/appledouble and when reading
multipart/pem, for example.)
To carry the question a bit further: How onerous is it to have to
look ahead a couple of lines, versus an arbitrary amount? We have
several comments that are unhappy with arbitrary and one that is
very unhappy with ANY look-ahead.
Couple of lines? It can be thousands, you know. It is often 20 or more now, and
I expect it to grow significantly in the future.
The lookahead issue is really secondary, however. This whole thing is *UGLY*. I
don't want to have to read ahead to find out something I should have been told
right away. It dirties up my code, making it harder to understand and much more
difficult to maintain. And I especially don't want to have to do it when I
don't see where I accrue even the tiniest of benefits from all this.
My own leanings: Implementation and performance efficiencies are
important. If look-ahead -- even for a few lines, but into the
"next" body part -- is onerous, then we should not do it.
It is terribly, terribly onerous.
I continue
to believe we should have a generic multipart construct. This is
probably a matter of philosophy rather than compelling, technical
requirement. I think it would be cleaner not to have to register
a multipart name for every tailored use of multipart, when there is
also at least one other content-type being registered.
I have yet to hear any compelling reasons to have such a thing, philosophical
or otherwise. On the other hand, I also have no real problem with this proposal
as long as you add the parameter I need.
Hence, I'm leaning towards suggesting that the header-set (or
equivalent) spec call for the generic, encapsulating multipart
to have a parameter that names the content-type of the 'header',
replicating the value put into the content-type for that other
body part, and to specify a content-id to distinguish which of
the body parts to treat as the header.
Perhaps in most cases the header parameter will be the same as the inner
header's content type, but I don't necessarily see why this needs to be a
requirement. There may be cases where a given multipart construct can have
different sorts of headers.
Ned