This would be a valid point if message/rfc822 were strictly aligned with
RFC822. But it isn't -- the name, which was chosen and implemented long
before the exact rules for the type were put in place, is misleading.
Message/rfc822 was specifically designed to allow for material that isn't
legal according to RFC822 (and, I suspect, DRUMS). Specifically, the
requirements for what headers have to be present are substantially relaxed,
as are the syntax rules.
I think this suggests a legitimate question about some sort of labeling
which notes that the content really is (honest to goodness) conformant
specifically with 822, or with netnews, or whatever. (822 variants, such
as an incomplete draft message, versus a fully 'received' one are useful
distinctions, too.)
I completely agree, which is why I suggested a parameter to message/rfc822
as the solution. We certainly do not want to define a flotilla of new
composite subtypes to cover all these cases.
Ned