From xemacs-m  Wed May 14 00:46:01 1997
Received: from mikan.jaist.ac.jp (mikan.jaist.ac.jp [150.65.8.6])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id AAA05232
	for <xemacs-beta@xemacs.org>; Wed, 14 May 1997 00:45:57 -0500 (CDT)
Received: from is18e0s01.jaist.ac.jp (MORIOKA Tomohiko <morioka@jaist.ac.jp>) by mikan.jaist.ac.jp (8.7.5); id OAA15563; Wed, 14 May 1997 14:44:37 +0900 (JST)
Message-Id: <199705140544.OAA15563@mikan.jaist.ac.jp>
X-MUA: mh-e 5.0.2 + emh 0.20, SEMI MIME-View 0.88
X-Face: %yc?f+O/cVKlH*K(H2X/6-d''suf|"1{S:Y0}_9$t@0G3:5M2:-Ck^[8+4^iSLeGc[Ey[WP
 PF]2M#Q9C'u~[=7TJP72J`PZdWvP=s-'-/LhFneC->=ILc~H#$lf2%hLL5U8?psIp`<[>d&@$Pm%~(
 A'"CJ.zuX@TXh\Ra4,b7M&`f"hexU-a4,#X\]Bfp'JI+MGUDRA%_$&UnWAem4}1R"4%uivgn;xFZ%"
 NS>)eCuFYNHc/:W^:{7H>bGQS],x5z[Cy~C;7j#:8y9q|"~9~UWjE<Vm_;)o<Q4S5NweLc(cl7-suY
 NF|_O*xodbmQavM
From: =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko <morioka@jaist.ac.jp>
To: Kenichi Handa <handa@etl.go.jp>
cc: steve@miranova.com, mrb@Eng.Sun.COM, xemacs-beta@xemacs.org, Kazu@Mew.org,
        ksakai@netwk.ntt-at.co.jp
Subject: Re: emacs-mule as a coding system name for Emacs' internal format 
In-reply-to: Your message of "Wed, 14 May 1997 11:02:48 JST."
             <199705140202.LAA03093@etlken.etl.go.jp> 
X-Emacs: Emacs 19.34.94, MULE 3.0 =?ISO-2022-JP?B?KBskQjlITVUybBsoQik=?=
Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.80)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Wed_May_14_14:44:25_1997-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Wed, 14 May 1997 14:44:36 JST
Sender: morioka@jaist.ac.jp

--pgp-sign-Multipart_Wed_May_14_14:44:25_1997-1
Content-Type: text/plain; charset=ISO-2022-JP

>>>>> <199705140202.LAA03093@etlken.etl.go.jp> $B$K$F(B
>>>>> $B!H(Bhanda$B!I(B= Kenichi Handa <handa@etl.go.jp> $B$5$^[)$/(B:

handa> Mr. Stallman also told me that the name automatic-conversion is
handa> not good.  It can be acceptable on decoding, but if we consider
handa> it can also be used on encoding, the name `undecided' is much
handa> better.

handa> I also think the name `undecided' is reasonable.  For instance,
handa> 	(detect-coding-region 1 2) => undecided
handa> makes sense much more than returning `automatic-conversion'.

  I think so.  I think `undecided' is good name.


handa> Another matter is that he also requested to have coding systems
handa> of more informative names.  For instnace, as for the current
handa> name of "CODING", make "REGION-CODING" as the real name and
handa> make "CODING" the alias of it.

handa>    From: Richard Stallman <rms@gnu.ai.mit.edu>
handa>        In this case, real name is "japan-shift-jis", and the
handa>    aliases are:
handa> 	       shift_jis and sjis

handa> I'm not sure which is better, REGION or LANG/SCRIPT, but
handa> anyway, this seems to be a good idea.  He suggested to use
handa> "europe-" prefix for coding systems of names iso-8859-X.

  Coding-system of mule is not basically closed character set.
shift_jis or big5 is closed so japanese-sjis or chinese-big5 aren't so
strange.  However `iso-8859-1' of mule can include JIS X0208, or
`iso-2022-jp' can include ISO 8859-1.

  In addition, `japanese-iso-2022-jp' or `chinese-cn-gb2312' seem
strange.  If such kind of systematic naming is required, I propose
following:

    CODING-SYSTEM-NAME = SCRIPT-(-ENCODING)(-VARIANT)

    SCRIPT = SCRIPT_PRIM(-SCRIPT_MINOR)

    SCRIPT_PRIM = amharic | arabic | chinese | cyrillic | devanagari |
                  greek | japanese | korean | lao | latin | thai |
                  tibetan | ...

    SCRIPT_MINOR = <natural number> | gb | ...

    ENCODING = 7bit ; ISO 2022 based 7bit encoding
             | euc  ; ISO 2022 based 8bit encoding (default)
             | <other encoding name (ex. sjis, big5, viscii, tis620)>

    VARIANT = irv ; ISO 646 IRV (may be omitted)
            | ms ; Microsoft extension
            | eten ; big5-eten
            | other variant name (ex. jisx0201)

Example:

	MIME charset   |MULE alias
	===============+=================================
	iso-2022-jp    |japanese-7bit
	euc-jp         |japanese-euc
	               |japanese-euc-irv
	shift_jis      |japanese-sjis
	               |japanese-sjis-irv
	windows-31j    |japanese-sjis-ms
	iso-2022-kr    |korean-7bit
	euc-kr         |korean-euc
	iso-2022-cn    |chinese-7bit
	iso-2022-cn-ext|chinese-7bit
	cn-gb-2312     |chinese-gb(-euc)
	               |chinese-gb(-euc)-ms (chinese-gbk)
	hz-gb-2312     |chinese(-gb)-hz
	cn-big5        |chinese-big5
	cn-big5(eten)  |chinese-big5-eten
	iso-8859-1     |latin-1(-euc)
	iso-8859-2     |latin-2(-euc)
	iso-8859-3     |latin-3(-euc)
	iso-8859-4     |latin-4(-euc)
	iso-8859-5     |cyrillic(-euc)
	koi8-r         |cyrillic-koi8r
	               |cyrillic-alternativnyj
	iso-8859-6     |arabic(-euc)
	iso-8859-7     |greek(-euc)
	iso-8859-8     |hebrew(-euc)
	iso-8859-9     |latin-5(-euc)
	viscii         |latin(-vietnamese)-viscii

-- 
$B(8(,!D!E!&2{$+$7$$L$Mh$N5-21$r$U$H;W$$=P$7$+$1$?!&!E!D(,(,(8(,(,(,(8(,(B
$B("("(B $B(!(B $B("(B  $B(!(B  $B!?(B    $B(!(B   $B(+(!(B     $B(((B                $B(!(B   $B(!(+(B $B(((*(!(B
$B(+(+(!(+(B|$B".(,(!(+(B $B<i2,(B $BCNI'(B (MORIOKA Tomohiko) <morioka@jaist.ac.jp>$B(!(B
$B(5(5(,(5(,(:(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
--pgp-sign-Multipart_Wed_May_14_14:44:25_1997-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.3ia
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM3lRQBnuUGV7wuH5AQG1zAP8C3itBVzTI92D+Qb3yUqiReW1de51glcc
1lYpSQ2mC0ri2WWoFcxIbCdMlfZFtL/M3bVufSHH9X352LsqdR3gaWM/q+6Ttw+x
bRZe2e0PsciDGgOorpf0kaOp9lhDBRwowpNvD7eeNRVFXm4ZNtkCBsw4YUz2WHAQ
PVKJjVXPAJE=
=myA6
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Wed_May_14_14:44:25_1997-1--

