I have been discussing with Keld in off-list mail some concerns that
I have with the current drafts of RFC-CHAR and RFC-MNEM. While some
editorial issues have been resolved, there are several places where
Keld and I perceive things differently.
In the interest of a better set of Internet Mail RFCs, I'm appending
my concerns below for everyone's consideration. I'd like to hear what
others think about the RFCs as well -- either in off-list mail or via
the list. I think that this is the right list because these two RFCs
directly impact the work done on RFC-XXXX.
1) I think that the current STATUS OF MEMO section in the draft
for RFC-MNEM is not well phrased and could lead to undesirable
confusion among the readers of the memo. I propose the following
changes to clarify the scope and purpose of the proposed RFC.
REMOVE:
"This supplements the set defined in [1], and in RFC-XXXX [2] where
the format specified in this memo is known as Text/Quoted-Readable."
ADD:
"This RFC specifies character set conversions between a User Agent
and its Mail Transfer Agent. The reference to character sets here is
not intended to encourage the use of unrecommended character sets in
Internet mail. RFC-XXXX defines which character sets are standard
in Internet mail, the names used for those character sets in Internet
mail headers, and the definition of the headers and body for Internet
mail messages. RFC-XXXX also makes the Internet Assigned Numbers
Authority responsible for any additions to the recommended character
sets and their names."
"This supplements the set defined in [1], and specifies the format
referred to as Text/Quoted-Readable in RFC-XXXX. In all cases where
this quoted-readable format is used in Internet mail, messages using
this format must be RFC-XXXX compliant."
2) RFC-CHAR refers to the ISO/ECMA registered version of ASCII which
is reportedly not identical with the current definition of ASCII
(ANSI X3.4). The Internet standards require ANSI X3.4 rather than
the ISO/ECMA version. RFC-CHAR should be modified to use ANSI X3.4
as the reference and conform to X3.4 in its table of characters.
To do otherwise creates needless incompatibility with existing
conforming implementations. RFC-XXXX has already settled this
issue in favor of being 100% backwards compatible with existing
conforming implementations.
3) The phrase "communication character set" is unclear.
It would be clearer if changed to read "mail transport character
set". This would also help make RFC-MNEM more consistent
with current UA/MTA terminology.
4) The example header refers to "ISO_8859-1" while RFC-XXXX uses
"ISO-8859-1". RFC-MNEM should change to use the format and
syntax specified in RFC-XXXX.
5) RFC-CHAR should make very explicit that it is not specifying the
character sets or character set names for use in Internet mail.
The current wording will cause confusion amongst the readers.
The IETF working group has reached a consensus that the
proliferation of character sets is undesirable and RFC-XXXX has
specified a small well-chosen set of character sets to be used
in standard Internet mail.
RFC-XXXX also requires that the existing standard "X-something"
format be used for those character sets defined by local agreement
and that the IANA is the sole authority for adding all other charset
names to Internet standard status.
6) It would be desirable for all references to "ASCII" in RFC-MNEM and
RFC-CHAR be changed to "US ASCII" so that people outside the US who
are accustomed to referring to ALL 7-bit character sets as "ascii" in
common usage do not inadvertently misread the content of the RFCs.
I think it is important for all RFCs to be clear and unambiguous and
to actively try to prevent confusion from arriving. This is one area
where the IETF has historically done a good job (in contrast to other
standards groups). Referring to ISO standards for the sake of not
referring to the more correct ANSI standards is counter-productive.
7) It isn't clear to me that "quoted printable" is useful for many
non-European languages because many glyphs cannot be usefully
represented using strings of US ASCII. I'm not sure that this is
fixable, but I'm concerned that we not end up being Euro-centric.
We should in fact try to address the non-European concerns
(Chinese, etc.) as well.
Ran
randall(_at_)Virginia(_dot_)EDU