[Top] [All Lists]

Problems with RFC-MNEM & RFC-CHAR

1991-07-12 11:50:21
  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.

  "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."

  "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.


<Prev in Thread] Current Thread [Next in Thread>