[Top] [All Lists]

Re: Re[2]: yet another way to indicate related MIME body parts

1993-10-26 08:16:13
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

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.  



<Prev in Thread] Current Thread [Next in Thread>