Alas, ISO-10646 and ISO-2022 are less "character-sets" in the traditional
sense, as they are a character-set-registry-and-encoding standard.
What this means is that these two ISO standards say how to switch
the character sets (sometimes called pages). Alas, in order to
find this information you typically have to scan the entire document
to glean this information. It would be very useful to indicate,
at the top level of a body part, which actual character sets are
needed in order to display the document; this way the software can
tell if it can successfully translate (in the case of a gateway) or
display the document.
While I fully understand your reasoning, I think that it is equally,
if not more, important that the conformance section of any RFC that
talks about 2022, mandate certain character sets. Imagine the
frustration of the poor user who, upon noticing that the RFC mentions
Japanese in 2022, decides to use it, only to find that some supposedly
conformant gateway along the route unilaterally and cheerfully decides
that it is not going to support Japanese just because the RFC author
didn't write a tight conformance section.
And if the RFC is going to clearly specify which subsets, options, etc
(i.e. profile) of 2022 is mandated, there is no compelling reason to
indicate the character sets in the message header. Either you support
the named profile, or you don't conform to the RFC.
Standards should include very careful wording about the subsets and
options allowed, and the conformance criteria. If implementors are
allowed to choose arbitrary subsets, interoperability won't be
achieved.
Note that I'm not suggesting that we put Japanese in the conformance
section. I just used Japanese as an example.
Erik