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:
Is it acceptable to require that the 'header' body part be at
the beginning or is there particular benefit in letting it be
anywhere in the multipart set?
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.
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. 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.
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.
This is substantially more complicated than I had originally wanted,
but the concern for operational efficiency is serious.
Comments?
Dave