Subject: header ni MIME dounyuu ni tsuite

From: [email-masked] (Wataru KAWAKAMI)
Date: Mon, 25 Oct 1993 04:00:22 GMT

### Japanese subject will be read as below: ###
X-Nsubject: headerに MIME 導入に ついて

  NTTの川上です。
  議論のただき台くらいにはと思って、私のheaderに対するMIMEの
導入についての基本的な考えをまとめてみました。

BEGIN ==========================================================
『headerに対するMIMEの導入についての個人的な考え』

					1993/10/25
					[email-masked]
					(Wataru KawaKami)

1. upper-compatiblilty

  mailer/new-systemが*解釈*に使用する`From:',`To:'
`Subject:'などには、現在、inter-net内のcommon-
languageとなっている英語を使う。(upper-compati-
bilityのため)

  つまり、現在使用されている既存のheaderについては、
upper-compatibilityが保たれている(対応していない
programで読んだ時に、``意味のある''情報が得られる
ようになっている)こと。

2. その他のフィールドへの導入

  別フィールドをheaderに設けて(ex: Mime-From: etc.)
それをMIME用に使用するのは構わない。(ただし、現時点
で行なわれている他の実現方法(ex: X-N*)に{干渉しない,
共存する}こと。)

  ただ、MIMEをheaderに導入することによって、headerが
重くなるようであれば、header側には、pointer(例えば、
行番号)のみをいれて、実体は、mail/news systemのbody部に
入れるようにした方がいいと思われる。

(個人的には、headerは、極力その各項目が一行として
認められるとwataruが考えている約 80 - 100 bytes位
入った方がよいと思っている。)

  また、新規に作るmail/news-readerのuser-interfaceに
おける`ヘッダー'(ex: 宛先、題目)とmail/news-systemに
おける`header'(`From:',`To:')は分けて考えた方がよい。

3. databaseとして mail/news

  現在、MIMEで実用速度で検索可能なツール(grep,less etc.)が
ない現在、記事検索を行なうことを考慮にいれると、MIMEで書いた
内容を別フィールドに検索可能なcodeにdecodeしておいてあると
助かる。(ex: mime2xnでの実現)

END =========================================================
といったところです。みなさんは、いかがでしょうか。

						wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Shinji Kono)
Date: Mon, 25 Oct 1993 08:23:00 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Wataru KAWAKAMI) writes 
>『headerに対するMIMEの導入についての個人的な考え』

というより、これをfjのstandardとして提案するのはどうですか?  単純に要約
すると、
    「MIMEは既存のSubject / GCOSには使うな」
    「そのかわりMime-Fromなどを使え」
ということでしょう?

少なくともfjは海外にもながれている以上、Subject line, Adress feild の英
語としての読みやすさみたいなものは考慮されるべきです。また、Fieldを別に
した方が実装も簡単ですよね。

Subject: Re: header ni MIME dounyuu ni tsuite 
よりも、
Subject:    Re: on introducing MIME in header
X-NSubject: Re: headerに MIME を導入することについて
の方が便利ですし。ニュースリーダでも、例えばNSubjectを優先するとか
すればいいわけでしょう? 既存のMail readerでも余分なheader fieldを
見ることぐらいは簡単ですし今でもできるものが多いと思います。

In article <[email-masked]>,
      [email-masked] (Takanari HAYAMA) writes:
>   将来、MIMEの符号化および復号化が透明に行なわれれば、
> 結果として、meaningful ASCIIに捕らわれないmeaningful
> TEXTを入れることができます。 ...
>   Mail Boxに入る時に、変換されていれば問題ないのはな
> いでしょうか？

ここまで要求するのなら、ISO-2022をそのまま通すのと手間は変わりません。
MIMEをheaderにいれるなら、どうせどういうエンコードを許すのかをもう一度
議論しなければなりません。それよりは、例えばfj固有のfieldを設定する方が
現実的だと思います。

body部ならuuencodeと変わりないわけですから、勝手にドウゾというところ
ですね。uuencodeよりは便利かも知れない。

---
Shinji Kono @           [email-masked]
河野真治 Sony Computer Science Laboratory, Inc,Japan

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 26 Oct 1993 03:00:52 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: headerに MIME導入に ついて

  NTTの川上です。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> というより、これをfjのstandardとして提案するのはどうですか?
もともと、叩き台としてあげたものですから、これを元に、皆さんの
意見が集約できればと思います。ここから、fjのstandardができあが
れば、本望ですね。

 >> 								 単純に要約
		      ~~~~~~~ plus `From:', `To:'.
 >> ということでしょう?
MIMEについては、そうですね。(upper compatiblityを保つため。)

 >> 語としての読みやすさみたいなものは考慮されるべきです。また、Fieldを別に
そうですね。

 >> の方が便利ですし。
適当な、日本語<->英語の変換プログラムがない現時点では、当面は、
romajiも可とした方が良いかと考えています。
# romajiなら、kakasiを使えば、自動変換できますし。。。。

 >>			ニュースリーダでも、例えばNSubjectを優先するとか
"X-Nsubject:"の実装がまさしくそうなっています。

 >> 議論しなければなりません。それよりは、例えばfj固有のfieldを設定する方が
同感です。

 >> body部ならuuencodeと変わりないわけですから、勝手にドウゾというところ
uuencodeより便利(multi-mediaのための自動変換の枠組を与えている)
というところが、MIMEの本質かなと思ってます。
						wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Wed, 27 Oct 1993 02:29:47 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Shinji Kono) 氏曰く、

河野> In article <[email-masked]> , 
河野> 	[email-masked] (Wataru KAWAKAMI) writes 

河野> 少なくともfjは海外にもながれている以上、Subject line, Adress feild の英
河野> 語としての読みやすさみたいなものは考慮されるべきです。また、Fieldを別に
河野> した方が実装も簡単ですよね。

  問題が技術的なものでなく、言語なのであるならば、ローマ字表記も英語と
して読みにくいのだから、問題なんじゃないですか？

  私はそこまで英語中心主義にならなくても良いと思います。何語で header 
をつけ、何語で内容を記述するかは書き手の自由に任されるべきだと思います。

  英語との併記表現の奨励には賛成しますが、header への日本語表現の禁止
には反対します。

〓〓〓〓〓〓〓〓〓〓〓 ロシアン・ティーを一杯。 〓〓〓〓〓〓〓〓〓〓〓
〓〓〓〓〓  ☆ ジャムではなくマーマレードでもなく蜂蜜で ☆  〓〓〓〓〓
〓〓〓〓〓         МОРいОКА  ТОМОХИКО         〓〓〓〓〓
〓〓〓〓〓〓〓  Internet E-mail: <[email-masked]>  〓〓〓〓〓〓〓

---

From: [email-masked] (HIRANO Satoshi)
Date: Tue, 26 Oct 1993 13:43:18 GMT

>をつけ、何語で内容を記述するかは書き手の自由に任されるべきだと思います。

私もそう思います。なにしろ、英語の Subject: は読みずらい。
それに、参加者が多様化して、英語の Subject: 自体が重荷になっています。
で、ローマ字の Subject: が増えているような気がするんですが、
それがまた読みずらい。

どうせ内容が日本語なんだから、Subject: が英語であることには
あまり意味がありません。中身の日本語が読めない人に対して
Subject: だけ(我々が不便を忍んで)サービスしても、何にもならないでは
ありませんか。
X-Nsubject: を使って英語の Subject: と併記するのも面倒なだけです。

電総研内では y佐藤さんの MIME エンコーダ／デコーダで日本語の
Subject: が使えるようになっているのですが、すごくいいですよ。
わかりやすいし、面倒はないし。

★ そろそろ、私の Emacs にも MIME を仕込まねば。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
平野   聡           電子技術総合研究所

[email-masked]    The future is Fluid.

---

From: [email-masked] (Shinji Kono)
Date: Tue, 26 Oct 1993 15:05:35 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (HIRANO Satoshi) writes 
>Subject: が使えるようになっているのですが、すごくいいですよ。

そういう意味ならMIMEなんか使わなくても社内では日本語のSubjectを
使ってます。なんか、現実にほとんど通るのに、わざと通らないふりを
してMIMEを強要している気もする。

でも、今は世界の大海へ出ていくfjの話ですよね?

>あまり意味がありません。

そうとは限らない。実際、Subject: / To: が英語であることを期待したプログ
ラムがそのまま動くでしょう。イギリスでgrepできるのは便利だったし。日本語
を勉強した人が、読みたい翻訳したい記事だけ選択するのにも便利です。

>X-Nsubject: を使って英語の Subject: と併記するのも面倒なだけです。

別にSubject:だけ書いてもいいし、X-Nsubjectは本体から一行とってくるように
してもいいし、あるいは Subject: がなければ、X-Nsubject:からロー字を生成
してもいい。個人的には、Subjectを一つ余計に書くのも本文に一行Summry をつ
けるのと同じように感じます。だいたい、平野さんだってSubject:を毎回書いて
いるわけじゃないでしょ。

MH/rnだって X-Nsubjectだったらformatの書換えだけで済むのに...

---

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Tue, 26 Oct 1993 19:37:25 GMT

On 10/27/93(00:05) [email-masked] (Shinji Kono) wrote
in <[email-masked]>
 |>電総研内では y佐藤さんの MIME エンコーダ／デコーダで日本語の
 |>Subject: が使えるようになっているのですが、すごくいいですよ。
 |>わかりやすいし、面倒はないし。
 |
 |そういう意味ならMIMEなんか使わなくても社内では日本語のSubjectを
 |使ってます。なんか、現実にほとんど通るのに、わざと通らないふりを
 |してMIMEを強要している気もする。

　「Why MIME?」の議論は Subject: $BGr;3MS(B の記事をきっかけとして
はじまりました。社内か国内か国外かとか、技術的な不備による不連続性
を、ユーザに強制的に認識させるのはナンセンスです。

＃一連の議論は、etlport.etl.go.jp:‾ftp/pub/mime/[email-masked] に
＃アーカイブしてありますので、消失してしまったかたは御利用下さい。

 |でも、今は世界の大海へ出ていくfjの話ですよね?

ええっ！そうだったのですか…
ぼくは、インターネットメイルと、USENET ニュース及びそれと接続可能
な各種のサービス全ての話しだと思っていました。
fjニュースに閉じた話しって、できるんでしょうか？

日本語に限った話しっていうのでもないですよね。例えば、海外からやっ
てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
でしたら、早めにしかるべきところで表明した方が良いと思いますが…

　　　　　　　　　　　　　　　　 @ @
┰── ─┰─ ┰　　  ／／＼^^　( - )  {サービス、自分のために}
┠─++佐藤＠ＥＴＬ　／　876m＼ _<   >_　　　　　　　　　　　　..
┸── 　┸　 ┸────────────────────── (- @)∋ ──┘
★MIMEエンコーダ/デコーダ発売中★etlport.etl.go.jp:pub/mime/mimehead.tar.Z
★なんでMIMEやねん永久保存版★etlport.etl.go.jp:pub/mime/[email-masked]

---

From: [email-masked] (Shinji Kono)
Date: Wed, 27 Oct 1993 02:26:40 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) writes 
>fjニュースに閉じた話しって、できるんでしょうか？

単に、「fjではそうしましょ」というだけでいいと思います。 「半角かなは使
わないで」ってのと同じですよね。既に先例があるではないですか。

>でしたら、早めにしかるべきところで表明した方が良いと思いますが…

それに、別にfieldをつけて、そこにMIMEをいれるののどこが困るのですか?  き
ちんと下のlayerでやってくれるなら文句はないんだけど、今の互換性を破壊す
る形でするなら、それなりの圧力はあるでしょ。ちなみにしかるべきところって
どこなのかな。しかるべきところでいっていれば、fjでやってもいいというわけ
でもないでしょう。

MIMEみたいな変更を強いるなら、ついでに8bit thruの変更もして欲しいです。
結構、大きな変更なのにUnix file system までMIMEにしようっていう野望があ
るわけでもないんですよね。いいわけは他だ一つ「asciiに見える」。Ambitious
でもなければSmoothでもない。

fj.livingでもたまに日本語Subjectを見ますが、どれくらいのところが届いてな
いのでしょう? 川上さんのX-Nsubjectは見えてますか? まさか存在しない非互換
性で脅しをかけているわけじゃないですよね? C-News や B-Newsでsubject
field に触っているのはinewsのfront endだけですから、いったん出てしまえば
割と保存されると思いますけど。

---

---

From: [email-masked] (Masataka Ohta)
Date: 27 Oct 93 05:28:32 GMT

In article <[email-masked]>
	[email-masked] (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) writes:

>社内か国内か国外かとか、技術的な不備による不連続性

　かくて、メインフレームとＥＢＣＤＩＣは永遠に栄えるのであった。ちゃんち
ゃん。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Wed, 27 Oct 1993 10:09:17 GMT

On 10/27/93(14:28) [email-masked] (Masataka Ohta) wrote
in <[email-masked]> (fj.mail:2255/etlss2):
 |In article <[email-masked]>
 |	[email-masked] (Yutaka Sato 佐藤豊) writes:
 |
 |>社内か国内か国外かとか、技術的な不備による不連続性
 |>を、ユーザに強制的に認識させるのはナンセンスです。
 |
 |　かくて、メインフレームとＥＢＣＤＩＣは永遠に栄えるのであった。ちゃんち
 |ゃん。

最近はｆｊで太田さんを見かける機会も少いので、この際にお尋ねしたいの
ですが、インターネットでの非ASCII文字コードが標準化されるのは、いつ
頃になると思われますか？また、それはどのようなものになるでしょう？

＃しかるべき所で聞けってか(^_^)
　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Akira Takuma)
Date: Wed, 27 Oct 1993 03:29:08 GMT

fj.mailの<[email-masked]>
の記事においてJST時間1993年10月27日(水)04時37分25秒頃、
佐藤さんは書きました。

  | 日本語に限った話しっていうのでもないですよね。例えば、海外からやっ
  | てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
  | でしたら、早めにしかるべきところで表明した方が良いと思いますが…

そのわりに fromMime を含めて ISO-2022-JP 専用みたいなプログラム
が多いのは何故でしょうか。MIME の実装はリーダにとってものすごく
重荷だからではないですか？
# 個人的には同じことを表現するのに様々なエンコード方法があるのは
# プログラム書く時に面倒なだけで好きではないです。

確か何かの記事で metamail は ISO-2022-JP に対応していないが
読むことは可能といわれていたと思いますが、確かに読むことは
可能ですね。
しかし、それがユーザが想定していない文字セットだったら端末
を乱すことでしょう。
また、試していませんがエンコードする方は駄目なのではないで
しょうか？(どの区間をエンコードして良いか判断が難しいため)

つまり結局はリーダがどの言語か意識していないと使いものになら
ないわけです。

それに

< =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= @etlkbs.etl.go.jp>

はエイリアスで可能とかいわれていましたが、それこそほとんど
無意味だと思います。ユーザが意識していないといけないわけですし、
@etl... のくだりは現状ではどうしようもないのではないでしょうか？
(間違っていたら訂正してください)

つまり MIME でヘッダに多言語が流せるよといわれても多言語に対応して
いるリーダがないことには嬉しいことはほとんどないばかりか、現状
のように日本語だけのためにリーダ毎に面倒な実装を必要としているのは
おかしいと思いませんか？

MIME による日本語ヘッダにはメリットが確かにありますが、それにも
増してデメリットが大きいと思うわけです。

やっぱり body に使うのがいいですねぇ。
-- 
-------------------------------------------------------------------------
(株) 松下ソフトリサーチ	第一開発部 第一開発室 宅間
				E-mail:[email-masked]
-------------------------------------------------------------------------

---

From: [email-masked] (Wataru KawaKami)
Date: Wed, 27 Oct 1993 07:42:25 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: headerに MIME 導入 に ついて

  NTTの川上です。参考までにお聞きしたいのですが、

  "fj.mail"の"Re: header ni MIME dounyuu ni tsuite"について
    (記事<[email-masked]>)、[email-masked]、
  >> てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
って、headerのmail/news-systemが解釈する部分(ex: From:, To:)に
入ってきているのでしょうか。もし、入ってきているのであれば、
そこいらの議論は海外ではどこで行なわれているのでしょうか。

  もし、ご存知でしたら、後学のため、お教え下さい。

						wataru
P.S.
  body部分、headerのmail/news-systemが単にcopyする部分に入って
いるなら、ここでの話しとは別ですよね？
  いま、ここで議論されているのは、headerのmail/news-systemが
解釈する部分へのMIMEの導入だと思っているのですが、いかがでしょう。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Satoru OKAMOTO 岡本 聡)
Date: Wed, 27 Oct 1993 08:00:43 GMT

岡本＠NTTです。
[email-masked] と一緒に X-Nsubject: の最初のインプリメントを行いました。

 >field に触っているのはinewsのfront endだけですから、いったん出てしまえば

いわゆるJP-patchが当てられたC-Newsは ESC を透過します。
しかしながら B-News は inews が header の ESC を落します。
(B-News 用の patch をwataru が fj.sources に投稿したと思います。)

＃実はつい最近まで X-Nsubject は local でしか通用していなかったりする。
＃MIME なら一応自分が用意すれば楽しめるというメリットはありますね。

---

From: [email-masked] (Wataru KawaKami)
Date: Wed, 27 Oct 1993 09:33:57 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: headerに MIME導入 に ついて

  NTTの川上です。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> をつけ、何語で内容を記述するかは書き手の自由に任されるべきだと思います。
headerの場所によると思いますが。

  From:, To:とかに書いてあると、非対応のものだと単なるmeaning-
lessな文字列を見ることになります。また、ここにMIMEでかいて来る
ということは、MIMEを強要されているように感じられます。

						wataru

---

From: [email-masked] (Wataru KawaKami)
Date: Wed, 27 Oct 1993 10:08:26 GMT

### Japanese subject will be read as below: ###
X-Nsubject: X-Nsubjectの誕生について (was Re: headerに MIME導入.....)

  NTTの川上です。X-Nsubjectの誕生に当たっては、okamotoくんおよび
buchi@ntttsd氏には、世話になりました。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite ("について
    (記事<[email-masked]>)、[email-masked]、
 >> (B-News 用の patch をwataru が fj.sources に投稿したと思います。)
そうですね。思えば、懐かしいです。buchi@ntttsd氏のgnus版とともに、
これが、X-Nsubjectの最初でした。これを元に、当時wataruが使っていた
vnに組み込んだのがfj.sourcesに投稿されたものです。

  誕生当時は、結構なsiteがESCを落している用だったので、gnus,vn
などの対応に当たっては、強引に復活する機能を付加していきました。
gnusのためになれないelispも書いたというのも今思えば、懐かしい
思い出です。(fillesc2.el, jis-to-emacs-kanji.el)
# テストに協力していただいた皆様に感謝。
# でも、もうすぐ、不用になるかな。:-)

  あと、takahasiさんが作られたkakasiなる強力な漢字->romaji変換の
プログラムが出てきたことが、私としては、嬉しかったです。とりあえず、
これを使って、X-Nsubjectのみを書けば、Subjectをつけてくれるという
環境が手元にでき上がりました。(ConvInews.sh)
# 日本語->英語 converterができれば、いうことなしですが。
# そうすれば、common-language, local-languageの双方がヘッダーに
# 入ってくれる。

 >> ＃実はつい最近まで X-Nsubject は local でしか通用していなかったりする。
宣伝が足りなかったのかなぁ。。。。:-P  一応、ESCが落ちても、対応の
ニュースリーダでは、読めていました。
# vnは、saveする時は、復活したものがセーブされるように作ったように
# 記憶しています。

 >> ＃MIME なら一応自分が用意すれば楽しめるというメリットはありますね。
それは、X-N*でも同じですね。
						wataru

# MIME in headerも、別ヘッダーに入っていたら、ここまでもめ
# なかったのにと思うのは、私だけでしょうか。。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Nakamura Atsushi)
Date: Wed, 27 Oct 1993 18:12:46 GMT

中村@松下技研です。

＃ fj.mail.mimeはいつできるんだろう...

On 10/27/93(11:26) [email-masked] (Shinji Kono) wrote
in <[email-masked]> (fj.mail:742/localhost):
 |
 |単に、「fjではそうしましょ」というだけでいいと思います。 「半角かなは使
 |わないで」ってのと同じですよね。既に先例があるではないですか。

「日本語のヘッダはやめましょう」という先例がありましたが、その
結果として、本文は日本語で、サブジェクトは英語で、という記事が
fjには流れます。

英語しか読めない人、日本語しか読めない人、両方読める人、という
3種類の人がいた時に、これでは両方読める人しか便利ではありません。
そういう意味で、この取り決めは理不尽だと思います。

MIMEヘッダを推奨する、禁止する、という以外に、現状のまま放置する
という選択があると思います。
MIMEの場合、半角かなと違って、受けとった記事のためにシステムに
害が及ぶわけではありませんし、metamailがありますから、まったく
読むことが不可能なわけでもありません。
余計な慣習が増えるという意味で、「MIMEはやめましょう」という
提案には賛成できません。読める人があまりいない、ということを
わかっていて流すぶんには、どうでもいいんじゃないでしょうか。

 |
 |それに、別にfieldをつけて、そこにMIMEをいれるののどこが困るのですか?  き
 |ちんと下のlayerでやってくれるなら文句はないんだけど、今の互換性を破壊す

別のfieldを新たに作られるのは、それに対するパッチを探さないと
いけないので、めんどうくさいです。
日本語サブジェクトのMIME化程度なら、nntpdでやってくれるパッチ
が転がってましたけど。

 |
 |MIMEみたいな変更を強いるなら、ついでに8bit thruの変更もして欲しいです。

8bit目を日本語だけのために使われるのは困るんじゃないでしょうか。
多言語化を考えた場合には、8bit thruにしても、何の役にも立たない
と思います。どこの国のEUCだかわからないんですから。

 |るわけでもないんですよね。いいわけは他だ一つ「asciiに見える」。Ambitious
 |でもなければSmoothでもない。

asciiに見える、ということは、どこの国の端末でも画面を壊すこと
はないし、どこの国のどんなに制限された媒体を経由しても情報が
落ちることはない、というのが特徴だと思います。
よくわからないのですが、ISO-2022であれば、(現実問題として)
この2つの性質を満たすのでしょうか？

	_________ [email-masked] { 中村敦司@松下技研(株) HI研究所 8-.}

---

From: [email-masked] (Shinji Kono)
Date: Thu, 28 Oct 1993 02:19:38 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Nakamura Atsushi) writes 
>よくわからないのですが、ISO-2022であれば、(現実問題として)

MIMEだろうがISO-2022だろうが、$@$@#$#@?B?B とかに見えるだけでしょう。
escapeを落すのはMailやNewsのfront-endであってtransporterではありませんか
ら、満たしているといっていいんじゃないかな。

確かにESC-(-Jが来ると落ちる端末とか昔はありましたけど、そんなの考慮する
必要あるのかなぁ?  そんなものがあるところではescapeはfront endで落してい
るでしょうし。MIMEってそういうものを考慮するためにあるの?

>そういう意味で、この取り決めは理不尽だと思います。

すくなくともSubjectは読めるんですよね... 確かにSubjectとして日本語を使え
ないのはおかしいと思います。通すのだったらできるだけ簡単な方法を選択した
い。例えば、bodyと同じとか... bodyとheaderと同時にMIMEにしてしかもuserか
ら見えないなら文句ないんだけど。HeaderはMIMEでbodyはISO-2022なの? なん
で?

---

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Thu, 28 Oct 1993 06:29:40 GMT

On 10/27/93(12:29) [email-masked] (Akira Takuma) wrote
in <[email-masked]> (fj.mail:2258/etlss2):
 |  | 日本語に限った話しっていうのでもないですよね。例えば、海外からやっ
 |  | てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
 |  | でしたら、早めにしかるべきところで表明した方が良いと思いますが…
 |
 |そのわりに fromMime を含めて ISO-2022-JP 専用みたいなプログラム
 |が多いのは何故でしょうか。MIME の実装はリーダにとってものすごく

自分が扱える部分だけを扱う、というのはMIMEのheader/bodyを通じた共通
の基本方針です。MIMEは「これを自分が扱えるかどうか」を判断するための
共通の言語を、最低限の共通文字である US_ASCII で定義しているわけです。
これが、守岡さんたちが言われた「MIMEの宣言性」というのの基本です。
RFCを引用しておきます（既に読まれていたらごめんなさい。逆にもし読ま
れていないと、議論を続けるのを困難に感じます）

[RFC1521]
>4. The Content-Type Header Field
>   The purpose of the Content-Type field is to describe the data
>   contained in the body fully enough that the receiving user agent can
>   pick an appropriate agent or mechanism to present the data to the
>   user, or otherwise deal with the data in an appropriate manner.
...
>  It should be noted that the list of Content-Type values given here
>  may be augmented in time, via the mechanisms described above, and
>  that the set of subtypes is expected to grow substantially.
>
>   When a mail reader encounters mail with an unknown Content-type
>   value, it should generally treat it as equivalent to
>   "application/octet-stream", as described later in this document.

[RFC1522]
>6.2. Display of encoded-words
>   Any encoded-words so recognized are decoded, and if possible, the
>   resulting unencoded text is displayed in the original character set.
...
>   In the event other encodings are defined in the future, and the mail
>   reader does not support the encoding used, it may either (a) display
>   the encoded-word as ordinary text, or (b) substitute an appropriate
>   message indicating that the text could not be decoded.
>
>   If the mail reader does not support the character set used, it may
>   (a) display the encoded-word as ordinary text (i.e., as it appears in
>   the header), (b) make a "best effort" to display using such
>   characters as are available, or (c) substitute an appropriate message
>   indicating that the decoded text could not be displayed.

 |が多いのは何故でしょうか。MIME の実装はリーダにとってものすごく
 |重荷だからではないですか？
 |# 個人的には同じことを表現するのに様々なエンコード方法があるのは
 |# プログラム書く時に面倒なだけで好きではないです。

多国語文字の同時サポートというのは、実際簡単な話ではないですね。表現
形式にしても、表示装置にしても。（これは、MULEに期待します）
fromMime（デコーダ）を多国語対応にするには、表示装置がどのような文字
セットのどのようなエンコーディングを扱えるかを知る手立てが必要ですが、
現状ではISO-2022-JP以外はあまりないと思ってさぼっています。
toMime（エンコーダ）の多国語対応については、入力がISO-2022の、我々が
使っている ISO-2022-JP のと同じタイプのものであれば、実装は簡単です。

 |また、試していませんがエンコードする方は駄目なのではないで
 |しょうか？(どの区間をエンコードして良いか判断が難しいため)
 |つまり結局はリーダがどの言語か意識していないと使いものになら
 |ないわけです。

ISO-2022-JPのようなASCIIを包含する文字セットの場合、これは実際簡単で
はありません。ASCII部分を含めてエンコードするには、 RFC822 の構文を
ちゃんと解析する必要があります。一方、非ASCII部分だけをエンコードする
と割り切れば、ISO-2022 の制御コードだけを認識すればエンコードできます。
実際、toMimeなども含め、ほとんどのエンコーダがそのような実装になって
いると思います。

 |< =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= @etlkbs.etl.go.jp>
 |
 |はエイリアスで可能とかいわれていましたが、それこそほとんど
 |無意味だと思います。ユーザが意識していないといけないわけですし、
 |@etl... のくだりは現状ではどうしようもないのではないでしょうか？
 |(間違っていたら訂正してください)

これはまあその、実際には MIME(RFC1522) の規格を逸脱した話です。
RFC1522 を読んで、私のウソを指摘しましょう。ただ、このような日本語の
名前の使用を切望している人は実際にいるので、これが可能になるように
規格の改訂を要求していく道はあると思います。

 |つまり MIME でヘッダに多言語が流せるよといわれても多言語に対応して
 |いるリーダがないことには嬉しいことはほとんどないばかりか、現状
 |のように日本語だけのためにリーダ毎に面倒な実装を必要としているのは
 |おかしいと思いませんか？
 |MIME による日本語ヘッダにはメリットが確かにありますが、それにも
 |増してデメリットが大きいと思うわけです。

実際のところ、ぼくなんかも最初は「生で日本語のヘッダーを」と考えて
いたし、MIMEが実際に普及するまでは（あるいはしない可能性もある）、
併用したらどうかと考えていて、i-headers ML でもそのように発言してい
ました。結局、MIMEを選んだのは、アドレスフィールドにも日本語が使い
たいし、非ASCII/非JISの人たちとも共存したいし、MTAの入れ換えよりは
MUAの入れ換えが現実的だと思ったからです。また、総合的に見てMIMEの
現在の方法が達成しているのと同等な機能を実現する、よりエレガントな
方法を思いつかないからでもあります。

RFC1522の方法は、複数の案の中から勝ち残って来たものです。もちろん、
フィールドを別にすると言う案もあったようですが、採用されなかった
わけです。同様な方法を再提案されている方はietf-822メイリングリスト
の過去の記事を読まれてみてはいかがでしょうか。
etlport.etl.go.jp:‾ftp/pub/mime/ietf の下にも置いてあります。

 |やっぱり body に使うのがいいですねぇ。

MIMEメッセージのボディに２つ以上の型のデータが含まれる時には（これは
極めて普通に起こりますが）、"multipart"という型で表現されます。
multipart型で束ねられる単位はボディ部品（body part）と呼ばれますが、
これは基本的にRFC822のメッセージと同一の規約に従っています。RFC822の
メッセージが入れ子になっていると考えて良いでしょう。従って、ボディ部
においても、ボディ部品ヘッダに関してはRFC1522による非ASCII表現が前提
になっています。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Thu, 28 Oct 1993 22:57:46 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Akira Takuma) 氏曰く、

宅間> fj.mailの<[email-masked]>
宅間> の記事においてJST時間1993年10月27日(水)04時37分25秒頃、
宅間> 佐藤さんは書きました。

宅間>   | 日本語に限った話しっていうのでもないですよね。例えば、海外からやっ
宅間>   | てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
宅間>   | でしたら、早めにしかるべきところで表明した方が良いと思いますが…

宅間> そのわりに fromMime を含めて ISO-2022-JP 専用みたいなプログラム
宅間> が多いのは何故でしょうか。MIME の実装はリーダにとってものすごく
宅間> 重荷だからではないですか？
宅間> # 個人的には同じことを表現するのに様々なエンコード方法があるのは
宅間> # プログラム書く時に面倒なだけで好きではないです。

  あくまで個人的な感想ですが、decoder を作るのは簡単です。single-octet
の文字セットだけなら登録されているものを全てサポートするのもそう難しい
ことではないと思います。2 octet のものは encoding の違いがあって、
single-octet の場合ほど単純ではないですが、それにしても、decoding に関
してはそんなに大変とはいえないと思います。

  ただし、encoder は確かに大変です。MIME の現在の使用の「不完全さ」も
あって、完璧な encoder は存在していないと思います。

  ただ、問題は読むことですから、decode が比較的楽な MIME の方法は許容
の範囲だと思います。

＃ MIME の decode の重さに関しては、header だけならすごく軽いですが、
＃ body も含めた full decoding をしようとするといきなり重くなります。
＃ MIME を実装する場合、現状では、header だけの decoding と body も含
＃ めた full decoding はリーダーがその時その時選択できるようにしておい
＃ た方が良いと思います。

宅間> 確か何かの記事で metamail は ISO-2022-JP に対応していないが
宅間> 読むことは可能といわれていたと思いますが、確かに読むことは
宅間> 可能ですね。
宅間> しかし、それがユーザが想定していない文字セットだったら端末
宅間> を乱すことでしょう。

  こうした現状においてこそ、MIME の持つ『宣言性』が有効なのではないで
しょうか？

＃ ところで、みんな body-part なら良いとおっしゃいますが、fj.sources 
＃ とかに MIME の形式で投稿しても良いんでしょうかね。やっぱり、Base64 
＃ とかで encode したら苦情殺到のような気がするんですが。
＃ shar の代わりに、octet-stream の 7bit encoding なら、それに対する苦
＃ 情は来ないみたいですが。external の anon-ftp でも多分大丈夫だろうな。
＃ 誰か、Base64 で投稿しないかな。

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Thu, 28 Oct 1993 23:05:42 GMT

>>>>> <[email-masked]> にて、

河野> すくなくともSubjectは読めるんですよね... 確かにSubjectとして日本語を使え
河野> ないのはおかしいと思います。通すのだったらできるだけ簡単な方法を選択した
河野> い。例えば、bodyと同じとか... bodyとheaderと同時にMIMEにしてしかもuserか
河野> ら見えないなら文句ないんだけど。HeaderはMIMEでbodyはISO-2022なの? なん
河野> で?

  少なくとも、私の body は MIME ですが。Content-Type: を見て下さい。も
ちろん、header だけの人もいますが。

  くどいようですが、encoding 法が MIME という訳じゃないのです。そのま
ま通るのなら、7 bit とか 8 bit といった encoding を使えば良いのだし
（header はそのままにしちゃう）、通らないなら、encoding をかける訳です。

---

From: [email-masked] (Shinji Kono)
Date: Thu, 28 Oct 1993 13:03:03 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Yutaka Sato ) writes 
>の基本方針です。

うーむ、だったら、fjではISO-2022が使えるんだからheader/bodyにそれを使え
ばいいと思うんだけど。fj以外は扱えない。これでいいじゃない。そういう発想
なら、「fjではSubject fieldにescapeを許し、JIS漢字を使う」で、終りです
ね。(なんで、そうしなかったんだろう?)

>RFCを引用しておきます（既に読まれていたらごめんなさい。逆にもし読ま

でも、利点がないように感じるのでは読む気になれません。(採用しない規格書
なんて読む?) ここを読んでいる大半の人がそうでしょう。推進するつもりな
ら、辛抱強く説明するしかないでしょう。

>結局、MIMEを選んだのは、アドレスフィールドにも日本語が使い
>MUAの入れ換えが現実的だと思ったからです。

でも、fjだったら、誰かもいってたけどJIS/日本語に決まっているわけでしょ?
共存するも何も、fj <-> comp って最初から離婚してしまっているのに。
Subjectにわけわからないもの流していいなら、最初からJISを流してます。

>わけです。

fjの中で勝ち残ってきたわけではないですね。UsenetやRFCでは、日本に特殊化
している環境で選択するには十分ではないと思います。

もう少しなんか「今までにないことができる!」みたいなのがないと、例えば
Sony CSLでMIMEを入れる気にならない。日本語Subjectなら社内では今でもでき
るんですから。

---

---

From: [email-masked] (Shinji Kono)
Date: Thu, 28 Oct 1993 13:05:58 GMT

[email-masked]。ちなみに、MHでX-Nsubjectを使いたかったら、
scan formに以下のものを使えばいいだけですね。

%6(msg)%<(cur)+%| %>%<{replied}-%|%<{encrypted}E%| %>%>¥
%02(mon{date})/%02(mday{date})%<{date} %|*%>¥
%10(mbox{from})  ¥
%{X-Nsubject}¥
%{subject}%<{body}<<%{body}%>
---
Shinji Kono @           [email-masked]
河野真治 Sony Computer Science Laboratory, Inc,Japan

---

From: [email-masked] (HIRANO Satoshi)
Date: Thu, 28 Oct 1993 14:56:40 GMT

In article <[email-masked]> [email-masked] (Shinji Kono) writes:
   >使ってます。

日本語の Subject: は便利。不便を忍んで英語にすることはないですよね。

   >でも、今は世界の大海へ出ていくfjの話ですよね?

なるほど、ごもっともです。

それだったら、世界中で fj を読んでいる人の事を考えないといけない。
その人たちは日本語の中身を読んでいるんだから、Subject: が日本語で
あっても読むことができます。

世界中に出ていった記事の Subject: が日本語であることを保証することは
どうやったらできるでしょうか。よくわかってないんだけど、それを
満たせるのはMIME だけなのでは。

★ gnus, mh-e で MIME を使う方法がまだわかりません。(;_;)

---

From: [email-masked] (Wataru KawaKami)
Date: Thu, 28 Oct 1993 03:10:46 GMT

### Japanese subject will be read as below: ###
X-Nsubject: MIMEの``乱入''(?) (was Re: headerにMIME導入について)

 NTTの川上です。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite ("について
    (記事<[email-masked]>)、[email-masked]、
  >> MIMEヘッダを推奨する、禁止する、という以外に、現状のまま放置する
MIME-headerを`禁止'するという話しはでていないと思いますよ。

`From:',`To:'などの大半のmail/news-systemが解釈する部分への
MIMEの``乱入''は、よくないのではないかという話しをしている
のだと思っていました。

# いろんな考え方の人が共存できるようにと考えると、少なくとも、
# 現行のものに対して、upper-compatibilityは保った方がよいの
# ではないでしょうか。

  >> 別のfieldを新たに作られるのは、それに対するパッチを探さないと
MIMEを*強要*されるのは、もっとめんどくさいです。
# 別のfieldを設けてやっていただく分には、構いませんが。

					wataru

# Subject, Fromが可読でないとすると、どこから、題目、送り主を
# 探すんだろう。。。。
# それとも、誰かMIMEなOSでも作るんだろうか。謎。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Shinji Kono)
Date: Thu, 28 Oct 1993 18:07:56 GMT

[email-masked]。だいぶ分かってきたぞ。要するに「MIMEは宣言であって、
encodingでない」ということですよね。問題は、それを
     From:/Subject: 内のコード切り替えやアドレスに使う
というセコイ技を出した所にあるような気がします。そういうことはコード系自身が
やるべきことでしょ? 例えば、Mail HeaderにはTo:, Newsgroups:, Message-Id: だけ
書いて、後は単一のMIME宣言だけでまとめれば、まだまし。

In article <[email-masked]> , 
	[email-masked] (HIRANO Satoshi) writes 
>★ gnus, mh-e で MIME を使う方法がまだわかりません。(;_;)

bodyとheaderで違うdecodeを使っているんだから難しいのは当然。いいかい、
X-Nsubject:なら、それを書けばいいだけです。ETL内部だったら、そのまま日本
語のSubject:を書いても通ると思うよ。なーんも、難しくない。Subject行に
ISO-2022と違った方法でAscii/JIS漢字の切り替えをするのだから、MIMEは、す
っごく、難しいわけ。

>どうやったらできるでしょうか。

日本と海外のgatewayで書き換えてもいいと思う。あるいはISO2022を広めると言
う手もあるし。主に日本国内で使われているNews Groupなのに国外優先って言う
のも変ですよね。でもさ、To:に日本語を使う分けにはいかないでしょう? それでは、
国際免許やVISA cardが日本語だけで書いてあるようなものです。

---

---

From: [email-masked] (Wataru KawaKami)
Date: 28 Oct 93 08:47:05 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: MIMEの``乱入''(?) (was Re: headerにMIME導入について)

  NTTの川上です。捕足です。

  >> MIMEヘッダを推奨する、禁止する、という以外に、現状のまま放置する
ですが、
	MIMEをheaderに導入すること*そのもの*について、推奨する、
	禁止する、という以外に、現状のまま放置するという選択が
	あると思います。(`From:',`To:',`Subject:'および他の
	部分にいれることについて、入れる場所に関係なく)

という意味に私にはとれました。ですから、私の

  "fj.mail"の
  "Invasion of MIME (?) (was Re: header ni MIME dounyuu ni tsuite)"に $
    (記事<[email-masked]>)、[email-masked]、
  >> MIME-headerを`禁止'するという話しはでていないと思いますよ。
は、
	``MIMEをheaderのいかなる部分にも入れてはいけない''という
	話しはでていない

という意味です。

	MIMEをheader部分に導入する場合、場所は問うが、upper-compati-
	bility(From:, To:, Subject:の可読性)を損なわない、現在試行
	されているものを妨げることがなければ、`放置'しても問題はない

というのが、一連の私の記事で主張しているところです。

 "fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、
    [email-masked]$
 >> 今の方法じゃ「To:」とか「address」とか書いてある場所に「日本語」が入っち
 >> ゃう分けでしょう？  やっぱりまずいよ。例えば、To:にxfacesとか入っていた
                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >> らどうです？  同じことをやっているわけですよね。
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
まさしく、これですね。

  ちなみに、海外でも、MIMEを`To:',`From:',`Subject:'にいれる
という検討はなされているんでしょうか。 > MIME'er の皆様

  そこでの、議論を聞いてみたい気がしています。
						wataru

---

From: [email-masked] (Junzou Kamahara)
Date: 28 Oct 93 05:44:13 GMT

鎌原＠阪大情報です。

>   るわけでもないんですよね。いいわけは他だ一つ「asciiに見える」。Ambitious

 MIMEの利点は、送り手と受け手の合意だけで実現できるということです。
8bit throughは中継サイトすべてが合意しなければならず、現状では現実的で
あるとは思えません。

>   field に触っているのはinewsのfront endだけですから、いったん出てしまえば

 うちでは、日本語ヘッダは見たことありません。X-Nsubjectも見えません。
Subjectを見ていただければ分かる通り化けています。ありもしない問題で困っ
ているわけではありません。
--
--------------------------------------------------------------
鎌原 淳三(かまはら じゅんぞう)([email-masked])
大阪大学大学院基礎工学研究科物理系専攻情報工学分野前期課程２年
宮原研究室(Information Network Architecture Lab.)
				Multimedia System Research Group

---

From: [email-masked] (Kazuhiro Kazama)
Date: 28 Oct 1993 10:02:29 GMT

風間＠ＮＴＴ基礎研です。

 > # Subject, Fromが可読でないとすると、どこから、題目、送り主を

　さすがにMIMEでエンコードされた文字列だけだったら問題ですが、たとえば、
混在して表記したらどう思いますか？

	From: [email-masked] (Kazuhiro Kazama/風間 一洋)

とか…。こうすれば、とりあえずMIMEデコーダーを持っていなくても内容を認
識できるし、grepもできます。

　可読でないと何度も言われているようですが、単に変換ルーチンがないと言
い換えた方がいいのではないでしょうか？

　たとえば、急にUnicodeを採用することに決められてしまったら、変換ルー
チンがなくてみんな読めません:-P また"X-Nsubject:"がうまく通らなくてデ
コーダ作ったりしたこともあったのですしね。

　「可読じゃない」という理由でMIMEに反対するのは少し不適切だと思います
ので、どうせならMIME対応するためのコストとか、MIMEを採用するのが正当な
のか？という議論に集中した方がいいでしょう。

 > # 別のfieldを設けてやっていただく分には、構いませんが。

　別フィールドは結構面倒くさいと思います。特に現在社内でサブジェクトに
漢字を許している会社もすでにあるようですから、こういう所では文句がでる
ことでしょう。単純にローマ字変換されても、読みにくいだけですしね。

　議論としては、「ヘッダに日本語を何らかの方法で通したいか？」と「その
場合にどんな手法を用いるべきか？」、「マルチメディアニュースをどうする
か？」の３点を明確にして議論するといいんじゃないかなと思います。

　「マルチメディアニュースなんていらない」と思っている人は、MIMEなんか
反対でしょうし、「ヘッダに日本語を入れて欲しくない」という人は全部の試
みに反対でしょう。立場の違いで意見が別れている気がしています。
--
	風間 一洋 ([email-masked])
	NTT基礎研究所 情報科学研究部
	分散コンピューティング原理研究グループ

---

From: [email-masked] (Masataka Ohta)
Date: 29 Oct 93 04:54:09 GMT

In article <[email-masked]> [email-masked] (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) writes:

>MTAの入れ換えよりは

　あいもかわらず嘘が繰り返されて、あいもかわらず誰もそれに気がついてない、
ということのようですね。

>RFC1522 を読んで、私のウソを指摘しましょう。

　８２２読まれるともっと根本的な嘘がばれますから、１５２２でびびらせるの
は、馬鹿相手にｄｅｂａｔｅするにはよい作戦ですね。

　それでは、馬鹿のみなさん、さようなら。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 29 Oct 1993 14:42:27 GMT

On 10/29/93(13:11) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]>
 |  fj のニュースで日本語を流すため、中継するすべてのサイトで Bnews にパッ
 |チを当てていた事実はどこへ行ったのでしょう。Body 部のためにすべてのサ
 |イトで対応することが現実に出来たのに、なぜ heder だと「対応が難しい」
 |ことになるんですか？

アドレスフィールドを含めた日本語化／国際化を考える場合には特に、
（メイルによるreplyなど）ニュースとメイルを包括して考える必要が
あると思います。そうするとメイルシステムでの対応のコストが問題
になります。ニュースとメイルの違いは、

(1) ニュース配送システムの数と、メイル配送システムの数の違い
  　（おそらく桁が違う）

(2) ソースが公開されていて自分たちの手でインストールしたニュー
　  スシステムと、通常はシステム附属のものをそのまま使っている
　  メイルシステム（手が出せない場合もある）の違い

にあると思います。またボディとヘッダの日本語化／国際化の違いは、

(3) RFC822において単なる "text" の並びであった body と、複雑な
　  構文が与えられた header の違い

ということだと思います。今回の場合にはさらに、

(4) 日本語化と国際化の違い

ということも含まれています。これらによって、当時のニュースのボ
ディ部の日本語のコストと、RFC822メッセージ一般のヘッダの国際化
のコストを同等に考えるのは、無理があると思います。

笹部さんの案は、ヘッダを 8bit 透過にすれば技術的には解決すると
いうことで、ぼくもそれはそうかもしれないと思います。しかし、
それを普及させるためのコストは高いと思いますし、完全に普及する
まではメイルシステムレベルでエラーを起こす危険が大です。また、
国際的に通用する共通の文字コードを合意するという、政治的に大変
な問題に関わりたくないとも思います。（もちろんそのような活動は、
大変重要で貴いことであると思いますけれど）

　　　　　　　　　　　　　　　　 O O
┰── ─┰─ ┰　　  ／／＼^^　(   )  {サービス、自分のために}
┠─++佐藤＠ＥＴＬ　／　876m＼ _<   >_　　　　　　　　　　　　..
┸── 　┸　 ┸────────────────────── (- @)∋ ──┘
★MIMEエンコーダ/デコーダ発売中★etlport.etl.go.jp:pub/mime/mimehead.tar.Z
（緊急修理お願い中;_;）

---

From: [email-masked] (SASABE Tetsuro)
Date: Fri, 29 Oct 1993 04:11:28 GMT

In article <[email-masked]>
    [email-masked] (Junzou Kamahara) writes:

 |8bit throughは中継サイトすべてが合意しなければならず、現状では現実的で
 |あるとは思えません。

  なぜ現実的で無いと断言できるのですか？

 |Subjectを見ていただければ分かる通り化けています。ありもしない問題で困っ
 |ているわけではありません。

  存在する現実を見ていないだけでは？

  fj のニュースで日本語を流すため、中継するすべてのサイトで Bnews にパッ
チを当てていた事実はどこへ行ったのでしょう。Body 部のためにすべてのサ
イトで対応することが現実に出来たのに、なぜ heder だと「対応が難しい」
ことになるんですか？

--
笹部 哲郎（ささべ てつろう）                       [email-masked]
root に求められるもの:  高いモラルと低い労働単価

---

From: [email-masked] (Wataru KawaKami)
Date: Fri, 29 Oct 1993 03:22:10 GMT

### Japanese subject will be read as below: ###
X-Nsubject: headerが削られる？ (Re: headerにMIME導入について)

  NTTの川上です。

  議論の筋からは、それるので、
	Followup-To: fj.news.b
としましたが、ちょっと確認したいものですから。。。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite ($@L2$$(J...)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >>  うちでは、日本語ヘッダは見たことありません。X-Nsubjectも見えません。
"X-Nsubject:"フィールドが中継経路でおとされていて、そちら
ではフィールドそのものがないということでしょうか。
よろしくお願いします。
						wataru
# headerって勝手に削ってもいいもの？
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KawaKami)
Date: Fri, 29 Oct 1993 03:48:45 GMT

NTTの川上です。

[email-masked]、
  ============================================================================
  "fj.mail"の(記事<[email-masked]>)
  "Re: Invasion of MIME (?) (was Re: header ni MIME dounyuu ni tsuite)"について
  ============================================================================
  >> とか…。こうすれば、とりあえずMIMEデコーダーを持っていなくても内容を認
ですが、個人的には、現実問題として、From:とかが長くなるのは
どうかなと思っています。[1] (news/mail systemが単にcopyする
ヘッダーの部分なら、問題はないのでしょうけれど。。。)

  >> 　可読でないと何度も言われているようですが、単に変換ルーチンがないと言
ここはどうも、私には、抵抗があります。また、
[email-masked]、
  ============================================================================
  "fj.mail"の"Re: About MIME."について
    (記事<[email-masked]>)、
  ============================================================================
  >>
  >>  なにがまずいのか分かりません。mail/news-systemに関して、それでちゃん
  >> と送れるなら、meaningfulである理由はなにもありません。それこそ後は送り
  >> 手と受け取り手のUser-Interfaceの問題。
とおっしゃっておられますが、headerがなにがしかの変換ルーチンを
使わないと簡単には読めないシステムもinternetの外には、たくさん
あるかと思うのですが、internetでは、伝送の効率などからみると
効率の悪い`可読な'ascii文字列をheaderに使うという方法でいままで
進んできたことを考えると、少なくとも、古くから使われているheaderの
フィールドについては、readable/unreadableということがinternetでは
意味を持ってくるのではと思って、`可読'ということばを使っています。

# sendmail(smtp)が`hello'と会話するのをはじめて知ったときは、
# びっくりしました。

[email-masked]、
  ============================================================================
  "fj.mail"の
  "Re: Invasion of MIME (?) (was Re: header ni MIME dounyuu ni tsuite)"について
    (記事<[email-masked]>)、
  ============================================================================
  >> チンがなくてみんな読めません:-P また"X-Nsubject:"がうまく通らなくてデ
ですが、"X-Nsubject"は、別フィールドを設けてやっているので、
ここで、議論されている``From:',`Subject:',`To:'とかにascii-un-
readableをいれる'という話しとは別だと思います。

  "X-Nsubject"については、基本的に
	利益を受ける人が負担を受けて、利益を受けない人の
	負担は最小化する
という受益者負担の発想でやっています。

  (MIME+base64)-encodingも、別フィールドでやっていたら、特に
議論にはならなかったと思いますが、いかがでしょうか。

  >> ので、どうせならMIME対応するためのコストとか、MIMEを採用するのが正当な
`正当なのか'という議論を進めていくとした場合、具体的にはどの
ような論点で議論をしていくことを念頭におかれているかを示して
いただければ、意識合わせもできて、議論が円滑に進むと思うの
ですが、いかがでしょうか。

  私個人としては、いままで、私が思うところの
	`正当なのか'
ということを議論してきたように思っているので、そうでないと
すると、何をもって、
	`正当なのか'ということの議論
かを知りたいと思っています。

  >> 漢字を許している会社もすでにあるようですから、こういう所では文句がでる
それこそ、user-interfaceの問題ですよね？
# 受益者負担で考えれば、題目 != "Subject:"でも特に問題はない
# わけですから。

`From:',`Subject:',`To:'とかは、いままでのnews/mail-readerの
互換用においておいて、別途フィールドを設けて、そこでどんな
方式がいいかということを検討した方がすっきりするかなと思い
はじめています。

  >> か？」の３点を明確にして議論するといいんじゃないかなと思います。
今のところ、
	ヘッダに日本語を何らかの方法で通したい
人が、
	その場合にどんな手法を用いるべきか？
ということで
	どういった問題点があるか
ということを議論しているとwataruは理解していたので、戸惑って
いるのですが、具体的にどのような点が不明確なので、明確にすべ
きかを打ち出していただけると議論が円滑に進むのではないかと
思います。
					wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

[Reference]
1. 例えば、sendmail.
===============================================================
 Newsgroups: fj.mail
 Subject: address fields exceeding 128 bytes
 Message-ID: <[email-masked]>
 Date: 12 Jul 93 13:06:48 GMT

  ......
 アドレスを 128 で切ってしまうような古い sendmail も、まだ、
 あちこちに残っていると思います。RFC-1342 の多言語ヘッダを用
 いている方は、安全方向に振る意味でも、エンコード後の御自分
 のアドレスが 127 bytes 以下に収まるよう、注意された方が良い
 のではないかと思います。
 ....
===============================================================

---

From: [email-masked] (Shinji Kono)
Date: Fri, 29 Oct 1993 15:57:12 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Yutaka Sato) writes 
>いうことで、ぼくもそれはそうかもしれないと思います。

8bit等価じゃなくてJIS漢字をそのまま通すかですね。直接的にはescapeでしょう。

>のコストを同等に考えるのは、無理があると思います。

前はsendmailもfreeじゃなかったですしね。B-Newsはいじるの大変だったし。ど
ちらも今は違います。うれしい限りですね。C-Newsはshell/awk scriptを直すだ
けだし。inewsのtrとanne.jonesのtrだけがescapeを削っているところですか
ら。大半のNews / Mail front endはSubjectまで含めて日本語化されてますし。
さらにMIME化するかどうかのコストの問題だな。

ISO-2022は日本でしか通用しないだろうというならそうかも知れません。西洋人
は英語と自国語を一つの文の中で切替えて使うというのをしないんですよね。
段々変わるとは思うのですけど。IRCとか新しいプロトコルはISO-2022でもいい
んだけど。でも、From: にMIMEを入れている人は海外と日本とで使い分けている
の? そういうの国際化っていうのかなぁ。

>まではメイルシステムレベルでエラーを起こす危険が大です。

Mailでも内部EUC/SJISのところでも、Network codeはJIS、あるいはmlocalでnkf
してしまっているところが大半なはずです。現実にJISのheaderはぽろぽろ出し
まっているというところでしょう。GyRAOjRGI0stGy とかいうコードが見えると
いうならMIMEだろうとISO-2022 だろうと、それほど差はないですね。

>な問題に関わりたくないとも思います。（もちろんそのような活動は、

だったらMIMEの布教もしなければいいのに。政治的な手間はMIMEだろうが
ISO-2022だろうがおんなじだと思いますけど。僕みたいな奴がいる限り。僕だっ
てもう少し佐藤さんが頑張れば改宗するかも知れません。例えばheaderをmulti
media化する必要があるのならMIMEも仕方ないと思えるのですけど...

---

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 29 Oct 1993 17:31:52 GMT

On 10/30/93(00:57) [email-masked] (Shinji Kono) wrote
in <[email-masked]> (fj.mail:2297/etlss2):
 [email-masked]。
 |In article <[email-masked]> , 
 |	[email-masked] (Yutaka Sato) writes 
 |>笹部さんの案は、ヘッダを 8bit 透過にすれば技術的には解決すると
 |>いうことで、ぼくもそれはそうかもしれないと思います。
 |
 |8bit等価じゃなくてJIS漢字をそのまま通すかですね。直接的にはescapeでしょう。

いいえ。河野さんは笹部さんの案に賛成だったはずですが、中身は読まれて
ないんでしょうか？

JIS漢字っていうのも良くわからないんですが、escapeと言われているから
ISO-2022-JP(JUNETコード)の事だと解釈しますと、問題は escapeだけでは
ありません。問題はむしろ、繰り返し指摘されているように、RFC822の
"specials"「()<>@,;:¥".[]」です。これら、RFC822 の構文をかたち作る
文字は、JIS-2バイトコードの1バイト目/2バイト目にどんどこ出てきます。
例えば、

　　1) To: kono (河野真治)
　　2) To: 河野真治 <kono>
　　3) To: "河野真治" <kono>

をエスケープ抜きで考えても、つまり、

　　1) To: kono ($@2OLn??<#(J)
　　2) To: $@2OLn??<#(J <kono>
　　3) To: "$@2OLn??<#(J" <kono>

も、いずれも問題です。最初の２つは構文エラーです。これらに対して例え
ば、SunOS4.1.3のsendmailで 1)は、

    % /usr/lib/sendmail -t
    To: kono ($@2OLn??<#^[()
    ^D
    kono ($@2OLn??<#^[()... Unbalanced '('
    Segmentation fault

となります。2)も同様。これが、デーモンとして走っている sendmailで起
きたら悲劇です。3)は、To: "$@2OLn??<kono(" <kono> のように壊れて届き
ました。これは、実装の問題なのでしょう。

もちろん「文字列がISO-2022でエンコードされている」ことを認識していれ
ば、JISの２バイトコードに含まれる specialsを、ASCII のspecialsと混同
することはありません。ただ、そのためにはISO-2022の制御コードと現在の
文字セットを認識するよう、sendmailなどを作りかえる必要があるでしょう。
（賢い太田さんは、そうしなくて済む案を持っているのかも知れないですが。
　馬鹿には想像もつきません）

我々はそのようなソフトウェアは作り慣れていますが、実際にはISO-2022-
JPでは、ISO-2022のごく限られた機能しか使っていません。ISO-2022全体は
目がまわるほど複雑（しかも拡張可能だったりしますよね）らしいので、
国際化のためにこれを sendmail に認識させたりするのは気の毒です。
だれかがやってくれるのなら有難いとは思います。でも、それが完全に普及
するまでは、恐くて使えません。実際、ISO-2022嫌いの多いらしい欧米で、
これを普及させるのは至難だと思います。

笹部さんの案は、このようなISO-2022によるASCII/非ASCIIの区別を避ける
ために、非ASCIIは全て最上位ビットが立った状態で表すと言うものです。
たしかに実現は簡単になります。でも、最上位ビットがどこかで落ちた時の
悲劇は同様でしょう。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 29 Oct 1993 18:51:23 GMT

On 10/30/93(00:57) [email-masked] (Shinji Kono) wrote
in <[email-masked]> (fj.mail:2297/etlss2):
 |>ということも含まれています。これらによって、当時のニュースのボ
 |>ディ部の日本語のコストと、RFC822メッセージ一般のヘッダの国際化
 |>のコストを同等に考えるのは、無理があると思います。
 |
 |前はsendmailもfreeじゃなかったですしね。B-Newsはいじるの大変だったし。ど
 |ちらも今は違います。うれしい限りですね。C-Newsはshell/awk scriptを直すだ
 |けだし。inewsのtrとanne.jonesのtrだけがescapeを削っているところですか
 |ら。大半のNews / Mail front endはSubjectまで含めて日本語化されてますし。
 |さらにMIME化するかどうかのコストの問題だな。

user agent(UA) 内部にMIME化のためのコードを埋め込むことは、必ずしも
必要ではありません。MIMEエンコーダ／デコーダをUAとTransfer Agent(TA)
の間に噛ませるだけで済みます。これで、UAはあたかも自分のローカルコー
ドで外部とやりとりしているように見えるわけです。

        ----------------------
        | Transfer Agent     | nntpd, sendmail, pop など
        ----------------------
           ｜    MIME     ↑
           ｜← encoded →｜
           ｜    text     ｜
          MIME           MIME
         decoder        encoder
           ｜    local    ｜
           ｜←  code   →｜
           ↓    text     ｜
        ----------------------
        | User Agent         | ニュース／メイルリーダ
        ----------------------

TAの中の、UAとのインターフェイス部分にエンコーダ／デコーダを仕込めば、
複数の（日本語対応の）UAを自動的にMIME対応にできます。また、MULEなど
による国際化が普及すれば、それをローカルコードとすることもできます。
＃実際、ぼくはMIME<->ISO-2022-JP対応のnntpdへのパッチを去年の7月に
＃作って配っています(<[email-masked]> <[email-masked]>)

別の方法としては、TA同士の通信をMIMEにして、TAがスプールに落としたり
UAから受けとる時にMIMEデコード／エンコードすることもできるでしょう。
JIS/{EUC,SJIS} の自動変換をやっている場合には、そこに噛ませれば良いと
思います。

 |ISO-2022は日本でしか通用しないだろうというならそうかも知れません。西洋人
 |は英語と自国語を一つの文の中で切替えて使うというのをしないんですよね。
 |段々変わるとは思うのですけど。IRCとか新しいプロトコルはISO-2022でもいい
 |んだけど。でも、From: にMIMEを入れている人は海外と日本とで使い分けている
 |の? そういうの国際化っていうのかなぁ。

韓国でもハングルメイルをISO-2022で実現していると聞きました。ただ、
ISO-2022-JP で使っているのとは違うコーディングシステムだそうですが。
なおぼくは、From: [email-masked] (Yutaka Sato 佐藤豊) にしています。
何が国際化なのか、という文化的な話はよくわかりません。

 |>それを普及させるためのコストは高いと思いますし、完全に普及する
 |>まではメイルシステムレベルでエラーを起こす危険が大です。
 |
 |Mailでも内部EUC/SJISのところでも、Network codeはJIS、あるいはmlocalでnkf
 |してしまっているところが大半なはずです。現実にJISのheaderはぽろぽろ出し
 |まっているというところでしょう。GyRAOjRGI0stGy とかいうコードが見えると
 |いうならMIMEだろうとISO-2022 だろうと、それほど差はないですね。

アドレスフィールド中のISO-2022-JPは、エンコードなりquotationなりをし
ないと、配送経路のTAを壊す可能性があります（<[email-masked]>）
あるいはTAにより変形されてしまう（字化けする）可能性もがあります。
（太田さんが言ったEBCDICゲートウェイがどうのというやつです）
MIMEの"BASE64"エンコーディングはそのような危険のないコードです。

 |>国際的に通用する共通の文字コードを合意するという、政治的に大変
 |>な問題に関わりたくないとも思います。（もちろんそのような活動は、
 |>大変重要で貴いことであると思いますけれど）
 |
 |だったらMIMEの布教もしなければいいのに。政治的な手間はMIMEだろうが
 |ISO-2022だろうがおんなじだと思いますけど。僕みたいな奴がいる限り。僕だっ
 |てもう少し佐藤さんが頑張れば改宗するかも知れません。例えばheaderをmulti
 |media化する必要があるのならMIMEも仕方ないと思えるのですけど...

ぼくは、政治やシステムに関わらずにユーザレベルで出来る方法を選び
ました。それにかかるコストと、またそれで実現出来る機能が見合う
ものだとも思っています。だけど、そのコストの評価は人それぞれでしょ
うから、別の方法を取ることに反対はしていないつもりです。実際、メッ
セージ全体を８ビット透過にするというような話は、実現してもらえると
有難いと思っています。だけど、その実現はMIME化にくらべると、とても
難しいと思うので、その実現を待っていられないのです。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 29 Oct 1993 19:22:13 GMT

On 10/29/93(13:54) [email-masked] (Masataka Ohta) wrote
in <[email-masked]> (fj.mail:2288/etlss2):
 |In article <[email-masked]> [email-masked] (Yutaka Sato 佐藤豊) writes:
 |>MTAの入れ換えよりは
 |>MUAの入れ換えが現実的だと思ったからです。
 |
 |　あいもかわらず嘘が繰り返されて、あいもかわらず誰もそれに気がついてない、
 |ということのようですね。
 |
 |>RFC1522 を読んで、私のウソを指摘しましょう。
 |
 |　８２２読まれるともっと根本的な嘘がばれますから、１５２２でびびらせるの
 |は、馬鹿相手にｄｅｂａｔｅするにはよい作戦ですね。

太田さんの禅問答も、脅しとしては効果的ですね。さすが(^_^)
実際、みなさんがＲＦＣ８２２を読んで僕の嘘を教えて下さると
ありがたいです。（自分では、何が嘘かわからないんです）

 |　それでは、馬鹿のみなさん、さようなら。

あれあれ。何が嘘なのか、ヒント教えてくれてからでもいいのに。
そうしないと、単なる脅しじゃないかと馬鹿はかんぐりますよ。

On 10/22/93(18:13) [email-masked] (Masataka Ohta) wrote
in <[email-masked]> (fj.mail:2201/etlss2):
 |　８２１／８２２のままで、ＩＳＯ−２０２２−ＪＰを含めて７ｂｉｔのＩＳＯ
 |２０２２は全部通るから、それで国際化は問題なかったと思いますが？
 |
 |　ＥＢＣＤＩＣでも使うとか、ＢＩＴＮＥＴで似非８２２使ってる邪悪な地域で
 |は７ｂｉｔがちゃんと通らないとかいう後ろ向きの発想を無視すれば。
 |
 |                                      太田　昌孝
 |                                      [email-masked]

太田さんの「問題ない」っていうのは、馬鹿どもの現実など問題
でないということなのかもしれませんが。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sat, 30 Oct 1993 06:23:28 GMT

On 10/30/93(08:58) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]> (fj.mail/ripspost:717/etlss2):
 |  無理矢理specialsを回避するより、別フィールドを設けたほうが、
 |すっきりすると思います。

Subjectだけの、日本語化だけを考えるならそうでしょうね。

 |  二つのフィールドを設けることについては、例えば、X-Nsubjectの
 |実装法を例に取ると、inewsに渡す前に、フィルターを被せて、
 |	User-I/F		news-field
 |	Subject:      ->	X-Nsubject:
 |	Subject:   -(filter)-> 	Subject:
 |としてしまえば、ほとんど問題はないだろうし。。。。

例えば、Ccなどにに並んだ、色んな国の(文字コードの)複数
人の名前を「別フィールド」で表現するのは簡単でしょうか？

 |# 転送系で、処理するより、User-interfaceで処理するほうが簡単そう。

それがMIMEの方針です。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Shinji Kono)
Date: Sat, 30 Oct 1993 02:55:38 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Yutaka Sato) writes 
>　　1) To: kono (河野真治)

川上さんとか僕の意見はTo:/Subject:ではMIME/JIS漢字は使わない
です。EUCでやればいいじゃんというのが笹部の意見なら、それは
あんまりうれしくはないな。

海外で通るかという問題でescapeが落ちた場合をいっているわけでしょうけど、
そういうときって英語で送るし... 

escapeが落ちないなら、もちろんSony NEWSのsendmailでは、ちゃんと通るんで
すけどね。JLEでJISが通らないのは、EUC/SJISがJLEでのsupportですから仕方な
い。EUC/SJISではJLEでも大丈夫なのです。

そういうところだとMIMEをinstallする手間は重い。なんか苦労して、結局、何
も新しいことはできない。これは、ちょっとさびしい。gatewayで処理できるな
らそうしたいところです。

が、その手間はMIMEだから軽いというわけじゃない。ユーザレベルで処理できる
から便利だとは限らないんです。特にMH+rn+viの僕には、なんか全然うれしくな
い。gatewayでX-Nsubject化してしまおうか...

>JPでは、ISO-2022のごく限られた機能しか使っていません。

ISO-2022はそういう風に使うものと僕は理解しています。MIMEでも、では現実に
どういうcodingを使うかいう問題は残っています。少なくともfjではISO-2022の
特定のsubsetという基準があるわけですから、それを利用したいところですね。

---

---

From: [email-masked] (Kazuhiro Kazama)
Date: 29 Oct 1993 11:29:24 GMT

風間＠ＮＴＴ基礎研ですね。

 > ヘッダーの部分なら、問題はないのでしょうけれど。。。)

　このsendmailのバグは確かに困ったものです。実際には私が書いたような表
記はよく使われていてほとんど問題がないようです。しかし、遊びのメッセー
ジを使って表記を長くするとこのバグに引っ掛かってしまうんですよね。

　すでに新しいsendmailでは問題が起こらないようになってますから、ある意
味ではそういうメッセージを入れないことで当面回避できる問題かもしれませ
ん。

 > 意味を持ってくるのではと思って、`可読'ということばを使っています。

　それは違うと思います。今の使われ方では、別にローカルでEUCとかSJIS使っ
ている場合に変換することと何の変わりもないと思います。SJISとかEUCの場
合もコード変換しなければ「可読」でない場合があります。

 > readableをいれる'という話しとは別だと思います。

　それでいいと思います。

　本気でやるのならX-Nsubject:を強制するより、よりすなおな形で…たとえ
ばISO-2022などのなんらかの漢字コードを通すようにすべきだと思いますから。

　私は同様にSubject:やFrom:などを全部MIMEで変換しなければ、特に否定は
しないと思います。

 > 議論にはならなかったと思いますが、いかがでしょうか。

　MIMEが特に問題だったのは、対応プログラムを持っていなければ読めなかっ
たが普及していなかった点と、導入時でいくつかの問題を起こした点でしょう。
別フィールドというのはそれほど関係ないと思います。

　もちろん、日本語を使えるようにするためにMIMEを用いるかどうかというの
は、前にも述べた通り別問題です。

 > ということを議論してきたように思っているので、そうでないと

　たとえば、MIMEの変換と漢字コード変換は変換という点では同一視するべき
ものですが、わざわざ別の物として考えている点などですね。そもそも立脚点
が間違っていれば、正当性の評価はできません。

 > それこそ、user-interfaceの問題ですよね？

　いや違います。前の投稿で述べた問題は本質的にユーザインターフェースで
は解決できない問題で、たとえばすでに社内で漢字のサブジェクトを使ってい
る人にとっては、

・題名を２種類入力するのは面倒である。
・題名を例えばローマ字などに自動変換してもよみにくい。

という問題はユーザインターフェースがすぐれていても解決できません。自動
変換が進歩して英語に変換してしまえば読みやすいでしょうが:-P

　やはり本格的に導入するとなると、もっとシームレスで自然なものが望まれ
るわけです。

 > # 受益者負担で考えれば、題目 != "Subject:"でも特に問題はない

　？

 > 方式がいいかということを検討した方がすっきりするかなと思い

　多分ここが違うのでしょう。私の意見は、別フィールドを設けることで妥協
するよりも、

・"Subject:"にそのまま日本語が使えるようになって欲しい。
・できれば"From:", "To:"にも日本語が使えて欲しい。

と思います。その上で、どんな方法を取った方がよいか議論したいと思ってい
ます。私は手法の方は別にMIMEに拘っていません。どちらかというとある漢字
コードをそのまま通すとか国際的なコード系…たとえばISO-2022かな…などを
使用して欲しいのですけどね。

　この場合には当然過渡期には「サブジェクト」が川上さんの言葉で言うと
「可読」でない時期が出てくることでしょう。要するにいつまでも不便なまま
で我慢するか、ある時期少し苦労しても便利さを享受するかの選択だと思いま
す。

　日本語のニュースを利用できるようにするために同じことを行なってきたの
ですから、もう一度やってもいいと思いますけどね。

 > きかを打ち出していただけると議論が円滑に進むのではないかと

　そもそも一番最初の「ヘッダに日本語を何らかの方法で通したい」という点
で、

1, Subject:だけ
2, From:まで使いたい。
3, （MIMEなどで）ボディ部まで処理したい。

という立場があるので、なかなか手段が一致しないと思うわけです。3を考え
ている人はヘッダまで同様に…と思うでしょうし、1だけなら2を考慮するより
容易な方法を提案するでしょう。
--
	風間 一洋 ([email-masked])
	NTT基礎研究所 情報科学研究部
	分散コンピューティング原理研究グループ

---

From: [email-masked] (Kazuhiro Kazama)
Date: 29 Oct 1993 11:46:18 GMT

風間＠ＮＴＴ基礎研です。

In article <[email-masked]> [email-masked] (Shinji Kono) writes:
 > のも変ですよね。でもさ、To:に日本語を使う分けにはいかないでしょう?
 > それでは、国際免許やVISA cardが日本語だけで書いてあるようなものです。

　アドレスが特定できれば、日本語が附加されるとうれしいとは思います（こ
こでは手段とかその実現可能性とは考慮していません）。

　たとえば私の名前をローマ字表記すると"Kazuhiro"になりますが、一洋、一
弘、和広、一広…って沢山ありますからかなりあいまいです。

　あとやっぱり日本語表示された方が認識力が高いんじゃないかな。

＃　せめてサブジェクトは日本語が可能になって欲しいですね。
--
	風間 一洋 ([email-masked])
	NTT基礎研究所 情報科学研究部
	分散コンピューティング原理研究グループ

---

From: [email-masked] (Wataru KawaKami)
Date: Sat, 30 Oct 1993 04:25:07 GMT

### Japanese subject will be read as below: ###
X-Nsubject: rfc822より (was Re: headerにMIME導入について)

  NTTの川上です。芸風はともかく、
  "fj.mail"の"Re: header ni MIME dounyuu ni tsuite"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> は、馬鹿相手にｄｅｂａｔｅするにはよい作戦ですね。
ということで、rfc822を再読してみました。

  rfc822の基本は、

	rfc822は、ARPA(ineternet)におけるコンピュータユーザー間の
	"電子メール"という枠組みの中で*テキスト*メッセージ転送を
	行なうときの標準を定めたものである。

	メッセージは、envelope(header)とcontents(body)からなり、
	envelope(systemのheader)は、システムが伝送や配送を達成する
	ための情報を含むもの

ということですね。つまり、基本は、header部分は、systemが*解釈*する
ことを前提している部分であるとなっています。(英語でご覧になりたい
方のために、該当部分をこの記事につけました。)

  ですから、厳密に、規格に従うのであれば、本来は、人間が読み書きする
部分は、contents(body)にいれるのが筋のようです。

  参考までに、他の電子メールシステムについて見てみたところ、inter-
net-mail/newsと並ぶ位有名な、e-mailシステムであるMOTIS(X.400)の
場合は、メールは、envelopeとmessageから成っているようです。

  envelopeが配送などのために使われる部分で、userからは、直接見えない
ようです。messageはheaderとbodyからなっています。envelopeは、ちょうど、
郵便の宛名の部分に相当しており、headerが、英語の手紙の頭(送り主の名前、
住所日付を書きます)の部分、bodyがちょうど文章の内容になります。

  そういう意味では、internet-mail/newsのheaderは、宛名と手紙の頭の
部分を足し併せたようなものですね。

  これを考えると、"From:"とかに日本語を入れるということは、手紙の
宛名に日本語を書くということと同じようなものですね。MIME+base64に
至っては、bar-codeを書くようなもんですね。別ヘッダーを付けるのは、
宛名面の隅に併記するのと同じですね。

# 考えてみたら、外国に手紙を出すのに、わざわざ日本語で宛名を書く、
# 併記する人は、いませんよね。。。。。

  また、<text>という記述が多数出てくるのですが、これって、readable-
asciiということではないでしょうか。ご参考まで。

						wataru
p.s.
  rfc822って基本的には、電子メール実装の概念(framework)と最低限の
文法について書いたものですね。(向こうの人は、概念を大事にしますから。)
  これの抜け道をつつく実装は、向こうの人には受け入れられないと
思いますがいかがでしょう。(単に規則が厳しくなるだけだと思います。)
(それとも、internetのMOTIS化を狙っている？)
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

[[Reference]]
1. タンネンバウム著、斉藤他訳、"コンピュータネットワーク"

[[rfc822より抜粋]]
=================================================================
     1.  INTRODUCTION

     1.1.  SCOPE

    ..........

          In this context, messages are viewed as having  an  envelope
     and  contents.   The  envelope  contains  whatever information is
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     needed to accomplish transmission  and  delivery.   The  contents
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     compose  the object to be delivered to the recipient.  This stan-
     dard applies only to the format and some of the semantics of mes-
     sage  contents.   It contains no specification of the information
     in the envelope.

     .............

     1.2.  COMMUNICATION FRAMEWORK

     .......

          Messages consist of lines of text.   No  special  provisions
     are  made for encoding drawings, facsimile, speech, or structured
     text.  No significant consideration has been given  to  questions
     of  data  compression  or to transmission and storage efficiency,
     and the standard tends to be free with the number  of  bits  con-
     sumed.   For  example,  field  names  are specified as free text,
                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     rather than special terse codes.
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          A general "memo" framework is used.  That is, a message con-
                                                        ~~~~~~~~~~~~~~
     sists of some information in a rigid format, followed by the main
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     part of the message, with a format that is not specified in  this
     ~~~~~~~~~~~~~~~~~~~~
     document.   The  syntax of several fields of the rigidly-formated
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     ("headers") section is defined in  this  specification;  some  of
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     these fields must be included in all messages.

     ........

     3.1.2.  STRUCTURE OF HEADER FIELDS

     ........

        Certain field-bodies of headers may be  interpreted  according
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        to  an  internal  syntax  that some systems may wish to parse.
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        These  fields  are  called  "structured   fields".    Examples
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        include  fields containing dates and addresses.  Other fields,
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        such as "Subject"  and  "Comments",  are  regarded  simply  as
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        strings of text.
        ~~~~~~~~~~~~~~~~

        Note:  Any field which has a field-body  that  is  defined  as
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               other  than  simply <text> is to be treated as a struc-
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               tured field.
               ~~~~~~~~~~~~

               Field-names, unstructured field bodies  and  structured
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               field bodies each are scanned by their own, independent
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
               "lexical" analyzers.
               ~~~~~~~~~~~~~~~~~~~~

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sat, 30 Oct 1993 19:41:54 GMT

On 10/30/93(13:25) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]> (fj.mail:2313/etlss2):
 |    [email-masked]、
 |  >> 
 |  >> 　８２２読まれるともっと根本的な嘘がばれますから、１５２２でびびらせるの
 |  >> は、馬鹿相手にｄｅｂａｔｅするにはよい作戦ですね。
 |ということで、rfc822を再読してみました。
...
 |	メッセージは、envelope(header)とcontents(body)からなり、

ほんとうですか？

 |[[rfc822より抜粋]]
....
 |     This stan-
 |     dard applies only to the format and some of the semantics of mes-
 |     sage  contents.   It contains no specification of the information
 |     in the envelope.

なのでは？　ただ、これに続いて

>>          However, some message systems may use information  from  the
>>     contents  to create the envelope.  It is intended that this stan-
>>     dard facilitate the acquisition of such information by programs.

だから、envelopeとcontentの表現(RFC822)は実装上密接に関係があると。

太田さんの禅問答は「envelope作る時にISO-2022-JPの部分を捨てちゃえ」
と解くのかな？　「MTAの入れ換えが必要」の部分を嘘と言ってたし。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Wataru KawaKami)
Date: Fri, 29 Oct 1993 23:58:13 GMT

### Japanese subject will be read as below: ###
X-Nsubject: *解釈*されるフィールド (was Re: [MIME] (ISO-2022 + JIS)....)

  NTTの川上です。

  "fj.mail"の"[MIME] (ISO-2022 + JIS) / RFC822 = ?"について
    (記事<[email-masked]>)、[email-masked]、
  >> "specials"「()<>@,;:\".[]」です。これら、RFC822 の構文をかたち作る
これって、まさしく、mail/news-systemがheaderのフィールドを
*解釈*しているから、specialsが存在するのではないでしょうか。

  もし、単にcopyしているのなら、そんなものは存在するはずは
ないですよね？

  無理矢理specialsを回避するより、別フィールドを設けたほうが、
すっきりすると思います。

  二つのフィールドを設けることについては、例えば、X-Nsubjectの
実装法を例に取ると、inewsに渡す前に、フィルターを被せて、
	User-I/F		news-field
	Subject:      ->	X-Nsubject:
	Subject:   -(filter)-> 	Subject:
としてしまえば、ほとんど問題はないだろうし。。。。
(inewsに渡す前に被せるフィルターは、以前、fj.sourcesに投稿した
	ConvInews.sh
をちょっと変更すればできてしまいます。入り用なら、手なおしして、
再出荷しますが。。。。)
						wataru

# 転送系で、処理するより、User-interfaceで処理するほうが簡単そう。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KawaKami)
Date: Sat, 30 Oct 1993 23:07:06 GMT

### Japanese subject will be read as below: ###
X-Nsubject: `封筒'と`中身' (was Re: rfc822より ....)

  NTTの川上です。

  "fj.mail"の
  "Re: From rfc822 (was Re: header ni MIME dounyuu ni tsuite)"について
    (記事<[email-masked]>)、[email-masked]、
  >> ほんとうですか？
 rfc822の頭の部分(SCOPE)にかいてあります。(下記参照。)これは、
  >>  |	メッセージは、envelope(header)とcontents(body)からなり、
としかとれないのですが、いかがでしょうか。

  rfcでは、envelopeとcontentsしか書いていないのですが、今までの
議論ででてくるheaderとbodyは、まさしくこれの意味で皆さん使って
ますよね？
  ここを見るかぎりでは、header部分に関しては、各fieldのsemanticsも
定義しているとかいてあります。

# ``rfcxxxxを読んでいないと議論が。。。''という割に。:-) > ysatoさん
# という私も、うろおぼえだった。:-<

[rfc822より]
=============================================================================
     Standard for ARPA Internet Text Messages

     1.  INTRODUCTION

     1.1.  SCOPE

     .......

          In this context, messages are viewed as having  an  envelope
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     and  contents.   The  envelope  contains  whatever information is
     ~~~~~~~~~~~~~~        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     needed to accomplish transmission  and  delivery.   The  contents
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     compose  the object to be delivered to the recipient.  This stan-
     dard applies only to the format and some of the semantics of mes-
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     sage  contents.   It contains no specification of the information
     ~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     in the envelope.
     ~~~~~~~~~~~~~~~
============================================================================

  >>  |     sage  contents.   It contains no specification of the information
この部分は、``封筒の中身''(所謂 body部分)についてはここrfc822では
定義していないという意味ですね。

  >> だから、envelopeとcontentの表現(RFC822)は実装上密接に関係があると。
これが本質だとwataruは理解しています。(特に、envelopeのfieldの
formatおよびsemantics。)
  headerは、基本的にsystemが解釈するものという私の理解も間違って
いなかったようです。そういう意味では、我々が日頃使っているmail/
news-readerは、systemが解釈する部分を例えば、題目、送り主を表示
するために流用しているに過ぎないということが言えそうですね。

						wataru
p.s.1   > ysatoさん
失礼かもしれませんが、もし読まれていないのでしたら、一度、コン
ピュータネットワーク(タンネンバウム著、斉藤他訳)の該当箇所を読ま
れてみることをおすすめします。ARPANET(internet)における電子メー
ルについて、基本的な説明はでていました。(p691)  
先の記事で書いたMOTIS(X.400)との比較、mail-gatewayについては、
p693です。 

p.s.2 (joke)
  へたにいじると、せっかくのsimple-mail-transfer-protocolが
complicated-mail-transfer-protocolになっちゃう。:-<

---

From: [email-masked] (Wataru KawaKami)
Date: Sun, 31 Oct 1993 00:56:51 GMT

### Japanese subject will be read as below: ###
X-Nsubject: jis7をheaderに通す (was Re: MIMEの``乱入''(?)....)

  NTTの川上です。

 "fj.mail"の
 "Re: Invasion of MIME (?) (was Re: header ni MIME dounyuu ni tsuite)"について
    (記事<[email-masked]>)、[email-masked]、
  >> ばISO-2022などのなんらかの漢字コードを通すようにすべきだと思いますから。
ちなみに、私は強制などしていません。:-)

  rfc822では、"Subject:"にjis-7が通ることになっています。[1]
"X-Nsubject:"を考えたころは、それが規格に明記されていることを
知らなかったし、現実問題としてほとんどのsiteでjis-7が通って
いませんでした。それを無理矢理jis7を"Subject:"に通して、他の
人に無意味な文字列を強制(見ざるを得ない状態と)するより、別フィ
ールドを設けて迷惑のかからない形で対応したかったというのが、
"X-Nsubject:"です。
  "Subject:"に規格どおり、jis-7が通るようになったら、それは、
私もその方が簡単でいいとは思います。(X-Nsubjectを育ててきたと
いう未練は別途ありますが。:-) )
# あとは、海外との問題でしょう。

  ですから、過渡段階としては、MIME+base64を使うより、jis7を
なまに通して、ECSが落ちるところでは、無理矢理埋めてやる(今の
"X-Nsubject:"でやっている方法)の方が簡単だと前から思っています。

# そういう意味では、"X-Nsubject:"は、encode/decodeはやって
# いません。単に、rfc822にのっとっていない経路で落ちるESCを
# 埋めているだけです。

  .......
  >> ものですが、わざわざ別の物として考えている点などですね。そもそも立脚点
kazamaさんは、
	1) 目に見える文字 <-> 2進数 の対応関係を示した符号
		jis7,ascii,euc,sjisなど
	2) 2進数 <-> 2進数 の対応関係を示した符号
		base64,uuencode,ishなど
を同じもののように扱ってらっしゃるように思えるのですが、いかが
でしょうか。うえの二つは本来違うものと思いまし、扱いを変えるのも
当然だと思います。(それとも、MIME+base64って、1)なんでしょうか。)

  >> 別フィールドというのはそれほど関係ないと思います。
おおいに関係あります。少なくとも、私やkonoさんが反対している
のは"Subject:"などのフールドに入ってきて、見ざるを得なくなって
きたからです。

#これを無視して、`関係ない'といいはるのは、いい加減やめてください！

個人的には、私も含めて、
   自分が普段読んでいる画面に"読めない、もしくは、読むために
   手間がかかる、よみづらい"文字列を見ざるを得ないのがいや
だから、みんな反対するのだと 思うのですが。
#  newsgrazerのuuencodededされたbodyが投稿されたときもそうでしたよね。

  >> は解決できない問題で、たとえばすでに社内で漢字のサブジェクトを使ってい
に関しては、自動変換すればよいので、問題ではありませんね。
# 私は大抵そうしています。

 >> ・題名を例えばローマ字などに自動変換してもよみにくい。
読みにくいのは、MIME+base64とて同じです。:-<

これって、まさしく、
   自分が普段読んでいる画面に"読めない、もしくは、読むために
   手間がかかる、よみづらい"文字列を見ざるを得ないのがいや
ですよね。
# この点は、"X-Nsubject;","MIME+base64"の双方とも、五分五分ですね。

  >> コードをそのまま通すとか国際的なコード系…たとえばISO-2022かな…などを
これは、いまのrfc822の基づくinternetでの話をされているのでしょうか。

確認のため書きますが、rfc822では、headerは手紙における封筒に当たる
もので、基本的にsystemが*解釈*(parse)するものと*決められて*います。
yheaderのfieldの名前の付け方、中身(contents)、用途(semantics)、などに
ついて*rigid*に決まっています。
=============================================================================
          A general "memo" framework is used.  That is, a message con-
     sists of some information in a rigid format, followed by the main
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     part of the message, with a format that is not specified in  this
     document.   The  syntax of several fields of the rigidly-formated
                                                      ~~~~~~~~~~~~~~~~
     ("headers") section is defined in  this  specification;  some  of
     ~~~~~~~~~~~~~~~~~~~
     these fields must be included in all messages.
=============================================================================
# もし読まれていないようでしたら、rfc822をちゃんと読んで、ここを
# 理解してください。>kazamaさん

  rfc822では、"Subject:"は書式の決まっていないfieldであり、コメント
的なものとして扱っているようで、jis7は規格上通ります。しかし、
"From:"や"To:"は、書式が決まっている(structured)fieldであり、systemが
解釈できる(machine-usable(addr-specs)))ことが要求されています。
  よって、入力可能だからといって、ここに余分な情報をいれるのは好ま
しくありません。

  ですから、我々が普段使っているnews/mail-readerは、本来systemが
みて解釈する部分である、header(手紙の封筒)にかかれている情報を題目
などとして*流用*しているに過ぎません。

  ここを前提にしないと、実りある議論はできないと思います。

# rfc822を読めば読むほど、別ヘッダーにするか、bodyにいれるように
# 考えるのが筋かと考えるようになりました。:-<

  >> 　日本語のニュースを利用できるようにするために同じことを行なってきたの
そういう意味では、"Subject:"に無理矢理jis7を通して、経路が対応
するまでは、暫定的に無理矢理ESCを埋めるなどして(実用上問題が
ないことは、"X-Nsubject:"の実装が示している)待つほうがよっぽど
最終目標に近いと思うのですが、みなさん、いかがでしょうか。

						wataru

[[reference]]

1. "fj.mail"の"field no KU-BUN. (was Re: Summary of status......)"について
    (記事<[email-masked]>)、[email-masked]、
  >> X-Nsubject: fieldの区分 (Re: 状況をまとめると.... )
  ......
  >>   ちなみに、rfc822を読むかぎりでは、unstructured fieldのcontentsは、
  >> 	any ASCII character (0-127 (decimal))
  >> となっているので、"Subject:"は、mohtaさんがいうように、規格上は、
  >> jis-7が通る筈ですね。

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sun, 31 Oct 1993 09:18:10 GMT

On 10/31/93(08:07) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]> (fj.mail:2317/etlss2):
 |  >>  |	メッセージは、envelope(header)とcontents(body)からなり、
 |としかとれないのですが、いかがでしょうか。
 |
 |  rfcでは、envelopeとcontentsしか書いていないのですが、今までの
 |議論ででてくるheaderとbodyは、まさしくこれの意味で皆さん使って
 |ますよね？
...
 |# ``rfcxxxxを読んでいないと議論が。。。''という割に。:-) > ysatoさん
 |# という私も、うろおぼえだった。:-<

RFC822には「envelopeとは何か」を抽象的にしか書いてないわけですが、
これはそれが RFC822のスコープの外だからでしょう。また、envelopeは
SMTP等のプロトコル上でcontentとは別にやりとりされ、ユーザには見え
ないのが普通だと思いますので、余計にわかりにくい。

RFC821(SMTP)にはenvelopeという言葉が使われていませんが、その拡張
案であるRFC1425には envelopeとcontentと言う言葉が明確に定義されて
います。前にも引用しましたが、もう一度だけRFC1425を最後に引用して
おきます。

RFC822という content ( = header + body )が、SMTP等で転送される時
に使われる情報がenvelopeで、これは実際、content中のheaderから
抽出されて作り出されるのが一般的です。RFC822には、そのような抽出
を容易にするために、contentの構文が規定されているわけです。

また、いくつかのheaderフィールドは、転送エージェント(MTA)によって
書き換えられたり追加されたりするので、その意味でSMTPのMTAは
RFC822に依存していると思います。そのため、構造を持つフィールドへの
非ASCIIの導入のためには「MTAの入れ換えが必要」というのは、嘘では
ないと思っています。

最後に、簡単な例をあげますと、
% /usr/lib/sendmail ysato
To: gama (がまがえる)
^D
この場合、envelopeのあて先にはysatoが使われ、content中のgamaは
使われませんから、ysatoにだけメイルが届きます。

　　　　　　　　　　　　　　　　 @ @

>RFC 1425                SMTP Service Extensions            February 1993
>                        SMTP Service Extensions
...
>3.  Framework for SMTP Extensions
>
>   For the purpose of service extensions to SMTP, SMTP relays a mail
>   object containing an envelope and a content.
>
>          (1)  The SMTP envelope is straightforward, and is sent as a
>               series of SMTP protocol units: it consists of an
>               originator address (to which error reports should be
>               directed); a delivery mode (e.g., deliver to recipient
>               mailboxes); and, one or more recipient addresses.
>
>          (2)  The SMTP content is sent in the SMTP DATA protocol unit
>               and has two parts: the headers and the body. The headers
>               form a collection of field/value pairs structured
>               according to RFC 822 [2], whilst the body, if structured,
>               is defined according to MIME [3]. The content is textual
>               in nature, expressed using the US ASCII repertoire (ANSI
>               X3.4-1986). Although extensions (such as MIME) may relax
>               this restriction for the content body, the content
>               headers are always encoded using the US ASCII repertoire.
>               The algorithm defined in [4] is used to represent header
>               values outside the US ASCII repertoire, whilst still
>               encoding them using the US ASCII repertoire.

---

From: [email-masked] (SASABE Tetsuro)
Date: Sun, 31 Oct 1993 10:22:55 GMT

In article <[email-masked]>
    [email-masked] (Shinji Kono) writes:

 |川上さんとか僕の意見はTo:/Subject:ではMIME/JIS漢字は使わない
 |です。EUCでやればいいじゃんというのが笹部の意見なら、それは
 |あんまりうれしくはないな。

  うーむ。私だけ呼び捨てかぁ。ま、いっか、そういう人なんだろう、きっと。

  これまで fj に私が書いていた記事は EUC か SJIS を使っちまえというも
のでした。今はちょっと違うことを考えつつあるのですが、まだうまくまとまっ
ていません。もう少しまとまってきたらポストしようと思っています。

---

From: [email-masked] (Junzou Kamahara)
Date: 30 Oct 93 14:00:50 GMT

鎌原＠阪大です。

>   ではフィールドそのものがないということでしょうか。

 すみません。化けて日本語に見えないということです。ヘッダがなくなって
いるわけではありません。

---

From: [email-masked] (Junzou Kamahara)
Date: 30 Oct 93 14:53:17 GMT

鎌原＠阪大です。

>    |8bit throughは中継サイトすべてが合意しなければならず、現状では現実的で

 Internetの話だからです。

>    |Subjectを見ていただければ分かる通り化けています。ありもしない問題で困っ

 うちの現状をお話ししただけです。

>   イトで対応することが現実に出来たのに、なぜ heder だと「対応が難しい」

 日本国内なら対応できるでしょうね。そうなれば、MIMEでも意味不明の羅列
ではなくなるでしょう。現状がそうでないから、MIMEが意味不明に見えるだけ
です。
 しかし世界的に見て、自分に利益がないことで動く人は少ないでしょう。
ここでのMIMEに関する議論を読んでいてもその感は強いですね。

 利益を得たい人が動くだけで実現できる方が、利益が得られない人を動かす
より簡単なのは明らかだと思います。