Subject: Re: header ni MIME dounyuu ni tsuite ($@L2$$(J...)

From: [email-masked] (SASABE Tetsuro)
Date: Mon, 1 Nov 1993 02:31:31 GMT

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

 |>     なぜ現実的で無いと断言できるのですか？
 | Internetの話だからです。

  現実に fj をスプールするために News システムにパッチをあてているサイ
トが世界中にあるわけですが、これも現実的ではないのですか？
	
 |>     fj のニュースで日本語を流すため、中継するすべてのサイトで Bnews にパッ
 |>   チを当てていた事実はどこへ行ったのでしょう。Body 部のためにすべてのサ
 |>   イトで対応することが現実に出来たのに、なぜ heder だと「対応が難しい」
 |>   ことになるんですか？
 |
 | 日本国内なら対応できるでしょうね。そうなれば、MIMEでも意味不明の羅列
 |ではなくなるでしょう。現状がそうでないから、MIMEが意味不明に見えるだけ
 |です。

  いまや fj は日本だけのものではありません。世界中で読まれています。 
fj のときと同じ対応が出来ると期待することのどこがおかしいでしょうか？

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

---

From: [email-masked] (Takahiro Kanbe)
Date: 1 Nov 1993 03:50:22 GMT

In article <[email-masked]>
	[email-masked] (Wataru KawaKami) writes:
>    rfcでは、envelopeとcontentsしか書いていないのですが、今までの
>  議論ででてくるheaderとbodyは、まさしくこれの意味で皆さん使って
>  ますよね？
全く違います。議論で出ているのも違うと思います。エンベロープに対するコ
ンテント、ヘッダに対するボディは全く別の概念です。

メールのシステムを、MTA(Message Transfer Agent)とMUA(Message User
Agent)の2つから構成される様にモデル化することが、よくあります。

MTA間では、

o メッセージをシステム間で転送するもの
o MTAの間で転送の処理に使用される情報を含んだものがエンベロープ
o 転送される実際の内容がコンテント

です。SMTPで言えば、そのセッション中で交換されるエンベロープはSender
(送信者)、Recipient(受信者)、送信の方法(通常は、ほとんど相手のメールボッ
クスに送る)の3つが相当します。

通常はコンテントに、ヘッダとボディが含まれているといって良いでしょう。
ヘッダはMUAにとって意味があります。そして、原則としてMTAはコンテントの
内容を変更してはなりません。但し、実際はMTAやMUAが、きっちりと分離して
いるわけではないなどの理由で、MTAは次の場合にヘッダを変更します。

o トレース・ヘッダの付加(RFC822ではReceived)

o MTAのプログラムがMUAの機能を含んでいて、アドレスの補間などを行う場合

o MTAが全く異なる世界のメールを処理する場合(gatewayの場合)

>  この部分は、``封筒の中身''(所謂 body部分)についてはここrfc822では
>  定義していないという意味ですね。
定義していないのはエンベロープです。RFC822はまさに、コンテントの内容を
規定しています。

>    headerは、基本的にsystemが解釈するものという私の理解も間違って
>  いなかったようです。そういう意味では、我々が日頃使っているmail/
>  news-readerは、systemが解釈する部分を例えば、題目、送り主を表示
>   するために流用しているに過ぎないということが言えそうですね。
ヘッダはMUA、さらに砕いて言ってしまえば、ユーザインターフェイスのため
にあると言っても過言ではないでしょう。あくまでも、ユーザがボディを参照
するときに役立つための情報を与えるものです。メールのリーダなどを含めて
「メール・システム」と言うのでしたら、別ですが、SMTPでは送信者、受信者
のアドレスさえあれば、メールの転送はできるんです。

なお、ニュース・システムについてはエンベロープとコンテントの議論はあて
はまりません。システムのモデルが全く異なりますので。敢えて、あてはめる
と、エンベロープは Message-ID だけとなります。

>  失礼かもしれませんが、もし読まれていないのでしたら、一度、コン
>  ピュータネットワーク(タンネンバウム著、斉藤他訳)の該当箇所を読ま
>  れてみることをおすすめします。ARPANET(internet)における電子メー
>  ルについて、基本的な説明はでていました。(p691)  
Marshall T. Rose, Internet Message, Prentice-Hall, 1993

こちらを、お読み下さい。

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

---

From: [email-masked] (守岡 知彦 (MORIOKA Tomohiko))
Date: Mon, 1 Nov 1993 17:44:03 GMT

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

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

川上>   NTTの川上です。

川上>  "fj.mail"の
川上>  "Re: Invasion of MIME (?) (was Re: header ni MIME dounyuu ni tsuite)"について
川上>     (記事<[email-masked]>)、[email-masked]、

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

  Subject: に ISO-2022-JP 文字列を生のままで入れて良いという合意が得ら
れるのなら、それはそれで良いことだと思います。

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

  Base64 ではなく、MIME ということであれば、私は、ISO-2022 に対応する
ものだと思っています。ISO-2022-JP は、複数の文字集合を ISO-2022 という
エンコード方式で一緒に使えるようにしたものですが、MIME もそのようなも
のだと考えられます。

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

  例えば、MIME の encode 方式として、Base64 の代わりに、ISO-8859-* に
おける Q-encode みたいに、かなとかはローマ字になるような encode 方式が
あればもう少し抵抗が少なかったかなあなんて思います。

（たとえば、「かなはローマ字になる」を encode すると
``=?ISO-2022-JP?J?KaNaHaRO--MA=3171NiNaRu?='' になるとか）

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

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

  すると、RFC 822 で規定されている comment なら良いんでしょうか？私は
コメント的なものとして comment を利用したいのですが。

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Mon, 1 Nov 1993 01:25:21 GMT

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

NTTの川上です。

  "fj.mail"の"Re: envelope and body. (Re: From rfc822 ...)"について
    (記事<[email-masked]>)、[email-masked]、
  >> 
  >> RFC822には「envelopeとは何か」を抽象的にしか書いてないわけですが、
  >> これはそれが RFC822のスコープの外だからでしょう。また、envelopeは
  >> SMTP等のプロトコル上でcontentとは別にやりとりされ、ユーザには見え
  >> ないのが普通だと思いますので、余計にわかりにくい。
MOTISなどのメールシステムでは、envelopeは、userに見えない
ようですね。(いっそ、MOTIS(X.400)に乗り換えるとか。:-))

  internet-mail/newsでは、できるだけ日常生活のmemoに近い形で
メールシステムを実現しようとしたから、逆に、ysatoさんがおっ
しゃられるところのわかりにくい形になってしまったのではない
でしょうか。

  わかりにくいとおっしゃるのであれば、いっそのこと、rfc-822の
envelope(header)部分は、envelopeとしてのみ使い、MOTISのように、
rfc-822のcontents部分に"From:,To:"とかの人間が見るためのheader/
bodyを入れる方法を提案し、tryされてはいかがでしょうか。

  そうすれば、かなりすっきりすると思います。

  私は、internet-mail/newsを使う以上、細かい部分を云々するより、
rfc822の考え方は、受け入れる必要があると私は考えますが、いかが
でしょうか。
					wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Akira Takuma)
Date: Sat, 30 Oct 1993 05:22:27 GMT

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

  |  |  | 日本語に限った話しっていうのでもないですよね。例えば、海外からやっ
  |  |  | てくる =?ISO-8859-X?Q?XXXX?= なども拒否するということでしょうか？
  |  |  | でしたら、早めにしかるべきところで表明した方が良いと思いますが…
  |  |そのわりに fromMime を含めて ISO-2022-JP 専用みたいなプログラム
  |  |が多いのは何故でしょうか。MIME の実装はリーダにとってものすごく
  | 自分が扱える部分だけを扱う、というのはMIMEのheader/bodyを通じた共通
  | の基本方針です。MIMEは「これを自分が扱えるかどうか」を判断するための
  | 共通の言語を、最低限の共通文字である US_ASCII で定義しているわけです。

MIME の宣言性自体は別に悪いことだとは思いませんが、結局自分の知らない
宣言だったら無視するわけでしょ？例えば ISO-2022-JP しか解釈していない
リーダの場合、これは海外からやってくる=?ISO-8859-X?Q?XXXX?= を拒否
しているのとどう違うのですか？(伝達できても読めなきゃ意味がないんじゃ
ないでしょうか)
例え無理に表示してもデコードしたら未知のエスケープシーケンスとか
入っていたら端末がふっとぶかも知れないわけですね。
非JISな人のことを考えてるようで考えてないように思えますが、私の
理解不足でしょうか。

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

これだったら満足にエンコードしようと思うと結局制御コード全部知って
いないといけないわけでしょ？非JISな人のことも考えるんだったら
それじゃ困ると思いませんか？
MUA 全てがそんなこと考えないといけないくらいだったら MTA が解釈する
以外のヘッダ(Subject なり)に ESC なりを透過するようにした方が簡単にも
思えるのですが。(もしくは本当に ESC コードだけか全体をエンコードする)

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

だからどうしてもしたければそれを MIME-From: とかでしたら
いいんじゃないですか？
MH 6.7? とかでリプライしたら失敗するとか Subject が途中で切れるとか
いう被害の方が大きいように思いますが。
仮に metamail や fromMime を併用しても例えば MH に EUC パッチを
あてていたら MIME デコードした部分だけ JIS になるのでページャーが
狂ったりしませんか？

  | メッセージが入れ子になっていると考えて良いでしょう。従って、ボディ部
  | においても、ボディ部品ヘッダに関してはRFC1522による非ASCII表現が前提
  | になっています。

メッセージ部分に MIME で multipart を使って何を書かれようが
それによって誤動作する MIME 非対応の MUA を私は知らないので
そちらについては別に反対はしていません。
-- 
-------------------------------------------------------------------------
(株) 松下ソフトリサーチ	第一開発部 第一開発室 宅間
				E-mail:[email-masked]
-------------------------------------------------------------------------

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Mon, 1 Nov 1993 05:54:30 GMT

On 11/01/93(10:25) [email-masked] (Wataru KAWAKAMI) wrote
in <[email-masked]> (fj.mail:2335/etlss2):
 |  >> RFC822には「envelopeとは何か」を抽象的にしか書いてないわけですが、
 |  >> これはそれが RFC822のスコープの外だからでしょう。また、envelopeは
 |  >> SMTP等のプロトコル上でcontentとは別にやりとりされ、ユーザには見え
 |  >> ないのが普通だと思いますので、余計にわかりにくい。

ここで私が「わかりにくい」と書いたのは、初めてRFC822を読んだ人や
メイルシステムにあまり馴染みのない人には、わかりにくい概念かも知
れないという意味です。だから、誤解するのもある程度しかたがない。

けど、その概念自身は、RFC1425や神戸さんの記事にも説明されている
ように極めて明確なもので、とてもわかりやすいと思います。

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

---

From: [email-masked] (Takahiro Kanbe)
Date: 1 Nov 1993 06:18:17 GMT

In article <[email-masked]>
>  思えるのですが。(もしくは本当に ESC コードだけか全体をエンコードする)
全てのMTAに簡単に手が入れられるという前提がありますね。

>  だからどうしてもしたければそれを MIME-From: とかでしたら
但し、少ーしでいいですから考えて頂きたいのは、メールはSMTPやInternetに
限らない他の世界(Decnet, XNS, BBSなど)に relay される場合があることで
す。そういった他の世界との「相互接続性」を重視すると、gatewayの役をす
るMTAで、

- 新しいヘッダのサポート
- ヘッダに対してもコード変換をサポート

といったのは結構、たいへんということが予想できますね。この点では、
ヘッダのフィールドにMIMEというのは、(まだ少しは)MTAの負荷にはなりにく
いといったことも言えます。(あくまでも「なりにくい」だけですが。)

--
神戸　隆博（かんべ　たかひろ）		FXIS/APD/EG コンパイル待ち

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Mon, 1 Nov 1993 08:50:26 GMT

On 10/30/93(14:22) [email-masked] (Akira Takuma) wrote
in <[email-masked]> (fj.mail:2336/etlss2):
 |  | 自分が扱える部分だけを扱う、というのはMIMEのheader/bodyを通じた共通
 |  | の基本方針です。MIMEは「これを自分が扱えるかどうか」を判断するための
 |  | 共通の言語を、最低限の共通文字である US_ASCII で定義しているわけです。
 |
 |MIME の宣言性自体は別に悪いことだとは思いませんが、結局自分の知らない
 |宣言だったら無視するわけでしょ？例えば ISO-2022-JP しか解釈していない
 |リーダの場合、これは海外からやってくる=?ISO-8859-X?Q?XXXX?= を拒否
 |しているのとどう違うのですか？(伝達できても読めなきゃ意味がないんじゃ
 |ないでしょうか)

ISO-8859-X については、K.Simonsen のニモニック(RFC1345)を使って
とりあえずASCII文字の組み合わせで表示するというようなことも考え
られます。
ギリシャ文字などは JIS-X-0208中のギリシャ文字に変換して表示する
ようなこともできますね。
ある文字セットに対するフォントを持っていても、文字コーディング
システムが違う場合は良くありそうなケースですが、その場合もMIME
で「これは何の文字セットだ」と宣言してあれば、ローカルな文字コ
ードへの変換は容易だと思います。

 |  | ISO-2022-JPのようなASCIIを包含する文字セットの場合、これは実際簡単で
 |  | はありません。ASCII部分を含めてエンコードするには、 RFC822 の構文を
 |  | ちゃんと解析する必要があります。一方、非ASCII部分だけをエンコードする
 |  | と割り切れば、ISO-2022 の制御コードだけを認識すればエンコードできます。
 |  | 実際、toMimeなども含め、ほとんどのエンコーダがそのような実装になって
 |  | いると思います。
 |
 |これだったら満足にエンコードしようと思うと結局制御コード全部知って
 |いないといけないわけでしょ？非JISな人のことも考えるんだったら
 |それじゃ困ると思いませんか？

自分が使っているローカルコードだけを知っていれば良いと思います。

 |MUA 全てがそんなこと考えないといけないくらいだったら MTA が解釈する
 |以外のヘッダ(Subject なり)に ESC なりを透過するようにした方が簡単にも
 |思えるのですが。(もしくは本当に ESC コードだけか全体をエンコードする)

ぼくのイメージだと、MIMEのエンコーダ／デコーダはそれぞれのMUAが
持っているというより、MTA と MUA の間に挟む共通コマンドという
感じで済むと思います。nkf みたいな感じですね。ローカルコードの
違いは、環境変数とかパラメタによって教えてやれば良いと思います。

 |  | これはまあその、実際には MIME(RFC1522) の規格を逸脱した話です。
 |  | RFC1522 を読んで、私のウソを指摘しましょう。ただ、このような日本語の
 |  | 名前の使用を切望している人は実際にいるので、これが可能になるように
 |  | 規格の改訂を要求していく道はあると思います。
 |
 |だからどうしてもしたければそれを MIME-From: とかでしたら
 |いいんじゃないですか？
 |MH 6.7? とかでリプライしたら失敗するとか Subject が途中で切れるとか
 |いう被害の方が大きいように思いますが。

アドレス(RFC822で言う addr-spec や route-addr)の部分に非ASCIIを
入れることの可否については、私は結論を持っていません。
フォールディングに対応していないソフトウェアについては、早急に
そのバグを修正して欲しいと思います。

 |仮に metamail や fromMime を併用しても例えば MH に EUC パッチを
 |あてていたら MIME デコードした部分だけ JIS になるのでページャーが
 |狂ったりしませんか？

nkfとtoMime/fromMimeを組み合わせて使うとかで、解決できないでしょ
うか？

 |  | メッセージが入れ子になっていると考えて良いでしょう。従って、ボディ部
 |  | においても、ボディ部品ヘッダに関してはRFC1522による非ASCII表現が前提
 |  | になっています。
 |
 |メッセージ部分に MIME で multipart を使って何を書かれようが
 |それによって誤動作する MIME 非対応の MUA を私は知らないので
 |そちらについては別に反対はしていません。

これの元は、

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

ということでした。RFC1521は良いが、RFC1522は駄目というように読めた
ので、RFC1521を受け入れることはRFC1522も受け入れることにつながると
いう意味のことをいいたかったわけです。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Yasushi Shinjo)
Date: Mon, 1 Nov 1993 14:44:36 GMT

こんちには。新城＠琉球大学です。

要約：漢字を通すには、X-NSubject:, MIME-From: よりも From:,
To: など標準のヘッダを使う方が有利だと思います。

In article <[email-masked]> 
	[email-masked] (Akira Takuma) writes:
> X-Nsubject: Re: ヘッダに MIME 導入について

いろいろな中継ホストで、X-NSubject: や MIME-From: のような標
準ではないヘッダが落ちる可能性が高いと思います。特に、メーリ
ング・リストなどでヘッダを加工している場合、しばしば落ちると
思います。たとえば、awk スクリプトで To:, From:, Reply-To: 
のような標準のヘッダは、/From:/ のようにパタン・マッチで引っ
かけて、printf("From: %s",...) のように保存されるでしょうが、
MIME-From: や X-NSubject: は落ちる可能性が高いでしょう。

それで、From: に漢字を入れようとなると、ESC を入れて JIS で
行くか、MIME を使う、８ビット・スルーにして EUC を使うなどの
方法が出てきますけど、この中では、安全性という観点で MIME が
有利かなと思います。ESC を入れても、漢字部分の @:()<>,といっ
た文字の問題があります。８ビット・スルーの方も、現状ではボディ
すら７ビットの中継サイトもあるくらいですし。

MIME対応のソフトウェアを入れる手間が問題になっていますが、何
かのついでにやれば、手間はかからないと思います。MH, krn, gn,
mnews などを開発なさっている／日本語化なさっている方が、なに
かのバージョンアップのついでに MIME 対応のコードを２・３行追
加して下さるだけで、あっという間に MIME が広まってしまうでしょ
う。

もう一つ、MIME の方法の面白い性質だなあと思ったのは、どんな
ヘッダでも使える所です。Subject: だけでなく、From: でも To:
Approved: でも、まったく一様に扱えるところです。X-NSubject: 
方式なら、X-NFrom: とか、X-NTo: とか、個々にやっていかなくて
はなりません。もし将来、新しいヘッダができたとしても、MIME 
の方法では、すぐに対応することができます。

それから、MIME の話とは直接は関係ないのですが、ヘッダといっ
ても、計算機が解釈する可能性があるからといっても、人間が読み
書きする部分と思っていいように思います。普通の郵便でも、宛名
や自分の名前を書きますよね。その部分は、郵便屋さん解釈するの
ですけど、送る人は書きますし、受け取った人も普通は読むわけで
す。誰から来たかなとか、○×申込書在中とか。

電子メールでも、To:, From:, Subject: に漢字を使いたくなるの
は当然なわけです。そのための実用的な方法として、MIME は、今
の所一番有利な方法じゃないかと思います。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　琉球大学　情報工学　　　　　　　　＼＼

---

From: [email-masked] (Shinji Kono)
Date: Mon, 1 Nov 1993 15:57:37 GMT

[email-masked]。
In article <[email-masked]> , 
	[email-masked] (Yasushi Shinjo) writes 
>は当然なわけです。そのための実用的な方法として、MIME は、今

News にしてもMailにしても、きちんとHeaderの中にJunet codeをローカルに許
しているサイトとの整合性の悪さ(a)が問題なんです。それがfjで実現できればベス
トなことは佐藤さんも認めている通りです。だとすれば、それをdiscourageする
ようなことをするのは良くない。

>バージョンアップのついでに MIME 対応のコードを２・３行追

というかゲリラ的にMIMEが広まっているから議論になっているのでしょう。
body/header にISO-2022とMIMEが混在するのが避けられない(b)。それに、MIME
を採用するならjisx0201.1976や98 code を拒否する根拠もないですよね。

>思います。

ある意味で別に落ちても構わない。MIMEでも行の折り返しで落ちるとかはありま
す。それでも、fieldが別なら別に被害はない。failure mailがとどいたときに
何かわかんないコードがFrom:に入っているのって悲劇です。僕は投票やアンケ
ートの時は直接的に困りましたし。互換性を問題にするなら別fieldが安全な選
択です。

(a)と(b)が改善されるならMIMEをサポートすると思います。しかし、fjのサイト
ならISO-2022を通す努力をする方が正しい気がする。Postmaster ‾= Userの大昔
と違って今やUserの方が圧倒的に多いわけですから、gatewayを直す方が
front-end を直すよりも楽かも知れません。

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

---

From: [email-masked] (Kazuhiro Kazama)
Date: 1 Nov 1993 13:40:48 GMT

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

In article <[email-masked]> [email-masked] (Wataru KawaKami) writes:
 > kazamaさんは、
 > 	   1) 目に見える文字 <-> 2進数 の対応関係を示した符号
 > 		   jis7,ascii,euc,sjisなど
 > 	   2) 2進数 <-> 2進数 の対応関係を示した符号
 > 		   base64,uuencode,ishなど
 > を同じもののように扱ってらっしゃるように思えるのですが、いかが
 > でしょうか。うえの二つは本来違うものと思いまし、扱いを変えるのも
 > 当然だと思います。(それとも、MIME+base64って、1)なんでしょうか。)

　私が特に指摘したのは、エスケープの落ちた文字列を復活させる手間と、
MIMEのエンコードの手間って似たようなものじゃないってことです。別に2)を
使ってもユーザに見えなければ実質上は同じだしね。

＃　もちろん、そういう方法を使うのはよいかどうかというのは別ですよ。

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

　私はMIMEの場合には、MIMEエンコードされる文字列だけだといやですけど、
アスキー表記が並記されていれば試験的に使って貰ってもかまわないという意
見です。

 > 読みにくいのは、MIME+base64とて同じです。:-<

　そうですね:-)

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

　そうだと思いますよ。

　前から書いているけど、私の主張はX-NsubjectもMIMEも似たようなもんで、
現段階でどちらもいきなり標準にして使われたら困るけど、まあ限定された範
囲で使って強制しなければかまわないよというものです。MIMEだけ攻撃される
のはおかしいと思いましたのでね。

 > # もし読まれていないようでしたら、rfc822をちゃんと読んで、ここを
 > # 理解してください。>kazamaさん

　これに関しては神戸さんがまったく違う解釈を示していますが、どちらが正
しいのかな？かなり興味深い問題ですね。
 
 > そういう意味では、"Subject:"に無理矢理jis7を通して、経路が対応
 > するまでは、暫定的に無理矢理ESCを埋めるなどして(実用上問題が
 > ないことは、"X-Nsubject:"の実装が示している)待つほうがよっぽど
 > 最終目標に近いと思うのですが、みなさん、いかがでしょうか。

　よくメーリングリストでローカルに特定のヘッダを定義して、それをユーザ
インターフェースが利用しているケースで、他のメーリングリストにもこの種
のヘッダへの対応を強制する人がいるんですね。一般的には、こういうローカ
ルルールへの要求に管理者は応じる義務はないということになっています。

　今回のX-Nsubjectのケースもこれに似ていると思いました。川上さんの意見
ではローカルのルールをもっとグローバルに適用してアングラ的にやればいい
ということなんでしょうが、すでに社内だけなら別の方法で日本語サブジェク
トなどを実現している所があるという話なので、私はさすがにこれを広い範囲
に広げるのはまずいと思ったわけです。

　あとRFCによるとメールの場合にはサブジェクトに日本語を通しても問題な
いが、ニュースの場合にはまずいという指摘をメールで受けましたので、ちょっ
と教えてもらおう／調べようと思っています。
--
	風間 一洋 ([email-masked])
	NTT基礎研究所 情報科学研究部
	分散コンピューティング原理研究グループ

---

From: [email-masked] (Yutaka Sato 佐藤豊)
Date: Mon, 1 Nov 1993 23:58:39 GMT

On 11/02/93(00:57) [email-masked] (Shinji Kono) wrote
in <[email-masked]> (fj.mail:2344/etlss2):
 |>電子メールでも、To:, From:, Subject: に漢字を使いたくなるの
 |>は当然なわけです。そのための実用的な方法として、MIME は、今
 |>の所一番有利な方法じゃないかと思います。
 |
 |News にしてもMailにしても、きちんとHeaderの中にJunet codeをローカルに許
 |しているサイトとの整合性の悪さ(a)が問題なんです。それがfjで実現できればベス
 |トなことは佐藤さんも認めている通りです。だとすれば、それをdiscourageする
 |ようなことをするのは良くない。

この文脈で佐藤というと、ぼくのことでしょうか？

ぼくは「世界中で受容される文字コードがあって、それがナマで通ること」
が理想だとは思います。けど、ISO-2022 がそのようなコードだとは、現状
では言えないと思います。インターネット規格であるMIMEを受容しない人が
いるのと同様に、国際規格であるISO-2022を受容しない人がいるからです。
それを嫌う理由というのも、類似しているように見えます。

　　　　　　　　　　　　　　　　 @ @

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 2 Nov 1993 02:44:13 GMT

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

  NTTの川上です。確認させて下さい。

  "fj.mail"の"Re: envelope and body. (Re: From rfc822 ...)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> ンテント、ヘッダに対するボディは全く別の概念です。
  ....
  >> 通常はコンテントに、ヘッダとボディが含まれているといって良いでしょう。
これは、"OSI"とか"X.400"での"envelope","contents"の定義の仕方
ですよね？(MOTISというシステムは、まさしく、このモデルにのっと
っている用ですね。。。。)

  rfc822の規格の中に使われている"envelope","contents"という
単語は、上の定義で使っているのではなく、我々が普段internet上で、
"header","body"のことを指しているのだと私にはとれるということを
書いたのですが、いかがでしょうか。(つまり、世の中で"envelope"が
指し示しているものと、rfc822の中の"envelope"が指し示している
ものが違うのではないかということです。)

参考までにお聞きしたいのですが、神戸さんの"header","envelope"の
rfc822における対応関係は、
  >> Marshall T. Rose, Internet Message, Prentice-Hall, 1993
上の本に書かれている内容なのでしょうか。それとも、神戸さんが
この本を読んで得た知識に基づいて、神戸さんのご意見としてかか
れたことなのでしょうか。もし、本の内容であるのであれば、その
部分をお教えいただければ幸いです。
					wataru
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 2 Nov 1993 03:10:30 GMT

### Japanese subject will be read as below: ###
X-Nsubject: 了解。 (was Re: headerが削られる？......)

  NTTの川上です。

  "fj.news.b,fj.mail"の"Re: some fields in header are deleted??? (Re: header ni MIME.....)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> 
  >>  すみません。化けて日本語に見えないということです。ヘッダがなくなって
  >> いるわけではありません。
了解しました。

news-systemが入れ替わって、これが化けなくなれば、"Subject:"も
通りますね。

# 化ける間は、fill-escすれば、とりあえず読めます。
# emacsでは、"fillesc2.el"+"jis-to-emacs-kanji.el", mnewsの
# kanjilib.cの中のrecover_jis()が強力です。:-)

  かなりのsiteでlocalには、"Subject:"の日本語通しができている
ようなので、できれば、jis7を試験的にでも通す合意をする方向で
検討していきたいと思うのですが、いかがでしょうか。

# ex) konoさん、いかがでしょう。

   ＊   ＊   ＊   ＊   ＊   ＊   ＊   ＊   ＊   ＊   ＊

  もともとの実装は、"Subject:"のjis7なま送りを想定して、readerの
整備を進めていました。

  現段階では、jis7を"Subject:"にいれるとお叱りを受けるので、
"X-Nsubject:"という別フィールドにいれるようにしています。

  "Subject:"のjis7なま送りが合意されれば、"X-Nsubject:"はその
*当初*の使命を全うしたことになります。

					wataru

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 2 Nov 1993 03:27:26 GMT

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

 NTTの川上です。

 "fj.mail"の"Re: header ni MIME dounyuu ni tsuite"について
    (記事<[email-masked]>)、
    [email-masked]、
 >> 加して下さるだけで、あっという間に MIME が広まってしまうでしょ
真に、そのように考えられているのでしたら、mnewsの作者が
書かれている以下の記事を参考に参考にしてあげて下さい。

 "fj.mail"の"Re: header ni MIME wo , no zakkan (Re: Why MIME ?)"について
    (記事<[email-masked]>)、[email-masked]、
 >> 
 >> 今の MIME の実装ではヘッダ全体に渡って MIME 対応かどうか調べる必要が
 >> あり性能的にも損失が大きいと思います。特に MIME では簡単に複数行に
 >> なってしまうので継続行を繋げて空白を除いて奇麗に表示しようとすると
 >> なおさらです。下手に毎回 metamail などの外部フィルタなど呼ぶような
 >> 実装でもしようものなら悲惨な速度になります。(実際開発中にいくらかの
 >> パターンを試して実感しました)
 >> 
 >> そこでさっきの例みたいに Mime- で始まるヘッダだけは必ずエンコードされて
 >> いることとし、Mime- を除いた名前のヘッダと置き換えてリーダが表示する
 >> わけです。
 >> こういう単純なルールであればリーダも作るのが楽ですし、Mime-* を解釈
 >> しないリーダは従来のフィールドをそのまま表示すればいいのです。
私も、mime2xnを書いていてそう思いました。

					wataru

# いい加減、jis7-in-"Subject:"で検討しませんか。:-)
# それとも、MIME同様、併記して、流してしまうとか。:-)
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KawaKami)
Date: Tue, 2 Nov 1993 05:32:08 GMT

NTTの川上です。

  rfc822を再度、読み返してみました。一部分、間違って、解釈
していたことがわかりました。

  "fj.mail"の"Re: envelope and body. (Re: From rfc822 ...)"について
    (記事<[email-masked]>)、[email-masked]、
  >> 指し示しているものと、rfc822の中の"envelope"が指し示している
ですが、rfc822の"envelope","contents"は、MOTISとかでいっている
ところの"envelope","contents"と同じものであることがわかりました。

  よって、"envelope"云々については、神戸さんがおっしゃるように、
	<< rfc822のSCOPE外である >>
というのが、正しいみたいです。

  ちなみに、rfc822の、該当部分、
========================================================================
     compose  the object to be delivered to the recipient.  This stan-
                                                            ~~~~~~~~~~
     dard applies only to the format and some of the semantics of mes-
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     sage  contents.   It contains no specification of the information
     ~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     in the envelope.
     ~~~~~~~~~~~~~~~
========================================================================
は、
	このstandardは、"contents"部分のフォーマットおよび、
	幾つかのsemanticsについてのみ適用される。封筒
	("envelope")部分の記載内容についてのspecificationは
	含まれない。
ということになります。

  message本体のみが配送され、本体から得られる情報からのみ、
配送に必要な情報(envelope)を生成しようとするからややこしい
ことをしないと、いけなくなってしまうわけですね。。。。

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

以下、余談です。

================================================================
  これなら、いっそのこと、rfc822のheaderを"envelope"にみた
てて、rfc822のbodyを"contents"とみたてて、"envelope"-"body"の
ある、mail/news-readerをつくれば、jis7は明日からでも使える
かも。:-)

  localで日本語を使っていても、gatewayで、そのまま、rfc822の
"body"に載せちゃえばいいし。

  それこそ、MIMEの枠で定義すれば、header名まで、日本語が
使えたりして。:-)
================================================================

						wataru

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

---

From: [email-masked] (Wataru KawaKami)
Date: Thu, 4 Nov 1993 05:28:46 GMT

### Japanese subject will be read as below: ###
X-Nsubject: X-Nsubjectについての誤解 (Re: jis7を......)

  NTTの川上です。

 "fj.mail"の"Re: Use jis7 in header(Re: Invasion of MIME (?) .....)"について
    (記事<[email-masked]>)、[email-masked]、
 >> 囲で使って強制しなければかまわないよというものです。MIMEだけ攻撃される
MIME+base64を何の予告もなしに、"Subject:"-fieldにいれたかでしょう。
(ex: nifty-mail<->jp gateway.)

  例えば、"Subject:"にESCが落ちるということをわかっていて、jis7が
englishとともに併記されていたら、どうだったでしょうか。おそらく、
日本語を入れてはいけないというお叱りのメールをいただいていたと思い
ます。

  別のfieldに入っている分には、なにもいわれなかったと思います。

  そこら辺が、"X-Nsubject:"という別のフィールドを設けて実装を始めた
理由です。

誤解があるようですが、
  >> ではローカルのルールをもっとグローバルに適用してアングラ的にやればいい
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  >> ということなんでしょうが、
は、まったくの誤解です。

  別の記事にも書いたように、"X-Nsubject:"は、"Subject:"にjis7が
認められていなかったころに"Subject:"にjis7が許可される日を夢見て、
mail/news-readerのjis7'ed-"Subject:"化を進めるべく、jis7の、当面
可能な流通方法として考え出したものです。(ちなみに、私は、これを
標準にするとはいっていません。"Subject:"にjis7が通る方が良いです
から。)

  ちなみに、kazamaさんのいう、``ローカルのルール''っていうのは、
どういう意味で書かれているのでしょうか。"X-Nsubject:"が規格に
なっていないから、``ローカル''という意味でしょうか。

  fj.sourceとかに投稿して、広く流しても、``ローカル''なんでしょ
うか。(アングラ的というのも解せません。)

						wataru

---

From: [email-masked] (Masataka Ohta)
Date: 7 Nov 93 13:06:57 GMT

In article <[email-masked]>
	[email-masked] (Wataru KawaKami) writes:

>  NTTの川上です。芸風はともかく、

　自分らのやってることのレベルの低さを自覚してほしいもんですねえ。

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

　どうやら、馬鹿じゃない人も一人はいたようですね。

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

　やっぱ、勘違いか、、、

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Masataka Ohta)
Date: 7 Nov 93 13:19:36 GMT

In article <[email-masked]>
	[email-masked] (Akira Takuma) writes:

>MIME の宣言性自体は別に悪いことだとは思いませんが、

　悪いんですよ。

>結局自分の知らない

　ということで、さすがにＩＥＴＦは馬鹿ばっかじゃないようで、ＭＩＭＥ　ｔ
ｙｐｅに関しては規制を強めつつあります。手遅れだと思うけど。

>思えるのですが。(もしくは本当に ESC コードだけか全体をエンコードする)

　ま、この程度じゃ、８２２読んだといっても３０点ですね。８２２を全く理解
せずにＭＩＭＥがどうのこうの言ってる馬鹿よりは数段ましですが。

　ｑｕｏｔｅｄ−ｓｔｒｉｎｇと、ＥＳＣの透過のためにＭＴＡとＭＵＡが果た
すべき役割についてレポート書いたら、あと２０点くらい加えてもいいかな。現
実のインプリについて調べたら、もう２０点。

　ま、いずれにせよ、いまさらエスケープの透過に血道をあげるよりは、文字コ
ード設計し直すほうがよっぽど簡単です（でした）けどね。

					太田　昌孝
					[email-masked]

---

From: [email-masked] (Wataru KAWAKAMI)
Date: Fri, 5 Nov 1993 03:54:56 GMT

### Japanese subject will be read as below: ###
X-Nsubject: Re: アングラ (Re: X-Nsubjectについての誤解.....)

  NTTの川上です。

  "fj.mail"の"Re: misunderstood of X-Nsubject (Re: Use jis7 in .....)"について
    (記事<[email-masked]>)、[email-masked]、
  >> 
  >> 　もし、川上さんの言うようにfj.sourcesにサンプルインプリメンテーション
  >> を投稿しただけで通信プロトコルが決定されるとしたら、それは非常におかし
  >> い考えだと思います。
そんなことは、誰も、いっていません。お願いですから、
話しの腰を*もまないで*下さい。

# ホントにそう思っていたら、だれもこんなところで議論を
# しませんよね？

  kazamaさんの``アングラ''の意味を確認したかっただけ
ですが。(お願いですから、憶測から、あたかも、あなたが
考えられているように、人が考えているかのよう*決めつける*
のは、やめて下さい。議論の見通しが悪くなると思います。)

  再度、確認しますが、kazamaさんのいっているところの、
アングラとは、
	公開(表だって)か非公開(隠れた)に関係なく、規格に
	なっていない
の意味ですね？つまり、表だって、実験的に、user-definedな
フィールドである、
	X-*
を使うということは、"アングラ"であるということですね？
(規格になっていたら、X-*にはなっていないはずですから。)

					wataru

# アングラって、"非公開(隠れた)かつ規格になっていない"と
# いった意味に使うと思うのですが、いかがでしょうか。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**

---

From: [email-masked] (Wataru KawaKami)
Date: 9 Nov 93 10:27:30 GMT

### Japanese subject will be read as below: ###
X-Nsubject: quoted-pairを使えば、jis7もFrom:を通る? (was Re: rfc822より....)

  NTTの川上です。

  "fj.mail"の
  "Re: From rfc822 (was Re: header ni MIME dounyuu ni tsuite)"について
    (記事<[email-masked]>)、
    [email-masked]、
  >> 　自分らのやってることのレベルの低さを自覚してほしいもんですねえ。
レベルの高いところは、mohtaさんにお任せします。:-)

というのは、さておいて。。。。

  >> >部分は、contents(body)にいれるのが筋のようです。
これは、別記事で訂正をだしました。(rfc822では、contentsについて
のみ、規定している。また、contents=(header+body)であるなど。)
# もう届きましたでしょうか？

  comment部分に本当にjis7が通せないかということを念頭に、rfc822を
眺めたところ、
	comment = "(" *(ctext / quoted-pair / comment) ")"
	quoted-string = <"> *(qtext/quoted-pair) <">
	quoted-pair = "\" CHAR		; may quote any char
	CHAR = <any ascii-character>	; (0-127) in decimal
となっており、quoted-pairを適宜使えば、quoted-string, domain-
literal, commentなら、重たいMIME+base64をわざわざ使わなくても、
jis7は等価的に通るのではないかということがわかってきました。
# もっと簡単にjis7をコメントにいれられそうですね。>moriokaさん
# こっちで、考えれば、アングラでない？:-)

だけど、現実問題、MTA/MUAがちゃんと実装されているのかなぁ。。。

あと、databaseとしての使い勝手を考えると、
  1) saveするときは、jis7に変換して、MTAになげるまえに、quoted-
     pairに変換する(userには、header部分も含めてjis7テキストに
     見える。)
  2) saveするときは、もとのヘッダー(Subject:,From:など)は、いじ
     らずにquoted-pairが入ったままにして、適当なヘッダー
     (X-Nsubject:,X-Nfrom:)を作って、そこにjis7生をいれておく
  3) quoted-pairを解釈するgrepを作る
かな。。。。

						wataru
# 似非rfc822が、Subject:のESCをハネル。:-<
# いずれにせよ、よい、勉強になります。
--
   川上　弥(かわかみ わたる) <[email-masked]>, NTT
 **** 漢字文は、日本人にとっての plain text だと思う。 ****
 ** header に一日も早く JIScode の ESC が通りますように。**