Inclusion of MNEM in the transition document

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

WG members (and Keld),
   My purpose in writing my earlier over-long note in response to Keld's
note was to try to identify the issues and one possible position that
neither ignored MNEN nor gave it strong endorsement.  My feeling that it
should not be strongly endorsed (Keld's original suggested text appeared
to me to constitute strong endorsement) rests on several factors:
  -- a desire to avoid anything that would require relay MTAs to have
deep MIME knowledge, consistent with my interpretation of the last sets
of conclusions reached in Washington and the general desire to minimize
complexity.  It is my belief (possibly incorrect) that the level of
knowledge required to recognize specific character sets, to ensure that
only appropriate character sets are converted that way, and to avoid
conversion of non-character material represents fairly deep MIME
knowledge, deeper than, e.g., knowing enough about the structures to
avoid creating nested encodings.
   -- the fairly explicit decisions by the 822 WG and IESG to separate
MNEM from the standards-track at that stage in its development
   -- a desire to leave the focus of the transition document as narrow
as possible, rather than beginning to slide material into it that
belongs in more general "mail gateway requirements" or "advice to
implementors of mail gateways" documents (anyone wishing to write those
should get in touch with Russ Hobby: they aren't "SMTP extensions").
    -- a personal bias that we don't to recommend techniques for
transitional/ conversion MTAs that include character conversion tables
whose nature requires that they be periodically updated to be fully
effective.  I don't have any particular objections to such things if
they are appropriate in some circumstance, but I do object to
recommending them.  The size of the tables and the number of cycles it
takes to look something up are not at issue here.  What is at issue is
an architectural preference for MTAs that need an absolute minimum of
fussing and maintenance.
   -- A lack of conviction that, for other that ISO 8859-1 and character
sets that are very close to it (and, indeed, even those), MNEM is 
intuitively readable by someone who is not aware of what it is.  Such
readability is the key to Keld's argument.  We can all probably agree
that quoted-printable is fairly unintelligible for characters not
represented as themselves, although one supposes that a very experienced
person could, in fact, read it (after all, lots of us learned to read
octal, hex, and various core dumps :-) ).  I'm convinced that MNEM is
*lots* more readible for Roman-like alphabetic characters once one gets
used to it (and I suspect almost everyone else is too).  What I'm not
convinced about is whether, if MNEM text is dropped, without warning, on
someone who hasn't seen it, it would look much more obviously
intelligible than quoted-printable.  If it is, then it is appreciably
better for near-interoperability than q-p.  If it is not, then it is
just an alternative.

In any event, Keld has stated his position, I've stated a position that
I think represented something close to the WG position on these issues
(and the context in which Greg wrote his document).  Keld has responded,
and I've explained my comments from a more personal point of view.  
This matter is in IESG's hands and, if they want additional input from
the WG on the subject, they should, and presumably will, ask for it.  I
would encourage Greg to reflect on the remarks of the last few days as
he reworks the document and to inform the WG about what he decides to
do.  But, since I don't think I'm going to significantly convince Keld,
and I don't think he is going to significantly convince me (fine-tuning
in both cases is of course possible), I suggest that we cut off this
discussion at, or close to, this point unless other people in the WG
feel like identifying themselves as confused on the issue and asking for
additional discussion on the points of confusion.

john