🚀 go-pugleaf

In article <xqryb0k33c1.fsf@srapc342.sra.co.jp>,
  Noriyuki Soda <soda@sra.co.jp> writes:

> この規定ですが、RFC1468 の著者の意図したことではなく、formal syntax を
> 記述する上での単なる誤りです。
> このことは、作成者も気づいており、それが
> 	draft-yamamoto-charset-iso-2022-jp-00.txt
> が生まれたきっかけの一つ（他の理由も大きいけど）ですよね。

そのあたりの経緯はよく知りません。

> ですから、
> 	charset=ISO-2022-JP で、ESC ( B や ESC ( J の入ってない行を
> 	含むメッセージは、RFC1468 に違反する
> という主張は、正しいとは思われません。

そうですか?

RFC1468 の問題点をみんなが知っていて, 何もいわなくても頭の中で適切に修
正したものを元に議論をしていると仮定できるならそれでもいいかもしれませ
んが, 少なくとも fj ではそのような仮定ができるとは思えません。

議論をする時は, もっと精密に行なうべきでしょう。

> RFC1468 の formal syntax には確かに違反していますが、それは、メッセー
> ジの方が間違っているのではなく、formal syntax の方が間違っているのでしょ
> う？

そのことに異論はありません。

> ここで、「それでも規格は規格だ」という建前論もありえるわけですが、
> 	・ほとんどの実装は、間違った formal syntax ではなく、RFC1468 
> 	  の著者の、もともとの意図に沿っている。
> 	・問題を fix した IETF draft が提出されている。
> という現状から見て、そういう建前論を擁護する必要は感じません。

私は, RFC を参照したときには RFC をちゃんと読んで欲しいということを願っ
ているに過ぎません。

そして, 少なくとも end 行に関連する議論で RFC を参照している人が,
RFC1468 の問題点を理解した上で議論しているように見えたことはないように
思います。

ところで, だれか JIS X 0201 Latin で終了する記事が化けるようなリーダー
を開発しないもんでしょうか?

> 田中さんは上記の IETF draft の作成に大きく関与していたわけですから、当
> 然、このことは ご存知かと思っていました。

私が口を出しはじめたのはかなり後の方になってからです。それも draft の
明らかな間違いや曖昧な解釈が可能な記述を取り除くという比較的単純なこと
しかやっていません。

だから, そもそもなぜ draft を出そうということになったのか, という話は 
draft の冒頭を読んでわかる程度にしか知りません。
(あれよりも詳しい話はどこかに書いてありましたっけ?)
-- 
[田中 哲][たなか あきら][Tanaka Akira]