Subject: Re: $BGr;3MS(J

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Tue, 12 Oct 1993 13:51:22 GMT

On 10/12/93(21:12) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]> (fj.jokes:50250/etlss2):
 |In article <[email-masked]>
 |    [email-masked] (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) writes:
 |
 | |白山羊さんたらナマの日本語Subject、エンコードしないで出した。
 | |inewsさんたら、そのまま通した。
 | |
 | |黒山羊さんたらナマのままfollowした。
 | |inewsさんたら、ESCを食べた。
 |
 |  だから私は i-headers のころから MIME は嫌いだと、、、、、、

ありゃりゃ。fj.jokes には、「白山羊」ネタが幾つか来ていますが、
元記事<[email-masked]>は、
MIMEを*使わずに*、ナマの日本語(いわゆるJISコード、あるいはISO-2022-JP)
のSubjectで出されているようです。

Subjectが「壊れた」のは、MIMEとは関係ない、と思いますが。

＃もし何かの冗談だったのなら、すみません。
＃followup-to: fj.mailです。
　　　　　　　　　　　　　　　　 @ @
┰── ─┰─ ┰　　  ／／＼^^　( - )  {サービス、自分のために}
┠─++佐藤＠ＥＴＬ　／　876m＼ _<   >_　　　　　　　　　　　　..
┸── 　┸　 ┸────────────────────── (- @)∋ ──┘
★MIMEエンコーダ/デコーダ発売中★etlport.etl.go.jp:pub/mime/mimehead.tar.Z
                         ^^^^^^
　　　　　　　　　ちなみに、タダです(^_^)

---

From: [email-masked] (SASABE Tetsuro)
Date: Tue, 12 Oct 1993 16:23:55 GMT

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

 | |  だから私は i-headers のころから MIME は嫌いだと、、、、、、
 |
 |ありゃりゃ。fj.jokes には、「白山羊」ネタが幾つか来ていますが、
 |元記事<[email-masked]>は、
 |MIMEを*使わずに*、ナマの日本語(いわゆるJISコード、あるいはISO-2022-JP)
 |のSubjectで出されているようです。

  これは私も確認しています。

 |Subjectが「壊れた」のは、MIMEとは関係ない、と思いますが。

  ですから、無意識に日本語を投げても壊れないシステムにしようよ、と言い
たかった訳でして、、、、、。

# そこで「MIME なら…」と言われるのがイヤで書いたのですが、先を見越し
# 過ぎた発言だったようです。

  i-headers ではお話したことなので佐藤さんはご存知かと思いますが、東京
大学学内の一部のニュースグループでは、ヘッダに漢字の入った記事の投稿を
許しています。大元記事の投稿者はそのあたりと混同したのでしょう。

# 単に知らなかっただけ、という気もする。

  その気になれば、漢字の Subject: をすどうしすることが出来るのに、なん
でわざわざ MIME なんや、という主旨のグチを言ってみたかったのでした。

 |＃followup-to: fj.mailです。

  なので、強引に fj.jokes に戻って頂きましょう。joke でないフォローを
なさる方はご注意下さい。

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

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Tue, 12 Oct 1993 20:38:51 GMT

On 10/13/93(01:23) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]> (fj.jokes:50257/etlss2):
 |  ですから、無意識に日本語を投げても壊れないシステムにしようよ、と言い
 |たかった訳でして、、、、、。
 |
 |# そこで「MIME なら…」と言われるのがイヤで書いたのですが、先を見越し
 |# 過ぎた発言だったようです。
 |
 |  i-headers ではお話したことなので佐藤さんはご存知かと思いますが、東京
 |大学学内の一部のニュースグループでは、ヘッダに漢字の入った記事の投稿を
 |許しています。大元記事の投稿者はそのあたりと混同したのでしょう。
...
 |  その気になれば、漢字の Subject: をすどうしすることが出来るのに、なん
 |でわざわざ MIME なんや、という主旨のグチを言ってみたかったのでした。

わたしは、MIME-PART2(RFC1342改めRFC1522)による、ヘッダ中の非ASCIIの表現は、

　・ASCIIベースで定義されたRFC821/822に基づくインターネットnews/mailで、
　・任意のヘッダフィールドにおいて、
　・任意の（複数の）文字セットを含むテキストを、
　・任意の（複数の）文字エンコーディングシステムで表現し、
　・EBCDICなどのゲートウェイなどもかいくぐりつつ、

転送する手段を実現するための、現状においてはまともな便法だと考えています。
またこれはインターネットメイルでヘッダ中に非ASCIIを表現するための、RFC822
に対する拡張として唯一公認された規格（現在、draft standard）だと思います。
この拡張では、RFC822の構文を守りつつ、上述のような多様性を実現するために、
表現がかなり冗長になっています。でもぼくは、それを正当な代価だと感じます。
（この点の感じ方は人によるでしょうね）

ところで、
笹部さんもご存知のように、もともとMIMEは現在PART1(RFC1341改めRFC1521)と
呼ばれている、ボディ部に対する多目的拡張（マルチメディア、多言語、多機能
…）のための規格として生まれました。そこで導入された文字セット名やエンコ
ーディング方式を流用して、ヘッダを非ASCIIへ拡張したのがRFC1522なわけです。

ですから、MIME対応のツールでは、ヘッダの多国語化、あるいはSubjectの日本語
化は、全体の機能のごく一部にしか過ぎません。(mimehead.tarは、そのごく一部
の機能であるヘッダのISO-2022-JP対応だけを支援するパッケージです:-)

ボディ部における多目的化を必要だと感じている人には、ヘッダ部の多国語化は
そのおまけのような感じでついてきます。一方、そうでない人には、重苦しい
だけかもしれません。でも、将来に渡って、news/mailではプレーンテキストだけ
を交換するだけで良いと思っている人は、あまりいないと思います。

また、現状のｆｊでも、ボディ部のMIME規格は従来の懸案の多くを解決できると
思います。例えば、

　・音声や画像の標準転送フォーマット (image/gif, audio/basic型など)
　・分割記事の自動結合 (message/partial)
　・ftp-mailなどとの連係 (message/external)
　・読み手の画面サイズに応じた行の折り返し (text/enriched)
　・その他いろいろ(^_^)

すでに、MIMEは紙の上だけの規格ではなく、多くのフリーソフト、商用ソフトに
おいてサポートされています。MIMEの概要と普及の現状を知るには、
comp.mail.mimeに投稿されているFAQを読むのがてっとり早いと思います。

From: [email-masked] (Tim Goodwin)
Newsgroups: comp.mail.mime,comp.answers,news.answers
Subject: comp.mail.mime frequently asked questions list (FAQ)
Supersedes: <[email-masked]>
Date: 22 Sep 1993 19:16:17 +0100
Organization: Pipex Ltd., 216 Science Park, Cambridge CB4 4WA, England
Lines: 1778
Approved: [email-masked]
Expires: 15 Nov 1993 18:16:10 GMT
Message-ID: <[email-masked]>
NNTP-Posting-Host: tank.pipex.net
Summary: This posting contains answers to some of the Frequently Asked
    Questions about MIME (Multipurpose Internet Mail Extensions).
    Please read it before posting a question to comp.mail.mime.

Archive-Name: mail/mime-faq
Last-modified: 1993/09/22
Version: 2.9

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Naoki HAMADA)
Date: 13 Oct 1993 02:32:56 GMT

わたしは MIME が嫌いなので、ちょっとだけ。

>わたしは、MIME-PART2(RFC1342改めRFC1522)による、ヘッダ中の非ASCIIの表現は、
（中略）
>転送する手段を実現するための、現状においてはまともな便法だと考えています。

  日本語も素通りするように agent を改良する、規格を変えてゆく、という
ののほうがよりまともだとわたしは思います。

>でもぼくは、それを正当な代価だと感じます。

  わたしには、正当な代価だとは感じられません。解決として単純化と複雑化
とがある場合、迷わず単純化をとるべきだと考えるからです。無闇にものごと
を複雑にするのは、見通しを悪くするばかりでかえって不便を招くというのが
わたしの経験です。

  また、ヘッダ部の他国語化とボディ部の多目的化とは本来目的が違うので、 
MIME を使えば実現できるからというだけの理由で安易にいっしょくたにする
べきではないと考えます。わたしは前者を切望しますが、後者の必要性を感じ
たことはありません。

浜田 直樹

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Wed, 13 Oct 1993 09:15:22 GMT

On 10/13/93(11:32) [email-masked] (Naoki HAMADA) wrote
in <[email-masked]> (fj.mail:2128/etlss2):
 |>わたしは、MIME-PART2(RFC1342改めRFC1522)による、ヘッダ中の非ASCIIの表現は、
 |（中略）
 |>転送する手段を実現するための、現状においてはまともな便法だと考えています。
 |
 |  日本語も素通りするように agent を改良する、規格を変えてゆく、という
 |ののほうがよりまともだとわたしは思います。

それは、あるべき姿かもしれません。けれどおそらくそのように、従来のイ
ンターネットメイル規格(RFC821,822)と互換性を保って拡張するのは、困難
ではないでしょうか？もし、前にあげたような条件を満たせる簡単な方法を
お考えなら、それをインターネットで提案するのは、大きな貢献になると思
います。

また、自分の使っている文字コードやエンコーディングを、インターネット
に素通ししたいという野望(^_^)は、誰もが持っていると思います。
JIS(iso-2022-jp), SJIS, UJIS, 各国のEUC, iso-8859-X, 複雑なiso-2022,
unicode, iso-10646, ... それらを同時に満たすことができるでしょうか？
僕は政治的にも技術的にも、困難だと思います。

ぼくの感覚では、ユーザインターフェイスの部分(MUA)からMIMEエンコーディ
ングを意識しないで済むなら、それが僕の知らない転送経路(MTA)でどのよう
な形で表現され、転送されていても、気になりません。

 |>でもぼくは、それを正当な代価だと感じます。
 |>（この点の感じ方は人によるでしょうね）
 |
 |  わたしには、正当な代価だとは感じられません。解決として単純化と複雑化
 |とがある場合、迷わず単純化をとるべきだと考えるからです。無闇にものごと
 |を複雑にするのは、見通しを悪くするばかりでかえって不便を招くというのが
 |わたしの経験です。

技術的に単純で見通しが良いのは、RFC821,822との互換性を捨てて、新たな
標準を作り、転送経路(MTA)もリーダ(MUA)も作り直すことでしょう。しかし
それはOSIの例に見るように、大変なコストを要します。それを避けるには、
従来の規格となんとか折り合うような便法を考えるしかないでしょう。

僕は RFC1522はまともな便法だと考えますし、それほど無闇な複雑化はして
いないと思います。また、無闇だと思った部分には、規格編集者やIETF-WGに
文句を言うように心がけたいと思います。それが、インターネットに間借り
してtakeばかりしてきた自分のせめてもの貢献だと思うからです。

さらにメタで恐縮ですが、
規格ができつつある段階で知らんぷりしておいて、出来上がってから文句を
言ったり、ただ乗りしたりするのは良くないと思います。（その意味では、
WGを作ってunicodeに徹底交戦しているmohta氏はエライと思う）

 |  また、ヘッダ部の他国語化とボディ部の多目的化とは本来目的が違うので、 
 |MIME を使えば実現できるからというだけの理由で安易にいっしょくたにする
 |べきではないと考えます。わたしは前者を切望しますが、後者の必要性を感じ
 |たことはありません。

やはり、だき合わせ商法は嫌われますね(^_^;)
しかし、数年後には浜田さんもマルチメディアしてると思うんだけど…

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Thu, 14 Oct 1993 01:22:16 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Naoki HAMADA) 氏曰く、

nao>   また、ヘッダ部の他国語化とボディ部の多目的化とは本来目的が違うので、 
nao> MIME を使えば実現できるからというだけの理由で安易にいっしょくたにする
nao> べきではないと考えます。わたしは前者を切望しますが、後者の必要性を感じ
nao> たことはありません。

  ボディー部の内容の記述ということに関しては、多国語化ということに関し
ても、大いに意味のあることだと思います。

  Unicode のようなもので『多国語化』を実現するというなら、システムを全
面的に入れ替えることによって、ある意味でシンプルな解決が計れるでしょう
が、そうしたやり方は Internet にはそぐわないでしょう。

  どんなものが入っているかを宣言する MIME のやり方は、たとえ、プレイン・
テキストしか使わないとしても、Internet における mail/news message の多
言語化を考えれば、重要だと思います。

  このことは、ヘッダーに関しても、言えると思います。

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

---

From: [email-masked] (Wataru KAWAKAMI)
Date: 13 Oct 93 01:36:47 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 漢字の Subject ( Re: 白山羊 )

  NTTの川上です。

 "fj.mail,fj.jokes"の"Re: $BGr;3MS(J"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> でわざわざ MIME なんや、という主旨のグチを言ってみたかったのでした。
是非、X-Nsubjectをお試しあれ。:-)
# Upper compatibility, headerの可読性を考えると`Subject:'は。。

  mnewsあたりだと、日本語で題目を書くと、勝手にX-Nsubjectと
Subjectに入ったような記憶があります。

  そこで、ばっさり、Subject行を消して、inewsに直接食わせる
かわりにConvInews.sh [1] に前もって食わせると、ここから呼ば
れるkakasiがローマ字にしてくれて、めでたくローマ字になった
Subjectが`Subject:'に埋まります。:-)

 >>   なので、強引に fj.jokes に戻って頂きましょう。joke でないフォローを
ということで、強引にfj.mailに持ってきました。
						wataru
# vn, mnews, gnus, ... elm, ... mime2xn.
# MIMEはbodyに使ってこそ、その真価を発揮すると思う。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

=== 参考文献 ===
[1] 
  From: [email-masked] (Wataru KAWAKAMI)
  Newsgroups: fj.sources
  Subject: Sample impl. of vn with Nihongo subject(II)
  Message-ID: <[email-masked]>
  Date: 28 Oct 92 09:01:00 GMT
  X-Nsubject: 日本語サブジェクト版 vn (II)

---

From: [email-masked] (TAKADA Toshihiro / 高田敏弘 )
Date: 13 Oct 93 02:45:14 GMT

こんにちは、高田です。ひとつ質問があります。

>でわざわざ MIME なんや、という主旨のグチを言ってみたかったのでした。

Subject: だけなら話は単純ですが、例えばアドレス・フィールドにも漢字を書
けるようにするには、漢字(JIS X 0208)のコード中に含まれる specials ("(",
"<" 等)もちゃんと処理しないと駄目だと思うのですが、

>許しています。大元記事の投稿者はそのあたりと混同したのでしょう。

そちらでは、それもやられているのでしょうか？

========================================================================
ＮＴＴ基礎研究所 情報科学研究部                                 高田敏弘
分散コンピューティング原理研究グループ              [email-masked]
========================================================================

---

From: [email-masked] (Wataru KawaKami)
Date: Wed, 13 Oct 1993 12:23:52 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: headerにMIMEを、の雑感 (Re: Why MIME ?)

  NTTの川上です。
  現行のニュースのheaderにMIMEをいれていくことについての
雑感です。

"fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、[email-masked]、
  >> な形で表現され、転送されていても、気になりません。
そういうことであれば、現行のニュースのheaderにではなく、現行の
ニュースのbodyの部分にMIME化されたヘッダーをいれて、対応する
ニュースリーダーで読めるようにしても、同じことだと思います。
NeXTのNewsgrazerって確か、そういうimplementationだったように
記憶しています。

# 実は、今のX-Nsubject:の考え(ESC救済,jisの生送り)でいこうと
# 決める途中で、代替案として考えたことがあります。

  今のように、Subject:行にMIMEしたものを入れる方法だと、それに
対応していないnews/mailreaderでは全く何のことかわからなくなって
しまい、Subject:/From:行の可読性が失われるように思います。今の
newsって、Subject:/From:行が可読であるのも特徴だと聞いています。

  また、fjが海外にでていっていることを考えた時、Subject:行やFrom:
行が英語もしくはローマ字であれば、日本語があまり得意でない人々も
読んで、意味を判読しやすいのではないかと思います。

  皆様の参考になれば幸いです。
					wataru

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

---

From: [email-masked] (Naoki HAMADA)
Date: 14 Oct 1993 05:12:27 GMT

>ではないでしょうか？

  「互換性」「拡張」の意味によるでしょう。

>従来の規格となんとか折り合うような便法を考えるしかないでしょう。

  OSI を持ち出してくるのはいくらなんでも話が極端すぎやしませんか？

  まあ、それはともかく、RFC821,822 をできるだけ活かした規格にすること
は別に異義ありません。かといって、ごちゃごちゃエンコーディングして複雑
化するのは嫌いです。

>言ったり、ただ乗りしたりするのは良くないと思います。

  これはわたしに言ってるんですか？「意見を言うな」とか「MIME を使うな」
とおっしゃってるんですか？だとすれば、わたしゃ単に「嫌いだ」と表明した
だけなので、全然筋違いですし。わけわかりません。

>しかし、数年後には浜田さんもマルチメディアしてると思うんだけど…

  そんな先のことはわかりません。憶測はよしましょう。

浜田 直樹

---

From: [email-masked] (Naoki HAMADA)
Date: 14 Oct 1993 05:15:30 GMT

>  このことは、ヘッダーに関しても、言えると思います。

  この部分が良くわからないのですが。

浜田 直樹

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Thu, 14 Oct 1993 10:31:51 GMT

On 10/13/93(21:23) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]> (fj.mail:2134/etlss2):
 |  >> ぼくの感覚では、ユーザインターフェイスの部分(MUA)からMIMEエンコーディ
 |  >> ングを意識しないで済むなら、それが僕の知らない転送経路(MTA)でどのよう
 |  >> な形で表現され、転送されていても、気になりません。
 |そういうことであれば、現行のニュースのheaderにではなく、現行の
 |ニュースのbodyの部分にMIME化されたヘッダーをいれて、対応する
 |ニュースリーダーで読めるようにしても、同じことだと思います。

そのためにはまず、NNTPのHEADコマンドを作り変えるなどの必要があるで
しょうね。また、ニュースリーダでフォローやリプライをする時に、元記事
から継承すべきフィールドも増えます。それを、色んな国の文字に対して
やるのは、簡単ではないでしょうね。

MIMEでは、そのようなことをせずに済むわけです。

 |  今のように、Subject:行にMIMEしたものを入れる方法だと、それに
 |対応していないnews/mailreaderでは全く何のことかわからなくなって
 |しまい、Subject:/From:行の可読性が失われるように思います。今の
 |newsって、Subject:/From:行が可読であるのも特徴だと聞いています。
 |
 |  また、fjが海外にでていっていることを考えた時、Subject:行やFrom:
 |行が英語もしくはローマ字であれば、日本語があまり得意でない人々も
 |読んで、意味を判読しやすいのではないかと思います。

英語(ローマ字)と、かな漢字文を併記することは、どのようなエンコーディ
ング方式をとるにしても、望ましいしいことだと思います。実際ぼくも、
併記するようにしています。

MIMEでは Subject(に限りませんが)に英語でも日本語でもロシア語でも、一
緒に併記することができます。例えば Cc などに、いろんな国の人の名前が
いろんな文字セットで入っていて構いません。また、自分の読めない文字や、
端末に表示できない文字セット／エンコーディング（特に、端末に害がある
かも知れないもの）は、デコードしないという選択もできるわけです。

一つの規格で、任意の文字セットに対して、インターネットの世界中に通用
するものであれば、多少コストがかかっても、ぼくはそれを採用したいと思
います。その昔、i-headers ＭＬでは、川上さんのおっしゃるような案を含
め幾つかの案がでましたが、ぼくは結局MIMEを選択しました。二度手間を避
けたかったからです。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Thu, 14 Oct 1993 10:36:59 GMT

On 10/14/93(14:12) [email-masked] (Naoki HAMADA) wrote
in <[email-masked]> (fj.mail:2135/etlss2):
 |  まあ、それはともかく、RFC821,822 をできるだけ活かした規格にすること
 |は別に異義ありません。かといって、ごちゃごちゃエンコーディングして複雑
 |化するのは嫌いです。

具体的な対案を示していただかないことには…

 |>しかし、数年後には浜田さんもマルチメディアしてると思うんだけど…
 |
 |  そんな先のことはわかりません。憶測はよしましょう。

確かにそうですね。ごめんなさい。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (SASABE Tetsuro)
Date: Thu, 14 Oct 1993 11:53:18 GMT

とうだいの笹部です。

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

 |On 10/13/93(11:32) [email-masked] (Naoki HAMADA) wrote
 |in <[email-masked]> (fj.mail:2128/etlss2):
 |
 | |  日本語も素通りするように agent を改良する、規格を変えてゆく、という
 | |ののほうがよりまともだとわたしは思います。
 |
 |それは、あるべき姿かもしれません。けれどおそらくそのように、従来のイ
 |ンターネットメイル規格(RFC821,822)と互換性を保って拡張するのは、困難
 |ではないでしょうか？

  私も浜田さんと同じ考え方をしています。

  確かに 822 を維持したままの拡張は私には思い付きません。が、どうせな
らば 821/822 の方を放棄するという選択肢だってあったはずです。MIME にし
ても対応していないサイトでは読め無いという点で大きな違いは無いと思うの
ですが。

 |また、自分の使っている文字コードやエンコーディングを、インターネット
 |に素通ししたいという野望(^_^)は、誰もが持っていると思います。
 |JIS(iso-2022-jp), SJIS, UJIS, 各国のEUC, iso-8859-X, 複雑なiso-2022,
 |unicode, iso-10646, ... それらを同時に満たすことができるでしょうか？
 |僕は政治的にも技術的にも、困難だと思います。

  8bit through にしてしまえば(相手がどのコード系だと思うかは別として)
通るとは思います。

 |ぼくの感覚では、ユーザインターフェイスの部分(MUA)からMIMEエンコーディ
 |ングを意識しないで済むなら、それが僕の知らない転送経路(MTA)でどのよう
 |な形で表現され、転送されていても、気になりません。

  私は、手間も問題だと思っています。
  私のように、NNTP でつないで読んでいる人間には、(現在のところ)読む側
で対応するしかない MIME は面倒。もしニュースシステムが 8bit を通すよう
になってくれれば、ユーザーサイドは何もする必要が無い。

 |技術的に単純で見通しが良いのは、RFC821,822との互換性を捨てて、新たな
 |標準を作り、転送経路(MTA)もリーダ(MUA)も作り直すことでしょう。

  上にも申しましたように、1から作り直さなくても 8bit 透過だけでかなり
のことが出来ると考えています。

 |さらにメタで恐縮ですが、
 |規格ができつつある段階で知らんぷりしておいて、出来上がってから文句を
 |言ったり、ただ乗りしたりするのは良くないと思います。（その意味では、
 |WGを作ってunicodeに徹底交戦しているmohta氏はエライと思う）

  あの時点で言える文句は言っていたつもりなんですが、、、、当時の私(い
まだってそうだけど)に何が出来たかなぁ。

 |やはり、だき合わせ商法は嫌われますね(^_^;)
 |しかし、数年後には浜田さんもマルチメディアしてると思うんだけど…

  これは技術の問題とは切り放しての、感情論ですが、このマルチメディアと
一緒になっているがための反発もあると思います。なんで日本語が画像ファイ
ルと同じに扱われにゃならんねん、という気分は私にもあるし。

---

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

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

>  このことは、ヘッダーに関しても、言えると思います。

nao>   この部分が良くわからないのですが。

  全世界で単一の文字コードを使うのでなければ、どんな文字コードを使って
いるかを宣言する方が安全だし、合理的だと思うからです。

---

From: [email-masked] (Issei Numata)
Date: 14 Oct 1993 13:14:31 GMT

沼田です．

>> newsって、Subject:/From:行が可読であるのも特徴だと聞いています。

同感です．以前やっとMIMEなるものがインストールされはじめたころ，面倒だ
から設定をしてなかったのですが，ある日それらしきエンコードされたデータ
がやってきました．

しょうがないなぁ，とおもってなんとかデコードしたところ，，，

Subject: はじめまして

とだけ書いてあり，脱力感を覚えたことがあります．Subject:なんぞ，たかが
1行(まぁ，長いのも書けるようですが)で，書ける情報など，たかが知れとり
ます．その1行が，ローマ字だろうが，英語だろうが，日本語だろうが情報に
あまり違いはないわけで，

>> 読んで、意味を判読しやすいのではないかと思います。

とのトレードオフを考えると，うーんちょっとねぇ．と思ってしまいます．
MIMEを完全には否定しませんが，道具は有効につかってこそ発揮されるので
はないでしょうか？

私が，よく言語をしらない国(たとえば韓国とか)のニュースが読めるように
なったときサブジェクトがハングルだとやっぱりちょっと悲しいな．

>> # MIMEは、bodyに使ってこそ、その真価を発揮すると思います。

おなぢく，そう思います．

--
沼田いっせい＠ＪＡＩＳＴ長期出張中 

☆スポンジみたいに、たっぷり夏を吸いこんだ。

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Thu, 14 Oct 1993 14:01:51 GMT

On 10/14/93(20:53) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]>
 | | |  日本語も素通りするように agent を改良する、規格を変えてゆく、という
 | | |ののほうがよりまともだとわたしは思います。
 | |
 | |それは、あるべき姿かもしれません。けれどおそらくそのように、従来のイ
 | |ンターネットメイル規格(RFC821,822)と互換性を保って拡張するのは、困難
 | |ではないでしょうか？
 |
 |  私も浜田さんと同じ考え方をしています。
 |
 |  確かに 822 を維持したままの拡張は私には思い付きません。が、どうせな
 |らば 821/822 の方を放棄するという選択肢だってあったはずです。MIME にし

sendmailやら何やらも捨てる／作り直すということでしょうか？
その選択肢は（気持ちは良いですが）現実的には困難だと私は思います。
それが現実的なら、例えばなぜOSIの普及に時間がかかるのでしょう？

 |ても対応していないサイトでは読め無いという点で大きな違いは無いと思うの
 |ですが。

送信者と受信者のMUAでMIMEに対応するのと、中継サイトのMTAを全て新
たな規格のもので入れ換えるのとの、コストの比較になりますね。
ぼくは大きな違いがあると思います。前者はすでに規格も存在し、多く
のツールが対応済みです。後者の実現は、大変だと思います。

 | |また、自分の使っている文字コードやエンコーディングを、インターネット
 | |に素通ししたいという野望(^_^)は、誰もが持っていると思います。
 | |JIS(iso-2022-jp), SJIS, UJIS, 各国のEUC, iso-8859-X, 複雑なiso-2022,
 | |unicode, iso-10646, ... それらを同時に満たすことができるでしょうか？
 | |僕は政治的にも技術的にも、困難だと思います。
 |
 |  8bit through にしてしまえば(相手がどのコード系だと思うかは別として)
 |通るとは思います。

どのコード系かわからなくて構わないということでしょうか？
複数のコード系が混在した場合には、どうやって解釈するのでしょう？
8bit というのは、日本では例えば EUC とか SJIS を流すということで
しょうか？ 

もし、7bits + ESC の透過ということでしたら、それはアドレス関係の
フィールドにおいては、RFC821/822を使う限り無理です。

 | |ぼくの感覚では、ユーザインターフェイスの部分(MUA)からMIMEエンコーディ
 | |ングを意識しないで済むなら、それが僕の知らない転送経路(MTA)でどのよう
 | |な形で表現され、転送されていても、気になりません。
 |
 |  私は、手間も問題だと思っています。
 |  私のように、NNTP でつないで読んでいる人間には、(現在のところ)読む側
 |で対応するしかない MIME は面倒。もしニュースシステムが 8bit を通すよう
 |になってくれれば、ユーザーサイドは何もする必要が無い。

ぼくは、nntpdにパッチをあてて、MIMEのエンコードやデコードを自動的
にするようにしています。ユーザサイドは、nntpdと生の JISコード
（ISO-2022-JP、またの名をJUNETコード）を交換するだけで、 MIMEのこ
とを意識する必要はありません。

 | |技術的に単純で見通しが良いのは、RFC821,822との互換性を捨てて、新たな
 | |標準を作り、転送経路(MTA)もリーダ(MUA)も作り直すことでしょう。
 |
 |  上にも申しましたように、1から作り直さなくても 8bit 透過だけでかなり
 |のことが出来ると考えています。

ぼくは、MIME対応にするだけで、ほとんどの要求は満たされると考えてい
ます。 8bit 透過にすることで、何ができるのかは良くわかりません。

 | |さらにメタで恐縮ですが、
 | |規格ができつつある段階で知らんぷりしておいて、出来上がってから文句を
 | |言ったり、ただ乗りしたりするのは良くないと思います。（その意味では、
 | |WGを作ってunicodeに徹底交戦しているmohta氏はエライと思う）
 |
 |  あの時点で言える文句は言っていたつもりなんですが、、、、当時の私(い
 |まだってそうだけど)に何が出来たかなぁ。

上のを浜田さんへのフォローに書いてしまったのは失敗でした。これは
誰に対してというものでもなく、また特にMIMEの件に限っての話しでも
なく、日頃の不満を書いてしまったのでした。恐縮です。

 | |やはり、だき合わせ商法は嫌われますね(^_^;)
 | |しかし、数年後には浜田さんもマルチメディアしてると思うんだけど…
 |
 |  これは技術の問題とは切り放しての、感情論ですが、このマルチメディアと
 |一緒になっているがための反発もあると思います。なんで日本語が画像ファイ
 |ルと同じに扱われにゃならんねん、という気分は私にもあるし。

日本だけが苛められていると思うのは、違うと思います。ASCII だけで
足りる国を除けば(^_^)、みんな平等ですよね。

インターネットメイルは、RFC822という、ASCIIを使って定義された構文
を持つ言語の文ですから、そのヘッダの処理系が ASCII を特別扱いに
するのは当然だと思います。

ツールを一旦MIME対応にすれば、エンドユーザはMIMEのことなど意識しな
くて良いし、実は転送時には日本語が自分の知っているコードと異なる形
にエンコードされて送られていることまで、気にする人はいないでしょう。
転送時に圧縮されたりしても気にならないのと同様に。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (SASABE Tetsuro)
Date: Thu, 14 Oct 1993 19:19:07 GMT

とうだいの笹部です。

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

 | |  確かに 822 を維持したままの拡張は私には思い付きません。が、どうせな
 | |らば 821/822 の方を放棄するという選択肢だってあったはずです。MIME にし
 |
 |sendmailやら何やらも捨てる／作り直すということでしょうか？
 |その選択肢は（気持ちは良いですが）現実的には困難だと私は思います。
 |それが現実的なら、例えばなぜOSIの普及に時間がかかるのでしょう？

  佐藤さん、浜田さんも言っているけど、ＯＳＩっていうのは行きすぎですよ。
確かにここには放棄とは書きましたが、私が意図しているのは 821/822 に対
して 8bit 透過を保証するという一点だけの拡張です。8bit 透過は 821/822
に適合しないのは知っているので「放棄」と書いたのであって、一からやり直
すわけではないことはその後にも書いたんですけれど…。

 |送信者と受信者のMUAでMIMEに対応するのと、中継サイトのMTAを全て新
 |たな規格のもので入れ換えるのとの、コストの比較になりますね。

  佐藤さんが sendmail の例を出されたのでメールについて言えば、IP 世界
では端点と点だけが対応すれば中継と言う問題はありませんよね。ニュースに
ついては、元々 fj で日本語文字を通すためには B News の改造が必要でした。
この改造が本文にとどまっていたのをヘッダにまで拡張することってそんなに
難しいですか？

# この「難しい」は、コーディングがという意味ではなく、8bit 透過のシス
# テムに各サイトが対応してくれるのを期待するのが「難しい」か、という意
# 味です。

 |ぼくは大きな違いがあると思います。前者はすでに規格も存在し、多く
 |のツールが対応済みです。後者の実現は、大変だと思います。

  一見対応済みのようですが…。実際にはヘッダが長くなったことによる障害
が多数報告されましたよね。NIFTY との接続では、当初 NIFTY 側からはヘッ
ダに 2byte 文字が入ったメールが届いていました。その頃には問題の発生を
まったく聞かなかった(mohta さんが文句を言ってはいましたが ;-))のに、
MIME 対応の長いヘッダが届くようになってから問題が噴出したのは単なる
「皮肉な現象」でしょうか？

 | |  8bit through にしてしまえば(相手がどのコード系だと思うかは別として)
 | |通るとは思います。
 |
 |どのコード系かわからなくて構わないということでしょうか？

  構わないと思います。

 |複数のコード系が混在した場合には、どうやって解釈するのでしょう？

  複数のコードという場合、注意しないと混同する2つの意味がありますよね。
言語ごと違う場合と、同じ言語でコードのみが異なる場合と。

 |8bit というのは、日本では例えば EUC とか SJIS を流すということで
 |しょうか？ 

  おっしゃる通りです。現在でも色々な方法で EUC や SJIS は自動判別され
ていますが、それで大きな問題が起きていますか？ 起きていなければ、私の
言っていることにそんなに無理はないと思います。私は、言語を判別する必要
はほとんど無いと思っています。

  現に私に日本語と ASCII 文字以外で書かれたメッセージが送られてきても
私は読むことが出来ません。複数の言語を読み書きできる人が居ないとは言い
ません。しかしその人が一つのメッセージの中で複数の言語を使う必要はある
でしょうか？ 私はそのような必要はほとんど無いと思っています。そうであ
るなら、複数の言語(コードではない)を使う人に限って本文やそれこそヘッダ
中で使用する言語を明示すれば良いだけです。

 |もし、7bits + ESC の透過ということでしたら、それはアドレス関係の
 |フィールドにおいては、RFC821/822を使う限り無理です。

  もちろんそれはよく理解していますよ。だから 8bit 透過にして EUC か
Shift JIS 使えば良いと思っています。JIS を使うとアドレス表記が混乱する
のは承知の上です。

 | |  これは技術の問題とは切り放しての、感情論ですが、このマルチメディアと
 | |一緒になっているがための反発もあると思います。なんで日本語が画像ファイ
 | |ルと同じに扱われにゃならんねん、という気分は私にもあるし。
 |
 |日本だけが苛められていると思うのは、違うと思います。ASCII だけで
 |足りる国を除けば(^_^)、みんな平等ですよね。

  ええっと、話が通じていないようです。感情論と断っているぐらいですから
通じなくても困らないのですが ^_^;、一応繰り返します。

  私は日本語がいぢめられていると言っているつもりではありません。非
ASCII 文字がなぜ画像データや音声データと同じに扱われてしまうのか、とい
う疑問です。ASCII 文字圏に住んでいる人々には漢字やタイ文字なんてただの
理解不能な記号にしか過ぎないんでしょうけれど。

 |インターネットメイルは、RFC822という、ASCIIを使って定義された構文
 |を持つ言語の文ですから、そのヘッダの処理系が ASCII を特別扱いに
 |するのは当然だと思います。

  ASCII 文字文化だけを対象に考えられていた体系は、それ以外の文化へ対応
しようとするならば修正を迫られるのが当然と考えます。

  MIME も修正だとおっしゃるかもしれません。しかし、実際には ASCII 文字
以外への対応をしたと言うよりも無理やり ASCII 文字で表記するようにして
しまったという方が近いのではないでしょうか。もっともこれも感情論の部類
ではあります。

 |ツールを一旦MIME対応にすれば、エンドユーザはMIMEのことなど意識しな
 |くて良いし、実は転送時には日本語が自分の知っているコードと異なる形
 |にエンコードされて送られていることまで、気にする人はいないでしょう。
 |転送時に圧縮されたりしても気にならないのと同様に。

  ツールをいったん 8bit 透過にし、EUC あるいは Shift JIS で表記するよ
うになれば(以下同文のため省略)。

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Fri, 15 Oct 1993 18:24:28 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (SASABE Tetsuro) 氏曰く、

笹部> In article <[email-masked]>
笹部>     [email-masked] (Yutaka Sato 佐藤豊) writes:

笹部>  | |  確かに 822 を維持したままの拡張は私には思い付きません。が、どうせな
笹部>  | |らば 821/822 の方を放棄するという選択肢だってあったはずです。MIME にし
笹部>  |
笹部>  |sendmailやら何やらも捨てる／作り直すということでしょうか？
笹部>  |その選択肢は（気持ちは良いですが）現実的には困難だと私は思います。
笹部>  |それが現実的なら、例えばなぜOSIの普及に時間がかかるのでしょう？

笹部>   佐藤さん、浜田さんも言っているけど、ＯＳＩっていうのは行きすぎですよ。
笹部> 確かにここには放棄とは書きましたが、私が意図しているのは 821/822 に対
笹部> して 8bit 透過を保証するという一点だけの拡張です。8bit 透過は 821/822
笹部> に適合しないのは知っているので「放棄」と書いたのであって、一からやり直
笹部> すわけではないことはその後にも書いたんですけれど…。

  8 bit 透過にして、日本ローカルに閉じることにすれば、その鎖国体制にお
いて、問題は起きないでしょう。

  8 bit 透過の上で、ISO-8859-* やら Shift-JIS やら、各国の EUC やら 
Unicode やらが飛び交う訳ですか？

  あるいは、どれか一つの文字エンコードを世界中で採用できればそれが良い
のでしょうが。日本としての理想は、Mule の *junet* code のような方式の
世界コード系を使うことでしょうね。

笹部>  |送信者と受信者のMUAでMIMEに対応するのと、中継サイトのMTAを全て新
笹部>  |たな規格のもので入れ換えるのとの、コストの比較になりますね。

笹部>   佐藤さんが sendmail の例を出されたのでメールについて言えば、IP 世界
笹部> では端点と点だけが対応すれば中継と言う問題はありませんよね。ニュースに
笹部> ついては、元々 fj で日本語文字を通すためには B News の改造が必要でした。
笹部> この改造が本文にとどまっていたのをヘッダにまで拡張することってそんなに
笹部> 難しいですか？

  だから、MIME の立場としては、本文にどんなものが書いてあるかも書いて
欲しい訳です。「ISO-2022-JP が書いてありますよ」とか「ISO-8859-1 が書
いてありますよ」とか。8 bit 透過にすること自体は、それはそれで結構なこ
とですが、問題の解決にはなっていません。MIME によって、何が書いてある
かを宣言することと、その中身をどんな形で流すかということは別次元の問題
です。

笹部>   一見対応済みのようですが…。実際にはヘッダが長くなったことによる障害
笹部> が多数報告されましたよね。NIFTY との接続では、当初 NIFTY 側からはヘッ
笹部> ダに 2byte 文字が入ったメールが届いていました。その頃には問題の発生を
笹部> まったく聞かなかった(mohta さんが文句を言ってはいましたが ;-))のに、
笹部> MIME 対応の長いヘッダが届くようになってから問題が噴出したのは単なる
笹部> 「皮肉な現象」でしょうか？

  これは、RFC-822 に対応してなかっただけの話で、MIME の責任ではないと
思います。MIME header を使うようになって表面化しただけの話で、前から、
複数行の From: は認められていたのですから。

笹部>  | |  8bit through にしてしまえば(相手がどのコード系だと思うかは別として)
笹部>  | |通るとは思います。
笹部>  |
笹部>  |どのコード系かわからなくて構わないということでしょうか？

笹部>   構わないと思います。

笹部>  |複数のコード系が混在した場合には、どうやって解釈するのでしょう？

笹部>   複数のコードという場合、注意しないと混同する2つの意味がありますよね。
笹部> 言語ごと違う場合と、同じ言語でコードのみが異なる場合と。

笹部>  |8bit というのは、日本では例えば EUC とか SJIS を流すということで
笹部>  |しょうか？ 

笹部>   おっしゃる通りです。現在でも色々な方法で EUC や SJIS は自動判別され
笹部> ていますが、それで大きな問題が起きていますか？ 起きていなければ、私の
笹部> 言っていることにそんなに無理はないと思います。私は、言語を判別する必要
笹部> はほとんど無いと思っています。

  鎖国するならそれで良いのでしょうね。そして、日本語以外は本当に文字化
けする訳です。

笹部>   現に私に日本語と ASCII 文字以外で書かれたメッセージが送られてきても
笹部> 私は読むことが出来ません。複数の言語を読み書きできる人が居ないとは言い
笹部> ません。しかしその人が一つのメッセージの中で複数の言語を使う必要はある
笹部> でしょうか？ 私はそのような必要はほとんど無いと思っています。そうであ
笹部> るなら、複数の言語(コードではない)を使う人に限って本文やそれこそヘッダ
笹部> 中で使用する言語を明示すれば良いだけです。

  けれど、この論では、日本語と英語だけを特別扱いする訳ですね。自分の判
る言語だけを、自分の使う言語だけを特別扱いする訳ですね。そのために、新
たなシステムの構築を迫る訳ですね。

  それぐらいなら、常に、どんな言語・文字集合・エンコーディングを使うか
を明示した方が良くはないですか？

笹部>  |もし、7bits + ESC の透過ということでしたら、それはアドレス関係の
笹部>  |フィールドにおいては、RFC821/822を使う限り無理です。

笹部>   もちろんそれはよく理解していますよ。だから 8bit 透過にして EUC か
笹部> Shift JIS 使えば良いと思っています。JIS を使うとアドレス表記が混乱する
笹部> のは承知の上です。

  日本は、EUC か Shift-JIS を使って、欧米諸国では、ISO-8859-1 を使って、
ブロック化を計ろうというのですか？

笹部>  | |  これは技術の問題とは切り放しての、感情論ですが、このマルチメディアと
笹部>  | |一緒になっているがための反発もあると思います。なんで日本語が画像ファイ
笹部>  | |ルと同じに扱われにゃならんねん、という気分は私にもあるし。
笹部>  |
笹部>  |日本だけが苛められていると思うのは、違うと思います。ASCII だけで
笹部>  |足りる国を除けば(^_^)、みんな平等ですよね。

笹部>   ええっと、話が通じていないようです。感情論と断っているぐらいですから
笹部> 通じなくても困らないのですが ^_^;、一応繰り返します。

笹部>   私は日本語がいぢめられていると言っているつもりではありません。非
笹部> ASCII 文字がなぜ画像データや音声データと同じに扱われてしまうのか、とい
笹部> う疑問です。ASCII 文字圏に住んでいる人々には漢字やタイ文字なんてただの
笹部> 理解不能な記号にしか過ぎないんでしょうけれど。

  まあ、ASCII 帝国主義には苛つきますが、国際化と称して、ISO-8859-1 帝
国主義や Unicode 帝国主義に流れるよりはましでしょう。MIME なら、お望み
なら、Shift-JIS や EUC を流すこともできますし、それこそ 8 bit 透過になっ
た暁には、本文に何もエンコードせずに堂々と流せるでしょう。

  そして、そのことが、国際化と矛盾しない訳です。

  Shift-JIS や EUC を入れようとすると、画像や音声と同じようにエンコー
ドしなければならないのは、それこそ、8 bit 透過ではないせいで、MIME の
責任ではありません。

  ASCII だって、

Content-Type: text/plain; charset=US-ASCII

と書くべきなのであって、その意味で平等です。（もちろん、ASCII 帝国主義
に負けそうになることもある訳ですが、そういう時こそ戦えば良い訳です）

  くどくくどく書きましたが、ASCII 帝国主義や ISO-8859-1 帝国主義や 
Unicode 帝国主義に反対するのと同じように、EUC や Shift-JIS を流せば良
いやんというような論には反対します。

---

From: [email-masked] (Naoki HAMADA)
Date: 15 Oct 1993 05:42:34 GMT

>具体的な対案を示していただかないことには…

  ですから、「嫌いだ」って言ってるだけなんですってば。ただ単に「嫌いだ」っ
て言うのもなんですから、「こういう理由で嫌いだ」と解説つきにしてるだけ
で。それとも何ですか、「対案抜きで嫌いだと言ってはならない」とでも？

  それはともかく、わたしの考えたかぎりでの具体案は、笹部さんがおっしゃっ
ていることとほぼ完全に一致します。

浜田 直樹

---

From: [email-masked] (Naoki HAMADA)
Date: 15 Oct 1993 05:56:48 GMT

>いるかを宣言する方が安全だし、合理的だと思うからです。

  ヘッダの文字コードをヘッダで宣言する、ということでしょうか。もとのレ
ベルとメタなレベルとがいっしょくたになってしまって、よくわからないので
すが。

浜田 直樹

---

From: [email-masked] (Naoki HAMADA)
Date: 15 Oct 1993 06:06:33 GMT

>  8 bit 透過にして、日本ローカルに閉じることにすれば、その鎖国体制にお

  日本ローカル？日本語を使う人は今や、グローバルに分布しています。ロー
カルで済む問題ではないでしょう。また、日本語だけの問題でもないでしょう。

>のでしょうが。日本としての理想は、Mule の *junet* code のような方式の

  「日本としての理想」というときの「日本」とは？日本語を情報交換の手段
として使う人々はいますが、そこに「日本」を持ち込むのは変です。

浜田 直樹

---

From: [email-masked] (Junzou Kamahara)
Date: 14 Oct 93 18:10:55 GMT

鎌原＠阪大です。

>     日本語も素通りするように agent を改良する、規格を変えてゆく、という

 それが世界(Internet)で受け入れられるものでなければ、意味がありません。
まして、日本語が通るだけで、表示できるかどうかは環境やアプリケーション
に依存するのであれば、まったく意味がありません。他国の人が作ったプログ
ラムでそのまま日本語「も」表示できてこそ意味があると思います。

>   を複雑にするのは、見通しを悪くするばかりでかえって不便を招くというのが

 多国語化に単純化という解決があるとは思えません。日本語が見えればそれ
でＯＫ、というなら現状でいいでしょう。そして永遠に日本語化パッチを当て
続けるわけです。
 今は過渡期だから混乱があるわけで、私はそれは仕方ない代償だと思います。
将来は、逆にユーザはMIMEを使っていることを意識しない日が来るでしょう。

>   べきではないと考えます。わたしは前者を切望しますが、後者の必要性を感じ

 RFC1521が多目的化されたボディ部に関する記述で、RFC1522がヘッダに非
ASCIIを記述するための拡張です。これらを合わせてMIMEと呼ぶようになり
ましたが、もとのRFC1342(非ASCIIヘッダの拡張)が受け入れられないもので
あったならば、現在のようにはならなかったでしょう。

 私は、多国語化も多目的化も切望しています。人それぞれですね。
--
--------------------------------------------------------------
鎌原 淳三(かまはら じゅんぞう)([email-masked])
大阪大学大学院基礎工学研究科物理系専攻情報工学分野前期課程２年
宮原研究室(Information Network Architecture Lab.)
				Multimedia System Research Group

---

From: [email-masked] (SASABE Tetsuro)
Date: Fri, 15 Oct 1993 11:14:56 GMT

落ち付いて読んで欲しいんだけどなぁ。。。。。。。。。

In article <[email-masked]>
    [email-masked] (=?ISO-2022-JP?B?GyRCPGkyLBsoQiA=?=
	=?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= (MORIOKA Tomohiko)) writes:

 |  8 bit 透過にして、日本ローカルに閉じることにすれば、その鎖国体制にお
 |いて、問題は起きないでしょう。

  どうして鎖国なんです？

 |  8 bit 透過の上で、ISO-8859-* やら Shift-JIS やら、各国の EUC やら 
 |Unicode やらが飛び交う訳ですか？

  その通りです。だから、各国どの言語が流れるかは問題にしていません。そ
れがどうして鎖国になるのかしら？

 |笹部> 「皮肉な現象」でしょうか？
 |
 |  これは、RFC-822 に対応してなかっただけの話で、MIME の責任ではないと
 |思います。MIME header を使うようになって表面化しただけの話で、前から、
 |複数行の From: は認められていたのですから。

  しかし、結果論としては新たな対応が必要になったわけです。その点では
「MIME なら対応済み」というのは正しくありませんよね？ MIME ヘッダが流
れるようになってはじめて気付いたのですから。

 |  鎖国するならそれで良いのでしょうね。そして、日本語以外は本当に文字化
 |けする訳です。

  だ・か・ら、どうして鎖国なんですか？

  私は日本語以外読めませんから、それ以外を考慮する必要はありません。例
えばタイなら(タイの方で英語とタイ語以外を読める方がどれぐらいいらっしゃ
るかは存じませんが)タイ語と ASCII 以外が流れる可能性は高くは無いでしょ
う。台湾なら…(以下同文)。

# アジアなら中国系の人は現地語とは別に中国語が流れる必要があるかな。

  私は、受け取り手にとって必要の無い情報の透過を保証する必要は無いと言っ
てるんです。私が日本人だから日本語を例にしただけ。

  もりおかさんご自身が上で書いておられるように、

 |  8 bit 透過の上で、ISO-8859-* やら Shift-JIS やら、各国の EUC やら 
 |Unicode やらが飛び交う訳ですか？

なんですけど。何語を使おうと関知しないよ、というシステムがどうして鎖国
なんですか？

 |  けれど、この論では、日本語と英語だけを特別扱いする訳ですね。自分の判
 |る言語だけを、自分の使う言語だけを特別扱いする訳ですね。そのために、新
 |たなシステムの構築を迫る訳ですね。

  違います。
  8bit 文字の透過を保証するだけです。そのために変更は必要になるかもし
れませんが。それを「新しいシステムの構築を迫る」と言うなら

 |  それぐらいなら、常に、どんな言語・文字集合・エンコーディングを使うか
 |を明示した方が良くはないですか？

これだって「新しいシステムの構築を迫」っていることに違いはありません。

 |  日本は、EUC か Shift-JIS を使って、欧米諸国では、ISO-8859-1 を使って、
 |ブロック化を計ろうというのですか？

  また「日本は」なんて言いだす。

  そういう言い方をなさるなら、逆にお聞きしたいことがあります。MIME に
従ってエンコードしておけば、日本語を理解しない欧米の人であっても「ブロッ
ク」されることなく理解できるのですか？ まさか！

---

From: [email-masked] (Wataru KawaKami)
Date: Thu, 14 Oct 1993 13:20:50 GMT

NTTの川上です。表現が足らなくて、どうも、うまく伝わっていない
ようです。補足がかえって誤解を招かないことを祈って補足させていた
だきます。

は、ユーザインターフェイス部分でヘッダーとして扱っている部分を
必ずしも、ニュースシステムのヘッダーとして扱わなくてもいいと
いうことがいいたかったのです。

  例えば、ユーザーインタフェースとして、`題目'(サブジェクト)を
入力する部分があったとき、それは必ずしもそのまま、ニュースシス
テムの``Subject:''に入れる必要は、なく、ニュースシステムの`body'の
部分にいれても、対応しているニュースリーダーから`題目'として認識
できればいいのではないかということです。
  また、真に、転送経路でどのように表現されているかを問わないので
あれば、情報をニュースシステムの`header'におくか、`body'に置くか
は、大きな問題はないのではないかという意味です。

# compatibilityを考えると、題目を英語のような共通の言語にして
# `Subject:'にいれておいた方がいいとは思いますが。。。

ですから、`body'に題目をいれるのであれば、
 "fj.mail"の"Re: header ni MIME wo , no zakkan (Re: Why MIME ?)"について
    (記事<[email-masked]>)、[email-masked]、
 >> しょうね。また、ニュースリーダでフォローやリプライをする時に、元記事
はとくに必要ないと思います。(ニュースリーダで対応すればいいわけ
ですから。。。。)

  >> MIMEでは、そのようなことをせずに済むわけです。
MIMEは単にエンコードの方法ですから、各国語でのやりとりに真に
対応するには、やはり、ニュースリーダーの継承すべきフィールドは
増えると思います。

  >> かも知れないもの）は、デコードしないという選択もできるわけです。
これを活かすためには、むしろ、現在のように`Subject:'に詰め込む
のではなく、別途フィールドを設けるか、bodyにおくかしたほうが
いいと考えています。
  デコードしないと選択した,デコードできない人(対応のリーダー
もしくはフォントがない等)にとっては、読めない文字が延々と
`題目'として見えるわけですから。。。
					wataru

# MIMEもuuencodeもishも、binhexも同じ穴のムジナ？:-)
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Shinji Kono)
Date: Fri, 15 Oct 1993 15:16:43 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (TAKADA Toshihiro ) writes 
>"<" 等)もちゃんと処理しないと駄目だと思うのですが、

もともとE-Mail addressが「英語/Ascii」なのに、余計なものをfieldを別に
入れるから変になるんじゃないかなぁ。fieldが別ならMIMEを使おうと使うまいと
便利だと思います。addressに日本語が使えるようになるなら別ですけど。
Subject fieldだって英語と日本語別にあった方がいいと思う。

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

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sat, 16 Oct 1993 00:07:02 GMT

On 10/15/93(20:14) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]> (fj.mail:2156/etlss2):
 |落ち付いて読んで欲しいんだけどなぁ。。。。。。。。。
 |
 |In article <[email-masked]>
 |    [email-masked] (守岡 知彦 (MORIOKA Tomohiko)) writes:
 |
 | |  8 bit 透過にして、日本ローカルに閉じることにすれば、その鎖国体制にお
 | |いて、問題は起きないでしょう。
 |
 |  どうして鎖国なんです？

鎖国しないことには、国外への流出を食い止められないからでしょう。
そのようなニュース／メイルを一粒たりとも国外へ出さないというのは、
困難だとは思いますけど。

 | |  8 bit 透過の上で、ISO-8859-* やら Shift-JIS やら、各国の EUC やら 
 | |Unicode やらが飛び交う訳ですか？
 |
 |  その通りです。だから、各国どの言語が流れるかは問題にしていません。そ
 |れがどうして鎖国になるのかしら？

笹部さんがどう感じるかではなくて、インターネットの世界中がそれを受
け入れるかどうかが問題なわけですね。
いずれにしても、どの文字セットのどのようなエンコーディングであるか
が判別不能なような文字コードがヘッダ中に許容されることは、無いと思
いますけど。

 | |笹部> 「皮肉な現象」でしょうか？
 | |
 | |  これは、RFC-822 に対応してなかっただけの話で、MIME の責任ではないと
 | |思います。MIME header を使うようになって表面化しただけの話で、前から、
 | |複数行の From: は認められていたのですから。
 |
 |  しかし、結果論としては新たな対応が必要になったわけです。その点では
 |「MIME なら対応済み」というのは正しくありませんよね？ MIME ヘッダが流
 |れるようになってはじめて気付いたのですから。

長いフィールドの折り返し(foldingは)、RFC822の極めて基本的で重要な仕
様です。これに対応していないような MTA/MUA は、すぐに直すべきだと思
います。別にMIMEを使わなくても、Ccなどでは長い行は良く起こります。
RFC822に準拠していない MTA/MUAで、RFC822準拠のメッセージが問題を起
こした場合、責任はその MTA/MUAにあります。

RFC822に準拠していないメッセージを流して、RFC822準拠のMTA/MUAで問題
を起こした場合、責任はそのメッセージを流した人にあります。
例えばヘッダに8bitsを通したいと思うなら、そのようにRFC821/822の拡張
を提案して、インターネットの承認を得なければなりません。

実際、今まさにRFC822のバージョンアップ作業がietf-smtpで進められて
いますから、何かを主張するなら今がチャンスでしょう。

  [RFC1425] SMTP Service Extensions
  [RFC1426] SMTP Service Extensions for 8bit-MIMEtransport

ietf-smtpのMLへの参加は、[email-masked]
付けています。（ぼくは参加してないですが）

[RFC1426]:
>3.  Framework for SMTP Extensions
...
>          (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.
...
>   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
>       USC/Information Sciences Institute, August 1982.
>
>   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
>       Messages", STD 11, RFC 822, UDEL, August 1982.
>
>   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
>       Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
>
>   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
>       Headers", RFC 1342, University of Tennessee, June 1992.
>
注：RFC1341,1342はRFC1521,1522で置き換えられました。

 | |  鎖国するならそれで良いのでしょうね。そして、日本語以外は本当に文字化
 | |けする訳です。
 |
 |  だ・か・ら、どうして鎖国なんですか？

海外に迷惑をかけないためですね。

 |  そういう言い方をなさるなら、逆にお聞きしたいことがあります。MIME に
 |従ってエンコードしておけば、日本語を理解しない欧米の人であっても「ブロッ
 |ク」されることなく理解できるのですか？ まさか！

MIMEにエンコードしていないと、sendmailなどのMTAで理解できないことが、
第一の問題だと思います。また、例えば数か国語で併記してあったときに、
読み手の読める／表示できる文字だけを表示するとかもできるわけです。
まあ、将来的には「これは日本語だから英語に翻訳して表示」みたいなのが
自動化されると素敵ですけどね(^_^)

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sat, 16 Oct 1993 00:16:57 GMT

On 10/16/93(09:07) I wrote in <[email-masked]>
 |実際、今まさにRFC822のバージョンアップ作業がietf-smtpで進められて
                ^^^^^^
                RFC821(SMTP)の間違いです(^_^;)

たぶん、まだ proposed standardの段階です。

RFC822の拡張をやっている ietf-822 のほうは、MIME(RFC1521,1522)を
draft standard化して、ほとんど役目を終えたようです。

蛇足ですが、インターネットの標準や、その作成・更新作業については、

  [RFC1310]  The Internet Standards Process  (March 1992)

に示されています。（その後これ自身が更新されたかどうかは、知りま
せん-_-）

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Sat, 16 Oct 1993 21:21:23 GMT

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

>いるかを宣言する方が安全だし、合理的だと思うからです。

nao>   ヘッダの文字コードをヘッダで宣言する、ということでしょうか。もとのレ
nao> ベルとメタなレベルとがいっしょくたになってしまって、よくわからないので
nao> すが。

  MIME header の場合、

=?ISO-2022-JP?B?日本語文字列?= =?ISO-8859-1?Q?latin-string?= ...

みたいな、複数の文字コード・エンコード系の混在が許されます。この際、必
然的に、どの文字コード・エンコード系を使っているかを宣言することになり
ます。

---

From: [email-masked] (Kenji Rikitake)
Date: 15 Oct 1993 15:09:52 GMT

In article <[email-masked]> [email-masked] (Yutaka Sato =?ISO-2022-JP?B?GyRAOjRGI0stGyhK?=) writes:
 |日本だけが苛められていると思うのは、違うと思います。ASCII だけで
 |足りる国を除けば(^_^)、みんな平等ですよね。

単なるルサンチマンだけでは技術は進歩しないと思う。
個人的にはMIMEにもUnicodeにも不満はあるけど、ある物は使って行きたい。

…という以上の意見は私にはありません。

// Kenji
--
Kenji Rikitake <[email-masked]> <[email-masked]> 
"If privacy is outlawed, only outlaws will have privacy."
                                         -- Philip Zimmermann, PGP User's Guide

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sun, 17 Oct 1993 08:02:55 GMT

On 10/14/93(22:20) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]>
 |は、ユーザインターフェイス部分でヘッダーとして扱っている部分を
 |必ずしも、ニュースシステムのヘッダーとして扱わなくてもいいと
 |いうことがいいたかったのです。
 |  例えば、ユーザーインタフェースとして、`題目'(サブジェクト)を
 |入力する部分があったとき、それは必ずしもそのまま、ニュースシス
 |テムの``Subject:''に入れる必要は、なく、ニュースシステムの`body'の
 |部分にいれても、対応しているニュースリーダーから`題目'として認識
 |できればいいのではないかということです。
 |  また、真に、転送経路でどのように表現されているかを問わないので
 |あれば、情報をニュースシステムの`header'におくか、`body'に置くか
 |は、大きな問題はないのではないかという意味です。

そのような合意がとれた社会の中で行われているならば、他から口だしする
ようなことでもありません。
＃私が必要としているのは、RFC822に基づくインターネットメイル／ニュ
＃ースシステム全般に適用可能な解ですけれど。

ただ、注意して頂きたいのは、メッセージのボディを勝手に書き換えて良い
というような規約はないということです。ヘッダの一部をボディに自動的に
挿入するようなゲートウェイが時々見られますが、これは大きな問題です。
MIME(RFC1521)では、ボディ部は単なる文字列でなく、Content-Typeに定義
された型の構文に従う文です。これを破壊するのは大きな問題です。

それでも、ボディ部にヘッダの一部を挿入するなら、MIMEのmultipart/mixed
型あたりに従って欲しいと思います。これは、i-headers ML でどなたかが
提案されてましたっけ。MIMEは拡張が可能な規格ですから、新たな型を合意
して登録するのが、良いと思います。

 | >> そのためにはまず、NNTPのHEADコマンドを作り変えるなどの必要があるで
 | >> しょうね。また、ニュースリーダでフォローやリプライをする時に、元記事
 |はとくに必要ないと思います。(ニュースリーダで対応すればいいわけ
 |ですから。。。。)

これは、UA(ニュースリーダ)で対応できない例の一つとしてあげました。
記事の一覧を行うためにHEADでなくARTICLE全体を見なければならないと
すると、性能的に大きな損失になります。

 |  >> から継承すべきフィールドも増えます。それを、色んな国の文字に対して
 |  >> やるのは、簡単ではないでしょうね。
 |  >> MIMEでは、そのようなことをせずに済むわけです。
 |MIMEは単にエンコードの方法ですから、各国語でのやりとりに真に
 |対応するには、やはり、ニュースリーダーの継承すべきフィールドは
 |増えると思います。

ここは意味がとれません…
RFC1522のどこが問題なのか、具体的に指摘して頂けると助かります。
RFC1521とRFC1522がごっちゃになっているような気がするのですが…？

 |  >> MIMEでは Subject(に限りませんが)に英語でも日本語でもロシア語でも、一
 |  >> 緒に併記することができます。例えば Cc などに、いろんな国の人の名前が
 |  >> いろんな文字セットで入っていて構いません。また、自分の読めない文字や、
 |  >> 端末に表示できない文字セット／エンコーディング（特に、端末に害がある
 |  >> かも知れないもの）は、デコードしないという選択もできるわけです。
 |これを活かすためには、むしろ、現在のように`Subject:'に詰め込む
 |のではなく、別途フィールドを設けるか、bodyにおくかしたほうが
 |いいと考えています。
 |  デコードしないと選択した,デコードできない人(対応のリーダー
 |もしくはフォントがない等)にとっては、読めない文字が延々と
 |`題目'として見えるわけですから。。。

表示しないという選択もあり得るわけですが…

 |# MIMEもuuencodeもishも、binhexも同じ穴のムジナ？:-)

MIMEでは「ヘッダ中の非ASCIIはエンコードする」と割り切ることで、RFC822
に準拠しつつ各国文字へ「なんとか」対応しているわけです。
これがエレガントな方法だとか完璧な解だなどとは、だれも主張していません。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sun, 17 Oct 1993 08:30:19 GMT

On 10/16/93(00:09) [email-masked] (Kenji Rikitake) wrote
in <[email-masked]> (fj.mail:2164/etlss2):
 | |日本だけが苛められていると思うのは、違うと思います。ASCII だけで
 | |足りる国を除けば(^_^)、みんな平等ですよね。

ASCIIだけで足りる「国」なんて実際にはないでしょうけどね。「人」
は居るかも知れないけど。

 |単なるルサンチマンだけでは技術は進歩しないと思う。
 |個人的にはMIMEにもUnicodeにも不満はあるけど、ある物は使って行きたい。

個人的にはUnicodeは嫌いなので(^_^;)MIMEと並べて欲しくありません。
Unicodeの指向と、MIMEの指向は正反対だと思います。

ただ、Unicodeが外国原産のテキスト処理系のインフラをマルチバイト
対応化に腰をあげさせる効果はあるでしょうから、反対はしませんけど。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Naoki HAMADA)
Date: 18 Oct 1993 08:42:28 GMT

>然的に、どの文字コード・エンコード系を使っているかを宣言することになり

  つまり、ヘッダ部でヘッダ部の文字コードを宣言する時には、局所的な宣言
になる、と理解してよろしいでしょうか？そしてそれは、ヘッダ部で本体の文
字コードを宣言する方式とは原理がことなる、と。

浜田 直樹

---

From: [email-masked] (Naoki HAMADA)
Date: 18 Oct 1993 09:07:04 GMT

わたしの主張は笹部さんとほぼ同じなので、繰り返すことはしません。

>将来は、逆にユーザはMIMEを使っていることを意識しない日が来るでしょう。

  好むと好まざるとに関わらず MIME が送り付けられてくるという現状があり
ますから、これはぜひそうあってほしいものです。いちいち「おお、これは 
MIME じゃ、解読せねば」なんて手間をかけずに、transparent に使えてほし
いものだと思います。

浜田 直樹

---

From: [email-masked] ( 守岡 知彦 (MORIOKA Tomohiko))
Date: Tue, 19 Oct 1993 00:11:16 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Naoki HAMADA) 氏曰く、
nao> NNTP-Posting-Host: mimo

>然的に、どの文字コード・エンコード系を使っているかを宣言することになり

nao>   つまり、ヘッダ部でヘッダ部の文字コードを宣言する時には、局所的な宣言
nao> になる、と理解してよろしいでしょうか？そしてそれは、ヘッダ部で本体の文
nao> 字コードを宣言する方式とは原理がことなる、と。

  そうだと思います。

  header を規定しているのは RFC-1522 で、body の文字コードは RFC-1521 
の Content-type: の charset で宣言されます。body が multipart の場合は、
part 毎に文字コードが違っても良いはずです。（例えば、同じ内容を複数の
言語で併記する場合、自分の読める言語だけ表示する、というようなことがで
きます。）

  次のような例が、RFC-1522 に載っています。

      From: Nathaniel Borenstein <[email-masked]>
            (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
      To: Greg Vaudreuil <[email-masked]>, Ned Freed
         <[email-masked]>, Keith Moore <[email-masked]>
      Subject: Test of new header generator
      MIME-Version: 1.0
      Content-type: text/plain; charset=ISO-8859-1

  header には ASCII と ISO-8859-8 を使っており、body は ISO-8859-1 で
す。

      From: =?US-ASCII?Q?Keith_Moore?= <[email-masked]>
      To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[email-masked]>
      CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <[email-masked]>
      Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
       =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

  これは、ちょっと奇妙な例ですが、US-ASCII と MIME のアルファベットで
ある ASCII は厳密に言えば違う概念なのかも知れません。普通はこんなこと
はしないと思いますが。この例では、body は MIME 形式になっていません。

---

From: [email-masked] (Chiaki Ishikawa)
Date: 18 Oct 93 11:45:50 GMT

In article <[email-masked]> [email-masked] (SASABE Tetsuro) writes:

     だ・か・ら、どうして鎖国なんですか？

たしかにそのような２つより多い複数語を必要とするパーセンテージは人口か
らみればすくないのかもしれませんが、必要とする人たちが、必要とする度合
は文字通り喉から手が出る程ほしいというものではないかと思います。私も欲
しいです。

たしかに。

たしかにこれも一つの判断基準ですが、
mail, news のように広くの場所で使われるツールの場合には、
（２つより多い）複数語をサポートするような機能をいれておくのが好ましいと思います。

 MIMEのようにすれば ugly かもしれないが、今のままでできるわけで
すから。もっといい方法が簡単に手にはいるようになればそちらに移行するこ
とにまったく異議はありません。この辺は誤解しないでください。ともかく複
数語の機能がエンドユーザレベルでつかえればなんでもいいわけです。

メイルとかニュースでは interoperability を確保したいわけですし、
できれば広範囲に流布するサンプルインプリメンテーションが
北米、ヨーロッパなどで容易に入手できるようになっていると
このましいと思います。
かくいう私のところでも
	News は Bnews, INN をつかっていますし、
	reader としては、Bnewsについてきたreaderの日本語化されたものと
か、Nemacsとかがつかわれています。
結局自分のところで作ったものはほとんどありません。

ということは、メインテナンス、バグフィクス、ユーザフィードバック向上な
どを手間をかけずにおこなうには、多数のユーザ（北米、南米、ヨーロッパな
ど。他の地方はまだユーザがすくないようです）が満足をえられるような自由
に入手できるソフトウェアが存在すると便利です。（いまの現状だと北米
で変更したバージョンを日本、ドイツとか、フランスとかでいちいち直してい
ると思われます。日本語向きのパッチを流して下さる方々には感謝しています。）

MIME だとそのような現状をすこしでも解消できるための基盤を提供できない
でしょうか？（もちろん最初にニュースリーダーとかの大幅な変更はいるかも
しれません。この辺は実際にMIMEのフィルターなどを作っている人の意見をき
きたいです。）

現在のところニュース、メイルなどはどうしても北米のバイアスが多いのは歴
史的に考えても当然なので、それをどうこういっても世界のニュース、メイル
のインストレーションをいきなり全部変更できない現状ではすこしずつ秩序を
みださない形で変更していくのが一番よいのではないかと思います。

ここで、MIMEの代替案を考慮している方々に考えて欲しいのは、今の日本語化
されたニュースリーダーとかメイルリーダーではヨーロッパの８ビット文字コー
ドがうまくサポートできないように見受けられることです。ヨーロッパのユー
ザーは数も多く、発言力はおおきいですから彼らにも使えるような形式で拡張
しておかいないと、相互に運用できるような拡張形式（MIMEのようなもの）が
好ましいと思います。
（Muleについてはまだつかっていないので知りません。NemacsがFSFのメイン
のディストリビューションにはいらなかったのは、おそらくそのままではあま
りにも 日本語に特有で他の８ビット言語と両立できなかったためだと思いま
す。それでMuleが作られたのでしょうが、一方でFSF から Emacs 19がでて
しまいまたバージョンの違いの問題が存在しています。
v19は better 8-bit support をうたっているようです。MIMEは好き
嫌いは別としてヨーロッパでも原理的には問題なく使うことができるはずので、
将来いろいろな自由に流布しているメイル、ニュースリーダがMIMEをサポート
する可能性がたかく、こういったソフトウェアのバージョン変更にともなう日
本語パッチの作成といった作業がへるのも魅力です。もちろん
自分でこういったパッチを作らない人、あるいは自分でニュース、メイルソフ
トウェアのメインテナンスをしない人にはどうでもよい点かもしれませんが、
わざわざこのNGを見るような人にとっては重要なことではないでしょうか。）

     もりおかさんご自身が上で書いておられるように、

ここは私の勘違いかもしれませんが、たぶんmimeのようにはっきりと決まった
形で内部のコード表現とかがきめられていれば、NewsReaderなりmail reader 
で、外からきたデータを複数のコード文字をサポートするための内部表現に変
換が確実にできるとかいうメリットがあるのではないでしょうか。（もちろん
２つ異常の複数の言葉がとびかうような使用状況を想定しています。）

Mimeに関しては好きだとか嫌いだとかいう発言が見られました。
私もMIMEのアプローチがきれいだとはおもいませんが、

- 相互に接続を要求される既存サイトが非常に多数ある。
- これらの相互接続には長期に使われている標準のプロトコルがすでに存在す
  る。（さいわいなことにプロトコルに追加／変更を提案するための手続きは
  明確に存在して、日本からも提案を出していくことが可能である。）
- ニュース、メイルの性格からなるだけ広範囲のところで使ってもらう必要が
  ある。
- 既存のニュースソフトウェア、メイルソフトウェアの使用をこれらのサイト
  でいきなり完全に新しいもので置き換えることは事実上不可能:（なかには
  コンピュータ会社が存在しなくなり７ビットのソフトウェアのバイナリしかないまま使っ
  ているなんていうところも北米にはあるらしいです。ちょっと極端な例ですけど。）
  すっかり置き換えよりは、上にかぶせるような形が好まれるだろう。

(さらに - 日本語、ASCIIといった２つの言葉だけのサポートではすでに足り
ないという条件もいれたいと思います。ヨーロッパの言語のサポートを無視で
きないとおもいませんか？ つまり、借りにMIME以外の方法があって、それを
ソフトウェアで提供しても、日本語英語だけしかサポートできないよ
うなものは、結局ヨーロッパのサイトにはうけいられず、相互に接続を要求さ
れる意味から北米のサイトでも広くはうけいれられないのではないでしょうか？）

といった上記の制限条件[他にもあるかもしれませんが。]の中で多数の国の言
葉をサポートするためにはコストの面でMIME はいい線いっているかもしれな
いと思っています。こまかな点で現在いろいろ仕様がつめられているようです
が、早く仕様がフィクスしてどんどん使えるような環境になればよいと思って
います。（エンドユーザーはどんな方式をつかっていようとともかく使えれば
よいのですが。最初にいったように、MIME以外でこれができればそれを使うに
はやぶさかではありません。）

別の話題ですが、Unicode については誰か別の方もいっていましたが、
Unicodeそのものは嫌いですが、北米のプログラマたちが
国際化にたいして興味をもつようになるための最初の刺激をあたえたという意
味で評価しています。（ヨーロッパのプログラマたちは２バイトコードに対しての理解
は別として、国際化に対しては北米のプログラマよりもはるかに意識していま
す。ですからそのようなプログラマたちにも受け入れることができるような解
決策を提案すると多数国語をサポートするようなシステムを実現できる近道だ
と思います。もちろんヨーロッパのプログラマの中にも全部８ビットを通すような
ソフトウェアでおきかえればよいというような発言をする人も見聞きしましたが、そ
の人たちは既存のサイトのソフトウェアの置き換えのコストは無視するとはっ
きりいいきっていました。私見ではこのコストは無視できないと思います。）

石川

---

From: [email-masked] (Shinji Kono)
Date: Mon, 18 Oct 1993 15:52:05 GMT

[email-masked]。こういう話題ってあんまりいいNGがないな。

In article <[email-masked]> , 
	[email-masked] writes 
>すから。

だからって、「Subject fieldにはASCIIならばなんでも入れてもいいんだろう」
みたいな発想が許されるとは思いません。

「Mailのheaderとbodyはbianryであって、ユーザが読むべきものではない」みた
いな発想もあるのは知っていますが、Unix的だとは思いません。Flat Textみた
いな概念がInternationalizationを生き残るにはそれなりのコストがかかりま
す。MIMEの方がより安いのは、そういうコストを無視しているからです。MIME
が互換性が高いのはプログラムにとってだけで、人間にとってじゃないでしょ
う?

せっかく、構造的なMail Headerを持っているのだから、それを使って
改善する方が簡単だと思うんだけどな。

まぁ、sendmail levelやrelaynews levelで変換してくれるならMIMEでも許さな
いでもないんですが、それだったら、

>きりいいきっていました。私見ではこのコストは無視できないと思います。）

ってのが成り立たないし...
---

---

From: [email-masked] (Naoki HAMADA)
Date: 19 Oct 1993 02:23:01 GMT

>（２つより多い）複数語をサポートするような機能をいれておくのが

  どのレベルでサポートするか、というのがひとつの問題になりますよね。 
news/mail の形式的な規格自身にぶち込んでしまうのではなく、そのレベルで
は可能なだけ透過性を高めるだけにしておいて、ユーザーインターフェースの
レベルで対応するのが良い、というのがわたしの主張です。そうやって切り分
けておいた方が問題が単純になって解決しやすいと思うのです。

  複数語の環境がどのように運用されるか、というところまで考えて 
news/mail の形式的な規格を決定しようとしても、実際にどのように運用され
るかはやはり、ユーザーの事情によっていろいろでしょうから、そうそう簡単
に決められるものでもないと思うのです。

  ひとつの文章のなかに複数語を記述して、全部わかる人に読んでほしい、と
いう人もいれば、ひとつの文章を複数語で書いて、どれかわかる人なら読める、
という人もいるでしょうし。

  そういう意味では、news/mail での 8bit 透過性を保証しておいて、あとは
ユーザーのがわで JUNET 方式＋Mule 方式みたいなものを利用するなり、自由
度を残しておく、というほうが望ましく思えます。

>しておかいないと、相互に運用できるような拡張形式（MIMEのようなもの）が

  ネットワーク上の力関係はともかくとして、ASCII だけでは表現できない文
字体系のひとつとして日本語をも使えるようにする、という姿勢は必要ですね。
日本語が特殊なのではなくて、ASCII だけで表現できる言語が特殊なんだ、と
声を大にして主張したいところです。

>MIMEは好き
>本語パッチの作成といった作業がへるのも魅力です。

  ヨーロッパで作成される MIME インターフェースが、はたして日本語をサポー
トするかどうか、わたしは非常に疑問に思うのですがいかがでしょう。そうい
う意味では楽観を許さないとわたしは思います。

浜田 直樹

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 19 Oct 1993 03:48:33 GMT

NTTの川上です。

  ご存知でしたら、お教え下さい。

"fj.mail"の"Re: header ni MIME wo , no zakkan (Re: Why MIME ?)"について
    (記事<[email-masked]>)、[email-masked]、
  >> そのような合意がとれた社会の中で行われているならば、他から口だしする
これは、bodyの部分に、例えば、
	TITLE: これは題目です
ということを書いてはいけないという決まりがあるので、Internet mail/
newsでは、user-interfaceのヘッダー(題目、宛先など)をbodyにいれては
いけないということでしょうか。

  >> 挿入するようなゲートウェイが時々見られますが、これは大きな問題です。
これは、記事の発信人が出す場合ではなく、中継経路がボディを書き換える
場合のことのみと考えていいのですよね？

  もし、これが記事の発信人にも適用されるのなら、
  >> な形で表現され、転送されていても、気になりません。
とはいえませんね。

 >> RFC1521とRFC1522がごっちゃになっているような気がするのですが…？
私が誤解している可能性があるので、その前に、佐藤さんの``継承''が
指しているところを確認させて下さい。私が理解している範囲では、
	各国語をその国別に個別のフィールドを設けてimplementした
	場合、それぞれのフィールドをニュースリーダーが解釈して
	やる必要がある
	(その点、佐藤さんのMIMEを用いた方法であれば、例えば、
	題目であれば、Subjectのみを解釈してやれば良い)
という意味かと思っています。

 >> 表示しないという選択もあり得るわけですが…
Subjectを表示しないという意味でしょうか。
# それでは、何のためのSubjectなんでしょう。。。

 >> これがエレガントな方法だとか完璧な解だなどとは、だれも主張していません。
だれもそんなことはいっていませんよ。過剰反応しないで下さいね。
# お手やわらかに。

  MIMEもuuencodeもishもbinhexも、printableな文字しか伝送でき
ない伝送路を用いて、等価的に8bitの情報をやりとりする伝送路を
提供するための方策に過ぎないという意味を込めて書いただけです。

  ですから、多国語化ということと、8bitが等価的に通るように
なったということは切り離して考えた方がよいのではと思ってい
ます。
					wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

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

X-Nsubject: Re: なぜMIME?

"fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> が互換性が高いのはプログラムにとってだけで、人間にとってじゃないでしょ
同感です。
 私>しまい、Subject:/From:行の可読性が失われるように思います。今の
 私>newsって、Subject:/From:行が可読であるのも特徴だと聞いています。

 >> >きりいいきっていました。私見ではこのコストは無視できないと思います。）
これも同感です。せめて、upper compatibilityは保っていか
ないと。。。
# 別に、X-N*がいいといっているわけではありません。> MIME'er

						wataru

---

From: [email-masked] (Chiaki Ishikawa)
Date: 19 Oct 93 09:10:22 GMT

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

そうですね。 fm.mail.mime?

私の考えでは ともかく newsreader, mail reader などが
mime (なり何らかの手段）をサポートすることで
人間（ユーザ）は気にせず使えるようななるのが理想です。
ですから、最初の MIME (なり何らかの手段）のサポートのコストは
かかるのはやむをえないと思います。

Mime はヘッダフィールドを適宜使っていると思うのですが？？

   ってのが成り立たないし...

私は、これはやはり newsreader, mail reader (user agentというのでしょう
か？）のレベルのサポートが一番手身近かと思います。

石川＞- 既存のニュースソフトウェア、メイルソフトウェアの使用をこれらのサイト
石川＞  でいきなり完全に新しいもので置き換えることは事実上不可能:（なかには

といったときの「ニュースソフトウェア、メイルソフトウェア」といったときには
おもに send mail level, relay news levelのことを考えていました。
newsreader, mail reader レベルでしたらいわゆるシステムにあまり手をいれ
ずにユーザレベルのプログラムの変更で対応できる可能性が高いので、おおざっ
ぱにいってコストが低いかとおもったわけです。（もちろん各サイトの管理者
にはそれなりの手間がかかるでしょうが、このコストは得られる機能を考えれ
ばリーズナブルではないかと私見では思います。もっともコストの算定は
サイト／個人でちがうとは思います。）

石川

---

From: [email-masked] ( 守岡 知彦 (MORIOKA Tomohiko))
Date: Wed, 20 Oct 1993 05:00:44 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Wataru KawaKami) 氏曰く、

 >> これがエレガントな方法だとか完璧な解だなどとは、だれも主張していません。
川上> だれもそんなことはいっていませんよ。過剰反応しないで下さいね。
川上> # お手やわらかに。

川上>   MIMEもuuencodeもishもbinhexも、printableな文字しか伝送でき
川上> ない伝送路を用いて、等価的に8bitの情報をやりとりする伝送路を
川上> 提供するための方策に過ぎないという意味を込めて書いただけです。

川上>   ですから、多国語化ということと、8bitが等価的に通るように
川上> なったということは切り離して考えた方がよいのではと思ってい
川上> ます。

  これはその通りだと思います。MIME は 8 bit が通るのなら、それをそのま
ま通すことができますし、それができないなら、適当な encoding をかけて通
します。MIME の encoding が MIME なのではなくて、その宣言性が MIME な
のだと思います。

  文字コードの統一や 8 bit を通す通信路の確保が「バイナリー・ベース互
換」とするなら、MIME のはソース・レベルの互換のようなものだと思います。

---

From: [email-masked] (Akira Takuma)
Date: Tue, 19 Oct 1993 12:05:46 GMT

宅間＠松下ソフトリサーチです。

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

  | ただ、注意して頂きたいのは、メッセージのボディを勝手に書き換えて良い
  | というような規約はないということです。

単なる思いつきですが、例えば MIME-Subject: など新しいフィールドを
ヘッダに設けてそこに文字セット名と uuencode みたいなものでエンコード
するというのはどうでしょうか。

Subject: TEST
Mime-Subject: ISO-2022-JP 1B24402546253925481B284A
                          ~~~~~~~~文字コードをそのまま 16 進 2 桁で続ける
みたいに。
X-Nsubject の考え方はこれに近いものがあります。現行の X-Nsubject
では ESC をヘッダ中に埋めるのという違反がありますが、これによる
トラブルは ESC が欠落する以外は遭遇したことがありませんし、これは
前もって削除しておいたり欠落しても強引に復活できます。(一部復活
できないパターンもありますが)
X-Nsubject 自体を削除される場合もごく稀にありますが、MIME においても
Content-Type とかが削除されることもあるので似たようなもんだと思って
います。

  | これは、UA(ニュースリーダ)で対応できない例の一つとしてあげました。
  | 記事の一覧を行うためにHEADでなくARTICLE全体を見なければならないと
  | すると、性能的に大きな損失になります。

今の MIME の実装ではヘッダ全体に渡って MIME 対応かどうか調べる必要が
あり性能的にも損失が大きいと思います。特に MIME では簡単に複数行に
なってしまうので継続行を繋げて空白を除いて奇麗に表示しようとすると
なおさらです。下手に毎回 metamail などの外部フィルタなど呼ぶような
実装でもしようものなら悲惨な速度になります。(実際開発中にいくらかの
パターンを試して実感しました)

そこでさっきの例みたいに Mime- で始まるヘッダだけは必ずエンコードされて
いることとし、Mime- を除いた名前のヘッダと置き換えてリーダが表示する
わけです。
こういう単純なルールであればリーダも作るのが楽ですし、Mime-* を解釈
しないリーダは従来のフィールドをそのまま表示すればいいのです。

とりあえず Subject ぐらいはみれないと困るので mnews でも MIME-ML
でお世話になりつつ ISO-2022-JP ヘッダだけは対応作業中(デコード側は
ほぼ完成)ですが、どうも中途半端な気がしてなりません。

MIME 自体にはほぼ賛成ですが、その価値は VISUAL/AUDIO/EXTERNAL
などにあると思います。

# でも世の中の動きに流されるんだろうなぁ。:-)
-- 
-------------------------------------------------------------------------
(株) 松下ソフトリサーチ	第一開発部 第一開発室 宅間
				E-mail:[email-masked]
-------------------------------------------------------------------------

---

From: [email-masked] (SASAKI-susumu)
Date: Tue, 19 Oct 1993 20:21:14 GMT

どこにコメントしたらいいかわかんねーんで適当に・・

「現在MIME対応じゃない news/mail-reader を使用している人間」に
とってはうざったいだけな代物な訳で・・・

「MIME対応のリーダー等はどこにどんな物が現在存在しているのか?」を
教えていただけないでしょうか?

ひとまず読むだけは読んでみたいと思ってはいるんですが・・・
-- 
	from [email-masked]
	佐々木 進/JA7VVT/atlan@mixcosy/pcs24554/GNG85986@PC-VAN
	([email-masked])

---

From: [email-masked] (TAKADA Toshihiro / 高田敏弘 )
Date: 19 Oct 1993 19:26:10 GMT

こんにちは、たかだ＠NTTです。

"Why MIME ?" について書きたいこともあるのですが、とりあえずこれ...

>   [email-masked]。こういう話題ってあんまりいいNGがないな。

そうですね。fj.mail.mime を作りませんか？

勿論 MIME 以外にも、8bit thru smtp の有効利用を考えるだとか何だとか、
他にも今後出てくる話は色々とあるでしょう。けれども、それはまだ
fj.mail で収めきれると思いますし。

現在 MIME に関する話題は fj.mail のみならず、各MIME対応のソフトウェア
や各環境といった文脈から、fj.editors.{emacs,mule} やら fj.sys.sun やら
何やらとあちこちでされていて、個人的には不便に思っています。

そういった他のNGでされた話も含めれば実績も充分だと思いますし。

どんなもんでしょうか？ 皆様。

---

From: [email-masked] (Takeshi Kusune)
Date: Wed, 20 Oct 1993 05:24:47 GMT

楠根＠慶応藤沢と申します。

このメールの内容

  ・ＭＩＭＥ（ヘッダー）に対応するのは難しい。
  ・私の使っているＭＩＭＥ対応の為のツールの紹介
  ・設定の仕方を教えて下さい。

 >> 「MIME対応のリーダー等はどこにどんな物が現在存在しているのか?」を

私もそう思います。

まえからＭＩＭＥの規格の（？）from: などがたくさん飛び交ってて、読んで
みたいのに読むことができないってことが良くありました。私の場合は学校の
とても大きなネットワークなので、ネットワークの管理者にＭＩＭＥなどに対
応するほどの機動力が期待できなかったので、自分で対応するしかありません。

仕方ないのでそういうフィルターなんかを探してインストールしようと思った
のですが、ＭＩＭＥに対応するためのキットがどうやら何系統もあるようで、
どれとどれを使えばどのレベルまで対応できるのかがとてもわかりにくかった
んです。

現在どうにかＭＩＭＥヘッダーを読むことまではできるようになりましたが、
投稿する時などはまだ未対応の状態です。それにどうも違う系統の同じ種類の
プログラムをダブって使用しているようですし。

私の英語力が弱いのが問題の原因なのかも知れませんが、こういう作業に抵抗
の少ない私でさえこう感じるのですから、私の大学の他の学生（このキャンパ
スでは理系分系に関わらずアカウントを全員持っています）のような人がＭＩ
ＭＥに対応するのは至難の技だと思います。

で、私の場合ですが、

  ・mime.el （Copyright (C) 1993 Masanobu UMEDA）
  ・tiny-mime.el （この間ニュースにながれてた）
  ・mimehead.tar.Z （etlport.etl.go.jpから）
  ・mm2.6.tar.gz、romime-1.1.shar.gz （bash.cc.keio.ac.jp から）

というものを持っています。

これらのツールの機能を使いこなす為の設定の仕方を教えてもらえば嬉しいの
ですが（多分機能は重複してると思います）。私の使っているリーダーは 
GNUS ver 13.3と MHE（以下のように書いてある）です。

 >> ;;;  mh-e.el	(Version: 3.6 for GNU Emacs Version 18 and MH.5 and MH.6)
 >> (setq mh-e-RCS-id "$Header: mh-e.el,v 2.24 88/08/29 12:07:53 larus Exp $")

.emacsのうち関係ありそうな部分をつけておきますので、なにか変なことをし
ているなら指摘して下さい（load-path などはちゃんと設定してあります）。

では、よろしく。
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
慶應義塾大学環境情報学部環境情報学科１年 楠根 雄志  埼玉県春日部市在住
           メールアドレス:[email-masked] (湘南藤沢キャンパス)
                          [email-masked]     (日吉キャンパス)

----------------------------------------------------------------------
(autoload 'mime-mode "mime" "" t)

;;
;; For mime
;;

;; (a) To use with mh-e, set up like followings on your .emacs:

;; In case of MH-E, you need the following hook definition:

(setq mh-letter-mode-hook
      (list
       (function
        (lambda ()
          (mime-mode)
          (make-local-variable 'mail-header-separator)
          (setq mail-header-separator "--------")))))

(setq mh-folder-mode-hook
      '(lambda()
;;;;	insert your current settings here
	 (require 'romime-mhe)))

(setq mh-compose-mode-hook
      '(lambda()
;;;;	insert your current settings here
	 ))

;; (b) To use with GNUS, set up like followings on your .emacs:

(setq gnus-Startup-hook ;; On GNUS 3.15 or later, gnus-startup-hook
      '(lambda ()
;;;;	insert your current settings here
	 (require 'tiny-mime)
	 (require 'romime-gnus)
	 ))

(setq gnus-Subject-prepare-hook
      '(lambda ()
	 (mime/decode-message-header)))

(setq gnus-Article-prepare-hook
      '(lambda ()
;;	 (set-mark (point-min))
;;       (goto-char (point-max))
;;	 (mime/decode-region)
	 (mime/decode-message-header)
	 ))

(setq gnus-Inews-article-hook
      '(lambda ()
	  (mime/encode-message-header)))

(setq rmail-mode-hook
      (list
       (function
	(lambda ()
	  (require 'mime)
	  (substitute-key-definition 'rmail-forward
				     'mime-forward-from-rmail-using-mail
				     (current-local-map))
	  ))))

(setq gnus-mail-forward-method 'mime-forward-from-gnus-using-mail)
(setq gnus-summary-mode-hook
      (list
       (function
	(lambda ()
	  (require 'mime)
	  ))))
----------------------------------------------------------------------

---

From: [email-masked] (守岡知彦 (MORIOKA Tomohiko))
Date: Wed, 20 Oct 1993 21:02:24 GMT

>>>>> <[email-masked]> =?ISO-2022-JP?B?GyRCJEskRiEiGyhC?=
	[email-masked] (Takeshi Kusune) =?ISO-2022-JP?B?GyRCO2FbKSQvISIbKEI=?=

楠根> このメールの内容

楠根>   ・ＭＩＭＥ（ヘッダー）に対応するのは難しい。
楠根>   ・私の使っているＭＩＭＥ対応の為のツールの紹介
楠根>   ・設定の仕方を教えて下さい。
楠根> で、私の場合ですが、

楠根>   ・mime.el （Copyright (C) 1993 Masanobu UMEDA）
楠根>   ・tiny-mime.el （この間ニュースにながれてた）
楠根>   ・mimehead.tar.Z （etlport.etl.go.jpから）
楠根>   ・mm2.6.tar.gz、romime-1.1.shar.gz （bash.cc.keio.ac.jp から）

楠根> というものを持っています。

* MIME 用のコマンド

<[email-masked]> にて、
村上麻里子 <[email-masked]> 氏曰く、

・metamail
	etlport.etl.go.jp: /pub/mime/mm*

 単なるページャのように使います。
 例えば、MHでしたら show | metamail のようにします。
 ヘッダだけでなく、MIMEで規定された他の機能(画像や音声など)
 も一通り全てあつかってます。

・mimehead.tar
	etlport.etl.go.jp:~ftp/pub/mime/mimehead.tar.Z

 電総研の佐藤さんが作った、ニュースのMIMEヘッダー用のnntpdへの
 パッチ及びエンコーダ、デコーダです。toMime/fromMimeというコマンド
 があって、メールのヘッダーのデコーダ、エンコーダにも応用がききます。
 私は、これで簡単なシェルスクリプトを書いて使っていますが、ヘッダーだけ
 であれば、これが一番お手軽なような気がします。

* Emacs Lisp

** Umerin さんの MIME tools

<[email-masked]> にて、
村上麻里子 <[email-masked]> 氏曰く、

・emacs-mime-tools.shar
	 wnoc-fuk.wide.ad.jp:~ftp/pub/GNU/etc/emacs-mime-tools.shar

 umerinさんがニュースで投稿していたものです。
 emasでメールを読み書きしている人のためのツールです。
 MIMEメールコンポーザー、MIME用のrmailツール、
 metamailをemacsで使うツールが入ってます。

*** mime.el

  mmencode を使って MIME message を作る。
  多目的メッセイジを作るための mime-mode がある。
  多目的メッセイジが割合簡単に作れる。

*** metamail.el

  metamail を使って MIME message を再生する。

  多目的メッセイジの再生ができる。

** tiny-mime.el

  MIME header の decoder. ISO-2022-JP, ISO-8859-* の header が復元でき
る。（ただし、NEmacs, NEpoch では、ISO-2022-JP, Base64 のみ）

*** GNUS 3.14.4 + tiny-mime

  GNUS 3.14.4 に tiny-mime-mode と metamail-mode を組み込んだもの。M-t 
で再生モードが切り替わる。

  Summary, mode-line も復元して表示する。日本語文字列を文字の途中でぶっ
た切ったりしないので、mode-line に正しく日本語文字列を表示できる。

*** GNUS 4.1 + tiny-mime

  同じく、GNUS 4.1 に tiny-mime-mode と metamail-mode を組み込んだもの。

*** mh-e 3.8 + tiny-mime

  mh-e 3.8 に tiny-mime-mode と metamail-mode を組み込んだもの。M-t で
再生モードが切り替わる。

** その他

  MH 附属の mh-e 用の MIME message encoder があるみたいです。

* まとめ

  metamail は、是非、インストールしましょう。結構簡単にできます。

  インストールのし易さなら、tiny-mime.el が一番でしょう。+ tiny-mime
patch を使って、metamail も使うと快適です。

  MIME message を書くなら、Umerin さんの mime.el の mime-mode は快適で
す。metamail パッケイジがインストールされていれば、OK です。

  MH-6.8-JP2 をインストールすれば、MH 自体が MIME をサポートします。そ
れが無理なら、metamail を使いましょう。

楠根> これらのツールの機能を使いこなす為の設定の仕方を教えてもらえば嬉しいの
楠根> ですが（多分機能は重複してると思います）。私の使っているリーダーは 
楠根> GNUS ver 13.3と MHE（以下のように書いてある）です。

 >> (setq mh-e-RCS-id "$Header: mh-e.el,v 2.24 88/08/29 12:07:53 larus Exp $")

  GNUS 4.1 か 3.14.4、mh-e 3.8 が入手できるなら、それを入手して、+
tiny-mime patch を当てるのが楽だと思います。

  しかし、この version を使うなら、

楠根> .emacsのうち関係ありそうな部分をつけておきますので、なにか変なことをし
楠根> ているなら指摘して下さい（load-path などはちゃんと設定してあります）。

楠根> では、よろしく。
楠根> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
楠根> 慶應義塾大学環境情報学部環境情報学科１年 楠根 雄志  埼玉県春日部市在住
楠根>            メールアドレス:[email-masked] (湘南藤沢キャンパス)
楠根>                           [email-masked]     (日吉キャンパス)

楠根> ----------------------------------------------------------------------
楠根> (autoload 'mime-mode "mime" "" t)

楠根> ;;
楠根> ;; For mime
楠根> ;;

楠根> ;; (a) To use with mh-e, set up like followings on your .emacs:

楠根> ;; In case of MH-E, you need the following hook definition:

(setq mh-letter-mode-hook
      (list
       (function
        (lambda ()
          (mime/decode-message-header) ; header を decode してくれます。
          (mime-mode)
          (make-local-variable 'mail-header-separator)
          (setq mail-header-separator "--------")))))

楠根> (setq mh-folder-mode-hook
楠根>       '(lambda()
楠根> ;;;;	insert your current settings here
楠根> 	 (require 'romime-mhe)))

  これは要りません。

楠根> (setq mh-compose-mode-hook
楠根>       '(lambda()
楠根> ;;;;	insert your current settings here
楠根> 	 ))

  これも要りません。

楠根> ;; (b) To use with GNUS, set up like followings on your .emacs:

楠根> (setq gnus-Startup-hook ;; On GNUS 3.15 or later, gnus-startup-hook
楠根>       '(lambda ()
楠根> ;;;;	insert your current settings here
楠根> 	 (require 'tiny-mime)
楠根> 	 (require 'romime-gnus)
楠根> 	 ))

  これも要りません。

楠根> (setq gnus-Subject-prepare-hook
楠根>       '(lambda ()
楠根> 	 (mime/decode-message-header)))

  これも要りません。

(setq gnus-Article-prepare-hook '(lambda ()
			       		(require 'tiny-mime)
			       		(mime/decode-message-header)
			       		))

楠根> (setq gnus-Inews-article-hook
楠根>       '(lambda ()
楠根> 	  (mime/encode-message-header)))

  mime-mode を使うなら、要りません。

----------------------------------------------------------------------
  mh-e の場合、良い hook が無いので、いずれにしても patch を当てなけれ
ばなりません。MH 自体で対応すれば別ですが。

---

From: [email-masked] (ZUKERAN shin)
Date: 20 Oct 1993 07:35:53 GMT

ずけらん@沖縄です。

TAKADA Toshihiro / =?ISO-2022-JP?B?GyRCOWJFRElSOTAbKEI=?= ([email-masked]) wrote:
: そうですね。fj.mail.mime を作りませんか？

賛成。

# 今はmh+metamailで読んでいます。
--
ドメイン名が変わりました。
ずけらん/[email-masked]

---

From: [email-masked] (SASABE Tetsuro)
Date: Wed, 20 Oct 1993 11:05:22 GMT

とうだいの笹部です。

In article <[email-masked]>
    [email-masked] (TAKADA Toshihiro / =?ISO-2022-JP?B?GyRCOWJFRElSOTAbKEI=?= ) writes:

 |そうですね。fj.mail.mime を作りませんか？

  気分的にちょっと嫌 :-) です。

 |勿論 MIME 以外にも、8bit thru smtp の有効利用を考えるだとか何だとか、
 |他にも今後出てくる話は色々とあるでしょう。けれども、それはまだ
 |fj.mail で収めきれると思いますし。

  むしろそれらを収容することを目論むのならば賛成するのですが、いかがで
しょうか。

---

From: [email-masked] (Kouhei Mugitani)
Date: Wed, 20 Oct 1993 09:49:50 GMT

>「MIME対応のリーダー等はどこにどんな物が現在存在しているのか?」を

  MIMEについては、佐藤さんもどこかで、書かれていたように海の向こうと
こちらでは、力というか関心の向いてる方向が、偉く違うように思います。

  海の向うは、body,一方、こちらでは、WIDEの一環として、Nifty->Internet
のメールが、サブジェクトが、MIME化されたのに伴い、サブジェクトの
MIME対応が、関心が高いようです。

  読むだけなら、metamail を、使えば、あるていどはなんとかなります。
（対応のソフトは、metamailの附属文書に記述があります。）

  いっぽう、サブジェクトについては、mimehead というものがありますが
これで、いけるやつは、ある程度限りがあります。

  すくなくとも、elm と nn は、もっとも重要なレター選択顔面と
記事選択画面が、今のところ、MIMEには、まったく無力です。(-.-)

--
---------------------------
麦谷 浩平＠シャープ株式会社
bobcat is MIPS RS-3230/risc-os4.52

---

From: [email-masked] (Kenji Rikitake)
Date: 20 Oct 1993 13:22:53 GMT

In article <[email-masked]> [email-masked] (SASAKI-susumu) writes:
 |「MIME対応のリーダー等はどこにどんな物が現在存在しているのか?」を
 |教えていただけないでしょうか?

emacs使わない人はmetamail
emacs使う人はmh-eとかtiny-mime.elとかが
いいんじゃないでしょうか。

// Kenji
--
Kenji Rikitake <[email-masked]> <[email-masked]>    (More available!)
Persuade me you may, but I won't be persuaded.                 -- Aristophanes

---

From: [email-masked] (Akihiko Kuroe)
Date: 21 Oct 93 03:47:51 GMT

黒江＠大日本印刷です。

>  MH-6.8-JP2 をインストールすれば、MH 自体が MIME をサポートします。そ

これなんですけど、メールヘッダだけならOption: MIMEを付けずにmakeしても
サポートしているみたいですね。但し、いろいろ設定しておく必要があります。
以下に設定のサンプルを示します。参考にして下さい。

＃MIMEに関係のない設定なんかも混ざっています。aliasesとかreplcompsとか。

手順1 「=====BEGIN:」と「=====END」にはさまれた部分を、
      「=====BEGIN:」に続く名前のファイル名で書き出します。
      ※この作業は拙作のpunpack.plが支援しています。
        ちょっと前にfj.lang.perlにポストしました。

手順2 「(名前)」の部分を自分の名前に書き換えます。

手順3 その他、自分の環境に合わせてカスタマイズをします。

=====BEGIN: .mh_profile
Draft-Folder: drafts
Editor: vi
Folder-Protect: 700
Msg-Protect: 600
Path: Mail
Signature: (名前)
Unseen-sequence: unseen
lproc: less
moreproc: less
showproc: mhl
automhnproc: mhn
display-coding: ja_JP.euc
file-coding: ja_JP.euc
process-coding: ja_JP.euc
ali: -alias aliases
burst: -verbose
comp: -form forwcomps
forw: -form forwcomps
inc: -form scancomps
mhn: -form mhl.format
repl: -form replcomps -filter replfilter -annotate
scan: -form scancomps
send: -alias aliases -hencode
whom: -alias aliases -hencode
=====END
=====BEGIN: Mail/aliases
; See comments at end of this file
; This file is almost empty as MH now supports personal aliases.
; @(#)$Id: MailAliases,v 1.3 90/04/05 15:40:57 sources Exp $

;everyone: *

; Blank lines and lines beginning with a ; are ignored.
; < file        -> read more aliases from "file"
; foo: fum      -> simple replacement
; foo: fum, fie -> list replacement
; foo: < file   -> list replacement from "file"
; foo: = group  -> list replacement from UNIX group
; foo: + group  -> list replacement by ALL users in /etc/passwd
;                     with gid == group
; foo: *        -> list replacement by ALL users in /etc/passwd
;                     with uid >= 200
; foo*: fum     -> matches foo<string> (including the empty string)
;
; using a ';' instead of a ':' indicates that the alias should be displayed
; along with the addresses used (normally, the addresses replace the alias
; completely)
=====END
=====BEGIN: Mail/forwcomps
To: 
cc: 
Subject: 
Fcc: outbox

(名前)です。
=====END
=====BEGIN: Mail/mhl.format
width=10000,overflowoffset=0,noleftadjust,nocompress
leftadjust,compwidth=9
ignores=received,return-path,path,nntp-posting-host,replied,forwarded
Message-Id:
Newsgroups:
Date:formatfield="%<(nodate{text})%{text}%|%(pretty{text})%>"
From:formatfield="%(hdecode{text})"
To:formatfield="%(hdecode{text})"
cc:formatfield="%(hdecode{text})"
Subject:formatfield="%(hdecode{text})"
extras:nocomponent,formatfield="%(hdecode{text})"
:
body:nocomponent,overflowtext=,overflowoffset=0,noleftadjust
=====END
=====BEGIN: Mail/replcomps
%(lit)%(formataddr(hdecode %<{reply-to}%|%<{from}%|%<{sender}%|¥
%<{return-path}%>%>%>%>))¥
%<(nonnull)%(void(width))%(putaddr To: )¥n%>¥
%(lit)%(formataddr(hdecode{to}))%(formataddr(hdecode{cc}))¥
%<(nonnull)%(void(width))%(putaddr cc: )¥n%>¥
%<{X-Nsubject}X-Nsubject: %{X-Nsubject}¥n%>¥
%<{subject}Subject: Re: %(putstr(hdecode{subject}))¥n%>¥
%<{date}In-reply-to: Your message of "%{date}."¥
%<{message-id}¥n             %{message-id}%>%>
Fcc: outbox

(名前)です。

In message %{message-id}¥n¥t%(hdecode{from})writes:
=====END
=====BEGIN: Mail/replfilter
body:component="> ",overflowtext="> ",overflowoffset=0,width=100
=====END
=====BEGIN: Mail/scancomps
%4(putnumf(msg))%<(cur)+%| %>¥
%<{replied}-%?{encrypted}E%?{content-type}M%| %>¥
%2(putnumf(mon{date}))/%2(putnumf(mday{date}))%<{date} %|*%>¥
%<(mymbox{from})%<{to}To:%14(hdecode(friendly{to}))%>%>¥
%<(zero)%17(hdecode(friendly{from}))%>%<{from} %|*%>¥
%<{subject}%(hdecode{subject}) %|*%>¥
%<{body}<< %(hdecode{body})%>
=====END

詳細はmh-6.8-JP-README.2を読んでみて下さい。
--
黒江明彦＠大日本印刷 画像研究所3部
<[email-masked]>

---

From: [email-masked] (Tetsuo Sakaguchi)
Date: 21 Oct 93 02:23:09 GMT

どうも、阪口＠図情大です。

>  読むだけなら、metamail を、使えば、あるていどはなんとかなります。

そうなんですけど、こないだ mm2.6 をインストールしてみたのですが、
ヘッダの From: とか Subject: はちゃんとやってくれます。
でも、引用した時に、この記事でもあるように In article ... というところに
From: から取り出したフルネームが入るとそれは変換してくれません。
こういったところにまで対応するというのは無理なんでしょうか?
それとも他に良いツールがあるのでしょうか?

--
阪口哲男＠図書館情報大学
Tetsuo Sakaguchi. University of Library and Information Science, JAPAN.

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Thu, 21 Oct 1993 06:33:59 GMT

「Why MIME」関係は週末にゆっくり書かせてください(^_^;)。さて、

On 10/21/93(06:02) [email-masked] (守岡知彦 (MORIOKA Tomohiko)) wrote
in <[email-masked]>

守岡さん、まとめをどうもありがとうございました。ぼくが関係している
metamailとmimehead.tarについて、補足説明させて頂きます。

 |* MIME 用のコマンド
 |
 |<[email-masked]> にて、
 |村上麻里子 <[email-masked]> 氏曰く、
 |
 |・metamail
 |	etlport.etl.go.jp: /pub/mime/mm*
 |
 | 単なるページャのように使います。
 | 例えば、MHでしたら show | metamail のようにします。
 | ヘッダだけでなく、MIMEで規定された他の機能(画像や音声など)
 | も一通り全てあつかってます。

metamail はMIME(RFC1351)の著者であるBELLCOREのNathaniel S. Borenstein
氏が開発したツール(user agent)です。規格の作成と並行して、その検証の
役割を兼ねて作られたと言っても良いでしょう。

metamail の特徴は、"mailcap"(RFC1343)というConfigurationファイルを使っ
て利用者の環境に応じたカスタマイズができたり、既存の色んなツールに容易
に外付けしてMIME機能を提供できるように作られているところです。

viewerの本体であるmetamail、composerの本体であるmailtoを中心として、
MIMEの個々のデータ型に対するviewerやcomposerのコマンド群（ほとんど
shellスクリプトで書かれています）からなります。MHのノリに近いですね。
BASE64/QUOTED-PRINTABLEエンコーダや、richtext処理系なども含め、metamail
とは独立に単体で使えるコマンド群を多く含んでいます。
＃実際ぼくのニュース＆メイルリーダも、mailcapと部品コマンド群(だけ)を
＃使って、MIME対応化しています。

metamail の現在の版は mm2.6(93年7月版)で、配布セットは本体のmm2.6.tar
と、contributeされた関連ソフト contrib2.6.tar からなります。contribの
中には、AmigaやMS-DOS上で動くmetamailのサブセット、MIMEメッセージでお
返事をくれるlist/archive server(ServiceMail。Tclで書かれています)など
が含まれています。

なお、同じくN.S.Borenstein氏が収集したMIMEのサンプルメッセージ(60件ほど)
が、上述のディレクトリの下の samples.tar.gz にあります。

・ucb/mail
	etlport.etl.go.jp:‾ftp/pub/mime/tahoe.tar.Z

フリーのucb/mailに、N.S.Borensteinがmetamailを組み込んだものです。

 |・mimehead.tar
 |	etlport.etl.go.jp:‾ftp/pub/mime/mimehead.tar.Z
 |
 | 電総研の佐藤さんが作った、ニュースのMIMEヘッダー用のnntpdへの
 | パッチ及びエンコーダ、デコーダです。toMime/fromMimeというコマンド
 | があって、メールのヘッダーのデコーダ、エンコーダにも応用がききます。
 | 私は、これで簡単なシェルスクリプトを書いて使っていますが、ヘッダーだけ
 | であれば、これが一番お手軽なような気がします。

これは実際には、metamailのcontribに置いてある「MMS:metamail server」
（metamail にクライアント／サーバ風インターフェイスを付けたもの）
の中から、RFC1522(ヘッダのエンコーディング)に関する部分を抜き出した
ものです。mm2.6/contrib2.6に含まれるものは旧いRFC1342対応ですが、
mimehead.tarのは1522に対応しています。以下のような使い方ができます。

　・フィルタコマンドとして (toMime/fromMime)
    　標準入力をMIMEエンコード／デコードして標準出力に出すプログラム
　　　テキストエディタの中から「バッファ内容をフィルタに通してバッファ
　　　に戻す」とか、ページャの前段やポスターの後段にかませて使えます。

　・エンコード／デコード関数ライブラリとして (libmms.a)
　　　与えられたファイルや文字列を、エンコード／デコードして、ファ
　　　イルや文字列に書き出す関数群。

　・nntpdへのパッチとして
　　　上述の関数をnntpdに組み込んで、MIMEのエンコード／デコードを
　　　自動的に行うようにするパッチです。ニュースリーダとnntpdは、
　　　ローカルコード（日本語: ISO-2022-JP）を含んだヘッダをやりとり
　　　します(HEAD,ARTICLE,POSTコマンド)。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Thu, 21 Oct 1993 20:23:39 GMT

>>>>> <[email-masked]> にて、
	[email-masked] (Tetsuo Sakaguchi) 氏曰く、

阪口> In article <[email-masked]>
>  読むだけなら、metamail を、使えば、あるていどはなんとかなります。

阪口> そうなんですけど、こないだ mm2.6 をインストールしてみたのですが、
阪口> ヘッダの From: とか Subject: はちゃんとやってくれます。
阪口> でも、引用した時に、この記事でもあるように In article ... というところに
阪口> From: から取り出したフルネームが入るとそれは変換してくれません。
阪口> こういったところにまで対応するというのは無理なんでしょうか?
阪口> それとも他に良いツールがあるのでしょうか?

  GNUS だったら news-reply-mode-hook に header の decoder を入れておけ
ば、ちゃんとやってくると思います。他の mailer/news reader の場合でも同
様です。

＃ 日本版、MIME FAQ なんかがあるといいかも知れませんね。そのためにも、
＃ fj.mail.mime ができたら良いな。

---

From: [email-masked] (Akihiko Kuroe)
Date: 22 Oct 93 03:09:39 GMT

黒江＠大日本印刷です。

>こういったところにまで対応するというのは無理なんでしょうか?

MH-6.8-JP2で、replcompsとかの設定を利用すればできました。
記事<[email-masked]>が参考になるかと思います。
＃手前味噌ですが...(^^;;
--
黒江明彦＠大日本印刷 画像研究所3部
<[email-masked]>

---

From: [email-masked] (Masataka Ohta)
Date: 22 Oct 93 09:13:45 GMT

>ても対応していないサイトでは読め無いという点で大きな違いは無いと思うの

　やれやれ。

　８２１／８２２のままで、ＩＳＯ−２０２２−ＪＰを含めて７ｂｉｔのＩＳＯ
２０２２は全部通るから、それで国際化は問題なかったと思いますが？

　ＥＢＣＤＩＣでも使うとか、ＢＩＴＮＥＴで似非８２２使ってる邪悪な地域で
は７ｂｉｔがちゃんと通らないとかいう後ろ向きの発想を無視すれば。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 22 Oct 1993 10:02:23 GMT

On 10/22/93(18:13) [email-masked] (Masataka Ohta) wrote
in <[email-masked]> (fj.mail:2201/etlss2):
 |> |それは、あるべき姿かもしれません。けれどおそらくそのように、従来のイ
 |> |ンターネットメイル規格(RFC821,822)と互換性を保って拡張するのは、困難
 |> |ではないでしょうか？
 |>
 |>  私も浜田さんと同じ考え方をしています。
 |>
 |>  確かに 822 を維持したままの拡張は私には思い付きません。が、どうせな
 |>らば 821/822 の方を放棄するという選択肢だってあったはずです。MIME にし
 |>ても対応していないサイトでは読め無いという点で大きな違いは無いと思うの
 |>ですが。
 |
 |　やれやれ。
 |
 |　８２１／８２２のままで、ＩＳＯ−２０２２−ＪＰを含めて７ｂｉｔのＩＳＯ
 |２０２２は全部通るから、それで国際化は問題なかったと思いますが？

あ、太田さんだ…

 |　ＥＢＣＤＩＣでも使うとか、ＢＩＴＮＥＴで似非８２２使ってる邪悪な地域で
 |は７ｂｉｔがちゃんと通らないとかいう後ろ向きの発想を無視すれば。

笹部さんもぼくも、アドレスフィールドでの使用を問題にしています。

To: [email-masked] (太田　昌孝),
    [email-masked] (Yutaka Sato 佐藤豊),
    笹部 哲郎（ささべ てつろう） <tss.a.u-tokyo.ac.jp>

のように書きたいというのは、後ろ向きの発想でしょうか？

ISO-2022を「素通し」するには、すべてのmail transfer agentにISO-2022
の全ての制御コードをパースする能力を持っていてもらう必要があると思う
のですが。。。

　　　　　　　　　　　　　　　　 @ @
┰── ─┰─ ┰　　  ／／＼^^　( - )  {まさか似せもーたじゃないだろな}
┠─++佐藤＠ＥＴＬ　／　876m＼ _<   >_　　　　　　　　　　　　..
┸── 　┸　 ┸────────────────────── (- @)∋ ──┘

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Thu, 21 Oct 1993 03:18:33 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 海の向うは、body (Re: header ni MIME .....)

  NTTの川上です。個人的な、感想です。

  "fj.mail"の"Re: header ni MIME wo , no zakkan (Re: Why MIME ?)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> のメールが、サブジェクトが、MIME化されたのに伴い、サブジェクトの
``海の向こう''の方(MIME in body)がMIMEの真価が発揮できる
使い方のような気がします。
					wataru
# みなさんは、いかがでしょうか。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Thu, 21 Oct 1993 03:14:31 GMT

### Japanese subject will be read as below: ###
X-Nsubject: elm の レター 選択画面. (Re: header ni MIME wo.....)

 NTTの川上です。

  >> 記事選択画面が、今のところ、MIMEには、まったく無力です。(-.-)
単に、SubjectのMIME(JIS-code + ``=?ISO-2022-JP?B?'')を
読むのであれば、先日投稿した、mime2xnを~/.forwardに入れ
てしまえば、メール到着時にX-N*に変換されますので、内容は、
X-N*対応のelmなら、レター選択画面で読めます。(mime2xnは、
複数行にまたがるheaderには、まだ対応していませんが。。)

					wataru

# elmのX-Nfrom対応をしなくっちゃ。でも、漢字で名前を
# 見たいという気持ちが高まらなくて。。。
# mime2xnの複数行対応が先かな。。。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 22 Oct 1993 11:43:05 GMT

On 10/20/93(04:26) [email-masked] (TAKADA Toshihiro / 高田敏弘) wrote
in <[email-masked]> (fj.mail:2185/etlss2):
 |こんにちは、たかだ＠NTTです。
 |
 |"Why MIME ?" について書きたいこともあるのですが、とりあえずこれ...
 |
 |In article <[email-masked]>
 |	[email-masked] writes:
 |>   [email-masked]。こういう話題ってあんまりいいNGがないな。
 |>そうですね。 fm.mail.mime?
 |
 |そうですね。fj.mail.mime を作りませんか？

賛成です。comp.mail の方も

comp.mail
comp.mail.elm
comp.mail.headers
comp.mail.maps
comp.mail.mh
comp.mail.misc
comp.mail.multi-media
comp.mail.mush
comp.mail.sendmail
comp.mail.uucp
comp.mail.mime

のように構造化されていますし、fj.mail もこの機会に同様な分離をやっても
良いと思います。とりあえずは、fj.mail.mime だけで足りるとは思いますが…

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Fri, 22 Oct 1993 15:32:12 GMT

以下の記事を fj.mail にポストしたのですが、さる方から「fj.news.groupに
ポストしたほうが良い」という指示を受けましたので、fj.news.group.net に
(クロス)ポストします。

元はMIME関連のニュースグループ(現在、"fj.mail.mime"が提案されています)
の作成の呼びかけなのですが、fj.mailの分割にも話が及んでいます。

On 10/22/93(20:43) I wrote
in <[email-masked]> (fj.mail:2208/etlss2):
 |On 10/20/93(04:26) [email-masked] (TAKADA Toshihiro / 高田敏弘) wrote
 |in <[email-masked]> (fj.mail:2185/etlss2):
 | |こんにちは、たかだ＠NTTです。
 | |
 | |"Why MIME ?" について書きたいこともあるのですが、とりあえずこれ...
 | |
 | |In article <[email-masked]>
 | |	[email-masked] writes:
 | |>   [email-masked]。こういう話題ってあんまりいいNGがないな。
 | |>そうですね。 fm.mail.mime?
 | |
 | |そうですね。fj.mail.mime を作りませんか？
 |
 |賛成です。comp.mail の方も
 |
 |comp.mail
 |comp.mail.elm
 |comp.mail.headers
 |comp.mail.maps
 |comp.mail.mh
 |comp.mail.misc
 |comp.mail.multi-media
 |comp.mail.mush
 |comp.mail.sendmail
 |comp.mail.uucp
 |comp.mail.mime
 |
 |のように構造化されていますし、fj.mail もこの機会に同様な分離をやっても
 |良いと思います。とりあえずは、fj.mail.mime だけで足りるとは思いますが…

自分で言い出しておいてなんですが、ぼくは MIME 関連のニュースグループ
の早急な作成を望んででいますので、fj.mail 分割の全般的な話がすんなり
進まないようでしたら、"fj.mail.mime"(にこだわりません。fj.net.mimeな
どの案もあるようです)の作成に絞って検討していただけると幸いです。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (enami tsugutomo)
Date: 22 Oct 93 00:36:23 GMT

In article <[email-masked]>,
	[email-masked] (守岡知彦 (MORIOKA Tomohiko)) writes:

>   mh-e の場合, 良い hook が無いので, いずれにしても patch を当てなけれ
> ばなりません.  MH 自体で対応すれば別ですが.

	僕はなるべく original の file を変更したくないので, 以下のよう
	にして hook を作って使っています.  この定義自体は .emacs とは
	別の file にして, mh-inc-folder-hook で require しています.

;;;
(defvar mh-show-function nil
  "*Called from mh-show with current FOLDER & MESSAGE")

;(fmakunbound 'si:mh-display-msg)
(or (fboundp 'si:mh-display-msg)
    (fset 'si:mh-display-msg (symbol-function 'mh-display-msg)) )

(defun mh-display-msg (msg-num folder)
  (si:mh-display-msg msg-num folder)
  (and mh-show-function
       (funcall mh-show-function folder msg-num) ))

えなみ つぐとも

---

From: [email-masked] (Shiino Masayoshi)
Date: 22 Oct 93 14:21:07 GMT

茶々になってしまうかも知れませんが、

>    笹部 哲郎（ささべ てつろう） <tss.a.u-tokyo.ac.jp>

To: [email-masked] (太田　昌孝),
    [email-masked] (Yutaka Sato 佐藤豊),
    笹部 哲郎（ささべ てつろう） <時分割.ノー.頭狂大.ガッコ.日本>

じゃあないんですか？
-- 
				椎野正元　（しいの　まさよし）

---

From: [email-masked] (Shinji Kono)
Date: Sat, 23 Oct 1993 01:32:11 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Shiino Masayoshi) writes 
>To: [email-masked] (太田　昌孝),

ぼくもそう思うな。

MIMEが悪いんじゃなくて、MIMEを入れる場所が悪い。きっと、sendmail/BINDレ
ベルで日本語アドレスとinternational addressの変換をおこなうんですよね。
今の方法じゃ「To:」とか「address」とか書いてある場所に「日本語」が入っち
ゃう分けでしょう？  やっぱりまずいよ。例えば、To:にxfacesとか入っていた
らどうです？  同じことをやっているわけですよね。

bodyに入れる分には文句はないんだけど。
---

---

From: [email-masked] (Wataru KawaKami)
Date: Fri, 22 Oct 1993 12:21:43 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 宛名 (was Re: Why MIME ?)

 NTTの川上です。メールの宛名についての雑感です。

 "fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、[email-masked]、
  >> のように書きたいというのは、後ろ向きの発想でしょうか？
後向きか否かは、私は、"To:"は、いつも、alias(address)を書いて
elmに展開させており、それで、特に不便を感じないので、よく
わかりませんが。。。

  単に、User Interfaceとして、"To:..."というように宛名が
見えて欲しいということであれば、特に、宛名を見えるまま、
"To:"フィールドにいれることに拘る必要はないと思っています。

					wataru

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Sat, 23 Oct 1993 08:37:42 GMT

On 10/22/93(23:21) [email-masked] (Shiino Masayoshi) wrote
in <[email-masked]> (fj.mail:2213/etlss2):
 |To: [email-masked] (太田　昌孝),
 |    [email-masked] (Yutaka Sato 佐藤豊),
 |    笹部 哲郎（ささべ てつろう） <時分割.ノー.頭狂大.ガッコ.日本>
 |
 |じゃあないんですか？

i-headers ML でも言いましたが、MIMEで日本語のアドレスを、って
いうのは、実際私も期待していました。ietf-822 でもそのような議
論があったようです。

結論としてそれに否定的なことになったのは、次のような理由だった
と記憶しています。
・日本語を知らない人に、あなたのアドレスをどう教えるか？
・外国人のアドレスを聞くときに、英文字以外で理解できるか？
・多様な文字セットのアドレスをルーティングするのは大変
・同じアドレスに２種類以上の表記方法があると管理が大変

ドメインアドレスはメイル／ニュース以外でも広く使われているので、
RFC821/822の拡張というスコープの中でこれを議論するのを避けたと
言うこともあるのかも知れません。
また、Unixなどでのログイン名などは一般にはローマ字でありそれを
好む人が多い現状では、ユーザ名の日本語化もそう簡単でないと思い
ます。

さて、それでもどうしても使いたい場合ですが。実は使えないわけで
はなかったりします。実際、アドレス

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

すなわち、

  <[email-masked]>

は生きています。=?ISO-2022-JP?B?GyRAOjRGI0stGyhK?= -> ysato
という alias が登録してあるからです。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (TAKADA Toshihiro / 高田敏弘 )
Date: 21 Oct 1993 12:07:28 GMT

こんにちは、高田です。

>    [email-masked] (TAKADA Toshihiro / =?ISO-2022-JP?B?GyRCOWJFRElSOTAbKEI=?= ) writes:
                                                    ↑ここら辺がですか?
じゃなくて... (^_^;

>  むしろそれらを収容することを目論むのならば賛成するのですが、いかがで

こういった方向(例えば fj.mail.ext ?)も考えなくもないのですが、以下の
２点で余り賛成できないのです。

・MIME と(例えば) 8bit thru の話は直交する概念である。

(8ビット環境で MIME を使うこともできますし(これだと今のような見苦しい
 base64 encoding しないで済むかも？)、MIME を捨てて8ビットで突っ走る
 という方向もあるという意味です。)

・有効利用云々の話は将来に向かっての話であるのに対して、MIME の話題は
  現状の話(これこれで使えますか? とか 設定の仕方とか)が多くなるであろ
  うと思われる。

特に後者の、夢と現状の泥々を同じ場所に置く、というのは好ましくないと
思うのですが、どう思われますか？

＃ 勿論 MIME に将来の夢がない訳ではありません。(^_^;
========================================================================
ＮＴＴ基礎研究所 情報科学研究部                                 高田敏弘
分散コンピューティング原理研究グループ              [email-masked]
========================================================================

---

From: [email-masked] (Takanari HAYAMA)
Date: 24 Oct 93 06:43:39 GMT

端山＠筑波大です。

  研究しているテーマ上、MIMEに対して興味を覚えている
ものです。

  最近のMIME関係の議論を見ていると、MIMEに反対してい
る方々は、何か忘れていることがあるように思えます。そ
こで、以下のようにまとめてみました。皆さんがよく知っ
ている事実をまとめただけなので、trivialな内容だと思
います。body部分については、ほとんどの方が賛成されて
いる様なので、header部分について。

〜〜〜

１．8bit thruにすれば、全て問題がないという主張につ
いて。

  実際に、Internetで8bit thruにするためには、現状で
は、非常に高いコストがあります。
  Internetの計算機が全て、オープンにIP接続しているの
であれば、8bitを扱いたいサイトだけsendmailなどを変更
すればいいかもしれません。しかし、現実には、UUCP接続
している所など、幾つかのサイトを経由しないとメールや
ニュースが届きません。特にニュースにおいて、8bitで投
稿された記事は、まずまともに届きません。
  結局、単点と単点を結ぶ間のサイトをすべて変更する必
要が生じるわけです。「自分が8bitを使いたいから、シス
テムを8bit thruに置き換えろ」なんて主張は、今の環境
では非現実的ですよね。

２．じゃあ、エスケープが通ればいいじゃないか、という
主張について。

  殆んどのサイトのFrom:やTo:のパーザは、1byte単位で
パージングしていますよね。そうするとISO-2022の様な、
複雑なものをサポートさせるように、中継点を含むシステ
ムの全パーザを変更する必要があると思います。
  例えば、「端山貴也」をASCII文字列としてみた場合、
「esc $@C<;35.Li esc (J」となるわけですよね。「@」と
か「(」は、エスケープに対応していないサイトでは、誤
動作の原因になると思います。
  この辺も、１と同様コストが高過ぎるので、非現実的
です。

〜〜〜

  MIMEはウザッタイから嫌いとおっしゃっている方々の気
持ちもわかります。しかし、ヘッダに日本語を使う際、現
実的に利用者に透明にでき、かつ、それに対応していない
サイトでの誤動作を招かないような方法は、今の所MIMEし
かないともいます。

＃「利用者に透明だ」とはいっていません。「利用者に透
＃明にできる」といっています。
    ^^^^^^^^
  MIMEは、RFC821/822に沿ったシステムを使っている所で
あれば、必ず問題なく通ります。ヘッダに対して日本語を
使ったりしたい利用者やサイトだけが、自己の判断の元に
選択してMIMEを導入することができます。現状では、読み
たくない人は、復号化しないで放っておけばいいと思いま
すし、使いたくない人は、従来通り、ヘッダにはASCII文
字セットで、人間が直接判別できるようにすればいい訳で
す。どちらかを押しつけるというのは、やってはいけない
ことだと思います。

  どちらにしろ、将来的にMIMEヘッダについては、メール
・サーバやニュース・サーバがスプールに書き込む時に、
復号化して、外に出す時に符号化するようになると思いま
す。こうなれば、ヘッダに関しては伝送手段を定義してい
るだけであると取れますから、利用者には透明で、いかに
も8bit thruになったように見えます。しかも、非常に安
いコストでです。対応できるサイトから、少しずつ変更し
ていけばいいという点では、ほぼ一斉に変更する必要のあ
る、8bit thruやescape thruよりも現実的だと思います。

  将来、Internetのtopologyが変われば、8bit thruやEscape
thruyも現実的になるやも知れません。全てがオープンに
IP接続できれば。もっとも、その時でも、コードを示すコ
ントロールがヘッダに定義される必要があると思います。

  僕は、日本語と英語とドイツ語を読みますから、それぞ
れの言語が読み書きできる環境が欲しいですからね。ドイ
ツ語なのに、知らない内にSJISとして変換されていたらた
まりません。また、インド人の友達がいますから、彼の名
前をインド語のフォントで読めれば素敵だと思います。ま
た、自分の名前を

From: 端山貴也--Takanari HAYAMA <[email-masked]>

と書けたら嬉しいですね。外国の友達にメールを出そうと
した時、その国の言葉を少しでも知っていたら、それをヘ
ッダに埋め込めることができたらいいと感じています。

  残念ながら、今の所そのための現実的な手段がMIMEしか
ないんですよね。今の現状に沿ったいい方法が、他にあれ
ばいいのですが。もっとも、僕は、MIMEが充分すっきりし
ていると思います。
--
z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z
筑波大学 電子・工学系 ＯＳ情報ベースシステム研究室 
			 端山貴也(Takanari HAYAMA)
z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z

---

From: [email-masked] (SASABE Tetsuro)
Date: Sun, 24 Oct 1993 10:13:27 GMT

In article <[email-masked]>
    [email-masked] (Masataka Ohta) writes:

  あきれる前に文脈を読んで下さいね。

  その通りです。

  だのに何で MIME を使わにゃならん、という文句から始まっているのです。

  ただし、ヘッダについては ISO-2022-JP を使うとアドレスとの区別が付き
にくい(ここでは付かないとの断言は避けますが)、しゃーないから 8bit 目も
通そうかい、という話をしているのですが。

---

From: [email-masked] (Naoki HAMADA)
Date: 24 Oct 1993 07:46:37 GMT

>る方々は、何か忘れていることがあるように思えます。

  MIME に反対だ、と表明した人がいるのですか？わたしを含めて「MIME が嫌
いだ」と表明した人はいましたが。

浜田 直樹

---

From: [email-masked] (Shinji Kono)
Date: Sun, 24 Oct 1993 14:00:20 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Takanari HAYAMA,[OS],,) writes 
>複雑なものをサポートさせるように、中継点を含むシステ

僕はGCOS fieldみたいな、meaningful ASCIIの場所に、dismeningful ASCII
をいれることがおかしいと思うだけです。FromやToは英語としての意味を
期待されているはずです。filedを変えればパーザなど必要なくてただcopy
するだけでしょう。今は7bitのISO-2022を通そうという話なわけですから。

8bit thruで、SJISもEUCも許そうという話なら僕だって反対です。しかも、
MIMEは、まさにそういう発想です。なんでもかんでも通れば便利という
ものではないでしょ。

>ばいいのですが。もっとも、僕は、MIMEが充分すっきりし

Mail Boxのdatabaseとしての性質が悪くなるのはいやです。
---
Shinji Kono @           [email-masked]
河野真治 Sony Computer Science Laboratory, Inc,Japan

---

From: [email-masked] (SASABE Tetsuro)
Date: Sun, 24 Oct 1993 16:30:12 GMT

とうだいの笹部です。

In article <[email-masked]>
    [email-masked] (Takanari HAYAMA) writes:

 |        body部分については、ほとんどの方が賛成されて
 |いる様なので、header部分について。

  body 部なんて議論は最初から無かったと思うのですが？

  body 部の、非 ASCII 言語のための MIME なんて馬鹿なこと…。mohta さん
じゃないけど、今でも透過しているものをどうしてややっこしくする必要があ
るんです？

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Mon, 25 Oct 1993 07:11:34 GMT

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

笹部> In article <[email-masked]>
笹部>     [email-masked] (Takanari HAYAMA) writes:

笹部>  |        body部分については、ほとんどの方が賛成されて
笹部>  |いる様なので、header部分について。

笹部>   body 部なんて議論は最初から無かったと思うのですが？

笹部>   body 部の、非 ASCII 言語のための MIME なんて馬鹿なこと…。mohta さん
笹部> じゃないけど、今でも透過しているものをどうしてややっこしくする必要があ
笹部> るんです？

  ？

  例えば、
わざわざエンコードした plain text.

みたいなことを想像されているんですか？

  body 部に MIME を使うというのは、
\documentstyle[a4j,12pt]{jarticle}

\begin{document}

MIME によって、構造化することによって、mail/news の message で、いろい
ろな data を扱えるようになります。

また、そうした data の処理を自動化できます。

そうした data には、文や絵や音や動画のような情報だけでなく、ftp をする
といった「処理」も含まれます。

\end{document}

みたいに、例えば、LaTeX の file を送る時、「これは LaTeX の file だよ」
と宣言しておけば、受け手は「LaTeX の file が来たら、compile して 
preview する」と決めておけば、自動的にそう処理するような、多目的
message を利用しようということではないのですか？

---

From: [email-masked] (Takanari HAYAMA)
Date: 25 Oct 93 00:03:24 GMT

On 10/24/93(23:00) [email-masked] (Shinji Kono) wrote
in <[email-masked]> (fj.mail:1542/maple):
 |>  殆んどのサイトのFrom:やTo:のパーザは、1byte単位で
 |>パージングしていますよね。そうするとISO-2022の様な、
 |>複雑なものをサポートさせるように、中継点を含むシステ
 |>ムの全パーザを変更する必要があると思います。
 |
 |僕はGCOS fieldみたいな、meaningful ASCIIの場所に、dismeningful ASCII
 |をいれることがおかしいと思うだけです。FromやToは英語としての意味を
 |期待されているはずです。filedを変えればパーザなど必要なくてただcopy
 |するだけでしょう。今は7bitのISO-2022を通そうという話なわけですから。

  将来、MIMEの符号化および復号化が透明に行なわれれば、
結果として、meaningful ASCIIに捕らわれないmeaningful
TEXTを入れることができます。

 |8bit thruで、SJISもEUCも許そうという話なら僕だって反対です。しかも、
 |MIMEは、まさにそういう発想です。なんでもかんでも通れば便利という
 |ものではないでしょ。

  メール・サーバやニュース・サーバから見れば、ただの
7bitのTEXTを流しているに過ぎません。最終的にそれを受
けとったユーザに取って、それが8bitになってもです。

  中間点では、今の所7bitで送られることが、今のMIMEで
は保証しています。

 |>ばいいのですが。もっとも、僕は、MIMEが充分すっきりし
 |>ていると思います。
 |
 |Mail Boxのdatabaseとしての性質が悪くなるのはいやです。

  Mail Boxに入る時に、変換されていれば問題ないのはな
いでしょうか？
--
z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z
筑波大学 電子・工学系 ＯＳ情報ベースシステム研究室 
			 端山貴也(Takanari HAYAMA)
z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z-z

---

From: [email-masked] (Takanari HAYAMA)
Date: 25 Oct 93 01:03:08 GMT

端山＠筑波大です。

On 10/25/93(01:30) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]> (fj.mail:1544/maple):
 | |        body部分については、ほとんどの方が賛成されて
 | |いる様なので、header部分について。
 |
 |  body 部なんて議論は最初から無かったと思うのですが？
 |
 |  body 部の、非 ASCII 言語のための MIME なんて馬鹿なこと…。mohta さん
 |じゃないけど、今でも透過しているものをどうしてややっこしくする必要があ
 |るんです？

  MIMEは、非ASCII言語の為のbodyの規約を定義している
わけではないでしょう。僕だって、そんなことを一言も
いってません。

  それはともかくとして、MIMEでbody部については、non-
flatテキストなどを入れる方法が定義されているだけだ
と思います。

---

From: [email-masked] (Tetsuo Sakaguchi)
Date: 25 Oct 93 00:29:12 GMT

早速のフォローありがとうございます。
といいたいのですが、若干誤解があったようで。(私の表現も誤解しやすかった
のかもしれませんが。)

>MH-6.8-JP2で、replcompsとかの設定を利用すればできました。

これらは、自分はフォロー/リプライを出す時に MIME-decode して、
In-article とかにフルネームを入れるという話しですよね?
私が知りたかったのは、MIME-encode されたフルネームが In-article 云々に
すでに入っている記事を読む際に decode できないかということです。
例えば、この記事の [email-masked] さんの記事の引用部が
それに該当します。
--
阪口哲男＠図書館情報大学
Tetsuo Sakaguchi. University of Library and Information Science, JAPAN.

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Mon, 25 Oct 1993 17:58:46 GMT

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

阪口> これらは、自分はフォロー/リプライを出す時に MIME-decode して、
阪口> In-article とかにフルネームを入れるという話しですよね?
阪口> 私が知りたかったのは、MIME-encode されたフルネームが In-article 云々に
阪口> すでに入っている記事を読む際に decode できないかということです。
阪口> 例えば、この記事の [email-masked] さんの記事の引用部が
阪口> それに該当します。

  えっと、こういう場合、tiny-mime.el やその本家筋に当たる mime-kit.el 
の mime/decode-region 関数を使って、decode したい region を decode す
れば OK です。例えば、

阪口> In article <[email-masked]> [email-masked] (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= (MORIOKA Tomohiko)) writes:

の場合、行頭で C-SPACE を押し、行末で M-x mime/decode-region を押せば、

阪口> In article <[email-masked]> [email-masked] (守岡 知彦 (MORIOKA Tomohiko)) writes:

と decode されます。

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Mon, 25 Oct 1993 04:50:23 GMT

On 10/26/93(02:58) [email-masked] (守岡 知彦 (MORIOKA Tomohiko)) wrote
in <[email-masked]> (fj.mail/ripspost:642/etlss2):
 |>>>>> <[email-masked]> にて、
 |	[email-masked] (Tetsuo Sakaguchi) 氏曰く、
...
 |阪口> 私が知りたかったのは、MIME-encode されたフルネームが In-article 云々に
 |阪口> すでに入っている記事を読む際に decode できないかということです。
...
 |  えっと、こういう場合、tiny-mime.el やその本家筋に当たる mime-kit.el 
 |の mime/decode-region 関数を使って、decode したい region を decode す
 |れば OK です。例えば、

(日本語化)ｖｉを使用している私たちは、

	!!fromMime	とか
	1G!GfromMime

などを愛用致しております(^_^)

　　　　　　　　　　　　　　　　 @ @
★ｏｎｅｗ-２.１ 近日発売予定★

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Mon, 25 Oct 1993 02:01:56 GMT

### Japanese subject will be read as below: ###
X-Nsubject: bodyにmime (was Re: About MIME.)

  NTTの川上です。やはり、MIMEは、

  "fj.mail"の"Re: About MIME."について
    (記事<[email-masked]>)、
    [email-masked]、
  >>   body 部に MIME を使うというのは、
  ....
  >> message を利用しようということではないのですか？
のように、bodyにMIMEを入れて、contents-typeなどによって、
applicationと連係させて、``多目的message''を機能させることの
方が、`To:', `From:'など、mailer/news-systemが解釈すべき
headerに入れることに執着することより、はるかにmeaningfulで
あると私は思います。
						wataru

# やっぱり、mimeは、bodyに使ってこそ、その真価を発揮する、と思う。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Masataka Ohta)
Date: 25 Oct 93 09:38:32 GMT

> |>ても対応していないサイトでは読め無いという点で大きな違いは無いと思うの

　べつに文脈なんか読まなくても（読んだけど）ここで議論ごっこしてるような
連中にろくなのいないということを再確認したかっただけ。

>にくい(ここでは付かないとの断言は避けますが)、

　つくんだよ。

　規格屋の自己満足を舶来だからってありがたがるんなら、せめて内容くらい読
んどけばいいのに。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (SASABE Tetsuro)
Date: Mon, 25 Oct 1993 10:39:36 GMT

In article <[email-masked]>
    [email-masked] (Masataka Ohta) writes:

 |　べつに文脈なんか読まなくても（読んだけど）ここで議論ごっこしてるような
 |連中にろくなのいないということを再確認したかっただけ。

   はて？

 |>  ただし、ヘッダについては ISO-2022-JP を使うとアドレスとの区別が付き
 |>にくい(ここでは付かないとの断言は避けますが)、
 |
 |　つくんだよ。

  付きますよ。だから断言してないじゃない。
  区別が出来ない MTA や UA が多い事実に従ってものを言っただけ。

 |　規格屋の自己満足を舶来だからってありがたがるんなら、せめて内容くらい読
 |んどけばいいのに。

  私はありがたがってないってば。嫌だと言ってるんだって。

# 全然読んでないのね、結局。

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Mon, 25 Oct 1993 11:41:35 GMT

On 10/25/93(19:39) [email-masked] (SASABE Tetsuro) wrote
in <[email-masked]> (fj.mail:2239/etlss2):
 | |　規格屋の自己満足を舶来だからってありがたがるんなら、せめて内容くらい読
 | |んどけばいいのに。
 |
 |  私はありがたがってないってば。嫌だと言ってるんだって。

インターネット規格を舶来だと思うのは変だと思います。規格作成の
ワーキンググループ(IETF:Internet Engineering Task Force)には誰
でも参加できるし、議事録も公開されています。IETFの議論の殆んど
はメイリングリストで行われているので、日本に住んでいても特に
ハンディキャップはないでしょう。もちろん、その結果としてのRFC
は配布自由で、いろんなところから入手できます。

[RFC1310]
>     Any member of the Internet community with the time and interest is
>     urged to attend IETF meetings and to participate actively in one
>     or more IETF Working Groups.  Participation is by individual
>     technical contributors, rather than formal representatives of
>     organizations.  The process works because the IETF Working Groups
>     display a spirit of cooperation as well as a high degree of
>     technical maturity; most IETF members agree that the greatest
>     benefit for all members of the Internet community results from
>     cooperative development of technically superior protocols and
>     services.
...
>     The procedures described in this document are intended to provide
>     a clear, open, and objective basis for developing, evaluating, and
>     adopting Internet Standards for protocols and services.  The
>     procedures provide ample opportunity for participation and comment
>     by all interested parties.  Before an Internet Standard is
>     adopted, it is repeatedly discussed (and perhaps debated) in open
>     open meetings and/or public electronic mailing lists, and it is
>     available for review via world-wide on-line directories.

インターネット規格に対して不満を言うには、IETFに参加して発言す
るのが効果的です。また、それ以外の場所で何か言っても、インター
ネット規格を動かすのは難しいでしょう。

　　　　　　　　　　　　　　　　 @ @
┰── ─┰─ ┰　　  ／／＼^^　( - )  {ルール、インターネット標準です}
┠─++佐藤＠ＥＴＬ　／　876m＼ _<   >_　　　　　　　　　　　　..
┸── 　┸　 ┸────────────────────── (- @)∋ ──┘
★MIMEエンコーダ/デコーダ発売中★etlport.etl.go.jp:pub/mime/mimehead.tar.Z

---

From: [email-masked] (enami tsugutomo)
Date: 25 Oct 93 13:05:49 GMT

以下の部分はちょっとあいまいに(僕には)思えるので確認させてください.
	引用が長くて申しわけありません.

In article <[email-masked]>,
	[email-masked] (SASABE Tetsuro) writes:

>  | 821/822のままで, ISO-2022-JPを含めて7bitのISO 2022は全部通るから, 
>  |それで国際化は問題なかったと思いますが?
> 
>   その通りです.

	(中略)

>   ただし, ヘッダについては ISO-2022-JP を使うとアドレスとの区別が付
> きにくい(ここでは付かないとの断言は避けますが), しゃーないから 8bit 
> 目も通そうかい, という話をしているのですが.

	RFC 822でいう body と unstructured field body (Subject: 等)に
	は 7bit の ISO 2022が通せるが, structured field body (To:
	From:等)には通せない, しかしそこにも ASCII以外の文字(集合?)を
	使いたい, ということでしょうか?

えなみ つぐとも

---

From: [email-masked] (SASABE Tetsuro)
Date: Mon, 25 Oct 1993 20:09:26 GMT

とうだいの笹部です。

In article <[email-masked]>
    [email-masked] (enami tsugutomo) writes:

 |	  以下の部分はちょっとあいまいに(僕には)思えるので確認させてください.

  はい。

 |	  RFC 822でいう body と unstructured field body (Subject: 等)に
 |	  は 7bit の ISO 2022が通せるが, structured field body (To:
 |	  From:等)には通せない, しかしそこにも ASCII以外の文字(集合?)を
 |	  使いたい, ということでしょうか?

  ええっと、「使いたい」の主語が私だと嘘になりますが、意味としてはそう
です。

  From: や To: に ISO-2022-JP 文字を書きたい人が居る(私ではない)。現在、
そういった人は MIME を使っていることが多い。私は MIME 以外の方法として 
8bit 透過を考えている。

という意味です。判りにくかったらごめんなさい。

---

From: [email-masked] (Tetsuo Sakaguchi)
Date: 26 Oct 93 01:30:55 GMT

ありがとうございます。えっと、私は vi ユーザなので、、、

>	1G!GfromMime

この fromMime というのはどこに(どういうキットに)あるのでしょうか?
私はまだ mm2.6 しか使ったことがないもので、、、、。
--
阪口哲男＠図書館情報大学
Tetsuo Sakaguchi. University of Library and Information Science, JAPAN.

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Tue, 26 Oct 1993 03:15:21 GMT

On 10/26/93(10:30) [email-masked] (Tetsuo Sakaguchi) wrote
in <[email-masked]> (fj.mail:2243/etlss2):
 |ありがとうございます。えっと、私は vi ユーザなので、、、
 |
 |In article <[email-masked]> [email-masked] (Yutaka Sato 佐藤豊) writes:
 |>(日本語化)ｖｉを使用している私たちは、
 |>
 |>	!!fromMime	とか
 |>	1G!GfromMime
 |
 |この fromMime というのはどこに(どういうキットに)あるのでしょうか?
 |私はまだ mm2.6 しか使ったことがないもので、、、、。

★発売中のMIMEエンコーダ/デコーダ★がそれです(^_^)

mm2.6 の contrib/mms/news の下にもありますが、これはもう旧式
(1342対応)なので、mimehead.tar のものをお使い下さい(1522対応)。

On 10/21/93(15:33) I wrote in <[email-masked]>
 | |・mimehead.tar
 | |	etlport.etl.go.jp:‾ftp/pub/mime/mimehead.tar.Z
...
 |　・フィルタコマンドとして (toMime/fromMime)
 |    　標準入力をMIMEエンコード／デコードして標準出力に出すプログラム
 |　　　テキストエディタの中から「バッファ内容をフィルタに通してバッファ
 |　　　に戻す」とか、ページャの前段やポスターの後段にかませて使えます。

なおmm2.7の発売は、年末か来年早々になる模様です。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Tue, 26 Oct 1993 21:02:05 GMT

On 10/25/93(20:41) I wrote in <[email-masked]>
 |インターネット規格を舶来だと思うのは変だと思います。規格作成の
 |ワーキンググループ(IETF:Internet Engineering Task Force)には誰
 |でも参加できるし、議事録も公開されています。IETFの議論の殆んど
 |はメイリングリストで行われているので、日本に住んでいても特に
 |ハンディキャップはないでしょう。もちろん、その結果としてのRFC
 |は配布自由で、いろんなところから入手できます。

MIME関連のIETFの議事録やRFCを以下に集めてありますので、御利用下さい。

etlport.etl.go.jp:‾ftp/pub/mime/
　　　　RFC     RFC{1425,1426,1468,1521,1522,...}
        ietf    ietf-822, ietf-smtp アーカイブ
        doc     MIME-FAQなど

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Mon, 25 Oct 1993 03:31:30 GMT

X-Nsubject: Re: MIMEについて

  NTTの川上です。

 "fj.mail"の"About MIME."について
    (記事<[email-masked]>)、
    [email-masked]、
  >> ッダに埋め込めることができたらいいと感じています。
User-interfaceとしては、面白いと思いますが。。。。
  ただ、*みたい/書きたい*のであれば、User-Interfaceにおける
ヘッダーにある内容をmail/news-systemのheaderにいれることに
拘らなくてもいいと思いますよ。user-interface(どう見えるか)と
mail/news-system(どう実現するか)は切り離して考えた方がいいと
思います。

  あとは、upper-compatibilityを保って欲しいです。(今のままだと、
例えば、Subjectに書いてあるMIME文字列は、非対応のreaderで見ると、
meaninglessな文字列ですから。。。)

  >> ばいいのですが。もっとも、僕は、MIMEが充分すっきりし
今の、`From:',`Subject:',`To:'などの、mail/news-systemが
*解釈*するヘッダーにいれなければ。konoさんの言葉をかりると、
 "fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、
    [email-masked]$
です。
					wataru

# MIMEを*解釈*するコマンド(grep,less etc)にOS。:-)
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

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

>>>>> <[email-masked]> にて、
	[email-masked] (Wataru KAWAKAMI) 氏曰く、

川上>   あとは、upper-compatibilityを保って欲しいです。(今のままだと、
川上> 例えば、Subjectに書いてあるMIME文字列は、非対応のreaderで見ると、
川上> meaninglessな文字列ですから。。。)

  semantics に関する議論は合理的でないと思います。

  >> ばいいのですが。もっとも、僕は、MIMEが充分すっきりし
川上> 今の、`From:',`Subject:',`To:'などの、mail/news-systemが
川上> *解釈*するヘッダーにいれなければ。

  しかしながら、address の phrase の部分や comment の内容を 
mail/news-system が *解釈* しているとは思えないのですが。

---

From: [email-masked] (Takahiro Kanbe)
Date: 28 Oct 1993 12:45:24 GMT

直接MIMEに関する発言ではありません。

> mail/news-system が *解釈* しているとは思えないのですが。
commentでは、括弧(parenthesis)について、

	- 対応が取れているか。
	- ネストしていないか。

を調べるシステム(sendmaliなど)が存在します。
これは、解釈していると言えないくはないですか?

--
神戸　隆博（かんべ　たかひろ）		FXIS/APD/EG

---

From: [email-masked] (Wataru KawaKami)
Date: 28 Oct 93 07:51:18 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 状況をまとめると.... (was Re: MIMEの``乱入''(?) ...)

  NTT川上です。表題を変えました。

  論点の整理を兼ねて、箇条書に分類してまとめてみました。間違いが
ありましたら、よろしくお願いします。議論の論点の整理になればと
思います。

==============================================================================
『状況をまとめると。。。 in fj.mail(93/10/28)』

				(93/10/28 [email-masked])
				Thanks to [email-masked].

1. `Subject:', `From:', `To:' など
  1.0  ascii-readable(english etc.)		(internet-common)
  1.1. ascii-encoded(MIME etc.)			賛否両論
  1.2. JIS-7(ESCを含む)				(ここでは提案なし？)
  1.3. 8-bit					(賛否両論？)

2. その他の header (X-* etc ???)
  2.0. ascii-readable(english etc.)		(internet-common)
  2.1. ascii-encoded(MIME etc.)			禁止を求める声無し
  2.2. JIS-7(ESCを含む)				禁止を求める声無し
  				(規格では、ESCはすでに通っている？)[1]
  2.3. 8-bit					賛否両論

3. body
  3.0. ascii-readable(english etc.)		(internet-common)
  3.1. ascii-encoded(MIME etc.)			禁止を求める声無し
  3.2. JIS-7(ESCを含む)				(現在のfjではokay)
  3.3. 8-bit					(ここでは提案なし？)

[comment]
1) 1.には、"Sender:","Newsgroup:","Path:","Message-ID","Reply-To:",
   "Followup-To:","Cc:"などが入ると思います。
2) 2.は、X-*とそうでないのを分ける必要があるかも知れません。
3) 今、hotな議論がされているのは、1.1.についてだと思います。
4) x.0にromajiは含まれるのかどうかというところです。
==============================================================================
ちなみに、"X-Nsubject:"は、日本語(internetからみれば、local-lan-
guage ?)の題目を読み書きするために2.2の実装法をとっています。

   ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊  ＊

  mail/newsについて、もしかしたら、別々に考えた方がよいのかも
知れません。

  ある意味で、mailは、自分の通そうとしている方式が中継経路に
対してがtransparentで、メールをうける相手のmailerが``解釈''
できればというところもあるような気はしています。しかし、中継
経路でのトラブルを考えると、From:,Subject:などは、可読にして
おいたほうがいいかなと思っています。
						wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

[Reference]
1. "fj.mail"の"Re: Why MIME ?"について
    (記事<[email-masked]>)、
    [email-masked]$

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Fri, 29 Oct 1993 09:45:54 GMT

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

川上> ==============================================================================
川上> 『状況をまとめると。。。 in fj.mail(93/10/28)』

川上> 				(93/10/28 [email-masked])
川上> 				Thanks to [email-masked].
川上> 				

川上> 1. `Subject:', `From:', `To:' など
川上>   1.1. ascii-encoded(MIME etc.)			賛否両論

川上> 2. その他の header (X-* etc ???)
川上>   2.1. ascii-encoded(MIME etc.)			禁止を求める声無し

川上> 3. body
川上>   3.1. ascii-encoded(MIME etc.)			禁止を求める声無し

  ``encoded'' という表現がなされていますが、くどいようですが、MIME は 
encoding 法ではないことを強調しておきたいと思います。

  MIME は data の種類を宣言する方法なのです。header においては文字コー
ドの種類を、body においては（各 part の）data の種類を。

  Base64 encoding をかけた ISO-2022-JP header の印象があまりにも強かっ
たせいか MIME = Base64 というイメージを持っておられる方がおられるかも
知れませんが、それは間違いです。

  将来的に、7 bit / 8 bit through になれば、header でも、例えば、7 と
か 8 という encoding を決めて、

	=?ISO-2022-JP?7?ISO-2022-JP文字列をそのまま書いちゃう?=

	=?EUC-JP?8?EUC文字列をそのまま書いちゃう?=

というのもできるかも知れません。（これでも、=? とか ? とか 7 とか 8 と
か ?= といった意味不明文字列が登場してるからだめかな？）

  ただ、重要なのは、（文字コードやエンコーディング法）を宣言するという
ことです。body においては、data の種類を宣言するということです。

  この記事の body は、text/plain という種類の data で ISO-2022-JP とい
う文字コードを 7 bit で encoding しています。

  7 bit through だから、わざわざ Base64 をかけたりしません。しかし、
binary を送る時には Base64 をかけないとまずいです。将来的には、圧縮 
encoding とかも登場するかも知れないし、そうした中から、目的にあった 
encoding を選ぶことができます。

  header に話を限れば、無数の文字集合と幾つかの encoding 法の数多い組
合せの中には、望ましい組合せというものがあるだろうし、また、
ISO-2022-JP などの 7bit がそのまま通るならば、わざわざ encoding をかけ
るのはばからしいだけです。それは、純粋に技術の問題です。

  MIME は ASCII 文字をアルファベットとする mail/news の message を記述
する『言語』で、従来の RFC822 に基づく header 記述言語の上位互換になっ
ています。MIME では、その言語を使って data の種類を『宣言する』だけで
す。

  従来通り、RFC822 に基づく言語を使うも良し、MIME 言語を使うも良しです。
MIME は RFC822 に基づくものに悪影響は与えませんし（悪影響を与えられた
ものは従来の仕様にも従っていなかったのです）、MIME の枠組を受け入れれ
ば、その宣言性に基づいて、いろいろ面白いことができます。

＃ところで、MIME の NG に関する話はどうなっちゃったんだろう？

---

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

鎌原＠阪大情報です。

>   例えば、Subjectに書いてあるMIME文字列は、非対応のreaderで見ると、

 それは下位互換なんじゃありませんか？上位互換なら、従来のヘッダがMIME
対応readerでも見えるってことで、それは全然問題ないですから。

>    >> ゃう分けでしょう？  やっぱりまずいよ。例えば、To:にxfacesとか入っていた

 なにがまずいのか分かりません。mail/news-systemに関して、それでちゃん
と送れるなら、meaningfulである理由はなにもありません。それこそ後は送り
手と受け取り手のUser-Interfaceの問題。

>   # MIMEを*解釈*するコマンド(grep,less etc)にOS。:-)

nkf -mでMIMEがエンコードできるようにするっていうのは？:-)。unixのgrep
で漢字を検索したことってないけど。。。
setenv LANG MIMEですか:-)

---

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

### Japanese subject will be read as below: ###
X-Nsubject: 検索ツール for MIME? (Re: なぜ MIME)

 NTTの川上です。

  "fj.mail"の"Re: About MIME."について
    (記事<[email-masked]>)、
    [email-masked]、
  >> nkf -mでMIMEがエンコードできるようにするっていうのは？:-)。unixのgrep
MIMEを推進していくのであれば、":-)"ではなくて、これを真面目に
検討しないと駄目なのではないでしょうか。

  別の記事で書いたかも知れませんが、ちなみに、私の場合、漢字
(jis-7)の複数のファイルを検索する場合、
	less(less  version 177j(w3.2[93/01/26]))
で検索しています。(以前、fj.sourcesにless177へのパッチを
出しました。)

# OSがEUC/SJISを受け付ける環境で使われている方は、直接
# 検索しているんでしょうね。
					wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

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

On 10/29/93(12:57) [email-masked] (Wataru KawaKami) wrote
in <[email-masked]> (fj.mail:2296/etlss2):
 |  >> nkf -mでMIMEがエンコードできるようにするっていうのは？:-)。unixのgrep
 |  >> で漢字を検索したことってないけど。。。
 |  >> setenv LANG MIMEですか:-)
 |MIMEを推進していくのであれば、":-)"ではなくて、これを真面目に
 |検討しないと駄目なのではないでしょうか。

"mimehead.tar"に含まれている fromMime, toMime, libmms.a などは、
そういった用途のために作ったものです(<[email-masked]>)

出ていくものには、nkf -j | toMime
入って来たものには fromMime | nkf -e とかで良いと思います。

 |  別の記事で書いたかも知れませんが、ちなみに、私の場合、漢字
 |(jis-7)の複数のファイルを検索する場合、
 |	less(less  version 177j(w3.2[93/01/26]))
 |で検索しています。(以前、fj.sourcesにless177へのパッチを

fromMime < file | less で、パイプ経由ですがlessができます。複数の
ファイルをやる場合には、less本体にパッチをあてるしかありませんが、
output.cの中で、

	for (p = line;  *p != '¥0';  p++)

の前に、

	MIME_strHeaderDecode(line,line,1024);

を加えてコンパイルして、libmms.a をリンクすれば取り敢えず使えます。
実際には、MIMEデコードするか否か、ヘッダ部分だけを扱うか否かの
スイッチを付ける必要があるとは思いますけど。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (enami tsugutomo)
Date: 30 Oct 93 02:17:12 GMT

In article <[email-masked]>,

> 2. その他の header (X-* etc ???)

	1. と 2. は何を基準にわけてますか?

	RFC822 に依るとするならば, Subject: なんて optional field だし, 
	その field body は unstructured なんだから, 2. のほうに近いと
	思うんですが.

えなみ つぐとも

---

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

### Japanese subject will be read as below: ###
X-Nsubject: fieldの区分 (Re: 状況をまとめると.... )

  NTTの川上です。

  "fj.mail"の"Re: Summary of status (Re: Invasion of MIME (?)...)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> 	その field body は unstructured なんだから, 2. のほうに近いと
おっしゃるとおりです。もう一度、rfc822に則って、区分をしきり直した
ほうがいいと感じています。

  ちなみに、rfc822を読むかぎりでは、unstructured fieldのcontentsは、
	any ASCII character (0-127 (decimal))
となっているので、"Subject:"は、mohtaさんがいうように、規格上は、
jis-7が通る筈ですね。
						wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Satoru OKAMOTO 岡本 聡)
Date: Sun, 31 Oct 1993 13:58:26 GMT

In article <[email-masked]> 
 >となっているので、"Subject:"は、mohtaさんがいうように、規格上は、
おっしゃる通りですが、field-name ("Subject"の部分)にはコントロールコードを
含めることができないので、処理を軽くする上で field-bodyも一緒にチェックして
コントロールコードを落とす実装が大半であったという経緯があります。

規格を厳密に運用するならば、規格準拠の実装を排除するためのコストを新たに
考える必要があると思います。

おまけ
C-Newsのinewsは field-body のESCは保存します(bodyのESCを通過させるため)。
しかし、その副作用として field-name のESCも落としません。
X-題目: なんてのも使用されてします可能性があります。
実際には、ESC-$-B,ESC-(-B がESC-$-b,ESC-(-b と小文字化されて漢字表記には
なりませんでしたけど。
-- 
■□■  日本電信電話（株）伝送システム研究所 伝送処理研究部    □■□
□■□  岡本  聡 (Satoru Okamoto)       [email-masked]  ■□■
■□■  Tel. 0468-59-8870               JG8PWT/1               □■□