ietf-822
[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
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

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