[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reviewing philosophies and assumptions
- To: ietf-smtp@xxxxxxxxxxxxxxxxxx
- Subject: Re: Reviewing philosophies and assumptions
- From: Hitoshi Doi <doi@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 26 Feb 91 13:43:19 JST
- Internet-reply-to: doi@jrd.dec.com
- Phone-reply-to: 045-336-5310 (in Japan)
- Uucp-reply-to: decwrl!jrdmax.enet!doi
I'm finally catching up with all of this mail..
# Well, well, I do consider that you read all this stuff very carefully,
# John, so I wondered why you missed my points. Now I know:-)
#
# The Japanese use of 2022 for mail is well documented, but in Japanese.
# Their 2022 use is very well documented, as in EUC and other character
# set encoding use. It is quite wide-spread, as far as I know.
# It is in general use outside Japan, as it is available with every
# X implementation - standard. I think you can call X "a real
# implementation". Well, I am a bit unhappy about talking on issues
# related to Japan, being no Japanese; maybe the people coming
# from Japan could enlighten us?
7 bit JIS code is used for mail on JUNET because
8 bit is not allowed in SMTP. If 8 bit characters were
allowed, there would be no need for this conversion.
Since the file codes that are used is 8 bit whether it is
EUC(UJIS) or Shift JIS, code conversions have to be done
when sending or reading mail.
So, to send mail one has to..
% edit file
% convert file to 7 bit JIS
% send file
Of course with Emacs, it can be done in fewer keystrokes.
A problem with this is that there are some non-un*x-like
systems that don't support 7 bit JIS. They don't have a
7 bit JIS to local kanji code conversion program.
Also, non-expert users don't understand why they can't just
send their text files through mail.
Hitoshi Doi, International Systems Engineering doi@jrdmax.jrd.dec.com
Japan Research and Development Center decwrl!jrdmax.enet!doi
Digital Equipment Corporation Japan doi@decvax.dec.com