Re: Reviewing philosophies and assumptions

[KLENSIN@xxxxxxxxxxxxxxx (John C Klensin)]

Keld J|rn Simonsen writes...
>John, you do not read my mailings carefully!
>I proposed to standardize existing practise.
>The Japanese are doing ISO 2022 shifts for mail. 
>This is actually the only existing practise in bigger
>character set usage in mail, that I am aware of.
>I still think the Japanese should get their practise codified.
>I am not going to write the specs, tho.
  Actually, I read the mailings very carefully, and this is exactly my
point.  The largely-undocumented, un-codified, Japanese use of 2022
shifts, and whatever it means about hardware/workstation requirements,
does not meet my criteria for what I've learned to define in standards
circles as "existing practice".  If we were having this discussion
after the Japanese practice were codified, in general use, and
available in real implementations outside that country, I would
probably take a different position.

>About 10646: yes it is not available on current hardware.
>But the same goes for the full 8859 family. Anybody got support for
>all 8859 character sets in one device? 
  Again, not the point.  My concern is what happens if the sending user
and receiving user don't have access to the same character sets.  I
would like to make that situation as easy to detect as possible.  I
would also like to make whatever happens (in error reporting, etc) to
be as orderly as possible.  And, I have the bias that, if translation,
interpretation, character encoding (a different activity from the
mechanical encoding of, e.g., 8 bits into 7), or transliteration are
going to be done, it should be a sender responsibility, not a receiver
one.  I'd welcome proposals for "I'm just sending this along, and we
will figure out, out-of-band, how to cope with it" (we typically call
this "transparent") negotiations, but I don't think they should be the
default.

>...so it should be mandatory for the MTA specification of our new
>mailing software, that no information should be lost.
 No disagreement.  I'm opposed to MTA's discarding or destroying
information.  With the exception of the "just truncate the 8th bit,
maybe you can figure it out" community, I can't imagine anyone favoring
MTAs losing information.  What I'm trying to do is propose ways in
which an MTA can decline to accept anything it can't handle without
information loss.  It might be that your arguments about, say, X
clients, argues that all MTAs *should* run "transparent".  But I'd like
to see provision for those that don't/won't/ can't.