Path: ie.u-ryukyu.ac.jp!u-ryukyu.ac.jp!oix.u-ryukyu.ac.jp!newshost.ryukyu.ad.jp!karei.center.oitaweb.ad.jp!newsfeed7.infoweb.ne.jp!newsgate1.web.ad.jp!newsfeed.mesh.ad.jp!onodera-news!Q.T.Honey!netaidnews!newsfeed.ip-kyoto.ad.jp!wnoc-kyo-news!cancer.nca5.ad.jp!nnws-lbm!toda
From: toda@lbm.go.jp
Newsgroups: fj.soc.copyright,fj.net.mime
Subject: 「Re: Re: Re:」問題 (Re: Ｎスぺをダビングさせて下さい)
Followup-To: fj.net.mime
Date: 11 Aug 2000 12:14:58 GMT
Organization: Lake Biwa Museum, Shiga Prefecture, Japan
Lines: 117
Message-ID: < 8n0qo2$3ie@nws-7000.lbm.go.jp> 
References: < 8mmi35$62q$1@neelix.mmtr.or.jp> 
	< 13365.965700952@rananim.ie.u-ryukyu.ac.jp> 
	< 8mp6r4$5f0$1@neelix.mmtr.or.jp> 
NNTP-Posting-Host: nws5000.lbm.go.jp
X-Newsreader: mnews [version 1.22] 1999-12/19(Sun)
Xref: ie.u-ryukyu.ac.jp fj.soc.copyright:11479 fj.net.mime:888

著作権論争は疲れるので参入するつもりは無いんですが、
「Re: Re: Re:」の問題について
＃ Followup-To: fj.net.mime とします。

In article < 8mp6r4$5f0$1@neelix.mmtr.or.jp>  niimi@gld.mmtr.or.jp writes:
> > > # なんだか河野氏は「Re: 」を増やすのが趣味みたいだなぁ。
> > > # 削っておこう。
> > Re: が増えるのは、Re:を含めてMIMEエンコードしているやつの方
> > に責任があるんだよ.... いったい何使ってるんだろう... 
> 私じゃないよ。増やしてるのは。
> 増えてるのは河野氏の記事からだよねぇ… このスレッドでは。

新美さんの環境から見れば
河野さんの記事で増えてるように見えると思いますが、
増える原因は、その直前の新美さんの記事にあるんですよ。

例えば、上に引用したやりとりの直接の契機になった記事の
Subjectは以下のようになっています。

河野さん
Message-ID: < 10646.965525246@rananim.ie.u-ryukyu.ac.jp> 
Date: 6 Aug 2000 01:27:01 GMT
Subject: Re: Ｎスぺをダビングさせて下さい

新美さん
Message-ID: < 8mk10c$81q$1@neelix.mmtr.or.jp> 
Date: Mon, 7 Aug 2000 00:10:18 +0900
Subject: Re: Ｎスぺをダビングさせて下さい

河野さん
Message-ID: < 11742.965588488@rananim.ie.u-ryukyu.ac.jp> 
Date: 6 Aug 2000 19:01:03 GMT
Subject: Re: Re: Ｎスぺをダビングさせて下さい

新美さん
Message-ID: < 8ml7v3$mkd$2@neelix.mmtr.or.jp> 
Date: Mon, 7 Aug 2000 11:30:01 +0900
Subject: Re: Re: Ｎスぺをダビングさせて下さい

河野さんは、いわゆる「生JIS」ですね。
「Subject: 」の後にいきなり「Re: 」が来て、
その後に「ESC $ B」で始まるISO-2022-JP文字列がそのまま入っています。

一方の新美さんは、いわゆる「MIME-Bエンコード」なんですが、
「Subject: 」の後にいきなり「=?iso-2022-jp?」で始まる
MIMEエンコードされた文字列が入っています。
つまり、インターネットを記事が流れている状態では
「Subject: 」の直後に「Re:」は存在せず、
MIMEデコードして初めて「Re:」という文字列が見えるのです。

さて、河野さんの環境は、ユーザが記事にフォローする意思を示した時に、
(1)元の記事のSubject（MIMEデコードも何もしない状態の元の文字列）の
   冒頭が「Re:」であるかどうかを判断し、違う場合は
   元の記事のSubjectの冒頭に「Re: 」を付加したものをSubjectとする
   「記事の叩き台」を準備し、編集環境に引き渡す。
(2)編集環境は、SubjectにMIMEエンコードされた文字列があれば
   デコードして、ユーザに編集させる。
(3)編集の終了した記事は（ISO-2022-JPでなければISO-2022-JPに変換して）
   そのままMIMEエンコードせずに投稿される。
という動作をするようになっているものと推測されます。

しかるに、新美さんの記事のSubjectの冒頭は
“MIMEデコードして「Re:」になる文字列”ではあっても
「Re:」そのものではありませんから、
河野さんの環境では「Re:」で始まっていないSubjectであると判断して
「Re: 」を付加します。その後でMIMEデコードされるので、

Subject: Re: Re: Ｎスぺをダビングさせて下さい

になるわけです。河野さんが編集段階でこれに気付いて
「Re:」１個を手動で除去すれば良いのですが、
論争が進んでいる最中に逐一注意せよという方が無理です。
で、そのまま記事が出て行ってしまうというわけです。
 
これに対策するには、

(a)MIMEエンコードする際に冒頭の「Re:」をエンコードしない。
つまり、本件の場合は

Subject: Re: Ｎスぺをダビングさせて下さい

という要領でエンコードする。

(b)フォローする側が、「Re:」の存在を判断する前にMIMEデコードする。

の何れか片方が励行されれば良いわけですが、
これまでの議論では(a)の方法で対策するべきであるというのが
大勢だったと思います。それは、特にfj.*においては

	MIME環境に対応することを参加者に強制するべきでない

と考えるのが大勢であるからです。その背景には

	そもそもMIMEエンコード自体が
	合意手続き抜きで「なし崩し」的に導入された

という経緯もあります。それゆえに、

	MIMEエンコードに伴って発生する問題には
	MIMEエンコードする側が対処するべきである

という基本姿勢になるわけです。

MIMEエンコードされたSubjectは未対応環境では読めませんが、
本文が読めれば議論に参加するに何の支障もありませんから、
それゆえに容認されているというのが実態です。

それに、新美さんの環境が行っているMIMEエンコードは、
それ自体がRFC違反だという説を唱える人も居るようです。
（RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
“MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）

というわけで、この問題に関しては、
新美さんの方が分が悪いんですよ。

                                戸田 孝＠滋賀県立琵琶湖博物館
                                 toda@lbm.go.jp