Two issues of some importance seem to be providing continuing confusion,
impeding the ability to obtain closure on RFC XXXX. I'm going to assert
a fairly pointed opinion, about each of them, and request the the rest
of the working group respond on these assertions:
1. Header character set
There is a continuing attempt to make RFC XXXX specify changes in the
handling of RFC 822 headers, specifically with respect to support for
alternate character sets (and languages). I believe that there can be
no reasonable debate about the importance of enhancing the ability of
Internet EMail to support other character sets and languages, but I
must strongly assert RFC XXXX is exactly the WRONG vehicle for pursuing
this issue, with regard to RFC 822 headers.
For all intents and purposes, RFC XXXX has nothing to do with RFC 822,
except for the very, very, VERY specific purpose of enhancing the
definition of the message body (denoted in RFC 822 as the *text ending
to the bnf rule for message). The Content-* fields that RFC XXXX
defines are new headers, but do not in any way alter definitions in
822. Hence, pursuit of header interpretation, within RFC XXXX,
would constitute a change in the working group's agenda for XXXX.
A separate effort is required for making the desired changes to 822.
2. Body-part character set
Several schemes have been suggested, to have RFC XXXX support alternate
characters sets (and languages) within individual body-parts. This,
certainly, is a reasonable goal for XXXX, since it DOES pertain to the
body. And again, I think it would be silly to debate the importance of
finding a solution to this requirement. One must be found.
However, my own assessment of the continuing discussion is that there is
no clear, nor even a clearly strong, choice. The international
community has been pursuing this point for some years and does not yet seem
close to resolution. The discussions within the working group do not
seem, to me, to provide any additional, special insight into this
problem.
In my opinion, RFC XXXX MUST provide a mechanism for specifying
character sets, but it is NOT required that it specify more than one
use of that mechanism, though the mechanism MUST be extensible. That
is, I believe that XXXX has a technical requirement to provide a way of
specifying alternate character sets, and that it must provide a
definition for exactly one such character set use, while permitting
the mechanism to be used for specifying other character sets, WHICH
MAY BE DEFINED LATER.
If this sounds as if I am suggesting that we defer this topic, you are
correct. I do not see a way for RFC XXXX do to its job without defining
the specification mechanism, but it clearly IS possible to defer the
rest.
I recommend that that effort be pursued separately.
OK, folks, start with the feedback...
Dave