Nathaniel,
1. I'm not sure a new subtype of multipart is necessary -- what's the
advantage over just using multipart/mixed in this context?
If the body-part does not have any sort of distinctive label, than how
will any software know that it is to be processed as email control
information, rather than some other, arbitrary sort of body-part? The
reason for defining special labels, whether they are major Content-type,
minor subtypes, or parameters, is to give software something to look
for and interpret.
2. I'd prefer to keep the human-readable text OUT of the
application/delivery-status entity body. Why? Because if we leave it
there, it may never be seen by users whose MIME agents don't implement
that type. If we've got a multipart message anyway, why not put the
prose in a text/plain (or even text/richtext) entity? That might make
the results at least somewhat meaningful to a larger set of recipients.
We need to include the human text somewhere, since structured error
messages usually don't contain enough diagnostic information. Without
quibbling about the details of encoding, I'll repeat the above concern
that simply stashing the free text in a stray body part means that
there is no way to associate it in an unambiguous way with the control
information.
Dave