Well, I've been convinced that there is ambiguity in RFC-XXXX, as
currently written, between a body part and an embedded message. And,
though I'm not convinced it is as bad an ambiguity as has been made out,
I'm certainly not opposed to fixing it. The question, then, is how to
fix it.
The only problem with saying "only part headers are allowed" is, as
Peter noted, the fact that we might want to augment the set of part
headers. Although I had been just about convinced by unrelated
arguments to make the cosmetic change from "Content-Encoding" and
"Content-Label" to "Trasport-Encoding" and "Description", another idea
comes to mind: we could say that "part headers" are the ones that start
with "Content-". Only "Content-XXX" fields are allowed in parts, as
opposed to encapsulated messages. I would have no problem with this
definition, which preserves a great deal of extensibility.
It does, however, suggest two alternatives regarding encapsulations.
One approach says that a "part" in a multipart message may be either a
part or an encapsulation, and the only way to tell the difference is to
see if there are any header fields that don't start with "Content-XXX".
The other says that a part MUST contain only part headers, and that an
encapsulation must look more like this:
Content-type: multipart; 1-s; foobar
--foobar
Content-type: encapsulated-message
From: blah, etc.
Content-type: whatever
...data...
--foobar
I must confess to being not entirely happy with either of these schemes.
The second scheme is uglier and potentially more confusing. The first
scheme implies that you may have to read all the way through a part's
headers before you know what type it really is. Neither of these makes
me entirely happy. Are there any better ideas, or (absent those)
compelling arguments for one or the other of these two? -- Nathaniel